The Feed 2025-03-19

alt text

AI Generated Podcast

https://open.spotify.com/episode/2cu7UIsIRCNA0EYH9CEX6q?si=jJ3vwxolROaKWC3MEoGKyw

Summarized Stories

ClearFake’s New Widespread Variant: Increased Web3 Exploitation for Malware Delivery

Summary

The latest variant of the ClearFake malicious JavaScript framework, active since December 2024, employs fake reCAPTCHA or Cloudflare Turnstile verifications to trick users into executing malicious PowerShell code, leading to system infection. This variant continues to use the EtherHiding technique and the ClickFix tactic but has incorporated new interactions with the Binance Smart Chain to load JavaScript code, fingerprint victims, and deliver the ClickFix lure. ClearFake, initially emerging in July 2023 with fake browser update pages, evolved to use fake error messages and PowerShell execution by May 2024. The framework compromises websites, primarily WordPress sites, by injecting a small JavaScript code that loads and executes further malicious components from the Binance Smart Chain. This new version leverages smart contract ABIs for these interactions. The threat remains widespread, potentially affecting hundreds of thousands of users globally. The final payloads delivered by ClearFake have included loader malware like Amadey, IDAT Loader, and HIjack Loader, which subsequently deploy infostealers such as Lumma and Stealc for Windows, and AMOS Stealer for macOS. More recently, it has been observed delivering Emmenhtal Loader and Vidar Stealer.

Technical Details

alt text The ClearFake infection chain begins with the injection of a brief JavaScript code into compromised websites, often WordPress sites. This initial script loads legitimate external dependencies (pako3 and web34), instantiates web3 objects to interact with the Binance Smart Chain using a custom ABI, retrieves next-stage JavaScript codes from a smart contract, and executes this fetched code using eval(). The ABI of the initial contract at wallet 0x9179dda8B285040Bf381AABb8a1f4a1b8c37Ed53 defines four functions: orchidABI, orchidAddress, merlionABI, and merlionAddress, all returning strings. The data retrieved from these functions is typically compressed with gzip and base64 encoded, requiring decoding and decompression using atob and pako.ungzip.

The EtherHiding technique involves storing obfuscated JavaScript code within the “Input Data” field of Binance Smart Chain smart contracts, structured according to the contract ABI specification. The initial contract’s data is deobfuscated by decoding the base64 blob starting with “H4sI” and then decompressing it with gzip. The ClearFake framework retrieves two new wallet addresses: 0x53fd54f55C93f9BCCA471cD0CcbaBC3Acbd3E4AA and 0x8FBA1667BEF5EdA433928b220886A830488549BD.

The second stage of the infection checks for the “data-ai-collecting-shown” cookie and then uses functions from the orchidABI to load and execute further obfuscated code hosted on the smart contracts of wallet 0x8FBA1667BEF5EdA433928b220886A830488549BD. The teaCeremony function handles the decoding (base64) and decompression (gzip) of the data retrieved from the orchidABI before executing it with eval(). The orchidABI includes functions like shibuyaCrossing (checks OS), akihabaraLights (checks browser), ginzaLuxury (downloads, decrypts, and displays the ClickFix lure), asakusaTemple (logs empty string), and tokyoSkytree (checks/sets ClearFake cookie).

The second stage fingerprints the victim by checking the User-Agent for the operating system and web browser. It then retrieves an external URL hosting the encrypted HTML code for the ClickFix lure and an AES key for decryption using the merlionABI functions associated with wallet 0x53fd54f55C93f9BCCA471cD0CcbaBC3Acbd3E4AA. This wallet contains methods like 0xda4c3e46 (state), 0x167d1c4b (AES key), 0x4128180a (ClickFix encrypted HTML page URL), and 0x67685e3e (ClickFix command). The downloaded HTML is decrypted using AES-GCM, with the first twelve bytes of the downloaded data serving as the Initialization Vector (IV) and GCM authentication tag. The domain “example[.]net” within the decrypted HTML is replaced with the compromised website’s domain before being displayed in a full-screen iframe.

The ClickFix lures, retrieved from URLs often hosted on Cloudflare Pages or Backblaze B2, typically mimic a fake Cloudflare Turnstile verification with unusual web traffic or a fake reCAPTCHA challenge along with a DNS error. Interacting with these fake challenges leads to the display of instructions to open the Run command window (Win+R), paste, and execute a malicious PowerShell command. This command, fetched from the Binance Smart Chain (method ID 0x67685e3e in merlionABI) or sometimes directly embedded in the encrypted HTML, is copied to the clipboard.

The executed PowerShell commands often involve Mshta.exe to run a script hosted on a remote server, masquerading as video or audio files (MP3, MP4, M4A). These scripts are the initial stage of Emmenhtal Loader. The MSHTA script contains an obfuscated payload and JavaScript code to deobfuscate and execute it. The deobfuscated payload is another JavaScript code that uses ActiveXObject to run a PowerShell script. This PowerShell script decrypts an AES-encrypted payload, which is yet another PowerShell script. This final PowerShell script downloads further malicious code (e.g., kangarooing.bmp) from remote URLs using a custom curl function, saves it to the AppData folder, and executes it. This downloaded payload is often a heavily obfuscated PowerShell script designed to bypass AMSI, decrypt an embedded payload, and execute it, with the final payload being Lumma Stealer.

In some instances, ClearFake has also distributed Vidar Stealer. This involved a ClickFix lure leading to the execution of an MSHTA command, which in turn executed a PowerShell command to download and run another PowerShell script from GitHub. This second script then downloaded and executed an executable (Vidar Stealer) from GitHub and uploaded the victim’s public IP address to a C2 server.

