Active Directory AS-REP Roasting Contas de Serviço Privilegiadas: As Contas que o Pre-Auth Deveria Proteger

Active directory as-rep roasting contas de serviço privilegiadas é o caso de maior risco abordado neste artigo: contas Kerberos com a pré-autenticação desativada que também estão em um grupo privilegiado ou funcionam como conta de serviço, não um usuário padrão qualquer.

Active Directory AS-REP Roasting Contas de Serviço Privilegiadas

O catálogo da EtcSec rastreia o caso de contas privilegiadas separadamente como ADMIN_ASREP_ROASTABLE (Crítico), porque uma conta que já está em Domain Admins, Enterprise Admins ou outro grupo Tier 0 com esse flag ativado transforma o AS-REP roasting em uma corrida direta de cracking offline até o DA, não uma cadeia de movimento lateral em várias etapas. Para a versão genérica desse ataque, aplicável a qualquer conta, veja AS-REP Roasting: Coletando Hashes Sem Credenciais — este artigo tem escopo mais restrito, focado no cluster de contas privilegiadas e de serviço que aquele artigo não cobre.

O flag subjacente é DONT_REQ_PREAUTH (0x400000 / decimal 4194304) no atributo userAccountControl (Microsoft Learn: UserAccountControl property flags). Quando ativado, qualquer cliente pode solicitar uma Kerberos Authentication Server Reply (AS-REP) para essa conta, e a resposta retorna com uma parte criptografada usando uma chave derivada da senha da conta — sem que o cliente precise provar que conhece essa senha. O MITRE ATT&CK T1558.004 rastreia isso como "Steal or Forge Kerberos Tickets: AS-REP Roasting".

A maioria dos artigos genéricos trata isso como um item de higiene de conta de usuário aplicável a todos os casos. Essa abordagem ignora por que dois clusters específicos importam mais:

• Contas privilegiadas sem pré-autenticação (ADMIN_ASREP_ROASTABLE, Crítico) — associação a grupo Tier 0 mais um hash roastável.
• Contas de serviço com o cluster de configurações incorretas adjacente — sem pré-autenticação (SERVICE_ACCOUNT_NO_PREAUTH), com logon interativo permitido (SERVICE_ACCOUNT_INTERACTIVE), e rodando com uma senha que não é rotacionada há mais de um ano (SERVICE_ACCOUNT_OLD_PASSWORD). Cada um isoladamente é Alto; juntos, significam que o hash é fácil de obter e, uma vez quebrado, permanece válido por muito tempo em uma conta que também pode ser abusada para acesso interativo.

Por Que o Flag Acaba Ativado em Contas Reais

O DONT_REQ_PREAUTH raramente é ativado por má intenção — geralmente é resquício de uma necessidade de compatibilidade específica que nunca foi limpa. As causas documentadas incluem migrações de SIDHistory entre domínios, nas quais algumas soluções de VPN ou federação de terceiros não conseguem concluir a pré-autenticação Kerberos para identidades migradas a menos que o flag seja temporariamente desativado durante a transição (Quest support KB 4313059), e compatibilidade com aplicações ou appliances legadas, nas quais uma biblioteca de cliente Kerberos mais antiga não consegue lidar com pré-autenticação de forma alguma (Tenable: How to Stop the Kerberos Pre-Authentication Attack; JumpCloud: What Is Kerberos Pre-Authentication?). A migração ou o appliance legado é desativado; o flag permanece ativado na conta indefinidamente porque nada volta a verificá-lo.

Como Funciona

A pré-autenticação Kerberos existe justamente para impedir essa classe de ataque: o cliente precisa criptografar um timestamp com uma chave derivada da sua senha e enviá-lo no AS-REQ antes que o KDC emita qualquer coisa. Sem esse requisito, a sequência se reduz a quatro passos: o atacante envia um AS-REQ para o nome de usuário-alvo sem senha e sem autenticação prévia no domínio, desde que a conta seja enumerável (LDAP, RPC ou uma lista de usuários vazada); o KDC responde imediatamente com um AS-REP porque a pré-autenticação não é exigida; parte desse AS-REP é criptografada com uma chave derivada da senha da conta; e o atacante quebra essa parte offline, sem nenhum registro no domínio de tentativas de senha malsucedidas, já que cada tentativa acontece no hardware do atacante, não contra o DC.

