Summary6 min read

SANS Stormcast: March 25th, 2026

Host: Johannes B. Ullrich
Theme: Recent High-Impact Supply Chain Attacks – From IP KVM Detection to the TeamPCP-Trivi-LightLLM Multi-Level Compromise

Episode Overview

This episode delivers a detailed look at recent cybersecurity threats, focusing on two main topics:

The detection of potentially abused IP KVM devices in enterprise environments
An in-depth analysis of ongoing, cascading supply chain attacks led by the threat group “TeamPCP,” centering on the compromise of security tools and developer dependencies, including Trivy, LightLLM, and Checkmarx.

Key Discussions and Insights

1. Detecting IP KVMs Used for Covert Access

[00:30 – 02:05]

Context: North Korean IT workers, posing as US IT help, use IP KVMs (Keyboard-Video-Mouse devices) to remotely access systems assigned to them, bypassing the need to install remote access software—which can make detection harder.
Johannes details hands-on testing with devices such as Sipeed nano KVM and piKVM for detection clues:
- Sipeed nano KVM: Identified as “Sipeed nano kvm” in USB device listings.
- piKVM: More generic USB identifiers, but the HDMI interface (as a monitor) exposes the model name “PIKVM” in its extended display identification data (EDID).
- Attackers may change these strings, but they remain a detection opportunity.
Quote:
“One of the reasons they’re using IP KVMs is that they don’t have to install any software, which of course makes them a bit more difficult to detect.” – Johannes [00:30]
Recommendation:
Monitor for unusual USB or HDMI device strings and consider that device identification can sometimes be changed in config files.

2. TeamPCP Supply Chain Attack Wave

[02:06 – 08:55]

a. Timeline and Summary

TeamPCP is identified as the actor behind a spate of high-profile supply chain attacks, first tracked by Flare in late 2025.
Flare's bot, "Hacker Bot Clause," found exposed credentials in CI/CD workflows, especially those securing privileged personal access tokens.

b. Trivy Compromise

Trivy, a free vulnerability scanner from Aqua Security, was the primary victim.
- Attackers compromised a privileged token and pushed malicious code into Trivy’s Visual Studio Code extension in late February 2026.
- Aqua Security responded quickly, patched the extension, and rotated credentials.
- However, attackers then silently replaced the main Trivy binary with a malicious version on March 19, rather than publishing a new version—making it harder to notice for those pinning by version, not commit hash.
Malicious Trivy binary acted as an info-stealer, targeting SSH keys, cloud tokens, and other secrets.
- The rapid response minimized damage, but Aqua Security advised the attacker may still have some access as of March 22.
Quote:
“The code added to Trivy was a standard info stealer and exfiltrated SSH keys, cloud tokens and other secrets from anybody running Trivy.” – Johannes [04:35]

c. LightLLM: Multi-Level Attack

On March 25, LightLLM announced their repository was also infected due to the Trivy compromise, escalating the incident into a multi-level supply chain attack:
- LightLLM acts as a proxy/router for Large Language Model (LLM) prompts, commonly centralizing access and credential management for organizations. It is sometimes embedded in other tools for ease of integration.
- By compromising LightLLM, attackers gained access to an even broader set of sensitive credentials, including those for a variety of LLM providers.
Quote:
“Really what it comes down to is, LightLLM has access to the credentials to access all these different LLMs, which, well, again is kind of what this entire compromise was after.” – Johannes [06:18]

d. Checkmarx and the “Domino Effect”

Checkmarx (specifically their KICS project—"Keeping Infrastructure as Code Secure") and its VS Code extensions were similarly compromised, likely (though not confirmed) via credentials stolen in the Trivy incident.
- These tools, being security-focused, often possess significant access within customer environments.

e. Expanding Targeting: From Stealing to Wiping

New evidence links TeamPCP to creation of a Kubernetes-specific wiper malware, notably targeting environments configured for Iran (via locale and timezone, not just IP).
- Distinguishing feature: First known instance of TeamPCP delivering a destructive payload (wiper) rather than just credential theft.
- Attribution based on a shared “Internet Computer Canister” used for C2 between malware samples.
Quote:
“The Kubernetes wiper is also interesting as it focuses specifically on systems in Iran. … The reason Aikido attributes the malware to TeamPCP is that one of the sort of specific techniques that TeamPCP is using is ICP or short for Internet Computer Canister for command and control.” – Johannes [08:05]

f. Threat Continues Unfolding

Multiple repositories may still be at risk. The longevity and breadth of the attack highlight the need for vigilance.

3. Mitigation Strategies & Takeaways

[08:56 – 10:04]