Recommendations

To protect against ClearFake:

  • Proactively monitor this threat due to the consistent updates to its framework code, lures, and distributed payloads.
  • Use internet scanning engines like Censys or PublicWWW to search for websites containing the initial JavaScript code. The provided Censys query is: services.http.response.body:"0x9179dda8B285040Bf381AABb8a1f4a1b8c37Ed53".
  • Monitor the wallet addresses associated with ClearFake (0x9179dda8B285040Bf381AABb8a1f4a1b8c37Ed53, 0x53fd54f55C93f9BCCA471cD0CcbaBC3Acbd3E4AA, and 0x8FBA1667BEF5EdA433928b220886A830488549BD) to identify compromised websites.
  • Monitor transaction data associated with the method ID 0x4128180a in the wallet 0x53fd54f55C93f9BCCA471cD0CcbaBC3Acbd3E4AA to track URLs hosting ClickFix lure HTML files.
  • Monitor transaction data associated with the method ID 0x67685e3e in the wallet 0x53fd54f55C93f9BCCA471cD0CcbaBC3Acbd3E4AA to track distributed PowerShell commands and the URLs hosting the initial stage of Emmenhtal Loader.

Hunting methods

  • Censys Query: services.http.response.body:"0x9179dda8B285040Bf381AABb8a1f4a1b8c37Ed53"
    • Logic: This query searches for the specific string “0x9179dda8B285040Bf381AABb8a1f4a1b8c37Ed53”, which is the wallet address storing the initial ABIs used by ClearFake, within the HTTP response body of scanned websites. Finding this string suggests the presence of the initial ClearFake JavaScript code injected into the website.
  • Monitoring transactions on the Binance Smart Chain for the identified wallet addresses, specifically looking at function calls related to retrieving JavaScript code (orchidABI), lure HTML URLs (merlionABI method ID 0x4128180a), and PowerShell commands (merlionABI method ID 0x67685e3e).

IOC

Wallet Addresses:
0x9179dda8B285040Bf381AABb8a1f4a1b8c37Ed53
0x53fd54f55C93f9BCCA471cD0CcbaBC3Acbd3E4AA
0x8FBA1667BEF5EdA433928b220886A830488549BD

URLs hosting ClickFix lure HTML files (as of February 2025):
hxxps://ert67-o9.pages[.]dev/data
hxxps://f003.backblazeb2[.]com/file/skippp/uu.html
hxxps://f003.backblazeb2[.]com/file/skippp/index.html
hxxps://hostme.pages[.]dev/host
hxxps://ghost-name.pages[.]dev/website
hxxps://gdfg-23rwe.pages[.]dev/index.html
hxxps://sha-11x.pages[.]dev/
hxxps://b1-c1-k8.pages[.]dev/
hxxps://1a-a1.pages[.]dev/
hxxps://sdfwefwg.pages[.]dev/
hxxps://niopg.pages[.]dev/
hxxps://sdfwefwg.pages[.]dev/
hxxps://cleaning-devices-k.pages[.]dev/
hxxps://tour-agency-media.pages[.]dev/
hxxps://fresh-orange-juice.pages[.]dev/
hxxps://you-insk-bad.pages[.]dev/
hxxps://human-verify-7u.pages[.]dev/
hxxps://recaptcha-verify-me-1c.pages[.]dev/
hxxps://macos-browser-update-9n.pages[.]dev/
hxxps://macos-browser-update-5i.pages[.]dev/
hxxps://recaptcha-verify-2e.pages[.]dev/
hxxps://recaptcha-verify-7z.pages[.]dev/
hxxps://recaptcha-verify-1t.pages[.]dev/
hxxps://recaptcha-verify-9m.pages[.]dev/
hxxps://disable-data-collect-ai.pages[.]dev/
hxxps://recaptcha-verify-1r.pages[.]dev/
hxxps://recaptha-verify-5q.pages[.]dev/

URLs hosting next-stage payload/Emmenhtal Loader (as of February 2025):
hxxps://note1.nz7bn[.]pro/nnp.mp4
hxxps://ai.fdswgw[.]shop/one.mp4
hxxps://mnjk-jk.bsdfg-zmp-q-n[.]shop/1.mp4
hxxps://nbhg-v.iuksdfb-f[.]shop/ajax.mp3
hxxps://hur.bweqlkjr[.]shop/m41.mp4
hxxps://hur.bweqlkjr[.]shop/1a.m4a
hxxps://yob.yrwebsdf[.]shop/1a.m4a
hxxps://yob.yrwebsdf[.]shop/3t.mp4
hxxps://start.cleaning-room-device[.]shop/sha589.m4a
hxxps://discover-travel-agency.pro/joke.m4a
hxxps://discover-travel-agency.pro/walking.mp3
hxxps://discover-travel-agency.pro/1.m4a
hxxps://travel.image-gene-saver.it.com/1.m4a
hxxps://ads.green-pickle-jo[.]shop/1.m4a
hxxps://recaptcha-verify-4h[.]pro/kangarooing.m4a
hxxps://recaptcha-manual[.]shop/kangarooing.m4a
hxxps://recaptcha-verify-4h[.]pro/xfiles/kangarooing.vsdx
hxxps://recaptcha-verify-4h[.]pro/xfiles/verify.mp4
hxxps://human-verify[.]shop/xfiles/verify.mp4
hxxps://human-verify-4r[.]pro/xfiles/verify.mp4
hxxps://human-verify-4r[.]pro/xfiles/human.cpp
hxxps://dns-verify-me[.]pro/xfiles/train.mp4
hxxp://83.217.208[.]130/xfiles/Ohio.mp4
hxxp://83.217.208[.]130/xfiles/VIDA.mp3
hxxp://83.217.208[.]130/xfiles/VIDA.mp4
hxxp://83.217.208[.]130/xfiles/trip.mp4
hxxp://83.217.208[.]130/xfiles/trip.psd
hxxp://80.64.30[.]238/trip.psd
hxxp://80.64.30[.]238/evix.xll
hxxps://raw.githubusercontent[.]com/fuad686337/tyu/refs/heads/main/BEGIMOT.xll
hxxps://domain[.]com/BEGIMOT.xll
hxxps://disable-data-ai-agent.pages.dev
hxxps://tumbl.design-x[.]xyz/glass.mp3
hxxps://f003.backblazeb2[.]com/file/skippp/glass.mp3
hxxps://sandbox.yunqof[.]shop/macan.mp3
hxxps://microsoft-dns-reload-1r.pages[.]dev
hxxps://microsoft-dns-reload-5q.pages[.]dev

