We will now be switching gears to cover how CloudTrail can help us out as an attacker. One of the ways it can help us is with reconnaissance and information gathering.
You might not always be able to compromise a user who has the necessary S3 read permissions and has access to encrypt the data with the KMS key used originally. If you don't have both of those permissions, then you won't be able to read the log files. There might even be other restrictions in place that make it difficult for you. To get around this, we can use our cloudtrail:LookupEvents permission to interact with the CloudTrail Event history. The CloudTrail Event history is an always-on, immutable record of read/write management events that is made available through the CloudTrail API. These logs can be fetched by using the LookupEvents API or by visiting the Event history page in the AWS web console:
Because the CloudTrail Event history is immutable and separate from S3, it can be a useful tool for both defenders and attackers. As a defender, if something happens and your CloudTrail logs get modified or deleted and you can recover them, the CloudTrail Event history could be a useful place to go to find out what happened during that time period (if it is in the last 90 days). As an attacker, we can use it to gather information about the target environment without needing to access S3 or KMS.
Due to the number of logs that get stored in Event history and the incredibly slow API calls required to download them, it can be difficult to review large amounts of information without some sort of filter. For reasons that can likely be attributed to you should use a real trail and not just the Event history; the CloudTrail LookupEvents API will only return 50 events at a time and is rate-limited to one call per-second. In big environments, this means it could take huge amounts of time to download all the logs for even just the past day. This leaves us with two options: one is to just wait out the download and try to get as many as possible, but that is not recommended due to the huge amount of time that may be involved. The second option is to inspect and filter the logs prior to downloading them, so that there are far fewer to wait on.
We can gather a lot of information from looking at different events in the Event history. On a large scale, we can determine what users/services are active and what kind of activity they do, and we can learn about their habits in AWS. This helps us because we can then use this knowledge during the attack. This way, we can stay under the radar by not doing anything that could be out of the ordinary in the account. Through the AWS web console, we have gone ahead and selected the CloudTrail CreateTrail Event that was generated when we set up the trail earlier in this chapter. The web console will aggregate the information into an easily viewable format, but we can click the View event button that appears in order to look at the raw JSON of the request. That JSON looks something like the following:
{
"eventVersion": "1.06",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDARACQ1TW2RMLLAQFTX",
"arn": "arn:aws:iam::000000000000:user/TestUser",
"accountId": "000000000000",
"accessKeyId": "ASIAQA94XB3P0PRUSFZ2",
"userName": "TestUser",
"sessionContext": {
"attributes": {
"creationDate": "2018-12-28T18:49:59Z",
"mfaAuthenticated": "true"
}
},
"invokedBy": "signin.amazonaws.com"
},
"eventTime": "2018-12-28T20:07:51Z",
"eventSource": "cloudtrail.amazonaws.com",
"eventName": "CreateTrail",
"awsRegion": "us-east-1",
"sourceIPAddress": "1.1.1.1",
"userAgent": "signin.amazonaws.com",
"requestParameters": {
"name": "ExampleTrail",
"s3BucketName": "example-for-cloudtrail-logs",
"s3KeyPrefix": "",
"includeGlobalServiceEvents": true,
"isMultiRegionTrail": true,
"enableLogFileValidation": true,
"kmsKeyId": "arn:aws:kms:us-east-1:000000000000:key/4a9238p0-r4j7-103i-44hv-l457396t3s9t",
"isOrganizationTrail": false
},
"responseElements": {
"name": "ExampleTrail",
"s3BucketName": "example-for-cloudtrail-logs",
"s3KeyPrefix": "",
"includeGlobalServiceEvents": true,
"isMultiRegionTrail": true,
"trailARN": "arn:aws:cloudtrail:us-east-1:000000000000:trail/ExampleTrail",
"logFileValidationEnabled": true,
"kmsKeyId": "arn:aws:kms:us-east-1:000000000000:key/4a9238p0-r4j7-103i-44hv-l457396t3s9t",
"isOrganizationTrail": false
},
"requestID": "a27t225a-4598-0031-3829-e5h130432279",
"eventID": "173ii438-1g59-2815-ei8j-w24091jk3p88",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "000000000000"
}
Even just from this single event, we can gather quite a bit of information about the user and the environment. The first thing we can see is that this API call was made by an IAM user along with a list of the user ID, ARN, account ID, access key ID used, user name, and whether they were MFA authenticated. Also, the invokedBy key has the value of signin.amazonaws.com, which tells us they were logged into the AWS web console when they performed this action, rather than using the CLI. Then we can see information about the request itself, which includes what event it was, what service that event was for, when the event happened, and then a few parameters included in the request. After that we see parameters returned from the API in the response, which tell us a little about the newly created CloudTrail trail.
Two of the most important things we skipped over included the IP address that the request originated from and the user agent used for the request. The IP will tell us where the call came from and with a larger sample set could potentially allow us to determine where the users work from, what the office IP address is, and more. For example, if we see that multiple users are originating from the same IP address during work hours (9am to 5pm), it would be safe to assume that they are all at the office or all on a VPN when working with AWS APIs. We then know that it would be strange if one of those users started coming from some external IP we haven't seen before when we compromise them, so we can build our attack plan around that to try and avoid it.
The same thing goes for user agents. In the preceding example event, the user agent was signin.amazonaws.com, which is the user agent that appears when using the AWS web console. If we look at a different event, such as when we used the GetEventSelectors API from the AWS CLI, we can see that the user agent is much more specific:
{
"eventVersion": "1.06",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDARACQ1TW2RMLLAQFTX",
"arn": "arn:aws:iam::000000000000:user/TestUser",
"accountId": "000000000000",
"accessKeyId": "AKIAFGVRRHYEFLLDHVVEA",
"userName": "TestUser"
},
"eventTime": "2018-12-28T20:57:17Z",
"eventSource": "cloudtrail.amazonaws.com",
"eventName": "GetEventSelectors",
"awsRegion": "us-east-1",
"sourceIPAddress": "1.1.1.1",
"userAgent": "aws-cli/1.16.81 Python/3.7.0 Windows/10 botocore/1.12.71",
"requestParameters": {
"trailName": "ExampleTrail"
},
"responseElements": null,
"requestID": "f391ba17-519x-423r-8b1t-16488a26b02p",
"eventID": "562b2177-1ra0-2561-fjm0-3f1app6ac375",
"readOnly": true,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "000000000000"
}
The user agent from this request is set to aws-cli/1.16.81 Python/3.7.0 Windows/10 botocore/1.12.71, which gives us a lot of information about the system the user is using. We can see they used version 1.16.81 of the AWS CLI, which is using Python version 3.7.0, on Windows 10, and using version 1.12.71 of the botocore library. This information on its own gives us an insight into the systems that may be in use at our target company, but also it allows us to gather a list of known user agents in the environment. With that list, we can then spoof our own user agent to look like a known one so that we don't stand out as abnormal in our API requests.
There are many things you can do by looking through CloudTrail logs/Event history, including the small amount of information gathering we did earlier. You could also determine what AWS services are in use in the account based on API calls made to those services, and you can potentially discover helpful information about specific resources in the account. For example, let's say that you don't have the ec2:DescribeInstances permission, but you have the ec2:ModifyInstance permission. In theory, you wouldn't be able to get a list of EC2 instances to then use the ec2:ModifyInstance API on because you don't have access, but you could look through CloudTrail logs to find an event where someone interacted with an EC2 instance in the past. That event will likely include the instance ID and possibly other information that could be helpful to you in discovering those assets in the environment.
Event history isn't the only place to look for this information either, because if you do have the necessary S3 and KMS permissions, you could just download the logs straight from the S3 bucket they are delivered to, which would be much quicker and much easier to parse than the output of the Event history API. Be careful to not trip any wires, though, as activity within that bucket might be being monitored, and a bunch of requests to download files from it could potentially look suspicious to a defender.