Resumo do aprendizado de alguns métodos de ataque sobre a autenticação Kerberos

Processo de autenticação Kerberos

prefácio

Este artigo compartilha principalmente alguns métodos de ataque sobre a autenticação Kerberos no domínio que aprendi recentemente. É baseado na autocompreensão e é explicado desde a compreensão dos princípios até o uso de ferramentas básicas. A compreensão e a análise pessoais são relativamente longas - sem fôlego Ok, por favor me perdoe. Se houver algum erro, faça uma correção.
O processo de autenticação Kerberos é apenas uma breve descrição. Existem muitos detalhes que não são explicados abaixo, como PAC, S4U2SELF (delegação), S4U2PROXY (delegação) etc. Para uma interpretação detalhada, é recomendável ler os artigos relacionados escritos pelo mestre daiker.
O ambiente principal deste artigo é o campo de tiro Red Sun VulnStack.

Controlador de domínio owa win2008R2 192.168.52.138
host de domínio sut1 win7 192.168.52.130
- Host fora do domínio k0uaz win7 (acessível ao controlador de domínio) 192.168.52.162 envolve principalmente sujeitos e funções
Controlador de domínio Controlador de domínio, conhecido como DC, um computador, para obter gerenciamento unificado de usuários e computadores
Centro de distribuição de chaves O centro de distribuição de chaves, conhecido como KDC, é instalado no controlador de domínio por padrão, incluindo AS e TGS
Serviço de Autenticação O Serviço de Autenticação, conhecido como AS, é usado pelo KDC para autenticar o Cliente
Serviço de Concessão de Tickets O Serviço de Concessão de Tickets, conhecido como TGS, é usado para KDC distribuir Chave de Sessão (chave temporária) para Cliente e Servidor
Active Directory O Active Directory, conhecido como AD, é usado para armazenar informações relacionadas a usuários, grupos de usuários e domínios.
Cliente Cliente refere-se ao usuário.
Servidor O servidor pode ser uma conta de computador ou um serviço.

processo e princípio

A figura acima envolve três processos de retorno de solicitação: Cliente e KDC AS, Cliente e KDC TGS, Cliente e Servidor. As respostas detalhadas da solicitação são as seguintes

AS-REQ: o cliente inicia uma solicitação de autenticação para KDC (AS) e as credenciais solicitadas são o registro de data e hora criptografado pelo hash NTLM do cliente e informações de identidade, etc.
AS-REP: AS utiliza Client NTLM HASH para descriptografar, e se a verificação estiver correta, retorna um ticket TGT criptografado com KRBTGT HASH (enviado para TGS em TGS-REQ e utilizado em troca de ST). TGT contém PAC
TGS-REQ: O cliente obtém o TGT armazenado em cache localmente (não pode ser descriptografado), que pode ser usado para trocar tickets ST para acessar os serviços correspondentes do TGS
TGS-REP: TGS usa KRBTGT HASH para descriptografar TGT, se o resultado estiver correto, retorna ST (tíquete do servidor) criptografado com Server Hash (usuário da máquina HASH) do servidor que fornece o serviço
AP_REQ: O cliente leva o ST obtido ao servidor para solicitar recursos
AP_REP: O Servidor usa seu próprio Hash para descriptografar o ST. Se a descriptografia estiver correta, leva o PAC obtido para visitar o KDC para determinar se o Cliente tem permissão para acessá-lo. Depois de descriptografar o PAC, o KDC obtém o sid do usuário e as informações do grupo e julga a autoridade de acordo com a lista de controle de acesso (ACL). Se corresponder, o servidor retorna o recurso ao cliente

Problemas de segurança relacionados ao Kerberos

Passe a chave (Hash)

Passe o Hash

Pass the Hash é aplicável tanto à autenticação NTLM quanto à autenticação Kerberos, não apenas fora do domínio, mas também dentro do domínio. Na autenticação Kerberos, o AS-REQ criptografa as informações relevantes através do Client Hash e as envia para o AS. Portanto, se obtivermos o NTLM Hash do Client, podemos obter horizontalmente as permissões de outros hosts através do Pass The Hash.

usar