GitHub URLs (for Vidar Stealer distribution):
hxxps://raw.githubusercontent[.]com/Vincent-48/html/refs/heads/master/page.txt
hxxps://raw.githubusercontent[.]com/Vincent-48/html/refs/heads/master/TestLAB.exe

C2 URL (for Vidar Stealer):
hxxps://lapkimeow[.]icu/run

URLs of MSHTA commands (for Vidar Stealer distribution):
hxxps://microsoft-dns-reload-1r.pages[.]dev

URLs of PowerShell commands distributed by ClearFake (as of February 2025):
hxxps://ai.fdswgw[.]shop/one.mp4
hxxps://mnjk-jk.bsdfg-zmp-q-n[.]shop/1.mp4
hxxps://nbhg-v.iuksdfb-f[.]shop/ajax.mp3
hxxps://nbhg-v.iuksdfb-f[.]shop/ajax.mp3
hxxps://hur.bweqlkjr[.]shop/m41.mp4

Original link: https://blog.sekoia.io/clearfakes-new-widespread-variant-increased-web3-exploitation-for-malware-delivery/

One PUT Request to Own Tomcat: CVE-2025-24813 RCE is in the Wild

Summmary

A new critical remote code execution (RCE) vulnerability, CVE-2025-24813, affecting Apache Tomcat servers is being actively exploited in the wild. Attackers can achieve full server takeover with a single PUT API request. The exploit, initially published on a Chinese forum, leverages Tomcat’s default session persistence and partial PUT request support. The attack occurs in two steps: first, a malicious serialized Java session file containing a base64-encoded ysoserial gadget chain is uploaded via a PUT request. Second, a GET request with a JSESSIONID referencing the uploaded malicious session triggers deserialization, leading to remote code execution. Traditional Web Application Firewalls (WAFs) often fail to detect this attack due to the seemingly normal PUT request, base64 encoding of the payload, and the two-step nature of the exploit. Wallarm’s API security platform can detect and block such attacks by decoding payloads, inspecting serialized objects, and tracking multi-step attacks. The first attack was observed by Wallarm on March 12th, prior to the public release of the exploit. The article warns of potential future exploits abusing Tomcat’s partial PUT handling for broader malicious activities. Real-time API security with deep inspection capabilities is highlighted as the necessary defense against this and evolving threats.

Technical Details

The CVE-2025-24813 exploit takes advantage of Tomcat’s default file-based session storage and its ability to handle partial PUT requests. The attack unfolds in two distinct phases:

  • Step 1: Malicious Session Upload: An attacker crafts a PUT request that contains a malicious payload. This payload is a serialized Java object generated using a tool like ysoserial. The serialized object is designed to execute arbitrary code upon deserialization. To evade basic security filters, this payload is base64-encoded within the PUT request. The target URL for this PUT request would typically be within Tomcat’s session management context, allowing the server to store the uploaded data as a session file within its designated session storage directory.

  • Step 2: Triggering Deserialization: Once the malicious session file is written to disk, the attacker sends a subsequent GET request to the vulnerable Tomcat server. The crucial part of this request is the JSESSIONID cookie. The attacker sets the value of this cookie to match the ID of the malicious session file that was uploaded in the first step. When Tomcat receives this GET request, it checks the JSESSIONID. Finding a corresponding session file in its storage, Tomcat attempts to deserialize the contents of this file. Because the file contains the malicious serialized Java object (the ysoserial gadget chain), this deserialization process leads to the execution of the embedded Java code, granting the attacker full remote code execution (RCE) on the Tomcat server.

This exploit is particularly dangerous because it requires no prior authentication. The only prerequisite is that the targeted Tomcat server must be configured to use file-based session storage, a common default setting. Furthermore, the base64 encoding of the payload makes it difficult for traditional Web Application Firewalls (WAFs) to detect the malicious content within the PUT request using simple pattern matching. The two-step nature of the attack also contributes to WAF evasion, as the malicious code is not present in the initial PUT request but is only activated during the deserialization triggered by the subsequent GET request. Most legacy WAFs lack the capability to deeply inspect uploaded files or correlate events across multiple HTTP requests to identify such multi-stage attacks.

Wallarm’s API security platform demonstrates a more effective approach by decoding base64-encoded payloads before analysis, allowing the detection of hidden malicious content. Additionally, it can unpack and inspect serialized Java objects, enabling the identification of known exploits like those generated by ysoserial. By tracking multi-step attacks, Wallarm can recognize the correlation between a session file upload and a subsequent request that triggers its malicious deserialization. This proactive approach allows for real-time blocking of the malicious PUT request, preventing the session file from ever being used to execute code. The first instance of this attack was detected by Wallarm on March 12th, 2024, originating from Poland, even before the public disclosure of the exploit. The article also warns that the underlying issue of partial PUT handling in Tomcat could be exploited in the future to upload other types of malicious files, such as JSP files, allowing for different attack vectors beyond session hijacking.

