Identity-Audit - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/tags/identity-audit/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioFri, 18 Sep 2026 19:41:30 +0000https://feed.craftedsignal.io/favicon-32x32.pngCraftedSignal Threat Feedhttps://feed.craftedsignal.io/3232https://feed.craftedsignal.io/favicon.svgAWS STS AssumeRole with New MFA Devicehttps://feed.craftedsignal.io/briefs/2026-09-aws-sts-mfa-persistence/Fri, 18 Sep 2026 19:41:30 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-09-aws-sts-mfa-persistence/Adversaries may register new MFA devices for compromised AWS IAM roles to maintain persistence, escalate privileges, or facilitate lateral movement by assuming roles via the AWS Security Token Service (STS).Adversaries targeting AWS environments may attempt to register new Multi-Factor Authentication (MFA) devices against compromised IAM identities to secure long-term access. By leveraging the AWS Security Token Service (STS) AssumeRole, AssumeRoleWithSAML, or AssumeRoleWithWebIdentity APIs, an attacker with valid but potentially limited credentials can perform privilege escalation or lateral movement. The registration of a new MFA device serves as a mechanism to bypass or supersede existing authentication requirements, granting the adversary persistent access to the assumed role's permissions. Defenders should monitor CloudTrail for successful role assumptions that reference previously unseen MFA serial numbers, as this pattern often deviates from standard administrative workflows or automated service account behavior.

Attack Chain

  1. An attacker gains initial access to a set of AWS IAM credentials (e.g., via hardcoded keys, leaked environment variables, or SSRF).
  2. The attacker uses the compromised credentials to query current IAM user permissions and MFA device configurations.
  3. The attacker registers a new, attacker-controlled MFA device (e.g., virtual MFA) to the compromised IAM user account via CreateVirtualMFADevice.
  4. The attacker associates the new MFA device with the target IAM role or user using EnableMFADevice.
  5. The attacker executes AssumeRole or a related STS action, providing the new MFA serial number in the request parameters.
  6. AWS validates the new MFA token, and the attacker receives temporary security credentials.
  7. The attacker leverages the elevated temporary session credentials to access, exfiltrate, or manipulate AWS resources.

Impact

Successful exploitation allows an adversary to maintain persistent access to an AWS account, escalate privileges beyond the initial scope, and move laterally across different accounts or services. This activity can lead to unauthorized data exfiltration, service disruption, or total account takeover depending on the IAM policies attached to the assumed role.

Recommendation

Prioritize monitoring of AWS CloudTrail logs for unusual AssumeRole events. Establish a baseline for normal MFA registrations and role assumptions to reduce false positives from legitimate administrative tasks.

  • Implement alerts for successful AssumeRole events where the request_parameters.serialNumber field is present and indicates a newly registered device.
  • Review all MFA device registration events (e.g., CreateVirtualMFADevice) alongside AssumeRole activity to identify unauthorized additions.
  • Revoke temporary credentials immediately if a role assumption is linked to an unauthorized MFA device registration.
  • Audit IAM policies to ensure that only authorized users have the permission to manage their own MFA devices.
]]>lowadvisorycloudawspersistenceidentity-auditLLMjacking via Compromised AWS Long-Term IAM Credentialshttps://feed.craftedsignal.io/briefs/2026-09-llmjacking-bedrock/Fri, 18 Sep 2026 19:29:20 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-09-llmjacking-bedrock/Adversaries are abusing stolen long-term AWS IAM access keys to perform unauthorized reconnaissance and high-cost model inference within Amazon Bedrock.LLMjacking involves threat actors gaining access to cloud environments and utilizing stolen long-term IAM credentials (AKIA* access keys) to abuse AI services. In the context of Amazon Bedrock, attackers prioritize identifying available foundation models for potential exploitation to run high-volume or high-cost model inference. This activity is notable because legitimate production workloads utilizing Bedrock typically operate under temporary IAM roles, making the use of long-term user keys for discovery and invocation highly irregular. Defenders should monitor for patterns where the same access key performs enumeration followed immediately by model invocation. This activity indicates a potential compromise of IAM credentials and an attempt to leverage the organization's cloud resources for unauthorized AI model consumption at the account owner's expense.

Impact

LLMjacking can result in significant financial impact due to high-volume model inference costs. Furthermore, it indicates that a threat actor has successfully gained Initial Access via compromised credentials, potentially allowing for broader exploitation of other AWS services such as S3 or Secrets Manager if the IAM user has excessive permissions.

Recommendation

  • Monitor AWS CloudTrail logs for the sequence of ListFoundationModels followed by InvokeModel, InvokeModelWithResponseStream, Converse, or ConverseStream by the same access key within 15 minutes.
  • Prioritize auditing of all existing long-term IAM user access keys, enforcing rotation, and migrating Bedrock workloads to IAM roles with short-lived credentials.
  • Investigate the source IP and user agent associated with any long-term key performing Bedrock operations to identify potential unauthorized access or credential exposure.
  • Restrict the usage of long-term keys for AI services through Service Control Policies (SCPs) where business requirements permit.
]]>highadvisorycloudllmawsllmjackingidentity-audit