As cloud environments expand to include human, machine and autonomous agent identities, mapping the functional roles of these identities has become a significant security challenge. To address this challenge, we designed a behavioral clustering model that extracts activity patterns from cloud audit logs. By adopting a clustering-based approach to identity mapping, organizations can gain greater visibility into cloud activity and integrate these behavioral patterns into automated threat detection mechanisms.
To create our behavioral clustering model, we examined the behavior of over 40,000 identities from 125 cloud environments over a two-month period, mapping these identities to functional roles. These roles include administrators, backup services, security tooling and development and operations (DevOps).
Identifying these functional roles is rarely straightforward because resource naming conventions or assigned identity and access management (IAM) policies do not always reveal an identity’s true behavior. Attackers routinely use masquerading techniques like pre-existing permission profiles and benign labels to make malicious activity harder to detect.
To illustrate the practical application of our model, we provide an in-depth analysis of the dataset's largest cluster: administrator console users in Amazon Web Services (AWS). We also show how an identity’s behavioral patterns provide richer context for cloud threat detection.
Additionally, we demonstrate how lightweight heuristic logic can be extracted directly from the clustering map, which can be implemented in standard SQL. This allows organizations to classify functional identity roles at scale, delivering continuous operational visibility without the need to continuously run a resource-intensive machine learning pipeline.
The methodology applied in our behavioral clustering model uses unsupervised machine learning algorithms, specifically Uniform Manifold Approximation and Projection (UMAP) and Hierarchical Density-Based Spatial Clustering of Applications with Noise (HDBSCAN), to construct a reliable behavioral map. This approach automatically categorizes a vast collection of cloud identities into distinct, clustered groups.
While our research specifically focuses on AWS CloudTrail data, the methodology can be easily extended to audit logs from other cloud providers, software as a service (SaaS), Kubernetes and other environments.
Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:
Unit 42 Cloud Security Assessment is an evaluation service that reviews cloud infrastructure to identify misconfigurations and security gaps.
If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.
When it comes to accurately detecting malicious activity within cloud environments, context is key. Consider a scenario where a cloud identity enumerates all resources within your environment. Is this a security tool that frequently scans resources as part of its normal routine? Or is it a service identity that usually serves a limited purpose, such as a backup service that only interacts with a single cloud storage bucket? One of these scenarios represents normal operational activity, the other indicates a potential security breach.
This reality forces us to draw a distinction between capabilities and active behavior:
Given that thousands of identities are operating across complex cloud environments, we are left with the following questions:
Analyzing the specific cloud operations an identity invokes, as captured in AWS CloudTrail, provides a clear picture of its day-to-day behavior and role. When observing a large enough collection of identities across multiple organizations, a macro-level picture begins to emerge.
A behavioral map visualizes each identity as a distinct data point, where its invoked operations dictate its coordinates. The scatter plot in Video 1 projects a vast array of AWS identities into a two-dimensional space based on their executed operations.
Video 1. AWS identity behavioral map.
In this simplified visualization, each dot represents a unique cloud identity, projected into a two-dimensional space where proximity reflects behavioral similarity and colors reflect behavioral clusters.
This map features the 30 largest clusters found in the dataset, representing approximately 20,000 identities. Due to a limited color palette, some colors are reused across the visualization; however, each spatially separated dense region represents its own isolated cluster.
The visual datapoint clustering, along with additional quantitative metrics, indicate that cloud identities have a strong tendency to share similar behavioral traits, often mapping to the same functional roles across different organizations.
To decode the functional role associated with each behavioral cluster, we combined four analytical methods:
To illustrate these methods, we narrow our analysis to a well-isolated cluster shown in Video 2. Consisting of roughly 5,000 identities spanning over 100 cloud projects, it represents one of the largest, most dense clusters in our dataset: administrative user identities.
Video 2. Detailed view of the administrative identity cluster.
The clustering algorithm we use is hierarchical, allowing us to partition large clusters into distinct sub-behaviors. However, for the purposes of this research, we analyze the cluster at a macro level, focusing on identities operating through the AWS Management Console.
An analysis of the most frequent operations within this cluster revealed a defining characteristic: roughly 94% of the identities invoked ConsoleLogin, an AWS Management Console sign-in event, as Figure 1 shows. For comparison, fewer than 1% of identities in any other cluster performed this operation.
We can also see that around 60% of the identities in the cluster invoke additional operations associated with the default AWS Console behavior, such as GetCostAndUsage and GetCostForecast.
To look beyond raw frequency and uncover the most distinguishing operations for this group, we examined the cluster using c-TF-IDF scoring, as illustrated in Figure 2. The APIs with the highest op_score serve as behavioral markers, occurring frequently within the selected cluster while remaining relatively rare across the rest of the global dataset.
The scoring results show that operations that are automatically triggered when logging into the AWS console – such as ListNotificationHubs – receive higher scores than those based on raw frequency analysis.
To further validate the hypothesis that this is a cluster of administrative user identities, we also examined textual metadata. We looked at the entire clustering map and highlighted only the identities whose resource names contain the substring admin. In Video 3, the admin string shows a strong concentration within our selected target group.
Video 3. Global behavioral map, with identities containing the admin substring highlighted in orange.
In addition to highlighting portions of the map based on names, it is also possible to highlight them based on attributes such as specific invoked operations, usage of selected services such as S3, EC2 Lambda or any other measurable attribute.
Mining common substrings from identity names provides additional context for cluster analysis. While relying on naming conventions of a single identity alone can generate inaccurate results, recurring patterns within a cluster help explain its underlying behavior. Using a Generalized Suffix Tree, we algorithmically discovered the cluster's most frequent substrings rather than searching for specific arbitrary keywords like “admin.” Among the top results was AWSReservedSSO_AdministratorAccess_ – the default prefix generated when assigning AdministratorAccess via AWS IAM Identity Center.
Combining these quantitative methods with visual mapping allows us to confidently conclude that this cluster indeed represents administrative users operating primarily through the AWS Management Console.
Repeating this profiling process across our dataset reveals clear, reproducible clusters for both human and machine identities, some of which shown in Figure 3. We were able to identify clusters based on behavioral patterns, including:
To build this behavioral map, we constructed a multi-stage data pipeline, as illustrated in Figure 4. The pipeline consists of the following stages:
The process begins by converting raw cloud audit logs into identity vectors that capture each identity's behavior and allow us to measure the distance between them. In this format, each identity is represented as a vector containing information about the specific operations it invoked.
By treating the set of possible operations as a “vocabulary,” we can represent each identity as a boolean vector where positions are marked true if the operation was invoked within the given timeframe. Because this vocabulary spans at least 15,000 possible operations — most of which are rarely invoked — the resulting vectors are both large (high-dimensionality) and sparse (mostly filled with zeros), making them challenging to process. Figure 5 shows the data format after this vectorization process, using test identities and data.
We applied the Uniform Manifold Approximation and Projection (UMAP) algorithm to reduce high-dimensional data into a lower-dimensional space while preserving its essential structure. Considering our vector representation, we found that cosine similarity works well as the distance metric for UMAP, as it focuses on the angle between the vectors rather than their magnitude.
We ran this dimensionality reduction on the vectorized data, processing it in two parallel passes:
Figure 6 shows how the format and dimensionality of the data change after applying UMAP in the first pass. The initial large vectors consisting of over 10,000 boolean values are transformed into much smaller, dense vectors with 32 continuous values.
At this stage, we feed the dense embeddings into the Hierarchical Density-Based Spatial Clustering of Applications with Noise (HDBSCAN) algorithm, which groups the identities by detecting dense regions in the dataset.
Once every identity is assigned to a cluster, or labeled as an outlier, we can begin investigating the groups to understand their shared behaviors. This analysis focuses on their common traits and how to distinguish them from identities in other clusters. The resulting groups align closely with standard functional roles in cloud environments, such as Administration, DevOps, Security and CI/CD.
After discovering the behavioral groups using the above pipeline, we can scale this detection capability to ingest new identities and automatically determine whether they belong to a known cluster.
Instead of running the full pipeline, we train a classifier to evaluate cluster membership for groups of interest. For example, a dedicated classifier can be built to detect DevOps users, while a different classifier can detect security tools.
We found that a simple logistic regression model trained directly on the original sparse boolean vectors can accurately identify our clusters of choice. Unlike more complex machine learning models that often require additional tools to interpret outputs and decisions, the trained logistic regression model is highly interpretable. This enables us to observe the cloud operations required to infer cluster membership, along with their respective mathematical weights.
In practice, the model's inference logic calculates a weighted sum of the present operations. This means that we can determine how each cloud operation increases or decreases the likelihood that an identity belongs to a target cluster, and which operations are most important for prediction.
Because the vocabulary of possible operations is vast, assigning weights to thousands of mostly irrelevant operations would be unnecessary. To address this challenge, we used L1 regularization, also known as Lasso. This is a penalty that forces the model to reduce the coefficients of irrelevant features to absolute zero, compressing the model to focus exclusively on a small subset of critical, defining operations.
These steps result in a local approximation of our more complex clustering model. By training the classifier on specific groups, the model is essentially distilled into an indicative set of a few dozen operations paired with corresponding coefficients. This concise logic can be used to quickly infer whether an identity belongs to a DevOps, administrative or security product cluster.
Beyond being transparent and explainable, this lightweight logic is simple and efficient enough to be implemented directly within standard SQL queries. By adopting this lightweight approach, organizations can perform accurate role inference at scale, without relying on resource-intensive pipelines.
While posture management establishes the essential baseline of what an identity is permitted to do, analyzing its behavior reveals what it actually executes in production. Knowing the true functional baseline of an identity allows security teams to quickly spot deviations, flag defense evasion attempts and accelerate incident response.
By utilizing unsupervised machine learning algorithms like UMAP and HDBSCAN, we demonstrated that cloud identities naturally form distinct behavioral clusters. Rather than relying on static assigned permissions, these clusters accurately reflect an identity's true functional role within an environment — such as administrative access, CI/CD pipelines or security scanning services.
After establishing these behavioral clusters, we can efficiently map identities to their functional roles using lightweight logic distilled from our model. This logic can be implemented directly in standard SQL queries, enabling highly scalable identity classification across enterprise environments. This methodology can also be applied to audit logs from other sources of operational data, including different cloud providers, Kubernetes and SaaS.
Enriching standard telemetry with behavioral metadata adds an important layer of context, exposing high-risk anomalies that static analysis could miss, such as a compromised backup service suddenly executing administrative actions.
As cloud environments continue to grow in complexity, a context-aware approach serves as a robust blueprint for future detection strategies, offering a clear path toward more precise, efficient and proactive security operations.
Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:
Unit 42 Cloud Security Assessment is an evaluation service that reviews cloud infrastructure to identify misconfigurations and security gaps.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Table 1 shows Cortex alerts that use roles assigned from behavioral analysis and the CDR module, mapped to MITRE ATT&CK® techniques.
| Alert Name | Alert Source | MITRE ATT&CK Technique |
| AWS SSM send command attempt | XDR Analytics BIOC, Cloud Detection & Response Module (CDR) | Cloud Administration Command (T1651) |
| AWS Password Policy Discovery | XDR Analytics BIOC, Cloud Detection & Response Module (CDR) | Password Policy Discovery (T1201) |
| AWS resource discovery | XDR Analytics BIOC, Cloud Detection & Response Module (CDR) | Account Discovery: Cloud Account (T1087.004) |
| AWS web ACL deletion | XDR Analytics BIOC, Cloud Detection & Response Module (CDR) | Impair Defenses (T1562) |
| Compute activity in dormant cloud region | XDR Analytics BIOC, Cloud Detection & Response Module (CDR) | Unused/Unsupported Cloud Regions (T1535) |
| AWS Backup vault was deleted | XDR Analytics BIOC, Cloud Detection & Response Module (CDR) | Inhibit System Recovery (T1490) |
| Cloud instance creation attempt | XDR Analytics BIOC, Cloud Detection & Response Module (CDR) | Modify Cloud Compute Infrastructure: Create Cloud Instance (T1578.002) |
| AWS Lambda Cross-Account sensitive permissions configured | XDR Analytics BIOC, Cloud Detection & Response Module (CDR) | Account Manipulation: Additional Cloud Roles (T1098.003) |
| AWS IAM Role's Trusted Policy Modification Allows Cross-Account Access | XDR Analytics BIOC, Cloud Detection & Response Module (CDR) | Account Manipulation: Additional Cloud Roles (T1098.003) |
| AWS IAM Role Created with Cross-Account Access | XDR Analytics BIOC, Cloud Detection & Response Module (CDR) | Account Manipulation: Additional Cloud Roles (T1098.003) |
| AWS S3 bucket exposure via ACL / policy modification | XDR Analytics BIOC, Cloud Detection & Response Module (CDR) | Account Manipulation: Additional Cloud Roles (T1098.003) |
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。