Transforming Security Incident Metadata to Security Outcomes

Transforming Security Incident Metadata to Security Outcomes

Speakers: Cydney Stude (Senior Security Engineer, AWS); Steve de Vera (Manager, AWS)

Conference: fwd:cloudsec

YouTube: https://www.youtube.com/watch?v=qIuGMxpQVGs

Overview

In this insightful talk from fwd:cloudsec, Cydney Stude and Steve de Vera from AWS Security Incident Response unveil the Threat Technique Catalog for AWS (TTC), a crucial initiative designed to enhance understanding and defense against adversarial behaviors within the Amazon Web Services ecosystem. The presentation details AWS's journey from a nascent state of incident tracking to establishing a robust framework that extends the widely recognized MITRE ATT&CK model with AWS-specific tactics, techniques, and procedures (TTPs). This catalog is not merely a theoretical exercise; it is continuously refined with real-world observations from the AWS Customer Incident Response Team, providing an invaluable resource for both AWS and its customers to proactively identify, detect, and mitigate emerging threats.

The core objective of the TTC is to transform raw security incident metadata into actionable security outcomes. By systematically categorizing and detailing how threat actors exploit common misconfigurations and compromised credentials within AWS environments, the catalog empowers security professionals to better understand their attack surface, contextualize emerging TTPs, and implement targeted defenses. Stude and de Vera present several specific, observed techniques, ranging from the perennial problem of long-term credential compromise to more sophisticated methods like API Gateway persistence and LLM resource hijacking, underscoring the dynamic nature of cloud security challenges and the continuous need for adaptive defense strategies.

Background

▶ Watch: Introduction to transforming security incident metadata (0:00)

The proliferation of cloud services has introduced a new paradigm for cybersecurity, presenting both immense opportunities and complex challenges. While cloud providers like AWS offer a highly secure infrastructure, the shared responsibility model places significant onus on customers to secure their applications, data, and configurations within the cloud environment. A persistent challenge for customers and cloud providers alike has been the effective tracking and categorization of adversarial behavior specific to cloud platforms. Generic frameworks, while foundational, often lack the granular detail required to address the unique attack vectors and service interactions inherent in a complex ecosystem like AWS.

Prior to the Threat Technique Catalog for AWS (TTC), there was a recognized gap in a comprehensive, AWS-specific framework to map observed adversarial actions to broader tactics. Security teams often struggled to correlate disparate incident data points, such as CloudTrail events or guard duty findings, into a coherent understanding of an attacker's campaign. This fragmentation hindered the ability to identify trends, develop targeted detections, and provide clear, actionable mitigation advice to customers. The existing MITRE ATT&CK framework, while a cornerstone of threat intelligence, required significant interpretation and extension to be fully applicable to the nuances of AWS services and API calls. The AWS customer incident response team, constantly engaging with customers experiencing compromises due to misconfigurations or exposed credentials, recognized the urgent need for a structured approach to document and share these real-world TTPs, thereby transforming reactive incident response into proactive security guidance.

Key Findings

▶ Watch: TTC's quarterly release schedule and real-world data (2:00)

The central finding presented in the talk is the successful development and ongoing evolution of the Threat Technique Catalog for AWS (TTC). Launched in the past year, with a latest June catalog release just prior to the talk, the TTC serves as a critical extension of the MITRE ATT&CK framework, specifically tailored to map adversarial behavior on AWS to high-level tactics like initial access, execution, and impact. This catalog is distinguished by its direct reliance on real-world observations from the AWS customer incident response team, ensuring that the documented techniques reflect actual threats employed by adversaries, rather than theoretical possibilities.

Key findings derived from the catalog's data and observation include:

• Real-world, Continuously Evolving Data: The TTC is populated with techniques directly observed in customer incidents, making it highly relevant and practical. It follows a quarterly release schedule (March, June, September, December) to rapidly disseminate new information to customers, contrasting with MITRE's six-month cycle.
• Focus on "Interesting" Techniques: AWS intentionally omits some basic reconnaissance techniques to prioritize the development and documentation of more complex and impactful threat actor methods.
• Statistical Insights into Compromise Vectors: Analysis of unauthorized events reveals that a significant two-thirds are a direct result of compromised long-term credentials, such as static access keys. This highlights a critical and persistent vulnerability.
• Impact of MFA: A recurring observation is that a large proportion of unauthorized activity occurs without MFA (Multi-Factor Authentication), underscoring its foundational importance.
• Driving Service Team Improvements: The data collected through the TTC directly informs AWS service teams, leading to security enhancements. Examples include AWS Identity and Access Management (IAM) enforcing MFA for root users across all account types, updates to GuardDuty detections, and the default removal of S3 Encryption with SSE-C (Server-Side Encryption with Customer-Provided Keys) due to its historical exploitation in ransomware attacks.
• Programmatic Availability Roadmap: AWS plans to make the TTC programmatically available, likely as a STIX data bundle, to enable broader integration and automation for security teams.

