Enterprise Plan: Boost SOC Performance, Reduce Business Risks with ANY.RUN

Editor’s note: The current article was originally published on April 10, 2024, and updated on July 15, 2025.

Modern cybersecurity teams face growing pressure: more threats, tighter SLAs, and less time to investigate. The difference between fast containment and a damaging breach often comes down to visibility, collaboration, and control. 

ANY.RUN’s Enterprise plan is a complete malware analysis plan built for organizations that can’t afford to miss a threat. It combines interactive sandboxing, robust privacy settings, centralized team management, and flexible integrations.  

It provides SOCs with the full picture of every threat, helping them respond quickly and accurately, no matter the size or sector of your organization. 

Integrate ANY.RUN in your SOC
Contact us for a quote or personalized demo 



Contact us


Why Leading Security Teams Choose ANY.RUN’s Enterprise Plan 

ANY.RUN’s Interactive Sandbox is used by SOC teams for malware and phishing analysis 

Enterprise gives security teams all the essentials in a single, unified solution—from threat visibility and secure collaboration to automation and ecosystem integration. With a setup designed to fit into existing workflows, it removes bottlenecks and accelerates decision-making at every stage of investigation. 

The results speak for themselves: 

  • 90% of companies report higher detection rates after adopting ANY.RUN 
  • 95% say they resolve investigations significantly faster 
  • 80% of Fortune 100 companies rely on ANY.RUN in their security operations 
  • Trusted by 15,000+ organizations across finance, telecom, retail, government, and healthcare 

ANY.RUN helps teams cut through alert noise, validate threats faster, and stay ahead of what’s coming next. 

☝ Enterprise Plan:
  • Is for SOC teams and MSSPs
  • Offers all features, including teamwork and Automated Interactivity
  • Available for integration via API and SDK
  • Covers 5 or more seats

Real-World Success Stories: How Security Teams Win with ANY.RUN Enterprise 

ANY.RUN’s Enterprise plan is trusted by leading organizations to solve real problems, streamline operations, and stay ahead of threats. 

From managed security providers to financial institutions, more than 15,000 organizations around the world use Enterprise to improve visibility, accelerate response, and strengthen their security posture. 

Expertware Cuts Investigation Time by 50% with ANY.RUN Enterprise 

Expertware, a leading European IT consultancy, needed to accelerate investigations, reduce manual overhead, and deliver faster results to clients. With Enterprise, they achieved a 50% reduction in malware investigation turnaround time

By replacing time-consuming manual setups with interactive sandboxing, Expertware improved visibility into complex threats, streamlined collaboration across their SOC, and scaled operations without adding overhead. 

Besides the faster investigation, Expertware achieved: 

  • Greater SOC efficiency: Interactive analysis and shared reports improved collaboration and reduced rework 
  • Deeper visibility: Full insight into multi-stage and fileless attacks, from macro execution to C2 communication 
  • Stronger client outcomes: Faster, clearer reporting helps clients respond before threats escalate 

Investment Bank Improves SOC Efficiency and Stops Ransomware with ANY.RUN Enterprise 

A Brussels-based investment bank adopted ANY.RUN’s Enterprise plan to overhaul its overloaded cybersecurity operations. Facing constant phishing and ransomware threats, their lean SOC team needed a solution that could speed up investigations, enhance visibility, and reduce manual work. 

With ANY.RUN, they replaced slow, manual triage processes with interactive sandboxing and automated analysis, allowing them to detect and contain attacks faster, without adding headcount. 

The combination of speed and knowledge allowed us to identify and prevent cyber attacks better than ever before.

Head of Cybersecurity, EU-based investment bank

Key improvements after adopting the Enterprise plan: 

  • Faster triage and response: Analysts process alerts twice as fast using automated sandbox submissions and interactivity 
  • Smarter planning and decision-making: Deeper behavioral insights help the team prioritize threats more effectively 
  • Prevented major ransomware incident: A suspicious supplier email was detonated in the sandbox, revealing ransomware and saving the company from significant financial and reputational damage 

ANY.RUN became a central part of their modernized SOC, delivering speed, visibility, and control without increasing complexity. 

Privacy: Keep Investigations Secure and Under Control 

In threat investigations, privacy plays an important role. A single public task launched by mistake can expose sensitive data, damage trust, or break compliance. The Enterprise plan helps your team avoid those risks with flexible private analysis options, role-based visibility controls, and secure access through SSO. 

Flexible Private Analysis Quotas 

Enterprise customers can choose the model that fits their team structure best: 

  • Unlimited private analyses per user with a per-user pricing model 
  • Unlimited users with a per-analysis pricing model 

This flexibility makes sure your investigations stay private, without limiting your team’s ability to scale or collaborate. 

Granular Privacy Controls 

Manage privacy in your team settings

You can control each user’s access to the sandbox, including the default privacy level of their analyses; whether tasks are visible only to the user, shared with the team, or accessible via a link. Team masters can define what analysts are allowed to share and ensure sensitive investigations aren’t exposed by mistake. 

In large or distributed teams, one misconfigured setting can lead to accidental data leaks. Granular privacy controls help reduce that risk by enforcing visibility rules at the user level, keeping your analysis environment secure without slowing your team down. 

Let us show you how ANY.RUN can help your SOC team – book a call with us ⬇

Single Sign-On (SSO): Simpler Access, Stronger Control 

For busy security teams, managing multiple logins can slow things down, and increase risk. With Single Sign-On (SSO) in the Enterprise plan, your team can log in to ANY.RUN using the same credentials they use across the rest of your organization. 

That means: 

  • Fewer login issues and less time wasted on password resets 
  • Stronger access control, especially as your team grows 
  • Easier onboarding and offboarding for analysts and contractors 

SSO helps your SOC stay efficient and secure, giving every team member fast, reliable access to the sandbox, without extra friction. It also reduces the chance of human error, making it easier to stay compliant with internal policies and external standards. 

Automated Interactivity: Streamline Analysis for Faster Response

See a video recording of the analysis performed by Automated Interactivity

Automated Interactivity, powered by machine learning, enables security teams to automate file/URL analysis by letting the sandbox simulate human actions to outsmart evasion tactics like CAPTCHAs and redirects. Available exclusively in Enterprise plan, it gives a massive boost to SOC efficiency by automating detonation of attacks and accelerating threat detection.

It identifies and detonates malicious content, such as email attachments, payloads inside archives, URLs in QR codes. Thanks to this feature, your SOC team can reduce workload, improve the detection rate and alert processing capabilities, while focusing on critical incidents only.

This sandbox has provided features we didn’t have previously and helps to make the team more efficient

Joel P., Enterprise (> 1000 emp.)

API/SDK: Integrate ANY.RUN for Faster SOC Workflows 

ANY.RUN app for IBM QRadar SOAR 

The Enterprise plan gives your team full access to API and SDK integrations, so you can embed ANY.RUN directly into your existing workflows, automate routine tasks, and enrich investigations with real-time behavioral data. 

Whether you use a SIEM, SOAR, or case management platform, ANY.RUN connects seamlessly, helping analysts cut down on manual effort and focus on what matters most. 

You can set up integration with other security vendors with ease

One of our latest integrations is with IBM QRadar SOAR, a popular platform for incident response. With ANY.RUN’s official app, teams can: 

  • Launch sandbox analyses directly from SOAR playbooks 
  • Enrich cases with fresh IOCs and behavioral insights 
  • Automate repetitive tasks to reduce Mean Time to Respond (MTTR) 

Setup takes minutes; just plug in your API key and get started. 

With integrations like this, ANY.RUN becomes a natural part of your security workflow, helping your team move faster, stay aligned, and act with greater precision. 

Teamwork: Smarter Collaboration for Analysts 

Even the most advanced tools fall short when teams can’t work together effectively. In many SOCs, analysts work in silos, communication breaks down, and duplicated work or missed alerts slow down investigations. 

Team management displayed inside ANY.RUN sandbox

The Teamwork feature in Enterprise makes collaboration seamless, whether your team sits in the same room or operates across time zones. Analysts can join a shared workspace, while team leads assign roles, track progress, and manage licenses, all from one central interface. 

  • Faster coordination across analysts, team leads, and managers 
  • Clear task ownership and role definitions to avoid confusion or rework 
  • Real-time supervision for team leads, without disrupting workflow 
  • Scalable team structure, ready to support fast-growing SOCs 
Track team members’ productivity

When every analyst knows what to focus on, and team leads can oversee without micromanaging, you reduce delays, avoid duplication, and build a stronger response process. 

ANY.RUN is used by companies of different sizes and across numerous industries

Other Enterprise-Grade Capabilities for Deeper, More Accurate Investigations 

The sandbox offers advanced threat analysis capabilities across Windows, Linux, and Android

