ralfhacker/kerbeus-bofBOF para abuso de Kerberos (uma implementação de algumas características importantes do Rubeus).
Beacon Object Files para abuso de Kerberos. Esta é uma implementação de algumas funcionalidades importantes do projeto Rubeus, escrita em C. O projeto oferece integração com as frameworks C2 Cobalt Strike, Havoc, AdaptixC2 e Outflank C2.
A ação asktgt constrói tráfego bruto AS-REQ (solicitação de TGT) para o usuário e chave de criptografia especificados (/rc4 ou /aes256). Uma flag /password também pode ser usada em vez de um hash - neste caso, /enctype:X usará RC4 por padrão. Se nenhum /domain for especificado, o domínio atual do computador é extraído, e se nenhum /dc for especificado, o mesmo é feito para o controlador de domínio atual do sistema. Se a autenticação for bem-sucedida, o AS-REP resultante é analisado e o KRB-CRED (um .kirbi, que inclui o TGT do usuário) é gerado como um blob base64. A flag /ptt irá "passar o ticket" e aplicar a credencial Kerberos resultante à sessão de logon atual. Outra nota de opsec: apenas um TGT pode ser aplicado por vez à sessão de logon atual, então o TGT anterior é limpo quando o novo ticket é aplicado ao usar a opção /ptt.
Para formar AS-REQs mais alinhados com solicitações genuínas, a flag /opsec pode ser usada; isso enviará um AS-REQ inicial sem pré-autenticação primeiro; se for bem-sucedido, o AS-REP resultante é descriptografado e o TGT é retornado; caso contrário, um AS-REQ com pré-autenticação é enviado em seguida.
A solicitação de um TGT sem um PAC pode ser feita usando a opção /nopac. A flag /nopreauth pode ser usada para enviar um AS-REQ sem pré-autenticação.
krb_asktgt /user:USER /password:PASSWORD [/domain:DOMAIN] [/dc:DC] [/enctype:{rc4|aes256}] [/ptt] [/nopac] [/opsec]
krb_asktgt /user:USER /aes256:HASH [/domain:DOMAIN] [/dc:DC] [/ptt] [/nopac] [/opsec]
krb_asktgt /user:USER /rc4:HASH [/domain:DOMAIN] [/dc:DC] [/ptt] [/nopac]
krb_asktgt /user:USER /nopreauth [/domain:DOMAIN] [/dc:DC] [/ptt]
A ação asktgs irá construir/analisar uma solicitação de ticket de serviço TGS-REQ/TGS-REP bruta usando o TGT especificado fornecido por /ticket:X. Este valor deve ser uma codificação base64 de um arquivo .kirbi. Se um /dc não for especificado, o controlador de domínio atual do computador é extraído e usado como destino para o tráfego da solicitação. A flag /ptt irá "passar o ticket" e aplicar o ticket de serviço resultante à sessão de logon atual. Um ou mais SPNs /service:X devem ser especificados, separados por vírgula.
Os tipos de criptografia suportados no TGS-REQ construído serão RC4_HMAC e AES256_CTS_HMAC_SHA1. Neste caso, a criptografia mutuamente suportada mais alta será usada pelo KDC para construir o ticket de serviço retornado. Se você quiser forçar chaves RC4 ou AES256, use /enctype:[rc4 or aes256].
Para formar TGS-REQs mais alinhados com solicitações genuínas, a flag /opsec pode ser usada; isso também fará com que um TGS-REQ adicional seja enviado automaticamente quando um ticket de serviço for solicitado para uma conta configurada para delegação irrestrita.
A flag /u2u foi implementada para solicitar tickets User-to-User. Juntamente com o argumento /tgs:X (usado para fornecer o TGT da conta alvo), o argumento /service:X pode ser o nome de usuário da conta para a qual o TGT fornecido é (com o argumento /tgs:X). O argumento /targetuser:X solicitará um PAC de qualquer outra conta inserindo uma seção de dados PA-FOR-USER PA com o nome de usuário do usuário alvo.
A flag /keyList foi implementada para Solicitações de Lista de Chaves do Kerberos. Essas solicitações devem utilizar um TGT parcial falsificado de um controlador de domínio somente leitura no parâmetro /ticket:BASE64. Além disso, o campo /spn:x deve ser definido para o SPN KRBTGT dentro do domínio, por ex. KRBTBT/domain.local.
krb_asktgs /ticket:BASE64 /service:SPN1,SPN2,... [/domain:DOMAIN] [/dc:DC] [/tgs:BASE64] [/targetdomain:DOMAIN] [/targetuser:USER] [/enctype:{rc4|aes256}] [/ptt] [/keylist] [/u2u] [/opsec]
A ação renew irá construir/analisar uma troca de renovação de TGT TGS-REQ/TGS-REP bruta usando o /ticket:X especificado. Este valor deve ser uma codificação base64 de um arquivo .kirbi. Se um /dc não for especificado, o controlador de domínio atual do computador é extraído e usado como destino para o tráfego de renovação. A flag /ptt irá "passar o ticket" e aplicar a credencial Kerberos resultante à sessão de logon atual.
krb_renew /ticket:BASE64 [/dc:DC] [/ptt]
Se uma conta de usuário (ou computador) estiver configurada para delegação restrita (ou seja, tem um valor de SPN no campo msds-allowedtodelegateto), esta ação pode ser usada para abusar do acesso ao SPN/servidor alvo.
Uma explicação resumida é que uma conta com delegação restrita habilitada pode solicitar tickets para si mesma como qualquer usuário, em um processo conhecido como S4U2self. Para que uma conta tenha permissão para fazer isso, ela deve ter TrustedToAuthForDelegation habilitado em sua propriedade useraccountcontrol, algo que apenas usuários elevados podem modificar por padrão. Este ticket tem a flag FORWARDABLE definida por padrão. O serviço pode então usar este ticket especialmente solicitado para solicitar um ticket de serviço para qualquer nome de entidade de serviço (SPN) especificado no campo msds-allowedtodelegateto da conta. Resumindo, se você tem controle de uma conta com TrustedToAuthForDelegation definido e um valor em msds-allowedtodelegateto, você pode se passar por qualquer usuário no domínio para os SPNs definidos no campo msds-allowedtodelegateto da conta.
O ticket S4U2self pode então ser usado como um parâmetro /tgs:Y (blob base64) para executar o processo S4U2proxy. Um valor msds-allowedtodelegateto válido para a conta deve ser fornecido (/service:X).
O parâmetro /altservice nos permite substituir qualquer nome de serviço que desejamos no arquivo KRB-CRED resultante. Um ou mais nomes de serviço alternativos podem ser fornecidos, separados por vírgula (/altservice:cifs,HOST,...).
Para formar os TGS-REQs mais alinhados com solicitações genuínas, a flag /opsec pode ser usada.
É possível, em certas circunstâncias, usar um ticket S4U2Self para se passar por usuários protegidos, a fim de escalar privilégios no sistema solicitante, conforme discutido aqui. Para este propósito, a flag /self e o argumento /altservice:X podem ser usados para gerar um ticket de serviço utilizável.
Para forjar um encaminhamento S4U2Self, apenas a chave de confiança é necessária. Usando o argumento /targetdomain:X com a flag /self e sem o argumento /targetdc, ele tratará o ticket fornecido com /ticket:X como um encaminhamento S4U2Self e solicitará apenas o ticket de serviço S4U2Self final. O /altservice:X também pode ser usado para reescrever o sname no ticket resultante.
krb_s4u /ticket:BASE64 /service:SPN {/impersonateuser:USER | /tgs:BASE64} [/domain:DOMAIN] [/dc:DC] [/altservice:SERVICE] [/ptt] [/nopac] [/opsec] [/self]
krb_cross_s4u /ticket:BASE64 /service:SPN /targetdomain:DOMAIN /targetdc:DC {/impersonateuser:USER | /tgs:BASE64} [/domain:DOMAIN] [/dc:DC] [/altservice:SERVICE] [/nopac] [/self]
A ação ptt enviará um /ticket:X (TGT ou ticket de serviço) para a sessão de logon atual através da API LsaCallAuthenticationPackage() com uma mensagem KERB_SUBMIT_TKT_REQUEST, ou (se elevado) para a sessão de logon especificada por /luid:ea4... Assim como outros parâmetros /ticket:X, o valor pode ser uma codificação base64 de um arquivo .kirbi.
krb_ptt /ticket:BASE64 [/luid:LOGONID]
A ação purge irá limpar todos os tickets Kerberos da sessão de logon atual, ou (se elevado) da sessão de logon especificada por /luid:0xA...
krb_purge [/luid:LOGONID]
A ação describe recebe um valor /ticket:X (TGT ou ticket de serviço), analisa e descreve os valores do ticket. Assim como outros parâmetros /ticket:X, o valor pode ser uma codificação base64 de um arquivo .kirbi.
krb_describe /ticket:BASE64
O klist listará informações detalhadas sobre a sessão de logon do usuário atual e os tickets Kerberos, se não elevado. Se executado de um contexto elevado (SYSTEM), informações sobre todas as sessões de logon e tickets Kerberos associados são exibidas. Informações de logon e ticket podem ser exibidas para um LogonID específico com /luid:3ea.. (se elevado).
krb_klist [/luid:LOGINID] [/user:USER] [/service:SERVICE] [/client:CLIENT]
A ação dump irá extrair os TGTs e tickets de serviço atuais se estiver em um contexto elevado (SYSTEM). Se não elevado, tickets de serviço para o usuário atual são extraídos.
krb_dump [/luid:LOGINID] [/user:USER] [/service:SERVICE] [/client:CLIENT]
A ação triage exibirá uma tabela dos tickets Kerberos do usuário atual, se não elevado. Se executado de um contexto elevado (SYSTEM), uma tabela descrevendo todos os tickets Kerberos no sistema é exibida.
krb_triage [/luid:LOGINID] [/user:USER] [/service:SERVICE] [/client:CLIENT]
Para os comandos klist, triage e dump, os tickets podem ser filtrados por /luid, /service e /client.
É necessário contexto SYSTEM.
O tgtdeleg abusa da GSS-API do Kerberos para obter um TGT utilizável para o usuário atual sem precisar de elevação no host. AcquireCredentialsHandle() é usado para obter um handle para as credenciais de segurança Kerberos do usuário atual, e InitializeSecurityContext() com a flag ISC_REQ_DELEGATE e um SPN alvo de CIFS/DC.domain.com para preparar um contexto delegado falso para enviar ao DC. Isso resulta em um AP-REQ na saída da GSS-API que contém um KRB_CRED no checksum do autenticador. A chave de sessão do ticket de serviço é extraída do cache Kerberos local e usada para descriptografar o KRB_CRED no autenticador, resultando em um TGT .kirbi utilizável.
Se a extração automática de alvo/domínio estiver falhando, um SPN conhecido de um serviço configurado com delegação irrestrita pode ser especificado com /target:SPN.
krb_tgtdeleg [/target:SPN]
O kerberoasting é usado para solicitar o ticket de serviço apropriado. O argumento /ticket:X especifica o TGT do usuário do domínio. O argumento /spn:X especifica o SPN alvo. Os argumentos /domain e /dc são opcionais e obtêm os padrões do sistema, assim como as outras ações.
O argumento /nopreauth:USER tentará enviar um AS-REQ com o serviço passado para /spn:Y para solicitar tickets de serviço.
krb_kerberoasting /spn:SPN [/nopreauth:USER] [/dc:DC] [/domain:DOMAIN]
krb_kerberoasting /spn:SPN /ticket:BASE64 [/dc:DC]
Se um usuário do domínio não tem a pré-autenticação Kerberos habilitada, um AS-REP pode ser solicitado com sucesso para o usuário, e um componente da estrutura pode ser quebrado offline como no kerberoasting. O argumento /user:X especifica o usuário alvo. Os argumentos /domain e /dc são opcionais, obtendo os padrões do sistema como as outras ações.
krb_asreproasting /user:USER [/dc:DC] [/domain:DOMAIN]
A ação hash receberá um /password:X e opcionalmente /user:USER e/ou /domain:DOMAIN. Ela gerará a representação rc4_hmac (NTLM) da senha. Se nomes de usuário e domínio forem especificados, as formas de hash aes128_cts_hmac_sha1 e aes256_cts_hmac_sha1 são geradas. Os nomes de usuário e domínio são usados como salts para as implementações AES.
krb_hash /password:PASSWORD [/user:USER] [/domain:DOMAIN]
A ação changepw receberá um blob .kirbi do TGT de um usuário e executará uma alteração de senha MS kpasswd com o valor /new:PASSWORD especificado. Se um /dc não for especificado, o controlador de domínio atual do computador é extraído e usado como destino para o tráfego de redefinição de senha.
Os argumentos /targetuser e /targetdomain podem ser usados para alterar a senha de outros usuários, desde que o usuário cujo TGT é tenha privilégios suficientes.
Observe que tanto um TGT de usuário quanto um ticket de serviço para kadmin/changepw podem ser usados para alterar a senha
krb_changepw /ticket:BASE64 /new:PASSWORD [/dc:DC] [/targetuser:USER] [/targetdomain:DOMAIN]
asktgt /cert:...describe