An attacker using a valid account looks like the account owner at the login screen, but rarely touches the same files, mailboxes, buckets and applications the owner does. MITRE D3FEND names the countermeasure that exploits this gap Resource Access Pattern Analysis (D3-RAPA) and defines it as "Analyzing the resources accessed by a user to identify unauthorized activity." It sits under the Detect tactic as a child of User Behavior Analysis (D3-UBA). This card explains what D3-RAPA does, which ATT&CK techniques D3FEND relates it to, where it is implemented, how to prove it works and where it falls short. It is written for detection engineers and SOC leads who already know the UEBA basics in the UEBA Guide.
Key takeaways
- It compares now with normal. D3FEND describes D3-RAPA as comparing a user's recent resource access against a baseline activity model and treating large differences as possible unauthorised activity.
- The mapping is to account misuse. Through the Authentication and Authorization artefacts, D3FEND relates D3-RAPA to eight ATT&CK techniques, led by Valid Accounts (T1078), password guessing, spraying and stuffing, and pass the hash and pass the ticket.
- Object-level logging is the hard part. The analytic is only as good as the resource access events behind it: Windows 4663 needs a SACL, cloud storage needs data event logging, and SaaS needs audit logs at the right licence tier.
- Peers sharpen the signal. "First time this user touched this resource" is noisy; "first time anyone in this peer group touched it" is much rarer and usually more useful.
- Low and slow defeats it. D3FEND's own considerations warn that false positives are likely and that an attacker who stays close to normal access behaviour may never cross the threshold.
D3-RAPA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-RAPA (d3f:ResourceAccessPatternAnalysis) |
| Tactic | Detect |
| Parent technique | User Behavior Analysis (D3-UBA) |
| Digital artefacts | Authentication and Authorization (D3FEND relation: analyzes) |
| Sibling techniques | Authentication Event Thresholding, Authorization Event Thresholding, Credential Compromise Scope Analysis, Domain Account Monitoring, Job Function Access Pattern Analysis, Local Account Monitoring, Session Duration Analysis, User Data Transfer Analysis, User Geolocation Logon Pattern Analysis, Web Session Activity Analysis |
| Input data | Per-identity records of which resource was accessed, when, with which action, from where |
| Output | An anomaly score or alert when access departs from the identity's or its peers' baseline |
| Main limitation | False positives from legitimate change; misses attackers who mimic normal access |
How it works
D3FEND's knowledge base article is brief: the technique compares a user's recent activity with a baseline activity model, and major differences may indicate unauthorised activity if they are severe enough. Its references are patents from Exabeam, Sophos, Idaptive, Palo Alto Networks and IBM (now Daedalus Group) on modelling user access to computer resources. In practice an implementation has four moving parts.
- Resource events: one record per access, carrying the identity, the resource (file path, share, bucket and object, mailbox, database, SaaS record type, application), the action (read, write, delete, permission change) and the source.
- Baselines: per identity, per peer group (team, role, manager, or a cluster learned from behaviour) and per tenant, over a learning window long enough to include monthly cycles.
- Features: first access to a resource, access to a resource uncommon for the user or the peers, unusual volume or breadth (many distinct resources in a short window), unusual actions such as deletes or permission changes, and unusual time or source.
- Scoring and triage: features are combined into a priority, enriched with identity context (privilege, departure date, recent risky sign-in) and sent to the SOC queue or used to raise a risk score in the identity provider.
D3-RAPA differs from its sibling D3-JFAPA Job Function Access Pattern Analysis, which judges access against what a job function should need, and from D3-UDTA User Data Transfer Analysis, which looks at the amount of data moved rather than which resources were touched.
Where identity fits
Service accounts, cloud roles and application identities usually have the most stable access patterns in an estate: the same pipeline reads the same buckets every night. That stability makes D3-RAPA a strong control for non-human identities when their logs are in scope. A CI role that suddenly lists every bucket, or a service principal that starts reading mailboxes, is a clear deviation. Microsoft Sentinel's UEBA, for example, lists service principal and managed identity sign-in logs among its data sources (in preview), and AWS GuardDuty's S3 anomaly findings baseline each IAM entity, which includes roles. See the MITRE ATT&CK T1078 Valid Accounts Guide for how stolen machine credentials are used.
ATT&CK techniques D3FEND relates to D3-RAPA
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-RAPA. The rows below are inferred because D3-RAPA analyzes the Authentication and Authorization artefacts, and these ATT&CK techniques produce or create those artefacts in the D3FEND ontology (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | Shared artefact (D3FEND relation) | What resource access analysis can catch |
|---|---|---|---|
| T1078 | Valid Accounts | Authentication, Authorization (produces) | A legitimate account touching shares, repositories or records its owner never uses |
| T1110.001 | Password Guessing | Authentication (produces) | Post-compromise access from a guessed account that departs from its history |
| T1110.003 | Password Spraying | Authentication (produces) | Several sprayed accounts suddenly accessing the same unusual resource |
| T1110.004 | Credential Stuffing | Authentication (produces) | Reused credentials leading to access outside the account's normal set |
| T1133 | External Remote Services | Authentication, Authorization (produces) | A VPN or remote access session followed by unusual internal resource access |
| T1187 | Forced Authentication | Authentication (produces) | Later use of captured credentials against resources the account does not normally touch |
| T1550.002 | Pass the Hash | Authentication (creates) | Lateral access to hosts and shares outside the account's baseline |
| T1550.003 | Pass the Ticket | Authentication (creates) | Kerberos service access to resources the account has not used before |
Read this table as "where the analytic can help after the authentication succeeds", not as coverage of the credential attack itself. Brute force is caught earlier and more reliably by D3-ANET Authentication Event Thresholding. D3-RAPA adds value when the attacker is already in with a working credential. Technique detail is in the MITRE ATT&CK T1110 Brute Force Guide and the MITRE ATT&CK T1550 Use Alternate Authentication Material Guide.
Where it is implemented
Product classes are listed alphabetically; the named features are examples from vendor documentation, not recommendations.
| Implementation class | Example feature (from vendor docs) | Resource events used | Fits when |
|---|---|---|---|
| Cloud provider threat detection | AWS GuardDuty S3 findings such as Discovery:S3/AnomalousBehavior and Exfiltration:S3/AnomalousBehavior, produced by a machine learning model that compares each IAM entity's API activity with its own history | Cloud storage and control plane API calls | Most sensitive data sits in cloud object storage |
| Data security and file activity monitoring | File server and NAS auditing with per-user baselines of folders accessed | File system object access events | Unstructured data on file shares is the main concern |
| Insider risk management | Policies that score access to sensitive content against the user's history and HR signals | Endpoint, SaaS and file activity | An insider threat programme with HR and legal input exists |
| SIEM UEBA | Microsoft Sentinel UEBA enrichment in the BehaviorAnalytics table, with ActivityInsights fields such as FirstTimeUserAccessedResource, ResourceUncommonlyAccessedByUser, ResourceUncommonlyAccessedAmongPeers and FirstTimeResourceAccessedInTenant | Sign-in, audit, Azure Activity, AWS CloudTrail, GCP audit and Windows security logs | Logs are already centralised and analysts work in the SIEM |
| Native OS auditing plus custom analytics | Windows event 4663 "An attempt was made to access an object", generated only where the object's SACL has a matching entry, with Accesses, Object Name and Logon ID fields | File system, registry and removable storage access | You need a no-cost start on a few critical shares |
The broader product landscape and evaluation questions are in the User and Entity Behaviour Analytics (UEBA) buyer's guide and the ITDR Guide.
Implementation steps
- Choose the crown-jewel resources. Start with three to five resource sets where unauthorised access would matter most: finance shares, source repositories, customer data stores, HR records, secrets stores. Resource access analysis over everything at once produces noise and cost.
- Turn on object-level logging. Apply SACLs for read, write and delete on the chosen Windows folders and enable the Audit File System subcategory; enable data event logging for the chosen cloud buckets; confirm the SaaS audit log records record-level access at your licence tier.
- Normalise the identity. Map every event to one identity key (UPN, object ID or IAM ARN) so on-premises, cloud and SaaS activity of the same person or workload lands in one baseline. Tag non-human identities separately.
- Learn before alerting. Let the baselines build over a window that covers month-end and quarter-end cycles. Run in report-only mode and review the top anomalies weekly.
- Tune with context, not suppression. Add joiner, mover and leaver feeds so a team move does not look like an intrusion; use peer group features to reduce first-access noise; keep a short, reviewed list of known benign service accounts with expected patterns rather than excluding them.
- Connect to response. High-priority anomalies on privileged or departing users go to the SOC; lower ones raise an identity risk score that triggers step-up authentication or access review.
- Roll back safely. If alert volume overwhelms the queue, return the rule set to report-only rather than disabling logging, so baselines keep learning while tuning continues.
How to verify it works
- Synthetic anomaly test: with approval, use a test account with a stable history to access a sensitive share or bucket it has never touched, then confirm the anomaly appears with the right identity, resource and priority.
- Log completeness check: for each crown-jewel resource, confirm a recent access event exists in the SIEM. A missing SACL or a disabled data event trail silently removes the resource from analysis.
- Emulation: include "valid account, unusual resources" scenarios in authorised adversary emulation, for example a compromised user browsing shares across departments, and record whether the analytic fired.
- Retrospective replay: replay a closed incident or insider case through the analytic and check whether it would have surfaced, and how early.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Crown-jewel resources with verified access logging | 100% of the chosen set | No logs, no detection |
| Synthetic anomaly tests detected | All quarterly tests | Proves the pipeline end to end |
| Share of resource anomalies closed as benign | Falling quarter on quarter | Shows tuning and context feeds are working |
| Identities with a mature baseline, human and non-human | Rising, reported separately | Coverage of the identities attackers use |
| Median time from anomaly to triage decision | Within one working day for high priority | Anomalies lose value quickly |
Limits, bypasses and failure patterns
- Attackers who stay inside the baseline: D3FEND notes that attackers who move low and slow may not differ enough to trigger an alert. An insider or an attacker using an account that already has broad access will look normal.
- Authorised access that is still abuse: resource analysis sees which records are touched, not why. In the Coinbase Insider Breach 2025, bribed support agents used accounts they were authorised to use, so volume and record-level patterns per agent, not first-time resource access, were the relevant signal.
- Blind spots from logging gaps: Windows 4663 needs a matching SACL entry; without it there is no event and no anomaly.
- Baselines poisoned by the attacker: an intrusion that starts during the learning window becomes part of normal. Seed baselines from a period you trust and review new identities manually.
- Organisational change mistaken for compromise: reorganisations, migrations and new projects flood the queue unless HR and change feeds are joined in.
- Non-human identities excluded as noisy: teams often suppress service accounts, which are the identities with the most predictable patterns and the most standing access.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2(12) Account Monitoring for Atypical Usage | The closest control to resource access pattern analysis |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring, AU-6 Audit Record Review, Analysis, and Reporting | The monitoring and analysis that produce the alerts |
| NIST SP 800-53 Rev 5 | AC-6 Least Privilege | Reduces the resources an abused account can reach in the first place |
| NIST CSF 2.0 | DE.CM-03, DE.AE-02, DE.AE-03 | Monitoring personnel activity and technology usage; analysing and correlating adverse events |
| MITRE D3FEND | D3-UBA, D3-RAPA | Parent and technique |
Practitioner checklist
- Pick a small set of crown-jewel resources before enabling resource analytics.
- Confirm SACLs, cloud data event logging and SaaS audit logs cover those resources.
- Map every event to one identity key and tag non-human identities.
- Use peer group features, not only per-user first access.
- Feed joiner, mover and leaver data into scoring.
- Keep service accounts in scope with documented expected patterns.
- Run a quarterly synthetic anomaly test and a log completeness check.
- Pair D3-RAPA with volume analysis for authorised-but-abusive access.
Standards and references
- MITRE D3FEND: Resource Access Pattern Analysis (D3-RAPA)
- MITRE ATT&CK: T1078 Valid Accounts
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (AC-2(12))
- Microsoft Learn: Microsoft Sentinel UEBA reference
- Microsoft Learn: Event 4663, an attempt was made to access an object
- AWS: GuardDuty S3 protection finding types
Related NHI Mgmt Group resources: UEBA Guide · Insider Threat Programme Guide · Identity Threat Hunting Guide · D3-SDA Session Duration Analysis · MITRE D3FEND Guide