In Q4 2025, Microsoft once again ranked as the most impersonated brand in phishing attacks, accounting for 22% of all brand phishing attempts, according to data from Check Point Research. This continues a multi-quarter trend in which attackers increasingly abuse trusted enterprise and consumer brands to harvest credentials and gain initial access. Google followed in second place with 13%, while Amazon climbed into third position at 9%, fueled by Black Friday and holiday sales, overtaking Apple. After a prolonged absence, Facebook (Meta) re-entered the top 10, landing in fifth place, highlighting renewed interest among attackers in social media account takeover. […]

The post Microsoft Remains the Most Imitated Brand in Phishing Attacks in Q4 2025 appeared first on Check Point Blog.

Executive Summary Check Point Research identified active, large-scale exploitation of CVE-2025-37164, a critical remote code execution vulnerability affecting HPE OneView. The exploitation campaign is attributed to the RondoDox botnet and escalated rapidly to tens of thousands of automated attack attempts. Check Point blocked tens of thousands of exploitation attempts through its security infrastructure, highlighting both the severity of the risk and the importance of layered defenses. Check Point reported the active exploitation to CISA on January 7, 2026, and the vulnerability was added to the Known Exploited Vulnerabilities KEV catalog the same day. Organizations running HPE OneView should patch immediately […]

The post Patch Now: Active Exploitation Underway for Critical HPE OneView Vulnerability appeared first on Check Point Blog.

In December 2025, organizations experienced an average of 2,027 cyber attacks per organization per week. This represents a 1% month-over-month increase and a 9% year-over-year increase. While overall growth remained moderate, Latin America recorded the sharpest regional increase, with organizations experiencing an average of 3,065 attacks per week, a 26% increase year over year. The data points to sharper regional and sector-level spikes in activity, driven primarily by ransomware operations and expanding exposure linked to enterprise adoption of generative AI (GenAI). Latin America experienced the sharpest rise in cyber attacks globally, with organizations in the region facing an average of […]

The post Latin America Sees Sharpest Rise in Cyber Attacks in December 2025 as Ransomware Activity Accelerates appeared first on Check Point Blog.

Key Points: VoidLink is a cloud-native Linux malware framework built to maintain long-term, stealthy access to cloud infrastructure rather than targeting individual endpoints. It reflects a shift in attacker focus away from Windows systems toward the Linux environments that power cloud services and critical operations. Its modular, plug-in-driven design allows threat actors to customize capabilities over time, expanding attacks quietly as objectives evolve. Adaptive stealth enables it to operate differently depending on defenses, prioritizing evasion in monitored environments and speed where visibility is limited. Check Point Research has identified a new and highly advanced malware framework, VoidLink, designed specifically to […]

The post VoidLink: The Cloud-Native Malware Framework Weaponizing Linux Infrastructure appeared first on Check Point Blog.

We identified remote code execution vulnerabilities in open-source AI/ML libraries published by Apple, Salesforce and NVIDIA.

The post Remote Code Execution With Modern AI/ML Formats and Libraries appeared first on Unit 42.

Holiday shopping season is in full swing, and Black Friday 2025 continued to demonstrate that consumer demand and attacker activity shows no signs of slowing. According to Adobe Analytics, U.S. consumers spent $11.8 billion online on Black Friday, setting a new record and highlighting sustained strength in online shopping. Yet behind this surge in legitimate traffic, retailers also faced a sharp rise in automated abuse, account takeover attempts, and reconnaissance across their digital storefronts.

This post breaks down what we saw across our network during the Black Friday period, including traffic trends, attack behavior, targeted geographies, and insights retailers can apply to strengthen their defenses ahead of the holiday home stretch.

What We Saw

Massive Traffic Surges Extending Past Black Friday

Retail traffic surged 37% above November averages, peaking on Black Friday but continuing into the weekend of November 29–30. Traditionally, traffic dips slightly on Saturday before building again on Cyber Monday, but this year showed a clear shift: shoppers kept buying throughout the weekend. This aligns with broader retail trends showing consumers taking advantage of longer promotional windows rather than concentrating purchases on a single day.

For retailers, this means the “peak” period is expanding- and with it, the window of exposure to cyber threats.

Bot Attacks Rose 50%, Focused on High-Value Workflows

Alongside legitimate traffic, bot attacks on retail sites spiked 50% over the November average. The timing closely tracked promotional activity, suggesting attackers were attempting to exploit increased consumer volume to blend in and avoid detection.

Broadly, these bots targeted:

• Authentication and account flows (e.g., /login)
• Inventory and product data endpoints (e.g., /datastore, /event/)
• Transaction and application paths (e.g., credit-card application flows, lottery/promotion services, and user log endpoints)

This behavior reflects typical seasonal abuse campaigns: credential stuffing to hijack accounts, automated scraping to gain pricing or inventory intelligence, and attempts to manipulate promotions or loyalty flows.

Attacks Concentrated on the US, UK, and Australia

Malicious traffic during Black Friday was heavily concentrated in three markets: the US (46%), Australia (12%), and the UK (11%). These regions represent some of the world’s most active e-commerce ecosystems, and attackers mirrored legitimate consumer behavior by focusing on markets with the highest transaction volumes and promotional activity.

The US, in particular, drew nearly half of all observed attacks, consistent with its dominant share of global Black Friday spending. Australia and the UK followed, reflecting strong regional participation in holiday sales events and an attacker strategy aimed at exploiting high-demand markets where automated activity can more easily blend in with legitimate traffic.

For retailers operating in these geographies, the data underscores the importance of region-aware threat monitoring and the need to maintain heightened vigilance throughout the extended holiday weekend.

Attack Patterns Reveal Automation, ATO Prep, and Abuse at Scale

Based on attacker activity observed over the holiday shopping weekend, several clear patterns emerged, showing a mix of high-volume automation, credential-based attacks, and spam and proxy abuse. Overall, the attack data suggests that adversaries were focused on the following behaviors:

1. Heavy Use of Known Bad Bots and Automated Browsers

A significant portion of malicious traffic came from known automated frameworks, including headless browsers and scripted tools designed to mimic real users. This type of activity typically supports:

• Large-scale login attempts
• Price, inventory, or content scraping
• Testing of checkout, promotion, and product pages for weaknesses

Attackers were industrializing their activity using automation that can rapidly adapt during peak events.

2. Preparing and Executing Account Takeover (ATO)

We observed high levels of activity associated with login reconnaissance and credential-testing behavior, indicating attempts to stage or execute ATO. Attackers were:

• Testing large volumes of username/password combinations
• Probing login endpoints to identify which attempts were blocked, challenged, or allowed
• Taking advantage of elevated holiday traffic to blend their activity into normal user patterns

This aligns with typical seasonal fraud behavior, where attackers target stored payment methods, loyalty balances, and customer identities.

3. Evading Detection Through Proxies and Client Impersonation

A large volume of traffic originated from anonymous proxies, VPNs, and other anonymization services, combined with indicators of client spoofing meant to disguise automation. Attackers were:

• Rapidly rotating IP addresses
• Using advanced bots, attempting to masquerade as legitimate browsers
• Using more simple bots, which use fingerprints or user agents that fell outside normal human patterns

In response, much of this traffic triggered JavaScript challenges or CAPTCHA enforcement, forcing suspicious clients to prove they were human.

4. Abusing Forms and Content Channels for Spam

We also observed activity consistent with comment spam, referrer manipulation, and other low-effort abuse aimed at exploiting retail sites as platforms for unwanted advertising or redirection. This typically includes:

• Submitting spam content through comment or feedback forms
• Inserting malicious or low-quality URLs via referrer fields
• Attempting to poison analytics or direct traffic elsewhere

While not as immediately damaging as ATO, these campaigns can harm site performance, customer trust, and brand analytics.

What This Means for Retailers

Black Friday 2025 reinforced several themes:

1. The peak holiday season is widening.
   High traffic persisted later into the weekend than in prior years. Retailers should consider extending peak staffing and monitoring coverage accordingly.
2. Attackers are increasingly using shopper traffic as camouflage.
   Surges in human activity closely mirror surges in automated abuse. Retailers need strong bot detection, fingerprinting, and behavioral analysis—not just rate limiting.
3. API security is now as important as web application security.
   Many of the top targeted URLs were APIs tied to data, personalization, or analytics. These endpoints often sit behind the UI and may not receive the same scrutiny as consumer-facing pages.
4. Geographic targeting is aligned with opportunity.
   The US, Australia, and UK remain prime markets for both legitimate and malicious traffic. Retailers serving these regions must expect elevated attack pressure during every promotional period.

Conclusion

This year’s Black Friday illustrated both consumer resilience and the evolving sophistication of attackers. Retailers saw new sales records, and attackers took advantage of the same moment to blend in, scale operations, and probe for weaknesses.

As the holiday season continues, retailers should ensure that defenses are calibrated for:

• Sustained high traffic (not just one peak day)
• Increased bot sophistication
• ATO protection
• Region-specific targeting aligned with revenue hotspots

By understanding the patterns we saw during Black Friday, retailers can prepare for the continued wave of holiday traffic and ensure a safer, smoother experience for their customers through the end of the year.

The post Black Friday 2025 in Review: What Retailers Need to Know About This Year’s Holiday Shopping Season appeared first on Blog.

After our research on Cursor, in the context of developer-ecosystem security, we turn our attention to the Jupyter ecosystem. We expose security risks we identified in the notebook’s export functionality, in the default Windows environment, to help organizations better protect their assets and networks.

Executive Summary

We identified a new way external Jupyter notebooks could be exploited by threat actors to lure unsuspecting users and compromise their workstation.

Companies are recommended to use a centralized Jupyter server, stay up to date and strictly restrict external files susceptible to processing with Jupyter software.

Introduction

Jupyter notebook is quite an institution in the development of AI projects. Back in 2015, around 200,000 notebooks were publicly available on GitHub—by early 2021 that number had surged to nearly 10 million. Used by more than 80 % of data scientists and AI engineers worldwide, Jupyter is deeply embedded in every stage of AI workflows, from exploratory analysis and visualization to model prototyping and collaboration.

When investigating this ecosystem, our approach was to try to imagine where a threat actor could find his way through, and leverage functionalities to exploit victims’ environments. The first direction came surprisingly easily: the configuration files.

Configuration files are often considered innocuous. However, they may include obscure parameters that most users aren’t aware of. Ignoring them would be a critical mistake.

Config files have led to vulnerabilities in many other instances. For example, in VSCode’s IDE, the .vscode/settings.json config file was also a key component in multiple high severity vulnerabilities discovered (CVE‑2021‑34529 , CVE‑2025‑53773 or CVE-2025-54130).

One specificity of the Jupyter ecosystem that makes this attack vector even more interesting is the fact that configuration files are also perfectly valid Python executables- making them easier to exploit.

Jupyter Configuration Files

The most common configuration file is jupyter_notebook_config.py, typically found in the user-specific configuration directory (~/.jupyter/). It’s responsible for defining core Notebook server settings such as network bindings, authentication options, file system paths, and various security-related parameters. However, other config files may also be used depending on the component, such as jupyter_nbconvert_config.py for export settings, or jupyter_server_config.py for Jupyter Server.

Configuration files can actually exist in any directory, allowing for layered overrides. Available options cover a wide range of functionality, from UI behavior and authentication to kernel management, export formats, logging, and more. This approach gives users fine-grained control over the entire Jupyter ecosystem.

For example:

c = get_config()
c.NotebookApp.port = 8888
c.FileContentsManager.save_script = True

However, acknowledging a high severity impact, Jupyter decided in October 2022 to remove CWD from the config paths, reducing the risk presented significantly.

This was the starting point of our research. We started searching for a similar or stronger way to exploit the same idea: having a file whose name is not constrained adjacent to a jupyter notebook, assuming an unsuspecting user would trigger an innocuous operation on a perfectly legit Jupyter notebook on the official Jupyter software and inadvertently allow full system compromise.

And this is exactly what we found by investigating the official export tool of Jupyter, nbconvert.

The Vulnerability

The vulnerability we discovered allows arbitrary code execution on Windows machines when exporting a notebook to PDF. By placing a properly named, malicious script in the notebook folder location, an attacker could hijack the conversion process and execute code with the privileges of the user.

When a Jupyter notebook containing SVG output is exported via nbconvert, the svg2pdf.py preprocessor is triggered to convert SVG images via the Inkscape tool. During this process, the path to Inkscape executable is resolved using Python’s shutil.which() via the following expression:

inkscape_path = which("inkscape")

without including inkscape anywhere as a mandatory nbconvert dependency. This opened the door to unintended code execution as the following figure shows:

Fig. 1: High level flow of exploitation of the security issue

shutil.which behavior is controlled internally by the Windows API function NeedCurrentDirectoryForExePathW, which returns TRUE (include CWD) when the NoDefaultCurrentDirectoryInExePath environment variable is not set, which is the default configuration on standard Windows installations.

In Python versions earlier than 3.12, `shutil.which()` ignores the `NoDefaultCurrentDirectoryInExePath` environment variable entirely, making it impossible to prevent this unsafe search behavior through configuration.

Python 3.12 and later versions properly respect this environment variable when set, but the variable remains unset by default on Windows systems, leaving many vulnerable.

Since nbconvert officially supports Python versions starting from 3.9, it includes versions that are affected by this issue both ways.

CVE-2025-53000

This unsafe lookup behavior aligns with CWE-427: Uncontrolled Search Path Element. Therefore, we recommended disabling the searching of inkscape software from CWD and relying on fixed safe search places.

Upon receiving our report, the Jupyter team reproduced the issue, acknowledged the associated risk, and requested a CVE (see below). A discussion was then initiated regarding how to fix the issue. However, the Jupyter team eventually stopped responding to our messages and has not addressed the issue to date.

CVE-2025-53000 has been assigned to this vulnerability. At the time of publication, the Github advisory has not yet been released by the maintainers.

Because export functionality is commonly used and generally trusted, it presents an attractive target for attackers, and especially in environments where notebooks are frequently shared—such as academic research groups, data science teams, or educational institutions—the potential for exploitation increases substantially.

Eventually, following our 90-day policy, we decided to publish this advisory to help protect the community.

Demonstration Video

The following demonstration video was recorded on a Windows 10 Enterprise x64 machine with default settings, using miniconda3 and Python 3.13.9, using the latest available Jupyter software versions, including:

Jupyter Core 5.9.1, nbconvert 7.16.6, and Notebook 7.5.0

Post Exploitation