The Enterprise plan gives your analysts the technical depth and flexibility to run more realistic, multi-stage investigations and uncover even the most evasive threats. 

  • Ensure full sandbox coverage without feature limitations: Enterprise users get access to 100% of sandbox functionality, unlocking every detection layer and configuration option available. 
  • Investigate advanced malware without time pressure: With 1,200-second VM timeout, your team has the time needed to observe full execution chains, from initial dropper to final payload. 
  • Reveal location-based behavior and evasion techniques: Use residential proxy and locale selection to simulate real-world environments and detect malware that hides its behavior under generic settings. 
  • Analyze threats across real-world environments: Run samples in Windows (11 64-bit, 10 32-bit, and Windows 10 64-bit for Developers, exclusive to Enterprise), Linux, and Android to detect OS-specific behavior and expand coverage across your attack surface. 
  • Uncover stealthy or delayed malicious actions: Rely on system process monitoring and reboot support to catch techniques that only activate during system events or over time. 
  • Enable external reporting and automation with precision: Export results using JSON and MISP formats, making it easier to integrate analysis findings into your internal tools or client reporting. 
  • Support managed services and external collaboration: Work with confidence using a commercial license, built for MSSPs and enterprise security teams with external commitments. 

These capabilities make Enterprise more practical for real-world, high-stakes investigations that demand clarity, completeness, and context. 

Trusted by Industry Leaders and Backed by the Community 

ANY.RUN is consistently rated as a leading solution on major platforms. 

Gartner Peer Insights Rating for ANY.RUN  

From MSSPs to financial institutions, teams around the world choose ANY.RUN to investigate faster, detect smarter, and simplify their daily workflows. These ratings reflect what thousands of users already know: interactive analysis makes all the difference

Boost SOC Performance with Real-Time Threat Intelligence 

Teams using ANY.RUN’s Interactive Sandbox also utilize advanced Threat Intelligence solutions that help you enrich your security, from detection to prevention. 

Threat Intelligence Lookup 

Threat Intelligence Lookup provides free access to fresh, live threat intelligence

Quickly assess suspicious IPs, domains, hashes, and URLs with real-time context from live sandbox detonations across 15,000 organizations. TI Lookup lets you uses over 40 behavioral and static indicators to help SOC teams make faster decisions, reduce false positives, and respond to threats before they escalate, minimizing business risk and cutting investigation time. 

Explore Threat Intelligence Lookup 

Threat Intelligence Feeds 

ANY.RUN’s TI Feeds offer unique malicious IPs, domains, and URLs for proactive defense 

Receive continuously updated network indicators pulled from the latest malware samples analyzed in our sandbox. ANY.RUN’s TI Feeds help you proactively block threats and improve detection rules across your entire security stack. 

Explore Threat Intelligence Feeds 

About ANY.RUN 

Designed to accelerate threat detection and improve response times, ANY.RUN equips teams with interactive malware analysis capabilities and real-time threat intelligence. 

ANY.RUN’s cloud-based sandbox supports investigations across Windows, Linux, and Android environments. Combined with Threat Intelligence Lookup and Feeds, our solutions give security teams full behavioral visibility, context-rich IOCs, and automation-ready outputs, all with zero infrastructure overhead. 

Ready to see how ANY.RUN’s services can power your SOC?   

Start your 14-day trial now → 

The post Enterprise Plan: Boost SOC Performance, Reduce Business Risks with ANY.RUN appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

Defendnot: fake antivirus software to disable Microsoft Defender

Many companies today operate a Bring Your Own Device (BYOD) policy, allowing employees to use their own devices for work purposes. This practice is especially prevalent in organizations that embrace remote working. BYOD brings many obvious advantages, but its implementation creates new risks for companies in terms of cybersecurity.

To protect systems from threats, information security departments often require that security software is installed on all devices used for work. At the same time, some employees – especially hotshot techies – may view antivirus software more as a hindrance than a help.

Not the most sensible attitude for sure, but convincing them otherwise can be hard. The main problem is that employees who believe they know better may find a way to dupe the system. Today, we investigate one such method: a new research tool known as Defendnot, which disables Microsoft Defender on Windows devices by registering fake antivirus software.

How no-defender blazed the trail using fake antivirus to disable Microsoft Defender

To understand exactly how Defendnot disables Microsoft Defender, we need to turn the clock back a year. Back then, a researcher with the X handle es3n1n created and published the first version of the tool on GitHub. Called no-defender, it was tasked with disabling the built-in Windows Defender antivirus.

To accomplish this task, es3n1n exploited a weakness in the Windows Security Center (WSC) API. Through it, antivirus software informs the system that it is installed and ready to start protecting the device in real time. Upon receiving such a message, Windows automatically disables Microsoft Defender to avoid conflicts between different security solutions all running on the same device.

Using the code of an existing security solution, the researcher created their own fake antivirus that registered in the system and passed all Windows checks. Once Microsoft Defender was disabled, the device was left unprotected – since no-defender offered no protection of its own.

The no-defender project quickly drew a following on GitHub, where it was starred over two thousand times. However, the antivirus developer company whose code was reused filed a complaint for violation of the Digital Millennium Copyright Act (DMCA). So es3n1n was forced to remove the project code from GitHub, leaving only a description page.

How Defendnot succeeded no-defender

But the story doesn’t end there. Almost a year later, New Zealand programmer MrBruh prompted es3n1n into developing a version of no-defender that didn’t rely on third-party code. Piqued by the challenge and poor sleep, es3n1n wrote a new tool in four days flat, which was dubbed Defendnot.

At the heart of Defendnot was a stub DLL posing as a legitimate antivirus. To bypass all WSC API checks – including Protected Process Light (PPL), digital signatures and other mechanisms – Defendnot injects its DLL into Taskmgr.exe, which is signed and already considered as trusted by Microsoft. The tool then registers the fake antivirus, prompting Microsoft Defender to immediately turn off and leave the device without active protection.

On top of that, Defendnot allows the user to assign any name to the “antivirus”. Similarly to its predecessor, this project became a hit on GitHub, having been starred 2100 times at the time of writing. To install Defendnot, the user must have administrator rights (which employees most likely have on personal devices).

How to protect corporate infrastructure from BYOD misuse

Defendnot and no-defender are positioned as research projects, with both tools demonstrating how trusted system mechanisms can be manipulated to disable protective functions. The conclusion is obvious: you can’t always trust what Windows says.

Therefore, so as not to endanger your company’s digital infrastructure, we recommend beefing up its BYOD policy with a number of additional security measures:

  • Where possible, make it mandatory for BYOD device owners to install reliable corporate protection administered by the company’s information security team.
  • If this is not possible, do not consider BYOD devices as trusted simply for having antivirus software installed, and limit their access to corporate systems.
  • Strictly control access permissions to ensure they correspond to employees’ job responsibilities.
  • Pay special attention to BYOD device activity in corporate systems, and deploy an XDR solution to monitor behavioral anomalies.
  • Train employees in the basics of cybersecurity so that they understand how antivirus software works, and why they shouldn’t try to disable it. To help with this, our Kaspersky Automated Security Awareness Platform delivers all you need and more.

Kaspersky official blog – ​Read More

What an SMS blaster is, and how to protect yourself from malicious SMS messages while traveling | Kaspersky official blog

Fake text messages pretending to be from banks, delivery services, or municipal agencies are scammers’ tactic of choice to trick people into revealing financial information and passwords. This type of phishing is often referred to as “smishing” (from “SMS phishing”). While nearly every carrier filters dangerous text messages, and only a fraction reach recipients, scammers have come up with something new. Over the past year, criminals have been arrested in the UK, Thailand, and New Zealand for sending messages that bypassed carrier networks and went directly to victims’ phones. This technology is known as “SMS blasting”.

What is an SMS blaster?

An SMS blaster pretends to be a cellular base station. About the size of an old computer tower, it bristles with antennas. Scammers often stash it in the trunk of a car or even in a backpack. Once activated, the blaster prompts all nearby phones to connect to it, as it appears to be the most powerful base station with the best signal. When a phone connects, it receives a fake SMS. Depending on the blaster model and reception conditions, the SMS broadcast range is between around 500 and 2000 meters. This is why criminals prefer to operate in crowded areas like shopping malls, or tourist and business centers: these are where all known attacks have been recorded. What’s more, the tech the scammers use provides them with all sorts of tricks: they don’t pay for the messages, they can spoof any sender, and they’re free to include any links at all; they don’t even need to know victims’ phone numbers: any phone will receive a message if it connects to the fake cell tower.

How an SMS blaster works

