Teams buy behaviour analytics as one product and then cannot say which behaviours it actually watches, which data feeds each model, or why the alerts it raises are worth acting on. MITRE D3FEND breaks the field into a parent technique, User Behavior Analysis (D3-UBA), in the Detect tactic, with eleven child techniques, each tied to a specific digital artefact such as an authentication event, an authorisation event or a domain user account. This guide uses that structure as a build plan: what each child detects, the data it needs, which children to build first, how they combine into useful detections and response, and where they fail. It is written for detection engineers, identity security teams and SOC leads. It does not repeat the product and baselining material in the UEBA Guide; each child technique has its own deep page linked below.
Key takeaways
- D3-UBA is eleven separate analytics, not one model. They range from deterministic account change monitoring to statistical baselines of data transfer and peer-group access.
- Build deterministic children first. Domain and local account monitoring need no baseline and catch high-value persistence; statistical children need weeks of clean data.
- Each child depends on one artefact. If you do not collect authentication, authorisation or resource access events with a stable identity, the matching children cannot work.
- The value is in combination. A single geolocation anomaly is noise; the same identity also exceeding its data transfer baseline is an incident.
- Credential Compromise Scope Analysis turns detection into response. It is the child that tells responders which credentials to evict.
What D3FEND means by User Behavior Analysis
D3FEND takes its definition of D3-UBA from the Gartner description of user behaviour analytics: a process for detecting insider threats, targeted attacks and financial fraud by looking at patterns of human behaviour and applying algorithms and statistical analysis to find meaningful anomalies. It records the synonym Credential Monitoring, and in the ontology D3-UBA is a direct child of Defensive Technique that "enables Detect". The technique overview adds a useful distinction: some techniques learn patterns, such as repeated logins from one IP address or large downloads, while others match explicit definitions of bad behaviour.
Despite the name, several children apply to any account, and the artefacts they analyse (authentication, authorisation, credentials, user accounts) belong equally to service accounts and workload identities. The section on non-human identities below covers what changes.
The child techniques
Every child of D3-UBA in the D3FEND ontology, grouped by what it watches, with the artefact relation D3FEND records and a typical data source. Data sources are examples.
| Technique | What it detects | D3FEND artefact relation | Typical data source | Needs a baseline? |
|---|---|---|---|---|
| D3-DAM Domain Account Monitoring | Creation of, or changes to, domain user accounts | monitors Domain User Account | Directory audit events, for example Windows 4720, 4738, 4765 | No |
| D3-LAM Local Account Monitoring | Unauthorised activity in local accounts | analyzes Local User Account | Host account audit events, endpoint queries | No |
| D3-ANET Authentication Event Thresholding | Authentication activity inconsistent with a user profile | analyzes Authentication | Identity provider and directory sign-in logs | Thresholds or baseline |
| D3-UGLPA User Geolocation Logon Pattern Analysis | Logons from unusual locations | analyzes Network Traffic | Sign-in logs with source IP and geolocation | Yes |
| D3-SDA Session Duration Analysis | Sessions of unusual length | analyzes Authentication, Authorization | Session start and end events, VPN and remote access logs | Yes |
| D3-AZET Authorization Event Thresholding | Authorisation activity inconsistent with a user profile | analyzes Authorization | Access decision logs, privilege use events | Thresholds or baseline |
| D3-JFAPA Job Function Access Pattern Analysis | Access unlike others in the same role or department | analyzes Authorization | Access logs joined to HR attributes | Peer group |
| D3-RAPA Resource Access Pattern Analysis | Unusual resources accessed by a user | analyzes Authentication, Authorization | File, application and database access logs | Yes |
| D3-UDTA User Data Transfer Analysis | Unusual amounts of data moved | analyzes Resource Access | Proxy, cloud storage and network flow logs | Yes |
| D3-WSAA Web Session Activity Analysis | Changes in web session behaviour against a baseline or known malicious patterns | analyzes Web Resource Access | Application and web server logs | Baseline or signatures |
| D3-CCSA Credential Compromise Scope Analysis | Which credentials may be compromised, from a system's logon history | analyzes Credential | Logon history on the affected host | No (investigative) |
Windows event IDs are from the Audit User Account Management subcategory, which also records 4722 (enabled), 4725 (disabled), 4726 (deleted) and 4740 (locked out). Equivalent records exist in Linux audit logs and cloud provider audit trails.
Choosing and sequencing the children
D3FEND does not set an order. The phases below are NHI Mgmt Group's recommendation, ordered by data readiness and alert precision.
- Phase 1, account state (D3-DAM, D3-LAM). Alert on new accounts, privileged group changes, SID History additions and re-enabled accounts. These are deterministic, low volume and catch persistence such as T1136.002 Domain Account and T1098 Account Manipulation. Test by creating and modifying a test account and confirming each alert.
- Phase 2, authentication thresholds (D3-ANET). Start with fixed thresholds on failures per account and per source, and with MITRE CAR-style rules such as multiple users logging into one host within an hour (CAR-2013-02-008), which flags possible T1078 misuse. Exclude terminal servers and jump hosts explicitly.
- Phase 3, authentication baselines (D3-UGLPA, D3-SDA). Once sign-in logs carry a stable user identifier and source IP, add location and session length baselines. Run in report-only mode for at least one business cycle before alerting.
- Phase 4, access and data (D3-AZET, D3-RAPA, D3-UDTA, D3-WSAA). These need resource-level logs, which are the most expensive to collect. Prioritise crown-jewel systems and cloud storage first.
- Phase 5, peer groups (D3-JFAPA). Requires reliable HR attributes such as job function and department. Build only when the joiner, mover and leaver data is accurate, or the model learns from wrong groups.
- Throughout, response scoping (D3-CCSA). Build the logon history query and the credential-to-host map before you need them, so that a confirmed alert flows straight into MITRE D3FEND Credential Eviction Implementation Guide work.
Combining children into detections
| Combination | Scenario it raises confidence on |
|---|---|
| D3-UGLPA + D3-ANET | Unfamiliar location immediately after a burst of failed attempts: password spraying followed by success (T1110.003) |
| D3-DAM + D3-AZET | New or changed account that then exercises privileges it never used before |
| D3-RAPA + D3-UDTA | New resources accessed and unusual volume moved: collection and exfiltration (T1567.002) |
| D3-SDA + D3-WSAA | Long-lived session with changed behaviour: possible stolen session cookie (T1550.004) |
| D3-JFAPA + D3-RAPA | Access outside the peer group to sensitive repositories: insider or compromised account (T1213) |
Small and large organisations
- Small teams: implement Phases 1 and 2 with the SIEM or identity provider you already have; built-in risky sign-in features usually cover D3-UGLPA. See the Impossible Travel and Anomalous Sign-In Detection guide.
- Large or regulated organisations: Phases 4 and 5 justify a dedicated analytics platform, data engineering for resource logs and an insider risk process with HR and legal. See the Insider Threat Programme Guide.
Where identity fits: service accounts and workloads
Machine identities are easier to baseline than people: a service account should authenticate from the same hosts, at the same rhythm, to the same resources. That makes D3-ANET, D3-RAPA and D3-UGLPA highly precise for non-human identities, often more precise than for humans. Two adjustments help. Use the source host or workload rather than geolocation as the location feature, and treat any interactive logon by a service account as an alert in its own right. Peer-group analysis (D3-JFAPA) does not apply as written, because machine identities have no job function; group them by owning application instead. See ITDR Guide for the wider identity detection programme.
ATT&CK techniques D3FEND relates to User Behavior Analysis
The D3FEND page for D3-UBA lists offensive techniques across almost every ATT&CK tactic, derived from the artefacts its children analyse, and labels them inferred and experimental. The selection below groups the most relevant by tactic; all IDs are current in ATT&CK v20. Treat it as a test list, not as coverage.
| ATT&CK tactic | Techniques (selection from the D3FEND page) | Children most likely to see it |
|---|---|---|
| Initial Access, Persistence, Privilege Escalation, Stealth | T1078.002 Domain Accounts, T1078.003 Local Accounts | D3-ANET, D3-UGLPA, D3-LAM |
| Persistence | T1136.001 Local Account, T1136.002 Domain Account, T1098.001 Additional Cloud Credentials, T1098.003 Additional Cloud Roles | D3-DAM, D3-LAM, D3-AZET |
| Credential Access | T1110.003 Password Spraying, T1110.004 Credential Stuffing, T1558.003 Kerberoasting, T1003.006 DCSync | D3-ANET, D3-AZET, D3-CCSA |
| Discovery | T1087.001 Local Account, T1087.002 Domain Account | D3-RAPA, D3-AZET |
| Lateral Movement | T1021.001 Remote Desktop Protocol, T1550.004 Web Session Cookie | D3-ANET, D3-SDA, D3-WSAA |
| Privilege Escalation, Stealth | T1134.001 Token Impersonation/Theft | D3-AZET |
| Exfiltration | T1567.002 Exfiltration to Cloud Storage, T1048 Exfiltration Over Alternative Protocol | D3-UDTA |
See the MITRE ATT&CK T1078 Valid Accounts Guide and the MITRE ATT&CK T1110 Brute Force Guide.
Detection and measurement
Measure the programme per child, not as one score, so gaps are visible. Metrics we suggest:
- Child coverage: number of the eleven children running in alert mode with a named owner.
- Data readiness: share of in-scope identities whose authentication, authorisation and resource events reach the analytics platform with a consistent identifier.
- Alert precision per child: alerts confirmed as true positives divided by alerts raised, reviewed monthly.
- Emulation detection rate: share of the ATT&CK behaviours in the table that, when safely emulated, produced an alert.
- Time from alert to scoped credential list: how quickly D3-CCSA output reaches responders.
- Non-human coverage: share of service accounts with an authentication baseline.
Framework mapping
| Framework | Reference | Link to D3-UBA |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-2(12) Account Monitoring for Atypical Usage | The closest single control to the family |
| NIST SP 800-53 Rev. 5 | AU-6 Audit Record Review, Analysis, and Reporting; SI-4 System Monitoring; AC-7 Unsuccessful Logon Attempts | Analysis, monitoring and threshold children |
| NIST CSF 2.0 | DE.CM-03, DE.AE-02 | Personnel activity monitored; adverse events analysed |
| CIS Controls v8.1 | Control 8 Audit Log Management, Control 5 Account Management | Log collection and account oversight |
| MITRE CAR | CAR-2013-02-008, CAR-2013-02-012, CAR-2016-04-004 | Analytics D3FEND cites as references for children |
Common failure patterns
- Starting with machine learning. Teams deploy baselines before account monitoring exists, and miss the account creation that a simple rule would have caught.
- Inconsistent identity keys. The same person appears as an email, a UPN and a SAM account name across sources, so baselines fragment and combinations never join.
- Service accounts excluded as noisy. Excluding them removes the identities with the most predictable, and therefore most detectable, behaviour.
- Peer groups built on stale HR data. D3-JFAPA learns from wrong departments and either floods or goes silent.
- Alerts with no route to eviction. Detections fire, but no one can quickly list the credentials to revoke.
Practitioner checklist
- Map each of the eleven D3-UBA children to a data source, owner and status.
- Turn on account management auditing on directories and hosts and alert on D3-DAM and D3-LAM events first.
- Normalise identities to one key across sign-in, access and data transfer logs.
- Run statistical children in report-only mode for a business cycle before alerting.
- Baseline service accounts by host and resource and alert on interactive logons.
- Build correlation rules that combine at least two children before paging an analyst.
- Prepare D3-CCSA queries so a confirmed alert yields a credential list for eviction.
- Emulate the mapped ATT&CK behaviours quarterly (example cadence) and track detection rate per child.
Standards and references
- MITRE D3FEND: User Behavior Analysis
- MITRE CAR: CAR-2013-02-008 Simultaneous Logins on a Host
- Microsoft Learn: Audit User Account Management
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- CIS: CIS Controls v8.1
Related NHI Mgmt Group resources: MITRE D3FEND Guide · UEBA Guide · Entra ID Sign-In and Audit Log Detection Guide · MITRE D3FEND Credential Eviction Implementation Guide