Once successfully triggered, this vulnerability gives the attacker arbitrary code-execution in the context of the user. This immediately impacts confidentiality, integrity, and availability, as the attacker can access, modify, or disrupt the user’s data and workflows. On typical Windows data-science workstations, victim accounts almost always have:

• Direct access to sensitive notebooks and datasets.
• Cached cloud credentials (AWS CLI, Azure CLI, gcloud, Databricks etc.)
• Locally installed package managers (conda, pip, winget) and DevOps pipelines that will happily run additional code.

This potentially amplifies the radius of compromise, allowing its effects to spread beyond the initial workstation.

Recommendations

Companies are recommended to rely on a centralized Jupyter server, ensure that all Jupyter-related software remains up to date, and enforce strict restrictions on external files that may be processed through Jupyter tools.

It is also recommended to enable the NoDefaultCurrentDirectoryInExePath environment variable to reduce the risk of unintentionally executing files from untrusted locations.

Conclusion

This vulnerability shows how the invisible glue of our workflows can become points of failure when not properly scrutinized.

We expect more vulnerabilities to surface in this fast-growing AI ecosystem as workflows become more automated, composable, and cloud-integrated, and we hope this report encourages teams to take a closer look at the quiet dependencies holding their environments together.

Timeline

• June 8: Disclosure report submitted.
• June 12: Issue reproduced.
• June 25: CVE reservation by Jupyter team.

The post Code Execution in Jupyter Notebook Exports appeared first on Blog.

Introduction and Vulnerability Overview 

Earlier this month, Imperva published an initial advisory outlining how our customers were protected against the newly disclosed React2Shell vulnerability impacting React Server Components (RSC). That post focused on the essentials: a critical flaw arising from unsafe server-side deserialization of client-controlled RSC payloads, its potential to enable unauthenticated remote code execution, and what we do to protect against it.  

In this follow-up, we expand on that foundation by examining what makes this vulnerability so dangerous. We explore the real-world footprint of this vulnerability, look at how it has appeared in the wild across different countries and sites, examine recorded exploit attempts that use this vulnerability as an entry point in opportunistic malware campaigns, and assess how the flood of AI-generated PoCs is complicating real-world defenses. 

General Statistics 

Before diving into the technical details, let’s begin with a macro-view of its real-world impact across the globe. 

Over the past week, Imperva sensors recorded over 127 million requests related to React2Shell (CVE‑2025‑55182) probing and exploitation attempts, highlighting the scale and automation targeting this vulnerability. These attempts spanned across more than 87 thousand distinct sites, showing that opportunistic scanning far outweighs targeted, single-tenant attacks.  

Activity was observed across 128 countries, with the United States and Singapore emerging as the most heavily targeted regions, underscoring the global reach of this CVE. 

The industry reach is widespread, although Education and Financial Services sites collectively account for almost half of all attacks.

The PoC Slop

Shortly after the public disclosure of React2Shell (CVE-2025-55182), a flood of what claimed to be “proof-of-concept” exploits began circulating. As the original disclosure site warns, many of these PoCs were invalidly crafted under incorrect assumptions, such as requiring explicit exposure of dangerous server-side functionality such as child_process.exec, vm.runInThisContext, or fs.writeFile rather than exploiting the actual flaw in the RSC Flight deserialization logic.

This surge of AI-generated PoC samples has a harmful side effect: it has muddied the waters for defenders. Instead of concentrating on the real vulnerability, security teams must sift through a sea of false or irrelevant exploit attempts. Attackers and bots are now producing a vast number of convincing-looking payloads, making it much harder for defenders to tell legitimate exploits from background noise.

An example of AI POC:

Malicious campaigns

In the immediate aftermath of the React2Shell disclosure, Imperva Threat research observed a large volume of malicious campaigns leveraging the vulnerability as an entry point. The following is a summary of just a few of the campaigns we observed along with the relevant IoCs:

1. Linux Remote Access Trojan Campaign
2. XNote RAT
3. Snowlight dropper
4. ReactOnMyNuts: Botnet and Cryptominer spreader campaign
5. Runnv Cryptojacking campaign

1. Linux Remote Access Trojan Campaign

Description:

A widespread campaign, where attackers leveraged the React Server Components vulnerability to download a malicious RAT executable. Once installed, the malware contacts a C2 server and retrieves JSON-based task instructions, such as running system commands, opening a reverse shell, and uploading or downloading files.

Top Targeted Countries: United States, Indonesia Thailand, Brazil, United Kingdom

Top Targeted Industries: Telecom and ISPs, Business, Financial Services, Gambling

Malicious command:

IoCs:

2. XNote RAT

Description:

A highly targeted campaign, affecting only financial services sites in Hong Kong, utilizing the React2Shell vulnerability to deploy the Xnote Remote Access Trojan Linux malware. The Xnote malware was exposed by Russian anti-virus company Doctor Web, who believe that there is “good reason to believe that some members of the Chinese hacker group called ChinaZ took part in the development of this Trojan.”

Targeted Country: Hong Kong

Targeted Industry: Financial Services

Malicious command:

IoCs:

3. Snowlight dropper

A campaign focused on deploying the SnowLight dropper through the React2Shell vulnerability. SnowLight serves as both an initial access vector and a persistence mechanism, executing malicious scripts that retrieve and install additional, more advanced payloads, most notably the VShell Remote Access Trojan (RAT).

SnowLight is associated with Chinese state-sponsored threat actors tracked as UNC5174, a group known for targeting research and education institutions, businesses, charities, NGOs, and government organizations across Southeast Asia, the United States, and the United Kingdom.

Targeted Countries: Indonesia, Australia, United States, Kuwait

Targeted Industry: Financial Services, Telecom and ISPs, Retail

Malicious command:

IoCs:

4. ReactOnMyNuts: Botnet and Cryptominer spreader campaign

Description:

A campaign utilizing the React2Shell vulnerability to spread both Mirai and XMRig cryptojacking malware samples using shared server architecture. The attackers used the vulnerability to execute a one-liner command aimed at downloading and installing both Mirai botnet and XMRig cryptojacking malware.

Cryptojacker configuration showing wallet addresses

Top Targeted Countries: United States, Australia, United Kingdom, Argentina, Columbia

Top Targeted Industries: Healthcare, Business, Financial Services, Computing & IT

Malicious commands:

IoCs:

5. Runnv Cryptojacking campaign

Description:

A cryptojacking campaign, with indicators of Chinese origin. The attackers utilized the React2Shell vulnerability to execute a dropper bash script, which downloads several second stage files including bash scripts and gzip compressed data. These components form the code and configuration of the cryptojacking operation. From an investigation of the wallet addresses used in the campaign we can see that (at the time of investigation) the threat actors were making around 170 USD per day, or around 62,050 USD per year.

Screenshot downloader script showing Chinese characters

Crypto wallet address:

Campaign Monero Wallet Statistics

Top Targeted Countries: United States, Brazil, United Kingdom, Colombia, Canada

Top Targeted Industries: Business, Financial Services, Lifestyle, Healthcare

Malicious commands:

IoCs:

Conclusion

The React2Shell vulnerability has quickly evolved from disclosure to widespread exploitation, with over 127 million attack attempts targeting more than 87,000 sites across 128 countries observed on the Imperva network alone within the first week. The campaigns documented here, from state-sponsored RATs to cryptojacking operations demonstrate how rapidly threat actors weaponize critical vulnerabilities. Imperva Cloud WAF and On-Premises WAF customers remain fully protected against these exploitation attempts.

The post Chain Reaction: Attack Campaign Activity in the Aftermath of React Server Components Vulnerability appeared first on Blog.

Overview

On December 3, 2025, the React and Next.js teams disclosed a critical security vulnerability (CVSS 10.0), identified as React2Shell, affecting applications that leverage React Server Components together with Server Actions or Server Functions.

The React2Shell vulnerability stems from improper validation of client-supplied data within certain server-side React features. An unauthenticated attacker could exploit this flaw by sending specially crafted requests, leading to unexpected server-side behavior. Successful exploitation could result in unauthenticated remote code execution.

This vulnerability requires no authentication and affects a wide range of modern React/Next.js deployments.

• Primary CVE: CVE-2025-55182 (React Core)
• Downstream tracking: CVE-2025-66478 (Next.js)

What Causes the Vulnerability

The affected functionality involves the mechanism React uses to receive and interpret data for server-side features. Certain malformed or intentionally crafted inputs may trigger unsafe processing paths on the server.

The React and Next.js teams have released security updates that strengthen these validation steps and prevent unintended behavior.

Impact

The vulnerability allows unauthenticated remote code execution (RCE) on servers running React Server Components.

Applications using React Server Components are vulnerable even if they do not explicitly define Server Function endpoints.

In effect, a malicious actor can send specially crafted requests to a vulnerable server and, due to insecure deserialization of serialized payloads, trigger unintended server behavior including arbitrary code execution.

As of this advisory, there is no evidence of active exploitation in the wild. However, numerous unauthorized or fake proof-of-concept (POC) exploits have been circulated publicly, which may cause confusion or unintended harm if tested without proper validation.

Affected Versions:

• React: 19.0.0, 19.1.0–19.1.1, 19.2.0
• js (App Router): 15.x ≤ 15.5.6, 16.x ≤ 16.0.6

Patched versions:

• React: 19.0.1, 19.1.2, 19.2.1
• js: 15.5.7+, 16.0.7+, 16.1+

Imperva Proactive Response

Imperva’s Threat Research team initiated an immediate investigation to assess the potential impact on customer environments.

Within hours, we:

• Analyzed the vulnerability and mapped out the most plausible exploitation paths
• Developed and validated virtual patching rules designed to detect and block malicious request patterns associated with the issue
• Rolled out these protections automatically across the entire Imperva Cloud WAF customer base

All cloud protections are already active, require no change from customers, and continue to be monitored and refined as new information becomes available. On-prem customers should review the Community Guide to manually deploy this policy.

Conclusion

This is a significant framework-level security issue affecting widely used technologies. Imperva customers are already protected through our rapid response and proactive security controls. We will continue to track this vulnerability closely and update protections as new information becomes available.

While Imperva protections mitigate known attack vectors, customers should:

1. Update React and Next.js to the vendor-provided patched versions
2. Review any server-side features that accept data directly from clients
3. Continue monitoring vendor advisories for future updates

For further assistance, please contact Imperva Support or your Customer Success representative.

The post Imperva Customers Protected Against React Server Components (RSC) Vulnerability appeared first on Blog.

At the end of October 2025, Oracle released an emergency security alert addressing CVE-2025-61757, a high-severity authentication-bypass flaw that enables remote code execution in the Identity Manager product of Oracle Fusion Middleware (versions 12.2.1.4.0 and 14.1.2.1.0). Multiple threat actors are already exploiting the vulnerability in the wild, and it was added to CISA’s Known Exploited Vulnerabilities catalog on November 21, 2025. 

Oracle Identity Manager is widely deployed across large enterprises, particularly in finance, government, healthcare, and other sectors that rely heavily on Oracle infrastructure. Because it remains a core identity platform for many organizations, this vulnerability significantly elevates risk, making CVE-2025-61757 especially critical. 

The Vulnerability 

Recent disclosures indicate that, unlike previous Oracle CVEs, this vulnerability is straightforward and highly susceptible to exploitation by threat actors. The vulnerability originates from an authentication bypass in Oracle Identity Manager’s REST APIs, where attackers can trick the security filter into treating protected endpoints as public by appending parameters such as ?WSDL or ;.wadl to the URL path. This exposes sensitive endpoints like:

After gaining unauthenticated access, attackers can interact with a Groovy script compilation endpoint. Although this endpoint is not intended to execute scripts, it can be exploited to run malicious code during the compilation process by abusing Groovy’s annotation-processing feature. 

This flaw chain allowed researchers to achieve pre-authentication remote code execution on vulnerable Oracle Identity Manager instances. 

What We’ve Seen 

Over the past week, more than 300,000 attack attempts have been detected targeting this vulnerability. These attacks are occurring globally across over 18 countries, with the majority focused on the US and France. 

Computing, healthcare, and business sites are hit the hardest by attack attempts. 

Bottom Line 

CVE-2025-61757 is a critical authentication bypass vulnerability with a high operational impact, potentially allowing attackers to achieve remote code execution. 

The Imperva Threat Research group tracked and identified the exploitation chain of this vulnerability, ensuring that Imperva customers with Elastic WAF, Cloud WAF, or On-Prem WAF are now protected out of the box. 

The post CVE-2025-61757: Imperva Customers Protected Against Critical Oracle Identity Manager Authentication Bypass Leading to Remote Code Execution appeared first on Blog.

Executive Summary The OPCOPRO “Truman Show” operation is a fully synthetic, AI‑powered investment scam that uses legitimate Android and iOS apps from the official mobile app stores, and AI‑generated communities to steal money and identity data from victims. Instead of relying on malicious code, the attackers use social engineering. The attackers pull victims using phishing SMS/ads/Telegram into tightly-controlled WhatsApp and Telegram groups, where AI‑generated “experts” and synthetic peers simulate an institutional‑grade trading community for weeks before any money or personal details are requested. The mobile apps themselves contain no trading logic and act only as WebView shells connected to attacker‑controlled […]

The post The Truman Show Scam: Trapped in an AI-Generated Reality appeared first on Check Point Blog.

VVS stealer (or VVS $tealer) is a Python-based infostealer targeting Discord users. It employs Pyarmor for obfuscation, contributing to its efficacy.

The post VVS Discord Stealer Using Pyarmor for Obfuscation and Detection Evasion appeared first on Unit 42.

Overview of the attacks

In mid-2025, we identified a malicious driver file on computer systems in Asia. The driver file is signed with an old, stolen, or leaked digital certificate and registers as a mini-filter driver on infected machines. Its end-goal is to inject a backdoor Trojan into the system processes and provide protection for malicious files, user-mode processes, and registry keys.

Our analysis indicates that the final payload injected by the driver is a new sample of the ToneShell backdoor, which connects to the attacker’s servers and provides a reverse shell, along with other capabilities. The ToneShell backdoor is a tool known to be used exclusively by the HoneyMyte (aka Mustang Panda or Bronze President) APT actor and is often used in cyberespionage campaigns targeting government organizations, particularly in Southeast and East Asia.

The command-and-control servers for the ToneShell backdoor used in this campaign were registered in September 2024 via NameCheap services, and we suspect the attacks themselves to have begun in February 2025. We’ve observed through our telemetry that the new ToneShell backdoor is frequently employed in cyberespionage campaigns against government organizations in Southeast and East Asia, with Myanmar and Thailand being the most heavily targeted.

