Security1 publisher2 min readPublished
Unit 42 sorted 40,000 cloud identities into job roles using two months of CloudTrail
Two months of AWS audit logs from 125 environments went through UMAP and HDBSCAN to group more than 40,000 identities by what they actually did, and the classification rules that fell out run in plain SQL.
The Watch · Security desk
What happened
- Unit 42 examined more than 40,000 identities across 125 cloud environments over two months and mapped each one to a functional role from its activity in cloud audit logs.
- Unit 42 says resource naming conventions and assigned IAM policies do not always reveal an identity's true behavior, and that attackers reuse existing permission profiles and benign labels.
- Heuristic rules pulled out of the clustering map can be written in standard SQL, which Unit 42 says classifies roles at scale without a machine learning pipeline running continuously.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- capability A team that never trains a model can still label its own identities, because the expensive clustering step produced rules that reduce to a query over audit logs.
- exposure The identity an attacker wants is the one that passes both checks a defender usually runs: its permissions were signed off years ago and its label says backup.
- decision Permissions auditing and behavioral classification now compete for the same identity-security budget, and Unit 42's position is that the first cannot answer what an identity does.
The model rests on a distinction Unit 42 draws between what an identity can do and what it does [9]. Permissions are the first, and cloud security posture management tools audit them. Unit 42 calls that only part of the identity puzzle [13]. Its reason: identities stay heavily over-privileged through misconfiguration, poor visibility, or an effort to cut friction during rapid development [10], and many of those identities sit in production for years without ever causing a problem [11].
Take an identity that enumerates every resource in an account. For a security tool that scans on a schedule, that is normal operation. For a service identity that usually touches one storage bucket, Unit 42 puts the same activity in the potential-breach column [14]. The API call is identical. The identity's own history is what separates the two readings.
The sample gives a sense of the population an analyst is being asked about. More than 40,000 identities across 125 environments works out to roughly 320 per environment [17].
The clustering itself is unsupervised: UMAP to project the behavioral features, HDBSCAN to group them, with no pre-assigned role labels feeding in [5]. That is the point, given that resource naming conventions and assigned IAM policies do not always reveal an identity's true behavior [3], and that attackers routinely reuse existing permission profiles and benign labels to make malicious activity harder to spot [4]. The largest cluster in the dataset is administrator console users in AWS [6]. Other roles Unit 42 mapped include backup services, security tooling and DevOps [2].
The cost claim is the part operators can act on. Unit 42 says lightweight heuristic logic can be extracted from the clustering map and written in standard SQL, classifying functional roles at scale without continuously running a resource-intensive machine learning pipeline [7]. The heavy compute is a one-time research step. What a team runs against its own audit logs is a query.
The writeup does not say how many of the 40,000 identities behaved unlike their names or IAM policies implied [19]. Masquerading is described as routine attacker practice, not counted in this dataset [4]. The research is Palo Alto Networks' own, and the post names Cortex Cloud, Cortex XDR and XSIAM, and Idira PAM and IGA as the products that protect its customers [16].
The data is AWS CloudTrail. Unit 42 says the method extends to audit logs from other cloud providers, SaaS platforms and Kubernetes [8]. It frames the problem as one created by environments that now hold human, machine and autonomous agent identities together [15].
What to watch
- Whether Unit 42 publishes the SQL heuristics and the behavioral feature set, so teams can reproduce the classification against their own CloudTrail.
- Whether the method is tested against Entra ID or Google Cloud audit logs, where the event vocabulary differs from CloudTrail's.
- A documented incident where behavioral clustering caught a masqueraded machine or agent identity that permissions review had passed.