AWS Security Events Through the Lens of the Seven MITRE ATT&CK Tactics

Hi, I’m Akira Nishikawa, a security engineer and one of the developers behind Suzaku and Senrigan.

Yamato Security is a Japan-based, volunteer-run security community. “Yamato” is an ancient name for Japan, so the name reflects the community’s roots in Japan.

At HITCON 2026, I presented on threat detection in AWS using two open-source tools, Suzaku and Senrigan, as a member of the security community Yamato Security.

In this article, I’ll summarize the events that occur in an AWS environment—and are recorded in AWS CloudTrail—at each stage of the MITRE ATT&CK Enterprise Tactics that I introduced in my part of the presentation.

This article is based on my own experience, along with research and blog posts published by Unit 42, Datadog Security Labs, Permiso, CrowdStrike, and Rapid7.

For that reason, I have intentionally omitted events that are theoretically possible but have not been observed in the wild. Please keep that limitation in mind.

Introduction

Have you ever faced any of these challenges when securing an AWS environment?

• You collect CloudTrail logs and have Amazon GuardDuty enabled, but you are not sure what to look for.
• Alerts keep coming in, but you cannot tell whether they represent an attack or a false positive.
• You want to create detection rules, but you do not know what attackers are likely to do.

To be honest, as I also mentioned during the presentation, it is difficult to detect an attack by looking at isolated events. Viewed individually, these events often look completely normal.

That is why you need to use a tool such as Suzaku or correlate multiple events before drawing a conclusion. In that sense, investigations are often easier after an incident has occurred. Proactively discovering threats before an incident is much more difficult.

Why Organize Events by MITRE ATT&CK?

MITRE ATT&CK is a framework that systematizes attacker behavior observed in the real world. The Enterprise version contains 14 Tactics in total, but the following seven are particularly important when operating an AWS environment.

Step	Tactic	Attacker’s objective
1	Initial Access	Gain an initial foothold in the environment
2	Discovery	Determine what exists in the compromised environment
3	Credential Access	Steal usable credentials and secrets
4	Persistence	Create a backdoor that allows re-entry after the attacker is removed
5	Privilege Escalation	Obtain more powerful privileges
6	Defense Evasion	Erase traces or disable detection
7	Impact	Carry out destruction, data theft, or abuse of cloud resources

One reason for organizing events this way is that GuardDuty Finding names use the same terminology. GuardDuty Findings follow a naming convention in which the Tactic appears at the beginning, such as Persistence:IAMUser/AnomalousBehavior. If you organize your detections around ATT&CK, you can immediately understand which stage of the attack an adversary may be in when you see a Finding.

The urgency is also completely different for one Discovery event versus one Defense Evasion event. The latter strongly suggests that the attacker may already have penetrated deeply into the environment, so it should receive a higher response priority.

Grouping these activities into seven phases may sound similar to the Cyber Kill Chain, but the two are different. The Kill Chain includes phases such as “Weaponization,” which cannot be observed inside a cloud environment. I therefore chose ATT&CK because I believe it is more practical for designing AWS logging and detection.

1. Initial Access

In AWS, major entry points are usually not malware-bearing emails. More commonly, attackers use access keys that were accidentally committed to GitHub, or access keys stolen by exploiting vulnerabilities such as SSRF. This is one of the ways cloud attacks differ from attacks against traditional on-premises environments.

GetCallerIdentity

In ATT&CK, this corresponds to T1078.004 (Valid Accounts: Cloud Accounts). The technique itself spans four Tactics—Initial Access, Persistence, Privilege Escalation, and Defense Evasion—but based on what I have observed, attackers commonly begin by calling GetCallerIdentity, so I classify it under Initial Access.

Some organizations may classify it as Discovery instead. In that case, the relevant technique is T1087.004. I see this as a difference in interpretation: T1078 describes the moment when stolen credentials are used, while T1087 treats the activity as the enumeration of account information. Personally, I consider T1078 the better fit for AWS environments. SigmaHQ positions it under T1087, however, and I do not claim that classification is wrong.

