Gaining initial access into enterprise environments continues to pose significant challenges for adversaries, as organizations increasingly adopt proactive security measures designed to detect, restrict, and block connections initiated from external networks. In response to these strengthened defenses, threat actors have shifted their focus toward exploiting trusted third-party relationships and software dependencies — leveraging supply chain attacks as a more effective avenue to infiltrate targeted enterprises while bypassing traditional security controls.

Supply Chain Attacks Explained

Supply-chain attacks are a tactic adversaries use to gain an initial foothold in a target enterprise by compromising third-party applications or services the organisation depends on. Even when an enterprise’s own defenses are strong, vulnerabilities or misconfigurations in those trusted components can be exploited to bypass security controls and lead to a full compromise.

Unmasking APT Groups: Supply Chain Attack Strategies

1. APT29 (Nobelium / Cozy Bear) — Compromised SolarWinds Orion updates during the 2020 supply-chain intrusion, inserting malicious code that granted wide-scale access to targeted organisations.
2. Sandworm (Russian GRU) — Delivered the destructive NotPetya attack in 2017 by exploiting the ME/doc update mechanism, making it one of the most damaging supply-chain incidents to date.
3. Winnti / APT41 (China-linked) — Known for targeting software vendors and gaming companies, frequently embedding backdoors such as ShadowPad into legitimate software updates to maintain persistent access. (Source: We Live Security)
4. Lazarus Group (North Korea) — Leveraged supply-chain techniques including trojanised developer tools, compromised installers, and malicious packages to deploy backdoors and steal credentials.
5. Barium / Wicked Panda (China-linked) — Conducted multiple high-profile intrusions by tampering with vendor build systems and legitimate installers, enabling them to infiltrate targeted enterprises via trusted software supply chains.

Anatomy of a Supply Chain Compromise

Adversaries have increasingly weaponised software packages that are frequently used by developers. If a developer or victim unknowingly downloads and installs such a malicious package, the embedded code is executed automatically. This can result in the deployment of backdoors, the exfiltration of sensitive data, or even the establishment of stable persistence through communication with command-and-control (C2) servers. Such attacks exploit the inherent trust developers place in widely used package repositories and third-party libraries, turning common development tools into vectors for compromise.

Python and its package

Packages are essentially collections of predefined functions bundled together into a single unit. Once packaged, developers or users can easily import them into their projects and invoke the associated functions. The diagram below provides a clearer illustration of this concept.

As illustrated, packages are collections of predefined functions designed to perform specific operations. For example, the package named maths includes multiple functions such as add, sub, and mul, each responsible for a different calculation. Once the maths package is imported into a project, it provides access to these built-in functions. The user simply needs to supply the required input, and the function executes accordingly, returning the desired result

Note: As of September 2025, the Python Package Index (PyPI) lists 678,726 projects

Understanding Supply Chain Compromise: Detection and Investigation Strategies

Identifying and investigating supply-chain attacks is highly complex due to significant detection gaps and the limited traces they often leave behind. As noted, weaponised packages are commonly used to deploy backdoors that establish stable communication with attacker-controlled C2 servers.

Once such a package is imported and executed within a project, it can silently compromise the environment.

To strengthen detection, defenders should focus on monitoring for

1. Monitoring suspicious process creation,
2. Inspecting and decoding Python packages to uncover hidden or malicious components.

Monitoring suspicious process creation

Initial investigations into suspicious processes can be challenging, as enterprises generate a high volume of process creation events, many of which may lead to false positives. To minimise noise, it is important to analyse the context of process execution. For instance, when Python scripts are run, they typically rely on an execution medium such as cmd or PowerShell, which can serve as valuable indicators during an investigation.

Prioritising and identifying suspicious processes requires multiple layers of correlation and analysis. Simply reviewing process creation events is not enough to confirm malicious activity; it is equally important to examine related events such as file creation and network communication. For instance, file creation activities linked to Python scripts can be particularly suspicious, as adversaries often leverage script execution to deploy backdoors or other malicious payloads.

event.code : 11 AND (process.name : "python.exe" OR process.name : "powershell.exe" OR process.name : "cmd.exe" OR process.name : "wscript.exe" OR process.name : "cscript.exe")

From the above results, it is clear that visibility is limited — for example, we cannot directly determine which specific script wrote a file on the host. To address this, we prioritise analysing process creation events associated with the identified process name python.

By correlating these events with their timestamps, we can effectively trace back and identify the script responsible for the file creation activity.

event.code : "1" and process.name: "python.exe"

By reviewing the collected logs, we can accurately identify the specific Python script associated with the file creation activity.

Decoding the python packages

As part of determining the root cause and understanding the adversary’s actual behaviour, we focus on analysing the identified suspicious Python script.

Upon review, the script appeared to contain nothing more than a simple print statement for testing. This is where the trick lies — during investigations, such tactics can easily mislead analysts. However, on closer inspection, we noticed that a package named downloader had been imported.

To uncover the script’s true functionality, the next step is to decode this package and analyse its actual behaviour.

The following list highlights the directories where Python libraries are located

C:\Users\<username>\AppData\Local\Programs\Python\Python<XY>\Lib\site-packages

C:\Python27\Lib\site-packages\pip\_internal

By navigating to the package folder, we were able to successfully locate the package that had been imported into the suspicious project.

Upon decoding the package, we discovered that its header was deliberately designed to communicate with an external network, enabling the download of a malicious payload.

The above simulation demonstrates a classic example of a supply-chain attack, where adversaries intentionally develop and distribute a malicious package. If such a package is unknowingly integrated into a project, the hidden payload is executed as designed, leading to compromise.

This highlights the critical importance of securing the software supply chain. Developers and security teams must remain vigilant by validating package sources, monitoring dependencies, and implementing robust detection strategies. Even a single unverified package can serve as an entry point for adversaries, turning trusted tools into powerful attack vectors.