The Feed 2025-03-26

alt text

AI Generated Podcast

https://open.spotify.com/episode/6kd9OWrE7Rp2mqGed2Qyqz?si=FWp33OJQTnuZ-C3LktzUhw

Summarized Stories

IngressNightmare: 9.8 Critical Unauthenticated Remote Code Execution Vulnerabilities in Ingress NGINX

Summary

Wiz Research has identified a series of critical unauthenticated Remote Code Execution (RCE) vulnerabilities in the Ingress NGINX Controller for Kubernetes, collectively dubbed IngressNightmare. These vulnerabilities, tracked as CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, and CVE-2025-1974, could allow attackers to gain unauthorized access to all secrets stored across all namespaces within a Kubernetes cluster, potentially leading to a complete cluster takeover. The most severe of these vulnerabilities have a CVSS v3.1 base score of 9.8. The attack vector targets the admission controller component of Ingress NGINX, which is often accessible over the network without authentication. Wiz Research estimates that approximately 43% of cloud environments are vulnerable, identifying over 6,500 publicly exposed vulnerable Kubernetes ingress controllers, including those belonging to Fortune 500 companies. Organizations using Ingress NGINX Controller for Kubernetes are urged to patch to the latest versions immediately and ensure their admission webhook endpoints are not exposed externally. The vulnerabilities stem from the improper sanitization of input during the NGINX configuration generation and validation phase within the admission controller. Successful exploitation involves injecting arbitrary NGINX configurations by sending malicious ingress objects to the admission controller, leading to code execution within the Ingress NGINX Controller’s pod.

Technical Details

alt text

The Ingress NGINX Controller for Kubernetes acts as an ingress controller, routing external traffic to the appropriate Kubernetes Services based on defined rules. It utilizes the popular NGINX reverse proxy. A key component is the admission controller, deployed within the Ingress NGINX pod, which validates incoming ingress objects before deployment. By default, this admission controller is accessible over the network without authentication.

The core vulnerability lies in how the admission controller processes incoming ingress objects. It constructs a temporary NGINX configuration based on these objects and validates it using the nginx -t command. Wiz Research discovered multiple vulnerabilities in this validation phase that allow for the injection of arbitrary NGINX configurations by sending specially crafted ingress objects directly to the admission controller.

Specifically, the research identified several injection points within the annotation parsers:

  • CVE-2025-24514 – auth-url Annotation Injection: The authreq parser, responsible for handling authentication-related annotations, specifically the auth-url field, incorporates the URL provided in this annotation into the temporary NGINX configuration without proper sanitization. This lack of sanitization allows an attacker to inject arbitrary NGINX directives that are evaluated when nginx -t is executed. This vulnerability is addressed in version 1.12.0 and later due to the introduction of stricter regex validation for annotations.

  • CVE-2025-1097 – auth-tls-match-cn Annotation Injection: The authtls parser, handling the auth-tls-match-cn annotation, uses the CommonNameAnnotationValidator. While this validator requires the value to start with CN= and the remaining characters to form a valid regular expression, researchers found a way to bypass these requirements to inject arbitrary NGINX configurations. The value of this annotation ($server.CertificateAuth.MatchCN) is inserted into the NGINX configuration template. Exploitation also requires providing the nginx.ingress.kubernetes.io/auth-tls-secret annotation, which refers to a TLS certificate or keypair secret within the cluster. The Ingress NGINX service account’s access to all secrets allows an attacker to specify any appropriately formatted secret, including default secrets present in many managed Kubernetes solutions.

  • CVE-2025-1098 – mirror UID Injection: The mirror annotation parser processes the UID from the ingress object and inserts it into $location.Mirror.Source in the temporary NGINX configuration. Since the UID (ing.UID) is not a Kubernetes annotation, the input is not subject to the annotation regex rules, allowing for direct injection of arbitrary NGINX configuration directives.

These configuration injection vulnerabilities (CVE-2025-24514, CVE-2025-1097, CVE-2025-1098) alone do not directly lead to code execution; they allow the injection of arbitrary NGINX directives that are then tested by nginx -t.

The final critical vulnerability, CVE-2025-1974 - NGINX Configuration Code Execution, allows for Remote Code Execution by leveraging the injected NGINX directives. The researchers discovered that the ssl_engine directive, part of the OpenSSL module included in Ingress NGINX, can load shared libraries at any point within the configuration file, unlike the load_module directive which must appear at the beginning.

To exploit this fully, an attacker needs to place a shared library on the Ingress NGINX Controller’s pod filesystem. This can be achieved by abusing the NGINX client body buffering feature. When an HTTP request body exceeds the default 8KB threshold, NGINX saves it to a temporary file. Although the file is immediately deleted, NGINX retains an open file descriptor to it, accessible via ProcFS. By sending a large HTTP request with a Content-Length header larger than the actual content, the NGINX process will hang, keeping the file descriptor open for an extended period. Since the Ingress NGINX Controller pod typically runs a minimal number of processes, an attacker can relatively easily guess the PID and file descriptor number to locate the uploaded shared library.

