Lesson 1.1: Hackers Hide Pulsar RAT Inside PNG Images in New NPM Supply Chain Attack - Hackread

Compliance Framework Mapping

Introduction

Welcome to Lesson 1.1: Hackers Hide Pulsar RAT Inside PNG Images in New NPM Supply Chain Attack - Hackread! Over the next 45 minutes, we will explore how attackers are compromising the software supply chain by hiding malware inside seemingly harmless image files.

But first, let me tell you about Marcus Webb.

It's 2:30 PM on a Tuesday in October. Marcus Webb, a senior developer at a fintech startup in London, is finalising a new feature. He types 'npm install' to pull in a trusted, open-source library his team uses for data visualisation. The familiar hum of his laptop's fan is the only sound in the room.

The build completes without error. Marcus pushes his code, satisfied. An hour later, a junior developer on his team messages him. 'My machine is running really slow since I pulled your branch,' she writes. Marcus dismisses it as a local issue, maybe a memory leak in the dev environment. He doesn't notice the new, hidden network connection his own machine just established.

By the next morning, the company's internal Git server is making outbound connections to an IP address in a country they don't operate in. Security alerts start to flash, but they're generic—'unusual network traffic.' Before anyone can piece it together, the attacker has a remote shell on Marcus's machine, and is using his credentials to move laterally through the build pipeline.

This is the story of a Data Breach. By the end of this lesson, you'll understand exactly why Marcus never stood a chance, and more importantly, what could have saved him.

Content Section 1: What is a Software Supply Chain Attack?

Think of your software like a car. You don't build every single bolt and microchip yourself; you rely on a supply chain of trusted manufacturers. A supply chain attack is when a criminal tampers with one of those components before it even reaches your factory floor.

The Attack Vector: Open-Source Repositories

In this incident, the target was the Node Package Manager (NPM), a public repository where millions of developers download open-source code libraries. Attackers uploaded a malicious package disguised as a legitimate tool.

The malicious package contained a standard PNG image file. However, hidden within the image's pixel data was an encoded, fully functional Remote Access Trojan (RAT) called Pulsar.

When a developer like Marcus installed the package, a post-installation script automatically ran. This script decoded the malware from the PNG and executed it on the developer's machine, bypassing traditional file-based antivirus scans that would flag an executable.

The Payload: Pulsar RAT

Pulsar RAT is a powerful, commercially available malware that gives an attacker complete control over an infected system. It can log keystrokes, steal files, capture screenshots, and use the victim's machine as a foothold to attack other systems on the network.

Once installed, it establishes a covert connection to a command-and-control server, allowing the attacker to operate silently from within the development environment, one of the most trusted parts of an organisation's network.

DORA Article 5-17 DORA requires financial entities to have strong ICT risk management frameworks that specifically address risks from third-party providers, like open-source software repositories. This attack shows why monitoring these dependencies is not optional.

ISO A.14.2 ISO 27001 A.14.2 mandates secure system engineering principles. This includes verifying the security of acquired software, which extends to open-source libraries pulled from public repositories during development.

Content Section 2: The Anatomy of the Attack

Understanding the step-by-step flow of this attack reveals why it's so effective. Let me show you exactly how Marcus was compromised.

Attack Flow: From Repository to Remote Control

Step 1: Weaponisation. The attacker creates a malicious NPM package, often with a name similar to a popular library (a tactic called 'typosquatting') or by compromising an existing maintainer's account.

Step 2: Delivery. The package, containing the weaponised PNG and a post-install script, is published to the public NPM registry.

Step 3: Exploitation. When Marcus runs 'npm install', the package and its scripts are executed with the privileges of his user account. The post-install script extracts the Pulsar RAT from the PNG and runs it.

Step 4: Installation & Command. The RAT installs itself persistently, calls home to the attacker's server, and awaits instructions, giving the attacker a remote control panel for Marcus's machine.

Key Technical Components: Steganography and Scripts

The core technique is steganography: hiding information within another file. The RAT's binary code was encoded into the binary data of the PNG image. A simple decoding script, bundled in the package, rebuilt the malicious executable in memory or on disk.

The 'package.json' file, which every NPM package has, defined a 'scripts' section with a 'postinstall' hook. This hook automatically runs the decoding script after installation, requiring zero interaction from the developer.

Why Traditional Defences Fail

Notice what all of these methods have in common. They rely on checking the wrong thing at the wrong time. They trust the source (NPM) and the file type (PNG), while the attack happens in the process between them.

This attack is designed to slip past common security layers. Here’s how:

NIST PR.IP-3 NIST CSF PR.IP-3 calls for integrating security into the system development life cycle. This attack shows the consequence of not securing the 'acquisition' phase of that cycle, where third-party software is brought in.

NIS2 Article 21 NIS2 mandates policies for risk analysis of information systems. This includes analysing risks introduced by the software supply chain and open-source dependencies, requiring proactive measures beyond just installing antivirus.

Content Section 3: Detection and Defence

