AWS security consulting ยท open source

GuardDuty is on. Does it detect anything?

Most AWS teams switch on detections and assume they work. We run real attack techniques in a sandbox account and show you what was detected, what was only logged and what was missed. Then we help you close the gaps.

The problem

Switched on is not the same as working

In one published test, six data-theft techniques run against a real AWS account produced no GuardDuty alert at all. The findings that did fire took between 15 minutes and about an hour.

Posture scanners such as Prowler tell you what is misconfigured. They can't tell you what happens when someone actually attacks. The only way to know is to run the attack and look.

$ firedrill run starter --expected-account 111111111111 --confirm
DETECTED    aws.defense-evasion.cloudtrail-stop@us-east-1
LOGGED      aws.persistence.iam-backdoor-user@us-east-1
LOGGED      aws.exfiltration.ec2-share-ebs-snapshot@us-east-1
PREVENTED   custom:s3-ssec-write@us-east-1
Example output. LOGGED means CloudTrail saw it, but nobody would have been alerted.
What a fire drill checks

Five questions every AWS team should be able to answer

Does a detection fire?

Run the technique, then check GuardDuty, Security Hub or your SIEM for the finding, and time how long it took.

Does the alert reach a human?

A finding nobody sees is a log entry. Check that it actually lands in Slack, email or your pager.

Do your SCPs and RCPs really block it?

Run the attack step and pass only when AWS denies it.

Do harmless actions stay quiet?

Run a benign twin of each attack. Noisy alerts get muted, and muted alerts miss real attacks.

Did anything break since last week?

Compare every run with the previous ones and fail when a detection that worked stops working.

Answer them with cloud-firedrill →

Open source, runs in your own sandbox account, no telemetry, no commercial SIEM required.