AWS IAM — CraftedSignal Threat Feed

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 Credentials Used from GitHub Actions and Non-CI/CD Infrastructure

hello@craftedsignal.io — Wed, 22 Apr 2026 17:45:55 +0000

This threat involves the unauthorized use of AWS credentials stolen from GitHub Actions secrets. Attackers exfiltrate these credentials and use them from their own infrastructure, bypassing the intended CI/CD environment. The activity is detected by observing AWS access keys appearing in CloudTrail logs originating from both legitimate GitHub Actions runners (identified by Microsoft ASN or the github-actions user agent string) and suspicious infrastructure outside the expected CI/CD provider ASNs (Amazon, Google, Microsoft). This indicates a breach of GitHub repository or organization secrets, leading to potential unauthorized access and control over AWS resources. This activity can begin with compromised Github accounts.

Attack Chain

An attacker gains unauthorized access to a GitHub repository or organization with AWS credentials stored as secrets.
The attacker exfiltrates the AWS access key ID and secret access key, either manually or through automated means, such as modifying a GitHub Action workflow to expose the secrets.
The attacker configures the stolen AWS credentials on their own infrastructure, using tools like the AWS CLI or boto3.
The attacker attempts to authenticate to AWS using the stolen credentials. This generates CloudTrail logs with the attacker’s source IP address and ASN.
The attacker performs reconnaissance activities, such as calling sts:GetCallerIdentity, ListBuckets, DescribeInstances, or ListUsers, to understand the AWS environment and identify potential targets.
The attacker attempts to escalate privileges or move laterally within the AWS environment by exploiting the compromised credentials.
The attacker may create, modify, or delete AWS resources, such as EC2 instances, S3 buckets, or IAM roles, depending on the permissions associated with the stolen credentials.

Impact

Successful exploitation leads to unauthorized access to AWS resources, potentially resulting in data breaches, service disruptions, or financial losses. The impact depends on the permissions associated with the stolen AWS credentials. A single compromised credential could expose sensitive data, disrupt critical services, or allow attackers to deploy malicious infrastructure within the victim’s AWS environment. Identifying and responding to this threat quickly is vital to minimize damages.

Recommendation

Deploy the Sigma rule “AWS Credentials Used from GitHub Actions and Non-CI/CD Infrastructure” to your SIEM and tune for your environment to detect suspicious usage patterns.
Rotate the compromised AWS access key in IAM immediately and update the corresponding GitHub repository/organization secret as described in the rule documentation.
Implement OIDC-based authentication (aws-actions/configure-aws-credentials with role-to-assume) instead of long-lived access keys as mentioned in the rule documentation.
If using OIDC, add IP condition policies to the IAM role trust policy to restrict AssumeRoleWithWebIdentity to known GitHub runner IP ranges, based on the information in the rule documentation.

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

Suspicious AWS SAML Activity Detection

hello@craftedsignal.io — Wed, 03 Jan 2024 18:22:30 +0000

This detection identifies potentially malicious Security Assertion Markup Language (SAML) activity within Amazon Web Services (AWS). The activity includes monitoring for AssumeRoleWithSAML and UpdateSAMLProvider events. An adversary might exploit SAML to gain unauthorized access, escalate privileges, move laterally within the AWS environment, or establish persistent backdoor access. The focus is on detecting unusual or unauthorized modifications to SAML configurations and role assumptions, which could indicate a compromised identity provider or malicious actor leveraging SAML for illicit purposes. Defenders should prioritize monitoring SAML-related API calls to identify and mitigate potential threats early in the attack chain.

Attack Chain

The attacker compromises or creates a malicious SAML identity provider.
The attacker configures the AWS environment to trust the malicious SAML provider using UpdateSAMLProvider.
The attacker crafts a SAML assertion to assume a specific role within the AWS environment.
The attacker uses the AssumeRoleWithSAML API call to authenticate with AWS using the crafted SAML assertion.
AWS STS validates the SAML assertion and, if valid, provides temporary credentials for the assumed role.
The attacker uses the temporary credentials to perform actions within AWS, potentially escalating privileges.
The attacker moves laterally within the AWS environment, accessing resources and services authorized for the assumed role.
The attacker establishes persistent access by creating backdoors or modifying existing IAM policies, leveraging the initially gained access.

Impact

Successful exploitation via SAML manipulation can lead to a complete compromise of the AWS environment. Attackers can gain unauthorized access to sensitive data, disrupt critical services, and deploy malicious infrastructure. The impact includes potential data breaches, financial losses, and reputational damage. The number of affected resources depends on the permissions associated with the roles assumed by the attacker.

Recommendation

Deploy the Sigma rule for AssumeRoleWithSAML events to detect suspicious role assumptions (see “AssumeRoleWithSAML Detection Rule”).
Deploy the Sigma rule for UpdateSAMLProvider events to detect unauthorized SAML provider modifications (see “UpdateSAMLProvider Detection Rule”).
Investigate any AssumeRoleWithSAML events originating from unfamiliar user agents or IP addresses by reviewing CloudTrail logs.
Monitor UpdateSAMLProvider events for unexpected changes to SAML provider configurations. Review associated CloudTrail logs for user identity, user agent, and hostname to ensure authorized access.
Tune the provided Sigma rules for your environment, addressing false positives by exempting known, legitimate behavior.

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.

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.