Two LiteLLM attacks stole credentials this year. Check if your AWS keys were used.
CtrlB is a unified telemetry platform for observability and security. Connect your CloudTrail bucket and it checks every event back to March for signs the attacker used your keys.
What the check looks for in your CloudTrail
CloudTrail records every AWS API call with the key that made it and the address it came from. The check reads those two fields.
Calls from the attacker's addresses
Any call from 168.100.8.57 or 165.227.201.8, the two addresses named in the October write-ups.
Machine keys used outside your network
AWS names an EC2 instance's keys after the instance ID. When the same key calls AWS from an address you don't own, it left that machine.
The calls an attacker makes first
sts:GetCallerIdentity to test the key, then listing calls such as bedrock:ListFoundationModels to see what it can reach.
What you get back
- Each AWS key the attacker used, by access key ID.
userIdentity.accessKeyId - The machine each key came from, by instance ID.
userIdentity.principalId - Every call made with that key, the addresses it came from, and when.
eventNamesourceIPAddresseventTime - If nothing matches, the searches we ran and the dates they covered.
queries rundates covered
How the check runs
- You give CtrlB read-only access to the S3 bucket your CloudTrail trail writes to.
s3:GetObjects3:ListBucket - CtrlB reads the log files and indexes them.
*.json.gz - We run the check across every month you have and send you the results.
back to March
What CloudTrail can't tell you
It shows keys being used, not taken.
A stolen key nobody has used yet leaves no record. If you ran an affected version, rotate your keys anyway.
It only covers AWS keys.
Model provider keys, GitHub tokens and SSH keys don't appear in CloudTrail.
March needs a trail in S3.
Without one, AWS keeps 90 days of event history. That covers October, not March.