The complete exploit chain involves:

  1. Uploading a malicious payload as a shared library to the pod by exploiting NGINX’s client-body buffer feature.
  2. Sending a crafted AdmissionReview request to the Ingress NGINX Controller’s admission controller, containing one of the directive injection payloads (CVE-2025-24514, CVE-2025-1097, or CVE-2025-1098).
  3. The injected directive is ssl_engine, which is used to load the uploaded shared library by specifying its ProcFS path using the guessed PID and file descriptor.
  4. Successful loading of the shared library results in arbitrary code execution on the Ingress NGINX Controller’s pod, granting access to all cluster secrets due to the pod’s elevated privileges.

The researchers used kube-review to create admission review requests from Ingress resource manifests for testing purposes.

Industries

The report mentions that over 6,500 vulnerable clusters were uncovered, including those belonging to Fortune 500 companies, indicating that a wide range of industries are potentially affected.

Recommendations

  • Update to the latest version of Ingress NGINX Controller, specifically versions 1.12.1 and 1.11.5, as these versions contain fixes for the identified vulnerabilities.
  • Ensure the admission webhook endpoint is not exposed externally. Use network policies to restrict access so that only the Kubernetes API Server can access the admission controller.
  • If immediate upgrade is not possible, consider these temporary mitigations:
    • Enforce strict network policies to allow only the Kubernetes API Server to access the admission controller.
    • Temporarily disable the admission controller component of Ingress-NGINX.
      • For Helm installations, reinstall with controller.admissionWebhooks.enabled=false.
      • For manual installations, delete the ValidatingWebhookConfiguration called ingress-nginx-admission and remove the --validating-webhook argument from the ingress-nginx-controller container’s Deployment or DaemonSet.
  • Re-enable the Validating Admission Controller after upgrading, as it provides important safeguards for Ingress configurations.

Hunting methods

  • Check if your clusters are using ingress-nginx by running the following kubectl command with at least cluster-scoped read-only permissions: 
    kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

    This command will list all pods across all namespaces that have the label app.kubernetes.io/name=ingress-nginx, indicating the presence of Ingress NGINX Controller.

  • Use the provided Nuclei template to check for exposed Ingress-NGINX admission controllers. The report does not include the template itself, but its purpose is to identify instances where the admission webhook endpoint is publicly accessible.

  • Wiz customers can utilize the pre-built query and advisory in the Wiz Threat Center and the Wiz Dynamic Scanner for validation of exposed admission controllers. The Wiz Runtime Sensor can also detect zero-day vulnerabilities like IngressNightmare by monitoring ingress traffic, capturing malicious admission review requests in real-time, and flagging anomalous library loads.

IOC

This report focuses on vulnerabilities within the Ingress NGINX Controller software and does not provide traditional Indicators of Compromise (IOCs) such as IP addresses, domains, or file hashes associated with specific attack campaigns.

However, potential indicators for identifying vulnerable or potentially compromised environments include:

  • Running versions of Ingress NGINX Controller prior to 1.12.1 or 1.11.5.
  • Network configurations that expose the Ingress NGINX admission controller (port 8443 by default) to external networks or internal networks beyond the Kubernetes API server.
  • Anomalous HTTP requests being sent to the Ingress NGINX admission controller endpoint (typically /admission) from unexpected sources within the cluster network.
  • Unexpected creation or modification of NGINX configuration files within the Ingress NGINX Controller pod.
  • Anomalous loading of shared libraries within the Ingress NGINX Controller process.

Original link: https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities

CVE-2025-26633: How Water Gamayun Weaponizes MUIPath using MSC EvilTwin

Summary

Trend Research has identified a campaign by the suspected Russian threat actor Water Gamayun, also known as EncryptHub and Larva-208, that exploits a zero-day vulnerability in the Microsoft Management Console (MMC) framework, tracked as CVE-2025-26633 and named MSC EvilTwin. This vulnerability allows attackers to execute malicious code and potentially exfiltrate data from infected systems. The attack involves manipulating .msc files and abusing the Multilingual User Interface Path (MUIPath) feature to load and execute malicious payloads, establish persistence, and steal sensitive information. Enterprises that heavily utilize Microsoft’s administrative tools are at significant risk of data breaches and financial losses from this campaign. Microsoft and Trend Zero Day Initiative’s™ (ZDI) bug bounty program collaborated to disclose and patch this vulnerability. Trend Micro has also released protections for its customers. This campaign is under active development and employs multiple delivery methods and custom payloads.

Technical Details

The Water Gamayun campaign leverages a technique called MSC EvilTwin (CVE-2025-26633), which abuses the Microsoft Management Console (MMC) framework (mmc.exe). The MMC is a GUI and programming framework for creating and managing administrative tools called snap-ins, which are often accessed through Microsoft console files (.msc).

