Iam — CraftedSignal Threat Feed

Expanding Detection Beyond Endpoints to Counter Evolving Threats

hello@craftedsignal.io — Fri, 01 May 2026 23:13:22 +0000

The 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’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.

Attack Chain

Initial Access via Cloud Misconfiguration: The attacker gains initial access through a misconfigured cloud service access key.
Cloud Console Manipulation: The attacker manipulates the cloud console to hide their tracks from endpoint detection.
Pivot to Cloud-Hosted Server: From the cloud console, the attacker pivots to a cloud-hosted server to begin discovery.
Credential Theft (Covert C2): The attacker utilizes DNS tunneling to a cloud storage location for C2 communication and steals credentials to use legitimate applications.
Lateral Movement: The attacker moves laterally using the stolen credentials, triggering impossible travel alerts across SaaS apps.
Rogue Asset Introduction: The attacker introduces a rogue device into the network, bypassing traditional endpoint security measures.
Persistence: The attacker maintains persistence through the rogue device, using it for covert movement and access.
Data Exfiltration: The attacker exfiltrates sensitive data, taking advantage of the gaps in security visibility.

Impact

Organizations 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’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.

Recommendation

Ingest 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.
Implement User and Entity Behavior Analytics (UEBA) as mentioned in the overview, to detect anomalous behavior indicative of compromised credentials by using a centralized workbench.
Deploy 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.
Implement continuous network monitoring and external attack surface management to detect and manage rogue assets, as highlighted in the attack chain.
Evaluate your current visibility through a formal assessment as recommended in the conclusion, to identify gaps in security coverage.

AWS IAM Privilege Operations via Lambda Execution Role

hello@craftedsignal.io — Fri, 01 May 2026 20:57:28 +0000

This 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.

Attack Chain

An attacker gains unauthorized access to a Lambda function, either through code injection, vulnerable dependencies, or misconfiguration.
The attacker leverages the Lambda function’s execution role, which has excessive IAM permissions.
The attacker executes IAM API calls, such as CreateUser, CreateRole, or CreateAccessKey, to create new IAM identities.
The attacker uses AttachUserPolicy, PutUserPolicy, AttachRolePolicy, or PutRolePolicy to grant elevated permissions to the newly created or existing IAM identities.
The attacker modifies instance profiles using CreateInstanceProfile and AddRoleToInstanceProfile to prepare EC2 instances for lateral movement.
The attacker uses the newly created or modified IAM identities to assume roles and access resources they were not previously authorized to access via sts:AssumeRole.
The attacker achieves privilege escalation, gaining control over sensitive AWS resources and services.
The attacker establishes persistence by creating rogue IAM users, roles, or access keys.

Impact

A 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.

Recommendation

Deploy the Sigma rule “AWS IAM Sensitive Operations via Lambda Execution Role” to your SIEM and tune for your environment to detect the described IAM API calls originating from Lambda execution roles.
Review and restrict the permissions granted to Lambda execution roles, following the principle of least privilege, to minimize the potential impact of a compromised function.
Monitor aws.cloudtrail.user_identity.arn to identify the Lambda function and associated deployment path responsible for the IAM API calls.
Investigate aws.cloudtrail.request_parameters for targets such as userName, groupName, roleName, policyArn, or instanceProfileName to understand the scope of the IAM operations.
Revoke or rotate the credentials of any compromised Lambda execution roles to prevent further unauthorized access.
Remediate any rogue IAM users, roles, or access keys created by the attacker to eliminate persistence mechanisms.

AWS IAM Login Profile Added for Root

hello@craftedsignal.io — Fri, 10 Apr 2026 16:27:52 +0000

This rule detects the creation of a console login profile for the AWS account root user, a highly privileged account. While CreateLoginProfile is normally applied to IAM users, when executed from a temporary root session (e.g., via AssumeRoot) without specifying a userName, 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.

Attack Chain