These findings collectively demonstrate the TTC's value as both a knowledge base and a data-driven mechanism for improving cloud security posture across the AWS ecosystem.

Technical Deep Dive

▶ Watch: CloudTrail metadata analyzed for incident response (3:00)

The Threat Technique Catalog for AWS (TTC) is fundamentally an extension of the MITRE ATT&CK framework, designed to provide granular, AWS-specific context to adversarial TTPs. While MITRE ATT&CK offers a high-level taxonomy of adversary tactics, the TTC drills down into the specific AWS actions and API calls that correspond to these tactics, providing detailed detection and mitigation information relevant to the AWS environment.

At its core, the TTC maps observed adversarial behaviors to MITRE tactics such as Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Exfiltration, and Impact. For each technique, the catalog provides:

• A clear description of the adversarial action.
• Specific CloudTrail event names or patterns for detection.
• Actionable mitigation strategies.

The catalog distinguishes between techniques directly from MITRE (often displayed in blue) and AWS-specific extensions (displayed in orange, with unique identifiers like TTC2-202306001). This layering allows AWS to adapt existing MITRE techniques with cloud-specific detection and mitigation guidance while also documenting entirely new techniques unique to the AWS platform.

The metadata captured from security incidents, primarily through CloudTrail event records, is crucial for populating the TTC. Key metadata points include:

• Identity: The principal making the API call (e.g., assumed role, IAM user).
• MFA Authentication Status: Whether the identity was MFA-authenticated.
• API Call: The specific AWS API invoked (e.g., DescribeInstances, UpdateAssumeRolePolicy).
• Region: The AWS region where the action occurred.
• Service: The AWS service involved.
• IP Address: The source IP of the request (captured for threat intelligence).
• User Agent: The client application making the request (captured for threat intelligence).
• Request Parameters: Details of the API call's arguments (captured for threat intelligence).
• Session Credential from Console: A boolean indicating if the session originated from the AWS Management Console.

These data points allow AWS to identify specific trends, such as the prevalence of un-MFA'd access in unauthorized activity or the use of particular API calls by threat actors. For instance, the observation of a specific API call used by a threat actor group in early January enabled AWS to investigate and understand the underlying actions. This data is then used to inform service teams, leading to improvements like IAM enforcing MFA for root users and GuardDuty detection updates. The TTC's continuous evolution, with quarterly releases, ensures that it remains current with emerging threats, focusing on "interesting" and impactful techniques observed in real-world customer incidents rather than exhaustive coverage of every possible action.

Demo / Proof of Concept

▶ Watch: Statistic: 2/3rds of incidents from compromised credentials (5:30)

While not a live software demonstration, the talk effectively serves as a "proof of concept" by detailing several observed Threat Actor Techniques (TTPs) that have been cataloged in the TTC. These examples illustrate how adversaries exploit common misconfigurations and vulnerabilities within AWS environments.

1. Long-Term Credentials (TTC ID: TTC2-202306000):

• How it works: Threat actors obtain long-term credentials (e.g., static access keys, username/password combinations) through various means (e.g., leaks, phishing). They then use these credentials to gain initial access to an AWS account and subsequently attempt to elevate permissions or perform other actions.
• Observed actions: Initial compromise, followed by attempts to add new permissions.
• Mitigation: Enforce least privilege, utilize MFA, prefer temporary credentials (AWS best practice), and adhere to best practices for secrets handling.

1. Assuming Root in Organization Member Account (TTC ID: TTC2-202306001):

