Silent attack: malicious NuGet packages point to ASP.NET to exfilter identities and open back doors

Security researchers have dug up a sophisticated campaign aimed at ASP.NET application developers who, far from looking for noisy infections on programmers' teams, aim at a more valuable and silent goal: the applications that those developers build. According to the report published by Socket, four malicious packages published in NuGet between 12 and 21 August 2024 acted together to filter ASP.NET identity data and to install persistent back doors in deployed applications.

The packages, published by the profile hamzazaheer they received more than 4,500 downloads before they were removed after the responsible disclosure. Their names - including variants such as NCryptyo, DOMOAuth2 _, IRAOAuth2.0 and SimpleWriter _- hide very different behaviors: from a "dropper" that activates the engagement chain to components that extract the identity tables, roles and permissions of ASP.NET Identity and that accept authorization rules sent by the attacker to grant privileges.

In essence, the campaign uses a first stage executable embedded in one of the packages (NCryptyo) that is activated when the bookstore is loaded into the application. This module installs hooks in the .NET JIT compiler to decrypt and deploy a secondary payload: a local proxy that listens to in localhost: 7152 and redirects traffic to a control and control server whose direction is dynamically resolved in the execution time. Through this local tunnel, the other packages begin to send sensitive information of identities and permissions abroad; the remote infrastructure can then respond with new rules of authorization that the application processes, allowing the attacker to create administrative accounts or disable security checks in production environments.

The package presented as PDF conversion utility, SimpleWriter _, it incorporates disturbing capabilities of unconditional writing in disk and hidden process execution, allowing the attacker to leave additional executables on the victim machine and start them without visible windows. The analysis of metadata and the compilation environment suggests that all packages come from the same actor, as they share identical construction prints.

It is important to highlight the vector by which it is acted: it is not just intended to compromise the workstation of the developer, but handling the authorisation layer during development to control deployed applications. When the application with malicious dependencies comes to production, the channel to the C2 can remain active and continue to exfilter permissions data and receive rules that give administrative access to any deployed instance.

This type of attack is another variation of the broader problem of the software supply chain: third-party components that seem harmless and are incorporated into projects end up being the way into critical systems. By comparison, Tenable reported another recent case in the npm ecosystem: a package called ambar-src which took advantage of the installation hook ( preinstall) to run malicious code on Windows, Linux and macOS and download chargers that gave remote access to the attacker. Tenable research details how these installers downloaded and executed binaries or scripts that, in different systems, deployed from shellcodes in memory to frameworks-based agents like Mythic, and exfiltered data to domains in cloud services to camouflage their traffic ( Tender).

The risks are clear: when a third party unit can change the logic of authorisation or install persistent processes, the integrity of the application and its users is compromised. For those who develop with ASP.NET, it is crucial to understand that exfiltration in these incidents focuses on the objects and structures that manage authentication and authorization - for example, the tables and schemes that it manages ASP.NET Identity- and that the presence of unreliable code in the construction cycle can allow the attacker to change those rules from the outside.

In view of this reality, hygiene practices should be strengthened in the management of units and the supply chain. Maintain an inventory of components and a SBOM, validate the source of signed packages and prefer signed artifacts, audit and scan units with specialized tools, isolate the construction processes and control the outgoing traffic from the CI / CD pipelines are measures that reduce the attack surface. In addition, lower privileged policies in the development and manual review of bookstore changes that interact with authentication and access rules help to detect anomalies before they reach production. In order to deepen controls and general recommendations on security in the supply chain, agency guides such as CISA They're useful.

Other technical resources are also relevant: Microsoft offers documentation on signing packages and best practices to consume packages in .NET environments ( package signature in NuGet), and open source projects and security providers continue to improve detections for these behaviors. In addition, research and tools that analyze JIT hooks, suspicious local proxies or executions at the time of loading are increasingly necessary to identify patterns such as those described by Socket and Tenable.

If you suspect that you have used any of these packages or any other unexpectedly acting, consider treating the system as potentially compromised: it eliminates the dependencies, reviews logs and authorization configurations, breaks credentials and secrets, and performs a forensic analysis if there are signs of unauthorized access. As a technical and operational reminder, the security of an application does not start or end in its source code: the bookstores and the process by which they come to your project matter as much as the code you write.

The community and package platforms are attentive and respond by removing malicious artifacts, but experience shows that pre-removal downloads can leave facilities in numerous repositories and pipelines. It is therefore essential that development, operations and security teams work together to identify and mitigate threats in the supply chain before they reach production.