Aqui assumimos que obtivemos o NTLM HASH do administrador de domínio logado em uma determinada máquina de domínio

As seguintes ferramentas estão disponíveis para PTH

Para usar o Mimikatz, porque você precisa injetar credenciais no lsass, você precisa de privilégios de administrador local (bypassuac) para ativar o Sedebug e pode usar as credenciais do usuário para acessar o host no domínio após a injeção.
Use wmicexec (py ou exe) para ir para pth, sem necessidade de privilégios de administrador, adequado para execução remota direta de comandos
Use o cme para verificar em lote o pth
etc.

Tome Mimikatz como um exemplo aqui, hack user (membro do grupo de administrador local de stu1, usuário de domínio)

Não tem permissão para acessar o diretório compartilhado do controlador de domínio

Após mimikatz injetar credenciais mimikatz "privilege::debug" "sekurlsa::pth /user:a /domain:god.org/rc4:b4ab235f987be3621a4ebd862189fd34"

Passe a Chave

prompt de dados mimikatz

ntlm hash é obrigatório em XP/2003/Vista/2008 e antes de 7/2008r2/8/2012 kb2871997 (AES não disponível ou substituível); As chaves AES podem ser substituídas apenas em 8.1/2012r2 ou 7/2008r2/8/2012 com kb2871997, neste caso você pode evitar o hash ntlm.

Pass the Key só pode ser usado no domínio, e as versões que suportam a criptografia Aes são win8.1/2012r2 ou win7/2008r2/8/2012 com o patch kb2871997 instalado

usar

obter chave aes

Em seguida, use também o módulo sekurlsa::pth

mimikatz "privilege::debug" "sekurlsa::pth /user:administrator /domain:god.org /aes256:bf723755bc5f72a377bda41ca58fd925df7ee45df9a026ac5cd320102a3a2e33"

Como o host Win7 não foi corrigido, o Pass The Key falha naturalmente. No ambiente de combate real, quando o PTH com método de criptografia rc4 não é suportado, pode estar no grupo de usuários protegidos. Neste momento, você pode tentar o método de criptografia Aes128, Aes256 para PTK

Passe o hash com a área de trabalho remota (modo de administrador restrito)

2014年，Microsoft发布了KB2871997补丁，它主要囊括了Windows 8.1和Windows Server 2012 R2中增强的安全保护机制。所以，以往的例如：Windows 7，Windows 8，Windows Server 2008R2和Windows Server 2012也可以更新该补丁后获得上述安全保护机制。
————————————————————————————————————————————————
Restricted Admin RDP模式的远程桌面客户端支持：
在此更新之前，RDP登录是一种交互式登录，只有在用户提供用户名和密码之后才可以访问。以这种方式登录到RDP主机时，会将用户凭据放置在RDP主机的内存中，如果主机受到威胁，它们可能会被窃取。此更新使RDP支持网络登录，其中可以传递用户现有登录令牌以进行RDP访问的身份验证。使用此登录类型可确保RDP服务器上不存储用户的凭据。从而保护凭据

通过上述解释可以理解该模式是为了保护使用RDP登录的用户凭据，通过网络验证的登录方式，RDP服务端不会保存用户的凭据

利用

win8.1以及win2012R2以上支持Restricted Admin mode模式，win8.1以及win2012R2默认开启Restricted Admin mode
条件：Client支持Restricted Admin mode模式，Server启用Restricted Admin mode模式
由于手头缺少win2012R2，因此这里使用两台Windows10来进行Pass The Hash With Remote Desktop
首先获取NTLM HASH

Use mimikatz para injetar NTLM HASH (privilege::debug é necessário para habilitar as permissões de depuração primeiro, aqui estão algumas capturas de tela)

sekurlsa::pth /user:administrator /domain:192.168.226.137 /ntlm:9c3767903480e04c089090d27123eaf9 "/run:mstsc.exe /restrictedadmin"

/domain Especifique o nome do computador ou ip
Aqui, não escolha sempre exigir credenciais

As credenciais estão corretas, mas o modo Admin restrito não está ativado

Ligue-o através do registro (0 está ativado, 1 está desativado, são necessários privilégios totais de administrador) e, em seguida, faça uma conexão RDP novamente REG ADD "HKLM\System\CurrentControlSet\Control\Lsa" /v DisableRestrictedAdmin /t REG_DWORD /d 00000000 /f

