Safeguard
Application Security•

Detecting and Mitigating Exploitation for Credential Access (T1212)

Attackers exploit flaws in authentication systems to steal or forge credentials. What MITRE documents for T1212, which events to watch, and how patching and design reduce risk.

Safeguard Security Team
4 min read

Exploitation for Credential Access (MITRE ATT&CK T1212) is the use of software vulnerabilities to collect credentials, or to get around authentication. MITRE files it under Credential Access and lists Identity Provider, Linux, Windows and macOS as platforms.

Authentication code is a high-value target. A flaw in it can be worth more than a stolen password.

How attackers use it

MITRE describes exploitation as taking advantage of a programming error in a program, a service, or the operating system or kernel to run adversary-controlled code. Credential and authentication mechanisms may be targeted to get useful credentials or to bypass the authentication process.

The page gives two examples. One is MS14-068, which targets Kerberos and can be used to forge Kerberos tickets with domain user permissions. The other is the replay attack, where the adversary intercepts packets sent between parties and plays them back later. If services do not validate authentication requests properly, replayed packets may let the adversary impersonate one party.

It also happens in the cloud. MITRE notes that adversaries have exploited vulnerabilities in public cloud infrastructure that allowed unintended authentication token creation and renewal.

Depending on the process targeted and the credentials obtained, this can also lead to privilege escalation. MITRE's examples include exploiting vulnerable network appliances to collect and exfiltrate valid credentials, and exploiting a flaw in VMware vCenter to obtain encrypted credentials from its database.

How to detect it

MITRE's detection strategy ties exploitation attempts to odd process behavior, service instability and suspicious authentication events.

Windows. Forged Kerberos tickets (for example from MS14-068), abnormal access to LSASS memory, replayed authentication attempts and unexpected crashes of authentication services.

Linux. Failed or unusual PAM authentications, abnormal segfaults in authentication services, and exploitation attempts followed by successful unauthorized logins. Correlation points to memory corruption, replay attempts and privilege escalation tied to credential services.

macOS. Abnormal crashes in opendirectoryd, unauthorized Keychain API use, and unusual sudo or login events.

Identity providers. Vulnerabilities in cloud identity providers such as Azure AD or Okta show up as unusual token creation or renewal, authentication bypass events and API abuse to mint tokens that should not exist. MITRE also points to absent or inconsistent audit logs as a warning sign.

For Windows, Kerberos events on domain controllers (4768 for ticket requests and 4769 for service ticket requests) are the place to start. Alert on tickets with odd attributes or from unexpected clients, and on crashes of authentication services.

How to reduce the risk

MITRE's mitigations:

  • Developer guidance. Validate authentication requests using one-time passwords, timestamps or sequence numbers on messages, digital signatures, or random session keys. These measures make replay harder.
  • Isolate applications with sandboxing, virtualization and microsegmentation to make it harder to advance through unpatched flaws.
  • Use exploit protection, such as Windows Defender Exploit Guard and control flow integrity checking, noting that compatibility varies.
  • Run a threat intelligence program so you know which exploits are likely to be used against you.
  • Patch internal enterprise endpoints and servers through patch management.

Check your own environment

Read-only. On a Windows domain controller, review recent Kerberos service ticket events (PowerShell, elevated):

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769} -MaxEvents 20

And a short checklist:

  • Are domain controllers and identity infrastructure at the top of your patch priority list?
  • Are authentication logs forwarded off the servers that produce them?
  • Do you alert on crashes of LSASS, authentication daemons and directory services?
  • Do your own applications check timestamps, nonces or signatures on authentication messages?
  • For cloud identity, do you monitor token creation and renewal, and check that audit logs have no gaps?

Quick check

What is a replay attack in this context?

The adversary intercepts packets between parties and later replays them. If a service does not validate authentication requests properly, the replay can allow impersonation.

What can developers add to authentication messages to make replay harder?

One-time passwords, timestamps or sequence numbers, digital signatures, or random session keys.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.