AWS - GuardDuty Enum
GuardDuty
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.
All Findings
Access a list of all the GuardDuty findings in: https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html
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.
Enumeration
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
guardduty:UpdateDetector
guardduty:UpdateDetectorWith this permission you could disable GuardDuty to avoid triggering alerts.
guardduty:CreateFilter
guardduty:CreateFilterAttackers with this permission have the capability to employ filters for the automatic archiving of findings:
iam:PutRolePolicy, (guardduty:CreateIPSet|guardduty:UpdateIPSet)
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.
guardduty:DeletePublishingDestination
guardduty:DeletePublishingDestinationAttackers could remove the destination to prevent alerting:
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 https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html 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 session.py 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.
UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration
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.
References
Last updated