The small control that stopped a supply chain attack

// the challenge

The client — a company building AI products — had workloads that could resolve any domain on the internet. That's the AWS default, and it's exactly what supply chain attacks rely on. When a compromised package version ships malicious code, that code has to phone home: to fetch instructions from the attacker or to push stolen data out. Both start with a DNS lookup, and nothing in the client's setup was watching those lookups.

// our approach

• Deployed Route 53 Resolver DNS Firewall on every VPC across both of the client's AWS accounts.
• Attached AWS managed domain lists for known malware and botnet command-and-control domains — lists AWS keeps updated, so there's nothing to maintain.
• Added custom deny lists for domains the client specifically wanted blocked.
• Set up both modes: known-bad domains are blocked outright, while suspicious categories alert first so legitimate traffic is never silently broken.
• Turned on query logging so there's always a record of what tried to resolve what.

// the outcome

The setup took a few days and costs almost nothing to run. When the LiteLLM supply chain attack hit, a compromised version of the library tried to call out to attacker-controlled domains from inside the client's infrastructure. The firewall blocked the lookups at the resolver, and the alerts told the team exactly which workloads were affected — before any data left the network. A few days of DNS work turned a potential breach into a non-event.