An SMS blaster exploits vulnerabilities in the 2G (GSM) communication standard. While 2G is primarily used today in remote, sparsely populated areas, all phones still support it. First, the blaster sends a technical signal over modern 4G/5G networks. When any phone or smartphone receives this signal, it attempts to switch to a 2G network. Simultaneously, the blaster broadcasts fake 2G base-station signals. The victim’s smartphone recognizes these as legitimate carrier signals and connects. Unlike the 3G, 4G, and 5G standards – where the smartphone and base station always perform a mutual cryptographic check during connection – this feature was only optional in 2G. This loophole allows an SMS blaster to mimic any carrier. Once connected, it can send any text message to a smartphone. After transmitting the SMS, the fake base station disconnects, and the smartphone reverts to its normal 4G/5G network with its legitimate carrier.

Perhaps surprisingly, this technology isn’t new. Similar to blasters, devices known as IMSI catchers, StingRays, or cell site simulators, have been used by law enforcement and intelligence agencies to gather data on individuals attending events of interest. However, criminals have found a new use for the technology.

Defending against SMS blasters

You can block fake text messages by disabling 2G network connectivity on your smartphone, but that’s a double-edged sword. If you live in an area with poor signal or far from major cities, your phone might still occasionally use 2G. This is why many carriers haven’t completely phased out the outdated technology.

If you haven’t seen the 2G icon (an “E” or “G” next to your signal-strength indicator) in years, you might want to consider this option. Android phones running version 12 or newer offer the ability to disable 2G, but not every vendor makes this toggle visible and accessible. Android 16 introduced notifications that alert you if your smartphone might be connected to a fake 2G tower, but due to hardware limitations these only work on certain newer smartphones.

There’s no similar option in iOS, but you can effectively disable 2G by activating Lockdown Mode. Unfortunately, this does far more than just turn off 2G; it significantly restricts many iPhone functions in the name of maximum security (many would say it renders an iPhone practically unusable).

To avoid sacrificing your phone’s functionality while still protecting yourself from dangerous text messages, consider using a comprehensive smartphone security system. SMS blasts will still be delivered to your phone, but they won’t cause harm thanks to two layers of protection. The system identifies malicious messages regardless of the cellular network and blocks SMS spam (only on Android devices), while phishing protection prevents you from navigating to dangerous websites (on all smartphones).

Beyond technical measures, vigilance and general precautions are crucial in combating fake text messages. Instead of tapping links, sign in to your banking app or delivery service website directly from your bookmarks, your smartphone’s home screen, or by manually typing the address into your browser.

What other tricks do scammers use to try and sneak into your smartphone?

Kaspersky official blog – ​Read More

Patch, track, repeat

Patch, track, repeat

Welcome to this week’s edition of the Threat Source newsletter.

We’ve made it halfway through 2025 already! It’s been a while since I last wrote about CVEs and how free support for Windows 10 will end on October 14, 2025, leaving you with no more security fixes.

While the CVE system remains the global standard for vulnerability reporting, recent developments have sparked concerns within the community about its long-term stability. Currently, the program operates solely as a U.S. government-funded initiative. Following the last-minute funding extension, we’re now seeing competing ideas and projects emerging. Whether it’s the CVE Foundation working to transition from a single funding stream to a diversified and stable model, ENISA’s EUVD, or the Global CVE Allocation System (GCVE), the landscape is changing.

On one hand, a multi-source environment enhances availability and resilience. On the other, this fragmentation raises practical concerns for both researchers and practitioners. We now face questions like “Where should I report a vulnerability?” and “How do I integrate and correlate vulnerability data across multiple sources with multiple identifiers?”

Looking back at the first six months of this year, we see that the rapid pace of CVE publications in 2024 has continued into 2025, with no signs of slowing down. In fact, the current trend suggests that 2025 will surpass last year’s total of a little more than 40,000 CVEs. To illustrate: the first half of 2024 saw an average of 113 CVEs published per day, whereas the first half of 2025 is running at a rate of 131 CVEs per day.

Patch, track, repeat

What concerns me even more is the steep increase in Known Exploited Vulnerabilities (KEVs). It wasn’t just the spike in March — we’re seeing a generally sharper rise overall.

Patch, track, repeat

Vendor diversity also continues to expand, increasing from 45 vendors during the first half of last year to 61 so far this year. Additionally, the proportion of KEVs affecting network-related gear has grown from 22.5% in 2024 to 25% in 2025.

But there’s a small piece of good news: So far, I haven’t seen any CVEs from as far back as 2012 being added to the KEV catalogue like we saw last year. This time, the oldest additions “only” go back to 2017.

Patch, track, repeat

Keep in mind that the CVE year merely indicates when a vulnerability was reserved or assigned. The vulnerability itself may have existed for many years prior. For example, the recent sudo/chroot issue remained undiscovered for over 12 years. 

In a nutshell: Keep tracking, keep patching. Vulnerabilities certainly won’t patch themselves.

The one big thing 

Microsoft’s July 2025 security update addresses 132 vulnerabilities, including 14 marked as “critical,” with several remote code execution (RCE) issues affecting Windows, Office, SharePoint and Hyper-V. Although none have been exploited in the wild yet, some vulnerabilities — like those in SharePoint and SPNEGO NEGOEX — are more likely to be targeted and could allow attackers to execute code remotely or locally.

Why do I care? 

These vulnerabilities could let attackers take control of your systems, steal information or disrupt business operations, even if you haven’t seen any attacks yet. If you’re running Windows servers, SharePoint or Microsoft Office, your environment could be at risk, especially for organizations that rely on these products daily.

So now what? 

Don’t wait. Make sure you’re applying Microsoft’s July patches as soon as possible. If you use Cisco Security Firewall or SNORT®, update your rulesets to the latest versions to maximize your protection.

Top security headlines of the week 