The MSC EvilTwin technique involves creating two .msc files with the same name: a clean, legitimate version and a malicious version. The malicious file is placed in a subdirectory named en-US within the same location as the clean file. This leverages the mmc.exe’s Multilingual User Interface Path (MUIPath) feature. The default system language, English (United States), uses MUI files (.mui) for language-specific resources. When a clean .msc file is executed, mmc.exe checks for a corresponding .msc file in the en-US subdirectory defined by the MUIPath. If found, mmc.exe loads and executes the malicious file from the en-US directory instead of the intended original file, without the user’s knowledge. This is demonstrated in the provided code snippet from mmc.exe, where the ScOnOpenDocument function calls scGetMuiPath to retrieve the MUI file.

The campaign also employs other techniques facilitated by the compromised .msc files:

  • Executing shell commands over MSC file web rendering: This technique abuses the ExecuteShellCommand method of the MMC’s View Object. The View Object serves as an external object when an MMC snap-in hosts Microsoft Internet Explorer components. By crafting malicious .msc files with an ActiveX control (Shockwave Flash Object), attackers can embed a script tag (<script>external.ExecuteShellCommand(...)</script>) in an HTML page loaded within the MMC. This allows for the execution of arbitrary shell commands on the victim’s machine. Figure 6 shows an example where this is used to download and execute a next-stage payload.
  • Mock trusted directories method: This technique involves creating fake directories that resemble legitimate system paths by adding trailing spaces or special characters (e.g., C:\Windows \System32). If an application’s path validation doesn’t properly handle whitespace, it might load files from the mocked directory instead of the actual system directory. The MSC EvilTwin loader utilizes this method to drop the malicious WmiMgmt.msc file in C:\Windows \System32\en-US.

The MSC EvilTwin loader is a PowerShell trojan loader that weaponizes all three techniques. The attack typically begins with a digitally-signed MSI file, masquerading as popular Chinese software like DingTalk or QQTalk, which fetches and executes the MSC EvilTwin loader from the attacker’s command-and-control (C&C) server.

The loader contains two Base64-encoded blobs: $originalConsole (a legitimate .msc file) and $hackedConsole (a malicious .msc file containing the attacker’s C&C server address). The loader first creates the mock directories C:\Windows \System32 and C:\Windows \System32\en-US. It then decodes and writes the contents of the original WmiMgmt.msc to C:\Windows \System32\ and the hacked WmiMgmt.msc to C:\Windows \System32\en-US\. In the malicious WmiMgmt.msc file, it replaces a placeholder {htmlLoaderUrl} with the attacker’s C&C server URL: hxxps://82[.]115.223.182/encrypthub/ram/.

Finally, the loader executes the legitimate WmiMgmt.msc from C:\Windows\System32\, which triggers the EvilTwin technique, causing mmc.exe to load and execute the malicious WmiMgmt.msc from the en-US directory. This malicious file contains the C&C URL in its StringTable section and uses the ActiveX Control snap-in to load Internet Explorer components within mmc.exe. The embedded HTML then uses the external.ExecuteShellCommand method to download and execute further payloads, such as ram.ps1, the Rhadamanthys stealer downloader.

The Water Gamayun group also uses these techniques in other modules, including:

  • EncryptHub stealer
  • DarkWisp backdoor
  • SilentPrism backdoor
  • Stealc
  • Rhadamanthys stealer

Countries

The report does not explicitly state the targeted countries, but it identifies the threat actor as suspected Russian.

Industries

The report mentions that various businesses, particularly those that use Microsoft’s administrative tools heavily, may be at risk.

Recommendations

  • Apply the patch released by Microsoft to address the CVE-2025-26633 vulnerability.
  • Enterprises need comprehensive cybersecurity solutions with a layered approach and advanced capabilities to combat these evolving threats.
  • Organizations can protect themselves with Trend Vision One™, an AI-powered enterprise cybersecurity platform offering centralized cyber risk exposure management, security operations, and layered protection.
  • Trend Micro customers should ensure their Trend Vision One™ - Network Security (TippingPoint Intrusion Prevention Filters) are up to date with the following filters:
    • 45359: TCP: Backdoor.Shell.DarkWisp.A Runtime Detection
    • 45360: HTTP: Trojan.Shell.EncryptHubStealer.B Runtime Detection
    • 45361: HTTP: Backdoor.Shell.SilentPrism.A Runtime Detection
    • 45594: HTTP: Trojan.Shell.EncryptHubStealer.B Runtime Detection (Notification Request)
    • 45595: HTTP: Trojan.Shell.MSCEvilTwin.A Runtime Detection (Payload - Server Response)
  • Trend Micro customers should leverage Trend Vision One Threat Intelligence for information on threat actors and their techniques to take proactive steps.
  • Utilize the Trend Vision One Intelligence Reports App for IOC sweeping related to ZDI-CAN-26371 (CVE-2025-26633).

Hunting methods

Trend Vision One customers can use the Search App to hunt for malicious indicators:

  • Monitor for network connections to the suspicious C&C IP: 
    eventId:3 AND eventSubId:204 AND (dst:"82.115.223.182")

    Logic: This query searches for network connection events (eventId:3, eventSubId:204) where the destination IP address (dst) is the identified C&C server IP.

  • Look for processes (mmc.exe) executing .msc files from unusual paths: 
    eventSubId:2 AND processFilePath:"*\mmc.exe" AND processFilePath:"*\powershell.exe" AND objectFilePath:"C:\\Windows \System32\*.msc"

    Logic: This query looks for process execution events (eventSubId:2) involving mmc.exe and powershell.exe where an .msc file is being accessed (objectFilePath) from the non-standard directory C:\\Windows \System32\, which uses a trailing space, indicative of the mock trusted directories technique.

