ADPWD-020: BitLocker Recovery Keys in AD
- Plataforma
- Active Directory
- Categoría
- AD Password & Lockout Policies
- Severidad
- Info
- Pilar de Zero Trust
- Identity (peso 2)
- Fixtures de referencia
- 1
- Cobertura de ramas
- Observada: los fixtures prueban los veredictos que ejercitan
- Procedencia
- baseline
Qué comprueba
The check performs an LDAP search across the domain naming context for objects of class msFVE-RecoveryInformation: (objectClass=msFVE-RecoveryInformation) Each msFVE-RecoveryInformation object is a child of a computer object in the directory and carries the following attributes: - msFVE-RecoveryPassword: the 48-digit numerical recovery password as a Unicode string. - msFVE-RecoveryGuid: the GUID that identifies the recovery key (matches the GUID printed at the BitLocker recovery prompt). - msFVE-KeyPackage: an optional binary blob containing the BEK material used by repair-bde.exe to recover individual sectors. - msFVE-VolumeGuid: the GUID of the protected volume. - whenCreated: the timestamp the key was escrowed, which corresponds to BitLocker enablement (or a key rotation event). For each hit the check records the parent computer DN, the recovery object GUID, the creation date, and the security descriptor (nTSecurityDescriptor) on the msFVE-RecoveryInformation object itself. Guerrilla then cross-references the population of computer objects in the domain against the population of computers that have at least one child msFVE-RecoveryInformation entry. Computers that exist in AD but have no escrowed key are surfaced as an inventory gap. The ACL on each recovery object is parsed and any non-default ACE granting read or full-control rights to a non-Tier-0 principal is reported.
Por qué importa
Two distinct risks attach to BitLocker recovery information in AD: 1. Missing escrow. If a laptop is lost or stolen and the recovery password was never escrowed, the data on that drive is unrecoverable to the business but recoverable to an attacker who controls the device, because BitLocker without a TPM+PIN configuration can be unsealed via a cold-boot, DMA, or LPC-bus attack against the TPM. Missing escrow also indicates that GPO settings ("Choose how BitLocker-protected operating system drives can be recovered" with "Do not enable BitLocker until recovery information is stored to AD DS" unchecked) are permissive, so users can defer or skip escrow. 2. Over-permissive escrow ACL. By default the schema grants Read property on msFVE-RecoveryInformation to the computer object itself (so the OS can write the key), to SYSTEM, and to members of Domain Admins via inheritance from the computer object. If an operator delegates "Read all BitLocker recovery information" rights to a Helpdesk group, every member of that group can pull the recovery password for any encrypted endpoint by querying LDAP. The recovery password unlocks the drive offline, bypassing the OS, EDR, and every login control. An attacker who compromises a single Helpdesk account inherits the ability to decrypt every laptop in the fleet, which converts a low-privilege compromise into wholesale data exfiltration without ever logging into the endpoint. The msFVE-RecoveryInformation attribute set is also a confidential attribute by default (searchFlags bit RODC_FILTERED + CONFIDENTIAL = 0x80 + 0x200), which means standard CONTROL_ACCESS rights are required to read it. Operators who add explicit Allow ACEs without understanding the confidential bit accidentally widen exposure.
Ruta de ataque
1. Recon: the attacker, holding any authenticated domain user credential, enumerates BitLocker recovery objects with PowerView or Get-ADObject: Get-ADObject -LDAPFilter "(objectClass=msFVE-RecoveryInformation)" -Properties msFVE-RecoveryPassword, msFVE-RecoveryGuid -SearchBase "DC=corp,DC=contoso,DC=com" If the ACL is default, the read fails with "Access is denied" because msFVE-RecoveryPassword is confidential. If a misconfigured Allow ACE exists (Helpdesk group, OU-level delegation), the read returns the 48-digit password. 2. ACL abuse: with PowerView the attacker enumerates ACLs that grant CONTROL_ACCESS on msFVE-RecoveryInformation to non-Tier-0 principals: Get-DomainObjectAcl -SearchBase "DC=corp,DC=contoso,DC=com" -LDAPFilter "(objectClass=msFVE-RecoveryInformation)" -ResolveGUIDs | Where-Object { $_.ActiveDirectoryRights -match "ReadProperty|GenericRead|GenericAll" -and $_.SecurityIdentifier -notmatch "S-1-5-32-544|S-1-5-18" } 3. Bulk extraction: if the attacker compromises a delegated group (Helpdesk, Desktop Support), they pull every recovery password in one query and stage it for offline use: Get-ADObject -LDAPFilter "(objectClass=msFVE-RecoveryInformation)" -Properties msFVE-RecoveryPassword, msFVE-RecoveryGuid | Export-Csv keys.csv -NoTypeInformation 4. Offline decryption: with physical access to a stolen or seized laptop, the attacker boots to the BitLocker recovery prompt, reads the displayed RecoveryGuid, looks up the matching msFVE-RecoveryPassword in the exfiltrated CSV, types it in, and obtains a fully decrypted volume. EDR, DLP, and login auditing are bypassed entirely because the OS is mounted from an attacker-controlled boot environment. 5. Persistence and reuse: recovery passwords do not rotate unless the operator explicitly invokes manage-bde -protectors -delete and re-enables protection, so a single exfiltration is good for the operational life of every endpoint in scope.
Cómo lo evalúa Guerrilla
Guerrilla issues a paged LDAP search (System.DirectoryServices.Protocols) for (objectClass=msFVE-RecoveryInformation) across the writable domain naming context. For each hit it records the parent DN, msFVE-RecoveryGuid, msFVE-VolumeGuid, whenCreated, and the nTSecurityDescriptor of the recovery object. It then runs a second search for (objectCategory=computer)(operatingSystem=Windows*) and computes the set difference: computers with no msFVE-RecoveryInformation child are reported as missing escrow. The ACL on each recovery object is parsed with System.DirectoryServices.ActiveDirectorySecurity and any ACE that grants ReadProperty, GenericRead, GenericAll, or the CONTROL_ACCESS extended right (rightsGuid for msFVE-RecoveryInformation reads) to a principal outside Domain Admins, Enterprise Admins, SYSTEM, or the computer object itself is flagged. The check requires only a member-of-Domain Users principal and is non-intrusive; it does not attempt to read msFVE-RecoveryPassword to confirm exposure. Optional Event Log correlation looks for Directory Service Access events (4662) with the BitLocker recovery information property set GUID to identify who has actually read recovery passwords in the last 90 days.
Valor recomendado
BitLocker recovery keys present in AD for all workstations and laptops. Recovery key access restricted to authorized administrators
Remediación
Query AD for BitLocker recovery information objects using Get-ADObject -Filter {objectClass -eq 'msFVE-RecoveryInformation'} -SearchBase 'DC=domain,DC=com'. Cross-reference with computer inventory to identify machines without BitLocker. Review ACLs on recovery key objects to ensure only authorized administrators can read them
Veredictos probados con fixtures
Cada veredicto de esta tabla está probado por un fixture de referencia en la suite de pruebas que valida el módulo. La tabla se deriva de la última ejecución en verde; no puede editarse a mano.
| Escenario | Veredicto esperado |
|---|---|
| clean | PASS |
Mapeos a marcos de referencia
- NIST SP 800-53
- SC-28, SC-28(1)
- CIS AD Benchmark
- 5.8.1
- MITRE ATT&CK
- T1005