ADPRIV-015: Privileged Accounts No MFA Indicator
- Plataforma
- Active Directory
- Categoría
- AD Privileged Account Security
- Severidad
- High
- Pilar de Zero Trust
- Identity (peso 3)
- Fixtures de referencia
- 3
- Cobertura de ramas
- Observada: los fixtures prueban los veredictos que ejercitan
- Procedencia
- baseline
Qué comprueba
The check enumerates privileged principals by querying every user object where adminCount=1, then joins the results to direct and nested membership of the protected groups enumerated by SDProp (Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Backup Operators, Server Operators, Print Operators, Replicator, Domain Controllers, Read-only Domain Controllers, Enterprise Read-only Domain Controllers, Key Admins, Enterprise Key Admins). For each principal it reads: - userAccountControl, specifically the SMARTCARD_REQUIRED bit (0x40000, decimal 262144) - msDS-SupportedEncryptionTypes, to confirm AES is available for smart card Kerberos PKINIT - altSecurityIdentities, to surface explicit certificate mappings used by smart card or Windows Hello for Business - userCertificate / userPrincipalName, to detect bound certificates and UPN-based mapping - pwdLastSet and PasswordNeverExpires, because a SMARTCARD_REQUIRED account still has an underlying password hash that the DC rotates on a schedule and that becomes a single-factor secret if SMARTCARD_REQUIRED is later cleared - lastLogonTimestamp and whenChanged, to flag stale Tier-0 accounts that have never been migrated to a phishing-resistant credential For hybrid environments the check additionally enumerates ms-DS-ConsistencyGuid and queries the Microsoft Graph /users/{id}/authentication/methods endpoint (when invoke-adaudit is run with -IncludeCloud) to confirm a phishing-resistant Entra ID method (FIDO2, Windows Hello for Business, or certificate-based authentication) is registered for the cloud-side identity. An on-premises privileged account with no SMARTCARD_REQUIRED flag and no phishing-resistant cloud method is reported as the primary finding.
Por qué importa
Privileged accounts are the highest-value targets in Active Directory and are subject to continuous password spraying, AS-REP roasting, Kerberoasting, NTLM relay, and phishing. Without a phishing-resistant second factor, a single password compromise on any of these accounts (through a leaked credential dump, a successful spray, a malicious browser session, an MFA-fatigue prompt against a weak factor, or a credential prompt on a compromised endpoint) yields immediate Domain Admin or Enterprise Admin authority. MITRE ATT&CK tracks this as T1078.002 (Valid Accounts: Domain Accounts) and as T1110 (Brute Force) when the entry vector is password spraying. The blast radius of a successful credential compromise on a Tier-0 account is the entire forest: krbtgt extraction, Golden Ticket forgery, DCSync, ACL backdoor placement, GPO modification, and persistence through ADCS template abuse all become possible. Enforcing SMARTCARD_REQUIRED replaces the password as the primary authentication secret with a certificate whose private key is bound to a TPM or hardware token, breaks every credential-replay technique that relies on knowing the password, and forces the attacker to physically possess (or remotely compromise the host of) the smart card or Windows Hello container. Microsoft has documented this as a baseline requirement for the Tier-0 / Enterprise Access Model since 2014, and CISA, NSA, and the UK NCSC explicitly call for phishing-resistant MFA on all privileged accounts.
Ruta de ataque
1. Reconnaissance: the attacker queries adminCount=1 over LDAP (no special rights required, any authenticated user can read it) or runs Get-DomainUser -AdminCount via PowerView, or imports BloodHound and walks the high-value targets list. This yields a clean list of every Tier-0 candidate. 2. Filter: the attacker reads userAccountControl on each result and drops any account where bit 0x40000 (SMARTCARD_REQUIRED) is set, because those accounts cannot be authenticated with a password alone via Kerberos preauth or NTLM. What remains is the list of password-authenticatable Tier-0 principals. 3. Credential acquisition: the attacker chooses among password spray (low-and-slow against the surviving list using common patterns, particularly effective against accounts with PasswordNeverExpires), AS-REP roast (any of the surviving accounts with DONT_REQ_PREAUTH set yields an offline-crackable hash), Kerberoast (any surviving account with a SPN yields a TGS encrypted with the account password), NTLM relay (coerced authentication from a privileged session relayed to LDAPS, SMB, or ADCS HTTP), or credential phishing. 4. Authentication: with the recovered password the attacker authenticates as the Tier-0 principal. Because no second factor is required, the DC issues a TGT immediately. The attacker now holds Domain Admin rights from any internet-reachable VPN endpoint or any internal foothold. 5. Privilege expansion: the attacker performs DCSync to extract krbtgt and forges a Golden Ticket, or extracts the NTDS.dit, or stages BloodHound to enumerate the post-compromise attack surface, or installs an ACL backdoor (ADACL-001) for persistence. 6. Detection evasion: because the authentication completes with a valid password and a valid TGT, the activity appears as a normal Tier-0 logon in Event ID 4624 and 4768, and is indistinguishable from the legitimate administrator absent additional telemetry such as logon source, time of day, or risk-based session evaluation.
Cómo lo evalúa Guerrilla
Guerrilla resolves protected principals by first enumerating SDProp-stamped users (Get-ADUser -Filter {adminCount -eq 1} -Properties userAccountControl, msDS-SupportedEncryptionTypes, altSecurityIdentities, userCertificate, pwdLastSet, lastLogonTimestamp) and then cross-referencing direct and recursive membership of the protected groups via Get-ADGroupMember -Recursive against the canonical group list. SMARTCARD_REQUIRED is detected by bitwise AND of userAccountControl with 0x40000; any account where the bit is clear is reported. The check also flags an inconsistent state where SMARTCARD_REQUIRED is set but altSecurityIdentities and userCertificate are both empty (the account is locked out of interactive logon and is operationally broken, which administrators sometimes resolve by clearing the bit rather than fixing the certificate binding). For hybrid forests the optional Graph join calls GET /v1.0/users/{id}/authentication/methods and reports any privileged account whose only registered method is password, SMS, voice call, or Microsoft Authenticator notification (non-phishing-resistant), because those methods do not satisfy modern Tier-0 baselines. Findings are emitted with the well known SID of the parent protected group so downstream correlation against ADPRIV-001 (Domain Admins enumeration) and ADTIER-001 (Tier model adherence) is straightforward.
Valor recomendado
All privileged accounts required to use MFA via smart card, Windows Hello for Business, or FIDO2. 'Smart card is required for interactive logon' flag set where applicable
Remediación
Review privileged accounts for smart card logon requirement using Get-ADUser -Filter {SmartcardLogonRequired -eq $false -and AdminCount -eq 1}. Deploy smart card or Windows Hello for Business authentication for all privileged accounts. Enable 'Smart card is required for interactive logon' flag on Tier 0 accounts
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 |
| known-bad | FAIL |
| throttled | Not Assessed |
Mapeos a marcos de referencia
- NIST SP 800-53
- IA-2(1), IA-2(2)
- CIS Benchmark
- 1.1.6
- ANSSI
- R5
- CIS AD Benchmark
- 4.4.1
- MITRE ATT&CK
- T1078.002