Notably, nearly all affected victims had previously been infected with other HoneyMyte tools, including the ToneDisk USB worm, PlugX, and older variants of ToneShell. Although the initial access vector remains unclear, it’s suspected that the threat actor leveraged previously compromised machines to deploy the malicious driver.

Compromised digital certificate

The driver file is signed with a digital certificate from Guangzhou Kingteller Technology Co., Ltd., with a serial number of 08 01 CC 11 EB 4D 1D 33 1E 3D 54 0C 55 A4 9F 7F. The certificate was valid from August 2012 until 2015.

We found multiple other malicious files signed with the same certificate which didn’t show any connections to the attacks described in this article. Therefore, we believe that other threat actors have been using it to sign their malicious tools as well. The following image shows the details of the certificate.

Technical details of the malicious driver

The filename used for the driver on the victim’s machine is ProjectConfiguration.sys. The registry key created for the driver’s service uses the same name, ProjectConfiguration.

The malicious driver contains two user-mode shellcodes, which are embedded into the .data section of the driver’s binary file. The shellcodes are executed as separate user-mode threads. The rootkit functionality protects both the driver’s own module and the user-mode processes into which the backdoor code is injected, preventing access by any process on the system.

API resolution

To obfuscate the actual behavior of the driver module, the attackers used dynamic resolution of the required API addresses from hash values.

The malicious driver first retrieves the base address of the ntoskrnl.exe and fltmgr.sys by calling ZwQuerySystemInformation with the SystemInformationClass set to SYSTEM_MODULE_INFORMATION. It then iterates through this system information and searches for the desired DLLs by name, noting the ImageBaseAddress of each.

Once the base addresses of the libraries are obtained, the driver uses a simple hashing algorithm to dynamically resolve the required API addresses from ntoskrnl.exe and fltmgr.sys.

The hashing algorithm is shown below. The two variants of the seed value provided in the comment are used in the shellcodes and the final payload of the attack.

Protection of the driver file

The malicious driver registers itself with the Filter Manager using FltRegisterFilter and sets up a pre-operation callback. This callback inspects I/O requests for IRP_MJ_SET_INFORMATION and triggers a malicious handler when certain FileInformationClass values are detected. The handler then checks whether the targeted file object is associated with the driver; if it is, it forces the operation to fail by setting IOStatus to STATUS_ACCESS_DENIED. The relevant FileInformationClass values include:

• FileRenameInformation
• FileDispositionInformation
• FileRenameInformationBypassAccessCheck
• FileDispositionInformationEx
• FileRenameInformationEx
• FileRenameInformationExBypassAccessCheck

These classes correspond to file-delete and file-rename operations. By monitoring them, the driver prevents itself from being removed or renamed – actions that security tools might attempt when trying to quarantine it.

Protection of registry keys

The driver also builds a global list of registry paths and parameter names that it intends to protect. This list contains the following entries:

• ProjectConfiguration
  
• ProjectConfiguration\Instances
  
• ProjectConfiguration Instance

To guard these keys, the malware sets up a RegistryCallback routine, registering it through CmRegisterCallbackEx. To do so, it must assign itself an altitude value. Microsoft governs altitude assignments for mini-filters, grouping them into Load Order categories with predefined altitude ranges. A filter driver with a low numerical altitude is loaded into the I/O stack below filters with higher altitudes. The malware uses a hardcoded starting point of 330024 and creates altitude strings in the format 330024.%l, where %l ranges from 0 to 10,000.

The malware then begins attempting to register the callback using the first generated altitude. If the registration fails with STATUS_FLT_INSTANCE_ALTITUDE_COLLISION, meaning the altitude is already taken, it increments the value and retries. It repeats this process until it successfully finds an unused altitude.

The callback monitors four specific registry operations. Whenever one of these operations targets a key from its protected list, it responds with 0xC0000022 (STATUS_ACCESS_DENIED), blocking the action. The monitored operations are:

• RegNtPreCreateKey
  
• RegNtPreOpenKey
  
• RegNtPreCreateKeyEx
  
• RegNtPreOpenKeyEx

Microsoft designates the 320000–329999 altitude range for the FSFilter Anti-Virus Load Order Group. The malware’s chosen altitude exceeds this range. Since filters with lower altitudes sit deeper in the I/O stack, the malicious driver intercepts file operations before legitimate low-altitude filters like antivirus components, allowing it to circumvent security checks.

Finally, the malware tampers with the altitude assigned to WdFilter, a key Microsoft Defender driver. It locates the registry entry containing the driver’s altitude and changes it to 0, effectively preventing WdFilter from being loaded into the I/O stack.

Protection of user-mode processes

The malware sets up a list intended to hold protected process IDs (PIDs). It begins with 32 empty slots, which are filled as needed during execution. A status flag is also initialized and set to 1 to indicate that the list starts out empty.

Next, the malware uses ObRegisterCallbacks to register two callbacks that intercept process-related operations. These callbacks apply to both OB_OPERATION_HANDLE_CREATE and OB_OPERATION_HANDLE_DUPLICATE, and both use a malicious pre-operation routine.

This routine checks whether the process involved in the operation has a PID that appears in the protected list. If so, it sets the DesiredAccess field in the OperationInformation structure to 0, effectively denying any access to the process.

The malware also registers a callback routine by calling PsSetCreateProcessNotifyRoutine. These callbacks are triggered during every process creation and deletion on the system. This malware’s callback routine checks whether the parent process ID (PPID) of a process being deleted exists in the protected list; if it does, the malware removes that PPID from the list. This eventually removes the rootkit protection from a process with an injected backdoor, once the backdoor has fulfilled its responsibilities.

Payload injection

The driver delivers two user-mode payloads.

The first payload spawns an svchost process and injects a small delay-inducing shellcode.  The PID of this new svchost instance is written to a file for later use.

The second payload is the final component – the ToneShell backdoor – and is later injected into that same svchost process.

Injection workflow:

The malicious driver searches for a high-privilege target process by iterating through PIDs and checking whether each process exists and runs under SeLocalSystemSid. Once it finds one, it customizes the first payload using random event names, file names, and padding bytes, then creates a named event and injects the payload by attaching its current thread to the process, allocating memory, and launching a new thread.

After injection, it waits for the payload to signal the event, reads the PID of the newly created svchost process from the generated file, and adds it to its protected process list. It then similarly customizes the second payload (ToneShell) using random event name and random padding bytes, then creates a named event and injects the payload by attaching to the process, allocating memory, and launching a new thread.

Once the ToneShell backdoor finishes execution, it signals the event. The malware then removes the svchost PID from the protected list, waits 10 seconds, and attempts to terminate the process.

ToneShell backdoor

The final stage of the attack deploys ToneShell, a backdoor previously linked to operations by the HoneyMyte APT group and discussed in earlier reporting (see Malpedia and MITRE). Notably, this is the first time we’ve seen ToneShell delivered through a kernel-mode loader, giving it protection from user-mode monitoring and benefiting from the rootkit capabilities of the driver that hides its activity from security tools.

Earlier ToneShell variants generated a 16-byte GUID using CoCreateGuid and stored it as a host identifier. In contrast, this version checks for a file named C:\ProgramData\MicrosoftOneDrive.tlb, validating a 4-byte marker inside it. If the file is absent or the marker is invalid, the backdoor derives a new pseudo-random 4-byte identifier using system-specific values (computer name, tick count, and PRNG), then creates the file and writes the marker. This becomes the unique ID for the infected host.

The samples we have analyzed contact two command-and-control servers:

• avocadomechanism[.]com
  
• potherbreference[.]com

ToneShell communicates with its C2 over raw TCP on port 443 while disguising traffic using fake TLS headers. This version imitates the first bytes of a TLS 1.3 record (0x17 0x03 0x04) instead of the TLS 1.2 pattern used previously. After this three-byte marker, each packet contains a size field and an encrypted payload.

Packet layout:

• Header (3 bytes): Fake TLS marker
• Size (2 bytes): Payload length
• Payload: Encrypted with a rolling XOR key

The backdoor supports a set of remote operations, including file upload/download, remote shell functionality, and session control. The command set includes:

Command ID	Description
0x1	Create temporary file for incoming data
0x2 / 0x3	Download file
0x4	Cancel download
0x7	Establish remote shell via pipe
0x8	Receive operator command
0x9	Terminate shell
0xA / 0xB	Upload file
0xC	Cancel upload
0xD	Close connection

Conclusion

We assess with high confidence that the activity described in this report is linked to the HoneyMyte threat actor. This conclusion is supported by the use of the ToneShell backdoor as the final-stage payload, as well as the presence of additional tools long associated with HoneyMyte – such as PlugX, and the ToneDisk USB worm – on the impacted systems.

HoneyMyte’s 2025 operations show a noticeable evolution toward using kernel-mode injectors to deploy ToneShell, improving both stealth and resilience. In this campaign, we observed a new ToneShell variant delivered through a kernel-mode driver that carries and injects the backdoor directly from its embedded payload. To further conceal its activity, the driver first deploys a small user-mode component that handles the final injection step. It also uses multiple obfuscation techniques, callback routines, and notification mechanisms to hide its API usage and track process and registry activity, ultimately strengthening the backdoor’s defenses.

Because the shellcode executes entirely in memory, memory forensics becomes essential for uncovering and analyzing this intrusion. Detecting the injected shellcode is a key indicator of ToneShell’s presence on compromised hosts.

Recommendations

To protect themselves against this threat, organizations should:

• Implement robust network security measures, such as firewalls and intrusion detection systems.
• Use advanced threat detection tools, such as endpoint detection and response (EDR) solutions.
• Provide regular security awareness training to employees.
• Conduct regular security audits and vulnerability assessments to identify and remediate potential vulnerabilities.
• Consider implementing a security information and event management (SIEM) system to monitor and analyze security-related data.

By following these recommendations, organizations can reduce their risk of being compromised by the HoneyMyte APT group and other similar threats.

Indicators of Compromise

More indicators of compromise, as well as any updates to these, are available to the customers of our APT intelligence reporting service. If you are interested, please contact intelreports@kaspersky.com.

36f121046192b7cac3e4bec491e8f1b5        AppvVStram_.sys
fe091e41ba6450bcf6a61a2023fe6c83         AppvVStram_.sys
abe44ad128f765c14d895ee1c8bad777       ProjectConfiguration.sys
avocadomechanism[.]com                            ToneShell C2
potherbreference[.]com                                 ToneShell C2

Overview of the attacks

In mid-2025, we identified a malicious driver file on computer systems in Asia. The driver file is signed with an old, stolen, or leaked digital certificate and registers as a mini-filter driver on infected machines. Its end-goal is to inject a backdoor Trojan into the system processes and provide protection for malicious files, user-mode processes, and registry keys.

Our analysis indicates that the final payload injected by the driver is a new sample of the ToneShell backdoor, which connects to the attacker’s servers and provides a reverse shell, along with other capabilities. The ToneShell backdoor is a tool known to be used exclusively by the HoneyMyte (aka Mustang Panda or Bronze President) APT actor and is often used in cyberespionage campaigns targeting government organizations, particularly in Southeast and East Asia.

The command-and-control servers for the ToneShell backdoor used in this campaign were registered in September 2024 via NameCheap services, and we suspect the attacks themselves to have begun in February 2025. We’ve observed through our telemetry that the new ToneShell backdoor is frequently employed in cyberespionage campaigns against government organizations in Southeast and East Asia, with Myanmar and Thailand being the most heavily targeted.

Notably, nearly all affected victims had previously been infected with other HoneyMyte tools, including the ToneDisk USB worm, PlugX, and older variants of ToneShell. Although the initial access vector remains unclear, it’s suspected that the threat actor leveraged previously compromised machines to deploy the malicious driver.

Compromised digital certificate

The driver file is signed with a digital certificate from Guangzhou Kingteller Technology Co., Ltd., with a serial number of 08 01 CC 11 EB 4D 1D 33 1E 3D 54 0C 55 A4 9F 7F. The certificate was valid from August 2012 until 2015.

We found multiple other malicious files signed with the same certificate which didn’t show any connections to the attacks described in this article. Therefore, we believe that other threat actors have been using it to sign their malicious tools as well. The following image shows the details of the certificate.

Technical details of the malicious driver

The filename used for the driver on the victim’s machine is ProjectConfiguration.sys. The registry key created for the driver’s service uses the same name, ProjectConfiguration.

The malicious driver contains two user-mode shellcodes, which are embedded into the .data section of the driver’s binary file. The shellcodes are executed as separate user-mode threads. The rootkit functionality protects both the driver’s own module and the user-mode processes into which the backdoor code is injected, preventing access by any process on the system.

API resolution

To obfuscate the actual behavior of the driver module, the attackers used dynamic resolution of the required API addresses from hash values.

The malicious driver first retrieves the base address of the ntoskrnl.exe and fltmgr.sys by calling ZwQuerySystemInformation with the SystemInformationClass set to SYSTEM_MODULE_INFORMATION. It then iterates through this system information and searches for the desired DLLs by name, noting the ImageBaseAddress of each.

Once the base addresses of the libraries are obtained, the driver uses a simple hashing algorithm to dynamically resolve the required API addresses from ntoskrnl.exe and fltmgr.sys.

The hashing algorithm is shown below. The two variants of the seed value provided in the comment are used in the shellcodes and the final payload of the attack.

Protection of the driver file

The malicious driver registers itself with the Filter Manager using FltRegisterFilter and sets up a pre-operation callback. This callback inspects I/O requests for IRP_MJ_SET_INFORMATION and triggers a malicious handler when certain FileInformationClass values are detected. The handler then checks whether the targeted file object is associated with the driver; if it is, it forces the operation to fail by setting IOStatus to STATUS_ACCESS_DENIED. The relevant FileInformationClass values include:

• FileRenameInformation
• FileDispositionInformation
• FileRenameInformationBypassAccessCheck
• FileDispositionInformationEx
• FileRenameInformationEx
• FileRenameInformationExBypassAccessCheck

These classes correspond to file-delete and file-rename operations. By monitoring them, the driver prevents itself from being removed or renamed – actions that security tools might attempt when trying to quarantine it.

Protection of registry keys

The driver also builds a global list of registry paths and parameter names that it intends to protect. This list contains the following entries:

• ProjectConfiguration
  
• ProjectConfiguration\Instances
  
• ProjectConfiguration Instance