Observed commands:

  • PUT /<session-storage-path>/<session-id>.session HTTP/1.1
  • Payload within the PUT request: base64(serialized_java_object(ysoserial_gadget_chain))
  • GET / HTTP/1.1 Host: vulnerable.host:8080 Cookie: JSESSIONID=<session-id>

Countries

  • Poland

Industries

  • Not specified in the source.

Recommendations

  • Move beyond reactive security measures that rely on waiting for CVEs and adding WAF rules after an exploit is known.
  • Implement real-time API security solutions capable of detecting and blocking threats as they occur.
  • Adopt security platforms that perform deep analysis of every request, rather than just pattern matching.
  • Ensure the security solution can decode and unpack payloads, including base64 and serialized objects, to expose hidden exploits.
  • Utilize solutions that can track and block multi-step attacks, even when obfuscation techniques are employed.
  • Consider disabling or hardening the use of file-based session storage if feasible (though this is not explicitly recommended in the article, it’s a general security practice related to session management).
  • Immediately investigate any unusual PUT requests targeting session storage directories.
  • Monitor for GET requests with JSESSIONID values that might correspond to previously uploaded unusual content.

Hunting methods

Due to the nature of the attack, traditional signature-based hunting might be challenging. However, the following logic can be used to develop hunting methods:

  • Focus on anomalous PUT requests: Look for PUT requests that are writing files to Tomcat’s session storage directory with unusual characteristics.
    • Analyze the size and content type of files being written via PUT requests.
    • Look for PUT requests with payloads that are base64-encoded and have characteristics of serialized Java objects.
  • Correlate PUT and GET requests: Investigate sequences where a PUT request writes a file to session storage, followed by a GET request with a JSESSIONID that matches the written file’s ID.
  • Deep packet inspection (if possible): Analyze the decoded content of PUT request bodies for known patterns or signatures associated with ysoserial or other Java deserialization exploits.
  • Monitor Tomcat logs: Look for unusual activity related to session creation and retrieval, especially in conjunction with PUT requests.

Specific query examples cannot be provided without knowing the specific log format and capabilities of the SIEM or hunting platform. However, the logic above outlines the key aspects to focus on. A security solution capable of the real-time API security features described by Wallarm would be the most effective way to proactively hunt for and block this type of attack.

IOC

IP Addresses:
195.183.###.###

Domains:
vulnerable.host:8080
java.net

Original link: https://lab.wallarm.com/one-put-request-to-own-tomcat-cve-2025-24813-rce-is-in-the-wild/

Remotely Exploitable AMI MegaRAC Vulnerabilities

Summmary

Eclypsium researchers have discovered a new remotely exploitable authentication bypass vulnerability (CVE-2024-54085) in AMI’s MegaRAC software affecting the Redfish interface. This vulnerability is similar to a previously patched issue (CVE-2023-34329) and allows attackers to bypass authentication remotely, potentially leading to full control of compromised servers. The vulnerability resides in the host-interface-support-module.lua file within the firmware. Successful exploitation can result in account creation, exposure of the Web UI and BMC features, malware deployment, ransomware, firmware tampering, bricking, and denial-of-service conditions. A Shodan search revealed approximately 1,000 exposed instances on the public internet. Several HPE Cray XD670, Asus RS720A-E11-RS24U, and an ASRockRack device are confirmed to be vulnerable, and more devices/vendors are likely affected. The vulnerability stems from how the “X-Server-Addr” or “Host” headers are processed and compared against data in a Redis database. Patches have been released by AMI to OEM vendors who need to incorporate them into their updates. Organizations are advised to ensure BMC interfaces are not exposed, apply updates, monitor for compromises, and perform supply chain checks. The CVSSv3 score is rated as 10.0 when Redfish is internet-exposed and 9.6 when access is adjacent.

Technical Details

The vulnerability, CVE-2024-54085, is an authentication bypass in the Redfish interface of AMI MegaRAC software. It builds upon the findings of CVE-2023-34329, indicating a potential incomplete fix or another underlying issue. The vulnerable code is located in the /usr/local/redfish/extensions/host-interface/host-interface-support-module.lua file within the firmware filesystem.

The vulnerability lies in the check_host_interface_connection function. This function attempts to verify the host interface connection by comparing the X-Server-Addr header (or the Host header if X-Server-Addr is not present) of an incoming request against IP addresses stored in a Redis database.

The critical part of the code is the following line:

string.match(uv1.strip_ipv4_mapped_ipv6(slot0:get_request().headers:get("X-Server-Addr") or slot0:get_request().headers:get("Host")), "([^:]+)") == slot7

This code extracts everything up to the first colon (:) from the X-Server-Addr or Host header using the string.match(..., "([^:]+)") regular expression.

The lighttpd web server used by MegaRAC will automatically add an X-Server-Addr header with the Redfish interface’s address. However, if an attacker includes their own X-Server-Addr header in the request, lighttpd prepends a comma and a space to its own header value. For example:

X-Server-Addr: <user-supplied-value>, ::ffff:1.2.3.4

Due to the string.match function, only the portion of the user-supplied value before the first colon is compared against the database entries. The default IP address in the database is often 169.254.0.17.