Depois que o host remoto habilita o modo Admin restrito, a conexão RDP é bem-sucedida

Você pode ver o Hash injetado na memória

Então eu usei a conta de administrador K0uaz aqui, então o Pass The Hash With Remote Desktop precisa apenas da autoridade de administrador local do destino, não necessariamente da conta de administrador local com sid 500

No entanto, se você apenas ingressar nos Usuários da Área de Trabalho Remota e não estiver no grupo Administradores, não poderá ter sucesso, porque esse mecanismo é para administradores limitados

Torrefação AS-REP

princípio

No AS_REP, o KDC retornará uma Chave de Sessão criptografada pelo usuário NTLM Hash (a Chave de Sessões é usada para garantir a segurança da comunicação entre o cliente e o TGS)

No modo de criptografia RC4_HMAC, podemos usar o mesmo processo de criptografia para criptografar as senhas de texto simples, enumerando exaustivamente as senhas de texto simples e, em seguida, comparar os resultados da criptografia com os textos cifrados para determinar se os resultados da detonação são os mesmos. o método de downgrade de criptografia (o método usado abaixo para Kerberoast quebrar o suporte do usuário para criptografia AES e retornar os dados criptografados do tipo RC4_HMAC) para especificar que o método de criptografia máximo suportado pelo cliente é apenas RC4_HMAC, para que AS_REP O método de criptografia do texto cifrado retornado é RC4_HMAC, para que possamos quebrar a senha do texto simples,
mas um problema que precisa ser resolvido aqui é o problema da pré-autenticação. No AS_REQ, um Timestamp criptografado com Client Hash será gerado e enviado para o KDC, e o KDC irá descriptografá-lo. O texto cifrado recebe um registro de data e hora. Se a descriptografia for bem-sucedida e o registro de data e hora estiver dentro de 5 minutos, a pré-autenticação foi bem-sucedida. O KDC usa este método para verificar a identidade do cliente , evitando efetivamente a quebra de força bruta

Quanto ao motivo pelo qual AS_REQ é enviado duas vezes por padrão, a explicação obtida no artigo de harmj0y é que o cliente não conhece o método de criptografia suportado com antecedência (aqui acho que é específico para o fato de o cliente não conhecer o método de criptografia de timestamp na pré-autenticação), portanto, solicite o método de criptografia suportado pelo KDC

Portanto, se a pré-autenticação estiver desativada, podemos executar uma explosão exaustiva para quebrar a senha de texto sem formatação.

Depois que a pré-autenticação for desativada, não haverá um segundo AS_REQ e o único AS_REQ não carregará o texto cifrado do carimbo de data/hora criptografado por hash NTLM

usar

Do not require Kerberos preauthenticationOs usuários do domínio com atributos podem ser consultados por meio do LDAP.As
condições de consulta específicas são as userAccountControl:1.2.840.113556.1.4.803:=4194304
seguintes, tomando o Rubeus como exemplo.Rubeus.exe asreproast /nowrap /format:hashcat

descriptografia hashcat hashcat -m 18200 hash.txt passwords.dict --force

Análise do princípio de repreensão de Rubeus

Ao analisar o tráfego com o Wireshark, pode-se ver que o princípio deste módulo é consultar os usuários do domínio das características do atributo através do LADP e, em seguida, enviar pacotes de solicitação AS_REQ em lotes, extrair a parte criptografada do NTLM Hash nos pacotes retornados, formate e gere a consulta ldap em um formato adequado para explosão de Hashcat:

Especifica que o tipo de criptografia compatível é apenas RC4_HMAC

O texto cifrado retornado é criptografado com RC4_HMAC (portanto, pode ser usado para detonação exaustiva)

nota de ouro

características

Precisa se comunicar com DC (não precisa interagir com AS, precisa se comunicar com TGS)
Precisa do hash do usuário krbtgt

princípio