In its JavaGhost article, Unit 42 notes that many threat actors use GetCallerIdentity as their first API call after compromising AWS credentials, in order to identify the account ID and user ID.

Other APIs used during this phase include iam:GetUser and iam:ListAccountAliases, but GetCallerIdentity is the strongest indicator in this context.

That said, Unit 42 has analyzed JavaGhost and believes the threat actor may have intentionally avoided calling GetCallerIdentity because the technique is well known. It is therefore not something you should rely on exclusively. So far, however, every attack I have personally observed has used GetCallerIdentity.

In any case, detecting this API call on its own is difficult. You need to combine it with other signals, such as the source IP and other source attributes.

2. Discovery

During this phase, the attacker checks IAM permissions and enumerates resources.

Datadog has published a list of frequently observed enumeration APIs collected through threat hunting. Based on the way these APIs are used, Datadog infers that the enumeration is automated and, at least during the initial stages, is not being performed manually by a human.

Category	Events
Permission enumeration	ListAttachedUserPolicies, ListAttachedRolePolicies, GetAccountAuthorizationDetails, GetPolicyVersion, SimulatePrincipalPolicy
Principal enumeration	ListUsers, ListRoles, ListGroups, ListAccessKeys, ListMFADevices
Storage reconnaissance	ListBuckets, GetBucketAcl, GetBucketPolicy, GetPublicAccessBlock
Compute and environment reconnaissance	DescribeInstances, DescribeImages, DescribeSnapshots, DescribeSecurityGroups, DescribeRegions
Data-store reconnaissance	DescribeDBInstances, DescribeDBSnapshots, ListTables
Serverless and container reconnaissance	ListFunctions, GetFunction, DescribeRepositories, ListClusters
Secret discovery	ListSecrets, ListVaults, DescribeParameters, ListKeys
Email and SMS capability checks	GetSMSAttributes, GetSendQuota, GetAccountSendingEnabled, ListIdentities
AI/ML reconnaissance	ListFoundationModels, GetFoundationModelAvailability, ListGuardrails
Monitoring and detection posture checks	DescribeTrails, GetTrailStatus, ListDetectors, GetModelInvocationLoggingConfiguration

Datadog has reported the combination of ListSecrets and ListVaults as a concrete pattern observed in a real environment.

Checking the monitoring posture is an early sign of Defense Evasion. Unit 42’s analysis of TeamTNT also reported that the attackers attempted to enumerate CloudTrail configuration and CloudFormation activity, in addition to IAM permissions, EC2 instances, and S3 buckets. If they succeed, logging may be disabled.

When AWS Organizations is used to enforce centralized controls, these attempts will often fail. That makes it important to detect the failed attempts as well. In that context, AccessDenied can be a strong signal of malicious activity.

When analyzing a case involving stolen Lambda credentials, Unit 42 reported that the attackers enumerated multiple services, but most of their requests were denied because they lacked the required permissions. If an attacker relies on automated tooling without first understanding the permissions available to them, the result can be a large volume of AccessDenied events.

A sudden increase in AccessDenied events is anomalous on its own, so it deserves attention. Datadog also appears to implement this as a standard detection rule.

Even if an attacker avoids GetCallerIdentity, this type of activity gives you another opportunity to detect the intrusion.

Datadog has also reported a case in which the same IP address called GetSMSAttributes across multiple Regions within a short period. Even a single API call may be detectable based on the number of Regions involved. It is highly unusual for a legitimate application to retrieve SMS-sending configuration across ten Regions.

3. Credential Access

One of the major attack paths in AWS is the theft of temporary credentials from IMDS, the Instance Metadata Service. Datadog’s State of Cloud Security 2025 report also describes calls to the Instance Metadata Service and the reading of environment variables as typical ways attackers steal credentials after compromising a cloud environment.