To guard these keys, the malware sets up a RegistryCallback routine, registering it through CmRegisterCallbackEx. To do so, it must assign itself an altitude value. Microsoft governs altitude assignments for mini-filters, grouping them into Load Order categories with predefined altitude ranges. A filter driver with a low numerical altitude is loaded into the I/O stack below filters with higher altitudes. The malware uses a hardcoded starting point of 330024 and creates altitude strings in the format 330024.%l, where %l ranges from 0 to 10,000.

The malware then begins attempting to register the callback using the first generated altitude. If the registration fails with STATUS_FLT_INSTANCE_ALTITUDE_COLLISION, meaning the altitude is already taken, it increments the value and retries. It repeats this process until it successfully finds an unused altitude.

The callback monitors four specific registry operations. Whenever one of these operations targets a key from its protected list, it responds with 0xC0000022 (STATUS_ACCESS_DENIED), blocking the action. The monitored operations are:

• RegNtPreCreateKey
  
• RegNtPreOpenKey
  
• RegNtPreCreateKeyEx
  
• RegNtPreOpenKeyEx

Microsoft designates the 320000–329999 altitude range for the FSFilter Anti-Virus Load Order Group. The malware’s chosen altitude exceeds this range. Since filters with lower altitudes sit deeper in the I/O stack, the malicious driver intercepts file operations before legitimate low-altitude filters like antivirus components, allowing it to circumvent security checks.

Finally, the malware tampers with the altitude assigned to WdFilter, a key Microsoft Defender driver. It locates the registry entry containing the driver’s altitude and changes it to 0, effectively preventing WdFilter from being loaded into the I/O stack.

Protection of user-mode processes

The malware sets up a list intended to hold protected process IDs (PIDs). It begins with 32 empty slots, which are filled as needed during execution. A status flag is also initialized and set to 1 to indicate that the list starts out empty.

Next, the malware uses ObRegisterCallbacks to register two callbacks that intercept process-related operations. These callbacks apply to both OB_OPERATION_HANDLE_CREATE and OB_OPERATION_HANDLE_DUPLICATE, and both use a malicious pre-operation routine.

This routine checks whether the process involved in the operation has a PID that appears in the protected list. If so, it sets the DesiredAccess field in the OperationInformation structure to 0, effectively denying any access to the process.

The malware also registers a callback routine by calling PsSetCreateProcessNotifyRoutine. These callbacks are triggered during every process creation and deletion on the system. This malware’s callback routine checks whether the parent process ID (PPID) of a process being deleted exists in the protected list; if it does, the malware removes that PPID from the list. This eventually removes the rootkit protection from a process with an injected backdoor, once the backdoor has fulfilled its responsibilities.

Payload injection

The driver delivers two user-mode payloads.

The first payload spawns an svchost process and injects a small delay-inducing shellcode.  The PID of this new svchost instance is written to a file for later use.

The second payload is the final component – the ToneShell backdoor – and is later injected into that same svchost process.

Injection workflow:

The malicious driver searches for a high-privilege target process by iterating through PIDs and checking whether each process exists and runs under SeLocalSystemSid. Once it finds one, it customizes the first payload using random event names, file names, and padding bytes, then creates a named event and injects the payload by attaching its current thread to the process, allocating memory, and launching a new thread.

After injection, it waits for the payload to signal the event, reads the PID of the newly created svchost process from the generated file, and adds it to its protected process list. It then similarly customizes the second payload (ToneShell) using random event name and random padding bytes, then creates a named event and injects the payload by attaching to the process, allocating memory, and launching a new thread.

Once the ToneShell backdoor finishes execution, it signals the event. The malware then removes the svchost PID from the protected list, waits 10 seconds, and attempts to terminate the process.

ToneShell backdoor

The final stage of the attack deploys ToneShell, a backdoor previously linked to operations by the HoneyMyte APT group and discussed in earlier reporting (see Malpedia and MITRE). Notably, this is the first time we’ve seen ToneShell delivered through a kernel-mode loader, giving it protection from user-mode monitoring and benefiting from the rootkit capabilities of the driver that hides its activity from security tools.

Earlier ToneShell variants generated a 16-byte GUID using CoCreateGuid and stored it as a host identifier. In contrast, this version checks for a file named C:\ProgramData\MicrosoftOneDrive.tlb, validating a 4-byte marker inside it. If the file is absent or the marker is invalid, the backdoor derives a new pseudo-random 4-byte identifier using system-specific values (computer name, tick count, and PRNG), then creates the file and writes the marker. This becomes the unique ID for the infected host.

The samples we have analyzed contact two command-and-control servers:

• avocadomechanism[.]com
  
• potherbreference[.]com

ToneShell communicates with its C2 over raw TCP on port 443 while disguising traffic using fake TLS headers. This version imitates the first bytes of a TLS 1.3 record (0x17 0x03 0x04) instead of the TLS 1.2 pattern used previously. After this three-byte marker, each packet contains a size field and an encrypted payload.

Packet layout:

• Header (3 bytes): Fake TLS marker
• Size (2 bytes): Payload length
• Payload: Encrypted with a rolling XOR key

The backdoor supports a set of remote operations, including file upload/download, remote shell functionality, and session control. The command set includes:

Command ID	Description
0x1	Create temporary file for incoming data
0x2 / 0x3	Download file
0x4	Cancel download
0x7	Establish remote shell via pipe
0x8	Receive operator command
0x9	Terminate shell
0xA / 0xB	Upload file
0xC	Cancel upload
0xD	Close connection

Conclusion

We assess with high confidence that the activity described in this report is linked to the HoneyMyte threat actor. This conclusion is supported by the use of the ToneShell backdoor as the final-stage payload, as well as the presence of additional tools long associated with HoneyMyte – such as PlugX, and the ToneDisk USB worm – on the impacted systems.

HoneyMyte’s 2025 operations show a noticeable evolution toward using kernel-mode injectors to deploy ToneShell, improving both stealth and resilience. In this campaign, we observed a new ToneShell variant delivered through a kernel-mode driver that carries and injects the backdoor directly from its embedded payload. To further conceal its activity, the driver first deploys a small user-mode component that handles the final injection step. It also uses multiple obfuscation techniques, callback routines, and notification mechanisms to hide its API usage and track process and registry activity, ultimately strengthening the backdoor’s defenses.

Because the shellcode executes entirely in memory, memory forensics becomes essential for uncovering and analyzing this intrusion. Detecting the injected shellcode is a key indicator of ToneShell’s presence on compromised hosts.

Recommendations

To protect themselves against this threat, organizations should:

• Implement robust network security measures, such as firewalls and intrusion detection systems.
• Use advanced threat detection tools, such as endpoint detection and response (EDR) solutions.
• Provide regular security awareness training to employees.
• Conduct regular security audits and vulnerability assessments to identify and remediate potential vulnerabilities.
• Consider implementing a security information and event management (SIEM) system to monitor and analyze security-related data.

By following these recommendations, organizations can reduce their risk of being compromised by the HoneyMyte APT group and other similar threats.

Indicators of Compromise

More indicators of compromise, as well as any updates to these, are available to the customers of our APT intelligence reporting service. If you are interested, please contact intelreports@kaspersky.com.

36f121046192b7cac3e4bec491e8f1b5        AppvVStram_.sys
fe091e41ba6450bcf6a61a2023fe6c83         AppvVStram_.sys
abe44ad128f765c14d895ee1c8bad777       ProjectConfiguration.sys
avocadomechanism[.]com                            ToneShell C2
potherbreference[.]com                                 ToneShell C2

Introduction

The Evasive Panda APT group (also known as Bronze Highland, Daggerfly, and StormBamboo) has been active since 2012, targeting multiple industries with sophisticated, evolving tactics. Our latest research (June 2025) reveals that the attackers conducted highly-targeted campaigns, which started in November 2022 and ran until November 2024.

The group mainly performed adversary-in-the-middle (AitM) attacks on specific victims. These included techniques such as dropping loaders into specific locations and storing encrypted parts of the malware on attacker-controlled servers, which were resolved as a response to specific website DNS requests. Notably, the attackers have developed a new loader that evades detection when infecting its targets, and even employed hybrid encryption practices to complicate analysis and make implants unique to each victim.

Furthermore, the group has developed an injector that allows them to execute their MgBot implant in memory by injecting it into legitimate processes. It resides in the memory space of a decade-old signed executable by using DLL sideloading and enables them to maintain a stealthy presence in compromised systems for extended periods.

Additional information about this threat, including indicators of compromise, is available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.

Technical details

Initial infection vector

The threat actor commonly uses lures that are disguised as new updates to known third-party applications or popular system applications trusted by hundreds of users over the years.

In this campaign, the attackers used an executable disguised as an update package for SohuVA, which is a streaming app developed by Sohu Inc., a Chinese internet company. The malicious package, named sohuva_update_10.2.29.1-lup-s-tp.exe, clearly impersonates a real SohuVA update to deliver malware from the following resource, as indicated by our telemetry:

http://p2p.hd.sohu.com[.]cn/foxd/gz?file=sohunewplayer_7.0.22.1_03_29_13_13_union.exe&new=/66/157/ovztb0wktdmakeszwh2eha.exe

There is a possibility that the attackers used a DNS poisoning attack to alter the DNS response of p2p.hd.sohu.com[.]cn to an attacker-controlled server’s IP address, while the genuine update module of the SohuVA application tries to update its binaries located in appdata\roaming\shapp\7.0.18.0\package. Although we were unable to verify this at the time of analysis, we can make an educated guess, given that it is still unknown what triggered the update mechanism.

Furthermore, our analysis of the infection process has identified several additional campaigns pursued by the same group. For example, they utilized a fake updater for the iQIYI Video application, a popular platform for streaming Asian media content similar to SohuVA. This fake updater was dropped into the application’s installation folder and executed by the legitimate service qiyiservice.exe. Upon execution, the fake updater initiated malicious activity on the victim’s system, and we have identified that the same method is used for IObit Smart Defrag and Tencent QQ applications.

The initial loader was developed in C++ using the Windows Template Library (WTL). Its code bears a strong resemblance to Wizard97Test, a WTL sample application hosted on Microsoft’s GitHub. The attackers appear to have embedded malicious code within this project to effectively conceal their malicious intentions.

The loader first decrypts the encrypted configuration buffer by employing an XOR-based decryption algorithm:

for ( index = 0; index < v6; index = (index + 1) )
{
if ( index >= 5156 )
break;
mw_configindex ^= (&mw_deflated_config + (index & 3));
}

After decryption, it decompresses the LZMA-compressed buffer into the allocated buffer, and all of the configuration is exposed, including several components:

• Malware installation path: %ProgramData%\Microsoft\MF
• Resource domain: http://www.dictionary.com/
• Resource URI: image?id=115832434703699686&product=dict-homepage.png
• MgBot encrypted configuration

The malware also checks the name of the logged-in user in the system and performs actions accordingly. If the username is SYSTEM, the malware copies itself with a different name by appending the ext.exe suffix inside the current working directory. Then it uses the ShellExecuteW API to execute the newly created version. Notably, all relevant strings in the malware, such as SYSTEM and ext.exe, are encrypted, and the loader decrypts them with a specific XOR algorithm.

If the username is not SYSTEM, the malware first copies explorer.exe into %TEMP%, naming the instance as tmpX.tmp (where X is an incremented decimal number), and then deletes the original file. The purpose of this activity is unclear, but it consumes high system resources. Next, the loader decrypts the kernel32.dll and VirtualProtect strings to retrieve their base addresses by calling the GetProcAddress API. Afterwards, it uses a single-byte XOR key to decrypt the shellcode, which is 9556 bytes long, and stores it at the same address in the .data section. Since the .data section does not have execute permission, the malware uses the VirtualProtect API to set the permission for the section. This allows for the decrypted shellcode to be executed without alerting security products by allocating new memory blocks. Before executing the shellcode, the malware prepares a 16-byte-long parameter structure that contains several items, with the most important one being the address of the encrypted MgBot configuration buffer.

Multi-stage shellcode execution

As mentioned above, the loader follows a unique delivery scheme, which includes at least two stages of payload. The shellcode employs a hashing algorithm known as PJW to resolve Windows APIs at runtime in a stealthy manner.

unsigned int calc_PJWHash(_BYTE *a1)
{
unsigned int v2;
v2 = 0;
while ( *a1 )
{
v2 = *a1++ + 16 * v2;
if ( (v2 & 0xF0000000) != 0 )
v2 = ~(v2 & 0xF0000000) & (v2 ^ ((v2 & 0xF0000000) >> 24));
}
return v2;
}

The shellcode first searches for a specific DAT file in the malware’s primary installation directory. If it is found, the shellcode decrypts it using the CryptUnprotectData API, a Windows API that decrypts protected data into allocated heap memory, and ensures that the data can only be decrypted on the particular machine by design. After decryption, the shellcode deletes the file to avoid leaving any traces of the valuable part of the attack chain.

If, however, the DAT file is not present, the shellcode initiates the next-stage shellcode installation process. It involves retrieving encrypted data from a web source that is actually an attacker-controlled server, by employing a DNS poisoning attack. Our telemetry shows that the attackers successfully obtained the encrypted second-stage shellcode, disguised as a PNG file, from the legitimate website dictionary[.]com. However, upon further investigation, it was discovered that the IP address associated with dictionary[.]com had been manipulated through a DNS poisoning technique. As a result, victims’ systems were resolving the website to different attacker-controlled IP addresses depending on the victims’ geographical location and internet service provider.

To retrieve the second-stage shellcode, the first-stage shellcode uses the RtlGetVersion API to obtain the current Windows version number and then appends a predefined string to the HTTP header:

sec-ch-ua-platform: windows %d.%d.%d.%d.%d.%d

This implies that the attackers needed to be able to examine request headers and respond accordingly. We suspect that the attackers’ collection of the Windows version number and its inclusion in the request headers served a specific purpose, likely allowing them to target specific operating system versions and even tailor their payload to different operating systems. Given that the Evasive Panda threat actor has been known to use distinct implants for Windows (MgBot) and macOS (Macma) in previous campaigns, it is likely that the malware uses the retrieved OS version string to determine which implant to deploy. This enables the threat actor to adapt their attack to the victim’s specific operating system by assessing results on the server side.

From this point on, the first-stage shellcode proceeds to decrypt the retrieved payload with a XOR decryption algorithm:

key = *(mw_decryptedDataFromDatFile + 92);
index = 0;
if ( sz_shellcode )
{
mw_decryptedDataFromDatFile_1 = Heap;
do
{
*(index + mw_decryptedDataFromDatFile_1) ^= *(&key + (index & 3));
++index;
}
while ( index < sz_shellcode );
}

