DC0084: Active Directory Credential Request
Requests for authentication credentials via Kerberos or other methods like NTLM and LDAP queries. Examples:
- Kerberos TGT and Service Tickets (Event IDs 4768, 4769) - NTLM Authentication Events - LDAP Bind Requests.
Analyst context for executives and security teams
Active Directory credential requests are the authentication breadcrumbs that show when accounts ask for access through Kerberos, NTLM, or LDAP binds. For leaders, this matters because identity activity is often the earliest evidence of account misuse, service disruption risk, or authentication control gaps—even though this ATT&CK data component does not define a specific attack technique by itself.
Executive priority
Prioritize confirmation that authentication request evidence is retained, searchable, and usable during incidents. This data supports identity risk decisions, SOC triage, incident scoping, audit evidence, and validation of controls around legacy authentication paths such as NTLM where applicable. The key business question is whether the organization can quickly answer: which account requested credentials or tickets, from where, for what service, and when?
Technical view
SOC and IR teams should validate visibility into Kerberos TGT requests, Kerberos service ticket requests, NTLM authentication events, and LDAP bind requests as described by ATT&CK. Because no official detection logic, platforms, tactics, or relationships are supplied for this object, treat it as a telemetry requirement rather than a standalone analytic. Useful validation should focus on field completeness, retention, normalization, and correlation with account, source, destination, and service context.
Likely telemetry
- Kerberos TGT request events, including Event ID 4768 where available
- Kerberos service ticket request events, including Event ID 4769 where available
- NTLM authentication events
- LDAP bind request records
- Authentication request metadata such as account, source, target service, timestamp, and result where collected
Detection direction
- Confirm the organization collects the credential request types named by ATT&CK: Kerberos TGT, Kerberos service ticket, NTLM, and LDAP bind activity.
- Validate parsing and normalization before writing detections; missing account, source, service, or result fields can make this data weak for investigations.
- Tune analytics with local baselines because authentication requests are high-volume and many are legitimate.
- Look for blind spots around uncollected NTLM events, LDAP bind visibility, short retention, and logs that are not forwarded to the SOC workflow.
- Use this data as supporting evidence for identity investigations rather than assuming it proves malicious behavior on its own.
Mitigation priorities
- Establish reliable collection and retention for the authentication request evidence described by ATT&CK.
- Ensure SOC and IR teams can search and correlate credential request records by account, source, service, and time.
- Review whether legacy or alternate authentication methods such as NTLM and LDAP binds are visible and governed according to organizational policy.
- Document logging coverage and retention as compliance and incident readiness evidence.
- Prioritize remediation of visibility gaps before relying on detections that require this data component.
Analyst notes and limits
This is a data component, not a technique. Its main defensive value is enabling identity-focused detection, investigation, and auditability. The supplied ATT&CK object provides examples of relevant authentication evidence but does not provide detection logic or relationship context to specific techniques.
ATT&CK supplies no official detection text, platforms, tactics, aliases, labels, or relationships for this object. Any assessment of coverage, risk, or detection quality requires local environment evidence and log configuration details.
Active Directory Credential Request
Requests for authentication credentials via Kerberos or other methods like NTLM and LDAP queries. Examples:
- Kerberos TGT and Service Tickets (Event IDs 4768, 4769) - NTLM Authentication Events - LDAP Bind Requests.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 3229c4f10d06… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DC0084Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.