An attacker can bypass authentication by crafting a request with an X-Server-Addr header that starts with an IP address present in the Redis database, followed by a colon. For instance, by setting X-Server-Addr: 169.254.0.17:. The string.match function will extract 169.254.0.17, which will match the database entry, successfully bypassing authentication.

Successful bypass allows for unauthenticated access to the Redfish interface. On a vulnerable HPE Cray XD670 1.17 system, this was confirmed to allow account creation via a crafted POST request to /redfish/v1/AccountService/Accounts with the malicious X-Server-Addr header. This, in turn, exposes the Web UI login and all remote BMC features.

In some non-default configurations, the Redis database may contain additional IP addresses obtained via specific IPMI commands, which can also be exploited using the same technique.

The impact of this vulnerability is significant. An attacker can gain remote control of the server, potentially leading to malware and ransomware deployment, firmware tampering (BMC and potentially BIOS/UEFI), bricking of motherboard components, physical server damage (over-voltage), and indefinite reboot loops. In data center environments, attackers could potentially leverage the vulnerability to send malicious commands to other BMCs on the same management segment, causing widespread disruption.

The CVSSv3 score reflects the severity, with a 10.0 rating for internet-exposed Redfish interfaces (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) and 9.6 for adjacent network access (AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H).

The vulnerability affects several devices, including:

  • HPE Cray XD670 (firmware versions 1.09, 1.13, 1.17)
  • Asus RS720A-E11-RS24U
  • An ASRockRack device And likely more due to the vulnerability’s location at a junction of multiple internal components.

AMI has released patches to OEM vendors.

Countries

  • United States
  • China
  • Germany
  • Korea, Republic of
  • United Kingdom (Based on the location of exposed MegaRAC instances found via Shodan)

Industries

  • Organizations with large server farms
  • Data centers
  • Cloud & hosting providers
  • Hyper-scaler environments
  • VDI environments
  • Fortune 500 companies hosting their own data centers

Recommendations

  • Ensure that all remote server management interfaces (e.g., Redfish, IPMI) and BMC subsystems are not exposed externally.
  • Restrict internal access to administrative users with ACLs or firewalls.
  • Perform regular software and firmware updates on servers, prioritizing the application of patches released by vendors for this vulnerability. Note that patching may require device downtime.
  • Ensure that all server firmware is regularly monitored for indicators of compromise or unauthorized modifications.
  • Monitor logs for unexpected behavior such as new account creation.
  • Perform supply chain checks of new equipment. Verify that new servers have high-severity vulnerabilities patched and the latest firmware updates installed.
  • Consider the joint guidance from CISA and NSA on hardening Baseboard Management Controllers (BMCs).
  • Eclypsium customers can leverage their platform to detect this vulnerability.

Hunting methods

  • Inspect network traffic for HTTP requests to the Redfish interface (/redfish/v1/) with a modified X-Server-Addr header. Specifically, look for headers where the value starts with a known or internal IP address followed by a colon (:) and potentially other values.
  • Monitor Redfish logs for successful authentication attempts originating from requests with suspicious X-Server-Addr or Host headers.
  • Analyze firmware images of AMI MegaRAC-based devices for the presence of the vulnerable host-interface-support-module.lua file and the specific code patterns in the check_host_interface_connection function.
  • Monitor for unexpected account creation events through the Redfish interface. This could indicate successful exploitation.
  • Look for PUT requests to Redfish endpoints that might be attempting to modify system configurations after a potential authentication bypass.

Logic of the query (example for network traffic monitoring): The goal is to identify HTTP GET or POST requests targeting the Redfish API where the X-Server-Addr header contains a known internal IP address followed by a colon. This pattern suggests a potential attempt to exploit the authentication bypass.

// Example pseudo-query for network traffic logs
SELECT *
FROM network_logs
WHERE destination_port IN (80, 443) // Common HTTP/HTTPS ports for Redfish
  AND uri LIKE '/redfish/v1/%'
  AND (
    http_request_headers LIKE '%X-Server-Addr:169.254.0.17:%' OR // Default IP
    http_request_headers LIKE '%X-Server-Addr:192.168.%:%' OR // Common private range
    http_request_headers LIKE '%X-Server-Addr:10.%:%'    OR // Common private range
    http_request_headers LIKE '%X-Server-Addr:172.16.%:%' OR // Common private range
    http_request_headers LIKE '%Host:169.254.0.17:%'      OR // If X-Server-Addr is absent
    http_request_headers LIKE '%Host:192.168.%:%'        OR
    http_request_headers LIKE '%Host:10.%:%'             OR
    http_request_headers LIKE '%Host:172.16.%:%'        OR
    http_request_headers LIKE '%X-Server-Addr: <internal_ip>:%' OR // Replace with known internal IPs
    http_request_headers LIKE '%Host: <internal_ip>:%'    // Replace with known internal IPs
  );

This is a basic example and would need to be adapted to the specific syntax and capabilities of the network monitoring tools being used. It also requires knowledge of the internal IP address ranges used in the environment.

IOC

File Hashes:
N/A (The vulnerability is in a Lua script within the firmware)

IP Addresses:
169.254.0.17 (Default potential IP in Redis database)

Original link: https://eclypsium.com/blog/ami-megarac-vulnerabilities-bmc-part-3/

Threat Assessment: GitHub Actions Supply Chain Attack: The Compromise of tj-actions/changed-files

Summmary