The shellcode uses a 4-byte XOR key, consistent with the one used in previous stages, to decrypt the new shellcode stored in the DAT file. It then creates a structure for the decrypted second-stage shellcode, similar to the first stage, including a partially decrypted configuration buffer and other relevant details.

Next, the shellcode resolves the VirtualProtect API to change the protection flag of the new shellcode buffer, allowing it to be executed with PAGE_EXECUTE_READWRITE permissions. The second-stage shellcode is then executed, with the structure passed as an argument. After the shellcode has finished running, its return value is checked to see if it matches 0x9980. Depending on the outcome, the shellcode will either terminate its own process or return control to the caller.

Although we were unable to retrieve the second-stage payload from the attackers’ web server during our analysis, we were able to capture and examine the next stage of the malware, which was to be executed afterwards. Our analysis suggests that the attackers may have used the CryptProtectData API during the execution of the second shellcode to encrypt the entire shellcode and store it as a DAT file in the malware’s main installation directory. This implies that the malware writes an encrypted DAT file to disk using the CryptProtectData API, which can then be decrypted and executed by the first-stage shellcode. Furthermore, it appears that the attacker attempted to generate a unique encrypted second shellcode file for each victim, which we believe is another technique used to evade detection and defense mechanisms in the attack chain.

Secondary loader

We identified a secondary loader, named libpython2.4.dll, which was disguised as a legitimate Windows library and used by the Evasive Panda group to achieve a stealthier loading mechanism. Notably, this malicious DLL loader relies on a legitimate, signed executable named evteng.exe (MD5: 1c36452c2dad8da95d460bee3bea365e), which is an older version of python.exe. This executable is a Python wrapper that normally imports the libpython2.4.dll library and calls the Py_Main function.

The secondary loader retrieves the full path of the current module (libpython2.4.dll) and writes it to a file named status.dat, located in C:\ProgramData\Microsoft\eHome, but only if a file with the same name does not already exist in that directory. We believe with a low-to-medium level of confidence that this action is intended to allow the attacker to potentially update the secondary loader in the future. This suggests that the attacker may be planning for future modifications or upgrades to the malware.

The malware proceeds to decrypt the next stage by reading the entire contents of C:\ProgramData\Microsoft\eHome\perf.dat. This file contains the previously downloaded and XOR-decrypted data from the attacker-controlled server, which was obtained through the DNS poisoning technique as described above. Notably, the implant downloads the payload several times and moves it between folders by renaming it. It appears that the attacker used a complex process to obtain this stage from a resource, where it was initially XOR-encrypted. The attacker then decrypted this stage with XOR and subsequently encrypted and saved it to perf.dat using a custom hybrid of Microsoft’s Data Protection Application Programming Interface (DPAPI) and the RC5 algorithm.

This custom encryption algorithm works as follows. The RC5 encryption key is itself encrypted using Microsoft’s DPAPI and stored in the first 16 bytes of perf.dat. The RC5-encrypted payload is then appended to the file, following the encrypted key. To decrypt the payload, the process is reversed: the encrypted RC5 key is first decrypted with DPAPI, and then used to decrypt the remaining contents of perf.dat, which contains the next-stage payload.

The attacker uses this approach to ensure that a crucial part of the attack chain is secured, and the encrypted data can only be decrypted on the specific system where the encryption was initially performed. This is because the DPAPI functions used to secure the RC5 key tie the decryption process to the individual system, making it difficult for the encrypted data to be accessed or decrypted elsewhere. This makes it more challenging for defenders to intercept and analyze the malicious payload.

After completing the decryption process, the secondary loader initiates the runtime injection method, which likely involves the use of a custom runtime DLL injector for the decrypted data. The injector first calls the DLL entry point and then searches for a specific export function named preload. Although we were unable to determine which encrypted module was decrypted and executed in memory due to a lack of available data on the attacker-controlled server, our telemetry reveals that an MgBot variant is injected into the legitimate svchost.exe process after the secondary loader is executed. Fortunately, this allowed us to analyze these implants further and gain additional insights into the attack, as well as reveal that the encrypted initial configuration was passed through the infection chain, ultimately leading to the execution of MgBot. The configuration file was decrypted with a single-byte XOR key, 0x58, and this would lead to the full exposure of the configuration.

Our analysis suggests that the configuration includes a campaign name, hardcoded C2 server IP addresses, and unknown bytes that may serve as encryption or decryption keys, although our confidence in this assessment is limited. Interestingly, some of the C2 server addresses have been in use for multiple years, indicating a potential long-term operation.

Victims

Our telemetry has detected victims in Türkiye, China, and India, with some systems remaining compromised for over a year. The attackers have shown remarkable persistence, sustaining the campaign for two years (from November 2022 to November 2024) according to our telemetry, which indicates a substantial investment of resources and dedication to the operation.

Attribution

The techniques, tactics, and procedures (TTPs) employed in this compromise indicate with high confidence that the Evasive Panda threat actor is responsible for the attack. Despite the development of a new loader, which has been added to their arsenal, the decade-old MgBot implant was still identified in the final stage of the attack with new elements in its configuration. Consistent with previous research conducted by several vendors in the industry, the Evasive Panda threat actor is known to commonly utilize various techniques, such as supply-chain compromise, Adversary-in-the-Middle attacks, and watering-hole attacks, which enable them to distribute their payloads without raising suspicion.

Conclusion

The Evasive Panda threat actor has once again showcased its advanced capabilities, evading security measures with new techniques and tools while maintaining long-term persistence in targeted systems. Our investigation suggests that the attackers are continually improving their tactics, and it is likely that other ongoing campaigns exist. The introduction of new loaders may precede further updates to their arsenal.

As for the AitM attack, we do not have any reliable sources on how the threat actor delivers the initial loader, and the process of poisoning DNS responses for legitimate websites, such as dictionary[.]com, is still unknown. However, we are considering two possible scenarios based on prior research and the characteristics of the threat actor: either the ISPs used by the victims were selectively targeted, and some kind of network implant was installed on edge devices, or one of the network devices of the victims — most likely a router or firewall appliance — was targeted for this purpose. However, it is difficult to make a precise statement, as this campaign requires further attention in terms of forensic investigation, both on the ISPs and the victims.

The configuration file’s numerous C2 server IP addresses indicate a deliberate effort to maintain control over infected systems running the MgBot implant. By using multiple C2 servers, the attacker aims to ensure prolonged persistence and prevents loss of control over compromised systems, suggesting a strategic approach to sustaining their operations.

Indicators of compromise

File Hashes
c340195696d13642ecf20fbe75461bed sohuva_update_10.2.29.1-lup-s-tp.exe
7973e0694ab6545a044a49ff101d412a libpython2.4.dll
9e72410d61eaa4f24e0719b34d7cad19 (MgBot implant)

File Paths
C:\ProgramData\Microsoft\MF
C:\ProgramData\Microsoft\eHome\status.dat
C:\ProgramData\Microsoft\eHome\perf.dat

URLs and IPs
60.28.124[.]21     (MgBot C2)
123.139.57[.]103   (MgBot C2)
140.205.220[.]98   (MgBot C2)
112.80.248[.]27    (MgBot C2)
116.213.178[.]11   (MgBot C2)
60.29.226[.]181    (MgBot C2)
58.68.255[.]45     (MgBot C2)
61.135.185[.]29    (MgBot C2)
103.27.110[.]232   (MgBot C2)
117.121.133[.]33   (MgBot C2)
139.84.170[.]230   (MgBot C2)
103.96.130[.]107   (AitM C2)
158.247.214[.]28   (AitM C2)
106.126.3[.]78     (AitM C2)
106.126.3[.]56     (AitM C2)

Introduction

The Evasive Panda APT group (also known as Bronze Highland, Daggerfly, and StormBamboo) has been active since 2012, targeting multiple industries with sophisticated, evolving tactics. Our latest research (June 2025) reveals that the attackers conducted highly-targeted campaigns, which started in November 2022 and ran until November 2024.

The group mainly performed adversary-in-the-middle (AitM) attacks on specific victims. These included techniques such as dropping loaders into specific locations and storing encrypted parts of the malware on attacker-controlled servers, which were resolved as a response to specific website DNS requests. Notably, the attackers have developed a new loader that evades detection when infecting its targets, and even employed hybrid encryption practices to complicate analysis and make implants unique to each victim.

Furthermore, the group has developed an injector that allows them to execute their MgBot implant in memory by injecting it into legitimate processes. It resides in the memory space of a decade-old signed executable by using DLL sideloading and enables them to maintain a stealthy presence in compromised systems for extended periods.

Additional information about this threat, including indicators of compromise, is available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.

Technical details

Initial infection vector

The threat actor commonly uses lures that are disguised as new updates to known third-party applications or popular system applications trusted by hundreds of users over the years.

In this campaign, the attackers used an executable disguised as an update package for SohuVA, which is a streaming app developed by Sohu Inc., a Chinese internet company. The malicious package, named sohuva_update_10.2.29.1-lup-s-tp.exe, clearly impersonates a real SohuVA update to deliver malware from the following resource, as indicated by our telemetry:

http://p2p.hd.sohu.com[.]cn/foxd/gz?file=sohunewplayer_7.0.22.1_03_29_13_13_union.exe&new=/66/157/ovztb0wktdmakeszwh2eha.exe

There is a possibility that the attackers used a DNS poisoning attack to alter the DNS response of p2p.hd.sohu.com[.]cn to an attacker-controlled server’s IP address, while the genuine update module of the SohuVA application tries to update its binaries located in appdata\roaming\shapp\7.0.18.0\package. Although we were unable to verify this at the time of analysis, we can make an educated guess, given that it is still unknown what triggered the update mechanism.

Furthermore, our analysis of the infection process has identified several additional campaigns pursued by the same group. For example, they utilized a fake updater for the iQIYI Video application, a popular platform for streaming Asian media content similar to SohuVA. This fake updater was dropped into the application’s installation folder and executed by the legitimate service qiyiservice.exe. Upon execution, the fake updater initiated malicious activity on the victim’s system, and we have identified that the same method is used for IObit Smart Defrag and Tencent QQ applications.

The initial loader was developed in C++ using the Windows Template Library (WTL). Its code bears a strong resemblance to Wizard97Test, a WTL sample application hosted on Microsoft’s GitHub. The attackers appear to have embedded malicious code within this project to effectively conceal their malicious intentions.

The loader first decrypts the encrypted configuration buffer by employing an XOR-based decryption algorithm:

for ( index = 0; index < v6; index = (index + 1) )
{
if ( index >= 5156 )
break;
mw_configindex ^= (&mw_deflated_config + (index & 3));
}

After decryption, it decompresses the LZMA-compressed buffer into the allocated buffer, and all of the configuration is exposed, including several components:

• Malware installation path: %ProgramData%\Microsoft\MF
• Resource domain: http://www.dictionary.com/
• Resource URI: image?id=115832434703699686&product=dict-homepage.png
• MgBot encrypted configuration

The malware also checks the name of the logged-in user in the system and performs actions accordingly. If the username is SYSTEM, the malware copies itself with a different name by appending the ext.exe suffix inside the current working directory. Then it uses the ShellExecuteW API to execute the newly created version. Notably, all relevant strings in the malware, such as SYSTEM and ext.exe, are encrypted, and the loader decrypts them with a specific XOR algorithm.

If the username is not SYSTEM, the malware first copies explorer.exe into %TEMP%, naming the instance as tmpX.tmp (where X is an incremented decimal number), and then deletes the original file. The purpose of this activity is unclear, but it consumes high system resources. Next, the loader decrypts the kernel32.dll and VirtualProtect strings to retrieve their base addresses by calling the GetProcAddress API. Afterwards, it uses a single-byte XOR key to decrypt the shellcode, which is 9556 bytes long, and stores it at the same address in the .data section. Since the .data section does not have execute permission, the malware uses the VirtualProtect API to set the permission for the section. This allows for the decrypted shellcode to be executed without alerting security products by allocating new memory blocks. Before executing the shellcode, the malware prepares a 16-byte-long parameter structure that contains several items, with the most important one being the address of the encrypted MgBot configuration buffer.

Multi-stage shellcode execution

As mentioned above, the loader follows a unique delivery scheme, which includes at least two stages of payload. The shellcode employs a hashing algorithm known as PJW to resolve Windows APIs at runtime in a stealthy manner.

unsigned int calc_PJWHash(_BYTE *a1)
{
unsigned int v2;
v2 = 0;
while ( *a1 )
{
v2 = *a1++ + 16 * v2;
if ( (v2 & 0xF0000000) != 0 )
v2 = ~(v2 & 0xF0000000) & (v2 ^ ((v2 & 0xF0000000) >> 24));
}
return v2;
}

The shellcode first searches for a specific DAT file in the malware’s primary installation directory. If it is found, the shellcode decrypts it using the CryptUnprotectData API, a Windows API that decrypts protected data into allocated heap memory, and ensures that the data can only be decrypted on the particular machine by design. After decryption, the shellcode deletes the file to avoid leaving any traces of the valuable part of the attack chain.

If, however, the DAT file is not present, the shellcode initiates the next-stage shellcode installation process. It involves retrieving encrypted data from a web source that is actually an attacker-controlled server, by employing a DNS poisoning attack. Our telemetry shows that the attackers successfully obtained the encrypted second-stage shellcode, disguised as a PNG file, from the legitimate website dictionary[.]com. However, upon further investigation, it was discovered that the IP address associated with dictionary[.]com had been manipulated through a DNS poisoning technique. As a result, victims’ systems were resolving the website to different attacker-controlled IP addresses depending on the victims’ geographical location and internet service provider.

To retrieve the second-stage shellcode, the first-stage shellcode uses the RtlGetVersion API to obtain the current Windows version number and then appends a predefined string to the HTTP header:

sec-ch-ua-platform: windows %d.%d.%d.%d.%d.%d

This implies that the attackers needed to be able to examine request headers and respond accordingly. We suspect that the attackers’ collection of the Windows version number and its inclusion in the request headers served a specific purpose, likely allowing them to target specific operating system versions and even tailor their payload to different operating systems. Given that the Evasive Panda threat actor has been known to use distinct implants for Windows (MgBot) and macOS (Macma) in previous campaigns, it is likely that the malware uses the retrieved OS version string to determine which implant to deploy. This enables the threat actor to adapt their attack to the victim’s specific operating system by assessing results on the server side.

