Incident response guide for AWS CloudTrail investigations – Part 2

In Part 1 of this guide, we examined two common incident scenarios: cross-account Amazon Simple Storage Service (Amazon S3) data deletion with ransomware implications, and cryptocurrency mining deployed through AWS CloudFormation using exposed AWS Management Console credentials. We also introduced k

<p><span class="LinkEnhancement"><a class="Link" href="https://aws.amazon.com/blogs/security/incident-response-guide-for-aws-cloudtrail-investigations-part-1/" target="_blank" rel="noopener" data-cms-ai="0">In Part 1</a></span> of this guide, we examined two common incident scenarios: cross-account <span class="LinkEnhancement"><a class="Link" href="https://aws.amazon.com/s3" target="_blank" rel="noopener" data-cms-ai="0">Amazon Simple Storage Service (Amazon S3)</a></span> data deletion with ransomware implications, and cryptocurrency mining deployed through <span class="LinkEnhancement"><a class="Link" href="https://aws.amazon.com/cloudformation" target="_blank" rel="noopener" data-cms-ai="0">AWS CloudFormation</a></span> using exposed AWS Management Console credentials. We also introduced key incident response terminology and investigative frameworks for analyzing <span class="LinkEnhancement"><a class="Link" href="https://aws.amazon.com/cloudtrail" target="_blank" rel="noopener" data-cms-ai="0">AWS CloudTrail</a></span> events.</p>

<p>In this second part, we explore a more complex, multi-stage attack: how a web application vulnerability can cascade into credential harvesting and unauthorized access to Amazon Bedrock services across multiple AWS Regions. We also cover additional investigation techniques and hardening steps to strengthen your security posture.</p>

<div class="RichTextHeading">

<h2><b>Scenario 3: SSRF to IMDSv1 credential harvesting with multi-Region Amazon Bedrock service misuse</b></h2>

</div>

<p>This scenario examines how a web application vulnerability can cascade into a multi-Region event targeting Amazon Bedrock services. The investigation demonstrates how threat actors chain together multiple techniques, using <span class="LinkEnhancement"><a class="Link" href="https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html" target="_blank" rel="noopener" data-cms-ai="0">Amazon Elastic Compute Cloud (Amazon EC2) Instance Metadata Service version 1 (IMDSv1)</a></span> through server-side request forgery (SSRF) and cross-Region pivoting to access Amazon Bedrock.</p>

<p>Your security team receives multiple alerts: failed <span class="LinkEnhancement"><a class="Link" href="https://aws.amazon.com/iam" target="_blank" rel="noopener" data-cms-ai="0">AWS Identity and Access Management (IAM)</a></span> operations in the us-east-1 Region, successful console sign-ins without multi-factor authentication (MFA), and unusual <span class="LinkEnhancement"><a class="Link" href="https://aws.amazon.com/bedrock" target="_blank" rel="noopener" data-cms-ai="0">Amazon Bedrock</a></span> API calls from us-east-2. Initially, these might seem like unrelated events across different services and Regions. However, as our Security Incident Response Team (SIRT) discovered, they represent a carefully orchestrated event chain that began with a web application vulnerability and culminated in unauthorized access to your organization’s AI infrastructure.</p>

<div class="RichTextHeading">

<h3><b>Architecture and progression</b></h3>

</div>

<p>The architecture in figure 1 maps a multi-stage attack that exploits the trust relationship between <span class="LinkEnhancement"><a class="Link" href="https://aws.amazon.com/ec2" target="_blank" rel="noopener" data-cms-ai="0">Amazon Elastic Compute Cloud (Amazon EC2)</a></span> instances and AWS services. A threat actor identified a server-side request forgery (SSRF) vulnerability in a web application running on an EC2 instance that had an attached <code class="CodeInline" style="color: #000">webdev</code> IAM role. Rather than attempting to escalate privileges directly, the threat actor used this foothold to reach the Instance Metadata Service version 1 (IMDSv1) endpoint and retrieve the temporary credentials issued to the <code class="CodeInline" style="color: #000">webdev</code> role. Because IMDSv1 returns credentials in response to a basic request with no session token, an SSRF flaw is enough to harvest them, which is why these credentials became the pivot point for everything that followed. The attack unfolded in five stages. Each stage is numbered in figure 1 so you can follow the progression from the initial web request through to the cross-Region Amazon Bedrock activity:</p>

<ol id="rte-5b61ece1-a2e9-11f1-97e2-abac47775c33" class="rte2-style-ol" start="1">

<li><b>Initial access</b>: The threat actor exploited the SSRF vulnerability in the web application to make server-side requests on the instance’s behalf.</li>

<li><b>Credential harvesting

Source: AWS Security Blog