More hunting queries may be available for Trend Vision One customers with Threat Insights Entitlement enabled.

IOC

IP Addresses

82.115.223.182

Domains

encrypthub/ram/ (path on the IP address)

File Hashes (SHA256)

80055590cf6573c6ef381c9b834c35c1a5e7463aedbcf4b5427a903f1e588c50 (mmc.exe)
5588d1c5901d61bb09cd2fc86d523e2ccbc35a0565fd63c73b62757ac2ee51f5 (digitally-signed MSI loader)

Original link: https://www.trendmicro.com/en_us/research/25/c/cve-2025-26633-water-gamayun.html

Weaver Ant, the Web Shell Whisperer: Tracking a Live China-nexus Operation

Summary

Sygnia investigated a sustained cyber espionage operation targeting a major telecommunication company in Asia, attributed to a China-nexus threat actor tracked as Weaver Ant. The primary objective of this group was to gain and maintain continuous access to telecommunication providers to facilitate cyber espionage and collect sensitive information. Weaver Ant heavily relied on web shells and web shell tunneling for persistence and lateral movement. The investigation uncovered the deployment of various web shell variants, including encrypted China Chopper and a custom ‘INMemory’ web shell. The threat actor exhibited advanced evasion techniques, including in-memory execution, ETW and AMSI patching, and the use of “PowerShell without PowerShell”. Weaver Ant demonstrated significant persistence, remaining active within the compromised network for over four years despite multiple remediation attempts. The threat actor utilized an Operational Relay Box (ORB) network consisting of compromised Zyxel routers to proxy traffic and conceal their infrastructure. Following the investigation, a coordinated eradication effort was conducted, but renewed activity from Weaver Ant was subsequently detected.

Technical Details

alt text

alt text

The Weaver Ant operation highlights a sophisticated and persistent threat targeting the telecommunications sector. Their modus operandi centered around the extensive use of web shells for gaining initial access, maintaining persistence, enabling remote code execution, and facilitating lateral movement via an intricate tunneling process.

Web Shells: The investigation identified two primary types of web shells, each with multiple variants:

  • Encrypted China Chopper: This was the most common web shell used, supporting AES encryption of the payload. Despite its simplicity, the encryption effectively bypassed automated payload detection at the Web Application Firewall (WAF) level. These web shells were deployed primarily on externally facing servers in various programming languages such as ASPX and PHP. The compromised servers acted as entry points into the victim’s network. The threat actor employed keyword-based evasion (using parameter names like ‘password’, ‘key’, ‘pass’) and exploited payload truncation due to WAF character limits to obscure their activities in logs. Figures 1 and 2 show examples of the ASPX and PHP versions with encryption.
  • ‘INMemory’ Web Shell: This custom web shell enabled in-memory execution of malicious modules to evade detection. It functioned by decoding a hardcoded GZipped Base64 string into a Portable Executable (PE) named ‘eval.dll’ and executing it entirely in memory. This involved decoding the Base64 string, creating memory streams, decompressing the data, loading the byte array using ‘Assembly.Load’, and executing the payload without writing it to disk. The web shell also obfuscated code using Base64-encoded strings, with a function called ‘invoke’ executed using decoded strings like ‘EVAL.Handler’ and ‘Invoke’. Figure 3 shows an example of the ASPX version. The ‘INMemory’ web shell executed C# code from ‘eval.dll’, which ran the payload delivered via HTTP requests. The ‘Invoke’ function within ‘eval.dll’ performed SHA256 hash matching on HTTP request headers against a hardcoded value. If a match was found, the content underwent two-stage encoding (Base64 and then UTF-8) before being executed using ‘JScriptEvaluate’ from the JScript library. The VSA Engine (Visual Studio for Applications Engine) facilitated just-in-time (JIT) compilation and execution of code at runtime. Figure 4 shows the ‘SHA256_hash’ function, and Figure 5 illustrates the payload encoding and execution.

Web Shell Tunneling: Weaver Ant utilized web shell tunneling, leveraging multiple web shells as ‘proxy servers’ to redirect inbound HTTP traffic to other web shells on different hosts, facilitating lateral movement within different network segments (typically internal servers not directly connected to the internet) using publicly accessible servers as gateways. This allowed them to operate without deploying additional tools on compromised hosts, using HTTP/S traffic to appear legitimate. The traffic was often encrypted, necessitating port mirroring and automated decryption to analyze the tunneled data. The threat actor employed a recursive HTTP tunnel tool, acting as a ‘second stage’ web shell, to access internal resources by forwarding requests to other web servers, supporting both ASPX and PHP versions. This tool decrypted an encrypted payload, decoded parameters (‘p1’, ‘p2’), parsed them to reconstruct HTTP requests or cURL commands, dynamically built and executed payloads, and returned the server’s response. Figure 6 shows a code snippet from the PHP variant. The layered encryption and obfuscation of payloads were likened to a ‘Matryoshka’ doll, requiring each layer to be peeled back to reveal the next.

