Typosquatted domains were early signals in the Trivy and LiteLLM attacks

supply chain
by Ian Muscat · 6 min read
Typosquatted domains were early signals in the Trivy and LiteLLM attacks

The TeamPCP supply chain campaign that hit Trivy on March 19 and spread to Checkmarx's KICS and LiteLLM within days has been thoroughly covered from the perspective of CI/CD security, credential rotation, and GitHub Actions hygiene. While we'll provide some background, we're not going to rehash all of the details here (if you're interested in reading more, Rami McCarthy has an excellent writeup and timeline here).

What we want to focus on is the role typosquatted domains played, not because it was the only vector, but because it might have been the earliest visible signal that an attack was being prepared.

What happened#

On March 19, 2026, attackers used compromised credentials to push malicious commits and tags across Aqua Security's Trivy ecosystem. The core Trivy scanner, trivy-action, and setup-trivy were all affected. Nearly all trivy-action and setup-trivy tags were force-pushed to point at attacker-controlled code. A malicious Trivy binary (v0.69.4) was published through official release channels including GitHub Releases, Docker Hub, and container registries.

The attackers were sophisticated. Imposter commits spoofed known contributors, and the legitimate Trivy scan still completed after the malicious payload ran, so affected workflows looked normal. Stolen credentials were encrypted and exfiltrated to attacker infrastructure; the malware could also fall back to creating repositories in the victim's own GitHub account.

Within a few days, the same group expanded to Checkmarx's KICS GitHub Action and to LiteLLM on PyPI. In LiteLLM's case, initial access came directly from credentials harvested during the Trivy compromise of LiteLLM's own CI/CD pipeline—a straight line from a compromised security tool to stolen publishing credentials and poisoned packages in an entirely different ecosystem.

The campaign was multi-stage and multi-vector; typosquatted domains were part of it. What follows is where they showed up, and what public registration and Certificate Transparency logs contained by the time the attacks escalated.

Where the typosquatted domains fit in#

Three typosquatted domains played operational roles across the campaign.

scan[.]aquasecurtiy[.]org was one transposed letter away from "aquasecurity" and served as the primary command and control for the Trivy compromise. The malicious Go files injected into the Trivy build process were fetched from this domain. Stolen credentials were exfiltrated to it. It appeared in build logs and workflow output, which means it needed to look plausible to anyone reviewing a CI run. A random-looking domain would have drawn attention. A domain that read like a legitimate Aqua Security service did not.

checkmarx[.]zone performed the same function when the campaign expanded to Checkmarx's KICS and AST GitHub Actions. Payloads were hosted there, stolen data was sent there.

models[.]litellm[.]cloud did the same for the poisoned LiteLLM packages on PyPI. The malicious .pth file in litellm 1.82.8 exfiltrated credentials to this domain on Python startup.

Each domain was chosen to match the identity of the specific target, to blend into the environment where it would appear, and to survive the kind of quick visual check that a developer might give an outbound request during a build.

Early warning signals#

Here is what stands out to us about these domains. They had to be registered before the attacks launched. And those registrations leave traces in public records.

Public WHOIS for aquasecurtiy[.]org shows a creation date of March 17, 2026 — roughly two days before the March 19 Trivy attack. Certificate Transparency logs show Let's Encrypt certificates for scan[.]aquasecurtiy[.]org issued on the same day (earliest not_before of 2026-03-17), consistent with the attacker bringing HTTPS infrastructure online within hours of registering the domain.

While slim, two days can still be a significant window between a detectable registration and the start of a campaign that compromised thousands of CI/CD pipelines.

For checkmarx[.]zone, the earliest Certificate Transparency entry shows a Let's Encrypt certificate with validity starting March 22, aligning with the second wave of the campaign as it expanded beyond Trivy. For models[.]litellm[.]cloud, Certificate Transparency shows TLS activity starting March 23, with WHOIS for the parent litellm[.]cloud domain listing creation on March 24; both within the same narrow window as the poisoned PyPI releases.

The pattern is consistent across all three targets. Register a convincing lookalike, obtain certificates, execute the attack. All of that happened on the public internet and was recorded in public logs. The compromised credentials, force-pushed tags, and imposter commits were essentially impossible to spot in real time. But a domain registration is a different kind of event. It is recorded, it is queryable, and if you are monitoring for it, it can surface before the attack begins.

We are not claiming that domain monitoring alone would have prevented this campaign. The attack exploited multiple weaknesses across credential management, release automation, and platform design. Fixing those underlying problems is critical, and the detailed guidance from Aqua Security, Wiz, Sysdig, and others on how to do that is well worth reading.

But the registration of aquasecurtiy[.]org on March 17 was an early signal sitting in public records two days before the first malicious commit was pushed.

Why open source projects are especially exposed#

Open source projects are attractive targets for this kind of preparation precisely because everything about them is public. Project names, package naming conventions, domain patterns, maintainer identities, and release infrastructure are all available for an attacker to study and imitate.

At the same time, most open source maintainers have no systematic way to monitor for lookalike domain registrations. They are already managing releases, triaging issues, reviewing contributions, and responding to security reports, usually without dedicated security resources. Adding "continuously scan for typosquatting domains" to that list is not realistic without tooling.

What we are doing about it#

Have I Been Squatted monitors for lookalike domain registrations across common typosquatting patterns, including transpositions, homoglyphs, TLD variations, and other techniques attackers use to create convincing infrastructure.

We are making Have I Been Squatted's "Pro" tier available at no cost to open source maintainers and projects.

This is not a response to the news cycle. It is something we have been working toward because we believe that the people maintaining the software that modern infrastructure depends on should have the tools they need to keep their supply chain secure.

Domain monitoring is not a complete answer to supply chain risk. It is one layer. But the Trivy and LiteLLM incidents show it is a layer that can surface activity early, before code is compromised and before credentials are stolen.

If you maintain an open source project and want to monitor for lookalike domains targeting your project, please get in touch at [email protected].

Domain Protection

Protect your brand from typosquatting.

Join security teams using Have I Been Squatted to monitor lookalike domains, phishing infrastructure, and brand impersonation across the open web.