Immediate advice:
- Use pinning by git hash (immutable commit) instead of version tags to prevent silent binary replacement attacks.
- Review secret management practices; solid secrets management would have limited the fallout.
- Watch for evolving indicators of compromise, but realize their ephemeral nature.
Quote:
“Secret management, of course, is sort of one of the things I keep lately hitting more and more on. That’s definitely sort of the unseen star of the show here because haven’t really seen any of the victims already using solid secrets management…” – Johannes [09:35]
Johannes will share links to detailed blog analyses, including IoCs and mitigation details.
He stresses this might only be the visible part of a widescale attack:
“LightLLM and Checkmarx, they’re probably just the tip of the iceberg. It’s very likely that TeamPCP had access to a number of other repositories given how popular Trivy is.” [09:09]

Notable Quotes

“[Attackers] don’t have to install any software, which … makes [IP KVMs] a bit more difficult to detect.” – Johannes [00:30]
“The code added to Trivy was a standard info stealer and exfiltrated SSH keys, cloud tokens and other secrets…” – Johannes [04:35]
“LightLLM has access to the credentials to access all these different LLMs, which … is kind of what this entire compromise was after.” – Johannes [06:18]
“The Kubernetes wiper is also interesting as it focuses specifically on systems in Iran… using ICP … for command and control.” – Johannes [08:05]
“Secret management … is sort of the unseen star of the show here.” – Johannes [09:35]
“LightLLM and Checkmarx … are probably just the tip of the iceberg.” – Johannes [09:09]

Timestamps for Major Segments

00:30: Detecting Remote Access via IP KVMs
02:06: TeamPCP Supply Chain Attacks Overview: Trivy case
04:35: How the Malicious Trivy binary stole secrets
06:18: LightLLM’s role in the multi-level supply chain attack
07:45: Compromise expands to Checkmarx / KICS
08:05: Kubernetes wiper’s emergence, Iran targeting, TeamPCP techniques
09:09: “Tip of the iceberg”—continued risk & recommended mitigations
09:35: Secret management—“the unseen star of the show”
09:55: IoCs, ephemeral threats, and further resources

Additional Notes

This episode underscores the increasing sophistication and persistence of supply chain attackers, especially those targeting the pipeline of security tools.
For technical readers and defenders, the recurring themes are the importance of immutable pinning, rapid credential rotation, vigilant secret management, and staying alert for cascading compromises.

For links to referenced blog posts, indicators of compromise, and further mitigation steps, see the show notes on the SANS ISC website.

Loading summary

Transcript1 lines