Defense Evasion Techniques:

  • In-memory execution of malicious modules.
  • Patching Event Tracing for Windows (ETW) processes to suppress or dismiss critical logs, including Sysmon logs.
  • Bypassing Antimalware Scan Interface (AMSI) by overwriting the ‘AmsiScanBuffer’ function in ‘amsi.dll’, rendering AMSI integrations ineffective.
  • Executing PowerShell commands without initiating the PowerShell.exe process by leveraging the ‘System.Management.Automation.dll’ module. This allowed them to use PowerShell modules like ‘Invoke-SMBClient’ for reconnaissance and lateral movement without triggering typical PowerShell monitoring.

Lateral Movement and Reconnaissance:

  • Utilized ‘Invoke-SMBClient’ with valid credentials (NTLM hashes of high-privileged local or domain accounts with long-standing passwords) to interact with SMB shares, deploy web shells on additional servers, and expand persistence. Figure 8 illustrates the web shell deployment chain.
  • Retrieved web server access logs and configuration files (e.g., ‘web.config’, ‘applicationHost.config’) from remote IIS web servers to harvest credentials and understand server operations.
  • Executed various ‘Invoke-SharpView’ commands against multiple Domain Controllers to enumerate the Active Directory environment, identify high-privilege accounts and critical servers (‘Get-DomainUserEvent’, ‘Get-DomainSubnet’, ‘Get-DomainUser’, ‘Get-NetSession’, ‘Get-NetComputer’). Command outputs were often saved under ‘C:\ProgramData’, compressed using the ‘Invoke-ZIP’ PowerShell function, and then exfiltrated. Figure 9 shows a code snippet from a PowerShell transcript log.

Infrastructure: Weaver Ant utilized a non-provisioned Operational Relay Box (ORB) network to proxy traffic and conceal their infrastructure. This network primarily consisted of compromised Zyxel CPE routers (mostly with firmware version VMG3625-T20A) operated by Southeast Asian telecommunication providers.

Attribution: Weaver Ant exhibits characteristics typical of a China-nexus targeted threat group, including target selection aligning with China’s cyber strategy, clear goals, a wide reliance on China Chopper variants, activity primarily within the GMT +8 time zone during working days, and the use of ORB networks. They also employed a backdoor previously linked to Chinese APT groups. The sharing of tools and infrastructure among China-nexus intrusion sets complicates definitive attribution.

Countries

Targeted countries were not explicitly stated but the targeted organization was a major telecommunication company in Asia.

Industries

The targeted industry was telecommunications.

Recommendations

  • Enable IIS logging and ingest it into the SIEM, with X-Forwarded-For (XFF) headers configured.
    • Monitor for any disruptions or stoppages in log ingestion.
  • Monitor for web pages creation by web server processes (i.e., ‘w3wp.exe’, ‘tomcat6.exe’).
  • Monitor for command execution originating from web server processes (i.e., ‘w3wp.exe’, ‘tomcat6.exe’).
  • Monitor for incoming HTTP requests with unusually large payloads in the request’s body.
  • Monitor for unexpected parameters names or values in incoming HTTP requests.
  • Enable PowerShell transcript logging to capture and analyze suspicious activity.
  • Minimize Privileges: Restrict web-service accounts to the least privileges required.
  • Control Management Traffic: Use ACLs and firewall rules to limit management traffic between web servers and internal systems, especially for SMB and HTTP/S.
  • Enforce Credential Hygiene: Implement LAPS, gMSA, or a PIM solution to regularly rotate credentials.
  • Enhance Detection: Deploy EDR/XDR solutions to monitor memory for malicious activity, including obfuscated in-memory web shells.
  • Strengthen Web Security: Tune WAF and logging systems to detect obfuscated code signatures and behavioral patterns linked to China Chopper and INMemory web shells.

Hunting methods

  • Monitor network traffic for connections originating from or destined to Southeast Asian telecommunication provider IP ranges, particularly those associated with Zyxel VMG3625-T20A routers, keeping in mind their use as an ORB network.
  • Implement network-based detection rules to identify patterns associated with encrypted web shell traffic, such as unusual HTTP POST requests with Base64 encoded or seemingly random encrypted data.
  • Correlate web server logs with network traffic to identify suspicious POST requests and the subsequent server responses. Look for large POST bodies and unusual user-agent strings.
  • Develop YARA rules to detect the file characteristics and code snippets of known China Chopper variants (including the encrypted versions) and the ‘INMemory’ web shell. Focus on unique code structures, encryption routines, and hardcoded strings.
  • Monitor for the creation of new ASPX, PHP, or other web-executable files in web server directories, especially if created by web server processes.
  • Analyze PowerShell transcript logs for the execution of reconnaissance commands associated with ‘Invoke-SharpView’ (e.g., Get-NetComputer, Get-DomainUser) and lateral movement tools like ‘Invoke-SMBClient’. Look for commands executed outside of regular administrator activity.
  • Detect processes injecting code into ‘mmc.exe’ or other legitimate system processes, which could be indicative of malicious web shell activity or in-memory payload execution.
  • Monitor for modifications to ETW and AMSI related DLLs or registry keys, which could indicate attempts to disable security logging and antimalware scanning.

