An attacker holding a valid account passes every logon check, so the evidence of misuse is in what the account then tries to read, change and delete. MITRE D3FEND names this countermeasure Authorization Event Thresholding (D3-AZET) and defines it as "Collecting authorization events, creating a baseline user profile, and determining whether authorization events are consistent with the baseline profile." It sits under the Detect tactic as a child of User Behavior Analysis, and is the post-logon counterpart of D3-ANET Authentication Event Thresholding. This card covers what D3-AZET measures, the ATT&CK techniques D3FEND relates to it, where the signals come from on Windows, Kubernetes and cloud platforms, how to test the thresholds and where they fail. It is for detection engineers, data security teams and SOC leads; the general analytics model is in the UEBA Guide.
Key takeaways
- It watches decisions, not logons. D3FEND's scope includes successful and failed authorization attempts and permission events such as viewing, editing, deleting and creating files and databases.
- Denials and volume both matter. A burst of access-denied results shows an account probing beyond its rights; a surge of granted reads shows an account using its rights at an abnormal scale.
- D3FEND links two ATT&CK techniques. Through the Authorization artefact, D3-AZET relates to Valid Accounts (T1078) and External Remote Services (T1133).
- Insiders and stolen accounts look the same here. Both act within granted permissions, which is why peer comparison and per-account baselines carry most of the value.
- Logging choices decide coverage. Object access auditing, cloud data events and Kubernetes audit policy are often off or minimal by design, and a threshold cannot fire on events never recorded.
D3-AZET at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-AZET (d3f:AuthorizationEventThresholding) |
| Tactic | Detect |
| Parent technique | User Behavior Analysis |
| Digital artefact | Authorization (D3FEND relation: analyzes Authorization); D3FEND also defines Cloud Service Authorization as a sub-artefact |
| Events in scope per D3FEND | Successful and failed authorization attempts; permission events such as viewing, editing, deleting and creating files and databases |
| Threshold types | Static or dynamic |
| MITRE CAR analytics referenced | CAR-2013-09-003 SMB Session Setups, CAR-2013-02-012 User Logged in to Multiple Hosts |
| Main limitation | Misuse that matches the statistical profile of normal work does not cross the threshold |
How it works
D3FEND describes a baseline user profile built from authorization events, with events that deviate beyond a static or dynamic threshold flagged for action. The two patent references describe the same idea in product form: the Idaptive patent compares behaviour profiles that include file access and authorization changes, and the Exabeam patent builds histograms of user behaviour after an initial training period and scores deviations as risk. In practice there are three useful rule shapes.
- Denial bursts: an account or workload receiving many access-denied results in a short window, especially across many distinct resources. This is the signature of an account exploring what its stolen credentials can reach.
- Volume and breadth outliers: an account reading far more records, files, objects or tables than its own history or its peer group. Successful access is the harder and more important case.
- First-time sensitive actions: an account exercising a permission it holds but has never used, such as changing an access control list, deleting objects or reading a restricted share.
CAR-2013-09-003, one of D3FEND's references, extracts the user name and target host from SMB session setups on port 445 to track which accounts touch which hosts. MITRE CAR itself maps that analytic to Forced Authentication (T1187) with low coverage and to D3FEND's IPC Traffic Analysis, so treat it as an example of building per-account access data rather than a ready AZET rule.
Authorization signals by platform
| Platform | Signal | Notes |
|---|---|---|
| Windows file servers | Event 5145, network share object access check (Audit Detailed File Share) | Records requested rights and an Access Check Results field showing which ACE granted or denied each right. Failures are logged only for share-level denials, not NTFS denials. Microsoft advises watching WriteData, DELETE, WRITE_DAC and WRITE_OWNER, especially on failures. Volume on busy servers is high |
| Windows hosts | Object access events (for example 4663) where a SACL is set | Only objects with auditing configured produce events, so place SACLs on sensitive paths rather than everywhere |
| Kubernetes | API server audit log | Access is denied by default; an overall deny verdict returns HTTP 403 Forbidden. The audit policy decides which requests and stages are recorded |
| Cloud provider APIs | API audit events with error fields | In AWS CloudTrail, for example, errorCode and errorMessage appear when a request fails, including authorization failures, alongside userIdentity, sourceIPAddress and eventName |
| Databases and SaaS | Native audit logs of object reads, permission errors and record exports | Often the only place the volume of records viewed is visible |
ATT&CK techniques D3FEND relates to D3-AZET
Relationship type: inferred only. D3FEND does not hand-map D3-AZET to ATT&CK. The rows below are derived through the shared Authorization artefact: D3-AZET analyzes Authorization, and the D3FEND ontology records both techniques as producing an Authorization (D3FEND 1.6.0, checked November 2026). Both IDs were checked against ATT&CK v20.
| ATT&CK ID | Technique | D3FEND artefact relation | What an authorization threshold can catch |
|---|---|---|---|
| T1078 | Valid Accounts | produces Authorization | A legitimate account suddenly reading many more resources, hitting new sensitive objects, or collecting denials across systems it never used |
| T1133 | External Remote Services | produces Authorization | A remote access session followed by access to resources outside the account's normal set |
Many techniques that follow a valid logon, such as cloud storage collection, leave authorization events too, but D3FEND does not list them for D3-AZET and they are not mapped here. The defensive detail for the two linked techniques is in the MITRE ATT&CK T1078 Valid Accounts Guide and the T1133 External Remote Services Defensive Guide.
Where it is implemented
| Implementation class | What it provides | Fits when |
|---|---|---|
| SIEM correlation rules | Static counts of denials and accesses per account, per resource and per window | Authorization logs are already centralised and the team writes its own rules |
| UEBA and ITDR analytics | Per-account and peer-group baselines, first-time-access scoring, risk aggregation across sources | Many accounts with varied roles where static counts produce noise |
| Data security and database activity monitoring tools | Record-level and query-level access baselines on data stores | The main risk is bulk reading of regulated data |
| Cloud provider threat detection services | Built-in anomaly findings on API usage and access-denied patterns | Cloud control planes and object storage carry the crown jewels |
| Application audit logging | Business-level events: records viewed, exports, permission changes | Support, CRM and back-office tools where insiders work within their rights |
Where identity fits
Workloads, service accounts and automation tokens make the clearest AZET baselines, because a given workload calls the same APIs on the same resources every day. A pipeline token that starts listing buckets, or a service principal that receives a run of access-denied errors on resources it never touched, is a strong signal of a leaked credential being explored. The ITDR Guide covers identity-centred detection tooling that applies these baselines to non-human identities.
Implementation steps
- Choose the resources that matter. List the shares, buckets, databases, clusters and SaaS objects whose misuse would be a reportable incident. AZET is too noisy to apply everywhere at once.
- Turn on the right logging. Set SACLs and Audit Detailed File Share on sensitive Windows paths, enable data-level API events for sensitive cloud storage, set a Kubernetes audit policy that records requests to secrets and role bindings, and enable record-access auditing in key applications.
- Build baselines per account and per peer group. Gather several weeks of history (an example, not a standard). Group accounts by role or team so a new joiner is compared to peers rather than to an empty history.
- Start with denial rules. Denials per account across distinct resources in a short window are quick to build and rarely benign at volume. Run in alert-only mode during a pilot.
- Add volume and first-use rules. Records or objects read per day against the account's own baseline and its peers; first use of a sensitive permission such as an ACL change.
- Tune by fixing sources. Backups, indexing services and scanners produce huge authorization volumes; give them their own baselines rather than raising the global threshold.
- Write the response and roll back. An AZET alert calls for confirming the business reason with the account owner, checking the logon source, and suspending access if the reason does not hold. Version every rule so a threshold that floods the queue can be reverted to the previous value while tuning continues.
How to verify it works
- Synthetic denial test: with an approved test account, request access to a set of resources it cannot reach and confirm the denial burst alert fires with account, source and resource list.
- Synthetic volume test: with a test account that holds read rights to a test share or bucket, read far more objects than its baseline and confirm the volume rule scores it.
- Logging coverage check: for each sensitive resource on the list, confirm its audit events arrived in the last day. A missing SACL or a disabled data event setting is invisible otherwise.
- Emulation: include post-logon discovery and collection in authorised exercises and record which steps raised AZET alerts.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Sensitive resources with authorization logging confirmed | All resources on the list | Coverage gaps are the main failure mode |
| AZET rules passing the monthly synthetic test | 100% | Proves rules and log paths work end to end |
| Alert precision after tuning | Tracked monthly | Noisy rules get disabled |
| Service accounts and workloads with their own baseline | Rising quarter on quarter | Non-human identities give the cleanest signal |
| Time from alert to owner confirmation | Tracked monthly | Bulk reading completes quickly |
Limits, bypasses and failure patterns
- Misuse inside the normal pattern: D3FEND's own consideration is that activity not statistically different from benign activity does not meet the threshold. In the Coinbase Insider Breach 2025, bribed support agents copied records within their normal permissions. Records viewed with no related ticket, and record counts far above peers, are the signals that could separate that activity from normal work.
- Logging only failures: denial rules catch exploration but miss an account that already has the rights it needs. Volume baselines on granted access are needed too.
- Partial denial logging: on Windows, event 5145 records denials at the share level only, not at the NTFS level, so denial counts from file servers understate reality.
- Slow collection: an attacker who reads a little every day for months stays within a daily threshold. Add longer windows (weekly and monthly totals) alongside daily ones.
- Global thresholds: one threshold for all accounts is either too high for clerks or too low for backup software. Baseline per account or per peer group.
- Over-broad permissions: if every account can read everything, there are no denials to count and every read looks authorised. Thresholding complements least privilege and access reviews; it does not replace them.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2(12) Account Monitoring for Atypical Usage | The control enhancement that describes this technique most closely |
| NIST SP 800-53 Rev 5 | AC-6(9) Log Use of Privileged Functions; AU-12 Audit Record Generation | Producing the authorization events the thresholds need |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring; SI-4(16) Correlate Monitoring Information; AU-6 Audit Record Review, Analysis, and Reporting | Analysis and correlation of the events |
| NIST CSF 2.0 | DE.CM-03, DE.AE-02 | Monitoring personnel activity; analysing adverse events |
| MITRE D3FEND | User Behavior Analysis, D3-AZET | Parent and technique |
Related countermeasures
- Authentication Event Thresholding (D3-ANET): the logon-side companion. See D3-ANET Authentication Event Thresholding.
- Resource Access Pattern Analysis (D3-RAPA): baselines of which resources an account touches. See D3-RAPA Resource Access Pattern Analysis.
- Job Function Access Pattern Analysis (D3-JFAPA): comparing access with what a role should need. See D3-JFAPA Job Function Access Pattern Analysis.
- Credential Compromise Scope Analysis (D3-CCSA): what to do once an alert suggests an account is compromised. See D3-CCSA Credential Compromise Scope Analysis.
Practitioner checklist
- Keep a list of sensitive resources and confirm each one produces authorization events.
- Use SACLs and Audit Detailed File Share on sensitive Windows paths only, to control volume.
- Collect cloud API audit events with their error fields, and data events for sensitive storage.
- Set a Kubernetes audit policy that records access to secrets and role bindings.
- Run denial-burst rules first, then volume and first-use rules.
- Baseline per account and per peer group; give backup and scanning services their own baselines.
- Add weekly and monthly windows to catch slow collection.
- Test each rule monthly with a synthetic denial and a synthetic volume run.
- Route alerts to an owner who can confirm the business reason quickly.
Standards and references
- MITRE D3FEND: Authorization Event Thresholding (D3-AZET)
- MITRE CAR: CAR-2013-09-003 SMB Session Setups
- MITRE CAR: CAR-2013-02-012 User Logged in to Multiple Hosts
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (AC-2(12))
- Microsoft Learn: Event 5145, a network share object was checked to see whether client can be granted desired access
- Kubernetes: Authorization
- AWS: CloudTrail record contents
Related NHI Mgmt Group resources: UEBA Guide · ITDR Guide · Insider Data Theft Guide · MITRE ATT&CK T1078 Valid Accounts Guide · MITRE D3FEND Guide