The article details a recent supply chain attack involving the compromise of the tj-actions/changed-files GitHub Action, which is used by over 23,000 repositories. Attackers injected malicious code into tagged releases of the action by modifying them to point to a dangling commit containing a payload designed to extract CI/CD secrets from the runner’s memory and expose them in workflow logs. The attack was facilitated by the compromise of a GitHub Personal Access Token (PAT) belonging to the @tj-actions-bot account and a lack of security controls in the affected repository, such as the absence of signed commits and branch/tag protection rules. The compromise is believed to have originated from a prior compromise of the reviewdog/action-setup repository, which indirectly impacted tj-actions/changed-files through its dependency on tj-actions/eslint-changed-files, leading to the compromise of additional actions within the reviewdog organization. The malicious activity occurred between 9 a.m. PT March 14, 2025, and 3 p.m. PT March 15, 2025, affecting workflows using vulnerable tags or branches of the compromised actions. The exposed secrets, printed double-encoded in Base64 in public workflow logs, could grant attackers unauthorized access and the ability to tamper with code. The incident highlights the significant risks associated with third-party dependencies in CI/CD pipelines and underscores the need for robust security measures. Palo Alto Networks’ products can help identify and mitigate such risks.

Technical Details

The attack was executed by gaining unauthorized access to the tj-actions/changed-files GitHub repository. Instead of directly modifying the visible source code, the attackers manipulated historical version tags. They altered these tags to point to a specific, malicious commit with the SHA1 hash 0e58ed8671d6b60d0890c21b07f8835ace038e67. This ensured that existing workflows pulling nearly all release versions of the action would inadvertently execute the compromised code.

The attackers leveraged a leaked GitHub Personal Access Token (PAT) associated with the @tj-actions-bot account to push the malicious commit. They also impersonated another user account, renovate[bot], to make the commit appear legitimate. The success of this operation was facilitated by the lack of security controls in the tj-actions/changed-files repository, specifically the absence of required signed commits and branch and tag protection rules.

The malicious commit contained a Python script designed to extract CI/CD secrets from the memory of the GitHub Actions runner. These secrets were then printed directly into the workflow logs, double-encoded in Base64 text. Because these logs are often public for public repositories, the exposed secrets became accessible to anyone. The types of secrets potentially exposed include API keys, access tokens, deployment credentials, and the unique GITHUB_TOKEN generated for each workflow run. A GITHUB_TOKEN with ‘write’ permissions could allow an attacker to push malicious code into the repository, potentially impacting the production environment.

The attack chain suggests an initial compromise of the reviewdog/action-setup action. Malicious code was pushed to this action, which was an indirect dependency of tj-actions/changed-files via the tj-actions/eslint-changed-files action. This indicates that tj-actions/eslint-changed-files was also compromised, and further investigation revealed that additional actions belonging to the reviewdog organization were also hijacked. Therefore, any repository or action within the reviewdog organization is considered risky to use until the investigation concludes.

The timeframe of the malicious activity was between 9 a.m. PT March 14, 2025, and 3 p.m. PT March 15, 2025. The impact was limited to GitHub Actions workflows that:

  • Referenced either tj-actions/changed-files or tj-actions/eslint-changed-files.
  • Pointed to one of the vulnerable tags or branches.
  • Executed within the specified timeframe.
  • Involved any actions created by the reviewdog organization.

The fact that the payload printed the secrets to the workflow logs, rather than sending them to an external location, raises questions about the attacker’s motives.

Industries

The article does not explicitly mention targeted industries, but any organization using GitHub Actions and the compromised dependencies could be affected. This potentially includes a wide range of industries involved in software development and deployment.

Recommendations

The article provides several recommendations for mitigating the risks associated with this type of attack:

Immediate Steps for Affected Users:

  • Identify usage: Search repositories for the use of tj-actions/changed-files and other mentioned actions.
  • Review workflow logs: Examine past workflow runs for evidence of secret exposure, particularly if logs are public, looking for Base64 encoded text.
  • Rotate secrets: Revoke and regenerate any credentials that may have been exposed, including API keys, access tokens, and deployment credentials.
  • Investigate malicious activity: If there are signs of the compromised action being executed, investigate further for any other indicators of malicious activity.

Long-Term Security Improvements:

  • Govern third-party services in use: Implement vetting procedures to ensure external actions are approved before integration.
  • Implement strict Pipeline-Based Access Controls (PBAC): Reduce permissions granted to GitHub Actions workflows to the minimum necessary and use fine-grained, short-lived tokens instead of long-term, broadly scoped secrets.
  • Pin GitHub actions: Instead of referencing by tag or branch (e.g., @v3 or @main), pin actions to a full-length commit SHA-1 hash to ensure code immutability.
  • Use verified actions.
  • Restrict the usage of GitHub actions allowed in the repository/organization, potentially limiting them to Enterprise actions.
  • Avoid defining read-all or write-all permissions for the GITHUB_TOKEN in pipeline configurations.
  • Avoid using insecure long-term credentials for cloud provider access from GitHub Actions.
  • Utilize OpenID Connect (OIDC) authentication to replace long-term credentials with short-lived access tokens for interacting with cloud providers.

Palo Alto Networks customers are advised to refer to specific out-of-the-box policies in their Prisma Cloud or Cortex Cloud environments related to unpinned GitHub actions, unrestricted usage of GitHub actions, and excessive pipeline permissions.

Hunting methods

The article suggests the following hunting methods:

  • Identify usage: Search for the specific GitHub Actions (tj-actions/changed-files and actions from the reviewdog organization) within repository configurations and workflow files. The logic is to determine the scope of potential impact.

  • Review workflow logs: Examine workflow execution logs within the timeframe of the attack (March 14-15, 2025) for any unusual activity or the presence of secrets printed in Base64 encoded format. The logic is to identify potential exfiltration of sensitive information.

  • Palo Alto Networks Protections: Prisma Cloud and Cortex Cloud can identify the usage of the vulnerable action in pipelines. They also offer policies to detect unpinned GitHub actions and excessive pipeline permissions. The logic is to leverage existing security tools to identify and flag potentially vulnerable configurations and past execution of the malicious code.

