# Stopping S3 Data Exfiltration in Real Time: A Step-by-Step Incident Response

An EC2 instance with access to sensitive S3 data is compromised by an attacker. The attacker uses temporary credentials obtained from the metadata service to download large amounts of data. GuardDuty alerts the development team, who must act quickly to stop the data exfiltration. This article explains the step-by-step process to revoke the compromised IAM role's temporary credentials and prevent further unauthorized access.

Step 1: Identify the compromised IAM role by examining the EC2 instance ID from the GuardDuty finding. Use the AWS CLI command to describe the EC2 instance and retrieve the instance profile ARN. Then, get the role name from the instance profile using the AWS IAM CLI.

Step 2: Invalidate all active sessions by attaching an inline deny policy to the IAM role. The policy denies all actions for any temporary credentials issued before a specific timestamp. Replace the timestamp with the current UTC time or use the console shortcut. Alternatively, the console provides a Revoke Sessions tab that automatically attaches the policy.

The inline policy works by evaluating every API call made with the temporary credentials. It checks the aws:TokenIssueTime claim in the request and denies the request if the timestamp is older than the specified limit. This mechanism ensures that all previously issued credentials are immediately invalidated, regardless of the source IP or network.

Step 3: Validate the revocation by checking the IAM policy attached to the role and confirming that the attacker's access has been cut. Use the AWS CLI to query CloudTrail for AccessDenied events related to S3 GetObject calls after the revocation timestamp. If AccessDenied responses are returned for legitimate access attempts, the revocation is successful.

Step 4: Verify that legitimate workloads can still access the S3 bucket. SSH into a healthy EC2 instance with the same IAM role or a test instance and use the AWS CLI to list the bucket contents. If the command returns the expected data, legitimate access is still working properly.

While revoking the IAM role's temporary credentials is an effective solution for immediate threat mitigation, it has some limitations. The role remains active, so revocation does not disable the role itself. New credentials issued after the revocation timestamp will still work, which means an attacker who still has access to the instance could obtain fresh credentials and bypass the revocation.

To address this, it is recommended to combine revocation with instance isolation by stopping or quarantining the compromised EC2 instance. This prevents the attacker from obtaining new credentials and ensures that the compromised credentials cannot be used from a different network.

Another limitation is that temporary credentials are still valid for a certain period (typically 15 minutes). If the attacker manages to obtain the credentials before revocation and uses them within this time window, they will bypass the revocation. Therefore, it is crucial to act quickly in response to an incident.

In summary, revoking the IAM role's temporary credentials is a crucial step in responding to an S3 data exfiltration incident. It invalidates all previously issued credentials and prevents further unauthorized access. However, it should be combined with instance isolation to ensure that the compromised role cannot be used for new credential issuance. By following this process, organizations can effectively mitigate the impact of S3 data exfiltration attacks and protect their sensitive data.