Category	Events
Secret retrieval	GetSecretValue, BatchGetSecretValue, GetParameter(s) (WithDecryption: true), GetParametersByPath
Decryption	Decrypt, GenerateDataKey
OS and database credentials	GetPasswordData, GenerateDbAuthToken
Key issuance	CreateAccessKey
Password theft	UpdateLoginProfile, ChangePassword
MFA disabling	DeactivateMFADevice, DeleteVirtualMFADevice
Token retrieval	GetAuthorizationToken (ECR), GetRoleCredentials (Identity Center)
IMDS abuse	No CloudTrail trace is left, but GuardDuty can detect it through InstanceCredentialExfiltration

This step is better addressed through prevention than detection. For example, the following controls are effective:

1. Enforce IMDSv2 (HttpTokens: required) to almost completely prevent credential theft through SSRF.
2. Detect attempts to revert to IMDSv1 through ModifyInstanceMetadataOptions.
3. Set HttpPutResponseHopLimit to 1 to prevent indirect access from containers.

4. Persistence

When incident response reaches the point where “access continues even after the leaked keys have been disabled or deleted,” the most likely explanation is that a persistence mechanism was overlooked.

Datadog reports that attackers who compromise an AWS environment frequently attempt to create an IAM user immediately afterward. I also often observe CreateUser. Of course, there are many other possibilities, including abusing existing users.

As I discussed at HITCON, I have also observed calls to GetFederationToken. This can provide access to the AWS Management Console, and the resulting access remains valid for up to 36 hours. Even if the access key is disabled or deleted, the attacker may still be able to operate during that period.

Datadog and CrowdStrike have both observed and published details about this technique. When it occurs, it is recommended to attach a deny-all policy to the affected IAM user. If the IAM user itself can be deleted, deleting it is of course preferable.

In CloudTrail, a console login with userIdentity.type set to FederatedUser is also a useful detection condition. Unless your organization has a tool that generates federation links, this type of login should not normally occur.

Category	Events
IAM backdoor	CreateUser, CreateAccessKey, CreateLoginProfile
Federation abuse	GetFederationToken, GetSigninToken, ConsoleLogin (FederatedUser)
Lambda + API Gateway	CreateFunction, AddPermission, CreateApi, CreateDeployment
Trust-policy tampering	CreateRole + UpdateAssumeRolePolicy
Identity-provider spoofing	CreateSAMLProvider, UpdateSAMLProvider, CreateOpenIDConnectProvider
Organization changes	InviteAccountToOrganization, CreateAccount
SSM persistence	CreateAssociation, CreateDocument, UpdateDocument
EC2 persistence	RunInstances (UserData), ModifyInstanceAttribute
Resource-policy injection	PutBucketPolicy, PutKeyPolicy, ModifySnapshotAttribute

Datadog has described a case in which attackers combined a Lambda function with an HTTP API Gateway trigger to build a mechanism that could dynamically create IAM users in response to external HTTP requests, even after the original credentials had expired.

It is useful to maintain an inventory of your Lambda functions so that you can quickly identify functions that should not exist. Datadog describes this technique as “persistence-as-a-service” and recommends detecting not only the creation of a Lambda function, but also the function’s combination with API Gateway.

Trust-policy tampering is easy to miss

Be careful with cases where an attacker adds their own account ID or "*" to the Principal in a role’s trust policy through UpdateAssumeRolePolicy. Because this does not require creating an IAM user or an access key, it will not be visible if you only inspect the list of users.

5. Privilege Escalation

AWS has more than 20 IAM privilege-escalation paths. Most of them revolve around the APIs below. Conversely, this means that monitoring these APIs covers a large proportion of privilege-escalation activity.

Category	Events
Policy attachment	AttachUserPolicy, AttachRolePolicy, PutUserPolicy, PutRolePolicy
Group-based escalation	AddUserToGroup
Policy replacement	CreatePolicyVersion + SetDefaultPolicyVersion
Role takeover	UpdateAssumeRolePolicy, AssociateIamInstanceProfile, ReplaceIamInstanceProfileAssociation
PassRole abuse	RunInstances, CreateFunction, CreateStack, RunTask (all used together with iam:PassRole)
Theft of another user’s credentials	UpdateLoginProfile, CreateAccessKey (for a privileged user)
Boundary/SCP removal	DeleteUserPermissionsBoundary, DetachPolicy, DisablePolicyType