While the article does not provide specific Yara, Sigma, KQL, or SPL queries, the principles of the attack can inform the development of such queries. For example, one could create a query to search for specific patterns in GitHub Actions workflow logs within the identified timeframe that might indicate the execution of the malicious payload and the printing of Base64 encoded secrets.

Logic for a potential log hunting query: The goal would be to identify workflow logs executed between March 14th and 15th, 2025, that contain Base64 encoded strings, potentially indicating the exfiltration of secrets by the malicious script. This would need to be correlated with workflows using the compromised actions.

// Example pseudo-query for workflow logs
SELECT *
FROM github_actions_workflow_logs
WHERE repository LIKE '%/%' // Assuming a way to identify repositories
  AND workflow_file LIKE '%.yml' // Common workflow file extension
  AND job_started_at >= '2025-03-14T09:00:00Z'
  AND job_completed_at <= '2025-03-15T15:00:00Z'
  AND log_output LIKE '%[A-Za-z0-9+/=]{50,}%' // Basic regex for potential Base64
  AND (
    workflow_uses LIKE '%tj-actions/changed-files%' OR
    workflow_uses LIKE '%tj-actions/eslint-changed-files%' OR
    workflow_uses LIKE '%reviewdog/%'
  )

This is a basic example and would require adaptation based on the specific logging format and querying capabilities of the platform used to store and analyze GitHub Actions workflow logs. More sophisticated queries could look for patterns of commands or keywords known to be associated with secret extraction or other malicious activities.

IOC

File Hashes:
0e58ed8671d6b60d0890c21b07f8835ace038e67

Original link: https://unit42.paloaltonetworks.com/github-actions-supply-chain-attack/

ZDI-CAN-25373: Windows Shortcut Exploit Abused as Zero-Day in Widespread APT Campaigns

Summmary

Trend Zero Day Initiative™ (ZDI) discovered the widespread exploitation of ZDI-CAN-25373, a zero-day vulnerability in Windows .lnk files that allows attackers to execute hidden malicious commands. This vulnerability is abused by both state-sponsored and cybercriminal groups. Attackers craft malicious .lnk files that use hidden command line arguments within the files to execute malicious payloads, making detection difficult. The exploitation of this vulnerability poses significant risks of data theft and cyber espionage to organizations. Eleven state-sponsored APT groups from North Korea, Iran, Russia, and China have been identified exploiting this vulnerability since at least 2017. Affected sectors include government, financial, telecommunications, military, and energy across various regions globally. Microsoft declined to issue a security patch for this vulnerability after it was reported through Trend ZDI’s bug bounty program. Trend Micro customers have had protections in place since October 2024 and January 2025.

Technical Details

alt text The ZDI-CAN-25373 vulnerability lies in how Windows displays the contents of shortcut (.lnk) files in the user interface. Attackers craft .lnk files with padded whitespace characters within the COMMAND_LINE_ARGUMENTS structure. The whitespace characters used for this padding include Space (\x20), Horizontal Tab (\x09), Line Feed (\x0A), Vertical Tab (\x0B), Form Feed (\x0C), and Carriage Return (\x0D). When a user inspects such a file, Windows fails to display the malicious arguments in the Target field of the shortcut’s properties, effectively hiding the commands that will be executed.

The Shell Link (.lnk) file format is a binary file used by Windows as a shortcut to files, folders, or applications. Threat actors favor this file type because command line arguments can be embedded within the Target field, leading to code execution. Every .lnk file begins with a ShellLinkHeader structure, containing mandatory fields like HeaderSize (0x0000004C) and LinkCLSID (00021401-0000-0000-C000-000000000046), which can act as magic bytes to identify .lnk files.

Following the header is the LinkFlags structure, which specifies the presence of other structures, including HasArguments. When HasArguments is set, the COMMAND_LINE_ARGUMENTS structure is present, storing the command line arguments executed when the shortcut is activated. Threat actors abuse this by adding malicious commands to download and execute payloads using tools like cmd.exe or powershell.exe.

The ICON_LOCATION structure is also commonly abused to change the .lnk file’s icon, often using spoofed extensions like .pdf.lnk with a matching icon to trick users.

The core of the ZDI-CAN-25373 exploit involves padding the COMMAND_LINE_ARGUMENTS structure with whitespace characters. Using Space (\x20) or Horizontal Tab (\x09) padding results in a seemingly empty Target field in the shortcut’s properties. Padding with Line Feed (\x0A) and Carriage Return (\x0D) can result in a single highlightable character in the Target field, further concealing the malicious commands. Some North Korean APT groups, such as Earth Manticore (APT37) and Earth Imp (Konni), have used extremely large .lnk files with significant amounts of whitespace and junk content to evade detection. Earth Imp’s malicious .lnk files had a median size of 3.32MB, with a maximum of 70.1MB, while Earth Manticore’s had a median of 33.33MB and a maximum of 55.16MB.

The exploitation of ZDI-CAN-25373 is classified as a User Interface (UI) Misrepresentation of Critical Information (CWE-451), as it prevents users from seeing the critical commands being executed, hindering their ability to assess the file’s risk.

Observed malware payloads and loaders in these campaigns include MaaS (Malware-as-a-Service), PoC (Proof-of-Concept), Lumma Stealer, GuLoader, and Remcos. Notably, Water Asena (Evil Corp) has been observed exploiting ZDI-CAN-25373 in their Raspberry Robin campaigns.