[00:05]
A
Hello and welcome to the Wednesday, March 25, 2026 edition of the sans Internet StormCenter's Stormcast. My name is Johannes Ulrich, recording today from Jacksonville, Florida, and this episode is brought to you by the Sans Edu Bachelor's degree program in Applied Cybersecurity. Filling diaries today, just one quick diary about detecting IP KVMs. I've spoken about, spoken and written about these IP KVMs a couple times in the past. This was a little bit inspired by some news coverage that North Koreans that are getting hired here in the US as IT help are often using IP KVMs to then connect the laptops that these companies are sending to US addresses. So they're using it basically as a remote access tool. And one of the reasons they're using IP KVM's is that they don't have to install any software, which of course makes them a bit more difficult to detect. So I looked at some of the detection options with usb. In particular, the Sipeed nano KVM that I tested has a USB device that's outright called Sipeed nano kvm. For the pikvm, that's the other device I tested. It's tiny, little bit more difficult in the sense that the USB devices are a little bit more generic in their strings. However, there's also an HDMI interface that emulates a monitor and monitors are sending extended display identification data and that lists as identifier and model name PIKVM for the pikvm. Now, of course attackers can adjust it, but there's certainly something that, that you may want to look for for the pikvm. Actually, I believe there's a simple configuration file where you can adjust some of these strings. Next, we do have a little bit of a lengthy story, a supply chain story. In part, it's a long story because I've been neglecting some of these supply chain stories lately. Well, got a little bit bored of them to be honest. You know, that sort of one npm, PyPi, GitHub, repo that gets compromised after the other. But lately there is one particular group that sort of has made quite the impact and that's Team pcp. Now, Flare is one of the companies that sort of has been looking at this particular group for quite a while. I think back in December or so they started tracking them. But late February they made news because a bot called Hacker Bot Clause that's sort of hunting for CI CD workflows that it configured was able to identify exposed credentials and hit paydirt when it ran into a privileged Personal access Token used by AquaSecurity. The bot used this credential to push malicious artifacts into a Visual Studio code extension from Aqua Security. And well, that then led to the compromise of that Visual Studio code extension for Aqua Security product called Trivi. What makes this more interesting is that Aqua Security deploys supply chain security solutions and Trivi is a free vulnerability scanner that Aqua Security created. The scanner integrates with various development environments including Visual Studio code, and that's sort of where the extension comes from. Now, a week or so later, maybe a couple days later, the timeline isn't that terribly clear here. Aqua Security realized that they had a problem. They published an initial advisory, fixed the extension and rotated credentials. Well, you would think all good now. Well, that's what they thought initially, but it turns out they must have forgotten a spot. The attacker came back on March 19 and updated the Trivi binary release. They did not release a new version as you have so often supply chain attacks, but instead they replaced existing version. This meant that organizations using Trivi that were now using the malicious version if they were basically just pinning the version that hack and not a GitHub commit based on the GitHub or the Git hashtag. The code added to Trivi was a standard info stealer and exfiltrated SH keys, cloud tokens and other secrets from anybody running Trivi. And Trivi has quite a good following now. Luckily Aqua Security actually noticed this issue quickly and remediated it in a couple of hours. Again they published the details on March 20th and 22nd. So that would have been this weekend, essentially a day later, which was yesterday. Akma Security stated that they believe the attacker still has some access to environment and they have since released additional updates basically sort of detailing what they're doing to mitigate this entire breach. Now today Light LLM announced that they were affected by the Trivi compromise and that now their repository was infected as well. This turned the Trevi supply chain attack into sort of a multi level supply chain attack. And well, because now anybody running lightllm also again had the same problem. Now what is Lightlm? Lightlm is at its nature sort of a proxy that is able to forward prompts to different LLMs. It's sort of used in two ways. First of all, organizations can use it to centralize LLM requests. Users connect to Litempl and then LightLM forwards the request to the model the user. Selected Organizations deployed Lightlm in this form so they don't have to reveal the actual credentials to users. They can do some metering Rate limiting and such and basically control costs in using these LLMs. LightLM is also included in other projects as a simplified sort of API to connect to different LLMs. So you really just have to connect to Lightlm and it sort of does some of the translations and such for you. But really what it comes down to is Lightlm has access to the credentials to access all these different lms, which well again is kind of what this entire sort of compromise was after. So now the info stealer has access to even more credentials in this particular case of course credentials to different lms. Now Team pcp, the group identified as responsible for the Trivi compromise, also has apparently compromised check marks using malware similar that was used against Trivi. They used a similar tactic of replacing existing version of Checkmark's open source projects like KICS and again Visual Studio code extensions that were published by by Checkmarks. KICS is short for keeping infrastructure as code secure. So another security tool compromised by Team PCP and again a tool that often has access to credentials. Sysdig, the company that assisted Trivi with the incident response suggests that checkmarks may have been compromised using credentials stolen via Trivi. So they are a Trivi user. But at this point we no real confirmation for what exactly happened here and how these two events are linked. But that's not really all. We also have some new development coming from Team pcp. So so far they were very specifically going after weak cloud configuration, weak repositories and then stealing credentials. Stealing credentials was their thing. Aikido Security suggested that a new Kubernetes wiper they identified this weekend for was also created by Team pcp. This would be again a very different payload than what they did now. Until now Team PCP exclusively deployed credential stealers. The Kubernetes wiper is also interesting as it focuses specifically on systems in Iran. Now the way it identifies them is by looking at the time zone and the locale information. So not just by IP address or such. It may also get basically systems configured for Farsi or configured for the Iranian time zone in other countries. The reason Aikido attributes the malware to Team PCP is that one of the sort of specific techniques that Team PCP is using is ICP or short for Internet Computer Canister for command and control. So these ICP canisters are used by Team pcp. The canister by the same identifier is used for the Iran attack. So that's why they think that they are related. Also in this case, once you're affected by it, it will not just basically wipe out your kubernetes infrastructure, it will also attempt to spread the ssh and that's a very common technique where it looks at hey, what secret keys are in the system, what past connections do we have to that system? Can we somehow deduct some trust relationships or look at authorized key files and such to figure out, you know, where we can connect with these keys to other systems? So this is an event that's still very much under development at this particular point. From a mitigation point of view, Lightlm and checkmarks, they're probably just the tip of the iceberg. It's very likely that Team PCP had access to number of other repositories given how popular Privy is. And as a result you should be aware that yes, this malware may show up in other repositories. So definitely pay attention here if you want to do something about it. Well then definitely pinning by git hashes versus by versions tags is sort of one way how you could prevent some of this happening here at least spreading to you overall. Secret management of course is sort of one of the things I keep lately hitting more and more on. That's definitely sort of the unseen star of the show here because haven't really seen of any of the victims already using sort of solid secrets management here. I'm going to add links to multiple blogs I mentioned because this is a little bit lengthy story here and in some ways it's actually multiple stories. So some of these blog posts also include additional indicators of compromise and mitigation steps. With all these indicators of compromise, I would always be a little bit careful, you know how ephemeral they are. But well, this is it for today, so don't forget that I'll be teaching Defending Web Apps in Orlando next week and San Diego in May. Thanks for listening, liking and subscribing and talk to you again tomorrow. Hopefully we'll have some time tomorrow for more than just sort of one big story.