IOC

Hashes (SHA1)

23c4049121a9649682b3b901eaac0cc52c308756
9022f78087e1679035e09160d59d679dc3ac345d
be52275b0c2086735dac478dc4f09fd16031669a
c879a8eb6630b0cd7537b068f4e9af2c9ca08a62
25a593b9517d6c325598eab46833003c40f9491a
a9bbea73504139ce91a0ec20fef303c68a131cd4
334a88e288ae18c6e3fd7fb2d1ad9548497d52ce
4aeeae023766153a91b83d02b1b24da20c0dd135
3cac6ff7cddcb8f82409c79c85d976300fc60861
55eeaa904bc6518a2715cc77648e6c5187416a46
ff7b2c3938306261881c42e78d0df51d9bcdd574
089439168d3c75b4da94ab801f1c46ad6b9e1fdc
a5c36b8022751cfeb4a88a21153847df3870c7c0
ad3dbec2b621807fa9a2f1b2f575d7077e494626
4dc0ebfa52adf9b9eb4fa8f0a359c21a14e183fb
d102a34b3f0efb57f1d9f04eff26b256875a3aa1
2b9b740fb5fe0549810500476f567002683df71d
4fa2b2ab3e24ee9d130cfeda63c7ae1ccbc393dc
495a4b4757f3b1eec7fdaa9d0b2930071565f2b1
f31920d636224356e8c7a182c2b9b37e42a09181
9dc3d272652851428f5cc44f2fd9458bff1d6a78
4dd22a08a5b103e1f2238aed7f7ce66c5a542533
02065bbdb3209e0522db3225600b8e79f8a10293
81622512757f897206a84b29ee866fb933fa3d48
151dc47b213aaec3751ffd1427737c65757ab410
492cbe143f795888d8e5006ac595f65f4565ed6e
0e282dc84d6cfd447fece7d3ecc622523b143aa8
49cd96df4c85cdd7461701340c0bb4d05a5049d8
207b7cf5db59d70d4789cb91194c732bcd1cfb4b

Original link: https://www.sygnia.co/threat-reports-and-advisories/weaver-ant-tracking-a-china-nexus-cyber-espionage-operation/

Excerpts from “Raspberry Robin: Copy Shop USB Worm Evolves to Initial Access Broker Enabling Other Threat Actor Attacks”

Summary

Raspberry Robin, also known as Roshtyak or Storm-0856, is a complex and evolving threat actor that has transitioned from a USB drive worm first observed in 2019 to a sophisticated initial access broker (IAB). It breaches enterprises and sells this access to numerous other criminal groups, many of which have connections to Russia. Notably, Raspberry Robin has also provided IAB services to the Russian GRU’s Unit 29155 cyber actors. This evolution involved a shift from targeting print and copy shops to compromising hardened corporate targets. Research indicates that Raspberry Robin works with various serious threat actors, including SocGholish, Dridex, and LockBit. The threat actor utilizes advanced tactics, including leveraging compromised QNAP NAS boxes, routers, and IoT devices for its command and control (C2) infrastructure and obfuscating malware with multi-layer packing. Collaboration among security researchers and organizations is crucial for uncovering more about this ongoing threat and ultimately stopping it. Silent Push has been actively tracking Raspberry Robin since 2023, identifying nearly 200 unique C2 domains through key nameserver and domain naming conventions, as well as IP and ASN diversity patterns.

Technical Details

alt text alt text

Raspberry Robin initially spread via “Bad USB” attacks, often through infected USB drives found in print and copy shops. When a user clicked on a malicious Windows shortcut (LNK) file disguised as a folder on the drive, it would create a CMD.exe process. Subsequently, MSIexec.exe would connect to a C2 server, transmitting device, username, and hostname information, followed by continued attempts to communicate with Tor nodes.

The attack methodology evolved, with USB drive attacks declining by Fall 2024. New distribution methods emerged, including the use of Discord to send archive files containing a legitimate, signed Windows executable alongside a malicious DLL that side-loaded the Raspberry Robin malware. Additionally, Raspberry Robin began spreading through archive files (.7z, .rar) via web downloads and later switched to Windows Script Files (.wsf). These downloaded malicious files often require a connection to the C2 to become fully weaponized. The malware performs checks to evade sandboxes and test environments.

Raspberry Robin builds its C2 infrastructure on compromised QNAP and Internet of Things (IoT) devices, employing “Fast Flux” DNS mapping techniques. This involves rapidly rotating short domains with uncommon 2-letter top-level domains (TLDs) across a network of compromised devices. Examples of these domains include q2[.]rs, m0[.]wf, and h0[.]wf. The threat actor uses lower reputation TLDs for their domains, with .wf, .pm, .re, .nz, .eu, .gy, .tw, and .cx being among the most frequently observed.