Durante o processo de autenticação Kerberos do Windows, o cliente envia suas próprias informações para o KDC e, em seguida, o KDC usa o NTLM-Hash do usuário Krbtgt como a chave para criptografar e gerar um TGT. Portanto, se você obtiver o valor NTLM-Hash de Krbtgt, poderá forjar qualquer TGT? Como o Krbtgt está disponível apenas no controlador de domínio, o uso de credenciais de ouro significa que você obteve permissões de controlador de domínio antes e as credenciais de ouro podem ser entendidas como um backdoor.

doença

1. Nome de domínio
2. Valor de SID de domínio
3. HASH de senha de conta KRBTGT de domínio
4. Nome de usuário forjado, que pode ser arbitrário (dentro de 20 minutos do serviço TGT, o serviço KDC do controlador de domínio não verificará a conta de usuário no TGT)

Quando obtivermos o hash de krbtgt, podemos usá-lo para fazer notas de ouro.
Suponha que obtivemos o hash de krbtgt através do método de ataque de dcsync (explicado e praticado abaixo)

Condição 1: varredura SPN para obter o nome de domínio god.org

Condição 2: whoami /all obtém o sid do usuário do domínio e o SID do domínio remove a última string

Condição 3: Hash da conta krbtgt 58e91a5ac358d86513ab224312314061
Condição 4: Nome de usuário forjado administrator

Faça Notas Douradas

Use mimikatz kerberos::golden para forjar tgt

Golden Ticket Grupo padrão:
SID de usuários do domínio: S-1-5-21 <DOMAINID> -513
SID de administradores de domínio: S-1-5-21 <DOMAINID> -512
SID de administradores de esquema: S-1-5-21 <DOMAINID > -518
Enterprise Admin SID: S-1-5-21 <DOMAINID> -519 (funciona apenas se o tíquete falsificado for criado no domínio raiz da floresta, mas adicione o parâmetro /sids para direitos de administrador da floresta do AD) SID do proprietário do criador de políticas do grupo
: S-1-5-21 <DOMAINID>-520

mimikatz.exe "kerberos::golden /domain:god.org /sid:S-1-5-21-2952760202-1353902439-2381784089 /user:administrator /krbtgt:58e91a5ac358d86513ab224312314061 /ticket:k0u.kiribi" exit
dica: Você pode adicionar /endin:xx /renewmax:xxo período de validade do ticket de modificação e o período máximo de validade do ticket de renovação. O padrão do Mimikatz é 10 anos

O ticket gerado pode ser importado para outras máquinas de domínio, ou você pode usar diretamente /ptt para injetar tgt na memória.
Primeiro, limpe o cache do ticket klist purge

Em seguida, kerberos::ptt k0u.kiribi injete no ticket do cache através do mimikatz

Klist verifica o cache do ticket e você pode ver o tgt falso

Neste momento, uma autoridade muito alta foi obtida.

Depois que a purga do klist limpa o cache do tíquete

Tips:
普通黄金票据存在局限性，适用于单域内，不适于域森林中

Passe o Bilhete

Além da primeira etapa do Kerberos, é necessária a verificação da criptografia NTLM Hash do usuário no lado do cliente e as operações subsequentes são verificadas por tickets (Tickets). Portanto, se recebermos um ticket ou falsificarmos um ticket, podemos mover horizontalmente através do bilhete, bilhete dourado O uso de notas de prata e MS14068 pode ser considerado um método de ataque do Pass The Ticket

usar

Mimikatz

Exportar tíquetes na memória via Mimikatz

(Privilégios de administrador habilitam SeDebug) Mimikatz.exe "privilege::debug" "sekurlsa::tickets /export" exit

Neste momento, capturamos o TGT do gerenciador de domínio, podemos injetar o TGT do gerenciador de domínio no cache e usar o TGT para trocar o certificado de serviço ST correspondente do TGS (nenhum privilégio de administrador é necessário). , use god.org\hack
domain Quando um usuário (autoridade do administrador local Stu1) acessa o serviço compartilhado Cifs do controlador de domínio, ele informa que não há permissão e é negado. Aqui, o TGT do controlador de domínio é injetado no cache e pode ser acessado com sucesso.

Vermelho

Rubeus ,
usando C# para implementar alguns métodos de ataque de função no Kekeo, etc.Rubeus.exe dump >test.txt

