Treason in your code: how a single committed package exposes the weakness of the software supply chain

Published 5 min de lectura 165 reading

A few days ago it was confirmed that the open supply chain of npm suffered a serious incident: the popular Axios package was manipulated to distribute a malicious multiplatform software, and Google has pointed out that a North Korean group known as UNC1069 would be behind the attack. Although the news jumped in several specialized media, what concerns the community is not only that such a widespread bookstore has been compromised, but the sophistication of the procedure and the ability of the attacker to operate in a scalable and stealth manner.

The mechanism used by the attackers was not to alter Axios' source code, but to take advantage of the confidence of the publishing chain. The maintainer's npm package was abducted and two manipulated versions (1.14.1 and 0.30.4) were published that added a malicious dependence called "plain-crypto-js". This unit was used by an installation hook (a postinstall defined in the file).package.json) to run code on the team of those who installed Axios: npm, by design, runs those scripts automatically after installation, which allowed a silent execution of the malicious code without touching the Axios API.

Treason in your code: how a single committed package exposes the weakness of the software supply chain
Image generated with IA.

The unit acted as a kind of vehicle to deploy a dropper JavaScript opfuscado, nicknamed SILKBELL (file called "setup.js"), which contacts a remote server and downloads the next stage according to the victim's operating system. In the Windows branch, a PowerShell-based load is delivered, in macOS a Mach-O binary written in C + + is installed, and in Linux a backdoor is provided in Python. After downloading and running the right load, the dropper does a cleaning: it eliminates traces and replaces thepackage.jsonfrom malicious dependence on a "clean" one without installation hook, which makes it difficult to detect further forensic.

The back door identified in the systems has been baptized as WAVESHAPER.V2, an evolution of a previous tool linked to the same actor. This variant expands functionalities and exploits a command and control channel with communication in JSON; it collects more information from the system and accepts orders to stop its execution, list directories and file metadata, run scripts (AppleScript, PowerShell or shell, according to platform) and even inject and run decoded binaries in memory. The malware conducts surveys to the control server every 60 seconds, and shares operational features and artifacts (such as time routes and user agent chains) that allowed security firms and Google to correlate it with UNC1069.

The attribution, although not always final, had important contributions: Elastic Security Labs was the first to detect functional similarities and Mandiant along with Google Threat Intelligence Group provided technical analyses that support the relationship between new samples and previous campaigns of the actor. The complete history is reported in multiple technical analyses and specialized news that document both the postinstall technique and the specific loads deployed: it is appropriate to review security sources for the commitment indicators and more technical context, for example in the registration of the package in npm and in reports of security specialists ( Axios page in npm, Elastic Security Labs analysis and media coverage such as The Hacker News).

What can we learn from this incident? First, that the attacks on the supply chain are evolving: they are not limited to an opportunistic script but to planned operations that combine commitment of accounts, prepositioned loads for multiple systems and mechanisms to erase prints. Experts have warned that this case should be seen as an operating pattern which can be replicated in other records and ecosystems (PyPI, NuGet, etc.), because the goal is to maximize the reach of automated building and developer units.

In practical terms, the measures that organizations and developers should take are not trivial and go through both the hygiene of the environments and safety practices in the publication and consumption of packages. It is appropriate to audit the dependency chains and block compromised versions, set (pin) secure versions in lock files aspackage-lock.jsonto prevent accidental updates, and check manually for suspected dependenceplain-crypto-jsinnode _ modules. If activity is detected, it is essential to complete malicious processes, isolate affected equipment and rotate credentials and keys that may have been exposed. In addition, blocking connections to the reported command and control domain and your associated IP helps to cut the control and control channel; traffic analysis tools and lock lists should be updated accordingly.

Beyond this reactive response, the ecosystem needs sustainable preventive measures: applying multifactor authentication in the maintenance accounts, forcing more stringent reviews of the changes that affect dependencies, generating and maintaining an SBOM (software bill of materials) to know exactly what comes into the buildings, and limiting the use of hooks that run code in installation or construction stages. It is also prudent to assume that any secret stored in the environment that published or built committed packages may have been compromised and should be rotated without delay.

Treason in your code: how a single committed package exposes the weakness of the software supply chain
Image generated with IA.

This incident is also a call for attention to the economy behind certain actors: groups with financial motivations have historically preferred campaigns against services and cryptomoneda platforms, and the observed sophistication (payloads for three systems, short-time deployment and self-destruction mechanisms) suggests an intention to operate on a large scale. The response should therefore not be limited to a specific patch, but rather to rethinking how organizations manage units and permits in their development cycle.

If you want to deepen, check the analyses published by security laboratories and intelligence providers that have documented the samples, domains and behavior patterns. Consult reliable and up-to-date sources will allow you to apply the latest commitment indicators and coordinate an appropriate response: Elastic Security Labs, Mandiant, ReversingLabs and specialized press reports such as The Hacker News are good starting points to contrast information and access IoCs lists.

In the end, the lesson is clear: confidence in a dependence is not immutable. Adopting stricter controls in the software supply chain, increasing surveillance in publishing processes and treating secret management as critical are essential steps to reduce the risk that a similar incident will affect your projects or your organization.

Coverage

Related

More news on the same subject.