The malware often uses port 8080 for communication. Research in 2024, through collaboration between Silent Push and Team Cymru, identified a singular IP address acting as a panel or data relay, connected to all the compromised QNAP devices through Tor relays. This IP address, located in an EU country, exhibited a consistent pattern of connections over potentially a year. The use of Tor makes deanonymizing the threat actors challenging.

Raspberry Robin leverages N-day exploits, targeting known vulnerabilities in QNAP and IoT products shortly after public disclosure. Check Point reported the use of two new 1-day local privilege escalation (LPE) exploits in 2024 before they were publicly disclosed, suggesting access to exploit dealers rather than internal development. The use of external 64-bit executables for these exploits, their lack of heavy obfuscation compared to the main component, and their 64-bit only nature further support this theory.

The threat actor employs multi-layer packing to obfuscate its malware, sometimes using up to 14 different layers. This complexity, combined with the initial access brokering business model, where follow-on payloads from clients like SocGholish can be deployed rapidly, can lead to misattribution of attacks.

Countries

Targeted Countries include:

  • Argentina
  • Australia
  • Mexico
  • Croatia
  • Italy
  • Brazil
  • France
  • India
  • Victims initially mostly outside the U.S., but this shifted.
  • Government agencies and telecommunication organizations from Latin America, Australia, and Europe.

Industries

Targeted industries include:

  • Technology
  • Manufacturing
  • Government agencies
  • Telecommunication organizations
  • Oil and gas
  • Transportation
  • Public administration
  • Finance
  • Retail
  • Education

Recommendations

  • Organizations with visibility into compromises should look for subtle signs of Raspberry Robin involvement.
  • Do not assume the threat actor demanding ransom is the only actor involved.
  • Publicize Raspberry Robin attacks and share details with law enforcement to facilitate resource allocation.
  • Continue extensive collaboration among defenders and research partners to uncover more about this threat.
  • Track Raspberry Robin as a critical and evolving threat.
  • Be aware that follow-on payloads like SocGholish might appear immediately after the initial Raspberry Robin infection, potentially leading to misattribution. Review logs carefully.
  • Critical infrastructure providers should be vigilant for Raspberry Robin infections, given the connection to the Russian GRU.
  • Consider using Silent Push’s Indicators of Future Attack (IOFA) Feeds for enhanced detection protocols (available with an Enterprise subscription).
  • Explore the Silent Push Community Edition for threat hunting and cyber defense capabilities.

Hunting methods

Silent Push utilized the following methods to track Raspberry Robin infrastructure:

  • Identifying key nameservers: Examining the infrastructure used to resolve Raspberry Robin domains.
  • Analyzing domain naming conventions: Recognizing patterns in how Raspberry Robin registers and names its domains, including the use of short domains (typically 3 characters) and uncommon 2-letter TLDs.
  • Observing IP and ASN diversity patterns: Tracking the IP addresses and Autonomous System Numbers (ASNs) associated with Raspberry Robin’s C2 infrastructure to understand the geographical distribution and hosting providers involved.
  • Continuous monitoring of C2 domains: Regularly checking the status and activity of identified C2 domains within the Silent Push platform.
  • NetFlow analysis: Collaborating with Team Cymru to analyze network traffic patterns associated with Raspberry Robin’s C2 infrastructure, providing insights into how it orchestrates its IAB services and the flow of communication between compromised devices and C2 servers. This helped identify a singular IP address used as a panel/data relay in 2024.

While the source doesn’t provide specific Yara, Sigma, KQL, or SPL queries, the logic behind Silent Push’s hunting methods involves identifying and tracking patterns in domain registration, DNS resolution, network traffic, and infrastructure hosting choices to uncover and monitor Raspberry Robin’s C2 network.

IOC

Domains

q2[.]rs
m0[.]wf
h0[.]wf
2i[.]pm
cloudns[.]net

Top Raspberry Robin TLDs

.wf
.pm
.re
.nz
.eu
.gy
.tw
.cx

Top Registrars

Sarek Oy
1API GmbH
NETIM
Epag[.]de
CentralNic Ltd
Open SRS

Top ASNs

3269 (ASN-IBSNAZ IT)
2856 (BT-UK-AS BTnet UK Regional network GB)
8400 (TELEKOM-AS RS)
1267 (ASN-WINDTRE IUNET IT)
3352 (TELEFONICA_DE_ESPANA ES)
205714 (Telemach Hrvatska d.o.o)
30722 (Vodafone Italy)
3320 (Deutsche Telekom)
9304 (Deutsche Telekom)
9269 (Hong Kong Broadband Network Ltd.)

Key IP Address: A singular IP address used as a panel/data relay in 2024 (connected through Tor relays and based in an EU country) was identified but is being redacted in presentations and this document to prevent inadvertent sharing and to support law enforcement actions. This IP is also not included in an IOFA feed as it only connects into the compromised infrastructure.