From this point on, the first-stage shellcode proceeds to decrypt the retrieved payload with a XOR decryption algorithm:

key = *(mw_decryptedDataFromDatFile + 92);
index = 0;
if ( sz_shellcode )
{
mw_decryptedDataFromDatFile_1 = Heap;
do
{
*(index + mw_decryptedDataFromDatFile_1) ^= *(&key + (index & 3));
++index;
}
while ( index < sz_shellcode );
}

The shellcode uses a 4-byte XOR key, consistent with the one used in previous stages, to decrypt the new shellcode stored in the DAT file. It then creates a structure for the decrypted second-stage shellcode, similar to the first stage, including a partially decrypted configuration buffer and other relevant details.

Next, the shellcode resolves the VirtualProtect API to change the protection flag of the new shellcode buffer, allowing it to be executed with PAGE_EXECUTE_READWRITE permissions. The second-stage shellcode is then executed, with the structure passed as an argument. After the shellcode has finished running, its return value is checked to see if it matches 0x9980. Depending on the outcome, the shellcode will either terminate its own process or return control to the caller.

Although we were unable to retrieve the second-stage payload from the attackers’ web server during our analysis, we were able to capture and examine the next stage of the malware, which was to be executed afterwards. Our analysis suggests that the attackers may have used the CryptProtectData API during the execution of the second shellcode to encrypt the entire shellcode and store it as a DAT file in the malware’s main installation directory. This implies that the malware writes an encrypted DAT file to disk using the CryptProtectData API, which can then be decrypted and executed by the first-stage shellcode. Furthermore, it appears that the attacker attempted to generate a unique encrypted second shellcode file for each victim, which we believe is another technique used to evade detection and defense mechanisms in the attack chain.

Secondary loader

We identified a secondary loader, named libpython2.4.dll, which was disguised as a legitimate Windows library and used by the Evasive Panda group to achieve a stealthier loading mechanism. Notably, this malicious DLL loader relies on a legitimate, signed executable named evteng.exe (MD5: 1c36452c2dad8da95d460bee3bea365e), which is an older version of python.exe. This executable is a Python wrapper that normally imports the libpython2.4.dll library and calls the Py_Main function.

The secondary loader retrieves the full path of the current module (libpython2.4.dll) and writes it to a file named status.dat, located in C:\ProgramData\Microsoft\eHome, but only if a file with the same name does not already exist in that directory. We believe with a low-to-medium level of confidence that this action is intended to allow the attacker to potentially update the secondary loader in the future. This suggests that the attacker may be planning for future modifications or upgrades to the malware.

The malware proceeds to decrypt the next stage by reading the entire contents of C:\ProgramData\Microsoft\eHome\perf.dat. This file contains the previously downloaded and XOR-decrypted data from the attacker-controlled server, which was obtained through the DNS poisoning technique as described above. Notably, the implant downloads the payload several times and moves it between folders by renaming it. It appears that the attacker used a complex process to obtain this stage from a resource, where it was initially XOR-encrypted. The attacker then decrypted this stage with XOR and subsequently encrypted and saved it to perf.dat using a custom hybrid of Microsoft’s Data Protection Application Programming Interface (DPAPI) and the RC5 algorithm.

This custom encryption algorithm works as follows. The RC5 encryption key is itself encrypted using Microsoft’s DPAPI and stored in the first 16 bytes of perf.dat. The RC5-encrypted payload is then appended to the file, following the encrypted key. To decrypt the payload, the process is reversed: the encrypted RC5 key is first decrypted with DPAPI, and then used to decrypt the remaining contents of perf.dat, which contains the next-stage payload.

The attacker uses this approach to ensure that a crucial part of the attack chain is secured, and the encrypted data can only be decrypted on the specific system where the encryption was initially performed. This is because the DPAPI functions used to secure the RC5 key tie the decryption process to the individual system, making it difficult for the encrypted data to be accessed or decrypted elsewhere. This makes it more challenging for defenders to intercept and analyze the malicious payload.

After completing the decryption process, the secondary loader initiates the runtime injection method, which likely involves the use of a custom runtime DLL injector for the decrypted data. The injector first calls the DLL entry point and then searches for a specific export function named preload. Although we were unable to determine which encrypted module was decrypted and executed in memory due to a lack of available data on the attacker-controlled server, our telemetry reveals that an MgBot variant is injected into the legitimate svchost.exe process after the secondary loader is executed. Fortunately, this allowed us to analyze these implants further and gain additional insights into the attack, as well as reveal that the encrypted initial configuration was passed through the infection chain, ultimately leading to the execution of MgBot. The configuration file was decrypted with a single-byte XOR key, 0x58, and this would lead to the full exposure of the configuration.

Our analysis suggests that the configuration includes a campaign name, hardcoded C2 server IP addresses, and unknown bytes that may serve as encryption or decryption keys, although our confidence in this assessment is limited. Interestingly, some of the C2 server addresses have been in use for multiple years, indicating a potential long-term operation.

Victims

Our telemetry has detected victims in Türkiye, China, and India, with some systems remaining compromised for over a year. The attackers have shown remarkable persistence, sustaining the campaign for two years (from November 2022 to November 2024) according to our telemetry, which indicates a substantial investment of resources and dedication to the operation.

Attribution

The techniques, tactics, and procedures (TTPs) employed in this compromise indicate with high confidence that the Evasive Panda threat actor is responsible for the attack. Despite the development of a new loader, which has been added to their arsenal, the decade-old MgBot implant was still identified in the final stage of the attack with new elements in its configuration. Consistent with previous research conducted by several vendors in the industry, the Evasive Panda threat actor is known to commonly utilize various techniques, such as supply-chain compromise, Adversary-in-the-Middle attacks, and watering-hole attacks, which enable them to distribute their payloads without raising suspicion.

Conclusion

The Evasive Panda threat actor has once again showcased its advanced capabilities, evading security measures with new techniques and tools while maintaining long-term persistence in targeted systems. Our investigation suggests that the attackers are continually improving their tactics, and it is likely that other ongoing campaigns exist. The introduction of new loaders may precede further updates to their arsenal.

As for the AitM attack, we do not have any reliable sources on how the threat actor delivers the initial loader, and the process of poisoning DNS responses for legitimate websites, such as dictionary[.]com, is still unknown. However, we are considering two possible scenarios based on prior research and the characteristics of the threat actor: either the ISPs used by the victims were selectively targeted, and some kind of network implant was installed on edge devices, or one of the network devices of the victims — most likely a router or firewall appliance — was targeted for this purpose. However, it is difficult to make a precise statement, as this campaign requires further attention in terms of forensic investigation, both on the ISPs and the victims.

The configuration file’s numerous C2 server IP addresses indicate a deliberate effort to maintain control over infected systems running the MgBot implant. By using multiple C2 servers, the attacker aims to ensure prolonged persistence and prevents loss of control over compromised systems, suggesting a strategic approach to sustaining their operations.

Indicators of compromise

File Hashes
c340195696d13642ecf20fbe75461bed sohuva_update_10.2.29.1-lup-s-tp.exe
7973e0694ab6545a044a49ff101d412a libpython2.4.dll
9e72410d61eaa4f24e0719b34d7cad19 (MgBot implant)

File Paths
C:\ProgramData\Microsoft\MF
C:\ProgramData\Microsoft\eHome\status.dat
C:\ProgramData\Microsoft\eHome\perf.dat

URLs and IPs
60.28.124[.]21     (MgBot C2)
123.139.57[.]103   (MgBot C2)
140.205.220[.]98   (MgBot C2)
112.80.248[.]27    (MgBot C2)
116.213.178[.]11   (MgBot C2)
60.29.226[.]181    (MgBot C2)
58.68.255[.]45     (MgBot C2)
61.135.185[.]29    (MgBot C2)
103.27.110[.]232   (MgBot C2)
117.121.133[.]33   (MgBot C2)
139.84.170[.]230   (MgBot C2)
103.96.130[.]107   (AitM C2)
158.247.214[.]28   (AitM C2)
106.126.3[.]78     (AitM C2)
106.126.3[.]56     (AitM C2)

This report describes a phishing campaign in which attackers impersonate legitimate Google generated messages by abusing Google Cloud Application Integration to distribute malicious emails that appear to originate from trusted Google infrastructure. The emails mimic routine enterprise notifications such as voicemail alerts and file access or permission requests, making them appear normal and trustworthy to recipients. In this incident, attackers sent 9,394 phishing emails targeting approximately 3,200 customers over the past 14 days. All messages were sent from the legitimate Google address noreply-application-integration@google.com, which significantly increased their credibility and likelihood of reaching end users’ inboxes. Method of attack Based on […]

The post Phishing Campaign Leverages Trusted Google Cloud Automation Capabilities to Evade Detection appeared first on Check Point Blog.

Key Insights Insider recruitment is a growing cyber threat across banks, telecoms, and tech firms. Darknet ads offer payouts from $3,000 to $15,000 for access or data. Crypto exchanges, banks, and cloud providers are prime targets. Prevention requires employee education, strict access controls, and darknet monitoring. The Rise of Insider Recruitment in Cyber Crime Cyber criminals are no longer relying solely on brute force, social engineering, or exploiting vulnerabilities. Increasingly, they are recruiting insiders within organizations to gain access to corporate networks, user devices, and cloud environments. Across darknet forums, employees are being approached, or even volunteering, to sell access […]

The post Cyber Criminals Are Recruiting Insiders in Banks, Telecoms, and Tech appeared first on Check Point Blog.

An XLL is a native Windows DLL that Excel loads as an add-in, allowing it to execute arbitrary code through exported functions like xlAutoOpen. Since at least mid-2017, threat actors began abusing Microsoft Excel add-ins via the .XLL format, the earliest documented misuse is by the threat group APT10 (aka Stone Panda / Potassium) injecting backdoor payloads via XLLs. 

Since 2021, a growing number of commodity malware families and cyber-crime actors have added XLL-based delivery to their arsenals. Notable examples include Agent Tesla and Dridex, researchers observed an increase of these malware being dropped via malicious XLL add-ins.

Attackers typically embed their malicious code in the standard add-in export functions, such as xlAutoOpen. When a user enables the add-in in Excel, the malicious payload executes automatically, dropping or downloading a malicious payload. Some malware families use legitimate frameworks to create XLL (Excel Add-in) files. One common example is Excel-DNA, a popular open-source framework.

These frameworks make it easier for attackers to build and load malicious XLLs. In some cases, they also allow threat actors to pack and execute additional payloads directly in memory.

In late October 2025, a 64-bit DLL compiled as an XLL add-in was submitted to VirusTotal from two different countries. The first submission came from Ukraine on October 26, followed by three separate submissions from Russia beginning on October 27. The Russian-submitted samples were named Плановые цели противника.xll (“enemy’s planned targets”) and Плановые цели противника НЕ ЗАПУСКАТЬ.xll, which depending on context can mean either “Do NOT release the enemy’s planned targets” or “Do NOT activate the enemy’s scheduled targets.”

This DLL contains an embedded second-stage payload, a backdoor we named EchoGather. Once launched, the backdoor collects system information, communicates with a hardcoded command-and-control (C2) server, and supports command execution and file transfer operations. While it uses the XLL format for delivery, its execution chain and payload behavior differ from previously documented threats abusing Excel add-ins. Through pivoting on infrastructure and TTPs we were able to link this campaign to Paper Werewolf (aka GOFFEE), a group that has been targeting Russian organizations.

Explore how Intezer Forensic AI SOC eliminates alert noise so you can focus on real threats.

Technical analysis

Let’s dive in deeper.

What is an XLL?

An XLL is an Excel add-in implemented as a DLL that Excel loads directly, usually with the .xll extension. Microsoft explicitly describes XLL files as a DLL-style add-in that extends Excel with custom functions. 

When a user double clicks the file with the .xll extension, Excel is launched, loads the DLL and calls its exported functions such as xlAutoOpen, initialization code, or xlAutoClose, when unloading. Often malicious XLLs embed their payload inside xlAutoOpen or through a secondary loader, so that code runs immediately once Excel imports the DLL.

Excel XLL add-ins and macros differ mainly in how they execute and the level of control they provide an attacker. Macros, VBA or legacy XLM, run as scripts inside Excel’s macro engine and are constrained by Microsoft’s security model, which now includes blocking macros from the internet, signature requirements, and multiple user-facing warnings. XLLs, on the other hand, are compiled DLLs that Excel loads directly into its own process using LoadLibrary(), giving them the full power of native code without going through macro security checks. While macros rely on interpreted scripting and COM interactions, XLLs can call any Windows API, inject into other processes, or act as full-featured malware loaders. This makes XLLs far more capable and harder to analyze, and it may explain why some threat actors chose XLL-based delivery methods rather than macro-based.

Loader behavior

The DLL exports two functions, xlAutoOpen and xlAutoClose, both of which return zero. This behavior differs from that of legitimate XLL add-ins as well as from previously documented threats abusing the XLL format, such as those described in the most recent CERT-UA publication. In this case, the malicious logic is not tied to the typical export functions but instead is triggered through dllmain. The main function of the loader is called when fdwReason > 2 meaning that dllmain_dispatch was called with DLL_THREAD_DETACH (=3). Essentially the main function will be called when any thread in Excel that previously called into the XLL (even Excel’s own threads) exits.

Triggering the malicious payload during DLL_THREAD_DETACH helps the malware evade detection by delaying execution until a thread exits. This bypasses typical behavior-based detection, which focuses on early-stage activity like PROCESS_ATTACH, making the execution appear benign at first and allowing the second-stage payload to activate covertly after the sandbox times out or AV heuristics complete.

SHA-256: 0506a6fcee0d4bf731f1825484582180978995a8f9b84fc59b6e631f720915da

The embedded file is dropped as mswp.exe in %APPDATA%\Microsoft\Windows, then executed as a hidden process using CreateProcessW with CREATE_NO_WINDOW. Standard Output and Error is captured and redirected via anonymous pipes. If process creation succeeds, the function returns true otherwise, it cleans up and returns false.

The backdoor: EchoGather

We refer to this backdoor as EchoGather due to its focus on system reconnaissance and repeated beaconing behavior. 

SHA-256: 74fab6adc77307ef9767e710d97c885352763e68518b2109d860bb45e9d0a8eb

The dropped payload is a 64-bit backdoor with hardcoded configuration and C2 address. It collects system information and communicates with the C2 over HTTP(S) using the WinHTTP API.

The data collected by EchoGather consists of:

• IPv4 addresses
• OS type (“Windows”)
• Architecture
• NetBIOS name
• Username
• Workstation domain
• Process ID
• Executable path
• Static version string: 1.1.1.1

Next, EchoGather encodes that data using Base64 and sends it to the C2 using POST method. The C2 address is constructed from hardcoded strings. In the analyzed sample the C2 address was: https://fast-eda[.]my:443/dostavka/lavka/kategorii/zakuski/sushi/sety/skidki/regiony/msk/birylievo
This transmission occurs in an infinite loop with randomized sleep intervals between 300–360 seconds.

In all of its C2 communications, EchoGather uses the WinHTTP API. It supports various proxy configurations and is designed to ignore SSL/TLS certificate validation errors, allowing it to operate in environments with custom or misconfigured proxy and certificate settings.

Supported commands 

EchoGather supports four commands. 

All outgoing communication with the C2 is encoded using standard Base64. When a command is received from the C2 the first 36 bytes contain the request ID, it’s a unique identifier that is being used when the backdoor needs to send the information is several packages. 

0x54 Remote Command Execution

EchoGather first extracts the request ID, followed by the command that needs to be executed. It then decrypts the string cmd.exe /C %s using a hardcoded XOR key (0xCA), which serves as a template for command execution. Using this template, it executes the specified command via cmd.exe. The output of the command is captured through a pipe and sent back to the C2 server, with the request ID prepended to the response.

0x45 Return Configuration

Sends the embedded configuration structure to the C2.

0x56 File Exfiltration

The backdoor begins by extracting a request ID and the name of the file to be exfiltrated. It opens the specified file, determines its total size, and calculates how many 512 KB chunks are required for transmission. A transfer header containing metadata about the chunk count and size is then sent to the C2 server. In response, the backdoor receives the request ID used to identify the session. The file is read and transmitted in chunks, with each chunk containing the request ID, chunk index, file tag, data length, and raw file data. 

0x57 Remote File Write

EchoGather receives a filename from the C2 and writes the incoming data chunks to the system, reconstructing the file as the chunks arrive.

Infrastructure analysis

During our research we found two domains that were used by the threat actors.

IP Resolutions for fast-eda.my

• The domain was registered on September 12, 2025.
• The very first resolution was between September 12th and 14th, the domain was resolved to 199.59.243[.]228.
• After that and until November 26th all of the resolutions were on Cloudflare instances. 
• From September 18th to November 24th the domain was resolved to 172.64.80[.]1
• On November 27th it was resolved to 94.103.3[.]82 the address is connected to Russia based on geolocation.

When we looked up the related files to this domain on VirusTotal, we found 7 files.
Two of them are powershell scripts that load the backdoor: mswt.ps1 and the second one wasn’t submitted with a name.

The two scripts are identical, including their execution flow. Both first decode two Base64-encoded files: a PDF document and the EchoGather payload. The PDF is opened, while the payload is executed in the background. The document appears to be an invitation, written in Russian, to a concert for high-ranking officers. However, the PDF is AI-generated and contains several noticeable inconsistencies. For instance, the stamp in the lower right corner appears to be an AI-generated attempt at recreating Russia’s national emblem, the double-headed eagle, but the result resembles a distorted or bird-like figure rather than the intended symbol. The text also includes several errors. Some Cyrillic letters are incorrect, for example, the letter Д is used in place of Л in multiple instances, and the word праздиика is a misspelled version of праздника. Additionally, the phrase «с глубоким уважением приглашает» (translated as “with deep respect invites (you)”) is unnatural and not idiomatic in the context of formal Russian invitations.

IP Resolutions for ruzede.com

• First seen on 2025-05-21, resolved to 162.255.119[.]43 and later to 5.45.85[.]43 until October 2nd.
• On October 2nd it was resolved to IP addresses in Cloudflare.

• From October 4th to November 26th the domain was resolved to the same address seen in the previous domain: 172.64.80[.]1
• On November 26th it was resolved to 193.233.18[.]137 in Russia based on geolocation.
  • The ip address is linked to different malicious domains. 

Using VirusTotal, we pivoted on the domain ruzede[.]com, and we identified a RAR archive that exploits a known vulnerability, CVE-2025-8088, a vulnerability in WinRAR that involves the abuse of NTFS alternate data streams (ADSes) in combination with path traversal. This flaw allows attackers to embed malicious content within seemingly harmless filenames by appending ADSes that include relative path traversal sequences. 

The archive contains a file named Вх.письмо_Мипромторг.lnk:.._.._.._.._.._Roaming_Microsoft_Windows_run.bat 

When the archive is opened, WinRAR fails to properly sanitize these ADS paths and extracts the hidden data streams, placing them in unintended or sensitive locations such as %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup. 

The phrase “письмо Мипромторг” is misspelled; the correct form is “письмо Минпромторга.” This term refers to an official letter or communication issued by the Ministry of Industry and Trade of the Russian Federation (Минпромторг России). The same misspelling error is in the archive file name: Вх.письмо_Мипромторг.rar.

