#NSBCS.127 – A Quick Look at Recent Software Supply Chain Risks

 

The software supply chain has always been a concern for most organisations. I recall reading FireEye's 2020 advisory on SolarWinds Orion, where a threat actor compromised the software's update functionality to install malware. Following that incident, organisations began taking the supply chain slightly more seriously, questioning whether a piece of third-party software was secure enough to be granted full administrative permissions over a system.

Now we have TeamPCP, a threat actor notorious for developing and recently releasing to the public the Shai-Hulud worm, malware used to infect a user's system and steal secrets such as GitHub, cloud and AI tokens. They gained notoriety by compromising legitimate npm and PyPI packages relied upon by thousands of users, stealing secrets at a scale never seen before and compromising high-profile organisations, including GitHub.

TeamPCP and their methodology is very optimised when you really think about:

  • Compromise trusted software packages: This has a few benefits, the scale at which it can compromise other organisations, trust that people have in these packages being safe, and the likelihood of it being installed by a developer who would have privileged access.

  • Information Stealer: Either dropping Shai Hulud or their own custom payload to steal all the secrets on the target system. Combined with the intended target being a developer, you basically guaranteed to lose high-value secrets in seconds.

  • Steal corporate data: Leveraging the secrets stolen from the beachhead host, exfiltrate the critical data for later extortion. In some cases, deploy ransomware.

  • Continue to spread: Using the trust from compromised secrets, inject code into more packages, spreading the attack to other organisations.

This is probably a hot take, but as an organisation, you can't really control when or how a trusted software package is going to be compromised. Sure, you can limit the exposure and reduce the attack surface, but as defenders, we all know that at some point the perimeter may be breached, and it is our layered defences that help prevent or limit the impact of the attack. The question we need to be asking is: if a developer is compromised, what can a threat actor do with their access? If your answer to that is "everything," then you should really consider reviewing your processes and controls.

Here are a few things for organisations to consider when planning their strategy to in handling software supply chain risk:

  • Endpoint Detection and Response: Are you able to detect suspicious payloads running or unusual access to the file system? Are you able to follow the trail in the event of an incident?

  • Least Privilege: If a secret is compromised, is the blast radius limited?

  • Secrets Management: Is there a need for the secret to even be on disk in plaintext and are we certain there are no secrets in our code repositories? Yes. TeamPCP also target memory but let’s start with the basics.

  • Access Control: Is there a need to access everything from the internet? Can we provide granular access to systems/secrets?

  • CI/CD Pipeline: If the pipeline was compromised is there anything that would prompt someone to investigate?

  • Software Auditing: Are dependencies for production environments documented? Are we able to lock the production versions to known good versions?

Ultimately, strengthening software supply chain security requires assuming compromise is inevitable and building layered controls that limit impact when it occurs.


What we read this week

  • Red Hat npm Packages Backdoored in "Miasma" Supply Chain Attack – On 1 June 2026, attackers compromised at least 32 packages (96 versions) under Red Hat's @redhat-cloud-services npm namespace, pulling roughly 117,000 weekly downloads. The payload was a new variant of the open-sourced Mini Shai-Hulud worm, self-identifying as "Miasma: The Spreading Blight" and designed to harvest developer credentials, cloud secrets, SSH keys and CI/CD tokens before self-propagating. The packages were published via compromised GitHub Actions OIDC tokens rather than a stolen npm token, indicating CI/CD pipeline compromise. Red Hat stated the impact was limited to internal tooling. Teams that installed affected versions should treat CI secrets and cloud credentials as compromised and rotate them.

  • DriveSurge: Initial Access Broker Hijacks Thousands of Sites for ClickFix and FakeUpdates – Silent Push profiled a threat actor, tracked as DriveSurge, operating an industrialised drive-by malware operation that ran largely undetected for close to a year. The actor functions as an initial access broker on a pay-per-install model, injecting scripts into thousands of legitimate, high-reputation websites and routing visitors through an open-source traffic distribution system (zTDS). Victims were served either a FakeUpdates lure impersonating browsers such as Chrome and Firefox, or a ClickFix prompt tricking them into running malicious PowerShell commands, targeting both Windows and macOS. Defenders should reinforce that legitimate browsers never require pasting commands into a terminal, and monitor for scripted execution following web browsing.

  • Sophos Uncovers AI-Assisted Ransomware Toolkit Automating AD Discovery and EDR Evasion – Sophos detailed a threat actor leveraging an AI-assisted framework that automates Active Directory discovery and iteratively develops malware to evade EDR products from Sophos, CrowdStrike and Microsoft. Development was accelerated using AI agents (including Cursor and Claude Opus) across coding, testing and OPSEC hardening, though the workflow remained human-driven. Components included Cobalt Strike profiles mimicking legitimate traffic, a Telegram bot API for C2, Python shellcode injection into Windows binaries, and a Cloudflare Worker to obscure the C2. Sophos assessed it was likely intended for real-world intrusions. The takeaway is that AI compresses attacker development cycles, but patching, MFA and comprehensive EDR coverage remain the priority.

  • Charter Communications Confirms Breach After ShinyHunters Leaks Customer Data – Charter Communications (Spectrum) confirmed a breach after the ShinyHunters extortion group published stolen records when a 27 May ransom deadline passed. ShinyHunters reportedly gained access on 1 April 2026 via a voice-phishing call against an employee's Microsoft Entra account, then exported records from Charter's Salesforce instance, with no technical exploit required. While the group claimed over 42 million records, Have I Been Pwned verified roughly 4.9 million unique email addresses, alongside names, phone numbers and addresses, plus around 85,000 employee directory records. Charter disputed that sensitive PI or CPNI was exfiltrated. Organisations should harden help-desk verification procedures and apply phishing-resistant MFA.

  • Google Patches Actively Exploited Android Zero-Day in June 2026 Update – Google's June 2026 Android Security Bulletin addressed 124 vulnerabilities, including CVE-2025-48595, a high-severity (CVSS 8.4) integer-overflow flaw in the Android Framework under active, targeted exploitation. The vulnerability allowed a local attacker to escalate privileges and execute code with no user interaction, affecting Android 14 through 16-QPR2. Google's "limited, targeted exploitation" wording — the fourth such Android zero-day since December 2025 — typically signals commercial spyware or nation-state activity against high-value individuals. On corporate-enrolled devices, privilege escalation could enable credential capture and MFA interception. Two patch levels (2026-06-01 and 2026-06-05) were issued; teams managing Android fleets should prioritise rollout.


Next
Next

#NSBCS.126 - AI, Accountability and Resilience: The Governance Challenge for Australian Businesses