How do you know if an AWS account was compromised?
Almost every AWS compromise leaves its trace in CloudTrail: the API call that confirmed a stolen key works, the burst of List and Describe calls mapping the account, the IAM user created as a backdoor, the GuardDuty detector deleted, the GPU instances launched in a region nobody uses. The hard part is finding those few events among millions.
This tool reads your exports in the browser, runs a set of detections written as reviewable rules (field matchers, thresholds, MITRE ATT&CK techniques), and gives a verdict — Clean, Suspicious or Compromised — with the evidence rows behind every finding, a timeline of the incident, a pivot on every principal, key, IP and resource, and a remediation checklist.
What it detects
- Initial access: long-term access keys suddenly used from a new IP address, root account use, console sign-ins without MFA, bursts of failed sign-ins.
- Reconnaissance: GetCallerIdentity with a long-term key, enumeration bursts (dozens of different List/Describe/Get calls in minutes), AccessDenied storms, Kali / Pacu / CloudFox user agents.
- Persistence and privilege escalation: CreateUser, access keys created for another user, AdministratorAccess or *:* policies, console passwords, role trust changes, new SAML / OIDC providers, public Lambda functions, EC2 user data and key pairs.
- Defense evasion: CloudTrail stopped or deleted, GuardDuty, Config, Security Hub disabled, S3 access logging and VPC Flow Logs removed, security groups opened to the internet.
- Data theft: buckets made public, snapshots shared with other accounts, bulk S3 downloads (CloudTrail data events or S3 access logs), large outbound transfers in VPC Flow Logs, secrets read in bulk.
- Impact and cost abuse: GPU instances launched, quota increase requests, activity in regions not used before, connections to mining pools, bulk deletions, KMS keys scheduled for deletion.
Limitations
- Detections point, they do not prove: every finding shows its evidence so you can confirm it. Legitimate administration can look like an attack, and a careful attacker may stay under the thresholds.
- Without S3 data events or S3 access logs, reading data from buckets is invisible; without VPC Flow Logs, so is network exfiltration.
- “New IP” and “new region” detections compare with the first day of the logs provided: include a few quiet days before the incident.
- No IP geolocation or ASN lookup (that would need a database or an online service): new countries are not detected yet.
- ALB, CloudFront and Parquet logs are recognised but not analysed yet.
FAQ
Are my logs uploaded anywhere?
No. The analyzer is Rust compiled to WebAssembly and runs in a Web Worker in your browser. Files are streamed from your disk and decompressed locally; there is no upload endpoint.
How do I investigate a leaked AWS access key?
Deactivate the key first, then drop the CloudTrail logs covering its lifetime. Pivot on the key in the Entities tab: the tool flags the first use from a new IP address, the calls made from there (recon, IAM changes, data access) and anything the key created — users, keys, instances — so you can clean up everything, not just the key.
Can it handle a multi-gigabyte CloudTrail export?
Yes. Files are read in chunks and gzip is decompressed as a stream, so memory stays bounded. Every record goes through the detections; for very large inputs the event explorer keeps the notable events and all evidence.
Which rules does it use?
About fifty detections written as data (field matchers, sliding-window thresholds, aggregates) with MITRE ATT&CK technique ids, in the spirit of Sigma rules. They are reviewable in the open-source rule file and cover the common AWS attack paths: leaked keys, IAM persistence, defense evasion, data theft and crypto-mining.
The verdict says compromised — what now?
Contain first: deactivate the leaked keys, delete the backdoor users and keys, stop the attacker's instances — the remediation checklist lists them from the findings. Preserve the logs before changing anything else, then scope the incident. AWS's Security Incident Response Guide describes the full process.
Is this an Amazon product?
No. It is an independent tool, not affiliated with, endorsed by or sponsored by Amazon Web Services.