There are three GuardDuty alerts under the PenTest category of findings types. These findings are PenTest:IAMUser/KaliLinux, PenTest:IAMUser/ParrotLinux, and PenTest:IAMUser/PentooLinux, which alert when AWS API calls are made from a Kali Linux server, Parrot Linux server, or Pentoo Linux server, respectively. These are rather simple to bypass, as long as you know what is causing them to get detected.
Regardless of the client you are using to interact with the API, whether that is one of the SDKs from the various languages that are supported (such as Java, Python, or Node.js), the AWS CLI (which uses Python behind the scenes), the AWS web console, or just raw HTTP requests, you will always have a user agent that describes your operating system and version, along with other software and their versions that are in use when making the request. This user agent string is then logged by CloudTrail, like we saw in Chapter 15, Pentesting CloudTrial.
Here's an example user agent that is sent when using the AWS CLI on Kali Linux:
aws-cli/1.16.89 Python/3.6.8 Linux/4.19.0-kali1-amd64 botocore/1.12.79
This user agent tells us a few things:
- The AWS CLI, version 1.16.89, was used to make the request.
- The AWS CLI is using Python version 3.6.8 behind the scenes.
- The operating system is Kali Linux with a kernel version of 4.19.0, running AMD 64.
- Python is using version 1.12.79 of the botocore library.
Here's an example user agent that is sent when using the AWS CLI on Parrot Linux:
aws-cli/1.16.93 Python/3.6.8 Linux/4.19.0-parrot1-13t-amd64 botocore/1.12.83
This user agent tells us a few things:
- The AWS CLI, version 1.16.93, was used to make the request.
- The AWS CLI is using Python version 3.6.8 behind the scenes.
- The operating system is Parrot Linux with a kernel version of 4.19.0, running AMD 64.
- Python is using version 1.12.83 of the botocore library.
An example user agent that is sent when using the AWS CLI on Pentoo Linux can be seen as follows:
[aws-cli/1.16.93 Python/2.7.14 Linux/4.17.11-pentoo botocore/1.12.83]
This user agent tells us a few things:
- The AWS CLI, version 1.16.93, was used to make the request.
- The AWS CLI is using Python version 2.7.14 behind the scenes.
- The operating system is Pentoo Linux with a kernel version of 4.17.11.
- Python is using version 1.12.83 of the botocore library.
When using the AWS web console, most CloudTrail logs will use the following user agent:
signin.amazonaws.com
This user agent tells us that the user is logged into the AWS web console, rather than using another method of interacting with the API.
For the Kali, Parrot, and Pentoo Linux user agents, we can see that they all contain their respective operating system names (kali, parrot, pentoo). This is essentially all that GuardDuty is looking for to identify the use of these operating systems, when reporting on the PenTest finding types that it offers.
To get your own user agent, you can make any AWS request to the API that will get logged in CloudTrail, then you can view the details of that CloudTrail event to see what user agent was logged. If you are using the Python boto3 library to interact with the AWS API, you can use the following line of code to print out what your user agent is:
print(boto3.session.Session()._session.user_agent())
To avoid these GuardDuty checks, even if we are using Kali Linux, Parrot Linux, or Pentoo Linux, we simply need to modify the user agent we are using before we make requests to the AWS API. As long as GuardDuty doesn't detect kali, parrot, or pentoo in our user agent, then we are alright.
The following code block shows a small example of how we might detect any of these operating systems, how to change the user agent in that scenario, and then how to successfully make a request with a modified user agent. This code is following the same Python 3 with boto3 pattern that we have followed throughout the book:
import random
import boto3
import botocore
# A list of user agents that won't trigger GuardDuty
safe_user_agents = [
'Boto3/1.7.48 Python/3.7.0 Windows/10 Botocore/1.10.48',
'aws-sdk-go/1.4.22 (go1.7.4; linux; amd64)',
'aws-cli/1.15.10 Python/2.7.9 Windows/8 botocore/1.10.10'
]
# Grab the current user agent
user_agent = boto3.session.Session()._session.user_agent().lower()
# Check if we are on Kali, Parrot, or Pentoo Linux against a lowercase version of the user agent
if 'kali' in user_agent.lower() or 'parrot' in user_agent.lower() or 'pentoo' in user_agent.lower():
# Change the user agent to a random one from the list of safe user agents
user_agent = random.choice(safe_user_agents)
# Prepare a botocore config object with our user agent
botocore_config = botocore.config.Config(
user_agent=user_agent
)
# Create the boto3 client, using the botocore config we just set up
client = boto3.client(
'ec2',
region_name='us-east-1',
config=botocore_config
)
# Print out the results of our EC2 DescribeInstances call
print(client.describe_instances())
Essentially, all this code is doing is checking whether kali, parrot, or pentoo are in the user agent string of our client, and if so, changing that to a known, safe user agent. This modification to our request will allow us to completely bypass the PenTest/user agent checks that GuardDuty makes.
Although it was this easy to bypass these GuardDuty checks with the boto3 library directly, it is a bit trickier (though, not impossible) when working with the AWS CLI. You will also need to add this code to any other piece of software that you are using, in order to ensure that you are never detected during your attack; however, luckily, Pacu takes this into consideration.
When launching Pacu (python3 pacu.py), this check for Kali, Parrot, and Pentoo Linux is performed for you automatically. If Pacu detects that you are running any of those operating systems, then it will automatically select a known safe user agent from a list it stores locally, and it will use this new user agent for any and all AWS requests that Pacu makes. This check will apply to the entire Pacu session that is created, so you will only see the warning that the change was made when you create your Pacu session. If you move that session to another computer, it will keep the user agent it chose originally, so all requests show up as consistent in CloudTrail.
On Pacu's startup, when you create a new session on one of the three operating systems we have been looking at, you will see something like the following message:
Now, anyone who inspects the CloudTrail logs will see that we are using Windows 10, not Kali Linux. That means GuardDuty will see the same thing and not trigger any of those findings on us.
Although these findings are listed under the PenTest GuardDuty category, which doesn't necessarily sound malicious, these checks are some of the most important ones we can work to bypass. This is because the use of any of these three operating systems will look highly suspicious to a defender who knows that they are not normally (or ever) used in their environment, which means our attack will likely be investigated and stopped within a short time.
When modifying our user agent in situations like this, it might not always make sense to use a seemingly random user agent as our replacement. Let's say that we compromised an account that strictly uses the AWS Java SDK for their API calls, but we compromise a user and change our user agent to reflect that we are using the Python boto3 library. This will look suspicious to any defender paying attention to this kind of thing. This type of detection is highly unreliable due to the user agent being in control of the user, so it probably will not be something that you encounter often, but it might be smart to pay attention anyway.
To beat any user agent detection, we could potentially review the CloudTrail logs of our target account to find the previous API calls that were made from the user that we compromised. Then, we could copy that user agent and use it as our own, killing two birds with one stone. We will hide the fact that we are on Kali, Parrot, or Pentoo Linux, and we will fit into the norm of the environment by using a user agent that has been seen before.