AWS - GuardDuty Enum

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

Other ways to support HackTricks:


According to the docs: GuardDuty combines machine learning, anomaly detection, network monitoring, and malicious file discovery, using both AWS and industry-leading third-party sources to help protect workloads and data on AWS. GuardDuty is capable of analysing tens of billions of events across multiple AWS data sources, such as AWS CloudTrail event logs, Amazon Virtual Private Cloud (VPC) Flow Logs, Amazon Elastic Kubernetes Service (EKS) audit and system-level logs, and DNS query logs.

Amazon GuardDuty identifies unusual activity within your accounts, analyses the security relevance of the activity, and gives the context in which it was invoked. This allows a responder to determine if they should spend time on further investigation.

Alerts appear in the GuardDuty console (90 days) and CloudWatch Events.

When a user disable GuardDuty, it will stop monitoring your AWS environment and it won't generate any new findings at all, and the existing findings will be lost. If you just stop it, the existing findings will remain.

Findings Example

  • Reconnaissance: Activity suggesting reconnaissance by an attacker, such as unusual API activity, suspicious database login attempts, intra-VPC port scanning, unusual failed login request patterns, or unblocked port probing from a known bad IP.

  • Instance compromise: Activity indicating an instance compromise, such as cryptocurrency mining, backdoor command and control (C&C) activity, malware using domain generation algorithms (DGA), outbound denial of service activity, unusually high network traffic volume, unusual network protocols, outbound instance communication with a known malicious IP, temporary Amazon EC2 credentials used by an external IP address, and data exfiltration using DNS.

  • Account compromise: Common patterns indicative of account compromise include API calls from an unusual geolocation or anonymizing proxy, attempts to disable AWS CloudTrail logging, changes that weaken the account password policy, unusual instance or infrastructure launches, infrastructure deployments in an unusual region, credential theft, suspicious database login activity, and API calls from known malicious IP addresses.

  • Bucket compromise: Activity indicating a bucket compromise, such as suspicious data access patterns indicating credential misuse, unusual Amazon S3 API activity from a remote host, unauthorized S3 access from known malicious IP addresses, and API calls to retrieve data in S3 buckets from a user with no prior history of accessing the bucket or invoked from an unusual location. Amazon GuardDuty continuously monitors and analyzes AWS CloudTrail S3 data events (e.g. GetObject, ListObjects, DeleteObject) to detect suspicious activity across all of your Amazon S3 buckets.

Finding Information

Finding summary:

  • Finding type

  • Severity: 7-8.9 High, 4-6.9 Medium, 01-3.9 Low

  • Region

  • Account ID

  • Resource ID

  • Time of detection

  • Which threat list was used

The body has this information:

  • Resource affected

  • Action

  • Actor: Ip address, port and domain

  • Additional Information

All Findings

Access a list of all the GuardDuty findings in:

Multi Accounts

By Invitation

You can invite other accounts to a different AWS GuardDuty account so every account is monitored from the same GuardDuty. The master account must invite the member accounts and then the representative of the member account must accept the invitation.

Via Organization

You can designate any account within the organization to be the GuardDuty delegated administrator. Only the organization management account can designate a delegated administrator.

An account that gets designated as a delegated administrator becomes a GuardDuty administrator account, has GuardDuty enabled automatically in the designated AWS Region, and also has the permission to enable and manage GuardDuty for all of the accounts in the organization within that Region. The other accounts in the organization can be viewed and added as GuardDuty member accounts associated with this delegated administrator account.


# Get Org config
aws guardduty list-organization-admin-accounts #Get Delegated Administrator
aws guardduty describe-organization-configuration --detector-id <id>

# Check external invitations
aws guardduty list-invitations
aws guardduty get-invitations-count

# Detector Information
aws guardduty list-detectors # 1 detector per account with GuardDuty
aws guardduty get-detector --detector-id <id> # Get detector info
aws guardduty get-master-account --detector-id <id>

# Get filters
aws guardduty list-filters --detector-id <id> # Check filters
aws guardduty get-filter --detector-id <id> --filter-name <name>