Countries

Countries of Origin of State-Sponsored APT Groups Exploiting ZDI-CAN-25373:

  • North Korea
  • Iran
  • Russia
  • China

Affected Regions (by file submission origin):

  • North America (primarily US and Canada)
  • Europe
  • Asia (East Asia)
  • South America
  • Australia
  • Africa

Industries

Sectors identified as being at particular risk for targeted attacks exploiting ZDI-CAN-25373 include:

  • Government
  • Private
  • Financial (including cryptocurrency-related)
  • Think tanks (including NGOs)
  • Telecommunications
  • Military and defense
  • Energy

Recommendations

Organizations should take the following immediate actions:

  • Immediately scan and ensure security mitigations for ZDI-CAN-25373.
  • Maintain vigilance against suspicious .lnk files in general.
  • Ensure comprehensive endpoint and network protection measures are in place to detect and respond to this threat.
  • Investigate potential compromise or attempts to compromise systems using ZDI-CAN-25373 as an intrusion vector.
  • When faced with uncertain intrusions, behaviors, and routines, assume that the system is already compromised or breached and immediately isolate affected data or toolchains.
  • Deploy robust Endpoint and Network Security solutions for broader perspective and rapid response.

Trend Micro customers have the following protections available:

  • Trend Vision One™ - Network Security:
    • TippingPoint Intrusion Prevention Filter: 44844 - ZDI-CAN-25373: Zero Day Initiative Vulnerability (Microsoft Windows) (released)
    • Trend Micro Deep Discovery Inspector (DDI) Relevance Rule: 5351 - ZDI-CAN-25373 Microsoft Windows Zero Day Vulnerability - HTTP(Response) (available March 20, 2025)
    • Network Sensor Relevance Rule: 5351 - ZDI-CAN-25373 Microsoft Windows Zero Day Vulnerability - HTTP(Response) (available March 20, 2025)
  • Trend Vision One™ - Cloud and Endpoint Security:
    • Trend Micro™ Deep Security™ and Cloud Workload Security Intrusion Prevention Rules:
      • 1012182 - Microsoft Windows Zero Day Vulnerability Over HTTP (ZDI-CAN-25373)
      • 1012183 - Microsoft Windows Zero Day Vulnerability Over SMB (ZDI-CAN-25373)
  • Leverage Trend Vision One Threat Intelligence, including Threat Insights, for information on threat actors, their activities, and techniques.
  • Utilize the Trend Vision One Intelligence Reports App for IOC sweeping and the Threat Insights App for emerging threat information related to ZDI-CAN-25373.

Hunting methods

Trend Vision One Search App Queries:

  • Detect suspicious cmd.exe or powershell.exe execution from LNK files: 
    eventSubId:2 AND (processFilePath:\"*\\cmd.exe\" OR processFilePath:\"*\\powershell.exe\") AND parentFilePath:\"*.lnk\"

    Logic: This query searches for events (identified by eventSubId:2) where cmd.exe or powershell.exe are executed (processFilePath) and their parent process is a .lnk file (parentFilePath). This helps identify potential malicious command execution initiated by a shortcut file.

Yara Threat Hunting Rule:

rule ZTH_LNK_EXPLOIT_A {
  meta:
    author = "Peter Girnus"
    description = "This YARA file detects padded LNK files designed to exploit ZDI-CAN-25373."
    reference = "<LINK_TO_BLOG>"
    target_entity = "file"
  strings:
    $magic = {4C 00 00 00 01 14 02 00} // Magic bytes for .lnk file
    $spoof_a = {20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00} // Padding with Space
    $spoof_b = {09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00 09 00} // Padding with Horizontal Tab
    $spoof_c = {0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00 0A 00} // Padding with Line Feed
    $spoof_d = {0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00 0D 00} // Padding with Carriage Return
    $spoof_e = {11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00} // Padding with Vertical Tab
    $spoof_f = {12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00 12 00} // Padding with Form Feed
    $spoof_g = {13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00 13 00} // Unknown padding (value 0x13)
    $spoof_h = {0D 00 0A 00 0D 00 0A 00 0D 00 0A 00 0D 00 0A 00 0D 00 0A 00 0D 00 0A 00 0D 00 0A 00 0D 00 0A 00 0D 00 0A 00 0D 00 0A 00 0D 00 0A 00 0D 00 0A 00 0D 00 0A 00 0D 00 0A 00 0D 00 0A 00 0D 00 0A 00 0D 00 0A 00 0D 00 0A 00 0D 00 0A 00 0D 00 0A 00 0D 00 0A 00} // Padding with Carriage Return and Line Feed
  condition:
    $magic at 0x00 and ($spoof_a or $spoof_b or $spoof_c or $spoof_d or $spoof_e or $spoof_f or $spoof_g or $spoof_h)
}

Logic: This YARA rule is designed to detect .lnk files exploiting ZDI-CAN-25373. It first checks for the magic bytes ($magic) at the beginning of the file (offset 0x00), which identify it as a .lnk file. Then, it looks for the presence of various padding sequences ($spoof_a to $spoof_h) consisting of different whitespace characters (Space, Horizontal Tab, Line Feed, Carriage Return, Vertical Tab, Form Feed, and combinations) with null bytes in between. These padding sequences are characteristic of the exploit, as they are used to hide the malicious command-line arguments within the .lnk file’s COMMAND_LINE_ARGUMENTS structure. If a file matches both the magic bytes and one of the defined padding patterns, the YARA rule will trigger, indicating a potential exploitation attempt.

Original link: https://www.trendmicro.com/en_us/research/25/c/windows-shortcut-zero-day-exploit.html