Essentially the file in the archive is a batch script that launches a hidden PowerShell process. This process navigates to a user-specific AppData directory, then downloads a PowerShell script named docc1.ps1 from a remote URL (https://2k-linep[.]com/upload/docc1.ps1) and saves it to the current working directory. The script is then executed via a new PowerShell instance with execution policy restrictions bypassed.

The downloaded script (docc1.ps1) extracts both a PDF file and an EchoGather payload, using a technique similar to the one described previously. However, in this instance, the embedded PDF differs from earlier samples. This document is allegedly sent from the deputy of the Ministry of Industry and Trade of the Russian Federation, asking for price justification documentation under the state defense order, focusing on violations of deadlines and reporting on pricing approval processes.

The companies listed with their emails on the top right side of the first page (Almaz-Antey, Shvabe, and the United Instrument-Making Corporation) are major Russian defense-industry and high-technology enterprises, and they might be the intended recipients of this decoy document.

The same vulnerability was used by several threat actors including RomCom (Russia-aligned) and Paper Werewolf, a cyberespionage group targeting Russian organizations and active since 2022. In early August, BI.ZONE Threat Intelligence published a report about an ongoing campaign of Paper Werewolf that exploits CVE-2025-6218, affects WinRAR versions up to and including 7.11 and enables directory traversal attacks that allow malicious archives to extract files outside their intended directories. A second zero-day, at the time, vulnerability that abuses ADSs for path traversal. The report doesn’t mention CVE-2025-8088, but based on the description we assume that is the same vulnerability.

The interesting part is that we can see similarities between the decoy documents from the report to the document above. First, the filename of the decoy document in the report is запрос Минпромторга РФ.pdf (Request of the Ministry of Industry and Trade of the Russian Federation.pdf) no misspellings in the filename. It refers to the same office. The document asks to assess the impact of a specific government resolution on production capacities of subsidy recipients. Next, both documents share the same template and structure: red stamp on the left side, followed by the same information about the office, the date and the request id. Both documents contain a request for information to be submitted to a government-affiliated organization.

Attribution

Based on the shared infrastructure, such as the ruzede[.]com domain, as well as notable similarities in decoy document construction and the exploitation of the WINRAR vulnerability that leverages ADSs, we attribute this campaign to the Paper Werewolf (aka GOFFEE) threat group. The recent use of XLL files suggests that the group is experimenting with new delivery methods while continuing to rely on established infrastructure, possibly in an attempt to evade detection. In addition, the use of a new, yet simple, backdoor may indicate an effort to improve and evolve their toolset.

Summary

It’s less common to see public reporting on threats targeting Russian organizations, which makes this campaign worth highlighting. The threat actor appears to be actively exploring new methods to evade detection, including the use of XLL-based delivery techniques and newly developed payloads. These changes suggest an effort to enhance their capabilities. However, there are still clear gaps in both technical execution and linguistic accuracy, indicating that their tradecraft is still developing. 

IOCs

XLL Loader

0506a6fcee0d4bf731f1825484582180978995a8f9b84fc59b6e631f720915da

EchoGather Hashes and C2 Infrastructure

sha256	C2 Address
c3e04bb4f4d51bb1ae8e67ce72aff1c3abeca84523ea7137379f06eb347e1669	https://ruzede[.]com/blogs/drafts/publish/schedule/seosso/login/mfa/verify/token/refresh/ips/blocklist/whitelist
0d1dd7a62f3ea0d0fbeea905a48ae8794f49319ee0c34f15a3a871899404bf05
b2419afcfc24955b4439100706858d7e7fc9fdf8af0bb03b70e13d8eed52935c	https://fast-eda.my/dostavka/lavka/kategorii/zakuski/sushi/sety/skidki/regiony/msk/birylievo
23d917781e288a6fa9a1296404682e6cf47f11f2a09b7e4f340501bf92d68514
dd5a16d0132eb38f64293b8419bab3a3a80f48dc050129a8752989539a5c97bf
74fab6adc77307ef9767e710d97c885352763e68518b2109d860bb45e9d0a8eb

Other Files

sha256	File name (based on VirusTotal)
b6914d702969bc92e8716ece92287c0f52fc129c6fb4796676a738b103a6e039	mswt.ps1
29101c580b33b77b51a6afe389955b151a4d0913716b253672cc0c0a41e5ccc8	N/A
cdc3355ae57cc371c6c0918c0b5451b9298fc7d7c7035fa4b24d0cd08af4122c	C:\Users\user\AppData\Roaming\Microsoft\Windows\docc1.ps1
dc2df351c306a314569b1eeaccf5046ce5a64df487fa51c907cb065e968bba80	Вх.письмо_Мипромторг.lnk:.._.._.._.._.._Roaming_Microsoft_Windows_run.bat
76e4d344b3ec52d3f1a81de235022ad2b983eb868b001b93e56deee54ae593c5	Вх.письмо_Мипромторг.rar
6a00b1ed5afcd63758b9be4bd1c870dbfe880a1a3d4e852bb05c92418d33e6da	invite.pdf
2abb9e7c155beaa3dcfa38682633dcbea42f07740385cac463e4ca5c6598b438	(pdf document)

Explore which AI SOC platform is right for you.

The post Tracing a Paper Werewolf campaign through AI-generated decoys and Excel XLLs appeared first on Intezer.

Introduction

If you’re a penetration tester, you know that lateral movement is becoming increasingly difficult, especially in well-defended environments. One common technique for remote command execution has been the use of DCOM objects.

Over the years, many different DCOM objects have been discovered. Some rely on native Windows components, others depend on third-party software such as Microsoft Office, and some are undocumented objects found through reverse engineering. While certain objects still work, others no longer function in newer versions of Windows.

This research presents a previously undescribed DCOM object that can be used for both command execution and potential persistence. This new technique abuses older initial access and persistence methods through Control Panel items.

First, we will discuss COM technology. After that, we will review the current state of the Impacket dcomexec script, focusing on objects that still function, and discuss potential fixes and improvements, then move on to techniques for enumerating objects on the system. Next, we will examine Control Panel items, how adversaries have used them for initial access and persistence, and how these items can be leveraged through a DCOM object to achieve command execution.

Finally, we will cover detection strategies to identify and respond to this type of activity.

COM/DCOM technology

What is COM?

COM stands for Component Object Model, a Microsoft technology that defines a binary standard for interoperability. It enables the creation of reusable software components that can interact at runtime without the need to compile COM libraries directly into an application.

These software components operate in a client–server model. A COM object exposes its functionality through one or more interfaces. An interface is essentially a collection of related member functions (methods).

COM also enables communication between processes running on the same machine by using local RPC (Remote Procedure Call) to handle cross-process communication.

Terms

To ensure a better understanding of its structure and functionality, let’s revise COM-related terminology.

1. COM interface
   A COM interface defines the functionality that a COM object exposes. Each COM interface is identified by a unique GUID known as the IID (Interface ID). All COM interfaces can be found in the Windows Registry under HKEY_CLASSES_ROOT\Interface, where they are organized by GUID.
2. COM class (COM CoClass)
   A COM class is the actual implementation of one or more COM interfaces. Like COM interfaces, classes are identified by unique GUIDs, but in this case the GUID is called the CLSID (Class ID). This GUID is used to locate the COM server and activate the corresponding COM class.

   All COM classes must be registered in the registry under HKEY_CLASSES_ROOT\CLSID, where each class’s GUID is stored. Under each GUID, you may find multiple subkeys that serve different purposes, such as:

   • InprocServer32/LocalServer32: Specifies the system path of the COM server where the class is defined. InprocServer32 is used for in-process servers (DLLs), while LocalServer32 is used for out-of-process servers (EXEs). We’ll describe this in more detail later.
   • ProgID: A human-readable name assigned to the COM class.
   • TypeLib: A binary description of the COM class (essentially documentation for the class).
   • AppID: Used to describe security configuration for the class.
3. COM server
   A COM is the module where a COM class is defined. The server can be implemented as an EXE, in which case it is called an out-of-process server, or as a DLL, in which case it is called an in-process server. Each COM server has a unique file path or location in the system. Information about COM servers is stored in the Windows Registry. The COM runtime uses the registry to locate the server and perform further actions. Registry entries for COM servers are located under the HKEY_CLASSES_ROOT root key for both 32- and 64-bit servers.

Client–server model

1. In-process server
   In the case of an in-process server, the server is implemented as a DLL. The client loads this DLL into its own address space and directly executes functions exposed by the COM object. This approach is efficient since both client and server run within the same process.
   

   In-process COM server

2. Out-of-process server
   Here, the server is implemented and compiled as an executable (EXE). Since the client cannot load an EXE into its address space, the server runs in its own process, separate from the client. Communication between the two processes is handled via ALPC (Advanced Local Procedure Call) ports, which serve as the RPC transport layer for COM.

What is DCOM?

DCOM is an extension of COM where the D stands for Distributed. It enables the client and server to reside on different machines. From the user’s perspective, there is no difference: DCOM provides an abstraction layer that makes both the client and the server appear as if they are on the same machine.

Under the hood, however, COM uses TCP as the RPC transport layer to enable communication across machines.

Certain requirements must be met to extend a COM object into a DCOM object. The most important one for our research is the presence of the AppID subkey in the registry, located under the COM CLSID entry.

The AppID value contains a GUID that maps to a corresponding key under HKEY_CLASSES_ROOT\AppID. Several subkeys may exist under this GUID. Two critical ones are:

• AccessPermission: controls access permissions.
• LaunchPermission: controls activation permissions.

These registry settings grant remote clients permissions to activate and interact with DCOM objects.

Lateral movement via DCOM

After attackers compromise a host, their next objective is often to compromise additional machines. This is what we call lateral movement. One common lateral movement technique is to achieve remote command execution on a target machine. There are many ways to do this, one of which involves abusing DCOM objects.

In recent years, many DCOM objects have been discovered. This research focuses on the objects exposed by the Impacket script dcomexec.py that can be used for command execution. More specifically, three exposed objects are used: ShellWindows, ShellBrowserWindow and MMC20.

1. ShellWindows
   ShellWindows was one of the first DCOM objects to be identified. It represents a collection of open shell windows and is hosted by explorer.exe, meaning any COM client communicates with that process.

   In Impacket’s dcomexec.py, once an instance of this COM object is created on a remote machine, the script provides a semi-interactive shell.

   Each time a user enters a command, the function exposed by the COM object is called. The command output is redirected to a file, which the script retrieves via SMB and displays back to simulate a regular shell.

   Internally, the script runs this command when connecting:

   cmd.exe /Q /c cd \ 1> \\127.0.0.1\ADMIN$\__17602 2>&1

   This sets the working directory to C:\ and redirects the output to the ADMIN$ share under the filename __17602. After that, the script checks whether the file exists; if it does, execution is considered successful and the output appears as if in a shell.

   When running dcomexec.py against Windows 10 and 11 using the ShellWindows object, the script hangs after confirming SMB connection initialization and printing the SMB banner. As I mentioned in my personal blog post, it appears that this DCOM object no longer has permission to write to the ADMIN$ share. A simple fix is to redirect the output to a directory the DCOM object can write to, such as the Temp folder. The Temp folder can then be accessed under the same ADMIN$ share. A small change in the code resolves the issue. For example:

   OUTPUT_FILENAME = 'Temp\\__' + str(time.time())[:5]

2. ShellBrowserWindow
   The ShellBrowserWindow object behaves almost identically to ShellWindows and exhibits the same behavior on Windows 10. The same workaround that we used for ShellWindows applies in this case. However, on Windows 11, this object no longer works for command execution.
3. MMC20
   The MMC20.Application COM object is the automation interface for Microsoft Management Console (MMC). It exposes methods and properties that allow MMC snap-ins to be automated.

   This object has historically worked across all Windows versions. Starting with Windows Server 2025, however, attempting to use it triggers a Defender alert, and execution is blocked.

   As shown in earlier examples, the dcomexec.py script writes the command output to a file under ADMIN$, with a filename that begins with __:

   OUTPUT_FILENAME = '__' + str(time.time())[:5]

   Defender appears to check for files written under ADMIN$ that start with __, and when it detects one, it blocks the process and alerts the user. A quick fix is to simply remove the double underscores from the output filename.

   Another way to bypass this issue is to use the same workaround used for ShellWindows – redirecting the output to the Temp folder. The table below outlines the status of these objects across different Windows versions.

   	Windows Server 2025	Windows Server 2022	Windows 11	Windows 10
   ShellWindows	Doesn’t work	Doesn’t work	Works but needs a fix	Works but needs a fix
   ShellBrowserWindow	Doesn’t work	Doesn’t work	Doesn’t work	Works but needs a fix
   MMC20	Detected by Defender	Works	Works	Works

Enumerating COM/DCOM objects

The first step to identifying which DCOM objects could be used for lateral movement is to enumerate them. By enumerating, I don’t just mean listing the objects. Enumeration involves:

• Finding objects and filtering specifically for DCOM objects.
• Identifying their interfaces.
• Inspecting the exposed functions.

Automating enumeration is difficult because most COM objects lack a type library (TypeLib). A TypeLib acts as documentation for an object: which interfaces it supports, which functions are exposed, and the definitions of those functions. Even when TypeLibs are available, manual inspection is often still required, as we will explain later.

There are several approaches to enumerating COM objects depending on their use cases. Next, we’ll describe the methods I used while conducting this research, taking into account both automated and manual methods.

1. Automation using PowerShell
   In PowerShell, you can use .NET to create and interact with DCOM objects. Objects can be created using either their ProgID or CLSID, after which you can call their functions (as shown in the figure below).
   

   Shell.Application COM object function list in PowerShell

   Under the hood, PowerShell checks whether the COM object has a TypeLib and implements the IDispatch interface. IDispatch enables late binding, which allows runtime dynamic object creation and function invocation. With these two conditions met, PowerShell can dynamically interact with COM objects at runtime.

   Our strategy looks like this:

   

   As you can see in the last box, we perform manual inspection to look for functions with names that could be of interest, such as Execute, Exec, Shell, etc. These names often indicate potential command execution capabilities.

   However, this approach has several limitations:

   • TypeLib requirement: Not all COM objects have a TypeLib, so many objects cannot be enumerated this way.
   • IDispatch requirement: Not all COM objects implement the IDispatch interface, which is required for PowerShell interaction.
   • Interface control: When you instantiate an object in PowerShell, you cannot choose which interface the instance will be tied to. If a COM class implements multiple interfaces, PowerShell will automatically select the one marked as [default] in the TypeLib. This means that other non-default interfaces, which may contain additional relevant functionality, such as command execution, could be overlooked.
2. Automation using C++
   As you might expect, C++ is one of the languages that natively supports COM clients. Using C++, you can create instances of COM objects and call their functions via header files that define the interfaces.However, with this approach, we are not necessarily interested in calling functions directly. Instead, the goal is to check whether a specific COM object supports certain interfaces. The reasoning is that many interfaces have been found to contain functions that can be abused for command execution or other purposes.

   This strategy primarily relies on an interface called IUnknown. All COM interfaces should inherit from this interface, and all COM classes should implement it.The IUnknown interface exposes three main functions. The most important is QueryInterface(), which is used to ask a COM object for a pointer to one of its interfaces.So, the strategy is to:

   • Enumerate COM classes in the system by reading CLSIDs under the HKEY_CLASSES_ROOT\CLSID key.
   • Check whether they support any known valuable interfaces. If they do, those classes may be leveraged for command execution or other useful functionality.

   This method has several advantages:

   • No TypeLib dependency: Unlike PowerShell, this approach does not require the COM object to have a TypeLib.
   • Use of IUnknown: In C++, you can use the QueryInterface function from the base IUnknown interface to check if a particular interface is supported by a COM class.
   • No need for interface definitions: Even without knowing the exact interface structure, you can obtain a pointer to its virtual function table (vtable), typically cast as a void*. This is enough to confirm the existence of the interface and potentially inspect it further.

   The figure below illustrates this strategy:

   

   This approach is good in terms of automation because it eliminates the need for manual inspection. However, we are still only checking well-known interfaces commonly used for lateral movement, while potentially missing others.

3. Manual inspection using open-source tools
   As you can see, automation can be difficult since it requires several prerequisites and, in many cases, still ends with a manual inspection. An alternative approach is manual inspection using a tool called OleViewDotNet, developed by James Forshaw. This tool allows you to:
   • List all COM classes in the system.
   • Create instances of those classes.
   • Check their supported interfaces.
   • Call specific functions.
   • Apply various filters for easier analysis.
   • Perform other inspection tasks.
   

   Open-source tool for inspecting COM interfaces

   One of the most valuable features of this tool is its naming visibility. OleViewDotNet extracts the names of interfaces and classes (when available) from the Windows Registry and displays them, along with any associated type libraries.

   This makes manual inspection easier, since you can analyze the names of classes, interfaces, or type libraries and correlate them with potentially interesting functionality, for example, functions that could lead to command execution or persistence techniques.

Control Panel items as attack surfaces

Control Panel items allow users to view and adjust their computer settings. These items are implemented as DLLs that export the CPlApplet function and typically have the .cpl extension. Control Panel items can also be executables, but our research will focus on DLLs only.

Attackers can abuse CPL files for initial access. When a user executes a malicious .cpl file (e.g., delivered via phishing), the system may be compromised – a technique mapped to MITRE ATT&CK T1218.002.

Adversaries may also modify the extensions of malicious DLLs to .cpl and register them in the corresponding locations in the registry.

• Under HKEY_CURRENT_USER:
  HKCU\Software\Microsoft\Windows\CurrentVersion\Control Panel\Cpls

• Under HKEY_LOCAL_MACHINE:
  • For 64-bit DLLs:
    HKLM\Software\Microsoft\Windows\CurrentVersion\Control Panel\Cpls
  • For 32-bit DLLs:
    HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Control Panel\Cpls

These locations are important when Control Panel DLLs need to be available to the current logged-in user or to all users on the machine. However, the “Control Panel” subkey and its “Cpls” subkey under HKCU should be created manually, unlike the “Control Panel” and “Cpls” subkeys under HKLM, which are created automatically by the operating system.

Once registered, the DLL (CPL file) will load every time the Control Panel is opened, enabling persistence on the victim’s system.

It’s worth noting that even DLLs that do not comply with the CPL specification, do not export CPlApplet, or do not have the .cpl extension can still be executed via their DllEntryPoint function if they are registered under the registry keys listed above.

There are multiple ways to execute Control Panel items:

• From cmd: control.exe [filename].cpl
• By double-clicking the .cpl file.

Both methods use rundll32.exe under the hood:

rundll32.exe shell32.dll,Control_RunDLL [filename].cpl

This calls the Control_RunDLL function from shell32.dll, passing the CPL file as an argument. Everything inside the CPlApplet function will then be executed.

However, if the CPL file has been registered in the registry as shown earlier, then every time the Control Panel is opened, the file is loaded into memory through the COM Surrogate process (dllhost.exe):

What happened was that a Control Panel with a COM client used a COM object to load these CPL files. We will talk about this COM object in more detail later.

The COM Surrogate process was designed to host COM server DLLs in a separate process rather than loading them directly into the client process’s address space. This isolation improves stability for the in-process server model. This hosting behavior can be configured for a COM object in the registry if you want a COM server DLL to run inside a separate process because, by default, it is loaded in the same process.

‘DCOMing’ through Control Panel items

While following the manual approach of enumerating COM/DCOM objects that could be useful for lateral movement, I came across a COM object called COpenControlPanel, which is exposed through shell32.dll and has the CLSID {06622D85-6856-4460-8DE1-A81921B41C4B}. This object exposes multiple interfaces, one of which is IOpenControlPanel with IID {D11AD862-66DE-4DF4-BF6C-1F5621996AF1}.

I immediately thought of its potential to compromise Control Panel items, so I wanted to check which functions were exposed by this interface. Unfortunately, neither the interface nor the COM class has a type library.

Normally, checking the interface definition would require reverse engineering, so at first, it looked like we needed to take a different research path. However, it turned out that the IOpenControlPanel interface is documented on MSDN, and according to the documentation, it exposes several functions. One of them, called Open, allows a specified Control Panel item to be opened using its name as the first argument.

Full type and function definitions are provided in the shobjidl_core.h Windows header file.

It’s worth noting that in newer versions of Windows (e.g., Windows Server 2025 and Windows 11), Microsoft has removed interface names from the registry, which means they can no longer be identified through OleViewDotNet.

Returning to the COpenControlPanel COM object, I found that the Open function can trigger a DLL to be loaded into memory if it has been registered in the registry. For the purposes of this research, I created a DLL that basically just spawns a message box which is defined under the DllEntryPoint function. I registered it under HKCU\Software\Microsoft\Windows\CurrentVersion\Control Panel\Cpls and then created a simple C++ COM client to call the Open function on this interface.

As expected, the DLL was loaded into memory. It was hosted in the same way that it would be if the Control Panel itself was opened: through the COM Surrogate process (dllhost.exe). Using Process Explorer, it was clear that dllhost.exe loaded my DLL while simultaneously hosting the COpenControlPanel object along with other COM objects.

Based on my testing, I made the following observations:

1. The DLL that needs to be registered does not necessarily have to be a .cpl file; any DLL with a valid entry point will be loaded.
2. The Open() function accepts the name of a Control Panel item as its first argument. However, it appears that even if a random string is supplied, it still causes all DLLs registered in the relevant registry location to be loaded into memory.

Now, what if we could trigger this COM object remotely? In other words, what if it is not just a COM object but also a DCOM object? To verify this, we checked the AppID of the COpenControlPanel object using OleViewDotNet.

Both the launch and access permissions are empty, which means the object will follow the system’s default DCOM security policy. By default, members of the Administrators group are allowed to launch and access the DCOM object.

Based on this, we can build a remote strategy. First, upload the “malicious” DLL, then use the Remote Registry service to register it in the appropriate registry location. Finally, use a trigger acting as a DCOM client to remotely invoke the Open() function, causing our DLL to be loaded. The diagram below illustrates the flow of this approach.

The trigger can be written in either C++ or Python, for example, using Impacket. I chose Python because of its flexibility. The trigger itself is straightforward: we define the DCOM class, the interface, and the function to call. The full code example can be found here.

Once the trigger runs, the behavior will be the same as when executing the COM client locally: our DLL will be loaded through the COM Surrogate process (dllhost.exe).

As you can see, this technique not only achieves command execution but also provides persistence. It can be triggered in two ways: when a user opens the Control Panel or remotely at any time via DCOM.

Detection

The first step in detecting such activity is to check whether any Control Panel items have been registered under the following registry paths:

• HKCU\Software\Microsoft\Windows\CurrentVersion\Control Panel\Cpls
• HKLM\Software\Microsoft\Windows\CurrentVersion\Control Panel\Cpls
• HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Control Panel\Cpls

Although commonly known best practices and research papers regarding Windows security advise monitoring only the first subkey, for thorough coverage it is important to monitor all of the above.

In addition, monitoring dllhost.exe (COM Surrogate) for unusual COM objects such as COpenControlPanel can provide indicators of malicious activity.
Finally, it is always recommended to monitor Remote Registry usage because it is commonly abused in many types of attacks, not just in this scenario.

Conclusion

In conclusion, I hope this research has clarified yet another attack vector and emphasized the importance of implementing hardening practices. Below are a few closing points for security researchers to take into account:

• As shown, DCOM represents a large attack surface. Windows exposes many DCOM classes, a significant number of which lack type libraries – meaning reverse engineering can reveal additional classes that may be abused for lateral movement.
• Changing registry values to register malicious CPLs is not good practice from a red teaming ethics perspective. Defender products tend to monitor common persistence paths, but Control Panel applets can be registered in multiple registry locations, so there is always a gap that can be exploited.
• Bitness also matters. On x64 systems, loading a 32-bit DLL will spawn a 32-bit COM Surrogate process (dllhost.exe *32). This is unusual on 64-bit hosts and therefore serves as a useful detection signal for defenders and an interesting red flag for red teamers to consider.