The Feed 2025-04-04

AI Generated Podcast

Spotify

Summarized Stories

• Critical vulnerability in CrushFTP file transfer software under attack: This news report discusses the active exploitation of the critical CVE-2025-2825 vulnerability in CrushFTP, noting its high severity, the observed exploitation attempts originating mainly from Asia, and the confusion surrounding the initially disclosed affected versions.

• Suspected China-Nexus Threat Actor Actively Exploiting Critical Ivanti vulnerabilities: This threat intelligence report reveals the active exploitation of the CVE-2025-22457 buffer overflow vulnerability in Ivanti Connect Secure appliances by a suspected China-nexus actor, leading to remote code execution and the deployment of malware families like TRAILBLAZE, BRUSHFIRE, and the SPAWN ecosystem.

• Fast Flux: A National Security Threat: This joint cybersecurity advisory from multiple national security agencies warns about the malicious “fast flux” technique, where cyber actors rapidly change DNS records to obfuscate malicious servers, and offers guidance on detection and mitigation strategies for organizations and service providers.

• Hunting malicious OneOnOne chats via MS Teams: This article describes the increasing trend of threat actors using Microsoft Teams one-on-one chats for malicious purposes like phishing and malware delivery, and provides KQL queries and methodologies for detecting such activity by monitoring domains, URLs, and IP addresses.

Critical vulnerability in CrushFTP file transfer software under attack

Summary

A critical unauthenticated access vulnerability, tracked as CVE-2025-2825, affects CrushFTP versions 10.0.0 through 10.8.3 and 11.0.0 through 11.3.0. This flaw allows remote and unauthenticated HTTP requests to bypass authentication and gain unauthorized access to the CrushFTP server. The vulnerability has been assigned a “Critical” severity rating with a CVSS score of 9.8 due to its low complexity, network-based attack vector, and ease of exploitation. Security researchers at ProjectDiscovery published technical details and a proof of concept (PoC) exploit on March 28, 2025. The Shadowserver Foundation has observed exploitation attempts in the wild based on this publicly available PoC. The vulnerability arises from the improper handling of an AWS S3-specific authentication method in the loginCheckHeaderAuth() method. Specifically, a boolean flag, lookup_user_pass, intended to determine whether to look up a user’s password, is also used as a parameter (anyPass) to control whether password verification is required. By crafting a specific HTTP request with an AWS4-HMAC Authorization header containing a username (without a tilde “~”), the lookup_user_pass flag defaults to true, causing the subsequent login_user_pass() and verify_user() methods to bypass password validation entirely. Successful exploitation allows attackers to perform arbitrary privileged actions, including accessing files, uploading malicious content, and creating administrator accounts. CrushFTP privately informed customers about the vulnerability on March 21, 2025, and later published a security advisory urging users to upgrade. The vendor has released patched versions 10.8.4 and 11.3.1 to address this issue.

Technical Details

The vulnerability resides in the loginCheckHeaderAuth() method within crushftp.server.ServerSessionHTTP. This method processes HTTP requests and checks for various authentication methods, including an AWS S3-specific method indicated by the “AWS4-HMAC” prefix in the “Authorization” header.

When an “Authorization” header starts with “AWS4-HMAC”, the server attempts to extract an s3_username from the header, specifically the value following an “=” and before a “/” character. This extracted s3_username is then assigned to the user_name variable, and the boolean variable lookup_user_pass is set to true. This lookup_user_pass flag has a dual purpose:

1. To indicate whether the system should look up a user’s password from storage (true) or use a provided password (false).
2. As the anyPass parameter in the login_user_pass() method, controlling whether password verification is enforced.

The vulnerable code flow proceeds as follows:

1. The loginCheckHeaderAuth() method is invoked upon receiving an HTTP request with an S3 authorization header.
2. If the “Authorization” header starts with “AWS4-HMAC”, the s3_username is extracted, user_name is set, and lookup_user_pass is set to true (unless a tilde “~” is present in the username).
3. The login_user_pass() method in crushftp.handlers.SessionCrush is called with lookup_user_pass as the first argument, which corresponds to the anyPass parameter.
4. Inside login_user_pass(), the verify_user() method is called, also passing the anyPass parameter.
5. In the verify_user() method within crushftp.handlers.SessionCrush, the anyPass parameter is eventually passed to the UserTools.ut.verify_user() method.
6. The UserTools.ut.verify_user() method in com.crushftp.server.UserTools contains a critical condition: if (UserTools.checkPassword(thePass)) { anyPass = true; } and later if (!anyPass && this.user == null && !theUser.toLowerCase().equals("anonymous")) { this.user_info.put("plugin_user_auth_info", "Password incorrect."); } return true;. When anyPass is true (as it is by default for S3 authorization headers without a tilde), the password verification is effectively bypassed because the method will return true even if the password is incorrect or not provided.

To exploit this vulnerability, an attacker can craft an HTTP request to the CrushFTP server with the following characteristics:

• A GET request to /WebInterface/function/?command=getUsername&c2f=<last_four_chars_of_CrushAuth_cookie>. The specific function called is not critical for the initial bypass.
• A “Host” header pointing to the target CrushFTP server.
• A “Cookie” header containing a CrushAuth cookie and a currentAuth cookie. The currentAuth cookie’s value must match the last four characters of the CrushAuth cookie. The CrushAuth cookie needs to be 44 characters long with a specific format: 13 numerical characters, an underscore, and a 30-character string. This cookie can be arbitrarily set as long as it adheres to the format and the c2f parameter matches the last four characters.
• An “Authorization” header starting with “AWS4-HMAC-SHA256 Credential=/" where `` is a valid or even the default administrator username like "crushadmin", and importantly, does not contain a tilde (~).

An example exploit request:

GET /WebInterface/function/?command=getUsername&c2f=3HLa HTTP/1.1
Host: 192.168.181.129:8080
X-Requested-With: XMLHttpRequest
Accept-Language: en-US,en;q=0.9
Accept: */*
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36
Accept-Encoding: gzip, deflate, br
Cookie: showRightRail=false; DoNotShowFTU=true; lastMangerHost=http%3A//localhost%3A8087; currentAuth=3HLa; CrushAuth=1742972465863_IdzGfLNkZvdjv2ew1O9txCFnwe3HLa;
Authorization: AWS4-HMAC-SHA256 Credential=crushadmin/
Connection: keep-alive

A successful first request might return a blank response. Subsequent requests with the same cookie can then execute commands as the authenticated user. For example, requesting /WebInterface/function/?command=getUsername&c2f=3HLa after the bypass will return an XML response indicating the authenticated user, such as “crushadmin”.

The patch in versions 11.3.1 and 10.8.4 addresses this by:

• Reorganizing the authentication logic.
• Calling login_user_pass() later in the process with false instead of lookup_user_pass as the anyPass parameter.
• Implementing a new configuration value s3_auth_lookup_password_supported, set to false by default, to disable S3 authentication for instances not using AWS integration.
• Adding a security check to block the vulnerable path when lookup_user_pass would be true.

Countries

According to Shadowserver’s report, the majority of exploitation attempts originated from IP addresses in Asia, with a smaller number coming from Europe and North America.

Industries

The sources do not explicitly mention specific targeted industries. However, given that CrushFTP is a “widely used multi-protocol file transfer server” facilitating secure data exchange for many organizations, a broad range of industries that rely on secure file transfer are potentially at risk.

Recommendations

• Immediately upgrade CrushFTP server instances to version 11.3.1 or later for v11, or 10.8.4 or later for v10. This is the primary remediation to address the vulnerability.
• If immediate patching is not possible, consider implementing network-level access controls to restrict connections to the CrushFTP server.
• Review user account activity for any unauthorized access from unrecognized IP addresses. This can be challenging if verbose logging is not enabled.
• Consider enabling verbose logging (“2”) to capture the Authorization header in the logs, which can help in detecting exploitation attempts. Look for “Authorization” headers containing “AWS4-HMAC-SHA256” that do not contain legitimate AWS resource identifiers. However, note that sophisticated attackers might craft seemingly legitimate but invalid headers.
• For organizations not using CrushFTP’s AWS integration features, ensure the new s3_auth_lookup_password_supported configuration value is set to “false” in the updated versions.

Hunting methods

• Review CrushFTP logs (if verbose logging level 2 is enabled) for lines containing READ: *Authorization: AWS4-HMAC-SHA256 Credential=<username>/* where <username> might be the default “crushadmin” or other usernames without a full and valid AWS signature. The lack of a proper signature or full AWS resource identifier in the Authorization header can be an indicator.
  • Logic: This query looks for HTTP requests attempting AWS S3 authentication without a complete signature, which is characteristic of the described exploit.
• Monitor network traffic for HTTP GET requests to /WebInterface/function/ with an “Authorization” header starting with “AWS4-HMAC-SHA256 Credential=” and a “Cookie” header containing a formatted CrushAuth cookie where the currentAuth parameter matches the last four characters of the CrushAuth value. Analyze the server responses for unexpected “200 OK” responses or blank responses followed by successful authentication in subsequent requests.
  • Logic: This method aims to detect the specific HTTP requests used in the exploit by looking for the distinct characteristics of the malicious requests, including the target endpoint, the specific Authorization header format, and the associated cookie.
• Utilize the Nuclei template published by ProjectDiscovery to scan for vulnerable CrushFTP instances. The template sends two requests to attempt accessing the user list API via the authentication bypass. A successful exploit returns an HTTP 200 response containing the user list.
  • Logic: This automated approach directly tests for the presence of the vulnerability by attempting to trigger the authentication bypass and verifying the server’s response.

IOC

Observed exploitation attempts originated from various IP addresses, predominantly in Asia, with some in Europe and North America. Due to the widespread nature of the exploitation and the lack of specific malicious IPs identified in the sources, providing a concrete list of IOC IPs is not feasible at this time. Monitor your server logs for suspicious activity from unfamiliar IP addresses accessing the web interface.

Original link:

• attackerkb.com
• cybersecuritydive.com
• projectdiscovery.io

Suspected China-Nexus Threat Actor Actively Exploiting Critical Ivanti vulnerabilities

Summary

This report summarizes two critical security analyses concerning the exploitation of Ivanti Connect Secure (ICS) devices. The first report, from CISA, details malware named RESURGE and a variant of SPAWNSLOTH discovered on a compromised critical infrastructure ICS device, where initial access was gained by exploiting CVE-2025-0282. RESURGE exhibits command and control capabilities via SSH tunneling and can modify files, manipulate integrity checks, and establish a web shell. It also drops a SPAWNSLOTH variant for log tampering and utilizes a custom binary with an open-source shell script and BusyBox for kernel image extraction and payload execution. The second report, from Google Threat Intelligence Group (GTIG) and Mandiant, focuses on the active exploitation of a different critical vulnerability, CVE-2025-22457, by the suspected China-nexus espionage actor UNC5221. This exploitation led to the deployment of new malware families, TRAILBLAZE and BRUSHFIRE, alongside previously identified SPAWN ecosystem malware, including SPAWNSLOTH and SPAWNWAVE. UNC5221 attempted to evade detection by modifying the Integrity Checker Tool (ICT). The actor has a history of zero-day exploitation targeting edge devices.

Technical Details

Resurge (CISA Report)

The CISA report on RESURGE highlights its similarity to SPAWNCHIMERA in creating SSH tunnels for C2. Upon execution, RESURGE checks if it is loaded by the ‘web’ or ‘dsmdm’ program. If loaded by ‘web’, it hooks the accept and strncpy functions, contains an XOR-encrypted private key for potential attacker connection, and establishes an unencrypted proxy using a decoding function [6, Figure 2]. This proxy tunnels traffic, decoding received data and forwarding it to the file /me/runtime/tmp/.logsrv, enabling communication via a secure shell. The hooked strncpy function is modified to limit copied data to 256 bytes under specific conditions [6, Figure 3]. If loaded by ‘dsmdm’, RESURGE creates a thread for an SSH shell bound to /me/runtime/tmp/.logsrv, providing a secure socket shell accessible upon file access [6, Figure 4]. Another thread drops liblogblock.so (a SPAWNSLOTH variant) to /tmp, interacts with the dslogserver process via shared memory, and attempts to load /tmp/.liblogblock.so after detecting dslogserver [6, 7, Figure 5].

RESURGE executes a series of commands. Commands 1 insert RESURGE into ld.so.preload for persistence, set up a web shell within compcheckresult.cgi for remote command execution via the “vXm8DtMJG” parameter, fake integrity checks, and generate keys to sign the manifest file [7, 8, 9, Figure 6]. The web shell is created by inserting Perl code into /tmp/data/root/home/webserver/htdocs/dana-na/auth/compcheckresult.cgi that executes a system command if the “vXm8DtMJG” parameter is present. Integrity checks are bypassed by modifying check_integrity.sh to always exit with code 0. Commands 2 decrypt, modify, and re-encrypt the coreboot RAM disk [7, 9, 10, 11, Figure 7]. This involves creating a temporary directory, executing dsmain -g to extract the kernel image (vmlinux), decrypting the coreboot image using a key extracted from vmlinux, modifying files within the decompressed coreboot filesystem (including copying RESURGE, dsmain, and a Python package), modifying the boot process in /tmp/coreboot_fs/bin/init to add RESURGE to ld.so.preload and copy binaries to root directories, repacking and re-encrypting the coreboot image. Commands 3 use the system() function to execute sed commands that modify the Python scripts scanner.py and scanner_legacy.py to prevent them from tracking mismatches or new files during integrity scans [7, 12, 13, Figure 8]. Specifically, lines containing mismatchCount += 1, mismatchedFiles.append(file), newFilesCount += 1, and newFilesDetected.append(file) are replaced with pass or a blank space.

The CISA report also details liblogblock.so, a variant of SPAWNSLOTH. If the process name is dslogserver, it detaches shared memory associated with the “g_do_syslog_servers_exist” IPC key, obtains the handle to the symbol “_ZN5DSLog4File3addEPKci”, and uses the funchook library to intercept function calls at runtime, effectively tampering with logs [15, 16, Figure 9]. The report notes that log messages were removed from funchook_create to obscure the use of this open-source tool.

The file dsmain contains the open-source script extract_vmlinux.sh and a subset of applets from the open-source tool BusyBox. It accepts arguments -e (encrypt using AES), -d (decrypt using AES), and -g (invoke extract_vmlinux.sh). The -g option writes extract_vmlinux.sh to /tmp and uses it to extract the uncompressed kernel image from a compromised kernel image, likely for vulnerability analysis. The included BusyBox applets provide a wide range of Unix utilities for command execution on compromised devices.

CVE-2025-22457 (Google GTIG/Mandiant) report

The GTIG/Mandiant report details the exploitation of CVE-2025-22457, a buffer overflow vulnerability. Observed exploitation began in mid-March 2025. Post-exploitation, a shell script dropper is used to deploy TRAILBLAZE and BRUSHFIRE. The shell script first identifies a child /home/bin/web process that is listening for connections and then creates several temporary files: /tmp/.p (PID of the web process), /tmp/.m (memory map), /tmp/.w (base address of the web binary), /tmp/.s (base address of libssl.so), /tmp/.r (BRUSHFIRE backdoor), and /tmp/.i (TRAILBLAZE dropper). It then executes /tmp/.i (TRAILBLAZE), deletes most temporary files and core dumps, kills child processes of the web process, and deletes /tmp/.p. This entire process is non-persistent.

TRAILBLAZE is an in-memory only dropper written in bare C using raw syscalls. It injects a hook into the identified /home/bin/web process and then injects the BRUSHFIRE passive backdoor into a code cave within that process. BRUSHFIRE is also a passive backdoor written in bare C that functions as an SSL_read hook. It first executes the original SSL_read and then checks if the returned data starts with a specific string. If it does, the remaining data is XOR decrypted and executed as shellcode. If the shellcode returns a value, BRUSHFIRE uses SSL_write to send the value back.

The GTIG/Mandiant report confirms the deployment of SPAWNSLOTH for log tampering against the dslogserver process. It also mentions SPAWNSNARE, a C utility for extracting and AES-encrypting the Linux kernel image without relying on command-line tools. SPAWNWAVE is described as an evolved version of SPAWNANT with combined capabilities, overlapping with SPAWNCHIMERA and RESURGE. The actor UNC5221 also attempted to modify the Integrity Checker Tool (ICT) to evade detection.

Countries

Based on the GTIG/Mandiant report, UNC5221 has targeted a wide range of countries. The CISA report does not specify targeted countries but mentions a compromise at a critical infrastructure organization.

Industries

The GTIG/Mandiant report mentions that UNC5221 has targeted various verticals. The CISA report indicates a compromise within critical infrastructure.

Recommendations

The CISA report recommends the following best practices:

• Maintain up-to-date antivirus signatures and engines.
• Keep operating system patches up-to-date.
• Disable File and Printer sharing services or use strong passwords/Active Directory authentication if required.
• Restrict users’ ability to install and run unwanted software and avoid adding users to the local administrators group unnecessarily.
• Enforce a strong password policy with regular changes.
• Exercise caution with e-mail attachments, even from known senders.
• Enable personal firewalls on workstations, configured to deny unsolicited connections.
• Disable unnecessary services on workstations and servers.
• Scan and remove suspicious e-mail attachments, ensuring the file type matches the header.
• Monitor users’ web browsing and restrict access to unfavorable content.
• Exercise caution with removable media and scan all downloaded software before execution.
• Maintain situational awareness of the latest threats and implement appropriate Access Control Lists (ACLs).

The GTIG/Mandiant report recommends:

• Immediately apply the patch for CVE-2025-22457 by upgrading Ivanti Connect Secure (ICS) appliances to version 22.7R2.6 or later.
• Use the external and internal Integrity Checker Tool (ICT) and contact Ivanti Support if suspicious activity is identified.
• Actively monitor for core dumps related to the web process.
• Investigate ICT statedump files.
• Conduct anomaly detection of client TLS certificates presented to the appliance.

Hunting methods

YARA Rules (CISA Report):

rule CISA_25993211_01 : RESURGE backdoor dropper rootkit bootkit
{
    meta:
        author = "CISA Code & Media Analysis"
        incident = "25993211"
        date = "2025-03-03"
        last_modified = "20250303_1446"
        actor = "n/a"
        family = "SPAWN"
        capabilities = "n/a"
        malware_type = "backdoor dropper rootkit bootkit"
        tool_type = "unknown"
        description = "Detects RESURGE malware samples"
        sha256_1 = "52bbc44eb451cb5e16bf98bc5b1823d2f47a18d71f14543b460395a1c1b1aeda"
    strings:
        $s1 = "snprintf"
        $s2 = "CGI::param"
        $s3 = "coreboot.img"
        $s4 = "scanner.py"
        $s5 = { 6C 6F 67 73 }
        $s6 = "accept"
        $s7 = "strncpy"
        $s8 = "dsmdm"
        $s9 = "funchook_create"
        $s10 = { 20 83 B8 ED }
    condition:
        all of them
}

This YARA rule CISA_25993211_01 aims to detect RESURGE malware samples based on specific strings found within the binary, including function names like “snprintf”, “accept”, “strncpy”, “funchook_create”, and strings related to CGI parameters, coreboot, and scanner scripts. The byte sequence $s10 is also included in the signature.

rule CISA_25993211_02 : SPAWNSLOTH trojan compromises_data_integrity
{
    meta:
        author = "CISA Code & Media Analysis"
        incident = "25993211"
        date = "2025-03-04"
        last_modified = "20250304_0906"
        actor = "n/a"
        family = "SPAWN"
        capabilities = "compromises-data-integrity"
        malware_type = "trojan"
        tool_type = "unknown"
        description = "Detects SPAWNSLOTH malware samples"
        sha256_1 = "3526af9189533470bc0e90d54bafb0db7bda784be82a372ce112e361f7c7b104"
    strings:
        $s1 = "dslogserver"
        $s2 = "g_do_syslog_servers_exist"
        $s3 = "_ZN5DSLog4File3addEPKci"
        $s4 = "dlsym"
    condition:
        all of them
}

The YARA rule CISA_25993211_02 is designed to detect SPAWNSLOTH malware by looking for specific strings associated with its log tampering functionality, such as “dslogserver”, “g_do_syslog_servers_exist” (an IPC key), the C++ symbol “_ZN5DSLog4File3addEPKci” (related to log file addition), and the dynamic linking function “dlsym”.

Sigma Rules (CISA Report):

################################################################################
# README
# - This is not a conventional Sigma rule. Please do not edit "logsource-product: blank" unless you are editing this rule to meet specific logsources/fields and know your environment.
# - Query may a take long time to process.
# - Ensure your EDR/SIEM instance has enough memory to run these AND/OR condition based queries.
# - Analyst may need to make adjustments to the query as required. Sometimes simpler does it. However, these rules provide full list of IOCs.
# - TLP GREEN + Please use local installation of Sigma to convert this rule.
# - TLP CLEAR may convert rules using (https://uncoder.io/ or https://sigconverter.io/)
# CISA Code & Media Analysis
################################################################################
title: Detects RESURGE Malware Activity Ivanti CVE 2025_0282
tlp: CLEAR
id: d26745fc-7a56-4ca9-9011-7ab416d14875
status: test
description: Detects RESURGE Malware Activity Ivanti CVE 2025_0282 as described in MAR-25993211.r1.v1. Some strings may have high FP. Analyst must adjust as needed.
references:
  - 25993211.r1.v1
  - 52bbc44eb451cb5e16bf98bc5b1823d2f47a18d71f14543b460395a1c1b1aeda
author: CISA Code & Media Analysis
date: 2025-03-28
modified: 2025-03-28
logsource:
  product: blank
detection:
  keywords:
    - "/bin/mkdir /tmp/new_img"
    - "/bin/dsmain -g"
    - "/tmp/installer/do-install-coreboot"
  keywords_1:
    - "sed -i"
  keywords_2:
    - '"1i/lib/%s"'
    - "ld.so.preload"
    - "Extracting Package"
    - "Saving package"
    - "clean"
    - "LD_PRELOAD"
    - "DSUpgrade.pm"
    - "check_integrity.sh"
    - "coreboot.img"
    - "boot"
    - "compcheckresult.cgi"
    - "/tmp/data/root/home/etc/manifest/manifest"
    - "manifest"
  keywords_3:
    - "cp"
  keywords_4:
    - "/lib/%s /tmp/data/root/lib"
    - "/lib/%s"
    - "/tmp/data/root/lib"
    - "scanner*.egg"
    - "/bin/dsmain /tmp/coreboot_fs/bin/dsmain"
    - "/tmp/coreboot_fs"
    - "/home/root/lib/%s"
    - "dsmain"
  keywords_5:
    - "openssl"
  keywords_6:
    - "dgst -sha256"
    - "genrsa -out"
    - "rsa -in"
    - "dgst -sha512"
  keywords_7:
    - "/tmp/data/root/home/perl/DSUpgrade.pm"
    - "/tmp/data/root/home/webserver/htdocs/"
    - "check_integrity.sh"
    - "private.pem"
    - "manifest"
  keywords_8:
    - "system"
    - "sed -i"
  keywords_9:
    - "mismatch*"
    - "newFiles*"
  keywords_10:
    - "pass"
    - "scanner*.py"
  keywords_11:
    - "/bin/dsmain"
  keywords_12:
    - "gunzip"
    - "gzip"
    - "cpio"
    - "-idvm"
    - "touch"
    - "sed -i"
    - "find"
    - "strings"
    - "-e"
    - "-d"
    - "-s"
  keywords_13:
    - "coreboot.img*"
    - "coreboot_fs"
    - "ld.so.preload"
    - "vmlinux"
    - "version"
  keywords_14:
    - "/bin/rm"
    - "rm"
  keywords_15:
    - "*vmlinux.sh"
    - "coreboot.img.1"
    - "coreboot_fs"
    - "private.pem"
  keywords_16:
    - "mv"
  keywords_17:
    - "manifest*"
  keywords_18:
    - "touch"
  keywords_19:
    - "ld.so.preload"
  keywords_20:
    - "vmlinux.sh"
  keywords_21:
    - "bzImage"
  keywords_22:
    - "new_img"
  keywords_23:
    - "echo"
  keywords_24:
    - "awk"
  keywords_25:
    - "print"
  keywords_26:
    - "output"
  condition: keywords or keywords_1 and keywords_2 or keywords_3 and keywords_4 or keywords_5 and keywords_6 and keywords_7 or keywords_8 and keywords_9 and keywords_10 or keywords_11 and keywords_12 and keywords_13 or keywords_14 and keywords_15 or keywords_16 and keywords_17 or keywords_18 and keywords_19 or keywords_20 and keywords_21 and keywords_22 or keywords_23 and keywords_24 and keywords_25 and keywords_26
falsepositives:
  - Rate of FP moderate with some strings.
  - Use this rule in an infected environment/logs.
  - Analyst may need to make adjustments to the query as required.
level: high

This rule works by first defining many lists containing specific indicator strings (like commands or filenames) known to be used by RESURGE malware. The detection then triggers if either any single indicator from the main list is found, OR if specific predefined combinations of indicators (from different lists linked by AND) are found together in the same log event.

YARA Rules (GTIG/Mandiant Report):

rule M_APT_Installer_SPAWNANT_1
{
    meta:
        author = "Mandiant"
        description = "Detects SPAWNANT. SPAWNANT is an   Installer targeting Ivanti devices. Its purpose is to persistently   install other malware from the SPAWN family (SPAWNSNAIL,   SPAWNMOLE) as well as drop additional webshells on the box."
    strings:
        $s1 = "dspkginstall" ascii fullword
        $s2 = "vsnprintf" ascii fullword
        $s3 = "bom_files" ascii fullword
        $s4 = "do-install" ascii
        $s5 = "ld.so.preload" ascii
        $s6 = "LD_PRELOAD" ascii
        $s7 = "scanner.py" ascii
    condition:
        uint32(0) == 0x464c457f and 5 of ($s*)
}

This Mandiant YARA rule M_APT_Installer_SPAWNANT_1 aims to detect SPAWNANT installers by looking for specific ASCII full-word strings like “dspkginstall”, “vsnprintf”, “bom_files”, along with partial string “do-install” and strings related to persistence mechanisms (“ld.so.preload”, “LD_PRELOAD”) and the scanner script (“scanner.py”). The condition checks for the ELF magic bytes and the presence of at least five of these strings.

rule M_Utility_SPAWNSNARE_1 {
    meta:
        author = "Mandiant"
        description = "SPAWNSNARE is a utility written in C that targets   Linux systems by extracting the uncompressed Linux kernel image   into a file and encrypting it with AES."
    strings:
        $s1 = "\x00extract_vmlinux\x00"
        $s2 = "\x00encrypt_file\x00"
        $s3 = "\x00decrypt_file\x00"
        $s4 = "\x00lbb_main\x00"
        $s5 = "\x00busybox\x00"
        $s6 = "\x00/etc/busybox.conf\x00"
    condition:
        uint32(0) == 0x464c457f
        and all of them
}

The Mandiant YARA rule M_Utility_SPAWNSNARE_1 is designed to detect SPAWNSNARE by identifying null-terminated strings within the binary related to its kernel extraction and encryption capabilities (“extract_vmlinux”, “encrypt_file”, “decrypt_file”), along with strings associated with its main function (“lbb_main”) and the use of BusyBox. The rule checks for the ELF magic bytes and requires all of the defined strings to be present.

rule M_APT_Utility_SPAWNSLOTH_2
{
    meta:
        author = "Mandiant"
        description = "Hunting rule to identify strings found in SPAWNSLOTH"
    strings:
        $dslog = "dslogserver" ascii fullword
        $hook1 = "g_do_syslog_servers_exist" ascii fullword
        $hook2 = "ZN5DSLog4File3addEPKci" ascii fullword
        $hook3 = "funchook" ascii fullword
    condition:
        uint32(0) == 0x464c457f and all of them
}

This Mandiant YARA rule M_APT_Utility_SPAWNSLOTH_2 is a hunting rule for SPAWNSLOTH, similar to the CISA rule, looking for the ASCII full-word strings “dslogserver”, “g_do_syslog_servers_exist”, the C++ symbol “_ZN5DSLog4File3addEPKci”, and the string “funchook”, indicating the use of the function hooking library. The rule also checks for the ELF magic bytes and requires all these strings to be present.

IOC

Hashes (SHA256)

52bbc44eb451cb5e16bf98bc5b1823d2f47a18d71f14543b460395a1c1b1aeda (libdsupgrade.so - RESURGE)
3526af9189533470bc0e90d54bafb0db7bda784be82a372ce112e361f7c7b104 (liblogblock.so - SPAWNSLOTH variant)
b1221000f43734436ec8022caaa34b133f4581ca3ae8eccd8d57ea62573f301d (dsmain - SPAWNSNARE)
4628a501088c31f53b5c9ddf6788e835 (/tmp/.i - TRAILBLAZE)
e5192258c27e712c7acf80303e68980b (/tmp/.r - BRUSHFIRE)
ce2b6a554ae46b5eb7d79ca5e7f440da (/lib/libdsupgrade.so - SPAWNWAVE)
10659b392e7f5b30b375b94cae4fdca0 (/tmp/.liblogblock.so - SPAWNSLOTH)

Hashes (MD5)

cfb263a731d51ff489168bbca0d3bd2f (libdsupgrade.so - RESURGE)
44d09ca5b989e24ff5276d5b5ee1d394 (liblogblock.so - SPAWNSLOTH variant)
6e01ef1367ea81994578526b3bd331d6 (dsmain - SPAWNSNARE)

Filenames/Paths

/tmp/data/root/lib
/tmp/data/root/home/venv3/lib/python3.6/site-packages/scanner-0.1-py3.6.egg
/tmp/data/root/home/etc/manifest/manifest
/tmp/data/root/etc/ld.so.preload
/tmp/data/root/home/perl/DSUpgrade.pm
/tmp/data/root/home/webserver/htdocs/dana-na/auth/compcheckresult.cgi
/tmp/data/root/home/bin/check_integrity.sh
private.pem
manifest.2
/tmp/data/root/home/etc/manifest/
/tmp/data/boot/
/tmp/new_img/
/tmp/extract_vmlinux.sh
/tmp/new_img/vmlinux
/tmp/coreboot_fs/
/tmp/coreboot_fs/coreboot.img.1.gz
/tmp/coreboot_fs/coreboot.img.1
/tmp/coreboot_fs/bin/dsmain
/tmp/coreboot_fs/lib/
/tmp/coreboot_fs/bin/scanner-0.1-py3.6.egg
/tmp/coreboot_fs/bin/init
/home/root/etc/ld.so.preload
/home/root/bin/dsmain
/home/root/home/venv3/lib/python3.6/site-packages/scanner-0.1-py3.6.egg
/home/root/lib/
scripts/scanner.py
scripts/scanner_legacy.py
/tmp/.p
/tmp/.m
/tmp/.w
/tmp/.s
/tmp/.r
/tmp/.i
/data/var/cores
/home/bin/web
/tmp/.liblogblock.so
/me/runtime/tmp/.logsrv
/lib/libdsupgrade.so

Registry Keys/IPC Keys

g_do_syslog_servers_exist (IPC key)

Original link: https://www.cisa.gov https://cloud.google.com

Fast Flux: A National Security Threat

Summary

This joint cybersecurity advisory (CSA) from several national cybersecurity agencies, including CISA, NSA, and the FBI, warns organizations about the significant national security threat posed by a malicious technique known as “fast flux”. Fast flux allows cybercriminals and nation-state actors to evade detection and maintain resilient command and control (C2) infrastructure by rapidly changing the Domain Name System (DNS) records associated with their malicious domains. This rapid rotation of IP addresses and sometimes even DNS name servers makes tracking and blocking their activities significantly more difficult. The advisory highlights that many networks have a defensive gap against this technique and encourages Internet service providers (ISPs), particularly Protective DNS (PDNS) providers, to develop and implement robust detection and blocking capabilities. It also provides guidance for organizations on how to detect and mitigate fast flux through a multi-layered approach involving DNS analysis, network monitoring, and threat intelligence. Collaboration between government and providers is recommended to develop scalable solutions against this persistent threat. Fast flux is used to support various malicious activities, including maintaining C2 channels, facilitating phishing campaigns, and ensuring the availability of cybercriminal forums and marketplaces. Bulletproof hosting (BPH) providers sometimes offer fast flux services to enhance the resilience and anonymity of their clients’ malicious operations. Examples of threat actors using fast flux include those involved in Hive and Nefilim ransomware attacks and the Gamaredon APT group.

Technical Details

Fast flux is a domain-based technique where malicious actors rapidly change the DNS records (specifically IP addresses) associated with a single domain. This dynamic resolution technique helps malware “call home” for updates and further instructions while decreasing the risk of detection and blocking by network defenders.

There are two main variants of fast flux:

1. Single Flux: In this technique, a single domain name is linked to a large number of IP addresses that are frequently rotated in DNS responses. If one IP address is blocked, the domain remains accessible through the others. While this technique can be used legitimately by content delivery networks (CDNs) and load balancers for performance in dynamic hosting environments, its malicious use ensures continued connectivity for threat actors.

2. Double Flux: This more advanced technique not only rapidly changes the IP addresses but also frequently changes the DNS name servers responsible for resolving the domain. This adds an extra layer of redundancy and anonymity to the malicious infrastructure. Double flux can utilize both Name Server (NS) and Canonical Name (CNAME) DNS records.

Both single and double flux techniques commonly leverage a botnet, which consists of numerous compromised hosts acting as proxies or relay points across the internet. This distributed infrastructure makes it very difficult for network defenders to pinpoint the origin of the malicious traffic and effectively block or take down the infrastructure through legal enforcement.

Fast flux offers several key advantages for malicious cyber actors:

• Increased Resilience: The rapid rotation through botnet devices makes it challenging for law enforcement or abuse notifications to disrupt their services quickly.
• Ineffective IP Blocking: By the time an IP address is identified and blocked, it is likely no longer in use by the fast flux domain, rendering IP blocking largely ineffective.
• Anonymity: The constantly changing IP addresses associated with the C2 botnets during an investigation make it difficult to trace malicious content back to the source.

Beyond C2 communications, fast flux is also employed in phishing campaigns to make social engineering websites more resistant to blocking and takedowns. Phishing often serves as the initial access point for more complex cyber compromises, used to steal credentials, financial information, distribute malware, or exploit vulnerabilities. Similarly, fast flux is used to maintain the high availability of cybercriminal forums and marketplaces, protecting them from law enforcement takedowns.

Bulletproof hosting (BPH) services, which ignore or evade law enforcement requests and abuse notices, sometimes provide fast flux services as a way for malicious actors to maintain connectivity and improve the reliability of their malicious infrastructure. Some BPH providers even advertise fast flux as a feature to help clients avoid blocklists like Spamhaus by having “dummy server interfaces” reported for abuse while the actual customer servers remain clean. This allows various malicious activities, including botnet management, fake shops, credential stealers, viruses, and spam mailers, to evade identification and blocking.

Countries

The advisory is a joint effort by cybersecurity agencies from the United States (NSA, CISA, FBI), Australia (ASD’s ACSC), Canada (CCCS), and New Zealand (NCSC-NZ), indicating a concern for national security across these nations. The technique is employed by both cybercriminals and nation-state actors. Gamaredon, a threat actor with suspected ties to Russia, is explicitly mentioned as using fast flux to limit the effectiveness of IP blocking.

Industries

The advisory is aimed at all organizations, Internet service providers (ISPs), and cybersecurity service providers. It specifically mentions government and critical infrastructure organizations as stakeholders who should coordinate on implementing mitigations. The mention of national security threats implies a broad concern across various sectors.

Recommendations

The authoring agencies recommend a multi-layered approach for detecting and mitigating malicious fast flux activity, emphasizing collaboration between government and providers. Key technical recommendations include:

• Leveraging Threat Intelligence Feeds and Reputation Services: Utilize these resources to identify known fast flux domains and associated IP addresses in security controls like firewalls, DNS resolvers, and SIEM solutions.
• Implementing Anomaly Detection Systems for DNS Query Logs: Identify domains exhibiting high entropy or IP diversity in DNS responses and frequent IP address rotations. Fast flux domains can cycle through tens or hundreds of IP addresses daily.
• Analyzing DNS Record Time-to-Live (TTL) Values: Fast flux domains often have unusually low TTL values, with IP addresses changing every 3 to 5 minutes being typical.
• Reviewing DNS Resolution for Inconsistent Geolocation: Malicious domains using fast flux tend to generate high volumes of traffic with inconsistent IP geolocation information.
• Using Flow Data: Identify large-scale communications with numerous different IP addresses over short periods.
• Developing Fast Flux Detection Algorithms: Create algorithms to identify anomalous traffic patterns that deviate from normal network DNS behavior.
• Monitoring for Phishing Activities: Correlate suspicious emails, websites, or links with potential fast flux activity, as fast flux can be used to rapidly spread phishing campaigns and maintain their availability.
• Implementing Customer Transparency and Information Sharing: Alert customers promptly upon confirming malicious fast flux activity.

For mitigation, the advisory recommends the following actions:

• DNS and IP Blocking and Sinkholing: Block access to identified malicious fast flux domains and IP addresses using non-routable DNS responses or firewall rules. Consider sinkholing malicious domains to a controlled server for traffic analysis and identification of compromised hosts.
• Reputational Filtering: Block traffic to and from domains or IP addresses with poor reputations, especially those associated with malicious fast flux activity.
• Enhanced Monitoring and Logging: Increase logging and monitoring of DNS traffic and network communications to detect new or ongoing fast flux activities. Implement automated alerting mechanisms for swift responses. Refer to ASD’s ACSC joint publication, Best practices for event logging and threat detection, for further guidance.
• Collaborative Defense and Information Sharing: Share detected fast flux indicators (domains, IP addresses) with trusted partners and threat intelligence communities through initiatives like CISA’s Automated Indicator Sharing or ISACs. Participate in public and private information-sharing programs to stay informed about emerging TTPs. Early discovery and sharing are crucial due to the short lifespan of malicious activity associated with these domains.
• Phishing Awareness and Training: Implement programs to educate personnel on identifying and responding to phishing attempts, and develop procedures for managing and containing phishing incidents facilitated by fast flux networks. Refer to joint Phishing Guidance: Stopping the Attack Cycle at Phase One for more information.

Organizations are encouraged to use cybersecurity and PDNS services that actively detect and block fast flux. It is important to validate with PDNS providers whether they offer this specific protection. NSA and CISA offer PDNS services for specific sectors.

Hunting methods

The advisory suggests several hunting methods based on the detection techniques:

• DNS Query Log Analysis:
  • High Entropy in DNS Responses: Look for domains that resolve to a large number of unique IP addresses within a short timeframe. This can be identified by analyzing DNS query logs and grouping queries by domain name, then counting the number of unique resolved IPs. A significantly high count compared to baseline could indicate single flux activity.
  • Frequent IP Address Rotations: Monitor the changes in resolved IP addresses for specific domains over time. A domain exhibiting rapid and frequent changes in its associated IP addresses is a strong indicator of fast flux. This can be achieved by tracking DNS resolution history.
  • Unusually Low TTL Values: Analyze DNS response records for unusually short TTL values. Queries for domains with consistently low TTLs (e.g., below a certain threshold like 300 seconds) should be investigated further as they suggest frequent record changes.
  • Inconsistent Geolocation: Correlate DNS resolution with geolocation data. A domain that resolves to IPs spread across numerous disparate geographical locations within a short period, without a legitimate reason (like a CDN with known global distribution), could be indicative of fast flux.
• Network Flow Analysis:
  • Large-Scale Communications with Numerous Different IP Addresses: Analyze network flow data (e.g., NetFlow, IPFIX) to identify internal hosts communicating with a high number of distinct external IP addresses over a short duration for a given domain or set of domains. This could indicate communication with a fast flux-backed infrastructure.
• Correlation with Threat Intelligence: Continuously compare observed DNS resolutions and network traffic with threat intelligence feeds that identify known fast flux domains and associated IP addresses.

Logic of the queries: These hunting methods rely on identifying statistical anomalies and patterns in DNS and network data that deviate from normal behavior. Legitimate services like CDNs might exhibit some level of IP diversity and rotation, but malicious fast flux activity typically involves a much higher frequency and volume of changes that are not geographically or logically consistent with legitimate content delivery or load balancing. The low TTL values are a deliberate tactic by threat actors to ensure rapid failover and hinder blocking efforts.

Original link: https://www.cisa.gov

Hunting malicious OneOnOne chats via MS Teams

Summmary

The article discusses the increasing trend of threat actors leveraging Microsoft Teams as an attack vector by initiating one-on-one chats with internal users. These attackers impersonate support teams or other trusted entities to establish credibility and deceive employees. Their primary goal is to deliver malicious payloads through shared files or links, leading to malware infections, phishing attempts, and the establishment of remote access for data theft and credential compromise. The document emphasizes the importance of monitoring one-on-one chats, particularly those originating from external domains, and highlights various Indicators of Compromise (IOCs) and KQL queries that can be used for detection, incident response, and proactive defense. The article also recommends implementing strict external communication policies, educating employees on social engineering tactics, and continuously monitoring Teams activity to mitigate these threats.

Technical Details

Threat actors are increasingly targeting Microsoft Teams users through one-on-one chats, exploiting the trust associated with internal communication platforms. The attackers, originating from external domains, typically impersonate support teams or other trusted personnel to socially engineer employees. This impersonation aims to build rapport and convince users to interact with malicious content.

The Tactics, Techniques, and Procedures (TTPs) observed include sending malicious files or URLs under the guise of providing assistance. These malicious payloads can range from malware designed to compromise systems to phishing pages intended to steal credentials. In some instances, the attackers aim to establish Remote Desktop Protocol (RDP) connections to gain persistent access to the organization’s environment.

The article highlights several technical approaches for detecting these malicious activities. One key technique is monitoring for “ChatCreated” events where the “CommunicationType” is “OneOnOne”. Analyzing the domains involved in these external chats is crucial, especially when the tenant allows communication with any external domain. The provided KQL query for hunting by domains focuses on identifying external domains initiating conversations and allows for whitelisting trusted domains while flagging suspicious ones. The logic of this query involves looking at CloudAppEvents for “Microsoft Teams” activity, specifically filtering for “ChatCreated” events with “OneOnOne” communication. It then expands the ParticipantsInfo to extract participating domains and SIP domains, filtering out internal Microsoft domains to highlight external interactions.

Another detection method involves hunting for malicious URLs shared within these chats. The article leverages the UrlHaus database, a threat intelligence source that tracks malicious domains. The provided KQL query retrieves actively tracked malicious URLs from UrlHaus and then joins this data with CloudAppEvents where Microsoft Teams is the application and MessageURLs are present. The logic here is to identify any instances where a URL found in Teams conversations matches a known malicious URL in the UrlHaus feed.

Finally, the article discusses analyzing the IP addresses of the chat initiators. By cross-referencing these IPs with threat intelligence sources like IPsum, organizations can identify potentially risky or compromised IPs attempting to engage in direct communication. The provided KQL query for this method also starts with CloudAppEvents filtered for Microsoft Teams and non-empty IP addresses, then joins this data with the IPsum threat intelligence feed based on matching IP addresses. This helps to identify “ChatCreated” “OneOnOne” communications originating from known malicious IPs.

Recommendations

The article provides the following mitigation recommendations:

• Enforce strict external communication policies.
• Educate employees on social engineering tactics.
• Continuously monitor Teams activity, including external message patterns and file transfers.
• Configure alert-based detection rules to trigger notifications whenever an unknown domain initiates a One-on-One chat.

Hunting methods

The article provides the following KQL queries for hunting malicious OneOnOne chats:

1. Hunting OneOnOne chats by Domains:

CloudAppEvents
| where Application has "Microsoft Teams" and isnotempty(IPAddress)
| extend Geo_IP = tostring(geo_info_from_ip_address(IPAddress).country)
| extend ChatName = todynamic(RawEventData).ChatName
| extend TeamName = todynamic(RawEventData).TeamName
| extend ChannelName = todynamic(RawEventData).ChannelName
| extend Operation = todynamic(RawEventData).Operation
| extend CommunicationType = todynamic(RawEventData).CommunicationType
| where  Operation has "ChatCreated" and CommunicationType has "OneOnOne"
| mv-expand  ParticipantsInfo = (todynamic(parse_json(RawEventData).ParticipantInfo))
|  mv-expand  ParticipatingDomains =  (ParticipantsInfo).ParticipatingDomains
|  mv-expand  ParticipatingSIPDomains =  (ParticipantsInfo).ParticipatingSIPDomains
|  mv-expand  ParticipatingSIPDomains =  (ParticipatingSIPDomains).DomainName
| where  Operation has "ChatCreated" and CommunicationType has "OneOnOne"
| where (ParticipatingDomains!="" or  ParticipatingSIPDomains!="") and (ParticipatingDomains !in ("microsoft.com") or ParticipatingSIPDomains !in ("microsoft.com"))
| project  AccountDisplayName,ChatCreatedFrom= IPAddress,ChannelName,ChatName, TeamName,Geo_IP, CountryCode,Operation,ParticipatingSIPDomains,ParticipatingDomains, ISP

Logic: This query looks for “ChatCreated” events in Microsoft Teams where the communication type is “OneOnOne”. It then extracts the participating domains (both regular and SIP domains) and filters out internal Microsoft domains to identify external domains initiating these chats. The results include details about the user involved, the IP address of the initiator, chat details, geographic information, and the participating domains.

2. Hunting Malicious OneOnOne chats by URL:

let URLHausOnlineRAW = externaldata (UHFeed:string) ["https://urlhaus.abuse.ch/downloads/csv_online/"] with(format="txt")
| where UHFeed !startswith "#"
| extend UHRAW=replace_string(UHFeed, '"', '')
| project splitted=split(UHRAW, ',')
| mv-expand id=splitted, dateadded=splitted, UHUrl=splitted, UHurl_status=splitted, UHlast_onlin=splitted, UHthreat=splitted, UHtags=splitted, UHLink=splitted, UHReporter=splitted
| extend UHUrl = tostring(UHUrl);
CloudAppEvents
| where Application has "Microsoft Teams"
| extend MessageURLs = tostring(todynamic(RawEventData).MessageURLs)
| extend MessageURLs_ = substring(MessageURLs, 2, strlen(MessageURLs) - 4)
| join kind=inner URLHausOnlineRAW on $left.MessageURLs_ == $right.UHUrl

Logic: This query first defines an external data source pointing to the UrlHaus online feed of malicious URLs. It parses this feed to extract the malicious URLs. Then, it looks for events in CloudAppEvents related to Microsoft Teams and extracts any URLs found in the messages. It then performs an inner join between the Teams message URLs and the list of malicious URLs from UrlHaus, highlighting any matches.

3. Hunting Malicious OneOnOne chats by IP:

let ipsumrawData = externaldata(ip_string: string)[h@"https://raw.githubusercontent.com/stamparm/ipsum/master/ipsum.txt"] with (format="txt");
CloudAppEvents
| where Application has "Microsoft Teams" and isnotempty(IPAddress)
| extend Geo_IP = tostring(geo_info_from_ip_address(IPAddress).country)
| extend ChatName = todynamic(RawEventData).ChatName
| extend TeamName = todynamic(RawEventData).TeamName
| extend ChannelName = todynamic(RawEventData).ChannelName
| extend Operation = todynamic(RawEventData).Operation
| extend CommunicationType = todynamic(RawEventData).CommunicationType
| extend MessageURLs = tostring(todynamic(RawEventData).MessageURLs)
| where  Operation has "ChatCreated" and CommunicationType has "OneOnOne"
| join kind=inner ( ipsumrawData) on $left.IPAddress == $right.ip_string
| project ActionType, Operation, AccountDisplayName, ChatCreatedFrom= IPAddress,Geo_IP, CountryCode,ChatName, CommunicationType

Logic: This query defines an external data source pointing to the IPsum list of suspicious and malicious IP addresses. It then looks for “ChatCreated” events with “OneOnOne” communication in Microsoft Teams and joins these events with the IPsum data based on matching IP addresses. This helps identify one-on-one chats initiated from IPs known to be potentially malicious.

Original link: https://detect.fyi