{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/iam/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Cortex XDR","Cortex XSIAM","Unit 42 Frontier AI Defense","Prisma Cloud","Cortex XSOAR","Cortex Xpanse","Prisma SASE","Prisma Access","Prisma SD-WAN"],"_cs_severities":["high"],"_cs_tags":["cloud-security","iam","incident-response","threat-detection"],"_cs_type":"advisory","_cs_vendors":["Palo Alto Networks"],"content_html":"\u003cp\u003eThe 2026 Unit 42 Global Incident Response Report highlights that threat actors are moving 4x faster to exfiltration than in 2025, exploiting blind spots due to an over-reliance on endpoint data. The proliferation of cloud services, microservices, and remote users has expanded the attack surface beyond what any single tool can monitor. Unit 42 found that in 75% of incidents, critical evidence was present in logs but wasn\u0026rsquo;t accessible or operationalized, allowing attackers to exploit the gaps. Organizations need to evolve their SOCs to ingest and correlate telemetry across their entire IT landscape, including IAM, cloud assets, OT/IoT, and AI workloads. Unit 42 recommends a single-pane-of-glass strategy powered by an AI-driven SOC platform like Cortex XSIAM to combat these threats.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access via Cloud Misconfiguration:\u003c/strong\u003e The attacker gains initial access through a misconfigured cloud service access key.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCloud Console Manipulation:\u003c/strong\u003e The attacker manipulates the cloud console to hide their tracks from endpoint detection.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePivot to Cloud-Hosted Server:\u003c/strong\u003e From the cloud console, the attacker pivots to a cloud-hosted server to begin discovery.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCredential Theft (Covert C2):\u003c/strong\u003e The attacker utilizes DNS tunneling to a cloud storage location for C2 communication and steals credentials to use legitimate applications.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e The attacker moves laterally using the stolen credentials, triggering impossible travel alerts across SaaS apps.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRogue Asset Introduction:\u003c/strong\u003e The attacker introduces a rogue device into the network, bypassing traditional endpoint security measures.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker maintains persistence through the rogue device, using it for covert movement and access.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration:\u003c/strong\u003e The attacker exfiltrates sensitive data, taking advantage of the gaps in security visibility.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eOrganizations are increasingly vulnerable to rapid data exfiltration due to the expanded attack surface and reliance on endpoint-centric security. The inability to correlate telemetry across diverse IT zones allows attackers to operate undetected, leading to significant data breaches, financial losses, and reputational damage. Unit 42\u0026rsquo;s research shows that attackers are moving 4x faster to exfiltration, exacerbating the impact of successful intrusions. The attacks target cloud environments, identity systems, and networks, creating a complex threat landscape for security teams to navigate.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eIngest and correlate telemetry from all IT zones (IAM, cloud, OT/IoT, AI workloads) into a single repository, as described in the overview, to eliminate data silos and gain holistic visibility.\u003c/li\u003e\n\u003cli\u003eImplement User and Entity Behavior Analytics (UEBA) as mentioned in the overview, to detect anomalous behavior indicative of compromised credentials by using a centralized workbench.\u003c/li\u003e\n\u003cli\u003eDeploy Cortex XSIAM, as discussed in the overview, to leverage AI-driven alert stitching, ML-based incident scoring, and UEBA for automated detection, investigation, and response.\u003c/li\u003e\n\u003cli\u003eImplement continuous network monitoring and external attack surface management to detect and manage rogue assets, as highlighted in the attack chain.\u003c/li\u003e\n\u003cli\u003eEvaluate your current visibility through a formal assessment as recommended in the conclusion, to identify gaps in security coverage.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-01T23:13:22Z","date_published":"2026-05-01T23:13:22Z","id":"/briefs/2026-06-detection-beyond-endpoint/","summary":"Threat actors are rapidly exfiltrating data by exploiting blind spots created by an over-reliance on endpoint data, necessitating a comprehensive security approach that incorporates cloud, identity, and network telemetry for effective threat detection and response.","title":"Expanding Detection Beyond Endpoints to Counter Evolving Threats","url":"https://feed.craftedsignal.io/briefs/2026-06-detection-beyond-endpoint/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS IAM","AWS Lambda"],"_cs_severities":["high"],"_cs_tags":["aws","iam","lambda","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis threat focuses on the abuse of AWS Lambda execution roles to perform sensitive IAM operations. Lambda functions, often running with over-permissioned roles, can be exploited by adversaries to escalate privileges and establish persistence within an AWS environment. An attacker gaining control of a Lambda function can leverage its execution role to make IAM API calls that would normally require elevated permissions. This includes creating new IAM users or roles, attaching policies to existing IAM entities, and modifying EC2 instance profiles. The scope of this threat includes any AWS environment utilizing Lambda functions with IAM permissions.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains unauthorized access to a Lambda function, either through code injection, vulnerable dependencies, or misconfiguration.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the Lambda function\u0026rsquo;s execution role, which has excessive IAM permissions.\u003c/li\u003e\n\u003cli\u003eThe attacker executes IAM API calls, such as \u003ccode\u003eCreateUser\u003c/code\u003e, \u003ccode\u003eCreateRole\u003c/code\u003e, or \u003ccode\u003eCreateAccessKey\u003c/code\u003e, to create new IAM identities.\u003c/li\u003e\n\u003cli\u003eThe attacker uses \u003ccode\u003eAttachUserPolicy\u003c/code\u003e, \u003ccode\u003ePutUserPolicy\u003c/code\u003e, \u003ccode\u003eAttachRolePolicy\u003c/code\u003e, or \u003ccode\u003ePutRolePolicy\u003c/code\u003e to grant elevated permissions to the newly created or existing IAM identities.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies instance profiles using \u003ccode\u003eCreateInstanceProfile\u003c/code\u003e and \u003ccode\u003eAddRoleToInstanceProfile\u003c/code\u003e to prepare EC2 instances for lateral movement.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly created or modified IAM identities to assume roles and access resources they were not previously authorized to access via \u003ccode\u003ests:AssumeRole\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker achieves privilege escalation, gaining control over sensitive AWS resources and services.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by creating rogue IAM users, roles, or access keys.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to full compromise of the AWS environment. An attacker could create highly privileged IAM users and roles, granting them the ability to access and control all AWS resources. This can result in data breaches, service disruptions, and financial losses. The impact is magnified in environments where Lambda functions are heavily relied upon for critical business operations.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS IAM Sensitive Operations via Lambda Execution Role\u0026rdquo; to your SIEM and tune for your environment to detect the described IAM API calls originating from Lambda execution roles.\u003c/li\u003e\n\u003cli\u003eReview and restrict the permissions granted to Lambda execution roles, following the principle of least privilege, to minimize the potential impact of a compromised function.\u003c/li\u003e\n\u003cli\u003eMonitor \u003ccode\u003eaws.cloudtrail.user_identity.arn\u003c/code\u003e to identify the Lambda function and associated deployment path responsible for the IAM API calls.\u003c/li\u003e\n\u003cli\u003eInvestigate \u003ccode\u003eaws.cloudtrail.request_parameters\u003c/code\u003e for targets such as \u003ccode\u003euserName\u003c/code\u003e, \u003ccode\u003egroupName\u003c/code\u003e, \u003ccode\u003eroleName\u003c/code\u003e, \u003ccode\u003epolicyArn\u003c/code\u003e, or \u003ccode\u003einstanceProfileName\u003c/code\u003e to understand the scope of the IAM operations.\u003c/li\u003e\n\u003cli\u003eRevoke or rotate the credentials of any compromised Lambda execution roles to prevent further unauthorized access.\u003c/li\u003e\n\u003cli\u003eRemediate any rogue IAM users, roles, or access keys created by the attacker to eliminate persistence mechanisms.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-01T20:57:28Z","date_published":"2026-05-01T20:57:28Z","id":"/briefs/2024-01-09-aws-lambda-iam-privilege-escalation/","summary":"Detection of IAM API calls that create or empower IAM users and roles, attach policies, or configure instance profiles when the caller is an assumed role session associated with AWS Lambda, potentially indicating privilege escalation or persistence.","title":"AWS IAM Privilege Operations via Lambda Execution Role","url":"https://feed.craftedsignal.io/briefs/2024-01-09-aws-lambda-iam-privilege-escalation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["cloud","aws","iam","persistence"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis rule detects the creation of a console login profile for the AWS account root user, a highly privileged account. While \u003ccode\u003eCreateLoginProfile\u003c/code\u003e is normally applied to IAM users, when executed from a temporary root session (e.g., via \u003ccode\u003eAssumeRoot\u003c/code\u003e) without specifying a \u003ccode\u003euserName\u003c/code\u003e, the profile is created for the root principal. This activity is especially concerning because it provides persistent access. An attacker gaining temporary root access via STS or credential compromise might exploit this to set a root password. The attacker can then use this new password to log in through the console. This method circumvents traditional access key rotation or disabling and can be employed even after the initial vulnerability is patched. This activity started being tracked on 2024-12-02, defenders need to be aware of this persistence mechanism and promptly investigate any such incidents.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an AWS account with sufficient privileges, possibly through compromised credentials or an STS session.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003eAssumeRoot\u003c/code\u003e API call to assume the privileges of the root user.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eCreateLoginProfile\u003c/code\u003e API call without specifying a \u003ccode\u003euserName\u003c/code\u003e. This action creates a console login profile directly for the root account instead of an IAM user. The \u003ccode\u003eaws.cloudtrail.request_parameters\u003c/code\u003e will not contain \u003ccode\u003euserName=\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker sets a password for the root account using the \u003ccode\u003eCreateLoginProfile\u003c/code\u003e API. \u003ccode\u003epasswordResetRequired\u003c/code\u003e might be set to \u003ccode\u003etrue\u003c/code\u003e or omitted, with omission potentially indicating an attacker-controlled password.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly created root account password to log in to the AWS Management Console. The event will be logged as a \u003ccode\u003eConsoleLogin\u003c/code\u003e event.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the root account\u0026rsquo;s privileges to create or modify resources, escalate privileges, or exfiltrate data.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence by using the console login, even if the initially compromised credentials or temporary session tokens are revoked.\u003c/li\u003e\n\u003cli\u003eThe attacker may also create new IAM users or roles with elevated permissions to further solidify their presence.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack can lead to complete control over the AWS environment. The attacker can create, modify, or delete resources; access sensitive data; and disrupt services. Because the root user has unrestricted privileges, the impact is extremely high. There have been no reported victim counts. However, any successful exploitation can have severe impacts including data breaches, financial loss, and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS IAM Login Profile Added for Root\u0026rdquo; to detect unauthorized creation of login profiles for the root account and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any \u003ccode\u003eCreateLoginProfile\u003c/code\u003e events where \u003ccode\u003eaws.cloudtrail.user_identity.type\u003c/code\u003e is \u003ccode\u003eRoot\u003c/code\u003e and \u003ccode\u003eaws.cloudtrail.request_parameters\u003c/code\u003e does not contain \u003ccode\u003euserName=\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eEnable CloudTrail, GuardDuty, AWS Config, and Security Hub across all regions for continuous monitoring of root and IAM activity to improve overall visibility.\u003c/li\u003e\n\u003cli\u003eReview IAM policies for least-privilege adherence, focusing on \u003ccode\u003eiam:CreateLoginProfile\u003c/code\u003e, \u003ccode\u003eiam:UpdateLoginProfile\u003c/code\u003e, and \u003ccode\u003eiam:CreateAccessKey\u003c/code\u003e permissions.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-10T16:27:52Z","date_published":"2026-04-10T16:27:52Z","id":"/briefs/2024-12-aws-root-login-profile/","summary":"An adversary with temporary root access in AWS may create a login profile for the root account to establish persistent console access, even if the original access keys are rotated or disabled.","title":"AWS IAM Login Profile Added for Root","url":"https://feed.craftedsignal.io/briefs/2024-12-aws-root-login-profile/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["cloud","aws","iam","credential-access","initial-access"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection rule, published by Elastic, is designed to correlate AWS security alerts and prioritize investigations related to potentially compromised IAM access keys. Specifically, it focuses on scenarios where a long-term IAM access key is observed originating from a new source IP address (detected by the \u0026ldquo;AWS Long-Term Access Key First Seen from Source IP\u0026rdquo; rule, rule ID 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f) and is also associated with other open alerts of medium, high, or critical severity. This correlation aims to surface instances where a newly exposed or compromised access key is actively being used for malicious activities, enabling security teams to respond more effectively to potential credential access incidents and initial access attempts. The rule is a higher-order rule that analyzes existing security alerts within an Elastic Security deployment and leverages the \u003ccode\u003ekibana.alert\u003c/code\u003e fields to identify related events.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains access to a valid AWS IAM Long-Term Access Key. This could be through phishing, credential stuffing, or exposed credentials in source code.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the compromised access key to interact with AWS services from a new and previously unseen IP address. This triggers the \u0026ldquo;AWS Long-Term Access Key First Seen from Source IP\u0026rdquo; rule (rule ID: 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f).\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised credentials to perform reconnaissance activities within the AWS environment, such as listing resources or querying IAM configurations.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to escalate privileges by exploiting misconfigurations or vulnerabilities in IAM policies.\u003c/li\u003e\n\u003cli\u003eThe attacker performs actions indicating lateral movement within the AWS environment, such as accessing or modifying resources in different AWS accounts.\u003c/li\u003e\n\u003cli\u003eThe attacker compromises additional AWS resources or services, such as EC2 instances or S3 buckets. These activities trigger medium, high, or critical severity alerts.\u003c/li\u003e\n\u003cli\u003eThe correlation rule identifies the co-occurrence of the \u0026ldquo;AWS Long-Term Access Key First Seen from Source IP\u0026rdquo; alert and other elevated severity alerts associated with the same access key ID.\u003c/li\u003e\n\u003cli\u003eThe security team investigates the correlated alerts and takes appropriate remediation steps, such as rotating the compromised access key and reviewing IAM policies.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack leveraging compromised AWS IAM credentials can lead to significant data breaches, service disruption, and financial losses. Attackers can gain unauthorized access to sensitive data stored in S3 buckets, compromise EC2 instances, and disrupt critical AWS services. The correlation rule aims to reduce the dwell time of attackers by prioritizing the investigation of compromised credentials associated with ongoing malicious activity. This can prevent attackers from further escalating their attacks and minimizing the overall impact of the breach. Failure to detect and respond to these attacks can result in regulatory fines, reputational damage, and loss of customer trust.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the \u0026ldquo;AWS IAM Long-Term Access Key Correlated with Elevated Detection Alerts\u0026rdquo; rule (rule ID 98cfaa44-83f0-4aba-90c4-363fb9d51a75) in your Elastic Security environment to identify potentially compromised IAM access keys.\u003c/li\u003e\n\u003cli\u003eInvestigate alerts triggered by the rule by pivoting on the \u003ccode\u003eaws.cloudtrail.user_identity.access_key_id\u003c/code\u003e in CloudTrail and IAM to understand the context of the access key usage.\u003c/li\u003e\n\u003cli\u003eReview the sibling alerts identified by the rule using \u003ccode\u003eEsql.kibana_alert_rule_name_values\u003c/code\u003e and \u003ccode\u003eEsql.kibana_alert_rule_id_values\u003c/code\u003e to understand the scope and impact of the potential compromise.\u003c/li\u003e\n\u003cli\u003eConfigure your Elastic Security deployment to properly map risk scores to severity levels, ensuring that \u003ccode\u003ekibana.alert.risk_score \u0026gt;= 47\u003c/code\u003e corresponds to medium or higher severity alerts.\u003c/li\u003e\n\u003cli\u003eRotate or disable any IAM access keys identified as compromised by the rule to prevent further unauthorized access.\u003c/li\u003e\n\u003cli\u003eEnable AWS CloudTrail logging to capture detailed information about API calls made within your AWS environment, providing valuable context for investigating security alerts.\u003c/li\u003e\n\u003cli\u003eImplement the \u0026ldquo;AWS Long-Term Access Key First Seen from Source IP\u0026rdquo; rule (rule_id: 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f) if not already enabled, as it is a pre-requisite for this correlation rule.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-06T14:37:37Z","date_published":"2026-04-06T14:37:37Z","id":"/briefs/2026-06-aws-iam-access-key-correlation/","summary":"This rule correlates AWS Long-Term Access Key First Seen from Source IP alerts with other open alerts of medium or higher severity that share the same IAM access key ID to prioritize investigation of potentially compromised accounts, helping identify post-compromise activity.","title":"AWS IAM Long-Term Access Key Correlated with Elevated Detection Alerts","url":"https://feed.craftedsignal.io/briefs/2026-06-aws-iam-access-key-correlation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["aws","cloudtrail","saml","iam","deletion","impact"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThe deletion of a SAML provider in AWS can be a significant indicator of malicious activity. An attacker who has gained initial access to an AWS environment may attempt to remove the SAML provider used by the information security team or system administrators. This action can severely impede the team\u0026rsquo;s ability to investigate and respond to ongoing attacks. By disrupting access, the attacker gains a window of opportunity to further escalate privileges, move laterally within the environment, and achieve their objectives without immediate detection or intervention. This activity directly impacts the availability and integrity of resources within the AWS cloud environment.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial access is gained to an AWS account through compromised credentials or other means (T1078.004).\u003c/li\u003e\n\u003cli\u003eThe attacker enumerates existing IAM resources, including SAML providers, using AWS CLI or API calls.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies the SAML provider used by administrative or security teams.\u003c/li\u003e\n\u003cli\u003eThe attacker executes the \u003ccode\u003eDeleteSAMLProvider\u003c/code\u003e API call via the AWS CLI, API, or AWS Management Console (T1531).\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eDeleteSAMLProvider\u003c/code\u003e event is logged in AWS CloudTrail with a \u0026ldquo;success\u0026rdquo; status.\u003c/li\u003e\n\u003cli\u003eAdministrative and security teams lose access to AWS resources that require SAML authentication.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the compromised account to escalate privileges, create new IAM users, or modify existing policies.\u003c/li\u003e\n\u003cli\u003eThe attacker persists in the environment, potentially exfiltrating data or deploying malicious workloads (T1485).\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe deletion of an AWS SAML provider can have serious consequences. It disrupts access for administrators and security personnel, delaying incident response and potentially allowing attackers to further compromise the environment. This can lead to data breaches, service disruptions, and financial losses. The severity of the impact depends on the criticality of the affected AWS resources and the speed of detection and recovery.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS SAML Provider Deletion Activity\u0026rdquo; to your SIEM and tune for your environment to detect this specific event.\u003c/li\u003e\n\u003cli\u003eInvestigate any \u003ccode\u003eDeleteSAMLProvider\u003c/code\u003e events in AWS CloudTrail, focusing on the user identity, user agent, and source IP address (logsource: aws/cloudtrail).\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all IAM users, especially those with administrative privileges, to reduce the risk of credential compromise (T1110).\u003c/li\u003e\n\u003cli\u003eReview and enforce the principle of least privilege for all IAM roles and users to limit the impact of compromised credentials.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-12-19T00:00:00Z","date_published":"2024-12-19T00:00:00Z","id":"/briefs/2024-12-19-aws-saml-provider-deletion/","summary":"An adversary may delete an AWS SAML provider to disrupt administrative access, hindering incident response and potentially escalating privileges within the AWS environment.","title":"AWS SAML Provider Deletion Activity","url":"https://feed.craftedsignal.io/briefs/2024-12-19-aws-saml-provider-deletion/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS IAM","AWS S3"],"_cs_severities":["high"],"_cs_tags":["aws","iam","s3browser","s3","policy","cloudtrail"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe S3Browser utility is being used to create Inline IAM policies within AWS. This activity is flagged as suspicious when the policy includes the default S3 bucket name placeholder value of \u003ccode\u003e\u0026lt;YOUR-BUCKET-NAME\u0026gt;\u003c/code\u003e. This could indicate that the user has not properly configured the policy or is unaware of the implications of using a generic placeholder, potentially granting unintended access to S3 resources. This behavior was observed being used by the threat actor Guivil. The use of S3Browser in this manner poses a risk of privilege escalation, persistence, and unauthorized access to sensitive data stored in S3 buckets.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an AWS account, possibly through compromised credentials or misconfigured IAM roles (T1078.004).\u003c/li\u003e\n\u003cli\u003eThe attacker utilizes the S3Browser utility to interact with AWS S3 buckets.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to create an Inline IAM policy using S3Browser.\u003c/li\u003e\n\u003cli\u003eThe attacker fails to replace the default bucket name placeholder \u003ccode\u003e\u0026lt;YOUR-BUCKET-NAME\u0026gt;\u003c/code\u003e with a specific bucket ARN.\u003c/li\u003e\n\u003cli\u003eThe attacker saves the IAM policy with the default bucket name placeholder, leading to a broad or unintended scope of permissions.\u003c/li\u003e\n\u003cli\u003eThe poorly configured policy is applied to a user, role, or group.\u003c/li\u003e\n\u003cli\u003eThe attacker potentially escalates privileges or gains unauthorized access to S3 resources.\u003c/li\u003e\n\u003cli\u003eThe attacker persists in the environment with the newly created or modified IAM policy.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eCreation of an IAM policy with the default bucket name placeholder leaves S3 buckets open to potential unauthorized access. A successful attack could lead to data exfiltration, data modification, or denial of service. The scope of the impact depends on the specific permissions granted within the policy and the resources accessible through the affected IAM user, role, or group.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS IAM S3Browser Templated S3 Bucket Policy Creation\u0026rdquo; to your SIEM and tune for your environment to detect this specific activity.\u003c/li\u003e\n\u003cli\u003eInvestigate any instances where \u003ccode\u003ePutUserPolicy\u003c/code\u003e events are associated with the S3Browser user agent (logsource: aws/cloudtrail).\u003c/li\u003e\n\u003cli\u003eReview existing IAM policies for the presence of the default bucket name placeholder \u003ccode\u003earn:aws:s3:::\u0026lt;YOUR-BUCKET-NAME\u0026gt;/*\u003c/code\u003e (logsource: aws/cloudtrail).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-26T12:00:00Z","date_published":"2024-01-26T12:00:00Z","id":"/briefs/2024-01-26-s3browser-iam-policy/","summary":"An AWS IAM policy is created by the S3Browser utility with the default S3 bucket name placeholder, potentially indicating unauthorized access or misconfiguration.","title":"S3Browser IAM Policy Creation with Default Bucket Name","url":"https://feed.craftedsignal.io/briefs/2024-01-26-s3browser-iam-policy/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS IAM"],"_cs_severities":["high"],"_cs_tags":["cloud","aws","iam","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe S3 Browser utility, a Windows-based client for managing Amazon S3 storage and other cloud services, can be abused by threat actors to create new IAM users or access keys within compromised AWS environments. This activity, if unauthorized, can lead to privilege escalation, persistence, or even initial access, depending on the context of the compromise. The use of S3 Browser is identifiable via the userAgent string in AWS CloudTrail logs. While legitimate use of S3 Browser for administrative tasks exists, its unexpected appearance in user activity, particularly in sensitive accounts, should be investigated. This activity is particularly concerning because it can allow attackers to establish a foothold in the cloud environment and move laterally.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to an AWS environment, potentially through compromised credentials or an exploited vulnerability.\u003c/li\u003e\n\u003cli\u003eThe attacker installs and configures S3 Browser on a compromised host or uses an existing installation.\u003c/li\u003e\n\u003cli\u003eThe attacker authenticates S3 Browser to the AWS environment using existing compromised credentials or an assumed role.\u003c/li\u003e\n\u003cli\u003eThe attacker uses S3 Browser to execute the \u003ccode\u003eCreateUser\u003c/code\u003e API call within AWS IAM.\u003c/li\u003e\n\u003cli\u003eThe attacker configures the new IAM user with elevated privileges, potentially granting administrator access.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker uses S3 Browser to execute the \u003ccode\u003eCreateAccessKey\u003c/code\u003e API call for an existing IAM user.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly created access key to perform actions within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the new user or access key for persistence, lateral movement, and data exfiltration within the AWS environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation and IAM creation can lead to complete compromise of the AWS environment. An attacker with escalated privileges can access sensitive data, modify configurations, disrupt services, and deploy malicious infrastructure. Depending on the permissions granted to the created user or access key, the attacker could potentially pivot to other AWS accounts or services, leading to widespread damage. This can result in significant financial losses, reputational damage, and regulatory penalties.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS IAM S3Browser User or AccessKey Creation\u0026rdquo; to your SIEM and tune for your environment to detect anomalous IAM activity originating from S3 Browser.\u003c/li\u003e\n\u003cli\u003eInvestigate any instances of \u003ccode\u003eCreateUser\u003c/code\u003e or \u003ccode\u003eCreateAccessKey\u003c/code\u003e events in AWS CloudTrail logs where the \u003ccode\u003euserAgent\u003c/code\u003e contains \u0026ldquo;S3 Browser\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all IAM users to mitigate the risk of credential compromise.\u003c/li\u003e\n\u003cli\u003eReview and enforce the principle of least privilege for all IAM users and roles to limit the impact of compromised credentials.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T14:30:00Z","date_published":"2024-01-03T14:30:00Z","id":"/briefs/2024-01-03-s3browser-iam/","summary":"The use of S3 Browser to create IAM users or access keys in AWS environments indicates a potential privilege escalation, persistence, or initial access attempt by threat actors leveraging a known cloud administration tool.","title":"AWS IAM User or Access Key Creation via S3 Browser","url":"https://feed.craftedsignal.io/briefs/2024-01-03-s3browser-iam/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Amazon Web Services"],"_cs_severities":["medium"],"_cs_tags":["privilege-escalation","aws","iam"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis detection identifies potentially malicious activity related to AWS Identity and Access Management (IAM) policies. Specifically, it focuses on the creation of new versions of customer-managed policies (\u003ccode\u003eCreatePolicyVersion\u003c/code\u003e) and the modification of the default version (\u003ccode\u003eSetDefaultPolicyVersion\u003c/code\u003e). Attackers who have compromised IAM users or roles with sufficient permissions (iam:CreatePolicyVersion or iam:SetDefaultPolicyVersion) can use these actions to escalate their privileges within the AWS environment. By introducing a more permissive policy version and setting it as the default, attackers can gain unauthorized access to resources and perform actions that would otherwise be restricted. This activity is especially concerning when the modified policies are attached to highly privileged roles or users, such as those used for administrative tasks or break-glass scenarios.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker compromises an IAM user or role with permissions to modify IAM policies (\u003ccode\u003eiam:CreatePolicyVersion\u003c/code\u003e or \u003ccode\u003eiam:SetDefaultPolicyVersion\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a customer-managed policy attached to a high-privilege role or user.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a new policy version with overly permissive rules, such as wildcard actions and resources.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the \u003ccode\u003eCreatePolicyVersion\u003c/code\u003e API call to upload the malicious policy version to the target policy.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker uses the \u003ccode\u003eSetDefaultPolicyVersion\u003c/code\u003e API call to set a pre-existing, but less restrictive, policy version as the default.\u003c/li\u003e\n\u003cli\u003eThe compromised IAM user or role assumes the high-privilege role targeted in step 2.\u003c/li\u003e\n\u003cli\u003eThe attacker gains elevated privileges based on the modified IAM policy.\u003c/li\u003e\n\u003cli\u003eThe attacker performs unauthorized actions within the AWS environment, such as accessing sensitive data, modifying infrastructure, or creating new resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation can lead to significant privilege escalation, allowing attackers to gain control over critical AWS resources and data. The number of affected users and roles depends on the scope of the compromised policy and its attachments. The consequences can include data breaches, service disruptions, and financial losses. In environments where IAM policies are not closely monitored, attackers may be able to maintain their elevated access for extended periods, further compounding the damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;AWS IAM Customer Managed Policy Version Created or Default Version Set\u0026rdquo; to your SIEM to detect suspicious policy modifications. Tune the rule based on your organization\u0026rsquo;s baseline activity.\u003c/li\u003e\n\u003cli\u003eReview \u003ccode\u003eaws.cloudtrail.request_parameters\u003c/code\u003e logs to identify the \u003ccode\u003epolicyArn\u003c/code\u003e and \u003ccode\u003epolicyDocument\u003c/code\u003e associated with the policy changes detected by the rule.\u003c/li\u003e\n\u003cli\u003eImplement strong IAM governance practices, including the principle of least privilege and regular reviews of policy permissions, to minimize the impact of policy manipulation.\u003c/li\u003e\n\u003cli\u003eMonitor CloudTrail logs for \u003ccode\u003eAttachUserPolicy\u003c/code\u003e, \u003ccode\u003eAttachRolePolicy\u003c/code\u003e, or \u003ccode\u003eCreatePolicyVersion\u003c/code\u003e spikes from the same principal as detected policy modifications.\u003c/li\u003e\n\u003cli\u003eEnable MFA for all IAM users, especially those with permissions to manage IAM policies.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-aws-iam-policy-manipulation/","summary":"Successful creation of new or setting default versions of customer-managed IAM policies can indicate privilege escalation attempts by attackers modifying policy permissions.","title":"AWS IAM Customer Managed Policy Version Manipulation for Privilege Escalation","url":"https://feed.craftedsignal.io/briefs/2024-01-aws-iam-policy-manipulation/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["EKS","STS"],"_cs_severities":["high"],"_cs_tags":["aws","cloudtrail","iam","kubernetes","initial-access","web-identity"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThis detection rule identifies instances of successful AWS \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e calls originating from a Kubernetes service account but not from an Amazon-managed Autonomous System Number (ASN). The primary concern is the potential compromise or misuse of projected service account tokens. Kubernetes service accounts can be mapped to IAM roles through OIDC using IRSA (IAM Roles for Service Accounts). Typically, these credential requests originate from within AWS-managed or associated networks. However, if a request with a Kubernetes service account identity originates from an external ASN (i.e., not \u003ccode\u003eAmazon.com, Inc.\u003c/code\u003e), it raises suspicion that the token might have been exfiltrated and is being used from an unauthorized location. This rule is designed to highlight such anomalies, prompting further investigation into possible token theft or misconfiguration.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains unauthorized access to a Kubernetes service account token within a compromised pod or through other means.\u003c/li\u003e\n\u003cli\u003eAttacker exfiltrates the service account token from the Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the exfiltrated token to call the AWS STS \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e API.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e call is made from a network with an ASN organization name that is not \u003ccode\u003eAmazon.com, Inc.\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eAWS CloudTrail logs the successful \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e event, including details about the user, source IP, and ASN organization.\u003c/li\u003e\n\u003cli\u003eThe compromised IAM role is used to perform unauthorized actions within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThese actions could include data exfiltration, resource modification, or further lateral movement within the cloud infrastructure.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful attack of this nature can lead to significant security breaches within an AWS environment. An attacker leveraging stolen service account tokens can gain unauthorized access to sensitive resources, leading to data breaches, service disruption, or financial loss. This is especially concerning for organizations heavily reliant on Kubernetes and AWS, as it can undermine the security of their cloud-native applications and infrastructure. While the number of affected organizations is unknown, the potential impact on those targeted can be severe, leading to substantial remediation costs and reputational damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eAWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN\u003c/code\u003e to your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule by following the investigation steps in the rule\u0026rsquo;s \u003ccode\u003enote\u003c/code\u003e field.\u003c/li\u003e\n\u003cli\u003eExpand the \u003ccode\u003esource.as.organization.name\u003c/code\u003e exclusions in the Sigma rule for known and trusted egress paths if needed.\u003c/li\u003e\n\u003cli\u003eEnable geolocation/ASN enrichment for your AWS CloudTrail logs to accurately identify the source of \u003ccode\u003eAssumeRoleWithWebIdentity\u003c/code\u003e calls.\u003c/li\u003e\n\u003cli\u003eRegularly review and rotate IRSA trust relationships to minimize the impact of compromised service account tokens.\u003c/li\u003e\n\u003cli\u003eRevoke the role session, rotate IRSA trust where appropriate, investigate token exposure, and reduce service account and role permissions if unauthorized access is suspected.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-03-aws-assume-role-external-asn/","summary":"Detects successful AWS `AssumeRoleWithWebIdentity` calls where the caller identity is a Kubernetes service account and the source autonomous system organization is not `Amazon.com, Inc.`, which may indicate a stolen or misused projected service-account token being exchanged for IAM credentials off-cluster.","title":"AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN","url":"https://feed.craftedsignal.io/briefs/2024-01-03-aws-assume-role-external-asn/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["AWS IAM"],"_cs_severities":["high"],"_cs_tags":["aws","cloud","iam","s3browser","privilege-escalation","persistence"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eThe threat involves the use of the S3 Browser utility, a Windows application, to interact with Amazon Web Services (AWS) Identity and Access Management (IAM). Attackers are leveraging S3 Browser to perform reconnaissance, specifically targeting IAM users that do not have a login profile configured. Upon identifying such users, the attacker proceeds to create a login profile for them. This tactic may be indicative of an attempt to gain unauthorized access or maintain persistence within the AWS environment. The activity is detectable via AWS CloudTrail logs and was first publicly reported in May 2023 in connection with the threat actor GUIVIL.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains initial access to a system with AWS CLI tools installed or uses a compromised IAM user with sufficient permissions.\u003c/li\u003e\n\u003cli\u003eThe attacker configures S3 Browser with valid AWS credentials, enabling interaction with the AWS environment.\u003c/li\u003e\n\u003cli\u003eS3 Browser initiates a \u003ccode\u003eGetLoginProfile\u003c/code\u003e API call in AWS CloudTrail, to enumerate IAM users and identify those without existing login profiles.\u003c/li\u003e\n\u003cli\u003eS3 Browser, upon finding an IAM user without a login profile, initiates a \u003ccode\u003eCreateLoginProfile\u003c/code\u003e API call.\u003c/li\u003e\n\u003cli\u003eThe attacker sets a password for the newly created login profile, gaining console access to the targeted IAM user account.\u003c/li\u003e\n\u003cli\u003eThe attacker logs into the AWS console using the newly created credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages the IAM user\u0026rsquo;s permissions to perform further reconnaissance, lateral movement, or data exfiltration within the AWS environment.\u003c/li\u003e\n\u003cli\u003eThe attacker establishes persistence by maintaining access through the created login profile, even if other access methods are revoked.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows attackers to gain unauthorized console access to previously unprotected IAM user accounts. This can lead to privilege escalation, data breaches, and disruption of cloud services. The lack of multi-factor authentication on newly created login profiles increases the risk of account compromise. The impact can range from reconnaissance to full-scale control of the AWS environment, depending on the permissions associated with the compromised IAM users.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect \u003ccode\u003eGetLoginProfile\u003c/code\u003e and \u003ccode\u003eCreateLoginProfile\u003c/code\u003e events originating from the S3 Browser user agent in AWS CloudTrail logs.\u003c/li\u003e\n\u003cli\u003eInvestigate any instances of IAM LoginProfile creation originating from unusual user agents or IP addresses.\u003c/li\u003e\n\u003cli\u003eImplement multi-factor authentication (MFA) for all IAM users, including those with console access to mitigate the impact of compromised credentials.\u003c/li\u003e\n\u003cli\u003eReview IAM policies to ensure least privilege and restrict the ability to create or modify LoginProfiles to authorized personnel only.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-02T12:00:00Z","date_published":"2024-01-02T12:00:00Z","id":"/briefs/2024-01-02-s3browser-iam-loginprofile/","summary":"The S3 Browser utility is being used to enumerate IAM users lacking login profiles and subsequently create them, potentially for reconnaissance, persistence, and privilege escalation within AWS environments.","title":"S3 Browser Used to Create IAM Login Profiles","url":"https://feed.craftedsignal.io/briefs/2024-01-02-s3browser-iam-loginprofile/"}],"language":"en","title":"CraftedSignal Threat Feed — Iam","version":"https://jsonfeed.org/version/1.1"}