1. Executive summary
This item is not a vulnerability, breach or campaign report: it is a defensive research publication from Unit 42 describing a behavioural-clustering methodology for mapping the functional roles of cloud identities from audit logs. The authors analysed over 40,000 identities across 125 cloud environments over a two-month period, using UMAP and HDBSCAN to group identities into functional roles (administrators, backup services, security tooling, DevOps), with AWS CloudTrail as the primary data source. No CVE, CVSS score, CISA KEV entry or exploitation state applies — there is no vulnerability in scope and no threat actor is named or attributed. The bottom-line risk to EMEA financial services clients is indirect but material: the paper's core premise is that IAM policy and resource naming do not reliably reveal what an identity actually does, which is precisely the gap attackers exploit through masquerading (pre-existing permission profiles, benign labels) in cloud environments that many institutions cannot currently baseline. Clients with immature cloud identity baselining should treat this as a detection-engineering input, not an incident.
2. Regulatory framing
No specific DORA/NIS2 article is directly engaged by this item. This is a defensive methodology publication with no incident, no third-party failure, no supply-chain event and no exploitation to report; mapping it to incident-management or reporting articles would be compliance-checkbox padding. The relevance to DORA Art. 24 (digital operational resilience testing) and NIS2 Art. 21(2)(d) (supply chain security measures) is at most thematic and does not change a client's obligations on the basis of this item alone.
3. Technical analysis & attack chain
This item contains no attack chain. It is a detection methodology. The following describes what the research actually did and what it claims, from source facts only.
Problem statement. The authors frame cloud identity detection as a context problem. An identity enumerating all resources in an environment is either a security tool performing routine scanning or a compromised service identity behaving outside its normal scope — the same API activity, two very different meanings. The paper draws an explicit distinction between capability (what an identity's permissions allow it to do) and active behaviour (what it actually does). The authors state that while least privilege is the industry-standard recommendation, many identities remain heavily over-privileged in practice, attributing this to misconfigurations, lack of visibility, and a desire to reduce technical friction.
Method. The model is built on unsupervised machine learning:
- UMAP (Uniform Manifold Approximation and Projection) for dimensionality reduction of identity activity patterns.
- HDBSCAN (Hierarchical Density-Based Spatial Clustering of Applications with Noise) for clustering the reduced representation into distinct groups.
Input data is activity patterns extracted from cloud audit logs. The study population was over 40,000 identities drawn from 125 cloud environments over a two-month period. Identities were mapped to functional roles including administrators, backup services, security tooling, and DevOps.
Scope and portability. The research focuses specifically on AWS CloudTrail data. The authors state the methodology can be extended to audit logs from other cloud providers, SaaS, Kubernetes and other environments — this is a claim of portability, not a demonstration of it, and should be treated as such.
Operationalisation. The paper's most actionable claim is that lightweight heuristic logic can be extracted directly from the clustering map and implemented in standard SQL. This allows functional role classification at scale without continuously running a resource-intensive ML pipeline — i.e. the expensive clustering is a one-off exercise whose output is distilled into cheap, continuously-runnable queries.
Worked example. The paper provides an in-depth analysis of the dataset's largest cluster: administrator console users in AWS. No specific API calls, event names, field names, thresholds or SQL is reproduced in the source material provided to us.
Adversary relevance (as stated by the source). The authors state that attackers routinely use masquerading techniques — pre-existing permission profiles and benign labels — to make malicious activity harder to detect. This is presented as motivation for the methodology, not as analysis of a specific actor, campaign or toolset. No threat actor, malware family or intrusion set is named anywhere in the source.
Confidence caveat. All quantitative claims in this section (40,000+ identities, 125 environments, two-month window, cluster composition) are single-sourced to Unit 42 and are not independently corroborated. The methodology has not been validated by a third party in the material provided. Treat the numbers as vendor-reported.
4. Mitigation & containment
There is no containment action here — nothing has been compromised. The following are process and detection-engineering controls the source material actually supports.
P1 — within 24h
- Confirm AWS CloudTrail coverage is complete and centralised for every account in scope, including organisation trails and any accounts currently excluded. The entire methodology depends on audit-log completeness; a gap in CloudTrail coverage is a blind spot in any identity baseline you attempt to build.
- Inventory cloud identities with administrative or console access and flag those whose IAM policy grants materially broader permissions than their observed activity requires. The source's central finding is that policy does not describe behaviour — do not accept an IAM policy review as evidence of what an identity does.
P2 — within 72h
- Establish a behavioural baseline for high-value identity classes (administrator console users, backup services, security tooling, DevOps) using at least a multi-week observation window. The source used two months; shorter windows will produce noisier clusters.
- Prioritise the administrator console user population for baselining, as this was the largest cluster in the source dataset and is the highest-impact role if impersonated.
- Where you have detection engineering capacity, evaluate whether the clustering output can be distilled into SQL heuristics against your existing log store, per the source's stated approach, rather than standing up a continuous ML pipeline.
P3 — within 7 days
- Review identities whose naming conventions or labels imply a narrow function (e.g. a backup service) but whose permissions are broad. The source explicitly identifies benign labels as a masquerading vector.
- Reduce over-privilege identified in the P1 inventory, prioritising identities that combine broad permissions with low observed activity diversity.
- If you lack in-house capability to build and maintain the clustering model, the source names Unit 42 Cloud Security Assessment as a commercial evaluation service, and lists Cortex Cloud, Cortex XDR/XSIAM, Idira PAM and Idira IGA as vendor products. These are vendor claims about their own portfolio; we have not assessed them.
5. Indicators of compromise
No indicators of compromise available in the source material. The source describes no malware, no atomic artefacts, no hashes, no domains, no IPs, no file paths and no registry keys.
The source does describe observable behaviours. These are single-sourced to Unit 42 and are conceptual rather than operationalised — the source does not name the specific API calls or log fields that would evidence them. Verify against your own CloudTrail schema before building detections.
Behavioural indicators
| behaviour | where to observe | confidence |
|---|---|---|
| An identity enumerating all resources within an environment, where that identity's normal pattern is narrow (e.g. a backup service that only interacts with a single storage bucket) | Cloud audit logs (AWS CloudTrail in the source's scope) | single-sourced; conceptual, not operationalised |
| An identity operating outside the activity pattern of its functional role cluster (administrator, backup service, security tooling, DevOps) | Cloud audit logs, compared against a behavioural baseline | single-sourced; conceptual, not operationalised |
| An identity whose IAM policy grants broad capability but whose observed activity is narrow — or the inverse | IAM policy export correlated with audit-log activity | single-sourced; conceptual, not operationalised |
| Use of pre-existing permission profiles and benign resource/identity labels to blend malicious activity into normal patterns | IAM configuration review plus audit-log activity | single-sourced; stated as attacker technique, no actor named |
6. Detection
Insufficient indicators to author detection rules.
The source provides no distinctive strings, command-line flags, mutex names, scheduled-task or service names, file names or paths, registry keys, or hard-coded values. It names no API operations, no log field names and no thresholds. Any YARA or Sigma rule authored from this material would detect reporting about the methodology rather than the behaviour it describes, and would not match anything in production.
7. Sources
- Unit 42 (Palo Alto Networks), "Unmasking Cloud Identities: From Behavioral Clustering to Automated Detection", https://unit42.paloaltonetworks.com/behavioral-clustering-map-to-cloud-identities/, published 2026-09-14.
8. Adverse Trace position
We assess this as an informational, low-urgency item with no direct client impact: there is no vulnerability, no exploitation in the wild, no CISA KEV entry, no CVSS score and no named threat actor, so no severity rating applies and we will not manufacture one. Its value is as a detection-engineering input for institutions that cannot currently answer "what does this cloud identity actually do?" — a question the source argues, and our own cloud incident experience supports, is not answered by IAM policy review alone. The material is single-sourced to a vendor with commercial products in the adjacent space, and the quantitative claims (40,000+ identities, 125 environments) are unverified by any third party; we flag that explicitly rather than presenting the numbers as established fact. We will not issue a follow-up unless the methodology is operationalised into published detection content, a named actor is linked to the masquerading techniques described, or a client reports an intrusion that this approach would have detected. Clients wanting to act on this should start with CloudTrail coverage completeness and an administrator-console-identity baseline — those two steps are prerequisites for everything else the paper describes.
Published via PulseTrace — Adverse Trace threat intelligence.