Alleged Chinese hacker tied to Silk Typhoon arrested for cyberespionage
A Chinese national was arrested in Milan, Italy for allegedly being linked to the state-sponsored Silk Typhoon hacking group, which is responsible for cyberattacks against U.S. organizations and government agencies. (Bleeping Computer

Jailbreaking AI with information overload 
Researchers say you can trick AI chatbots like ChatGPT or Gemini into teaching you how to make a bomb or hack an ATM if you make the question complicated, full of academic jargon, and cite sources that do not exist. (404 Media

SatanLock is shutting down
The announcement that the group was closing its doors first came through its official Telegram channel and dark web leak site. Hunters International, another well-known ransomware group, also recently announced that it was shutting down its operations. (Dark Reading

Ingram Micro scrambling to restore systems after ransomware attack
The IT distributor giant confirmed over the weekend that a ransomware attack was responsible for a widespread outage over its services, and they were forced to take certain systems offline on Friday afternoon, in response to the incident. (SecurityWeek

Malicious Chrome extensions with 1.7M installs found on Web Store
Malicious extensions with 1.7 million downloads in Google’s Chrome Web Store pose as legitimate tools but could track users, steal browser activity, and redirect to potentially unsafe web addresses. (Bleeping Computer)

Can’t get enough Talos? 

Scams, jailbreaks and poetic justice
In this episode of the TTP, Hazel Burton sits down with Talos’ Jaeson Schultz to explore the underground world of criminal LLM abuse, from elaborate scams to role-playing jailbreak prompts designed to trick AI into ignoring its own rules.

Vulnerability Roundup
Cisco Talos’ Vulnerability Discovery & Research team has disclosed and coordinated patches for two vulnerabilities each in Asus Armoury Crate and Adobe Acrobat.

PDFs: Portable documents, or perfect deliveries for phish? 
A popular social engineering technique returns: callback phishing, or TOAD attacks, which leverage PDFs, VoIP anonymity and even QR code tricks.

Beers with Talos: Terms and conceptions may apply 
In this episode, the crew reassembles after a totally intentional and not-at-all accidental hiatus. They cover AI-assisted IVF, a possible underground war against dairy, and the real heroes: conference dogs.

Upcoming events where you can find Talos 

Most prevalent malware files from Talos telemetry over the past week 

SHA 256: a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91   
MD5: 7bdbd180c081fa63ca94f9c22c457376 
VirusTotal: https://www.virustotal.com/gui/file/a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91/details 
Typical Filename: IMG001.exe 
Detection Name: Simple_Custom_Detection   

SHA 256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 
MD5: 2915b3f8b703eb744fc54c81f4a9c67f 
VirusTotal: https://www.virustotal.com/gui/file/9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 
Typical Filename: VID001.exe 
Claimed Product: N/A 
Detection Name: Win.Worm.Coinminer::1201 

SHA256: 47ecaab5cd6b26fe18d9759a9392bce81ba379817c53a3a468fe9060a076f8ca  
MD5: 71fea034b422e4a17ebb06022532fdde  
VirusTotal: https://www.virustotal.com/gui/file/47ecaab5cd6b26fe18d9759a9392bce81ba379817c53a3a468fe9060a076f8ca/details 
Typical Filename: VID001.exe  
Claimed Product: N/A  
Detection Name: Coinminer:MBT.26mw.in14.Talos

Cisco Talos Blog – ​Read More

How extensions from Open VSX were used to steal cryptocurrency

Our researchers have uncovered several malicious fake extensions targeting Solidity developers in the Open VSX marketplace. At least one company has fallen victim to the attackers distributing these extensions — losing approximately US$500 000 in crypto assets.

Threats associated with malware distribution in open-source repositories have been known about for a long time. Despite this, users of AI-powered code editors like Cursor AI and Windsurf are forced to use the open-source extension marketplace Open VSX, as they have no other source for the extensions these platforms need.

However, extensions on Open VSX do not undergo the same rigorous checks as those on the Visual Studio Marketplace. This loophole allows attackers to distribute malicious software disguised as legitimate solutions. In this post, we dive into the details of the malicious Open VSX extensions investigated by our experts, and explain how to prevent similar incidents within your organization.

Risks for users of Open VSX extensions

In June 2025, a blockchain developer who had just lost approximately US$500 000 in crypto assets to attackers reached out to our experts and requested an incident investigation. While examining a disk image from the compromised system, our researchers noticed a suspicious component of an extension named Solidity Language for the Cursor AI development environment. The component was executing a PowerShell script — a sure sign of malicious activity.

The Solidity Language extension on the Open VSX marketplace

The description of the Solidity Language extension published on the Open VSX marketplace

The extension was installed from the Open VSX marketplace, where it had tens of thousands of downloads (presumably inflated by bot activity). The description claimed to optimize development of smart contract code written in the Solidity language. However, analysis of the extension revealed it had no useful functionality whatsoever. The developers who installed it mistook the lack of advertised features for a bug, didn’t immediately investigate, and just continued their work.

The browser extension wasn’t actually faulty; it was fake. Once installed, it contacted a command-and-control server to download and run a malicious script. This script then installed ScreenConnect — a remote access application — on the victim’s computer.

The attackers used ScreenConnect to upload additional malicious payloads. In the incident our experts investigated, these tools specifically allowed the attackers to steal passphrases for the developer’s crypto wallets and then syphon off cryptocurrency. A detailed technical description of the attack, along with indicators of compromise, is available in a Securelist blog post.

Manipulating search: how attackers promote malicious extensions

A look into the Open VSX marketplace revealed a concerning trend: a fake extension, deceptively named “Solidity Language”, ranked fourth in search results, while the legitimate extension, simply called solidity, appeared all the way down at eighth. It’s no surprise then that the developer downloaded the counterfeit instead of the genuine article.

When searching Open VSX for "solidity", the imposter extension appeared higher than the legitimate one

Search results for “solidity”: the malicious extension (red) vs. the legitimate one (green)

This ranking is quite surprising, especially considering that at the time of the search, the legitimate extension had more downloads: 61 000 compared to the fake’s 54 000.

The key lies in Open VSX’s ranking algorithm. It doesn’t solely rely on download counts to determine relevance; it also considers other factors like verification status, ratings, and recency. This is exactly how the attackers managed to outrank the genuine extension in search results: the fake one had a more recent update date.

The fake plugin was removed from the Open VSX marketplace on July 2, 2025, right after the cryptocurrency heist. However, the very next day, we found another malicious package with the same name as the original extension, “solidity”, and the same harmful functionality as Solidity Language.

Additionally, our researchers used an open-source component-monitoring tool to discover yet another malicious package in Open VSX. Several details link this package to the same cybercriminals.

Why do developers have to rely on the Open VSX marketplace?

The Visual Studio Marketplace, Microsoft’s official store, has long been the primary industry source for extensions. It includes automatic scanning for malicious code, sandboxed execution of extensions for behavioral analysis, monitoring for anomalies in extension usage, and a number of other features to help identify harmful extensions. However, its licensing agreement dictates that only solutions for use with Visual Studio products can be published in the Visual Studio Marketplace.

Consequently, users of increasingly popular AI-powered code editors like Cursor AI and Windsurf must install extensions from an alternative store: Open VSX. The problem is that this platform has less stringent extension vetting, which makes it easier to distribute malicious packages compared to Microsoft’s official marketplace.

To be fair, attackers sometimes manage to publish malicious extensions even in the more secure Visual Studio Marketplace. For instance, this spring, experts found three malicious extensions there with an infection scheme very similar to the one described in this post, also targeting Solidity developers.

How to stay safe?

No matter where you’re installing extensions from, we recommend the following:

  • Be careful when searching marketplaces.
  • Always take note of who the developer of an extension is.
  • Check the code and behavior of extensions you install.
  • Use an XDR solution to monitor any suspicious activity inside the corporate network.

Kaspersky official blog – ​Read More

Asus and Adobe vulnerabilities

Asus and Adobe vulnerabilities

Cisco Talos’ Vulnerability Discovery & Research team recently disclosed two vulnerabilities each in Asus Armoury Crate and Adobe Acrobat products.  

The vulnerabilities mentioned in this blog post have been patched by their respective vendors, all in adherence to Cisco’s third-party vulnerability disclosure policy.    

For Snort coverage that can detect the exploitation of these vulnerabilities, download the latest rule sets from Snort.org, and our latest Vulnerability Advisories are always posted on Talos Intelligence’s website.     

Asus Armoury Crate stack-based buffer overflow and authorization bypass  vulnerabilities

Discovered by Marcin 'Icewall' Noga of Cisco Talos.   

These vulnerabilities were recently covered in a deep-dive post, Decrement by one to rule them all.

Asus Armoury Crate is a software utility used to manage Asus and ROG lighting, performance, and updates.

TALOS-2025-2144 (CVE-2025-1533) is a stack-based buffer overflow vulnerability in the AsIO3.sys kernel driver of Asus Armoury Crate 5.9.13.0. A specially crafted I/O request packet (IRP) can lead to stack-based buffer overflow. An unprivileged attacker can run a program from user mode to trigger this vulnerability.

TALOS-2025-2150 (CVE-2025-3464) is an authorization bypass vulnerability in the AsIO3.sys functionality of Asus Armoury Crate 5.9.13.0. A specially crafted hard link can lead to an authorization bypass. An attacker can create a hard link to trigger this vulnerability.

Adobe Acrobat Reader out-of-bounds read and use-after-free vulnerabilities 

Discovered by Kamlapati Choubey of Cisco Talos.   

Adobe Acrobat Reader is one of the most popular PDF reading software currently available. Talos found an out-of-bounds read vuln, TALOS-2025-2159 (CVE-2025-43578), in the Font functionality of Adobe Acrobat Reader 2025.001.20435. A specially crafted font file embedded into a PDF can trigger this vulnerability which can lead to disclosure of sensitive information.

TALOS-2025-2170 (CVE-2025-43576) is a use-after-free vulnerability in the annotation object processing functionality of Adobe Acrobat Reader 2025.001.20435. A specially crafted Javascript code inside a malicious PDF document can trigger reuse of a previously freed object, which can lead to memory corruption and could result in arbitrary code execution.

An attacker needs to trick the user into opening the malicious file to trigger either of these vulnerabilities.

Cisco Talos Blog – ​Read More

Is a Gemini AI update about to kill privacy on your Android device? | Kaspersky official blog

On July 7, 2025, Google rolled out a Gemini update that gives its AI-powered assistant access to Phone, Messages, WhatsApp, and Utilities data on Android devices. The company announced this update via an email to the users of its chatbot — essentially presenting them with a fait accompli. “We’ve made it easier for Gemini to interact with your device”, the email read. “Gemini will soon be able to help you use Phone, Messages, WhatsApp, and Utilities on your phone, whether your Gemini Apps Activity is on or off”.

According to Google, the update improves privacy because users can now use Gemini's features without having to enable Gemini Apps Activity. Pretty convenient, right?

According to Google, the update improves privacy because users can now use Gemini’s features without having to enable Gemini Apps Activity. Pretty convenient, right?

The update applies regardless of whether the Gemini Apps Activity feature is enabled or not. Google pushed the update to all Android versions that support Gemini, starting with Android 10. So, although the company warned users, it clearly failed to ask for their explicit consent. Google has already practiced subtle coercion to use its features before: just a month ago, Gemini was integrated into the Gmail client without any warning.

The email itself contained neither clear instructions for how to disable the new features, nor detailed explanations as to what exactly Gemini would do with the collected data. Users received the email just two weeks before the update was launched.

As you’d expect, the tech community was on the verge of panic. Previously, users who wanted to integrate Gemini with their apps had to explicitly enable Gemini Apps Activity. This allowed Gemini to store and use their data long-term, and potentially gave developers access to it – of course, “only for the purpose of improving Google AI”.

Warning prompt when launching Gemini in the browser for the first time

Warning prompt when launching Gemini in the browser for the first time

Google isn’t alone in this. OpenAI, Anthropic, and other AI companies are guilty of the same “improving service quality” excuse. At least Google gives users the illusion of choice. What makes this case different is that, even with Gemini Apps Activity turned off, Google will still retain your conversations with the AI assistant for up to 72 hours — all for the same purposes of safety, security, and feedback.

We won’t debate whether this is good or bad — we’ll just show you how to completely block Gemini’s access to your apps and data. Grab your phone, and let’s go!…

How to disable Gemini via the app?

  1. Open Gemini on your Android device.
  2. Tap your profile picture or initials in the top-right corner.
  3. Select Gemini Apps Activity.
  4. Tap Turn off, or select Turn off and delete activity.
Disabling Gemini via the app

Disabling Gemini via the app

How to disable Gemini via the web interface?

  1. Open Gemini in a browser.
  2. Click the hamburger menu in the top-left corner.
  3. Select Activity or Settings & HelpActivity.
  4. Tap Turn off, or select Turn off and delete activity.

Alternatively, you can reach that option directly to turn off Gemini Apps Activity right there.

Disabling Gemini via the web interface

Disabling Gemini via the web interface

How to block Gemini from accessing individual apps and services?

If rather than disabling the AI assistant altogether you want to restrict Gemini’s access to data only from certain services like your email or photos, you can customize which apps it can work with and which it cannot.

Disabling Gemini’s access to individual services via the app:

  1. Open the Gemini app.
  2. Go to your profile and select Apps.
  3. Turn off the toggle next to each app or service whose data you don’t want to share with Gemini.
Disabling Gemini's access to individual services via the app

Disabling Gemini’s access to individual services via the app

Disabling Gemini’s access to individual services via the web interface:

  1. Open Gemini in a browser.
  2. Click the hamburger menu in the top-left corner.
  3. Select Settings & help → Apps.
  4. Turn off the toggle next to each app or service whose data you don’t want to share with Gemini.

Alternatively, you can reach that section of the settings directly.

Disabling Gemini's access to individual services via the web interface

Disabling Gemini’s access to individual services via the web interface

How to configure additional privacy settings for Gemini?

Deleting saved Gemini data:

  1. While in the Gemini app, go to your profile and select Gemini Apps Activity. In a browser, open Activity, click Delete, and select a time range.
    • Last hour/day clears your recent activity.
    • All time clears all your activity.
    • Custom range lets you select a range of data to clear.
  2. Confirm deletion.
Deleting saved Gemini data

Deleting saved Gemini data

Setting up auto-delete for Gemini data:

  1. While in the Gemini app, go to your profile, and select Gemini Apps Activity. In a browser, open Activity.
  2. Choose how long saved data will be kept before it’s deleted: three, 18, or 36 months.
Setting up auto-delete for Gemini data

Setting up auto-delete for Gemini data

How to completely remove Gemini from your smartphone?

If you plan not to use Gemini on your phone altogether, you can simply uninstall the app:

  1. Go to Settings and select Apps.
  2. Find Gemini, and tap Uninstall if that option is available.
  3. If you don’t see Uninstall, tap Disable Gemini is a system app on some phones and thus not easy to remove. For more details on how to deal with this, see Delete the undeletable: how to disable and remove Android bloatware.

If you’re determined not to have any Google services on your phone, consider installing GrapheneOS; however, be forewarned that this is a solution for geeks with a Pixel phone only.

How to check that you’ve successfully disabled Gemini?

When you’re done with the settings, it’s a good idea to verify if your changes have been applied successfully:

  1. Go to the Gemini Activity.
  2. Check that there are no records of your activity.
  3. In the Gemini app, check the state of the toggles in the Apps.
  4. Repeat these checks after each Google update you install.

To protect your Android device, use tried-and-true security solutions like Kaspersky for Android. This will give you peace of mind knowing you don’t have to worry about malware, your privacy, passwords, or personal and payment data.

Here are a few other posts about the subtleties of privacy in Google services and beyond.

Kaspersky official blog – ​Read More

How to Maintain Fast and Fatigue-Free Alert Triage with Threat Intelligence 

Alert triage as one of the critical SOC and MSSP workflows implies evaluating, prioritizing, and categorizing security alerts to determine which threats require immediate attention and which can be safely dismissed or handled through automated processes. 

Efficient alert triage, supported by robust threat intelligence, ensures that organizations stay ahead of adversaries while maintaining analyst productivity and morale. We shall see how it works on the example of ANY.RUN’s Threat Intelligence Lookup.  

Why Triage is the Key to Efficiency 

For SOCs, triage ensures that internal teams focus on high-priority incidents that could compromise critical systems or data. MSSPs, managing multiple clients, rely on triage to allocate resources efficiently across diverse environments, ensuring timely responses tailored to each client’s needs.  

The triage process acts as the gateway between detection and action — the critical juncture where security alerts either trigger appropriate defensive measures or fade into background noise. 

Challenges and Problems of Alert Triage 

Alert triage is fraught with challenges that compromise its effectiveness in many organizations. 

  • Alert Overload: Modern SOCs generate thousands to millions of alerts daily from tools like SIEMs, EDRs, and network monitoring systems. Analysts can only investigate a fraction of these, leading to potential oversight of critical threats. 
  • False Positives: Many alerts are benign or irrelevant, consuming valuable time and resources.  
  • Lack of Context: Alerts often require analysts to manually gather data from disparate sources, slowing down investigations and increasing the risk of errors. 
  • Resource Constraints: Limited staffing and budget constraints stretch SOC teams thin, making it difficult to handle high alert volumes efficiently; the same goes for MSSPs managing multiple clients. 
  • Evolving Threats: The complexity and variety of modern cyberattacks demand constant adaptation, challenging analysts to stay ahead with limited tools and time. 

These obstacles create inefficiencies, delay responses, and increase organizational risk.

Speed as a Critical Key Performance Indicator

Speed in alert triage, measured by metrics like Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR), is a critical KPI for SOCs and MSSPs. Rapid triage minimizes the window of opportunity for attackers, reducing potential damage from breaches, data loss, or system downtime. For businesses, fast triage aligns with key objectives: 

  • Minimizing Financial Impact 
  • Protecting Customer Trust 
  • Operational Continuity  
  • Regulatory Compliance 

Organizations with efficient triage processes can handle larger volumes of security data without proportionally increasing staff, improving operational efficiency and ROI on security investments.

Analyst Fatigue: The Hidden Threat to Security Effectiveness 

Analyst fatigue occurs when security professionals become mentally and emotionally exhausted from processing endless streams of alerts, many of which prove to be false positives or low-priority events. 

Cognitive overload increases when analysts must process more information than their mental capacity allows, leading to lower accuracy in threat assessment. Emotional exhaustion develops from the constant pressure of potentially missing critical threats, creating a state of chronic stress that affects both performance and well-being. 

The business impact is profound and multifaceted. Fatigued analysts are more likely to miss genuine threats, increasing the exposure to successful attacks. They may also escalate false positives to avoid responsibility. High fatigue levels contribute to analyst turnover, creating recruitment and training costs while leaving organizations vulnerable during transition periods. 

A negative feedback loop emerges where stressed analysts make more mistakes, leading to increased scrutiny and pressure, which further exacerbates fatigue. This cycle can devastate team morale.  

Balancing Speed and Accuracy: The Dual Challenge of Analyst Overload 

The “need for speed” in alert triage is inseparable from the problem of analyst overload and fatigue. SOCs and MSSPs must analyze threats, incidents, and artifacts quickly to contain risks, but this analysis must be accurate and comprehensive to avoid missing critical threats or wasting resources on false positives.  

Solutions that streamline triage without sacrificing accuracy are essential for overcoming this paradox. You do not choose between speed and accuracy but develop systems and processes that enable both.

ANY.RUN’s Threat Intelligence Lookup: A Comprehensive Solution

ANY.RUN’s Threat Intelligence Lookup addresses both the speed and fatigue challenges by providing rapid, comprehensive threat context for indicators like files, URLs, domains, and IP addresses, and enabling teams to make informed decisions quickly.  
 
Besides basic IOCs, this data contains attack and behavioral indicators including: 

  • file modifications, 
  • processes, 
  • network activity, 
  • TTPs mapped to the MITRE ATT&CK Matrix, 
  • malware configurations, Suricata IDS signatures. 

The data is derived from investigations of real-world cyberattacks on over 15,000 companies using ANY.RUN’s services.   

When analysts encounter suspicious artifacts during triage, they can quickly query the service to obtain detailed information about the threat. This eliminates the time-consuming process of manually researching threats across multiple sources. 

TI Lookup Use Cases: Faster and Smarter Alert Triage

Instead of spending valuable time manually investigating suspicious artifacts, analysts can focus on higher-level analysis and decision-making. Here are a couple of examples.  

1. Artifact Quick Check 

A suspicious IP spotted in network connections can be checked against TI Lookup’s vast indicator database in a matter of seconds.   

destinationIP:”195.177.94.58″ 

IP search results with a malicious verdict 

The IP address is exposed as malicious and a part of Quasar RAT inventory. It has been detected in recent malware samples, so it is an indicator of an actual threat.   

Get 50 search requests to test TI Lookup in your SOC
Speed up triage and gain threat context for fast response 



Request trial


2. Process Investigation 

Suppose an analyst notices a legitimate utility like certutil.exe is used for retrieving content from an external URL. All they have to do is copy a snippet of command line contents and paste it into TI Lookup search bar with the CommandLine search parameter:  

commandLine:”certutil.exe -urlcache -split -f http” 

Lookup by a fragment of a command line command 

Switching to the Analyses tab of the search results, the analyst observes a selection of malware samples that performed this command during their execution chain. Now he knows that this behavior is typical for Glupteba trojan acting as a loader. Each sample analysis can be researched in depth and used for collecting IOCs.  

3. Registry Change Understanding 

Could it be okay if an app changes Windows registry key \CurrentVersion\Run responsible for default autoruns at system startup, by adding a command that initiates a script execution chain via mshta.exe using built-in VBScript? Query TI Lookup using RegistryKey and RegistryValue search parameters:  

registryKey:”SOFTWAREMicrosoftWindowsCurrentVersionRun” AND registryValue:”mshtavbscript” 

Malware samples that change Windows registry in a certain way 

As we can notice looking at the found sandbox analyses, such registry modification is often associated with malware evasion and persistence techniques, and is typical for XWorm RAT.  

4. Mutex detection 

When a new malware emerges, the available intelligence on it can be scarce. Nitrogen ransomware became notorious for targeting the valuable and vulnerable financial sector back in mid-2024. For months, a single research report was the source of public data on this strain. It provided analysts with two IOCs and two IOBs, one of the formers was a mutex.  

Before encrypting files, Nitrogen creates a unique mutex (nvxkjcv7yxctvgsdfjhv6esdvsx) to ensure only one instance of the ransomware runs at a time. The mutex can be used for Nitrogen detection, and searching for it via Threat Intelligence Lookup delivers Nitrogen samples detonated in the Interactive Sandbox.  

syncObjectName:”nvxkjcv7yxctvgsdfjhv6esdvsx” 

SyncObject parameters in TI Lookup help to work with mutexes  

Each sample can be explored to enrich the understanding of the threat and gather additional indicators not featured in public research. 

Nitrogen sample analysis: ransom note and one of the main processes 

5. Payload recognition 

File hashes as unique digital fingerprints of a particular file are popular indicators of compromise. TI Lookup supports md5, sha256 and sha1 search parameters, but also allows to use a file name as a query. 

filePath:”Electronic_Receipt_ATT0001″ 

File search results: not always malicious but not to be trusted 

These lookup results show that a certain file name pattern can emerge in both malicious and benign samples: phishing kit campaigns often use filenames typical for popular documentation formats. 

We can observe several samples of phishing attacks using the file with such name pattern in the Interactive Sandbox:  

A phishing sample analysis 

File name search can help understand the general mechanics of phishkit attacks and see a broader picture of emerging threats.

Fast, Fatigue-Free Alert Triage with Threat Intelligence 

It’s up to you not to choose between speed and accuracy, nor to accept analyst fatigue as an unavoidable cost of doing business. Instead, embrace solutions that enable both rapid response and meticulous analysis. 

ANY.RUN’s Threat Intelligence Lookup fuels this strategy by providing immediate, context-rich insights into suspicious artifacts and transforming reactive, manual investigations into proactive, informed decision-making. This translates into tangible business values: 

  • Enhanced Operational Efficiency: Teams can process a higher volume of alerts with existing staff, optimizing the return on investment in security tools and personnel. 
  • Reduced Organizational Risk: Faster and more accurate identification of genuine threats minimizes the window of opportunity for attackers, thereby reducing the likelihood of successful breaches, data loss, and system downtime.   
  • Improved Analyst Productivity and Morale: Automating the initial stages of threat intelligence gathering frees analysts from repetitive, cognitively taxing tasks.  
  • Preserved Customer Trust and Brand Reputation: Swift and effective handling of security incidents demonstrates a commitment to protecting sensitive data and maintaining operational integrity. 

Investing in solutions like ANY.RUN’s Threat Intelligence Lookup is not just about technology; it’s about building a sustainable and resilient security posture that protects an organization’s financial health, its most valuable assets, and its people. 

About ANY.RUN  

Over 500,000 cybersecurity professionals and 15,000+ companies in finance, manufacturing, healthcare, and other sectors rely on ANY.RUN. Our services streamline malware and phishing investigations for organizations worldwide.  

  • Speed up triage and response: Detonate suspicious files using ANY.RUN’s Interactive Sandbox to observe malicious behavior in real time and collect insights for faster and more confident security decisions.  
  • Improve threat detection: ANY.RUN’s Threat Intelligence Lookup and TI Feeds provide actionable insights into cyber attacks, improving detection and deepening understanding of evolving threats. 

Start 14-day trial of ANY.RUN’s solutions in your SOC today 

The post How to Maintain Fast and Fatigue-Free Alert Triage with Threat Intelligence  appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

Microsoft Patch Tuesday for July 2025 — Snort rules and prominent vulnerabilities

Microsoft Patch Tuesday for July 2025 — Snort rules and prominent vulnerabilities

Microsoft has released its monthly security update for July 2025, which includes 132 vulnerabilities affecting a range of products, including 14 that Microsoft marked as “critical.”  

In this month’s release, Microsoft observed none of the included vulnerabilities being actively exploited in the wild. Out of 14 “critical” entries, 11 are remote code execution (RCE) vulnerabilities in Microsoft Windows services and applications including KDC Proxy service, Microsoft Office and SharePoint server. 

CVE-2025-49735 is an RCE vulnerability in Windows KDC Proxy Service (KPSSVC) given a CVSS 3.1 score of 8.1. To successfully exploit this vulnerability, an unauthenticated attacker could use a specially-crafted application to leverage a cryptographic protocol vulnerability in KPSSVC to perform RCE against the target. Microsoft has noted that this vulnerability only affects Windows servers that are configured as a Kerberos key Distribution Center (KDC) Proxy Protocol server, and domain controllers are not affected. Microsoft assessed that the attack complexity is “high,” and exploitation is “more likely.”  

CVE-2025-49704 is an RCE vulnerability in Microsoft SharePoint server given a CVSS 3.1 score of 7.7. Microsoft noted that this vulnerability in Microsoft Office SharePoint is due to improper control of generation of code (“code injection”) which would allow an authenticated attacker to execute code over a network. To exploit this vulnerability, an authenticated attacker in a network-based attack, with a minimum of Site Member permission, could execute arbitrary code remotely on the SharePoint server. Microsoft assessed that the attack complexity is “low,” and exploitation is “more likely.”  

CVE-2025-49695, CVE-2025-49696, CVE-2025-49697, CVE-2025-49698, CVE-2025-49702 and CVE-2025-49703 are RCE vulnerabilities in Microsoft Office and Microsoft Word. The vulnerabilities CVE-2025-49695 and CVE-2025-49698 are “use after free” (UAF) vulnerabilities that occur when Microsoft Office tries to access memory that has already been freed. CVE-2025-49696 is an out-of-bounds read in Microsoft Office. Microsoft assessed that for CVE-2025-49695 and CVE-2025-49696, the attack complexity is “low,” and exploitation is “more likely.” For CVE-2025-49697, CVE-2025-49698, CVE-2025-49702 and CVE-2025-49703, the attack complexity is “low,” and exploitation is “less likely.”   

CVE-2025-48822 is an RCE vulnerability in Windows Hyper-V Discrete Device Assignment (DDA) given a CVSS 3.1 score of 8.6. This vulnerability is an out-of-bounds read in Hyper-V that could allow an unauthorized attacker to execute code locally. Microsoft assessed that the attack complexity is “low,” and exploitation is “less likely.” 

CVE-2025-47981is an RCE vulnerability in SPNEGO Extended Negotiation (NEGOEX) Security Mechanism given a CVSS 3.1 score of 9.8. This vulnerability is a heap-based buffer overflow that could allow an unauthorized attacker to execute code over a network. According to Microsoft, this vulnerability affects Windows client machines running Windows 10, version 1607 and above, due to the following GPO being enabled by default on these operating systems: “Network security: Allow PKU2U authentication requests to this computer to use online identities.” Microsoft has assessed that the attack complexity is “low,” and exploitation is “more likely.”  

CVE-2025-49717 is an RCE vulnerability in Microsoft SQL Server, given a CVSS 3.1 score of 8.5. This vulnerability is a heap-based buffer overflow that could allow an unauthorized attacker to execute code over a network. However, Microsoft has assessed “exploitation unlikely”. 

The last critical vulnerability listed (CVE-2025-47980) is an information disclosure in Windows Imaging Component that, if exploited, could allow an attacker to read small portions of heap memory. Microsoft has assessed that the attack complexity is “low,” and exploitation is “less likely.”   

Talos would also like to highlight the following “important” vulnerabilities as Microsoft has determined that their exploitation is “more likely:”  

  • CVE-2025-49701: Microsoft SharePoint Remote Code Execution Vulnerability 
  • CVE-2025-49724: Windows Connected Devices Platform Service Remote Code Execution Vulnerability 

A complete list of all the other vulnerabilities Microsoft disclosed this month is available on its update page.   

In response to these vulnerability disclosures, Talos is releasing a new Snort ruleset that detects attempts to exploit some of them. Please note that additional rules may be released at a future date, and current rules are subject to change pending additional information. Cisco Security Firewall customers should use the latest update to their ruleset by updating their SRU. Open-source Snort Subscriber Ruleset customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.   

Snort 2 rules included in this release that protect against the exploitation of many of these vulnerabilities are: 64435, 64436, 65092, 65096 – 65107, 65110 – 65113.  

The following Snort 3 rules are also available: 301114, 301268 – 301272. 

Cisco Talos Blog – ​Read More

Technical Analysis of Ducex: Packer of Triada Android Malware 

Many have probably heard of the modular malware for mobile devices called Triada. Even nine years after its first mention in 2016, it remains one of the most advanced Android trojans out there. Recently, our team at ANY.RUN came across an interesting sample of this malicious software. The sample in question was embedded in a fake Telegram app.  

Since the capabilities of this threat have been extensively studied and described by other researchers, we focused on the packer used by the malware that we named Ducex.  

Here’s a detailed breakdown of our analysis and key findings. 

Key Takeaways 

  • Triada’s Android Packer: Ducex is an advanced Chinese Android packer found in Triada samples, whose primary goal is to complicate analysis and confuse the detection of its payload. 
  • Encrypted Functions: The packer employs serious obfuscation through function encryption  using a modified RC4 algorithm with added shuffling. 
  • XORed Strings: Beyond functions, all strings used by Ducex are also encrypted using a simple sequential XOR algorithm with a changing 16-byte key. 
  • Debugging Challenges: Ducex creates major roadblocks for debugging. It performs APK signature verification, failing if the app is re-signed. It also employs self-debugging using fork and ptrace to block external tracing. 
  • Analysis Tool Detection: The packer actively detects the presence of popular analysis tools such as Frida, Xposed, and Substrate. If any of these tools are found in memory, the process terminates its execution. 
  • Payload Storage & Encryption: The Triada payload is uniquely stored within Ducex’s own classes.dex file in a large, additional section after the main application code, avoiding detection as separate files. 

Initial Analysis  

Our investigation began with the analysis of a Triada sample inside ANY.RUN’s Interactive Sandbox.  

Analysis of the fake Telegram app in ANY.RUN’s Sandbox 

The service quickly identified the malware family, and we were able to confirm this by recognizing the characteristic domains it communicated with.  

The domains Triada communicates with detected during sandbox analysis 

From there, we moved on to inspect the packer. 

Detect malware in a live, interactive environment
Analyze suspicious files and URLs in ANY.RUN’s Sandbox 



Sign up with business email


Why We Decided to Analyze Ducex 

Not malicious itself, Ducex is still quite interesting. Its developers tried their best to complicate analysis as much as possible and confuse detection of the payload it carries using various techniques that will be discussed below. 

We have not obtained the source code of this tool, so we relied exclusively on its reverse engineering. For the same reason, we gave it a name ourselves. Studying the classes in the code, we noticed that its authors used the word “Duce” a lot.  

“Duce” names of code entities 

The library they utilize is called “libducex”. Based on this, we called the packer “Ducex”. 

Ducex: The Architecture 

Before proceeding to detailed analysis of the tool, let’s look at the general operation scheme of Ducex: 

General Ducex scheme 

We have outlined all the stages of the tool’s execution; we will demonstrate and discuss them below in their interplay.  

Analyzing App’s Java Code 

When opening the malicious APK in an Android decompiler (e.g., JADX), the AndroidManifest shows the following data under the application tag: 

Application tag contents in AndroidManifest 

The com.m.a.DuceApplication class immediately catches our attention. It is specified in android:name, which means an instance of this class is created immediately after the application is launched. Going to its code, we see two methods: attachBaseContext() and onCreate(). 
 

Methods within com.m.a.DuceApplication class 

We are interested in these methods specifically, as they will be called when creating an instance of the class, in the specified order. Inside them, we see calls to methods of the CoreUtils class:  

Methods of CoreUtils class 

That’s where it gets interesting. As can be seen in the screenshot above, most methods of this class are native, and they are implemented in the “libducex.so” library. 

Additionally, if we decrypt the presented strings, we get, respectively, “org.telegram.messenger.ApplicationLoaderImpl” and “androidx.core.app.CoreComponentFactory“.  

As can be seen in DuceApplication.onCreate() and DuceApplication.attachBaseContext(), it is org.telegram.messenger.ApplicationLoaderImpl that will be called to launch the fake Telegram using the CoreUtils.runOn() and CoreUtils.runOnC() methods, and androidx.core.app.CoreComponentFactory will be used in DuceAppComponentFactory, which overrides the creation of various application components (Application, Activity, etc.) to inject custom logic during their initialization using the same methods from CoreUtils

A CoreUtils method is used to override the creation of Application 

Since the most interesting things happen in the libducex.so library, let’s proceed to its analysis. 

Libducex.so Library Analysis 

Encrypted Functions 

It turned out, you can’t just start analyzing the library. For example, the program entry point looks like this: 

Entry point with obfuscation 

Most instructions are displayed incorrectly. It looks like very serious obfuscation or a completely non-working function. At this point we estimated what would be called even before the program entry point and moved to JNI_OnLoad.  

JNI_OnLoad is called after the library is loaded into memory and the control is passed to the JVM.  

JNI_OnLoad with obfuscation 

As we can see in the screenshot, the situation is exactly the same. The code looks non-working, which makes you think that it might not even be obfuscated but encrypted. So, if even JNI_OnLoad is encrypted, then we need to turn to functions that execute earlier than both it and Entry Point, which means before control is transferred to the JVM.  

This function could be .init_proc, which executes immediately after loading the library into memory. And indeed, it was there that we found correct code capable of being decompiled: 

.init_proc function 

Getting a little ahead of ourselves, we’ll say that the functions were indeed encrypted, and their decryption occurs in .init_proc, in the nested create_key__decrypt_funcs function. Now back to the analysis.  

The first thing that interests us is the configuration that is passed as the second argument to the function called in the figure above: 

Configuration used to decrypt functions 

It consists of the following fields, presented in the same order as in the screenshot above: 

  1. Magic value ‘mxe’;  
  1. Decryption start address (in our case, Entry Point);  
  1. Number of bytes for decryption;  
  1. Function that will be called after completion of decryption;  
  1. 16-byte buffer – key that will be used during decryption. 

The decryption itself, occurring in create_key__decrypt_funcs, is carried out according to the configuration data. At first it seemed to us that the code had been encrypted using classic RC4, but this is not quite so. The developers slightly modified the algorithm by adding additional shuffling, so standard RC4 implementations didn’t work; we had to implement it ourselves.  

Our decryption script takes a key as input, as well as the part of the file containing encrypted functions. The necessary parameters (the key, the start address of the encrypted part, and its size) are taken from the configuration described above. 

def rc4_init(key):  

    s = list(range(256))  

    s += [0, 0]  

    j = 0 

    for i in range(256): 
        key_byte = key[i & 0xf] 
        j = (j + s[i] + key_byte) &0xff 
        s[i], s[j] = s[j], s[i] 
 
    return s 
  

def rc4_process(s, encoded_data):  

    i = s[256]  

    j = s[257]  

    output = bytearray(encoded_data) 

    for n in range(len(encoded_data)): 
        i = (i + 1) & 0xff 
        a = s[i] 
        j = (j + a) & 0xff 
        b = s[j] 
        s[i], s[j] = b, a 
        output[n] ^= s[(a + b) & 0xff] 
 
        for _ in range(2): 
            i = (i + 1) & 0xff 
            a = s[i] 
            j = (j + a) & 0xff 
            b = s[j] 
            s[i], s[j] = b, a 
 
    return bytearray(output) 
  

def decrypt(key, func_buf): 

    s = rc4_init(key) 
	decoded_funcs = rc4_process(s, func_buf) 
	return decoded_funcs 

Applying the script to our library, we got the correct code. Entry Point, for example, now looks as follows: 

Decrypted Entry Point code 

Now all instructions are correct, and there are no problems with code decompilation. 

Encrypted Strings 

The encrypted functions, as it turned out, are not the only thing that developers decided to hide from the researcher’s eyes. All strings used by the packer are also encrypted. The algorithm is quite simple: it’s sequential XOR with a given key consisting of 16 bytes. The algorithm is unchanged throughout the entire sample, only the key changes. Example script with a given key: 

def xor_data(data, key):  

result = bytearray()  

for i in range(len(data)):  

result.append(data[i] ^ key[i % len(key)]) return result 

key = b"GeGrE0tX`:0^6qLS"  

encoded_buf = bytearray([0x1d, 0x0c, 0x37, 0x52, 0x2c, 0x5e, 0x12, 0x34, 0x01, 0x4e, 0x55, 0x5e])  

decrypted = xor_data(encoded_buf, key) 

print(decrypted) 

In the output after running this simple script, you can see: bytearray(b’Zip inflatex00′).

What’s interesting here is that all the functions used for decryption are called immediately upon initialization, not when required in the code. And the reference to the array with pointers to these functions is located, respectively, in .init_array, there are a huge number of them there: 

.init_array section with functions for decryption 

Control Flow Obfuscation 

In case the researcher breaks through the encryption, the developers have further obfuscated the code. For example, this is how the structure of the function in which native method names are decrypted looks: 
 

Structure of the function responsible for native methods names decryption 

And this is not even half of the function’s code, which could have been about 20 lines long. And all because of such constructions of cycles and conditions, which do not serve any purpose except to complicate the code: 

Cycles with the sole purpose to complicate the code 

At this point you might think that it would be enough to run the sample under a debugger and go through all these conditional jumps, see the decrypted functions and strings, but if only it were that simple. 

APK Signature Verification 

The first thing we attempted was to parse the APK using Apktool utility and insert the line android:debuggable=”true” under the application tag in AndroidManifest, then rebuild and sign the APK again.  

Upon doing this in the smartphone settings, it’s possible to set up the application to wait for a debugger to connect. It also makes it possible to utilize the following command for adb: adb shell am set-debug-app -w –persistent <package>. On the next launch, a window “Waiting For Debugger” should appear and disappear after the debugger is connected. 
 
But in our case this didn’t work. After rebuilding the application, it began to “crash” immediately after loading libducex. The app checks the APK signature and terminates if it doesn’t match the expected one. Below you can see decrypted strings used when obtaining APK signatures: 

Decrypted strings used when obtaining APK signatures 

Self-Debugging 

Thus, debugging the application by changing the APK didn’t work. Fortunately, there is a way to debug Android applications without setting the debuggable flag and, accordingly, without the need to rebuild and re-sign the file. 

This method is more laborious, as it involves building your own Android image and then using it in the emulator. Its description can be found here.   

Thus, we built the image, used the debug command given above, and tried to run the application under the debugger. However, the packer held another surprise: after launching the application, the “Waiting For Debugger” window appears only for a fraction of a second, after which normal launch occurs, without waiting for the debugger. This may indicate that the application “debugs itself” so that no one else can debug it. 

We found the corresponding functions: a process sets handlers using the rt_sigaction system call, for example, for the SIGCHLD event. This handler checks what happened to the child process, after which it can either terminate or continue its execution. 
 

rt_sigaction call 
  • In x8 – rt_sigaction call code; 
  • In x0 – SIGCHLD code; 
  • In x1 – handler structure address; 
  • In x2 – flags, in our case 0. 

And then another interesting thing occurs: the parent process uses the fork system call to create a child process, which, in turn, will work to monitor the state of the parent process. It uses the ptrace system call with the PTRACE_ATTACH parameter to attach to the parent process, after which it waits for events from it and, depending on what happened, resumes the process or terminates it and its own execution. 

ptrace call  
  • In x8 – ptrace call code; 
  • In x0 – PTRACE_ATTACH code; 
  • In x1 – value from global variable – parent process pid; 
  • In x2 – unused addr argument; 
  • In x3 – unused data argument. 

So, parent and child processes monitor each other’s state and react in case of certain events. Additionally, considering that a process can have only one tracer, connecting an external debugger becomes impossible in this case. 

Detection of Frida, Xposed, and Others 

At this point, two options remain: either static code analysis, at most using tools capable of emulating instructions (e.g., emulators on the Unicorn engine), or installing Frida hooks to change application behavior without actual APK modification and still be able to dynamically analyze the unpacking process. 

But Frida wouldn’t work either, because the packer has built-in checks for the presence of frida_server, as well as Xposed, Substrate, etc. 

Decrypted strings in memory 

If any of these strings are found in memory, the process terminates execution. This can be patched, but it’ll take time to find the implementations in the code. And we shouldn’t forget about the signature verification used in the library. So we continue with static code analysis.  

Where Does the Packer Get Code to Run?

Ducex doesn’t create a separate encrypted file with a payload, instead it stores this code inside its own classes.dex, in a special additional section that goes after the main application code, thus avoiding detection of additional files: 

The large section after the map section contains the payload 

The screenshot shows that after the map section, where everything should have ended, there is an additional section, and a very large one in size. That’s where the payload is located. 

The payload, i.e., Triada, is stored as additional dex modules. It’s noteworthy that despite all its complexity, this tool doesn’t fully compress and encrypt the dex files that it later runs. Instead only 2048 == 0x800 bytes from the beginning of each module are encrypted, while the rest remains untouched. Thus, at least the dex module header will always be completely encrypted, as it has a fixed size of 0x70 bytes, further sections do not have a fixed size. There are 5 modules in the file.  

There is also a configuration shared by all modules:  

Another configuration common to all modules 

Here there is a certain magic value starting with “mx”, but now with additional bytes x01x02. The most useful thing here is the 16-byte key. It is highlighted in red in the screenshot above. 
 
Additionally, there are configurations for each of the modules storing information for decrypting them: 

Configuration with info for decrypting a module 

The first 4 bytes of this structure are very important, here we have the value 0x100==256, which means that the first 0x800 bytes of this dex are encrypted. If there was, for example, the number 258, this would mean that part of the dex is compressed using zlib. Then come the highlighted fields with module sizes and another 16-bit decryption key, immediately after which the encrypted module block begins. 

File structure can be represented like this:  

Classes.dex file structure 

This scheme doesn’t depict all fields in the configurations, but those that were required for our analysis. 

How Is Decryption Performed?  

Decryption here is quite complex. Two algorithms are used for it: a modified RC4 and SM4. 
 
The first one is well known, but not the second. SM4 is a Chinese block encryption standard. It is not as popular as, for example, AES, and we managed to identify it by the substitution table: 

The substitution table used by SM4 

It’s important to note that even the table was encrypted, as well as all the strings used by the tool.  

As we know, the unpacker’s dex file contains one main configuration and configurations for each of the 5 modules. All of them require a key. Tracking the execution flow, we can draw the following conclusions: 

  1. native_init method: first, the module is decrypted using the key specified in the module’s configuration. This is a preparatory action that can change depending on the first four bytes of the configuration. In our case it’s 256, which means decryption is needed, as indicated above; 
  1. native_dl method: here, the same decryption function is called, only now a different key is used, the one specified in the configuration shared by all modules. 

What Happens Next?  

Let’s turn back to our Java code and remember what happens in the attachBaseContext method: 

attachBaseContext method 

The native init() and dl() methods are called, and there the main decryptions occur. Immediately after this the CoreUtils.runOn() method is called with the method name org.telegram.messenger.ApplicationLoaderImpl as an argument by the decrypted string CoreUtils.ran. Here no decryptions are observed, only the method launch. Now Triada begins its work. 

Summary 

Ducex is indeed a very complex and interesting Chinese tool, worthy of the malware that it carries as payload. Its developers tried to foresee as much as possible to confuse Triada detection and complicate analyst research. 

IOCs 

Title Description
Name 131eaf37b939f2be9f3e250bc2ae8ba44546801b5ca6268f3a2514e6a9cb8b5c.apk
MD5 25faee9bbf214d975415ae4bd2bcd7b9
SHA1 06f8ca016b2bf006702501263818b7606851f106
SHA256 131eaf37b939f2be9f3e250bc2ae8ba44546801b5ca6268f3a2514e6a9cb8b5c

The post Technical Analysis of Ducex: Packer of Triada Android Malware  appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More