• How it works: An adversary gains access to credentials within a management account or a delegated administrator account that possess the permissions to assume the root user role in member accounts of an AWS Organization. If centralized root access is enabled (or can be enabled by the attacker), they perform the sts:AssumeRole action to assume root into a member account. This makes containment significantly more complex across multiple accounts and regions.
• Observed actions: sts:AssumeRole into member accounts, leading to broad, unrestricted actions.
• Mitigation: Disable root user credentials if using centralized root access (though re-enabling is possible with sufficient permissions), harden the management/delegated administrator account, and consider using a delegated administrator account for SCP application (SCPs don't apply to the organization management account).

1. Trusted Relationship Role Assumption (TTC ID: TTC2-202306002):

• How it works: A threat actor gains initial access to an AWS account. They then use the UpdateAssumeRolePolicy API call to modify an existing IAM role's trust policy, establishing trust with an unknown external AWS account. This allows the external account (controlled by the attacker) to assume the compromised role, creating a persistent backdoor.
• Observed actions: UpdateAssumeRolePolicy to add an external AWS:Principal to an IAM role's trust policy.
• Mitigation: Regularly review trust relationships using IAM Access Analyzer, restrict cross-account access to specific Organization IDs using SCPs, and apply general prevention techniques like MFA and least privilege.

1. API Gateway Persistence (TTC ID: TTC2-202306003):

• How it works: This is a more technical and niche technique. The threat actor sets up API Gateway and Lambda resources with a public endpoint, often without any authentication. The configured Lambda function is designed to create and return new admin credentials (e.g., access keys, new users) when the public endpoint is hit. This provides a persistent, on-demand credential generation mechanism for the attacker.
• Observed actions: CreateFunction, AttachUserPolicy, CreateAccessKey, CreateUser via the Lambda function.
• Mitigation: Enforce least privilege for Lambda functions, implement MFA, always use authentication for API Gateway endpoints (unless specifically designed for public access with strict controls), and adhere to best practices for secrets handling.

1. Support Case Closure (TTC ID: TTC2-202306004):

• How it works: When AWS detects potential unauthorized activity, it often opens a support case to notify the affected customer. A threat actor with sufficient permissions within the compromised account can then close this AWS-initiated support case, effectively silencing the notification and allowing their malicious activity to persist undetected for longer periods.
• Observed actions: ResolveCase or CloseCase actions on AWS Support cases.
• Mitigation: Implement redundancy for notifications (e.g., multiple email addresses, SNS for support case updates), ensure clear ownership and awareness of who can manage support cases, and follow best practices for secrets handling.

1. S3 Encryption with SSE-C (TTC ID: TTC2-202306005):

• How it works: This technique was historically used in ransomware attacks. A threat actor gains access to an account and then uses the S3 CopyObject API call to re-encrypt existing S3 objects using Server-Side Encryption with Customer-Provided Keys (SSE-C). The critical aspect is that the threat actor owns the customer-provided key, rendering the original data inaccessible to the legitimate customer without the attacker's key.
• Observed actions: CopyObject with x-amz-server-side-encryption-customer-key headers.
• Mitigation: Prefer short-term credentials, establish robust data recovery procedures with segmentation and multiple backup layers (including versioning and cross-region replication), implement continuous monitoring, and block the use of SSE-C (AWS now blocks this by default, but awareness of past risks is important).

1. LLM Resource Hijacking (TTC ID: TTC2-202306006):

• How it works: Threat actors gain access to an account and begin using Large Language Model (LLM) services, such as Amazon Bedrock, to invoke models. This is often observed in unused regions, a defense evasion tactic as customers typically monitor regions they actively use. The primary motivation appears to be obtaining free compute resources for LLM inferences.
• Observed actions: InvokeModel API calls, often in regions not typically used by the customer.
• Mitigation: Apply least privilege to LLM resources, limit access to Bedrock with specific principals and regions, and crucially, enable model invocation logging to capture the content sent to the models (without this, only the InvokeModel success is visible, not the actual prompts).

These detailed examples provide concrete illustrations of the value the TTC brings to understanding and combating real-world cloud threats.

Defensive Implications

▶ Watch: Important disclaimer on AWS security and misconfigurations (6:50)

The insights gleaned from the Threat Technique Catalog for AWS (TTC) and the observed TTPs provide critical defensive implications for organizations operating within AWS. The overarching message is a return to fundamental security principles, coupled with leveraging AWS-native security tools and proactive monitoring.

1. Prioritize Security Fundamentals: The talk repeatedly emphasizes "security basics" or "security vegetables":

• Least Privilege: Granting only the minimum necessary permissions to users and roles is paramount. This limits the blast radius of compromised credentials, making incidents less painful and easier to contain. Incident responders consistently find that incidents with fewer permissions are significantly less impactful.
• Multi-Factor Authentication (MFA): The statistic that two-thirds of unauthorized events stem from compromised long-term credentials, often without MFA, highlights its non-negotiable importance. Enforcing MFA for all users, especially root users and administrative roles, is a primary defense.
• Temporary Credentials: Where possible, favor temporary credentials over long-term static access keys. This significantly reduces the window of opportunity for attackers to exploit compromised credentials.
• Secrets Handling Best Practices: Securely manage and rotate all credentials and API keys. Avoid embedding them directly in code or public repositories.

1. Leverage AWS Security Services:

• IAM Access Analyzer: This tool is crucial for identifying unintended external access to your resources, including roles with suspicious trust relationships. It should be a first line of defense in investigating role assumption incidents.
• Service Control Policies (SCPs): For organizations using AWS Organizations, SCPs are powerful for enforcing guardrails across all accounts. They can restrict cross-account access to only trusted Organization IDs, prevent the use of specific services or API calls (like SSE-C), or enforce regional restrictions.
• GuardDuty: Ensure GuardDuty is enabled and configured, as its detections are continually updated with insights from AWS's incident response teams, including those from the TTC.

1. Proactive Monitoring and Alerting:

• CloudTrail Logging: Enable CloudTrail in all regions and aggregate logs to a central, secure logging account. Monitor for specific API calls outlined in the TTC, especially mutating calls (e.g., UpdateAssumeRolePolicy, CreateFunction, CopyObject).
• Redundant Notification Channels: For critical alerts, especially those from AWS Support, configure multiple notification channels (e.g., SNS topics pushing to multiple emails, Slack, PagerDuty). Do not rely on a single point of contact. This prevents threat actors from delaying detection by closing support cases.
• Region Monitoring: Do not overlook unused AWS regions. Threat actors frequently exploit these areas for defense evasion, assuming customers only monitor regions where they actively deploy resources. Centralized CloudTrail logging and multi-region monitoring are essential.
• Model Invocation Logging (for LLMs): For organizations using LLM services like Amazon Bedrock, enabling model invocation logging is critical. Without it, defenders cannot see the actual prompts or content sent to the models, hindering investigations into potential LLM resource hijacking.

1. Robust Data Recovery and Incident Response Plans:

• Data Recovery Procedures: Develop and regularly test comprehensive data recovery procedures, including multiple layers of backups, versioning for S3 buckets, and cross-region replication. This is paramount for mitigating the impact of data encryption or deletion attacks.
• Data Perimeters: Implement network data perimeters to restrict credential usage to specific IP spaces. As highlighted by Steve de Vera, this can prevent compromised long-term credentials from being used outside of your controlled environment, offering a significant mitigation against a prevalent attack vector.

By internalizing the lessons from the TTC and implementing these defensive strategies, organizations can significantly enhance their resilience against sophisticated and evolving cloud-specific threats.

Key Takeaways

• The Threat Technique Catalog for AWS (TTC) is a crucial, real-world extension of MITRE ATT&CK, providing AWS-specific TTPs based on observed incidents to aid in detection and mitigation.
• Compromised long-term credentials (e.g., static access keys) are a primary initial access vector, accounting for two-thirds of unauthorized events, underscoring the critical need for MFA and temporary credentials.
• Adversaries frequently exploit misconfigurations and leverage defense evasion tactics such as operating in unused AWS regions or closing AWS-initiated support cases to prolong their access.
• Implementing least privilege, robust identity and access management, and comprehensive monitoring across all regions are fundamental to preventing and detecting cloud-specific attacks.
• AWS-native security tools like IAM Access Analyzer, Service Control Policies (SCPs), and CloudTrail are indispensable for identifying and mitigating risks, with capabilities like model invocation logging becoming vital for emerging threats like LLM hijacking.
• Proactive data recovery procedures and the establishment of data perimeters are essential guardrails to limit the impact of compromise and prevent unauthorized credential use outside controlled environments.

About the Speaker(s)

Cydney Stude is a Senior Security Engineer for the AWS Customer Incident Response Team. In her role, she directly engages with customers who have experienced security incidents within their AWS environments, focusing on issues stemming from the customer side of the shared responsibility model, such as misconfigurations and exposed credentials. Her expertise lies in analyzing threat actor actions post-access and developing strategies for containment and mitigation.

Steve de Vera is a Manager for the AWS Security Incident Response Service. He leads teams responsible for responding to security events and plays a key role in developing frameworks and resources like the Threat Technique Catalog for AWS. His work involves understanding broader threat trends and translating incident data into actionable insights and improvements for AWS services and customer security posture.