Respond to IAM Role credential exfiltration

In this module, you will take manual steps to simulate a scenario (IAM Role credential exfiltration) that you will then investigate and remediate. You will copy IAM temporary security credentials from the EC2 instance and use them to make API calls from your laptop. Then you will investigate the GuardDuty finding for this activity.

Retrieve the IAM temporary security credentials using AWS Systems Manager

To simulate this threat you will retrieve the IAM temporary security credentials generated by the IAM Role for EC2. You can either SSH directly into the instance and query the metadata or follow the steps below using AWS Systems Manager Session Manager .

Session Manager is a managed service that provides you with one-click secure access to your instances without the need to open inbound ports and manage bastion hosts. You have centralized access control over who can access your instances and full auditing capabilities to ensure compliance with corporate policies.

1. Go to Session Manager in the AWS Systems Manager console.

2. Click the Start Session button.

3. Select the GuardDuty-ICE-Instance and click Start session. This will start a shell session that you will use to fetch the active security credentials on the instance.

4. In the shell, run the following command:

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` && curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/

Then run this:

curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/GDWorkshop-EC2-Compromised

5. Make note of the AccessKeyID, SecretAccessKey, and Token. Now that you have retrieved the IAM temporary security credentials from the EC2 instance, use them to setup an AWS CLI profile on your local machine. Then we’ll use the profile to make API calls.

Use the security credentials from your laptop

6. From a command prompt, run the following commands (replacing <AccessKeyId>, <SecretAccessKey>, and <Token> with your credentials). Make sure the region corresponds to the region you have been working in.

aws configure set profile.badbob.region us-east-1

aws configure set profile.badbob.aws_access_key_id <AccessKeyId>

aws configure set profile.badbob.aws_secret_access_key <SecretAccessKey>

aws configure set profile.badbob.aws_session_token <Token>

7. Now that you have your profile, you can use it to make API calls. Explore what you have access to by running the following commands to query different services. Don’t be surprised if you see some access denied responses, it is intended. Run the following commands. Do you have any IAM permissions?

aws iam get-user --profile badbob

Answer: This command should return an AccessDenied error.

aws iam create-user --user-name Chuck --profile badbob

8. What about DynamoDB? Try the following commands.

aws dynamodb list-tables --profile badbob

aws dynamodb describe-table --table-name GuardDuty-Example-Customer-DB --profile badbob

9. Can you query the data? aws dynamodb scan --table-name GuardDuty-Example-Customer-DB --profile badbob

Continue to run the other commands:

aws dynamodb scan --table-name GuardDuty-Example-Customer-DB --profile badbob

aws dynamodb delete-table --table-name GuardDuty-Example-Customer-DB --profile badbob

Check resources after deleting: aws dynamodb list-tables --profile badbob

10. Do you have access to Systems Manager Parameter Store? Answer: No.

aws ssm describe-parameters --profile badbob

aws ssm get-parameters --names "gd_prod_dbpwd_sample" --profile badbob

aws ssm get-parameters --names "gd_prod_dbpwd_sample" --with-decryption --profile badbob

aws ssm delete-parameter --name "gd_prod_dbpwd_sample" --profile badbob

Investigate the GuardDuty finding

11. In the steps above, you simulated IAM Role credential exfiltration. Now you will investigate the GuardDuty finding generated as a result of the actions you took. Begin by navigating to the GuardDuty console .

12. You should see a finding with the type UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS. If you do not see the finding, you may need to refresh the page and/or wait a few minutes.

13. Click on the UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS finding to view the full details. Looking at the finding details you can see that this is a HIGH severity finding. This finding informs you of attempts to run AWS API operations from a host outside of EC2, using temporary AWS credentials that were created on an EC2 instance in your AWS account. This indicates your EC2 instance has been compromised, and the temporary credentials from the instance have been exfiltrated to a remote host outside of AWS.

Review the automated remediation

In this scenario, there is already automated remediation for this finding type set up using Amazon EventBridge and AWS Lambda. AWS Lambda is a serverless, event-driven compute service that lets you run code for virtually any type of application or backend service without provisioning or managing servers. You can trigger Lambda from over 200 AWS services, and only pay for what you use. Amazon EventBridge is a serverless event bus that makes it easier to build event-driven applications at scale using events generated from your applications and AWS services. EventBridge delivers a stream of real-time data from event sources to targets like AWS Lambda. Let’s review the automation and see if it worked!

14. Navigate to the Amazon EventBridge console . From the left navigation, under the Buses section, click Rules.

15. Click on the rule Name that was configured for this particular finding, GuardDuty-Event-IAMUser-InstanceCredentialExfiltration. Take a look at the Event Pattern. Event patterns have the same structure as the events they match. Rules use event patterns to select events and send them to targets. An event pattern either matches an event or it doesn’t. Here you can see we are only matching events with the type “UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS” from “aws.guardduty”.

JSON result:

{
  "source": ["aws.guardduty"],
  "detail": {
    "type": ["UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS"]
  }
}

16. When an event matches the Event pattern seen above, it can be sent to Targets. Click on the Targets tab. This rule is configured to send these findings to a Lambda function and an SNS topic.

17. Let’s check out the Lambda function that we are sending these findings to. Go to the Lambda console and click the function named GDWorkshop-Remediation-InstanceCredentialExfiltration. The Lambda function retrieves the Role name from the finding details and then attaches an IAM policy that revokes all active sessions for the role.

from __future__ import print_function
from botocore.exceptions import ClientError
import json
import datetime
import boto3
import os
 
def handler(event, context):
 
  # Log out event
  print("log -- Event: %s " % json.dumps(event))
 
  # Create generic function response
  response = "Error auto-remediating the finding."
 
  try:
 
    # Set Clients
    iam = boto3.client('iam')
    ec2 = boto3.client('ec2')
 
    # Set Role Variable
    role = event['detail']['resource']['accessKeyDetails']['userName']
 
    # Current Time
    time = datetime.datetime.utcnow().isoformat()
 
    # Set Revoke Policy
    policy = """
      {
        "Version": "2012-10-17",
        "Statement": {
          "Effect": "Deny",
          "Action": "*",
          "Resource": "*",
          "Condition": {"DateLessThan": {"aws:TokenIssueTime": "%s"}}
        }
      }
    """ % time
 
    # Add policy to Role to Revoke all Current Sessions
    iam.put_role_policy(
      RoleName=role,
      PolicyName='RevokeOldSessions',
      PolicyDocument=policy.replace('\n', '').replace(' ', '')
    )
 
    response = "GuardDuty Remediation | ID:%s: GuardDuty discovered EC2 IAM credentials (Role: %s) being used outside of the EC2 service.  All sessions have been revoked.  Please follow up with any additional remediation actions." % (event['detail']['id'], role)
 
  except ClientError as e:
    print(e)
 
  print("log -- Response: %s " % response)
  return response

Verify that the remediation was successful

18. To verify that the InstanceCredentialExfiltration finding was remediated, you can run one of the CLI commands you ran earlier on you local machine again. You should see an error response “with an explicit deny in an identity-based policy”.

aws dynamodb list-tables --profile badbob

22. You can also view the Role to evaluate the policy that was attached. Navigate to the AWS IAM console.

23. Click Roles in the left navigation.

24. Click on the Role you identified in the GuardDuty finding, GDWorkshop-EC2-Compromised.

25. Under the the Permissions tab, click the RevokeOldSessions policy. Notice the explicit deny all.