Unmasking Cloud Identities: From Behavioral Clustering to Automated Detection Palo Alto Networks' Unit 42 built a behavioral clustering model that mapped over 40,000 cloud identities across 125 cloud environments over a two-month period into functional roles including administrators, backup services, security tooling and DevOps. The model uses unsupervised machine learning algorithms UMAP and HDBSCAN on AWS CloudTrail audit logs, and the team showed that lightweight heuristic logic extracted from the clustering map can be implemented in standard SQL to classify identity roles at scale without continuously running a resource-intensive machine learning pipeline. The work is aimed at improving cloud threat detection by distinguishing normal operational behavior from malicious activity that uses masquerading techniques such as pre-existing permission profiles and benign labels. 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 https://umap-learn.readthedocs.io/en/latest/ and Hierarchical Density-Based Spatial Clustering of Applications with Noise HDBSCAN https://hdbscan.readthedocs.io/en/latest/how hdbscan works.html , 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 https://www.paloaltonetworks.com/unit42/assess/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 https://start.paloaltonetworks.com/contact-unit42.html . | Related Unit 42 Topics | Cloud https://unit42.paloaltonetworks.com/tag/cloud-security/ , Identity https://unit42.paloaltonetworks.com/tag/identity/ , Detection https://unit42.paloaltonetworks.com/tag/threat-detection/ | 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: - What an identity can do : Identity permissions dictate the operations that a role is permitted to perform. Although the industry-standard recommendation is to enforce the principle of least privilege https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html grant-least-privilege , the reality is that many identities remain heavily over-privileged. This typically happens due to misconfigurations, a lack of visibility or simply a desire to reduce technical friction during rapid development. Attackers can exploit over-privileged identities to execute malicious operations that should have been blocked by tighter access controls. At the same time, many over-privileged identities exist in production for years without ever causing an issue. Security teams use cloud security posture management CSPM to audit assigned cloud permissions – but this is only part of the identity puzzle. - What an identity actually does : This lies within the domain of cloud detection and response CDR https://www.paloaltonetworks.com/cyberpedia/what-is-cloud-detection-and-response-cdr . Analyzing the practical evidence of operations invoked by different identities is the main focus of this article. To do this we inspect observed API activity such as authentication ConsoleLogin, GetSigninToken and discovery ListBuckets, ListRoles . To interact with the 240 services offered by AWS, there are more than 15,000 possible operations an identity can invoke. Given that thousands of identities are operating across complex cloud environments, we are left with the following questions: - Are there common behavioral patterns that identities naturally follow? - How can we reliably differentiate between the footprints of various functional roles such as administrators, DevOps, backup services and security tools? Analyzing the specific cloud operations an identity invokes, as captured in AWS CloudTrail https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html , 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: - Operation frequency: Analyzing the most frequent operations invoked within each cluster - Class-based scoring c-TF-IDF : Using c-TF-IDF scoring https://maartengr.github.io/BERTopic/api/ctfidf.html to identify operations that distinguish one cluster from the rest - Attribute-based mapping: Highlighting various portions of the map based on specific operations, services and/or string matching - Identity naming patterns: Mining common substrings and naming conventions within each cluster 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 https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-aws-console-sign-in-events.html , 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 https://docs.aws.amazon.com/aws-cost-management/latest/APIReference/API GetCostAndUsage.html and GetCostForecast https://docs.aws.amazon.com/aws-cost-management/latest/APIReference/API GetCostForecast.html . 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 https://docs.aws.amazon.com/notifications/latest/APIReference/API ListNotificationHubs.html – 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 https://en.wikipedia.org/wiki/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 https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html – 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: - DevOps - Infrastructure as Code IaaC runners - Continuous integration and continuous delivery CI/CD systems - Security products - Backup agents - Networking components - FinOps platforms To build this behavioral map, we constructed a multi-stage data pipeline, as illustrated in Figure 4. The pipeline consists of the following stages: - Cloud audit log ingestion - Pre-processing and vectorization - Dimensionality reduction - Clustering 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 https://docs.aws.amazon.com/boto3/latest/reference/services/ — 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 https://umap-learn.readthedocs.io/en/latest/ 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 https://en.wikipedia.org/wiki/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: - The first pass creates dense embeddings, which are lower-dimensional vectors for the clustering algorithm. This significantly reduces dimensions while preserving enough detail to maintain behavioral information. - The second pass compresses the original sparse vectors into a two-dimensional plot specifically for visualization, as shown in Figures 1, 2 and 5. 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 https://hdbscan.readthedocs.io/en/latest/how hdbscan works.html 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 https://en.wikipedia.org/wiki/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