An attacker gains initial access to an AWS account with sufficient privileges, possibly through compromised credentials or an STS session.
The attacker executes the AssumeRoot API call to assume the privileges of the root user.
The attacker uses the CreateLoginProfile API call without specifying a userName. This action creates a console login profile directly for the root account instead of an IAM user. The aws.cloudtrail.request_parameters will not contain userName=.
The attacker sets a password for the root account using the CreateLoginProfile API. passwordResetRequired might be set to true or omitted, with omission potentially indicating an attacker-controlled password.
The attacker uses the newly created root account password to log in to the AWS Management Console. The event will be logged as a ConsoleLogin event.
The attacker uses the root account’s privileges to create or modify resources, escalate privileges, or exfiltrate data.
The attacker maintains persistence by using the console login, even if the initially compromised credentials or temporary session tokens are revoked.
The attacker may also create new IAM users or roles with elevated permissions to further solidify their presence.

Impact

A 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.

Recommendation

Deploy the Sigma rule “AWS IAM Login Profile Added for Root” to detect unauthorized creation of login profiles for the root account and tune for your environment.
Investigate any CreateLoginProfile events where aws.cloudtrail.user_identity.type is Root and aws.cloudtrail.request_parameters does not contain userName=.
Enable CloudTrail, GuardDuty, AWS Config, and Security Hub across all regions for continuous monitoring of root and IAM activity to improve overall visibility.
Review IAM policies for least-privilege adherence, focusing on iam:CreateLoginProfile, iam:UpdateLoginProfile, and iam:CreateAccessKey permissions.

AWS IAM Long-Term Access Key Correlated with Elevated Detection Alerts

hello@craftedsignal.io — Mon, 06 Apr 2026 14:37:37 +0000

This 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 “AWS Long-Term Access Key First Seen from Source IP” 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 kibana.alert fields to identify related events.

Attack Chain

An 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.
The attacker uses the compromised access key to interact with AWS services from a new and previously unseen IP address. This triggers the “AWS Long-Term Access Key First Seen from Source IP” rule (rule ID: 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f).
The attacker leverages the compromised credentials to perform reconnaissance activities within the AWS environment, such as listing resources or querying IAM configurations.
The attacker attempts to escalate privileges by exploiting misconfigurations or vulnerabilities in IAM policies.
The attacker performs actions indicating lateral movement within the AWS environment, such as accessing or modifying resources in different AWS accounts.
The attacker compromises additional AWS resources or services, such as EC2 instances or S3 buckets. These activities trigger medium, high, or critical severity alerts.
The correlation rule identifies the co-occurrence of the “AWS Long-Term Access Key First Seen from Source IP” alert and other elevated severity alerts associated with the same access key ID.
The security team investigates the correlated alerts and takes appropriate remediation steps, such as rotating the compromised access key and reviewing IAM policies.

Impact

A 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.

Recommendation

Deploy the “AWS IAM Long-Term Access Key Correlated with Elevated Detection Alerts” rule (rule ID 98cfaa44-83f0-4aba-90c4-363fb9d51a75) in your Elastic Security environment to identify potentially compromised IAM access keys.
Investigate alerts triggered by the rule by pivoting on the aws.cloudtrail.user_identity.access_key_id in CloudTrail and IAM to understand the context of the access key usage.
Review the sibling alerts identified by the rule using Esql.kibana_alert_rule_name_values and Esql.kibana_alert_rule_id_values to understand the scope and impact of the potential compromise.
Configure your Elastic Security deployment to properly map risk scores to severity levels, ensuring that kibana.alert.risk_score >= 47 corresponds to medium or higher severity alerts.
Rotate or disable any IAM access keys identified as compromised by the rule to prevent further unauthorized access.
Enable AWS CloudTrail logging to capture detailed information about API calls made within your AWS environment, providing valuable context for investigating security alerts.
Implement the “AWS Long-Term Access Key First Seen from Source IP” rule (rule_id: 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f) if not already enabled, as it is a pre-requisite for this correlation rule.

AWS SAML Provider Deletion Activity

hello@craftedsignal.io — Thu, 19 Dec 2024 00:00:00 +0000

The 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’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.

Attack Chain