A seta aponta para o. kirbi codificado em base64
pode exportar diretamente as credenciais codificadas em base64 através do Rubeus ou convertê-las em arquivos. O formato de arquivo pode ser Kerberos::ptt xxx.kirbi usado com contas de importação Mimikatz Rubeus.exe ptt /ticket:base64 (é necessário processar o formato de codificação base64 exportado, excluir vários espaços, Para excluir novas linhas, você pode adicionar o parâmetro /nowrap sem novas linhas)

Após a importação, você pode Rubeus.exe klist visualizar os tickets em cache

Os serviços compartilhados do controlador de domínio podem ser acessados com um tíquete de alto privilégio do controlador de domínio

/ticket:file.kirbi O formulário que também pode ser usado
pode chamar o método WriteAllBytes na classe de arquivo no namespace system.io da biblioteca de classes .net por meio do Powershell para decodificar o código base64 e gravá-lo no arquivo [IO.File]::WriteAllBytes("Adcontrol.kirbi", [Convert]::FromBase64String("处理后的凭据Base64编码"))

importar Rubeus ptt /ticket:file.kirbi

Tips:
票据文件注入内存的默认有效时间为10小时
Klist Purge清除缓存后注入的TGT也随着被清除

Kerberoasting

princípio

No TGS_REP no processo de autenticação kerberos são retornados o Server Hash (Ticket) e a Session Key (Server Session Key), sendo o mais importante o ST ticket gerado pela criptografia da chave através do NTLM Hash do serviço. Quando o algoritmo de criptografia de autenticação for RC4_HMAC (tipo de criptografia fraca), podemos usar o mesmo processo de criptografia para obter o texto cifrado por meio da senha exaustiva e comparar o texto cifrado obtido com o texto cifrado no ticket ST. Se forem iguais, a senha está correto. , Explodido com sucesso para obter o texto simples das
credenciais de serviço

(Nome da Entidade de Serviço)SPN

Os nomes principais de serviço (SPN: ServicePrincipal Names) são instâncias de serviço e a autenticação Kerberos usa SPNs para associar instâncias de serviço a contas de login de serviço.
O formato do SPN é:serviceclass/host:port/servicename

SPN é o nome exclusivo de um serviço no domínio. Existem dois tipos de SPN:

Um é registrado na conta da máquina (computadores) no AD. Quando a autoridade de um serviço é Sistema local ou serviço de rede, o SPN é registrado na conta da máquina (computadores), como SMB ou serviço de registro remoto
O outro é registrado na conta do usuário do domínio (Usuários). Quando a autoridade de um serviço é um usuário do domínio, o SPN é registrado na conta do usuário do domínio (Usuários). Neste momento, ao acessar um determinado serviço, o serviço criptografado no ticket ST devolvido O ticket é o ticket da conta de serviço, ou seja, a credencial da conta associada ao SPN e ao serviço
Dicas:
Setspn -Q */*Consulte todos os SPNs.
Você pode definir o atributo de usuário do domínio servicePrincipalName como o SPN de destino por meio do LDAP. Você
pode recuperar rapidamente quais usuários do domínio têm o atributo servicePrincipalName por meio do LDAP para encontrar o alvo de detonação (baixa autoridade é suficiente )

Pontos de implementação

寻找有价值的SPN : 寻找基于域账户的(最好是高权限)SPN，基于主机的SPN密码复杂随机且30天自动更换一次，因此难以破解
获得RC4_HMAC加密形式的ST票据 : 支持RC4_HMAC或启用AES认证加密但是未禁用RC4_HMAC

利用

首先为域用户liukaifeng01关联一个SPN

老方法
用到的工具为kerberoast
首先通过遍历SPN(筛选有价值的SPN)，然后对获得的所有SPN发起TGS请求获取ST票据缓存到本地(Mimikatz中的kerberos::ask可实现发起单个TGS请求)，再通过Mimikatz等工具导出ST凭据，然后通过爆破脚本tgsrepcrack.py尝试爆破出明文口令
新方法
用到的工具为Invoke-kerberoast
较新的方式是一步到位，(首先通过LDAP查询带有ServicePrincipalName属性的域用户)不需要发送TGS请求后通过Mimikatz导出ST凭据了，通过微软提供的类KerberosRequestorSecurityToken直接发起TGS请求，然后再返回的内容中提取加密的ST票据进行格式化，方便使用John和Hashcat来破解
这里举例使用的工具是Rubeus，该工具同样实现了Invoke-kerberoast的功能Rubeus kerberoast(普通域用户权限即可)

如果复制粘贴不方便，可以使用/outfile:path指定Hash参数的写入路径

Rubeus返回的Hash参数对应的值就是hashcat官方指定的RC4_HMAC加密方式破解的格式

kali中使用hashcat爆破hashcat -m 13100 hash.txt passwords.dict --force

加密降级突破AES加密类型

首先设置用户启用AES加密，通过AD用户和计算机管理设置liukaifeng01用户启用AES加密

LDAP查看msDS-SupportedEncryptionTypes属性

这时候再进行Kerberoast时，返回的票据加密类型为AES256

Capture o pacote e visualize TGS_REQ, você pode ver que o cliente fornece os algoritmos de criptografia suportados para o servidor, incluindo RC4e AEScriptografia

Olhando para TGS_REP, você pode descobrir que o algoritmo usado no ticket ST retornado é o tipo de criptografia mais alto suportado =>AES256

Então, aqui está uma conjectura.Se fornecermos o algoritmo de criptografia mais alto suportado em TGS_REQ RC4, o método de criptografia retornado em TGS_REP será o mesmo RC4?
Este método foi implementado no Rubeus e é realmente eficaz.Rubeus kerberoast /tgtdeleg

Os algoritmos de criptografia suportados no pacote de solicitação TGS_REQ são apenasRC4

liukaifeng01Embora o método de criptografia suportado pelos usuários do domínio seja AES, o que é obtido é um RC4tíquete criptografado. O tíquete obtido dessa maneira ainda pode ser quebrado.
A única maneira de resolver a degradação da criptografia é desativá-la completamente na política de segurança Autenticação Kerberos no política de grupo.RC4
notas de prata

características
Não requer interação com controlador de domínio (KDC)
Precisa do NTLM Hash do serviço de destino (obtenha Server Hash para falsificar TGT)

princípio

A composição do Ticket na terceira etapa da autenticação: Ticket=Server Hash(Server Session Key+Client info+End Time)
se tivermos o Server Hash, podemos forjar o ST, o servidor não conhece a Server Sessoin Key antes de receber o ST, então o mais importante em todas essas autenticações é o Server Hash, com Server Hash, podemos forjar ST para acessar serviços especificados. O Server Hash aqui se refere ao Hash do usuário da máquina, e o usuário da máquina é, na verdade, o usuário do sistema.

doença

1. Nome de domínio
2. Valor SID do domínio (valor SID, observe que o valor após o último é removido)
3. NTLM-Hash da conta do servidor no domínio
4. Nome de usuário forjado, que pode ser qualquer nome de usuário.
5 , o serviço Kerberos no servidor de destino

Faça notas de prata

Aqui ainda está pegando o controlador de domínio owa como exemplo, e obtenha o Hash da conta da máquina através do mimikatz

Depois de obter o hash, faça um ticket de prata através de mimikatz (algumas condições foram obtidas na prática do ticket de ouro acima mencionado), e o serviço de destino é cifs. Normalmente, os
usuários comuns do domínio hack não têm permissão para acessar:

Faça notas de prata através do mimikatz e importe diretamente

ver notas atuais

Acessado com sucesso o diretório compartilhado

Mas isso é diferente do tipo de criptografia normal. A falsificação de Mimikatz é o RC4 tipo de criptografia, e o SPN normal associado à conta da máquina geralmente é AES criptografado. Portanto, para o tíquete ST para forjar o serviço de acesso CIFS, o fluxo da prata bilhete Também é mais fácil identificar

Os tipos comuns de serviços falsos são os seguintes

Tips:
开启PAC验证可防御白银票据(Server发送PAC的数字签名给KDC校验)

Enumeração de nome de usuário e força bruta de senha

três condições

usuário existe

A descrição do usuário existe: error_code:eRR-PREAUTH-REQUIRED
Descrição do erro de senha:error_code:eRR-PREAUTH-FAILED

usuário inexistente

descrever:error_code:eRR-C-PRINCIPALL-UNKNOWN

kerbrute

cenas a serem usadas

Se você não estiver no domínio e não puder obter usuários no domínio por meio do protocolo LDAP ou SAMR (se você tiver o nome de usuário e a senha no domínio, também poderá obter informações por meio da interação do controlador de domínio e LDAP fora do domínio)
.
não terá logs como quebra de força bruta do LDAP (4625 - Falha ao fazer logon em uma conta)

princípio principal

Depois de enviar o pacote de solicitação AE-REQ construído, julgue se o usuário existe e se a senha está correta pela diferença entre os pacotes retornados

Enumeração de nome de usuário

dentro da regiãokerbrute_windows_amd64.exe userenum -d god.org username.txt

kerbrute_windows_amd64.exe userenum --dc 192.168.52.138 -d god.org username.txt
O endereço IP do Dc precisa ser especificado fora do domínio

spray de senha

Especifique a senha, percorra o nome de usuário kerbrute_windows_amd64.exe passwordspray -d god.org username.txt Abc123!
e envie o nome de usuário no primeiro pacote

Após o DC retornar que o nome de usuário está correto, ele envia o segundo AS-REQ, que contém o NTLM HASH da senha

pyKerbrute

A versão Python do kerbrute implementada pelo mestre 3gstudent adicionou duas funções
◼ Aumentar o suporte para o protocolo TCP
◼ Aumentar a verificação do hash NTLM

Enumeração de nome de usuário

A principal implementação de EnumADUser.py é enviar um pacote com estrutura As-REQ para modificar CnameString (corrigir sname para krbtgt)

EnumADUser.py: EnumADUser.py 192.168.52.138 god.org user.txt tcp

É um pouco diferente do pacote enviado pelo kerbrute

spray de senha

Em primeiro lugar, o pyKerbrute é dividido em dois modos, clearpassword e ntlmhash
classpassword: realizar a criptografia de texto simples em NTLM Hash e, em seguida, criptografar o registro de data e hora por meio do algoritmo de criptografia RC4-HMAC e, em seguida, usar o módulo ntlmhash para pulverizar senhas ntlmhash:
diretamente através de RC4-HMAC-MD5 Algoritmo de criptografia criptografa timestamp

ADPwdSpray.py : ADPwdSpray.py 192.168.52.138 god.org username.txt clearpassword Abc123! udp

Os pacotes de dados enviados pelo kerbrute são bastante diferentes nos algoritmos de criptografia suportados, que não são tão secretos quanto o kerbrute

pyKerbrute envia um pacote aqui, mas não o envia para determinar se o nome de usuário existe e solicita autenticação diretamente, e o algoritmo de criptografia especifica RC4-HMAC-MD5, e kerbrute suporta vários métodos de criptografia. Depois de dar uma olhada no código Kerbrute , encontrei o método de implementação
NewWithPassword Vem da biblioteca gokrb5 , que facilita a autenticação relacionada ao Kerberos para clientes e servidores e implementa muitos algoritmos de criptografia na biblioteca

Detecção de força bruta pré-autenticação do Kerberos

O Kerberos usa o protocolo de pré-autenticação Kerberos e não gera logs (4625 - Falha ao fazer logon em uma conta),
mas gera os seguintes logs:
◼ Um log é gerado quando a verificação da senha é bem-sucedida (4768 - Um tíquete de autenticação Kerberos (TGT) foi solicitado)
◼ Senha Gera logs quando a autenticação falha (4771 - Falha na pré-autenticação do Kerberos)

Verifiquei os logs em meu próprio controlador de domínio local e descobri que 4768 existe, mas o usuário está correto e a senha está errada, e 4771 não será exibido sem nenhum prompt.

sucesso

falhar

nulo

resolver

Consultando as informações, encontrei o local para modificar a política de login. Para detalhes, consulte Audit Kerberos Authentication Service

O tipo 4771 pode ser capturado após modificar a política de auditoria:

ataque dcsync

Princípio do ataque DCSync

Use o protocolo DRSR (Directory Replication Service Remote Protocol) para obter informações confidenciais do controlador de domínio,
disfarçar o host atual como um controlador de domínio (DC) e persuadir o DC real a sincronizar seu banco de dados com o DC malicioso que finge ser o host enviando um pedido

Condições de Uso

A DACL correspondente às seguintes permissões estendidas é necessária

De acordo com o artigo do mestre 3gstudent, os seguintes usuários no grupo têm as permissões acima◼Usuários
no grupo Administradores◼Usuários
no grupo Administradores de Domínio◼Usuários
no grupo Administradores Corporativos◼Contas de computador
de controladores de domínio

prática

Os usuários no grupo de administradores referidos aqui não se referem aos administradores locais na máquina do domínio, mas ao grupo de administradores locais no controlador de domínio.
Aqui está um exemplo de um usuário no grupo Administradores no Red Sun Shooting Range likaifeng01.liukaifeng01

O usuário é membro do grupo de administradores locais do controlador de domínio, mas não é membro do administrador de domínio.
Obtenha a lista de controle ACL do membro por meio de Get-DomainObjectAcl do Powerview para visualizar as três permissões acima.

DS-Replication-Get-Changes-In-Filtered-Set
DS-Replication-Get-Changes
DS-Replication-Get-Changes-All

Satisfaça as três permissões acima e exporte o Hash por meio da função dcsync do mimikatz

Você também pode adicionar diretamente os três privilégios acima a usuários de domínio comuns por meio do PowerView
e pode ter autoridade para executar ataques Dcsync. Como método de manter a autoridade, você pode primeiro adicionar um usuário de domínio comum hack e hack o Dcsync direto falhará.

Adicione três privilégios estendidos ao hack do usuário do domínio por meio do PowerView com privilégios de administrador Add-DomainObjectAcl -TargetIdentity "DC=god,DC=org" -PrincipalIdentity hack -Rights DCSync -Verbose
e visualize os privilégios de propriedade do usuário por meio de ADfind.exe ou Get-DomainObjectAcl AdFind.exe -sc getacls -sddlfilter ;;;;;god\hack -recmute

Get-ObjectAcl -Identity "dc=god,dc=org" -ResolveGUIDs | ? {$_.SecurityIdentifier -match "S-1-5-21-2952760202-1353902439-2381784089-1111"}

A captura de tela está incompleta. Foi provado acima que o usuário do hack possui essas três permissões e, em seguida, chame o módulo dcsync através do mimikatz novamente para obter todo o Hash

Em seguida, exclua os três privilégios estendidos do usuário. Você pode usar o seguinte comando Remove-DomainObjectAcl -TargetIdentity "DC=god,DC=org" -PrincipalIdentity hack -Rights DCSync -Verbose
para excluir e usar o módulo Dcsync novamente, mas não pode mais ser obtido.

Tips
Dcsync攻击可以作为权限维持的方式=>拿到高权限后可以通过Powerview中的Add-DomainObjectAcl给普通用户添加上述三个特权,使普通用户仍然可以通过Dcsync获取所有Hash

endereço da ferramenta

kerbrute pyKerbrute Rubeus kerberoast Invoke-Kerberoast

学习参考链接

上文学习总结自3gstudent文章，倾旋博客，unknowsec博客，car7n博客，Muxueo博客，harmj0y博客，安全客等等
当时看的有点太杂了，整理完笔记后发现很多粗看的文章都没记下来文章链接渗透技巧——通过Kerberos pre-auth进行用户枚举和口令爆破 Kerberos的黄金票据详解 Kerberos的白银票据详解彻底理解Windows认证 – 议题解读手把手教你入门内网渗透之二 Kerberos Pass the Hash with Remote Desktop(Restricted Admin mode)【技术分享】Kerberoasting：一种Kerberos活动目录攻击方法域渗透——Kerberoasting 高级域渗透技术之再谈Kerberoast攻击 Roasting AS-REPs

关于PAC

对于PAC有疑惑的可以看下面的下四篇文章Windows内网协议学习Kerberos篇之PAC 了解 Microsoft Kerberos PAC 验证 PAC在Kerberos认证协议中的作用什么是 Kerberos PAC

来源： https://forum.butian.net/share/614