Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Protections implemented by AWS for scanning

Blackfoot is the EC2 elastic networking backend

AWS MadPot:

  • When they detect a connection to a ip that’s not allocated to any Elastic IP they will know it’s a scanner so they can mark your ip. This is not great for my TLS scanner…
  • Sonaris is the S3 protection

Important part will be if you can run your scanner on AWS infrastructure that uses dynamic outbound public ips, they very likely won’t block your IP as that would mean they could impact other AWS customers.

I'm not sure where I got the above information anymore, I think it was in a podcast somewhere from Critical Thinking?

Summary of some services

Learned this during some discussions

  • Mithra - network to inspect DNS request per region. Is also give a 'benign reputation source',that guardduty uses to prevent false positives. Route53 domain blocking also uses Mithra, perhaps also some AWS internal services use it but wasn't really clear.
  • MadPot - Think a more standard honeypot solution. When it detect a proper validated attack, it can replicate the blacklisted ips to the whole network.
  • Blackfoot - analyze all inbound and outbound flows (13T flows an hour) to VPCs. How many of these come from malicious ips, and they use MadPot to determine if it's a really malicious ip.
  • Sonaris - internal threat intelligence tool looks at network traffic and find potential security threats. Finds attempts of people trying to find public buckets, vulnerable services on EC2, etc.
  • SnowTube, what public IPs are associded with EC2. is published to an SNS topic. Would be beautiful if we can subscribe to this topic?!! are there explicit accounts or Org conditions? Can we levarage AWS services to listen to this topic? How can we find out the name of the SNS topic?
  • IP Ownership. this is a service managed by EC2 team - EC2 which ip addresses are associated with what instances for a point in time

How does GuardDuty work?

  • S3 malware uses bitdefender to help with hashes. They also have a few other internal rules for it.
  • GuardDuty gathers all required data itself, does not need you to enable it (vpc flow logs, cloudtrail, dns logs, S3/RDS access logs)

GuardDuty infrastructure

GuardDuty is built using a lot of the 'normal' AWS services, like Lambda, S3, EC2, RDS, Firehose.

  • Frontend running in customer account, these are the actual resources that will be checked.

  • Non guardduty internal components, S3, Route53 logs, flow logs, service logs from s3, eks audit logs, IP Ownership, (this is a service managed by EC2 team - EC2 which ip addresses are associated with what instances for a point in time), Mithra (DNS inspection)

Their evaluation components:

  • Stateless processor: evaluate, this is related to the threat intel providers. eg. ip ownership, external vendor intel (croudstrike and proofpoint are definitely used), etc
  • Stateful processing: This is where machine learning models are applied, what kind of things can it detect
  • Malware engine:

Another service:

  • Account service: Which accounts do you have enabled guardduty on, what is the delegate account, what features are enabled? etc?

Security boundaries:

GuardDuty runs internally across a whole lot of these above 'micro'services. They spread their services into different accounts, using it as a security boundary. Often they just use IAM roles and resource policies to control this, they don't put everything behind API gateways etc.

DNS Graph statistics

They get all their data from Route53 to build their mitigfations (200TB DNS logs with 5B subdomain nodes oktober-2025).

Domain (TLD + 1) -> CNAME -> DNS Subdomain -> DNS -> EC2 Instances Subdomain -> DNS -> AWS Account

Domain reputation pipeline:

  1. Create a graph for the Domain target
  2. Train models on the graph
  3. Evaluate models using ??

Firenze for Model Evaluation

What are the manual sec engineer steps eg. for evaluation domains.

  • New domain comes, are any ip addresses already sinkholed, so more likely to be malicious. Is it low popularity, is it nonsense, is the TLD abused often?

Firenze will use the signals that sec engineers generate or engineers identify new of these weak signals, to better evaluate a model and provide guardrails. This is used to improve Mithra.

There is a whitepaper firenze-model-evaluation-using-weak-signals

High level getting findings into GuardDuty

  • ingest signals, apply ETL
  • Signals delta table -> Clustering
  • Clustering
  • Compoind signals Delta Table -> Pripritization
  • Compoind signals Delta Table -> training
  • Prioritization -> attach sequences (s3)
  • attach sequences (s3) -> Security Hub
  • attach sequences (s3)-> Finding Gateway -> Findings into the API for GuardDuty console.