Initial access is gained to an AWS account through compromised credentials or other means (T1078.004).
The attacker enumerates existing IAM resources, including SAML providers, using AWS CLI or API calls.
The attacker identifies the SAML provider used by administrative or security teams.
The attacker executes the DeleteSAMLProvider API call via the AWS CLI, API, or AWS Management Console (T1531).
The DeleteSAMLProvider event is logged in AWS CloudTrail with a “success” status.
Administrative and security teams lose access to AWS resources that require SAML authentication.
The attacker leverages the compromised account to escalate privileges, create new IAM users, or modify existing policies.
The attacker persists in the environment, potentially exfiltrating data or deploying malicious workloads (T1485).

Impact

The 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.

Recommendation

Deploy the Sigma rule “AWS SAML Provider Deletion Activity” to your SIEM and tune for your environment to detect this specific event.
Investigate any DeleteSAMLProvider events in AWS CloudTrail, focusing on the user identity, user agent, and source IP address (logsource: aws/cloudtrail).
Implement multi-factor authentication (MFA) for all IAM users, especially those with administrative privileges, to reduce the risk of credential compromise (T1110).
Review and enforce the principle of least privilege for all IAM roles and users to limit the impact of compromised credentials.

S3Browser IAM Policy Creation with Default Bucket Name

hello@craftedsignal.io — Fri, 26 Jan 2024 12:00:00 +0000

The 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 . 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.

Attack Chain

An attacker gains initial access to an AWS account, possibly through compromised credentials or misconfigured IAM roles (T1078.004).
The attacker utilizes the S3Browser utility to interact with AWS S3 buckets.
The attacker attempts to create an Inline IAM policy using S3Browser.
The attacker fails to replace the default bucket name placeholder with a specific bucket ARN.
The attacker saves the IAM policy with the default bucket name placeholder, leading to a broad or unintended scope of permissions.
The poorly configured policy is applied to a user, role, or group.
The attacker potentially escalates privileges or gains unauthorized access to S3 resources.
The attacker persists in the environment with the newly created or modified IAM policy.

Impact

Creation 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.

Recommendation