Original link: https://www.silentpush.com/blog/raspberry-robin/

The Curious Case of PlayBoy Locker

Summary

The PlayBoy Locker is a newly identified Ransomware-as-a-Service (RaaS) platform that lowers the barrier to entry for cybercriminals by providing sophisticated attack kits to less-skilled individuals. This platform operates on an affiliate model, allowing affiliates to deploy ransomware payloads developed by the PlayBoy Locker operators in exchange for a percentage (85%) of the ransom payments. The RaaS offers a comprehensive toolkit including ransomware binaries for Windows, NAS, and ESXi systems, management dashboards, and support services such as regular updates, anti-detection features, and customer support for affiliates via dark web forums. The PlayBoy Locker group became active in September 2024, initially seeking beta testers and later establishing an affiliate program on a dark web forum and an onion site, where they also posted their first victim. Unexpectedly, the operators later attempted to sell their project, indicating a potential shift in their operations.

Technical Details

PlayBoy Locker’s technical capabilities vary depending on the targeted operating system. The current Windows version employs a combination of hc-128 and curve25519 encryption algorithms and is written in the C++ programming language. It features segmented file encryption and can automatically spread within an Active Directory environment using LDAP with provided credentials. The ransomware utilizes a multithreaded queue for encryption, allowing for faster processing of files. It terminates various processes and services to unlock files before encryption, including common applications and security-related processes. Additionally, it attempts to delete shadow copies to prevent data restoration via Windows snapshots by executing the command vssadmin delete shadows /all /quiet. The Windows variant also includes functionalities to restart the system, change the wallpaper, ensure only one locker process runs at a time, wipe free space, deploy a customizable ransom note (saved as “INSTRUCTIONS.txt” in non-excluded directories), and empty the recycle bin. It attempts self-deletion after completing its operations using the command C:\Windows\System32\cmd.exe /C ping 127.0.0.1 -n 2 >nul del /F file name. To facilitate lateral movement, PlayBoy Locker performs LDAP scans requiring parameters like -ip, -u (username), and -p (password) to discover available machines on the network and subsequently attempts to copy the ransomware executable and set up a remote Windows service to execute it. The ransomware maliciously exploits the Restart Manager (RstrtMgr.dll) to handle open and unsaved files before encryption.

The ESXi version of PlayBoy Locker can automatically shut down virtual machines, runs as a daemon, and allows for excluding specific files and paths, with a relatively small build size of 70 kb. The NAS version focuses on simple single-path encryption and appears to be fully automatable through a web-based builder, which also includes active chat and administration panels.

The initial compromise likely occurs through standard infection vectors like phishing emails or compromised Remote Desktop Protocol (RDP) endpoints. PlayBoy Locker’s activities map to several MITRE ATT&CK techniques across various tactics, including Execution (Windows Management Instrumentation, Native API), Persistence (Create or Modify System Process: Windows Service), Discovery (File and Directory Discovery, Network Share Discovery, System Network Configuration Discovery), Privilege Escalation (Valid Accounts: Default Accounts, Valid Accounts: Domain Accounts), Defense Evasion (Obfuscated Files or Information: Software Packing, Reflective Code Loading), Collection (Automated Collection), and Impact (Data Encrypted for Impact, Service Stop, Inhibit System Recovery).

Recommendations

Cybereason recommends the following to detect and prevent PlayBoy Locker attacks:

  • Follow and hunt PlayBoy Locker affiliate activity to identify pre-ransomware behaviors.
  • Promote cybersecurity best practices, such as multifactor authentication and patch management.
  • Regularly backup files and establish a robust backup process and policy for data restoration.
  • Keep systems fully patched to mitigate exploitable vulnerabilities.
  • Involve Incident Response services for thorough investigation and containment to fully eliminate the threat actor.
  • For Cybereason Defense Platform users:
    • Enable Anti-Malware and set the Signatures mode to Prevent, Quarantine, or Disinfect.
    • Enable Anti-Ransomware (PRP), set it to Quarantine mode, and enable shadow copy protection. Enable Application Control.
    • Enable Variant Payload Prevention with prevent mode on Cybereason Behavioral execution prevention.

Hunting methods

The sources do not provide specific hunting queries (Yara, Sigma, KQL, SPL, or others) [n/a]. However, the technical details provided can inform the development of such queries. For example, one could look for processes attempting to execute vssadmin delete shadows /all /quiet or command lines containing ping 127.0.0.1 -n 2 >nul del /F. Monitoring for the creation of files named INSTRUCTIONS.txt in multiple directories after suspicious process termination events could also be a valuable hunting method. Additionally, observing network traffic patterns indicative of LDAP scans originating from unusual endpoints, especially when followed by remote service creation attempts, could signal potential PlayBoy Locker activity.

IOC

Hashes

3030a048f05146b85c458bcabe97968e5efdd81b224b96c30c83b74365839e7b
a9e1bd8f9cbeeec64da558027f380195f7ed572f03830a890dd0494e64d98556

Original link: https://www.cybereason.com/blog/threat-analysis-playboy-locker