# Findings
aws guardduty list-findings --detector-id <id> # List findings 
aws guardduty get-findings --detector-id <id> --finding-ids <id> # Get details about the finding
aws guardduty get-findings-statistics --detector-id <id> --finding-statistic-types <types>

# Get trusted IP addresses
aws guardduty list-ip-sets --detector-id <id>
aws guardduty get-ip-set --detector-id <id>

# Member accounts of the current AWS GuardDuty master account
aws guardduty list-members --detector-id <id>
aws guardduty get-members --detector-id <id> --account-ids <id>
aws guardduty get-member-detectors --detector-id <id> --account-ids <id>

# Continuously export its findings to an Amazon S3 bucket
aws guardduty list-publishing-destinations --detector-id <id>

# Intelligence sets that you have uploaded to GuardDuty
aws guardduty list-threat-intel-sets --detector-id <id>
aws guardduty get-threat-intel-set --detector-id <id> --threat-intel-set-id <id>

GuardDuty Bypass

General Guidance

Try to find out as much as possible about the behaviour of the credentials you are going to use:

  • Times it's used

  • Locations

  • User Agents / Services (It could be used from awscli, webconsole, lambda...)

  • Permissions regularly used

With this information, recreate as much as possible the same scenario to use the access:

  • If it's a user or a role accessed by a user, try to use it in the same hours, from the same geolocation (even the same ISP and IP if possible)

  • If it's a role used by a service, create the same service in the same region and use it from there in the same time ranges

  • Always try to use the same permissions this principal has used

  • If you need to use other permissions or abuse a permission (for example, download 1.000.000 cloudtrail log files) do it slowly and with the minimum amount of interactions with AWS (awscli sometime call several read APIs before the write one)

Breaking GuardDuty


With this permission you could disable GuardDuty to avoid triggering alerts.

aws guardduty update-detector --detector-id <detector-id> --no-enable 
aws guardduty update-detector --detector-id <detector-id> --data-sources S3Logs={Enable=false}


Attackers with this permission have the capability to employ filters for the automatic archiving of findings:

aws guardduty create-filter  --detector-id <detector-id> --name <filter-name> --finding-criteria file:///tmp/criteria.json --action ARCHIVE

iam:PutRolePolicy, (guardduty:CreateIPSet|guardduty:UpdateIPSet)

Attackers with the previous privileges could modify GuardDuty's Trusted IP list by adding their IP address to it and avoid generating alerts.

aws guardduty update-ip-set --detector-id <detector-id> --activate --ip-set-id <ip-set-id> --location


Attackers could remove the destination to prevent alerting:

aws guardduty delete-publishing-destination --detector-id <detector-id> --destination-id <dest-id>

Deleting this publishing destination will not affect the generation or visibility of findings within the GuardDuty console. GuardDuty will continue to analyze events in your AWS environment, identify suspicious or unexpected behavior, and generate findings.

Specific Findings Bypass Examples

Note that there are tens of GuardDuty findings, however, as Red Teamer not all of them will affect you, and what is better, you have the full documentation of each of them in so take a look before doing any action to not get caught.

Here you have a couple of examples of specific GuardDuty findings bypasses:

GuardDuty detect AWS API requests from common penetration testing tools and trigger a PenTest Finding. It's detected by the user agent name that is passed in the API request. Therefore, modifying the user agent it's possible to prevent GuardDuty from detecting the attack.

To prevent this you can search from the script in the botocore package and modify the user agent, or set Burp Suite as the AWS CLI proxy and change the user-agent with the MitM or just use an OS like Ubuntu, Mac or Windows will prevent this alert from triggering.


Extracting EC2 credentials from the metadata service and utilizing them outside the AWS environment activates the UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS alert. Conversely, employing these credentials from your EC2 instance triggers the UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWS alert. Yet, using the credentials on another compromised EC2 instance within the same account goes undetected, raising no alert.

Therefore, use the exfiltrated credentials from inside the machine where you found them to not trigger this alert.


Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

Other ways to support HackTricks:

Last updated