ADNET-003: SMB Server Signing Required (Domain Policy)
- Plataforma
- Active Directory
- Categoría
- AD Network & Relay Preconditions
- Severidad
- Critical
- Pilar de Zero Trust
- Networks (peso 3)
- Fixtures de referencia
- 3
- Cobertura de ramas
- Observada: los fixtures prueban los veredictos que ejercitan
- Procedencia
- baseline
Qué comprueba
The check evaluates the effective server-side SMB signing posture in three layers. First, the Default Domain Policy is parsed via the SYSVOL GPT.ini path \\<domain>\sysvol\<domain>\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf for the Security Options key MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\RequireSecuritySignature. A value of 4,1 means Enabled; absent or 4,0 means Disabled. Second, each enumerated member host is queried via remote registry (with fallback to WMI StdRegProv) for the same value, capturing the live runtime setting after all GPO precedence has been applied. Third, the companion value EnableSecuritySignature (signing offered when client requests) is captured for context; required overrides offered, so the check key is RequireSecuritySignature. The check also records the OS version (Win32_OperatingSystem.BuildNumber) because Windows 11 24H2 (build 26100) and Windows Server 2025 (build 26100) enable RequireSecuritySignature by default in fresh installs, while in-place upgrades preserve the prior value. Domain controllers are evaluated separately because they bind their SMB signing posture to the Default Domain Controllers Policy and the SMB signing requirement is already enabled out of the box on DCs since Windows 2000. The output for each host is one of: Required (pass), Offered-only (fail, relay possible), Disabled (fail, relay trivial), or Indeterminate (host unreachable or registry path blocked).
Por qué importa
NTLM relay against SMB is the most common privilege-escalation pattern in modern internal pentests and ransomware intrusions. When SMB signing is not required on the server, the integrity check that would otherwise bind a challenge-response pair to a specific session is absent, which means an attacker sitting between the client and server can forward the authentication material to a different target host and the target will accept it as valid. The blast radius depends entirely on which principal is coerced and which target the attacker chooses. Relay a Domain Admin to a file server: full filesystem write. Relay a server computer account to itself (cross-protocol): local administrator on the source host via the Resource-Based Constrained Delegation primitive. Relay a domain controller machine account (via PetitPotam / DFSCoerce / PrinterBug) to ADCS Web Enrollment: a certificate as the DC, then DCSync, then Golden Ticket, then full forest compromise within minutes. The relay sink is the unsigned SMB server; remove the sink and an entire family of attacks (ntlmrelayx -t smb://, secretsdump via relay, PetitPotam-to-SMB, KrbRelay-to-SMB) is closed without any client-side changes. Microsoft explicitly recommends server-side SMB signing required as the primary mitigation in MSRC advisories ADV170014 (LM/NTLMv1 hardening) and the PetitPotam / ADV210003 guidance, and it is one of the two controls (the other being EPA / channel binding on HTTP) that the SpecterOps and TrustedSec NTLM relay playbooks identify as load-bearing for AD network defense.
Ruta de ataque
Step 1: Foothold and positioning. The attacker has a low-privilege domain user credential (or none at all if they can poison name resolution from an unauthenticated foothold). They place themselves on the L2/L3 path between victim clients and a target file server using LLMNR/NBT-NS/mDNS poisoning (Responder), IPv6 router advertisement spoofing (mitm6), DHCP option injection, or simple ARP spoofing. Step 2: Stand up the relay. The attacker launches Impacket ntlmrelayx with the unsigned SMB target list: ntlmrelayx.py -tf targets.txt -smb2support -socks. The targets file contains every member server whose RequireSecuritySignature is 0. ntlmrelayx listens on TCP 445, 80, 88, and 389 and waits for inbound NTLM authentications. Step 3: Trigger the authentication. Three options. (a) Passive: Responder poisons the next broadcast name lookup and a client connects to the attacker on SMB. (b) Active coerce against a workstation or server: PetitPotam.py target_ip attacker_ip via MS-EFSRPC EfsRpcOpenFileRaw, PrinterBug via MS-RPRN RpcRemoteFindFirstPrinterChangeNotificationEx (printerbug.py from Impacket), DFSCoerce via MS-DFSNM (dfscoerce.py by Filip Dragovic / wh0amitz), or ShadowCoerce via MS-FSRVP (shadowcoerce.py). Each triggers the victim machine account to authenticate to the attacker IP over SMB. (c) Cross-protocol coerce of a domain controller: PetitPotam against the DC, which authenticates as DOMAIN\DC$ to the attacker. Step 4: Relay lands. ntlmrelayx receives the NTLM Type 1 from the victim, forwards it to a target unsigned SMB server, negotiates the challenge-response with the victim, and presents the valid Type 3 to the target as the victim principal. Because the target does not require signing, it accepts the session and ntlmrelayx now has an authenticated SMB session as the victim against the target. Step 5: Action on objective. ntlmrelayx by default executes secretsdump-style behavior on a successful relay: dump SAM/LSA on the target. With -c "powershell -enc <base64>" it executes a payload via SCM. With --socks it parks the session as a SOCKS proxy and the attacker drives it interactively with proxychains + smbclient / impacket-secretsdump / impacket-wmiexec. If the relayed principal is a domain admin or a server local admin, the attacker has code execution. If the relayed principal is the DC machine account and the relay target is another DC, the attacker performs DRSUAPI replication (DCSync) and harvests the krbtgt hash. Step 6: Persistence. The attacker registers a service binary in C$\Windows\Temp via the relayed session, creates a scheduled task, or, if they collected the krbtgt hash, mints a Golden Ticket for arbitrary impersonation that survives password resets of every other principal.
Cómo lo evalúa Guerrilla
Guerrilla performs the check in three passes. Pass one parses every linked GPO at the domain root, the Domains OU container, and any Tier 0 OU for the registry policy MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\RequireSecuritySignature, recording the GPO GUID, the precedence rank, and whether the policy is set to 4,1. Pass two enumerates every enabled computer object whose operatingSystem attribute matches Windows Server* or Windows 1*/Windows 7/8/10/11 (excluding domain controllers, which are evaluated under ADKERB/ADDOM checks), then for each reachable host opens the remote registry hive HKLM via [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey and reads SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\RequireSecuritySignature. Hosts where remote registry is disabled fall back to Get-CimInstance against root\default StdRegProv GetDWORDValue. Pass three correlates the per-host result against the GPO-effective expected value and flags any drift (GPO says required, host reports 0) as a separate finding (ADGPO precedence violation). The check additionally captures the SMB1 protocol state via Get-SmbServerConfiguration EnableSMB1Protocol and the SMB2/3 EncryptData and RejectUnencryptedAccess settings, because a host with signing not required AND SMB1 enabled is the worst-case relay sink. No SMB sessions are established by the audit; all reads are passive against the registry.
Valor recomendado
Default Domain Policy enables 'Microsoft network server: Digitally sign communications (always)' (RequireSecuritySignature on LanManServer = 1)
Remediación
Edit the Default Domain Policy: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > 'Microsoft network server: Digitally sign communications (always)' = Enabled. Registry: HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters\RequireSecuritySignature = 1. Windows 11 24H2 / Server 2025 enable this by default; older OS versions need explicit policy.
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
- SC-8, SC-23
- CIS AD Benchmark
- 6.2.1
- MITRE ATT&CK
- T1557.001