Article by Nick Frichette

Bypass GuardDuty Pentest Findings for the AWS CLI¶

As a cloud Penetration Tester or Red Teamer, we need to be aware of what artifacts we leave behind in the logs that we touch. One easy to overlook clue is the User-Agent value passed in AWS API requests. When using the AWS CLI or SDK to interact with AWS services, the User-Agent string is passed in the headers of the HTTP request. This string can be used to identify the tool or library making the request.

This can give away the operating system you are using and may raises suspicion from defenders. For example, say you steal credentials from a developer workstation running MacOS and suddenly start making requests from a Windows machine. This suspicious activity could be noticed by automation and an alarm could be raised.

This is where AWS GuardDuty comes in. GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior to protect your AWS accounts and workloads. GuardDuty takes this idea a step further and has built-in detections for common penetration testing Linux distributions like Kali Linux, ParrotOS, and Pentoo Linux. If you make AWS API requests from one of these distributions, GuardDuty will trigger a PenTest Finding.

As you can imagine, this is not ideal. The good news is that the User-Agent string is entirely within our control. While this value is unfortunately something we cannot natively configure with the AWS CLI, we can use external tooling to intercept our requests and modify them. In this article, we will explain how we can modify our User-Agent string when using the AWS CLI to avoid triggering GuardDuty alerts.

Burp Suite Setup and Usage¶

To begin, download and install Burp Suite Community Edition. With it running, navigate to the Proxy tab and click Proxy settings.

Next, scroll to HTTP match and replace rules:

From here, click Add and enter the following values:

• Type: Request header
• Match: ^User-Agent.*$
• Regex match: Should be checked
• Replace: This can be any string of your choosing. Ensure you preprend User-Agent: to the beginning of the string. For a list of potential User-Agent values, you can refer to this list from Pacu.

Click Test to see an example of what your change would look like.

To finish, click OK. To ensure your new rule is enabled, scroll to the bottom of your match and replace rules.

Next, we need to configure our AWS CLI to use Burp Suite as a proxy. This can be done by setting the HTTP_PROXY and HTTPS_PROXY environment variables. For example:

export HTTPS_PROXY=http://127.0.0.1:8080
export HTTP_PROXY=http://127.0.0.1:8080

With this setup, all of your AWS CLI requests will be routed to Burp Suite, however you will likely encounter the following error:

SSL validation failed for https://sts.us-east-1.amazonaws.com/ [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate in certificate chain (_ssl.c:1129)

This is because Burp Suite uses a self-signed certificate. There are multiple options to resolve this issue and I will defer to your professional discretion on which to use. You could, for example, add the self-signed certificate to your trusted certificates. Alternatively you could disable SSL verification with the AWS CLI using the --no-verify-ssl flag.

Regardless of the method you choose, after making a request to the AWS API you should see the User-Agent string you configured appear in the associated CloudTrail logs.

With all of this in place, you can now make requests to the AWS API using the CLI without triggering GuardDuty alerts.