Full Report
Changes to the msds-KeyCredentialLink attribute are not audited/logged with standard audit configurations. This required serious investigations and a partner firm in infosec provided us the answer: TrustedSec. So, credit where […] The post Enable Auditing of Changes to msDS-KeyCredentialLink appeared first on Black Hills Information Security, Inc..
Analysis Summary
# Best Practices: Auditing and Detecting Changes to `msDS-KeyCredentialLink`
## Overview
These practices address a specific security gap concerning the Active Directory attribute `msDS-KeyCredentialLink`, which is commonly exploited for privilege escalation (e.g., via "Shadow creds" attacks). Standard auditing configurations do not log modifications to this attribute, necessitating custom Directory Service auditing setup to detect unauthorized changes.
## Key Recommendations
### Immediate Actions
1. **Obtain Necessary Tools:** Download and stage the `Set-AuditRule.ps1` tool from the Open Threat Research Forge repository to configure auditing policies.
### Short-term Improvements (1-3 months)
1. **Identify Schema GUID:** Determine and verify the Schema GUID for the `msDS-KeyCredentialLink` attribute, which is **`5b47d60f-6090-40b2-9f37-2a4de88f3063`**.
2. **Configure Directory Service Auditing:** Execute the necessary PowerShell command using `Set-AuditRule.ps1` to apply a custom Audit Rule to the entire domain, specifically targeting modifications to the `msDS-KeyCredentialLink` attribute for **Success** events.
3. **Verify Audit Configuration:** Confirm that Directory Service auditing is enabled on all Domain Controllers.
### Long-term Strategy (3+ months)
1. **Establish Detection Logic:** Integrate logs generated by the new audit rule (Event ID 5136) into your Security Information and Event Management (SIEM) solution (e.g., Microsoft Sentinel).
2. **Implement KQL Hunting Queries:** Deploy the provided Kusto Query Language (KQL) query to continuously monitor for and alert on Event ID **5136** where the `ModifiedAttribute` is exactly **`msDS-KeyCredentialLink`**.
3. **Regular Review:** Periodically review the auditing configuration to ensure the rule remains applied correctly across all domain objects.
## Implementation Guidance
### For Small Organizations
- Focus on implementing the `Set-AuditRule.ps1` script directly by an administrator familiar with Active Directory and PowerShell execution.
- Utilize a simple logging mechanism (built-in Windows Event Viewer archiving) if a full SIEM is not yet deployed, but prioritize setting up the audit rule first.
### For Medium Organizations
- Integrate the new audit events (Event ID 5136 referencing the attribute) into the existing SIEM platform.
- Use the provided KQL (or equivalent SIEM query language) to create a high-fidelity, active alert for success events related to `msDS-KeyCredentialLink` modifications.
### For Large Enterprises
- Incorporate the application of this new mandatory Audit Rule into existing Group Policy Objects (GPOs) or Active Directory configuration management pipelines to ensure domain-wide, consistent enforcement.
- Centralize the detection logic within dedicated Security Orchestration, Automation, and Response (SOAR) playbooks for automated triage upon detection.
## Configuration Examples
The following command applies the audit rule to the domain (replace `DC=doazlab,DC=com` with your actual domain DN):
powershell
Import-Module ActiveDirectory
# Download the tool (ensure proper security verification before running unknown scripts)
iwr -Uri https://raw.githubusercontent.com/OTRF/Set-AuditRule/master/Set-AuditRule.ps1 -OutFile Set-AuditRule.ps1
Import-Module .\Set-AuditRule.ps1
Set-AuditRule -AdObjectPath 'AD:\DC=doazlab,DC=com' `
-WellKnownSidType WorldSid `
-Rights WriteProperty,GenericWrite `
-InheritanceFlags All `
-AttributeGUID 5b47d60f-6090-40b2-9f37-2a4de88f3063 `
-AuditFlags Success
**Sentinel Detection Query (KQL):**
kql
union Event, SecurityEvent
| where EventID == 5136
| parse EventData with * 'ObjectDN">' ObjectDN "' ModifiedAttribute "<" *
| where ModifiedAttribute == "msDS-KeyCredentialLink"
| project Computer , TimeGenerated , Activity, ObjectDN, ModifiedAttribute
## Compliance Alignment
- **NIST CSF:** Focuses heavily on Protect (PR.DS - Data Security) and Detect (DE.DP - Anomalous Activity Detection).
- **ISO 27001:** Relevant to A.12.4 (Logging and monitoring).
- **CIS Controls:** Aligns with Control 14 (Security Awareness and Skills Training) by providing necessary information, and Control 16 (Application Software Security) as it relates to hardening core identity infrastructure.
## Common Pitfalls to Avoid
- **Overlooking Attribute GUID:** Failing to use the correct Schema GUID (`5b47d60f-6090-40b2-9f37-2a4de88f3063`) will result in the rule targeting the wrong attribute or failing entirely.
- **Insufficient Rights:** Running the `Set-AuditRule` command without sufficient permissions (e.g., Domain Admin rights, or specific rights to modify the domain Naming Context's DACL) will cause the rule configuration to fail silently or explicitly.
- **Inconsistent DC Auditing:** Only configuring the audit rule without ensuring that **Directory Service Auditing** is enabled globally on all Domain Controllers will prevent relevant event logs (Event ID 5136) from being generated.
## Resources
- **Audit Tool:** OTRF Set-AuditRule script (GitHub source: `https://github.com/OTRF/Set-AuditRule`).
- **Reference Documentation:** Microsoft documentation for the `msDS-KeyCredentialLink` attribute schema details.
- **Detection Repository:** Defensive Origins GitHub repository for detection logic (`https://github.com/DefensiveOrigins/Detect-msDS-KeyCredentialLink`).
- **Research Origin:** TrustedSec blog post detailing the methodology for this detection gap.