Pacu allows us to use AWS CLI directly from Pacu CLI for situations where you may want to run a single command, rather than a full module. Let's use this functionality and our new administrator permissions to run an AWS CLI command to request data that we didn't previously have. This can be done just by running the AWS CLI command as we normally would, so that we can try running a command to enumerate other resources in the account. We are currently in our own personal account, so this command might not return any valid data for you, but it will be important to check this API call in other accounts that you are attacking.
We can check if the account has GuardDuty enabled in the us-east-1 region by running this command from the Pacu CLI:
aws guardduty list-detectors --profile Test --region us-west-2
In our Test account, we do have GuardDuty running, so we get the output shown in the following screenshot. But if you do not have GuardDuty running, then the DetectorIds field will be empty:
The command returned a single DetectorId from AWS. For this API call, the presence of any data means that GuardDuty has been enabled previously for this region, so it is safe to assume that it is still enabled without making any more API calls. If GuardDuty is disabled in the target region, DetectorIds will just be an empty list. As an attacker, it is preferable for GuardDuty to be disabled, because then we know that it is not alerting our target to any malicious activity that we are performing.
Even if GuardDuty is enabled, however, this does not mean that our efforts are futile. There are many factors that come into play in an attack scenario like this, such as if anyone is even paying attention to the GuardDuty alerts that are being triggered, the response time for someone to react to the alerts if they do notice one, and whether the person reacting has a strong understanding of AWS to be able to trace your actions fully.
We can check for GuardDuty, and other logging and monitoring services by running the detection__enum_services Pacu module. This module will check for CloudTrail configurations, CloudWatch alarms, the active shield Distributed Denial of Service (DDoS) protection plan, GuardDuty configurations, Config configurations and resources, and virtual private cloud (VPC) flow logs. These services all have different purposes, but as an attacker it is important to know what is watching you and what is tracking you.
Pacu has many modules within the enum category that can be used to enumerate various resources in our target AWS account. Some interesting modules to check include the aws__enum_account module, which enumerates information about current AWS account; the aws__enum_spend module, which gathers a list of AWS services that money is being spent on (so you can determine what services are in use without needing to query that services API directly); or the ec2__download_userdata module, which downloads and decodes the EC2 user data that is attached to each EC2 instance in the account.
EC2 user data is essentially just some text that you add to an EC2 instance, and once the instance is online that data is made available to it. This can be used to set up the initial configuration of an instance or provide it with settings or values that it might need to query later. It is also possible to execute code through EC2 user data.
Often, users or software will place hardcoded secrets (such as API keys, passwords, and environment variables) into EC2 user data. This is bad practice and is discouraged by Amazon in their documentation, but it continues to be a problem. As an attacker, this works to our benefit. EC2 user data can be read by any user with the ec2:DescribeInstanceAttribute permission, so any hardcoded secrets are also made available to them. As an attacker, it is important to check this data for anything that may be useful.
The ec2__download_userdata Pacu module will automatically go through and download the user data for all the instances and launch templates that were enumerated in the account, making it easy for us to sift through the results.
You can run the following command to start the module:
run ec2__download_userdata
Now Pacu will check each EC2 instance that it is aware of for user data, and if there is any, it will download it to the ./sessions/[session name]/downloads/ec2_user_data/ folder inside the main Pacu directory.
If you haven't already enumerated EC2 instances and launch templates in the target account with the ec2__enum module, you will be prompted to run it prior to the module executing. You will likely be presented with a message that confirms if you want to run the module against every AWS region, which for right now is fine, so we will answer y:
After the EC2 instances have been enumerated, it will likely ask you the same question for EC2 launch templates, which also hold user data. We can allow this to enumerate as well.
After instances and launch templates have been enumerated, the execution will switch back to our original ec2__download_userdata module to download and decode the user data associated with any instances or launch templates that we found.
The module found three EC2 instances and one EC2 launch template in our account that had user data associated with them. The following screenshot shows the output from the module, including the results of its execution and where it stored that data:
The ec2__download_userdata module found user data attached to three out of four EC2 instances in the account and one out of one launch template found in the account. It then saved that data to the ./sessions/Demo/downloads/ec2_user_data/ folder of the Pacu directory.
If we navigate to the folder that these files were downloaded to and open them in a text editor, we can see the data in plaintext. The following screenshot shows that the instance with the i-0d4ac408c4454dd9b ID instance in the ap-northeast-2 region had the user data that follows:
This is just an example to demonstrate the concept, so basically when the EC2 instance is started up, it will run this command:
echo "test" > /test.txt
Then it will continue the boot process. Most of the time, scripts that are passed into the EC2 user data are only executed when an instance is first created, but by using the #cloud-boothook directive in the preceding user data, the instance is instructed to run this code on every single boot instead. This is a good method to use to gain persistent access to EC2 instances by placing a reverse shell in the user data to be executed on every instance reboot, but this will be looked at more in further chapters.