Marcus's computer knew something was wrong. New network connections were made, and unfamiliar processes ran. It just couldn't tell him. Here’s what to look for.

Network-Level Indicators

Monitor for outbound connections from developer workstations or build servers to unknown or suspicious external IP addresses, especially following package installation events.

Look for beaconing behaviour—regular, call-home traffic from the RAT to its command-and-control server. This may be disguised within normal web traffic but will have consistent timing and destination.

Implement egress filtering and proxy logging. Even if you can't block all traffic to NPM, you can log it and analyse for anomalies, like a development machine connecting to a server in a high-risk country immediately after installing a package.

Endpoint-Level Indicators

Use Endpoint Detection and Response (EDR) tools to look for process lineage anomalies. For example, a Node.js process (`node`) spawning unusual child processes like `cmd.exe` or `powershell` shortly after package installation.

Monitor for file system changes in user temp directories or AppData folders immediately following an `npm install`. The decoded RAT executable may be written here briefly before execution.

Scan running processes and memory for known Pulsar RAT signatures or behavioural patterns, such as code injection or attempts to disable security software.

Supply Chain Signals

Implement Software Composition Analysis (SCA) tools that scan `package.json` and `package-lock.json` files for known malicious packages, suspicious scripts, or dependencies with poor security histories.

Monitor source code repositories for the introduction of new dependencies, especially those with recently created accounts, few downloads, or names similar to popular packages.

Enforce policies that require peer review or security approval before adding new external dependencies to critical projects.

SOC2 CC7.1 SOC 2 CC7.1 requires system operations to be monitored for anomalies. This attack underscores the need to monitor not just production servers, but also development and build systems for unusual process and network activity.

GDPR Article 32 GDPR Article 32 requires appropriate security of processing, including the 'resilience of processing systems.' A breach originating in the development supply chain that accesses personal data would be a clear failure of these resilience measures.

Content Section 4: Building Your Compliance Evidence

Compliance isn't about ticking boxes; it's about building a verifiable story of security. This lesson provides chapters for that story.

Evidence Generation

This lesson provides documentation for multiple compliance frameworks:

For DORA Article 5-17 auditors... For DORA auditors, you can now demonstrate that your staff have been trained on specific ICT risks related to third-party dependencies and software supply chains, fulfilling requirements for staff awareness and specialised training.

For ISO A.14.2 auditors... For ISO 27001 assessors, you can evidence that secure development practices have been reviewed, with a specific focus on the security of acquired software (open-source libraries) as part of your development life cycle controls.

For NIST PR.IP-3 auditors... For NIST CSF reviewers, you can show proactive steps to integrate security into the development life cycle by implementing a process to audit and analyse software dependencies, addressing the PR.IP-3 category.

Audit Trail

Document your completion of this lesson:

• Lesson title and date completed
• Time invested: approximately 45 minutes
• Key learnings in your own words
• Activity submission reference
• Follow-up actions identified (e.g., 'Schedule a supply chain risk workshop with dev team')

Conclusion

Let me tell you how Marcus's story ended.

The breach was contained, but not before the attackers exfiltrated preliminary database schemas and internal API documentation. The incident response cost the company over £200,000 in consultancy fees, lost developer time, and a mandated regulatory report. Marcus, though not blamed, was moved off core development for six months.

The organisation eventually implemented a mandatory SCA tool in its CI/CD pipeline, enforced multi-factor authentication for all package publisher accounts, and created a formal review board for new external dependencies. These changes came months too late for Marcus's project.

But it doesn't have to be your story. That's why we're here.

You should now understand how software supply chain attacks work by weaponising trusted components. You understand the specific technique of using steganography in image files to bypass defences. You know key detection indicators at the network, endpoint, and supply chain level. And you understand how this threat maps to major compliance frameworks like DORA and NIST.

Next, we'll explore Next, we'll explore Lesson 1.2: Defending the Software Factory. We'll build on this knowledge and walk through practical technical controls to harden your development environment against these insidious attacks.

See you there.

Resources

The course materials folder contains downloadable resources for this lesson:

• Lesson 1.1 Quick Reference Card - Summarise the key detection indicators for NPM supply chain attacks and immediate response steps for a suspected Pulsar RAT infection on a single page.
• Compliance Mapping Worksheet - Map your organisation's software acquisition and development controls against the DORA, ISO 27001, and NIST CSF requirements relevant to supply chain attacks highlighted in this lesson.
• Risk Assessment Template - Assess your development team's exposure to dependency confusion, typosquatting, and malicious package scripts based on the attack vectors covered in this lesson.
• Further reading - Links to official NPM security advisories, the MITRE ATT&CK framework page on Supply Chain Compromise (T1195), and OWASP guidance on Software Supply Chain Security.

Hackers Hide Pulsar RAT Inside PNG Images in New NPM Supply Chain Attack - Hackread Defence Masterclass | Threat Intelligence | Lesson 1.1
© LimitedView Limited | 2026