Behavioral Mapping Brings Context to AWS Identity Detection

Cloud identity monitoring often begins with a permissions question: what can a role or user do? Palo Alto Unit 42 argues that a second question is just as important: what does that identity actually do in production?

In its research, “Unmasking Cloud Identities: From Behavioral Clustering to Automated Detection”, Palo Alto Unit 42 presents a behavioral approach to mapping cloud identities from audit-log activity. The work focuses on AWS CloudTrail and uses machine-learning techniques to group identities by the operations they perform. The resulting behavioral profiles can then be reduced to lightweight logic suitable for standard SQL queries.

This is not a report of a single intrusion or a newly discovered malware family. It is a detection-engineering study aimed at improving the context available to security teams when they investigate cloud IAM activity. Its central premise is that identity permissions and identity behavior describe different parts of the risk picture.

Why permissions alone provide an incomplete picture

An AWS identity may be authorized to perform a broad range of actions without regularly using them. Unit 42 notes that over-privileged identities can remain in production for long periods without generating an incident. Conversely, a role with a familiar name or apparently benign policy may be misused if an attacker obtains access to it.

Static posture analysis can identify excessive permissions, but it does not necessarily establish whether an identity behaves like an administrator, a backup service, a security scanner, or a CI/CD component. Behavioral analysis supplies that missing operational baseline.

Unit 42 illustrates the problem with resource enumeration. An identity that lists many resources could be a security product performing a routine scan, or it could be a service account whose normal function is limited to a storage bucket. The same API activity can therefore have very different meanings depending on the identity’s established role.

The research also describes masquerading as a challenge. Names, labels, and existing permission profiles may make an identity appear ordinary even when its activity does not match the behavior expected from that functional role. A behavioral baseline can expose that mismatch without relying only on naming conventions or assigned IAM policy.

What Unit 42 analyzed

Palo Alto Unit 42 examined the behavior of more than 40,000 identities across 125 cloud environments over a two-month period. The research mapped identities to functional categories including administrators, backup services, security tooling, DevOps systems, infrastructure-as-code runners, CI/CD systems, networking components, and FinOps platforms.

The source organization’s findings indicate that identities tend to form recognizable behavioral groups. These groups are based on the AWS operations recorded in CloudTrail rather than solely on the names or permissions associated with an identity.

For the analysis, each identity was represented as a vector describing which cloud operations it invoked during the observation period. The operational vocabulary contained more than 15,000 possible operations, creating a high-dimensional and sparse dataset. Unit 42 used Uniform Manifold Approximation and Projection, or UMAP, to reduce the dimensionality and Hierarchical Density-Based Spatial Clustering of Applications with Noise, or HDBSCAN, to identify dense groups and outliers.

The research used several methods to interpret those groups:

• Operation frequency: identifying the APIs most commonly used by identities in a cluster.
• Class-based scoring: using c-TF-IDF to find operations that distinguish one group from the rest of the dataset.
• Attribute-based mapping: highlighting groups according to operations, services, or metadata.
• Identity naming patterns: examining recurring substrings and naming conventions as supporting context.

These methods are complementary rather than interchangeable. Unit 42 specifically cautions, through its methodology, against treating the name of an individual identity as decisive evidence. Repeated patterns across a cluster provide stronger context than a single “admin” or similar substring.

The administrator cluster as a worked example

The report examines a large cluster of identities operating primarily through the AWS Management Console. It contained roughly 5,000 identities spanning more than 100 cloud projects. About 94% of the identities in this cluster invoked ConsoleLogin, while fewer than 1% of identities in other clusters performed that operation, according to Unit 42’s analysis.

Approximately 60% of the identities in the selected cluster also invoked operations associated with normal AWS Console behavior, including GetCostAndUsage and GetCostForecast. The researchers further identified operations such as ListNotificationHubs as useful distinguishing markers when applying class-based scoring.

Metadata helped validate the interpretation, but did not replace behavioral evidence. Identities containing the substring “admin” were concentrated in the cluster, and the researchers found recurring names beginning with AWSReservedSSO_AdministratorAccess_, a prefix associated with AWS IAM Identity Center assignments of AdministratorAccess.

Unit 42’s assessment is that the combined evidence supports classifying this group as administrative users primarily accessing AWS through the Management Console. That conclusion comes from the convergence of activity patterns, statistical scoring, attributes, and naming evidence—not from any one API or naming convention.