Datadog’s State of Cloud Security 2025 report, mentioned earlier, gives AWSMarketplaceFullAccess as an example of an apparently harmless AWS managed policy that can provide a privilege-escalation path. An attacker can use it to launch an EC2 instance with a privileged role attached and thereby obtain administrative access to the account.

This is related to iam:PassRole. PassRole allows an IAM role to be passed to an AWS service, but it is not inherently dangerous on its own. It is required for operations such as attaching a role to an EC2 instance or configuring an execution role for a Lambda function, so it is commonly included in policies used by developers in their day-to-day work.

The risk appears when PassRole is combined with permissions to create or launch a service. For example:

Example:
iam:PassRole + ec2:RunInstances
  → Launch an EC2 instance with an administrator role attached
    → Access the instance through UserData or SSH
      → Retrieve temporary credentials for the role from IMDS (169.254.169.254)
        → Obtain administrator privileges

The problem is that this combination is sometimes included in AWS managed policies from the beginning. AWSMarketplaceFullAccess, mentioned above, is one such example.

There are also similar privilege-escalation techniques involving Lambda functions, ECS tasks, and other services.

Not every escalation involves attaching a policy. CreatePolicyVersion may appear harmless at first glance, but it can be used to replace an existing policy. In such a case, no “attachment” event such as AttachUserPolicy is generated. If you monitor only policy-attachment events, you will miss it.

After creating a new policy version, the attacker replaces the active version with SetDefaultPolicyVersion. It is therefore useful to detect CreatePolicyVersion and SetDefaultPolicyVersion as a pair.

6. Defense Evasion

Once this Tactic is observed, you should begin incident response immediately.

An attempt to stop logging means that the attacker intends to do something they do not want you to see. Moreover, actions taken after logging is disabled will not be recorded. A Defense Evasion alert may therefore be the last clue you have.

Category	Events
CloudTrail disruption	StopLogging, DeleteTrail, UpdateTrail, PutEventSelectors
Detection-service disruption	DeleteDetector, UpdateDetector, CreateFilter (suppression rule), DisableSecurityHub, StopConfigurationRecorder
Log deletion or retention reduction	DeleteFlowLogs, DeleteLogGroup, PutRetentionPolicy, DeleteModelInvocationLoggingConfiguration
Destruction of recovery mechanisms	PutBucketVersioning (Suspended), PutBucketLifecycle, DeleteBackupVault
Notification-path removal	DeleteAlarms, RemoveTargets, DeleteRule
Guardrail removal	DeletePublicAccessBlock, UpdateAccountPasswordPolicy, DeleteGuardrail (Bedrock)
IMDS weakening	ModifyInstanceMetadataOptions (to IMDSv1)
Region hopping	Any activity in a Region that is not normally used

Attackers may use UpdateTrail to change the destination bucket or exclude global events without deleting the trail itself. In that situation, the management console will continue to show that a trail exists. If you monitor only StopLogging, you will miss this type of tampering.

Similarly, CreateFilter can create a situation in which GuardDuty is still running, but Findings originating from the attacker’s IP address are automatically archived. You need to monitor configuration changes in general, not just the disabling of detection services.

This may not happen often, but if GuardDuty is not enabled in a particular Region, an attacker may choose to operate there. Do not leave a Region outside your detection coverage simply because you do not normally use it. Unless there is a specific reason not to, enable GuardDuty in every Region.

7. Impact

This is the stage at which the attacker carries out their ultimate objective. In practice, it is also common to monitor Exfiltration, or data theft, alongside Impact.

