The Axios npm supply chain incident: fake dependency, real backdoor
嗯,用户让我总结一下这篇文章的内容,控制在100个字以内,而且不需要用“文章内容总结”这样的开头。首先,我需要仔细阅读文章,理解主要事件和关键点。 文章讲的是Axios的两个恶意版本被发布到npm上,通过被入侵的维护者账户。这两个版本添加了一个带有后门脚本的恶意依赖项,导致了远程访问木马的传播。虽然这些包很快被移除了,但还是影响了多个开发者工作站和Docker容器。文章还提到了检测到的行为、狩猎查询以及推荐的应对措施。 接下来,我需要将这些信息浓缩到100字以内。要抓住主要事件:Axios版本被恶意发布、依赖项后门、RAT传播、影响范围以及应对措施。 可能会遗漏一些技术细节,比如具体的IOC或查询,但这些不是总结的重点。重点是事件的影响和处理建议。 最后,确保语言简洁明了,不使用复杂的术语,让读者一目了然。 </think> 2026年3月31日,Axios的两个恶意版本通过被入侵的维护者账户发布到npm。这些版本包含一个带有后门脚本的恶意依赖项,导致远程访问木马传播至开发者工作站和Docker容器。事件引发安全警报,并建议组织加强供应链安全、监控异常活动并修复受影响系统。 2026-4-3 09:24:56 Author: blog.nviso.eu(查看原文) 阅读量:9 收藏

On March 31, 2026, two malicious Axios versions (1.14.1 and 0.30.4) were briefly published to npm via a compromised maintainer account. The only change performed was the addition of a trojanized dependency, whose postinstall script deployed a cross‑platform RAT (for macOS, Windows, and Linux). Although the Axios packages were removed within hours, multiple hits were observed in our MDR service, mainly across developer workstations and Docker containers. In this blog post, we briefly walk through the details of the incident, share our observations, and provide KQL hunting queries used to identify and assess exposure across our MDR customers.

Brief Incident Summary

An adversary obtained access to the lead maintainer’s npm account and managed to publish two Axios versions (1.14.1 and 0.30.4). Both of these versions injected a malicious dependency under the name [email protected] with a postinstall dropper (setup.js) [1].

The dropper fetched OS-specific payloads from the C2 depending on the platform it was attempting to infect, and once the payload was retrieved it proceeded with clearing forensic traces and artifacts. The payloads fall under the classification of Remote Access Trojans (RAT) based on their observed capabilities (e.g., system reconnaissance, remote command execution). John Hammond from Huntress has an elaborate technical overview of these payloads in their blog post, taking a deep dive into the infection chain [2].

How the attack works
Figure 1: Technical Details of the Attack – socket.dev [1]

Evidence Observed

During these incidents, our SOC observed the following process tree. The postinstall dropper setup.js was executed via node.exe, which then initiated the rest of the process chain.

Incident process tree
Figure 2: Incident Process Tree

In a nutshell, after the execution of the postinstall script and the identification of the host OS as Windows, the location of powershell.exe binary is determined using the command where PowerShell. The binary is then copied to “C:\ProgramData\wt.exe”. Microsoft Defender for Endpoint (MDE) detects this activity, as copying the PowerShell binary to “C:\ProgramData\wt.exe” triggers an alert named “System executable renamed and launched“.

Subsequently, a VBS script named 6202033.vbs is created. Its purpose is to download the second stage PowerShell script 6202033.ps1, from the C2 infrastructure. The VBS script downloads and runs 6202033.ps1 (via wt.exe – the now renamed PowerShell executable) and immediately deletes itself. The PowerShell script is also deleted after its execution.