From machine-learning map to SQL detection

A full clustering pipeline is useful for discovering the landscape, but continuously running a complex model may not be practical for every security operation. Unit 42 therefore describes a second stage: distilling the behavioral findings into focused classifiers.

The researchers trained logistic-regression models for selected groups using the original sparse operation vectors. L1 regularization, also known as Lasso, reduced irrelevant feature weights to zero. The result was a smaller and more interpretable set of operations that increased or decreased the likelihood that an identity belonged to a target cluster.

This interpretability matters operationally. Analysts can review which CloudTrail operations contribute to a classification instead of receiving an opaque score with no clear explanation. Unit 42 reports that the resulting logic can be expressed in standard SQL, allowing organizations to classify identities at scale without continuously operating the full dimensionality-reduction and clustering pipeline.

For security teams, the practical model is a two-layer process. First, use broader analysis to discover and validate functional groups. Second, convert stable behavioral markers into maintainable queries that can run against new or changing CloudTrail data.

How the approach supports anomaly detection

Behavioral role information can add context to otherwise noisy detections. A backup identity that suddenly performs administrative operations should be investigated differently from a known console administrator performing the same operation. Similarly, an identity associated with a security scanner may reasonably enumerate resources, while a narrowly scoped application role doing so may warrant review.

The source research describes this as a way to identify deviations from an established functional baseline and to make defense-evasion attempts more visible. It does not claim that clustering alone proves compromise. A classification is context, not a verdict, and legitimate changes in architecture, automation, or job responsibility can alter an identity’s normal behavior.

In its appendix, Unit 42 lists example alerts that use behavioral roles alongside Cloud Detection and Response data. The listed detections include AWS Systems Manager command attempts, password-policy discovery, cloud-account discovery, web ACL deletion, activity in a dormant cloud region, backup-vault deletion, instance creation, cross-account permissions, trust-policy changes, and S3 exposure through ACL or policy modification. The appendix maps these alerts to MITRE ATT&CK techniques including T1651, T1201, T1087.004, T1562, T1535, T1490, T1578.002, and T1098.003.

Those examples should be understood as detection scenarios described by the source, not as evidence that the studied environments were attacked or that a particular actor carried them out.

What organizations should do now

• Centralize and retain CloudTrail data. Ensure that identity activity, authentication events, discovery operations, and administrative changes are available for investigation across relevant AWS accounts and environments.
• Build identity behavior baselines. Group identities by observed function, such as human administration, CI/CD, backup, security tooling, or application service activity. Treat permissions and behavior as separate data points.
• Use naming only as supporting evidence. Resource names and prefixes can help explain a cluster, but they should not determine whether activity is trusted.
• Prioritize role changes and functional mismatches. Review cases where a service identity begins using administrative APIs, a dormant identity becomes active, or an established role starts operating across unfamiliar services or regions.
• Translate validated patterns into explainable queries. SQL-based logic can provide a practical way to operationalize stable behavioral markers, while preserving visibility into why an identity was classified.
• Reduce excessive privilege. Behavioral analytics does not substitute for least privilege. Use findings to review unused permissions, standing administrative access, service-account scope, and cross-account trust relationships.
• Design for change. Reassess baselines after major deployments, migrations, tooling changes, or organizational shifts. A role’s legitimate behavior can evolve, and stale models can increase false positives.
• Correlate before escalating. Combine identity classification with authentication context, resource changes, ticketing records, deployment activity, and other available telemetry before treating an anomaly as an incident.

Unit 42 states that the methodology can extend beyond AWS CloudTrail to other cloud providers, SaaS platforms, and Kubernetes audit data. That is a research assessment and a design direction, not a result demonstrated in the supplied study. Organizations should validate portability against their own event schemas, identity models, and operational patterns.

Conclusion

Palo Alto Unit 42’s research presents behavioral clustering as a way to make cloud identity detection more precise. By learning what identities do—not only what they are allowed to do—security teams can establish functional baselines, reduce ambiguity in CloudTrail investigations, and turn validated machine-learning insights into explainable SQL detections.

The approach is most useful as an additional layer of context. It does not replace least-privilege controls, identity governance, logging, or human investigation. Its value lies in connecting those controls to the operational reality of cloud environments, where a role’s behavior may reveal risk that static permissions and familiar labels leave hidden.

Sources

Palo Alto Unit 42: Unmasking Cloud Identities: From Behavioral Clustering to Automated Detection