Ransomware is often discussed, but in real-world incidents I rarely see it. Phishing and spam campaigns sent through SES or SNS, as well as cryptomining, are much more common. Data theft is another common objective, and more recently I have also seen attempts to abuse Amazon Bedrock.

Unit 42 reported a case involving stolen Lambda credentials in which the attackers launched phishing campaigns through SES resources they had created. The JavaGhost analysis also identified phishing through SES and SNS as a primary objective. Similarly, Datadog reported a case in which operators of phishing sites impersonating the French government enumerated SMS-sending configuration in a victim’s AWS account.

Event	Purpose
VerifyEmailIdentity, VerifyDomainIdentity	Register a sender
SendEmail, SendRawEmail, SendBulkTemplatedEmail	Send email
CreateConfigurationSet, UpdateAccountSendingEnabled	Remove sending restrictions
SetSMSAttributes, Publish (SNS)	Send SMS messages

These incidents may not always be treated as severe, but the impact can be significant. Your domain may be used for phishing, your SES sending reputation may drop sharply, and legitimate email delivery may be affected. For that reason, I personally consider the severity to be Critical.

Regarding LLM jacking, Permiso discovered and reported that attackers were using hijacked LLM infrastructure to operate abusive AI chatbot services. Datadog also observed the enumeration of Bedrock in its Q3 2025 report, supporting the trend that Permiso reported in 2024.

Event
InvokeModel, InvokeModelWithResponseStream, Converse
ListFoundationModels, GetFoundationModelAvailability
DeleteModelInvocationLoggingConfiguration

MITRE ATT&CK has also introduced T1496.004 (Cloud Service Hijacking), formally documenting this threat. GuardDuty provides Impact:IAMUser/AnomalousModelInvocation and Impact:IAMUser/CostHarvesting as part of AI Protection.

Cryptomining may involve events such as the following:

Event
RunInstances (GPU or large instances, especially in an unused Region)
CreateCluster, RegisterTaskDefinition, RunTask (ECS/Fargate)
RequestSpotInstances, CreateFleet
RequestServiceQuotaIncrease

The following events may be associated with destruction, ransomware, data theft, or lateral movement.

Category	Events
Destruction	TerminateInstances, DeleteBucket, DeleteDBInstance, DeleteStack
Ransomware	ScheduleKeyDeletion, DisableKey, PutBucketEncryption (SSE-C)
Data theft	GetObject (large volumes), ModifySnapshotAttribute, CopySnapshot, CreateReplicationConfiguration
Lateral movement	SendSSHPublicKey (EC2 Instance Connect), SendCommand, StartSession

ScheduleKeyDeletion has a minimum waiting period of seven days, so it can be canceled if it is detected in time. Conversely, if you fail to detect it, recovery may become impossible. GuardDuty may also detect this activity.

Making a snapshot public through ModifySnapshotAttribute is a way to exfiltrate data without transferring a single byte directly. The problem is that the event itself may not look suspicious in the logs.

Conclusion

There are an enormous number of security events in AWS. However, if you reorganize them from the perspective of what the attacker is trying to achieve, you can narrow down what you need to investigate.

I have not yet tested whether Suzaku can detect every event described here, but I added 770 detection rules in August and improved its detection accuracy. Suzaku and Senrigan are useful for detecting this type of activity. That said, Suzaku is currently more useful during an incident than as a tool for routine daily operations, so incorporating it into an operational workflow requires some thought.

As I mentioned at HITCON, there are several other characteristics of attacks beyond the events covered in this article. I hope to discuss those at another time.

Even without using a tool like this, one thing you should do immediately is configure alerts for StopLogging and DeleteDetector. These are among the most effective ways to catch early signs of an attack.

They are not foolproof, but an environment in which either of these events appears—regardless of whether the operation succeeds or fails—is likely already in a serious state. They may also be the last events that remain in the logs.

This article became rather long, but thank you very much for reading to the end!

I will continue working to give back to the community by sharing the knowledge we gain at Cyber Security Cloud—and, in turn, by learning from the community as well. Thank you for your continued support!