Full Report
On the 31st of October 2022, a PR on CrackMapExec from Thomas Seigneuret (@Zblurx) was merged. This PR fixed Kerberos authentication in the CrackMapExec framework. Seeing that, I instantly wanted to try it out and play a bit with it. While doing so I discovered a weird behaviour with the Protected Users group. In this blogpost I’ll explain what the Protected Users group is, why it is a nice security feature and yet why it is incomplete for the Administrator (RID500) user.
Analysis Summary
# Vulnerability: Incomplete Enforcement of Protected Users Group Restrictions for RID 500 Account
## CVE Details
- CVE ID: N/A (Described as intended behavior by MSRC, not a formal CVE)
- CVSS Score: N/A (No official score provided as it's treated as design/configuration issue)
- CWE: CWE-287 (Improper Authentication) or CWE-284 (Improper Access Control) depending on interpretation.
## Affected Systems
- Products: Microsoft Active Directory Domain Services (AD DS) running on Windows Server (Protected Users group introduced in Windows Server 2012R2).
- Versions: All Active Directory environments where the RID 500 (Built-in Administrator) account exists.
- Configurations: Any domain environment where the RID 500 account is a member of the "Protected Users" group.
## Vulnerability Description
The security restrictions imposed by adding an account to the "Protected Users" group are incompletely enforced on the default Domain Administrator account (RID 500). Specifically:
1. **RC4 Restriction Bypass:** While NTLM authentication is blocked for users in Protected Users, the RID 500 account, even when a member of Protected Users, can still successfully authenticate via **Kerberos using the RC4 encryption type**. This allows an attacker with the NT hash of the RID 500 account to perform **OverPass-the-Hash (OPtH)** attacks against Kerberos-enabled services, which should be blocked by membership in Protected Users.
2. **Delegation Bypass:** Kerberos delegation restrictions (e.g., RBCD) imposed by the Protected Users group membership are **not enforced** for the RID 500 account. This allows an attacker to abuse delegation scenarios by impersonating the RID 500 account, even if it is listed in Protected Users.
This behavior is attributed to the `ms-DSSupportedProtocolEncryption` attribute on the RID 500 account being set to `0x0`, which implies all protocols are supported, overriding the Protected Users group settings regarding RC4 usage.
## Exploitation
- Status: Exploit technique demonstrated (PoC available via CrackMapExec manipulation).
- Complexity: Low (Requires possession of the target's NT Hash, which is generally obtained post-compromise in internal network assessments).
- Attack Vector: Network (Leveraging authentication protocols).
## Impact
- Confidentiality: High (Allows authentication to systems via Kerberos OPtH, bypassing security controls).
- Integrity: High (Allows successful authentication, potentially leading to configuration changes or privilege escalation).
- Availability: Low (The primary impact is on security controls, not system availability).
## Remediation
### Patches
- No security patch is available, as Microsoft MSRC stated this behavior is intended for the RID 500 account.
### Workarounds
1. **Explicitly Disable RC4 for RID 500:** Modify the `ms-DSSupportedProtocolEncryption` attribute on the RID 500 account. Setting this value to `0x18` (0x18) enables only AES-128 and AES-256, effectively disabling RC4 for this specific account (though this might affect legacy systems relying on RC4).
2. **Explicitly Disable Delegation for RID 500:** Regardless of Protected Users membership, ensure the "Account is sensitive and cannot be delegated" option is explicitly checked for the RID 500 account in Active Directory Users and Computers (or equivalent LDAP modification) to prevent delegation abuses.
3. **Disable RID 500 Account:** The ultimate, though potentially risky, remediation suggested is to disable the built-in Administrator account entirely and use delegated service accounts instead, in line with Microsoft's general best practice guidance.
## Detection
- **Indicators of Compromise:** Look for Kerberos authentication attempts against domain services involving the RID 500 account using the RC4 encryption type (TGS/TGT requests utilizing encryption type 23 - RC4-HMAC-MD5).
- **Detection Methods and Tools:** Monitor Active Directory authentication logs (4768/4769 events) filtering for the RID 500 principal name and verifying the encryption type used. Review the AD schema/LDAP configuration to determine the effective supported encryption protocols (`ms-DSSupportedProtocolEncryption`) for the administrator account.
## References
- CrackMapExec PR: defanged.github.com/Porchetta-Industries/CrackMapExec/pull/655
- Original Blog Post: defanged.blog.whiteflag.io/2023/03/protected-users-you-thought-you-were-safe-uh/
- MSDN Documentation on Protected Users: defanged.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group
- Microsoft Guidance on Securing Built-in Administrator Accounts: defanged.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-d--securing-built-in-administrator-accounts-in-active-directory