A velocidade de quebra depende do tipo de criptografia Kerberos negociado. Se a conta ainda permitir RC4 (etype 23), o atacante solicita RC4, e o modo 18200 do hashcat ($krb5asrep$23$...) o quebra ordens de magnitude mais rápido do que uma resposta AES-256 (etype 18) permitiria. Vale a pena fechar o fallback para RC4 ao mesmo tempo — veja Fallback para Kerberos RC4 no Active Directory para o caminho de detecção e remoção correspondente.

A Cadeia de Ataque

O AS-REP roasting raramente aparece sozinho em um comprometimento real. Um walkthrough publicado do laboratório ShadowGate, da Hack Smarter Labs — "ShadowGate Active Directory Lab Walkthrough", de incoggeek — descreve uma cadeia que começa com enumeração SMB anônima, avança para AS-REP roasting como primeiro passo credenciado, e então pivota para abuso de ACLs mapeadas com BloodHound (uma permissão GenericWrite abusada via Shadow Credentials) e ataques de enrollment do AD CS (ESC8, via autenticação forçada por PetitPotam ao endpoint de web enrollment da CA) a caminho de um certificado de Domain Controller. O AS-REP roasting é o que transforma um ponto de apoio totalmente não autenticado no primeiro segredo quebrável dessa cadeia — o mesmo motivo pelo qual Caminhos de Ataque no Active Directory até o Domain Admin trata um passo inicial de roasting Kerberos como uma aresta fundamental, e exatamente por isso um achado ADMIN_ASREP_ROASTABLE em uma conta Tier 0 é classificado como Crítico, e não tratado como higiene de rotina.

Passo 1 — Enumerar e solicitar

# Impacket -- enumera cada conta em usersfile.txt que tem pré-autenticação desativada
# e extrai hashes AS-REP quebráveis sem nenhuma credencial de domínio válida
impacket-GetNPUsers CORP.LOCAL/ -no-pass -usersfile usersfile.txt -format hashcat -outputfile asrep_hashes.txt

Passo 2 — Quebrar offline

# Quebrar offline os hashes $krb5asrep$23$... resultantes (modo 18200 = Kerberos 5, AS-REP, etype 23)
hashcat -m 18200 asrep_hashes.txt rockyou.txt

Detecção

O sinal de maior confiança é o Windows Security Event ID 4768 (Kerberos Authentication Ticket request) com Pre-Authentication Type 0, que só ocorre legitimamente quando a conta-alvo tem a pré-autenticação desativada (MITRE ATT&CK Detection Strategy DET0113; HackTheBox: AS-REP roasting detection). Combine-o com o tipo de criptografia negociado: 0x17 (RC4) junto com Pre-Auth Type 0 é o indicador combinado mais forte, já que um atacante rebaixa deliberadamente para RC4 para acelerar o cracking offline. Para a linha de base mais ampla de política de auditoria e Event IDs sobre a qual essa detecção se apoia, veja Monitoramento de Segurança do AD: Event IDs Que Importam.

Duas consultas PowerShell cobrem diretamente os detectores das lacunas do catálogo:

# Contas privilegiadas com pré-autenticação desativada (candidatas a ADMIN_ASREP_ROASTABLE)
Get-ADUser -Filter {(userAccountControl -band 4194304) -and (adminCount -eq 1)} `
    -Properties userAccountControl, adminCount, ServicePrincipalName, MemberOf |
    Select-Object Name, DistinguishedName, ServicePrincipalName

# Contas de serviço (com SPN) com pré-autenticação desativada, mais idade da senha
Get-ADUser -Filter {(userAccountControl -band 4194304) -and (ServicePrincipalName -like '*')} `
    -Properties ServicePrincipalName, PasswordLastSet, LastLogonDate |
    Select-Object Name, ServicePrincipalName, PasswordLastSet,
        @{N='PasswordAgeDays';E={(New-TimeSpan -Start $_.PasswordLastSet -End (Get-Date)).Days}}