Deploy the Sigma rule “AWS IAM S3Browser Templated S3 Bucket Policy Creation” to your SIEM and tune for your environment to detect this specific activity.
Investigate any instances where PutUserPolicy events are associated with the S3Browser user agent (logsource: aws/cloudtrail).
Review existing IAM policies for the presence of the default bucket name placeholder arn:aws:s3:::/* (logsource: aws/cloudtrail).

AWS IAM User or Access Key Creation via S3 Browser

hello@craftedsignal.io — Wed, 03 Jan 2024 14:30:00 +0000

The 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.

Attack Chain

An attacker gains initial access to an AWS environment, potentially through compromised credentials or an exploited vulnerability.
The attacker installs and configures S3 Browser on a compromised host or uses an existing installation.
The attacker authenticates S3 Browser to the AWS environment using existing compromised credentials or an assumed role.
The attacker uses S3 Browser to execute the CreateUser API call within AWS IAM.
The attacker configures the new IAM user with elevated privileges, potentially granting administrator access.
Alternatively, the attacker uses S3 Browser to execute the CreateAccessKey API call for an existing IAM user.
The attacker uses the newly created access key to perform actions within the AWS environment.
The attacker leverages the new user or access key for persistence, lateral movement, and data exfiltration within the AWS environment.

Impact

Successful 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.

Recommendation

Deploy the Sigma rule “AWS IAM S3Browser User or AccessKey Creation” to your SIEM and tune for your environment to detect anomalous IAM activity originating from S3 Browser.
Investigate any instances of CreateUser or CreateAccessKey events in AWS CloudTrail logs where the userAgent contains “S3 Browser”.
Implement multi-factor authentication (MFA) for all IAM users to mitigate the risk of credential compromise.
Review and enforce the principle of least privilege for all IAM users and roles to limit the impact of compromised credentials.

AWS IAM Customer Managed Policy Version Manipulation for Privilege Escalation

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This 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 (CreatePolicyVersion) and the modification of the default version (SetDefaultPolicyVersion). 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.

Attack Chain

An attacker compromises an IAM user or role with permissions to modify IAM policies (iam:CreatePolicyVersion or iam:SetDefaultPolicyVersion).
The attacker identifies a customer-managed policy attached to a high-privilege role or user.
The attacker crafts a new policy version with overly permissive rules, such as wildcard actions and resources.
The attacker uses the CreatePolicyVersion API call to upload the malicious policy version to the target policy.
Alternatively, the attacker uses the SetDefaultPolicyVersion API call to set a pre-existing, but less restrictive, policy version as the default.
The compromised IAM user or role assumes the high-privilege role targeted in step 2.
The attacker gains elevated privileges based on the modified IAM policy.
The attacker performs unauthorized actions within the AWS environment, such as accessing sensitive data, modifying infrastructure, or creating new resources.

Impact

Successful 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.

Recommendation

Deploy the Sigma rule “AWS IAM Customer Managed Policy Version Created or Default Version Set” to your SIEM to detect suspicious policy modifications. Tune the rule based on your organization’s baseline activity.
Review aws.cloudtrail.request_parameters logs to identify the policyArn and policyDocument associated with the policy changes detected by the rule.
Implement strong IAM governance practices, including the principle of least privilege and regular reviews of policy permissions, to minimize the impact of policy manipulation.
Monitor CloudTrail logs for AttachUserPolicy, AttachRolePolicy, or CreatePolicyVersion spikes from the same principal as detected policy modifications.
Enable MFA for all IAM users, especially those with permissions to manage IAM policies.

AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This detection rule identifies instances of successful AWS AssumeRoleWithWebIdentity 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 Amazon.com, Inc.), 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.

Attack Chain

Attacker gains unauthorized access to a Kubernetes service account token within a compromised pod or through other means.
Attacker exfiltrates the service account token from the Kubernetes cluster.
The attacker uses the exfiltrated token to call the AWS STS AssumeRoleWithWebIdentity API.
The AssumeRoleWithWebIdentity call is made from a network with an ASN organization name that is not Amazon.com, Inc..
AWS CloudTrail logs the successful AssumeRoleWithWebIdentity event, including details about the user, source IP, and ASN organization.
The compromised IAM role is used to perform unauthorized actions within the AWS environment.
These actions could include data exfiltration, resource modification, or further lateral movement within the cloud infrastructure.

Impact

A 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.

Recommendation

Deploy the Sigma rule AWS AssumeRoleWithWebIdentity from Kubernetes SA and External ASN to your SIEM and tune for your environment.
Investigate any alerts generated by the Sigma rule by following the investigation steps in the rule’s note field.
Expand the source.as.organization.name exclusions in the Sigma rule for known and trusted egress paths if needed.
Enable geolocation/ASN enrichment for your AWS CloudTrail logs to accurately identify the source of AssumeRoleWithWebIdentity calls.
Regularly review and rotate IRSA trust relationships to minimize the impact of compromised service account tokens.
Revoke the role session, rotate IRSA trust where appropriate, investigate token exposure, and reduce service account and role permissions if unauthorized access is suspected.

S3 Browser Used to Create IAM Login Profiles

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

The 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.

Attack Chain

Attacker gains initial access to a system with AWS CLI tools installed or uses a compromised IAM user with sufficient permissions.
The attacker configures S3 Browser with valid AWS credentials, enabling interaction with the AWS environment.
S3 Browser initiates a GetLoginProfile API call in AWS CloudTrail, to enumerate IAM users and identify those without existing login profiles.
S3 Browser, upon finding an IAM user without a login profile, initiates a CreateLoginProfile API call.
The attacker sets a password for the newly created login profile, gaining console access to the targeted IAM user account.
The attacker logs into the AWS console using the newly created credentials.
The attacker leverages the IAM user’s permissions to perform further reconnaissance, lateral movement, or data exfiltration within the AWS environment.
The attacker establishes persistence by maintaining access through the created login profile, even if other access methods are revoked.

Impact

Successful 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.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect GetLoginProfile and CreateLoginProfile events originating from the S3 Browser user agent in AWS CloudTrail logs.
Investigate any instances of IAM LoginProfile creation originating from unusual user agents or IP addresses.
Implement multi-factor authentication (MFA) for all IAM users, including those with console access to mitigate the impact of compromised credentials.
Review IAM policies to ensure least privilege and restrict the ability to create or modify LoginProfiles to authorized personnel only.