Skip to content

Latest commit

 

History

History
87 lines (56 loc) · 3.91 KB

T1098-WIN-002.md

File metadata and controls

87 lines (56 loc) · 3.91 KB

Note: You are viewing an old, archived version of this content. The latest version is available in the 'main' branch.

Shadow Credentials Added to Account (Alternative)

Metadata

ID: Shadow_Credentials_Added_to_Account_Alternative-Win

OS: WindowsEndpoint, WindowsServer

FP Rate: Low


ATT&CK Tags

Tactic Technique Subtechnique Technique Name
TA0004 - Privilege Escalation T1484 Domain Policy Modification
TA0003 - Persistence T1098 Account Manipulation

Utilized Data Sources

Log Provider Event ID Event Name ATT&CK Data Source ATT&CK Data Component
WindowsLog_Security 4662 Securitylogs Active Directory Active Directory Object Modification

Technical description of the attack

This query searches for modifications to the 'msDS-KeyCredentialLink' property in Active Directory. There are two different events which contain information to detect such changes: 5136 and 4662. This detection uses the 4662, which is an alternative if 5136 is not available.

Permission required to execute the technique

Administrator

Detection description

Windows Hello for Business (WHfB) supports multi-factor passwordless authentication. When the user or computer enrolls, the TPM generates a public-private key pair for the relevant account. The public key is stored in a new Key Credential object in the msDS-KeyCredentialLink attribute of the account. When a client logs in, Windows attempts to perform PKINIT authentication using their private key. Under the Key Trust model, the Domain Controller can decrypt their pre-authentication data using the raw public key in the corresponding NGC object stored in the client's msDS-KeyCredentialLink attribute. Attackers can abuse this property to gain local administrator access to a computer. Various attack tools such as Whisker, DSInternals and ntlmrelayx include functionality to modify this property.

Considerations

This query requires event 4662 (Active Directory object operations) to be logged. This attack can also be detected with event 5136, which is the preferred option. Detecting this attack with event 4662 is a backup strategy in case 5136 is not available in your environment.

False Positives

The property can also be used for legitimate purposes. However, the legitimate use of the property is limited in most environments.

Suggested Response Actions

Investigate the source of the update to the 'msDS-KeyCredentialLink' property.

Detection Blind Spots

Accounts changing their own 'msDS-KeyCredentialLink' property are excluded from this detection rule, since this behavior periodically happens for legitimate purposes, e.g. when updating Windows Hello for Business [WHfB] certificates. As a result, abusing this issue with an NTLM relay attack would not trigger this rule.

References


Detection

Language: Kusto

Platform: Sentinel

Query:

let timeframe = 1h;
SecurityEvent
| where ingestion_time() >= ago(timeframe)
| where EventID == 4662
| where Properties has "5b47d60f-6090-40b2-9f37-2a4de88f3063" // msDS-KeyCredentialLink.
| where Properties has "%%7685" or AccessList has "%%7685"// "Write Property": https://gist.github.com/brianreitz/d5b9397a2e8b3d52ceb9359897e07c3f.

Version History

Version Date Impact Notes
1.0 2022-06-17 major Initial version.