Password spraying, credential stuffing and the replay of stolen hashes all leave authentication events behind, and the question is whether anyone has set a line that those events cross. MITRE D3FEND names this countermeasure Authentication Event Thresholding (D3-ANET) and defines it as "Collecting authentication events, creating a baseline user profile, and determining whether authentication events are consistent with the baseline profile." It sits under the Detect tactic as a child of User Behavior Analysis. This card explains what D3-ANET measures, which ATT&CK techniques D3FEND links to it, where it is implemented, how to prove a threshold actually fires and where it is blind. It is written for detection engineers, identity teams and SOC leads; the wider behaviour analytics picture is in the UEBA Guide.
Key takeaways
- Baseline first, then a line. D3FEND describes collecting logon attributes such as device, time of day, day of week and location, building a baseline, then setting a static or dynamic threshold that new events are tested against.
- Two outcomes only. D3FEND lists the actions as Account Locking or raising an alert, so every threshold needs a decision on which one it drives, and lockout thresholds bring a denial of service risk.
- Eight ATT&CK techniques share the artefact. D3FEND links D3-ANET through the Authentication artefact to Valid Accounts, three Brute Force sub-techniques, External Remote Services, Forced Authentication, Pass the Hash and Pass the Ticket.
- Slow attacks sit under the line. D3FEND's own consideration is that activity which is not statistically different from benign activity will not meet an alert threshold, which is exactly how low and slow spraying is designed.
- Thresholds must be tested. A rule tuned once and never exercised drifts as log sources, identity providers and user populations change, so scheduled synthetic failures are part of the control.
D3-ANET at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-ANET (d3f:AuthenticationEventThresholding) |
| Tactic | Detect |
| Parent technique | User Behavior Analysis |
| Digital artefact | Authentication (D3FEND relation: analyzes Authentication) |
| Example data sources named by D3FEND | Directory server logs, VPN server logs, identity and access management logs, NAC logs, authentication client logs, Kerberos network traffic, LDAP network traffic |
| Resulting actions named by D3FEND | Account Locking, raising an alert |
| MITRE CAR analytics referenced | CAR-2013-02-008 Simultaneous Logins on a Host, CAR-2013-02-012 User Logged in to Multiple Hosts, CAR-2013-10-001 User Login Activity Monitoring |
| Main limitation | Detects statistical outliers only; attacks shaped to look normal pass |
How it works
D3FEND splits the technique into three steps: collect authentication events with their context, set a threshold either by manual configuration or by statistical analysis of deviations in historical data, then evaluate each new event against it. In practice that produces two families of rule.
- Static thresholds: fixed counts in a fixed window. Examples: more than a set number of failed logons for one account in ten minutes, failures for many distinct accounts from one source in five minutes (spraying), or one account authenticating to more hosts in an hour than it ever has. Easy to explain and test; blind to anything that stays under the count.
- Dynamic thresholds: a per-user or per-peer-group baseline, with an alert when an event or a count deviates by more than a set amount. Examples: a first logon at 03:00 for a user who never works nights, or a service account that normally touches two hosts suddenly touching forty. These catch more but need history, tuning and a way to explain an alert to an analyst.
The three MITRE CAR analytics D3FEND cites show the static style. CAR-2013-02-008 flags a host where more than one user logged in within one hour, looking at Windows logon types 2, 3, 9 and 10. CAR-2013-02-012 flags a user logged in to many machines, and names administrators and generic shared names as the expected false positives. CAR-2013-10-001 removes the 30 most frequent account names from logon events so that rare logins stand out, and warns that it will be noisy and need tuning.
Useful authentication signals on Windows and Linux
| Signal | Where it is recorded | Threshold idea (example only) |
|---|---|---|
| Event 4625 (account failed to log on) | Target host Security log | Failures per account and per source in a short window |
| Event 4771 (Kerberos pre-authentication failed) | Domain controllers | Distinct accounts failing from one client address (spraying over Kerberos) |
| Event 4776 (NTLM credential validation) | Computer authoritative for the account, the DC for domain accounts | Error 0xC0000064 (unknown user name) bursts for enumeration; 0xC000006A (bad password) bursts for guessing; 0xC0000234 (locked out) |
| Event 4740 (account locked out) | Domain controllers and member hosts | Lockouts per hour across the domain; any lockout of a privileged account; Caller Computer Name outside the domain |
| Event 4624 (successful logon) with logon type | Target host | Hosts per account per hour; success after a run of failures |
| pam_faillock tally | Linux hosts using Linux-PAM | Counts against the configured deny value within fail_interval |
| Identity provider sign-in logs | Cloud identity provider | Failures per account, per IP and per tenant; lockout error codes |
Microsoft's event 4776 guidance makes the same point D3-ANET is built on: many bad user names in a short window may indicate enumeration and many bad passwords may indicate brute force. Detailed spraying and stuffing patterns are in the Password Spraying and Credential Stuffing Defence Guide.
ATT&CK techniques D3FEND relates to D3-ANET
Relationship type: inferred only. D3FEND does not hand-map D3-ANET to ATT&CK. Each row below is a relationship D3FEND derives through a shared digital artefact: D3-ANET analyzes Authentication, and the D3FEND ontology records each technique below as producing or creating an Authentication (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | D3FEND artefact relation | What a threshold can catch |
|---|---|---|---|
| T1078 | Valid Accounts | produces Authentication | A real account logging on at an unusual time, from an unusual host or to more hosts than its baseline |
| T1110.001 | Password Guessing | produces Authentication | Many failures against one account |
| T1110.003 | Password Spraying | produces Authentication | Failures across many accounts from one source or one infrastructure range |
| T1110.004 | Credential Stuffing | produces Authentication | A burst of attempts against many accounts with a low success rate |
| T1133 | External Remote Services | produces Authentication | VPN or remote desktop gateway logons outside an account's normal pattern |
| T1187 | Forced Authentication | produces Authentication | Outbound authentication attempts to hosts that never normally receive them |
| T1550.002 | Pass the Hash | creates Authentication | NTLM logons for an account on hosts outside its baseline |
| T1550.003 | Pass the Ticket | creates Authentication | Kerberos logons for an account from hosts it does not normally use |
The relationship is a placement guide, not a coverage claim. Pass the Hash and Pass the Ticket succeed, so only a baseline of where an account normally logs on helps; a failure count never fires. Defensive detail for each technique is in the MITRE ATT&CK T1110 Brute Force Guide, the MITRE ATT&CK T1078 Valid Accounts Guide and the MITRE ATT&CK T1550 Use Alternate Authentication Material Guide.
Where it is implemented
| Implementation class | What it provides | Fits when |
|---|---|---|
| Operating system lockout policy | Static per-account thresholds. On Windows, Account lockout threshold under Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy, values 0 to 999, default 0 (never lock). On Linux, pam_faillock with deny, fail_interval and unlock_time in /etc/security/faillock.conf | Every estate, as the floor |
| Cloud identity provider protections | Built-in thresholds at the sign-in service. Microsoft Entra smart lockout, for example, defaults to 10 failed attempts and a 60 second first lockout in public cloud tenants, keeps separate counters for familiar and unfamiliar locations and does not count a repeat of one of the last three bad password hashes | Cloud sign-ins, where on-premises policy never sees the attempt |
| SIEM correlation rules | Static and windowed thresholds across sources: DCs, VPN, identity provider, NAC | You already centralise authentication logs |
| UEBA and ITDR analytics | Per-user and peer-group baselines with dynamic thresholds and risk scores | Large populations where static counts produce noise; see the ITDR Guide |
| VPN, NAC and remote access gateways | Per-account and per-source failure limits at the edge | External Remote Services is a real entry point in your estate |
Layer the thresholds. Where a cloud identity provider passes authentication through to on-premises Active Directory, Microsoft's smart lockout guidance says the cloud threshold should be lower than the AD DS threshold (AD DS at least two to three times higher) and the cloud lockout duration longer, so the cloud service absorbs spraying before it reaches domain controllers. The same layering logic applies to any identity provider in front of a directory.
Where identity fits
Service accounts and other non-human identities authenticate on a fixed pattern: the same hosts, the same times, the same protocol. That makes them the easiest accounts to baseline and the most valuable to threshold, because an interactive logon or a new source host for a service account is rarely benign. CAR-2013-10-001 does the opposite and removes the most frequent accounts, which are usually service accounts; keep a separate rule set for them rather than letting them fall out of view. The How to Find Accounts Excluded From MFA and Conditional Access guide covers finding the accounts most often targeted by spraying.
Implementation steps
- Inventory authentication sources. List every place a logon is decided: domain controllers, cloud identity providers, VPN, remote desktop gateways, Linux hosts, SaaS with local accounts. Confirm each one logs failures and successes with account, source and timestamp, and that the logs reach the SIEM.
- Turn on the auditing. On Windows, enable Audit Logon, Audit Credential Validation, Audit Kerberos Authentication Service and Audit User Account Management so 4625, 4776, 4771 and 4740 are produced.
- Collect a baseline. Gather at least several weeks of history (an example, not a standard) so weekly patterns, month-end peaks and service account schedules are visible before any dynamic threshold is set.
- Set static rules first. Per-account failures, per-source distinct accounts, lockouts per hour, and success after a run of failures. Run them in alert-only mode during a pilot.
- Decide lock or alert per rule. D3FEND names both. Lockout stops guessing but lets an attacker who knows user names lock everyone out; Microsoft's lockout threshold guidance warns of exactly that denial of service and suggests 10 as a starting point. NIST SP 800-63B Rev 4 section 3.2.2 requires verifiers to limit consecutive failed attempts on an authenticator to no more than 100, and suggests bot detection, increasing waits and risk-based controls to avoid locking out legitimate users.
- Add dynamic baselines. Hosts per account, new source per account, unusual time, and peer-group comparisons, starting with privileged and service accounts.
- Write the response. A spraying alert means credentials are being tested at scale: check for any success from the same source, force resets for accounts that succeeded, and block the source range. Account locking at scale is covered in the sibling page D3-AL Account Locking.
- Roll back safely. Keep previous rule versions. If a new threshold floods the queue or a lockout setting causes mass lockouts, revert to the previous values and keep the alert-only variant running while you tune.
How to verify it works
- Synthetic failure tests: from an approved test host, generate failed logons for a test account above each per-account threshold, and failures across a set of test accounts above the spraying threshold. Confirm the alert, its source details and the time to the on-call queue.
- Baseline deviation tests: log a test service account on to a host it never uses and confirm the dynamic rule scores it.
- Log path health: alert when the volume of 4625, 4771 or identity provider sign-in events drops to zero for a source, since a broken forwarder silences every threshold silently.
- Adversary emulation: include slow spraying in authorised exercises and record which attempt rates were and were not detected; that rate is your real detection floor.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Thresholds passing the monthly synthetic test | 100% | Proves rules and log paths work end to end |
| Authentication sources feeding the SIEM | All sources in the inventory | An unmonitored VPN or SaaS logon is a gap no threshold can fill |
| Lowest detected spraying rate in emulation | Falling over time | Shows how slow an attacker must be to stay hidden |
| Alert precision for threshold rules | Tracked monthly | Noise is the main reason thresholds get raised until useless |
| Mean time from first failure burst to analyst triage | Tracked monthly | Spraying succeeds within hours |
Limits, bypasses and failure patterns
- Low and slow: attackers who try a few passwords per account per day, rotate sources and stay below lockout are designed to sit inside the baseline. In the Microsoft Midnight Blizzard Breach 2024, the password spray used a small number of attempts to avoid lockout and came through residential proxy addresses that legitimate users also used. Cross-account and cross-tenant aggregation is the counter, along with MFA on every account, including test ones.
- Volume nobody acted on: in the 23andMe Breach 2023, a single day with over one million login attempts in July 2023 caused an outage but was not treated as a warning. A threshold that raises an alert no team owns is not a control.
- Thresholds per system only: a spray spread across VPN, identity provider and webmail stays under each system's line. Aggregate by source and by target population across systems.
- Lockout as the only response: on Windows the default threshold is 0, and where a threshold is set an attacker can lock out every known user. Pair lockout with alerting and a mass-unlock process.
- Success not watched: failure counts miss Pass the Hash, Pass the Ticket and any logon with a stolen valid password. Success-based baselines (new host, new time, new source) are required for those.
- Offline attacks: Microsoft notes the lockout threshold does not counter offline password attacks; cracking a stolen hash never produces an authentication event until the result is used.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-7 Unsuccessful Logon Attempts | Limit and act on consecutive failed logons |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring; AU-6 Audit Record Review, Analysis, and Reporting | The monitoring and analysis that thresholds sit in |
| NIST SP 800-53 Rev 5 | AC-2 Account Management | Monitoring account use for atypical activity |
| NIST SP 800-63B Rev 4 | Section 3.2.2 Rate Limiting (Throttling) | No more than 100 consecutive failed attempts per authenticator |
| NIST CSF 2.0 | DE.CM-03, DE.AE-02 | Monitoring personnel activity; analysing adverse events |
| MITRE D3FEND | User Behavior Analysis, D3-ANET | Parent and technique |
Related countermeasures
- Authorization Event Thresholding (D3-AZET): the same method applied to what an account does after it logs on. See D3-AZET Authorization Event Thresholding.
- User Geolocation Logon Pattern Analysis (D3-UGLPA): location-specific baselining. See D3-UGLPA User Geolocation Logon Pattern Analysis.
- Account Locking (D3-AL): the evict action D3FEND names as a result of D3-ANET.
- Decoy User Credential (D3-DUC): a zero-baseline account where any use is an alert. See D3-DUC Decoy User Credential.
- Multi-factor Authentication (D3-MFA): reduces the value of a guessed password. See D3-MFA Multi-factor Authentication.
Practitioner checklist
- Keep an inventory of every authentication source and confirm each one reaches the SIEM.
- Enable Windows auditing for 4625, 4771, 4776 and 4740, and collect identity provider sign-in logs.
- Run per-account, per-source and cross-account (spraying) thresholds, in alert-only mode first.
- Decide per rule whether it locks or alerts, and keep a tested mass-unlock process.
- Layer cloud identity provider lockout below on-premises directory lockout where authentication passes through.
- Baseline service and privileged accounts separately; alert on any new host or interactive logon.
- Add success-based baselines for Pass the Hash, Pass the Ticket and stolen password use.
- Test every threshold monthly with synthetic failures and record the result.
- Monitor log volume per source so a silent forwarder is noticed.
Standards and references
- MITRE D3FEND: Authentication Event Thresholding (D3-ANET)
- MITRE CAR: CAR-2013-10-001 User Login Activity Monitoring
- MITRE CAR: CAR-2013-02-012 User Logged in to Multiple Hosts
- MITRE CAR: CAR-2013-02-008 Simultaneous Logins on a Host
- NIST: SP 800-63B Rev 4 Authentication and Authenticator Management
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (AC-7)
- Microsoft Learn: Account lockout threshold
- Microsoft Learn: Event 4776, the computer attempted to validate the credentials for an account
- Microsoft Learn: Event 4740, a user account was locked out
- Microsoft Learn: Microsoft Entra smart lockout
- Linux-PAM: pam_faillock(8) manual page
Related NHI Mgmt Group resources: Account Lockout and Brute-Force Protection Guide · Impossible Travel and Anomalous Sign-In Detection · UEBA Guide · Password Spraying and Credential Stuffing Defence Guide · MITRE D3FEND Guide