SERVICE_ACCOUNT_INTERACTIVE não é um flag do userAccountControl — é um achado comportamental. Confirme-o correlacionando o sAMAccountName da conta de serviço com eventos 4624 com Logon Type 2 (Interactive) ou 10 (RemoteInteractive/RDP). Uma conta de serviço genuína só deve apresentar Logon Type 3 (Network) ou 5 (Service).

Remediation

Para contas privilegiadas

Remova o flag: desmarque "Do not require Kerberos preauthentication" na aba Account da conta, ou execute Set-ADAccountControl -Identity <account> -DoesNotRequirePreAuth $false. Execute novamente a consulta de detecção acima e confirme que ela retorna zero linhas. Se a conta foi marcada por causa de uma migração de SIDHistory ou transição de federação anterior, confirme que essa migração está totalmente concluída — incluindo a limpeza do SIDHistory — antes de reverter o flag, para que a pré-autenticação não quebre uma dependência ainda ativa.

Para contas de serviço

1. Migre contas de serviço roastáveis para gMSA. As Group Managed Service Accounts rotacionam automaticamente uma senha de 120 caracteres e não podem ser usadas para logon interativo por design, fechando SERVICE_ACCOUNT_OLD_PASSWORD e SERVICE_ACCOUNT_INTERACTIVE no mesmo movimento. Veja Exposição de Senha gMSA no Active Directory para as ressalvas sobre quem ainda consegue ler a senha de um gMSA depois de implantado.
2. Restrinja o logon interativo explicitamente. Onde uma conta ainda não pode migrar para gMSA, aplique "Deny log on locally" e "Deny log on through Remote Desktop Services" via GPO escopada para a OU da conta de serviço, e restrinja "Log on as a service" aos hosts que realmente precisam disso.
3. Rotacione a senha e imponha AES no Kerberos. Defina agora uma senha forte e única, e coloque a conta sob uma política de senha ou Fine-Grained Password Policy que realmente imponha rotação, em vez de deixá-la estática por um ano ou mais. Separadamente, imponha AES em vez de RC4 via "Network security: Configure encryption types allowed for Kerberos" — isso não corrige uma exigência de pré-autenticação ausente, mas eleva o custo de cracking de todo ticket que a conta negociar legitimamente.
4. Não recorra ao Protected Users como solução. O grupo de segurança Protected Users é o controle correto para contas privilegiadas humanas, mas a Microsoft recomenda explicitamente não adicionar contas de serviço ou de computador a ele: a associação bloqueia o cache de credenciais, então uma conta de serviço que não consiga alcançar um DC nem que seja brevemente falhará completamente. A associação também não remove o flag DONT_REQ_PREAUTH — uma conta de serviço deixada no grupo com esse flag ainda ativado continua exatamente tão roastável quanto antes. Veja Contas Privilegiadas do Active Directory: Protected Users, Delegação e Lacunas em Contas de Serviço para onde esse grupo se aplica e onde não se aplica.

Como a EtcSec Detecta Isso

A auditoria de Active Directory da EtcSec verifica esse cluster diretamente: ADMIN_ASREP_ROASTABLE marca membros de grupos privilegiados com pré-autenticação Kerberos desativada, SERVICE_ACCOUNT_NO_PREAUTH cobre o mesmo flag em qualquer conta de serviço com SPN, SERVICE_ACCOUNT_INTERACTIVE marca contas de serviço observadas ou configuradas para logon interativo, e SERVICE_ACCOUNT_OLD_PASSWORD marca contas de serviço cuja senha não foi rotacionada dentro da política. Nenhuma dessas verificações exige simulação de ataque ao vivo — são checagens de atributos LDAP e comportamento de logon executadas em toda passagem de auditoria.