Key behaviors we observed from the second stage PowerShell script are:

  1. System information discovery
    • OS version
    • File system enumeration
    • Local system enumeration
  2. Preparation for the persistence mechanism
    • Creation of “C:\ProgramData\system.bat“, a batch script that, when executed, uses PowerShell to execute commands retrieved from the C2 infrastructure
  3. Persistence mechanism created using the following registry key
    • Registry key: HKEY_CURRENT_USER\USER_SID\Software\Microsoft\Windows\CurrentVersion\Run
    • Value name: MicrosoftUpdate
    • Value data: C:\ProgramData\system.bat
  4. Communication towards the C2 infrastructure
    • hxxp[://]sfrclak[.]com:8000/6202033

The consistent reuse of the “6202033” file-naming convention (“sfrclak[.]com:8000/6202033″, 6202033.vbs, 6202033.ps1) by the attacker can be used to perform initial scoping using the Device Timeline in Defender.

Hunting Queries

Based on the information gathered thus far and the observed process chain, the following queries were compiled to assist us in scoping more of our MDR tenants who may have been impacted by this supply chain attack.

Note that the second query does not rely solely on IOCs; rather, it relies on the expected process execution steps, so further investigation may be required. That being said, the false-positive rate is expected to be low.

let Time = 7d;
let NetworksEvents = DeviceNetworkEvents
| where Timestamp > ago(Time)
| where RemoteUrl has_any ("sfrclak.com","callnrwise.com","calltan.com") or RemoteIP in ("142.11.206.73","23.254.167.216");
let ProcessEvents = DeviceProcessEvents
| where Timestamp > ago(Time)
| where ActionType == "ProcessCreated"
| where FileName == "wt.exe"
| where ProcessCommandLine has " -w hidden";
let FileEvents = DeviceFileEvents
| where Timestamp > ago(Time)
| where FileName has_any ("plain-crypto-js","6202033.ps1","6202033.vbs") or FolderPath contains @"/Library/Caches/com.apple.act.mond" or FolderPath contains "/tmp/ld.py" or SHA256 in ("e49c2732fb9861548208a78e72996b9c3c470b6b562576924bcc3a9fb75bf9ff","e10b1fa84f1d6481625f741b69892780140d4e0e7769e7491e5f4d894c2e0e09","ed8560c1ac7ceb6983ba995124d5917dc1a00288912387a6389296637d5f815c","f7d335205b8d7b20208fb3ef93ee6dc817905dc3ae0c10a0b164f4e7d07121cd","59336a964f110c25c112bcc5adca7090296b54ab33fa95c0744b94f8a0d80c0f","5bb67e88846096f1f8d42a0f0350c9c46260591567612ff9af46f98d1b7571cd","58401c195fe0a6204b42f5f90995ece5fab74ce7c69c67a24c61a057325af668","92ff08773995ebc8d55ec4b8e1a225d0d1e51efa4ef88b8849d0071230c9645a","617b67a8e1210e4fc87c92d1d1da45a2f311c08d26e89b12307cf583c900d101","fcb81618bb15edfdedfb638b4c08a2af9cac9ecfa551af135a8402bf980375cf");
let RegistryEvents = DeviceRegistryEvents
| where Timestamp > ago(Time)
| where RegistryKey has @"Software\Microsoft\Windows\CurrentVersion\Run"
| where RegistryValueName =~ "MicrosoftUpdate"
| where RegistryValueData =~ @"C:\ProgramData\system.bat";
union NetworksEvents, ProcessEvents, FileEvents, RegistryEvents

Kusto

let Time = 7d;
let ProcessEvents = DeviceProcessEvents
| where Timestamp > ago(Time)
| where ActionType == "ProcessCreated"
| where InitiatingProcessParentFileName in ("cscript.exe","wscript.exe")
| where InitiatingProcessFileName == "cmd.exe"
| where FileName in ("wt.exe","curl.exe") or ProcessVersionInfoOriginalFileName == "powershell.exe";
let FileEvents = DeviceFileEvents
| where Timestamp > ago(Time)
| where ActionType == "FileCreated"
| where InitiatingProcessFileName == "node.exe"
| where FileName in ("wt.exe","powershell.exe")
union ProcessEvents, FileEvents

Kusto

Recommended Actions

To reduce the risk of compromise and contain potential exposure from the malicious Axios versions, consider the following key actions:

  • Secure developer endpoints by deploying an EDR sensor and monitor for any abnormal activity (postinstall executions, unusual network beacons, script interpreter spawns).
  • Isolate any endpoint where IOC hits are observed. Reimage or restore to a known-good state, then rotate API keys, database credentials, tokens, and other sensitive secrets accessed from that system.
  • Block relevant IOCs (e.g., IP addresses, domains, hashes, URLs) across your security controls, where applicable.
  • Pin known safe versions of Axios in package-lock.json, to avoid accidental updates [3].
  • Verify recent CI/CD deployments rely only on safe Axios versions; rebuild affected images and artifacts with clean lockfiles and no cache [3].
  • Inspect lockfiles for trojanized versions ([email protected] and [email protected]) and any occurrence of plain-crypto-js (e.g., package-lock.json, yarn.lock, pnpm-lock.yaml). Ensure managed repositories use safe Axios versions [4].

In conclusion, organizations should remain vigilant for supply chain attacks, rely to pinned dependencies, and regularly review and update them with a security focus to minimize risk. Continuous monitoring and rapid response are critical to maintaining a secure development environment.

Indicators of Compromise (IOCs)

TypeIndicatorNotes
SHA25692ff08773995ebc8d55ec4b8e1a225d0d1e51efa4ef88b8849d0071230c9645acom.apple.act.mond
SHA256617b67a8e1210e4fc87c92d1d1da45a2f311c08d26e89b12307cf583c900d1016202033.ps1 (second stage)
SHA256ed8560c1ac7ceb6983ba995124d5917dc1a00288912387a6389296637d5f815c6202033.ps1 (second stage)
SHA256fcb81618bb15edfdedfb638b4c08a2af9cac9ecfa551af135a8402bf980375cfld.py
SHA256e10b1fa84f1d6481625f741b69892780140d4e0e7769e7491e5f4d894c2e0e09setup.js
SHA256f7d335205b8d7b20208fb3ef93ee6dc817905dc3ae0c10a0b164f4e7d07121cdsystem.bat
SHA256e49c2732fb9861548208a78e72996b9c3c470b6b562576924bcc3a9fb75bf9ffsystem.bat
SHA25658401c195fe0a6204b42f5f90995ece5fab74ce7c69c67a24c61a057325af668[email protected]
SHA25659336a964f110c25c112bcc5adca7090296b54ab33fa95c0744b94f8a0d80c0faxios-0.30.4.tgz
SHA2565bb67e88846096f1f8d42a0f0350c9c46260591567612ff9af46f98d1b7571cdaxios-1.14.1.tgz
Domainsfrclak[.]comC2 domain
Domaincallnrwise[.]comC2 domain
Domaincalltan[.]comC2 domain
URLhxxp[://]sfrclak[.]com:8000/6202033C2 URL
IP142[.]11[.]206[.]73C2 IP
IP23[.]254[.]167[.]216C2 IP
Table 1: Indicators of Compromise

Acknowledgements

Special thanks to Michael Athanasopoulos for his involvement & contributions in the incident’s analysis.

Sources:

[1] https://socket.dev/blog/axios-npm-package-compromised

[2] https://www.huntress.com/blog/supply-chain-compromise-axios-npm-package

[3] https://cloud.google.com/blog/topics/threat-intelligence/north-korea-threat-actor-targets-axios-npm-package?linkId=61174022

[4] https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan#code-repositories

[5] https://www.wiz.io/blog/axios-npm-compromised-in-supply-chain-attack

[6] https://www.sophos.com/en-us/blog/axios-npm-package-compromised-to-deploy-malware

Profile picture - Thomas Papaloukas

Thomas Papaloukas

Thomas works as a Senior Intrusion Analyst team lead at NVISO, focusing on incident response & operations, and enjoys fiddling with detection and reverse engineering. He likes the challenges of identifying and responding to security threats, and finding effective ways to detect & prevent them.

Panagiotis Panagopoulos

Panagiotis is a Senior Intrusion Analyst with strong SOC experience, focused on intrusion detection and response. Passionate about security and privacy, Linux, and FOSS. Hands-on, outside-the-box thinker who enjoys triaging and investigating complex security incidents, finding comfort in chaos and turning insights into actionable defenses.


文章来源: https://blog.nviso.eu/2026/04/03/the-axios-npm-supply-chain-incident-fake-dependency-real-backdoor/
如有侵权请联系:admin#unsafe.sh