От доменов до доменной печи. Капитан команды KiberS о ходе отборочных Standoff 17

От­бороч­ные кибер­битвы прош­ли онлайн с 28 фев­раля по 6 мар­та 2026 года. Коман­ды ата­кующих боролись за выход в финал. Учас­тни­ки сорев­новались целую неделю: инфраструк­тура полиго­на работа­ла круг­лосуточ­но. За это вре­мя им нуж­но было выпол­нить нес­коль­ко заданий, в том чис­ле:

• ре­али­зовать два кри­тичес­ких события и под­готовить отче­ты для жюри;
• ре­али­зовать шесть кри­тичес­ких событий и получить фла­ги через авто­мати­чес­кую про­вер­ку.

Фи­налис­тов отби­рали по двум кри­тери­ям: количес­тву очков и вре­мени, за которое коман­ды показа­ли резуль­тат. По ито­гам сорев­нований коман­да KiberS заняла третье мес­то — уве­рен­но зак­репилась в середи­не лидеров.

Я, Евге­ний Кабар­гин (kiberjen), капитан коман­ды KiberS. Мы спе­циали­зиру­емся на прак­тичес­кой offensive security и регуляр­но учас­тву­ем в сорев­новани­ях по кибер­битвам.

На отбо­ре Standoff 17 коман­да KiberS показа­ла высокий уро­вень под­готов­ки, сла­жен­ную работу и про­думан­ную так­тику атак. Мы ста­биль­но отыг­рали весь этап и уве­рен­но вош­ли в чис­ло силь­нейших команд.

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

От­дель­но хочу поб­лагода­рить коман­ду KiberS за работу — и во вре­мя сорев­нований, и при под­готов­ке это­го отче­та. Бла­года­ря вашей вов­лечен­ности, ини­циати­ве и готов­ности брать на себя ответс­твен­ность мы смог­ли показать отличный резуль­тат. Вы все кру­тыш­ки!

Подготовка

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

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

Даль­ше мы накида­ли гипоте­зы по воз­можным точ­кам вхо­да и век­торам атак. Опи­рались и на опи­сание инфраструк­туры, и на опыт прош­лых кибер­битв. Сра­зу заложи­ли типовые уяз­вимос­ти, воз­можные мис­конфи­ги и сце­нарии раз­вития ата­ки: от внеш­него перимет­ра во внут­реннюю сеть, а затем и в тех­нологи­чес­кий сег­мент. За счет это­го в активной фазе мы тра­тили мень­ше вре­мени на решения и били точ­нее.

От­дель­но мы разоб­рали роли в коман­де и налади­ли вза­имо­дей­ствие. Рас­пре­дели­ли зоны ответс­твен­ности: раз­ведка, экс­плу­ата­ция, пос­тэкс­плу­ата­ция и под­готов­ка отче­тов — и нас­тро­или обмен информа­цией. Это помог­ло убрать дуб­лирова­ние, сни­зить наг­рузку на учас­тни­ков и парал­лель­но про­раба­тывать нес­коль­ко век­торов ата­ки.

На отбо­роч­ном эта­пе нам дали сле­дующий ско­уп инфраструк­туры.

Внеш­ний периметр:

• 10.124.5.0/26
• 10.124.5.64/27

Внут­ренний периметр:

• 10.154.32.0/22

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

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

Разведка

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

Од­ним из пер­вых шагов мы про­ана­лизи­рова­ли DNS-инфраструк­туру. И не слу­чай­но: DNS-сер­веры час­то рас­кры­вают важ­ные детали архи­тек­туры сети — име­на хос­тов, внут­ренние сер­висы и свя­зи меж­ду ними. Ошиб­ки в нас­трой­ке DNS неред­ко поз­воля­ют вытащить эти дан­ные без слож­ной экс­плу­ата­ции.

Сна­чала мы базово прос­каниро­вали внеш­ний ско­уп по DNS (порт 53), что­бы про­верить, есть ли там дос­тупные DNS-сер­висы:

Во вре­мя ска­ниро­вания мы наш­ли DNS-сер­вер на хос­те 10.124.5.40 и про­вери­ли его на типич­ные небезо­пас­ные нас­трой­ки — в час­тнос­ти, мож­но ли выпол­нить zone transfer. Эта ошиб­ка в кон­фиге поз­воля­ет выкачать всю зону домена, вклю­чая спи­сок всех зарегис­три­рован­ных хос­тов.

Про­веря­ем это таким зап­росом:

По­пыт­ка сра­бота­ла: сер­вер без огра­ниче­ний раз­решил тран­сфер зоны. В ито­ге мы получи­ли спи­сок записей домена:

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

Так что уже на ран­нем эта­пе мы смог­ли выделить при­ори­тет­ные цели для даль­нейшей ата­ки:

• веб‑сер­вер (landing.x.stf) — воз­можная точ­ка вхо­да через веб‑при­ложе­ние;
• поч­товый сер­вер (mail.x.stf) — сце­нарии для фишин­га и атак на учет­ные записи;
• VPN-шлюз (vpn.x.stf) — потен­циаль­ный канал дос­тупа во внут­реннюю сеть;
• DNS-сер­вер (bind.x.stf) — источник допол­нитель­ной информа­ции и век­тор для даль­нейших атак.

Эти дан­ные задали нап­равле­ние всей даль­нейшей работы: мы сос­редото­чились на самых пер­спек­тивных узлах и выс­тро­или понят­ный сце­нарий ата­ки — от внеш­него перимет­ра до внут­ренне­го сег­мента.

Внешний периметр

Хост 10.124.5.36 (landing.x.stf)

По­лучив спи­сок хос­тов из DNS, мы переш­ли к деталь­ному раз­бору самых инте­рес­ных узлов. Одним из при­ори­тет­ных стал хост landing.x.stf (10.124.5.36): по наз­ванию вид­но, что на нем, ско­рее все­го, кру­тит­ся веб‑при­ложе­ние — а это типич­ная точ­ка вхо­да в инфраструк­туру.

Ска­ниро­вание хос­та показа­ло, что у него откры­ты такие сер­висы:

• SSH (22/TCP)
• HTTP (80/TCP)
• HTTP (3005/TCP)
• HTTP (8080/TCP)

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

Порт 80 — веб-приложения

Пе­рей­дя на http://landing.x.stf/, мы нат­кну­лись на кор­поратив­ный пор­тал ком­пании. На пер­вый взгляд — типовое при­ложе­ние: информа­цион­ные стра­ницы, опи­сание деятель­нос­ти и базовая навига­ция.

Но даже на этом эта­пе мы вытащи­ли полез­ную информа­цию. Про­ана­лизи­ровав кон­тент и струк­туру стра­ниц, мы соб­рали email-адре­са сот­рудни­ков — нап­ример, a_morris@x.stf и m_harris@x.stf. Поз­же их мож­но исполь­зовать для фишин­га или password spraying.

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

Ког­да мы пооб­щались с ботом, выяс­нилось, что механизм вос­ста­нов­ления устро­ен небезо­пас­но. Вмес­то нор­маль­ной про­вер­ки поль­зовате­ля — нап­ример, через токены или MFA — сис­тема, по сути, прос­то отда­вала учет­ные дан­ные в ответ на зап­рос.

Ис­поль­зуя эту логику, мы получи­ли учет­ные дан­ные сер­висной учет­ной записи:

• Email: support@x.stf
• Password: DblfYjZABjbzkUR

Учет­ные дан­ные

С эти­ми учет­ными дан­ными мы вош­ли в адми­нис­тра­тив­ную панель при­ложе­ния. Внут­ри наш­ли еще одну учет­ную запись:

• Ло­гин: agent
• Па­роль: [BeKMWzD]JCMu3$J;5GIP+VFwi7pg_

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

Порт 8080 — GeoServer

Еще одна инте­рес­ная наход­ка — веб‑интерфейс на пор­ту 8080:

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

Мы про­вери­ли стан­дар­тные учет­ные дан­ные и получи­ли дос­туп к адми­нис­тра­тив­ной панели:

• Ло­гин: admin
• Па­роль: geoserver

По­лучив дос­туп, мы выяс­нили, что на сер­вере сто­ит GeoServer 2.23.3. Затем про­вери­ли извес­тные уяз­вимос­ти и наш­ли CVE-2024-36401 — она поз­воля­ет выпол­нять про­изволь­ный код уда­лен­но, в том чис­ле без аутен­тифика­ции.

Эксплуатация CVE-2024-36401

Уяз­вимость свя­зана с некор­рек­тной обра­бот­кой вход­ных парамет­ров в OGC-зап­росах — WFS, WMS и WPS. В час­тнос­ти, параметр propertyName интер­пре­тиру­ется как XPath-выраже­ние.

GeoServer исполь­зует биб­лиоте­ку GeoTools, а та переда­ет дан­ные в Commons JXPath. Если не филь­тро­вать XPath-выраже­ния как сле­дует, их могут интер­пре­тиро­вать так, что ата­кующий смо­жет выпол­нить про­изволь­ный код на Java.

Глав­ная проб­лема в том, что уяз­вимость зат­рагива­ет не толь­ко слож­ные типы дан­ных, но и обыч­ные (simple feature types), поэто­му экс­плу­ати­ровать ее мож­но прак­тичес­ки «из короб­ки».

Экс­плу­ата­ция дает воз­можность:

• вы­пол­нять на сер­вере про­изволь­ные коман­ды;
• по­лучать уда­лен­ный шелл;
• зак­реплять­ся в сис­теме;
• раз­вивать ата­ку внут­ри сети.

Мы соб­рали OGC-зап­рос и получи­ли уда­лен­ный дос­туп к сис­теме.

По­лучен­ный шелл мы завели в наш C2-фрей­мворк KiberC2, что­бы цен­тра­лизо­ван­но управлять сес­сией и раз­вивать ата­ку даль­ше.

Зак­репив­шись на хос­те, мы переш­ли к пос­тэкс­плу­ата­ции. Для начала поис­кали кон­фиги и учет­ные дан­ные.

При ана­лизе фай­ловой сис­темы мы наш­ли кон­фигура­цион­ные фай­лы OpenVPN:

В них были парамет­ры под­клю­чения, которые откры­вали дос­туп к внут­ренне­му сег­менту сети.

С эти­ми дан­ными мы под­клю­чились к внут­ренне­му перимет­ру.

Сле­дом мы про­вери­ли, дос­тупны ли внут­ренние ресур­сы:

Ска­ниро­вание показа­ло: в сети есть SMB-сер­висы с ано­ним­ным дос­тупом, а это откры­вает допол­нитель­ные воз­можнос­ти для раз­ведки и даль­нейше­го взло­ма.

Один уяз­вимый сер­вис на внеш­нем перимет­ре дал нам не толь­ко дос­туп к хос­ту, но и выход во внут­реннюю сеть — с это­го и началось даль­нейшее раз­витие ата­ки.

Что­бы не упус­тить ничего важ­ного, мы сно­ва прош­лись по дру­гим узлам внеш­него перимет­ра — в час­тнос­ти по поч­товому сер­веру mail.x.stf, который тоже выг­лядел очень инте­рес­но.

Хост 10.124.5.11 (mail.x.stf)

Про­верив веб‑узлы внеш­него перимет­ра, мы перек­лючились на дру­гие цели, которые наш­ли на эта­пе DNS-раз­ведки. Одной из самых пер­спек­тивных ока­зал­ся поч­товый сер­вер mail.x.stf (10.124.5.11): такие узлы час­то хра­нят кри­тичес­ки важ­ные дан­ные и под­ходят для атак на поль­зовате­лей.

Пер­вичный ана­лиз показал, что на хос­те раз­вернут Microsoft Exchange. Это откры­вало воз­можнос­ти для атак через обра­бот­ку поч­ты и механиз­мы поль­зователь­ских катало­гов.

Перечисление пользователей через OAB

Од­ним из век­торов ата­ки стал ана­лиз механиз­ма Offline Address Book (OAB) — офлайн‑копии гло­баль­ной адресной кни­ги Exchange. Ее исполь­зуют кли­енты, нап­ример Microsoft Outlook, что­бы работать без пос­тоян­ного под­клю­чения к сер­веру.

При опре­делен­ных нас­трой­ках дос­туп к OAB мож­но получить без аутен­тифика­ции или поч­ти без огра­ниче­ний. Из‑за это­го OAB удоб­но исполь­зовать для перечис­ления поль­зовате­лей орга­низа­ции.

Мы вос­поль­зовались методи­кой иссле­дова­тель­ской коман­ды PT SWARM и извлек­ли дан­ные из OAB.

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

В резуль­тате вмес­то неболь­шого спис­ка поль­зовате­лей у нас ока­залась валид­ная база уче­ток, с которой мож­но идти даль­ше и раз­вивать ата­ку.

Фишинговая атака и первичный доступ

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

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

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

Повышение привилегий

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

Для это­го мы исполь­зовали GodPotato — инс­тру­мент, который экс­плу­ати­рует осо­бен­ности работы токенов Windows и под­нима­ет при­виле­гии до уров­ня SYSTEM.

По­лучив при­виле­гии SYSTEM, мы сня­ли дамп Local Security Authority и вытащи­ли из него учет­ные дан­ные и хеши паролей поль­зовате­лей.

Развитие атаки: Pass-the-Hash

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

Для под­клю­чения к хос­ту во внут­реннем сег­менте мы исполь­зовали такой зап­рос:

На этом шаге мы получи­ли адми­нис­тра­тив­ный дос­туп к внут­ренне­му хос­ту и смог­ли про­дол­жить ата­ку уже изнутри сети.

Закрепление и работа внутри периметра

Что­бы упростить даль­нейшую работу и не све­тить­ся, мы пус­тили тра­фик через наш C2-сер­вер — KiberC2.

В резуль­тате уда­лось:

• цен­тра­лизо­ван­но управлять сес­сиями;
• мар­шру­тизи­ровать тра­фик во внут­реннюю сеть;
• мас­шта­биро­вать ата­ку без пря­мого под­клю­чения к каж­дому хос­ту.

Ском­про­мети­ровав поч­товый сер­вер и учет­ные записи поль­зовате­лей, мы смог­ли:

1. По­лучить валид­ные учет­ные записи.
2. Зак­репить­ся в сис­теме.
3. По­высить при­виле­гии до уров­ня SYSTEM.
4. Из­влечь учет­ные дан­ные.
5. Про­вес­ти lateral movement во внут­ренний сег­мент.

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

Го­тово — прис­тупа­ем к реали­зации НС внут­ри перимет­ра!

Внутренний периметр

Захват системы управления инфраструктурой

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

Од­ной из таких целей стал сер­вер Microsoft System Center Configuration Manager (SCCM). Этот про­дукт широко исполь­зуют для адми­нис­три­рова­ния инфраструк­туры: раз­верты­вания соф­та, управле­ния обновле­ниями, запус­ка скрип­тов и цен­тра­лизо­ван­ного кон­тро­ля рабочих стан­ций. Если ском­про­мети­ровать SCCM, мож­но фак­тичес­ки получить кон­троль над зна­читель­ной частью домена.

Поиск уязвимости

Во вре­мя раз­ведки во внут­реннем сег­менте мы наш­ли хост SCCM и изу­чили его. Выяс­нилось, что он уяз­вим к CVE-2024-43468: проб­лема свя­зана с некор­рек­тной обра­бот­кой зап­росов к бэкенд‑ком­понен­там.

С помощью этой уяз­вимос­ти мож­но:

• вы­пол­нять про­изволь­ные SQL-зап­росы от име­ни учет­ной записи Management Point;
• ис­поль­зовать при­виле­гии уров­ня sysadmin для даль­нейше­го повыше­ния прав;
• вы­пол­нять коман­ды на уров­не ОС, нап­ример через xp_cmdshell;
• по­лучить пол­ноцен­ное RCE на сер­вере SCCM.

Так мы получи­ли пря­мой путь к ком­про­мета­ции одной из клю­чевых сис­тем инфраструк­туры.

Получаем административный доступ

С помощью CVE-2024-43468 мы выпол­нили SQL-зап­росы с повышен­ными при­виле­гиями и соз­дали в сис­теме учет­ную запись адми­нис­тра­тора.

Этот шаг помог нам зак­репить­ся в SCCM и про­дол­жить ата­ку уже с повышен­ными пра­вами.

Использование MachineAccountQuota

Даль­ше мы про­вери­ли стан­дар­тную нас­трой­ку домена — атри­бут ms-DS-MachineAccountQuota. По умол­чанию он раз­реша­ет любому аутен­тифици­рован­ному поль­зовате­лю соз­давать до десяти учет­ных записей компь­юте­ров.

Мы исполь­зовали этот механизм и соз­дали две учет­ные записи: kibers$ и kibers_approve$.

Этот под­ход час­то исполь­зуют в ата­ках на Active Directory: учет­ные записи компь­юте­ров помога­ют обхо­дить огра­ниче­ния и про­дол­жать работу с сер­висами, в том чис­ле с Microsoft Configuration Manager.

Закрепление в SCCM

Сле­дом мы зак­репились в сис­теме управле­ния. Через учет­ку dragom с дос­тупом к Microsoft SQL Server добави­ли соз­данные машин­ные акка­унты в при­виле­гиро­ван­ную груп­пу SCCM.

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

Доступ через SCCM

Для даль­нейшей работы мы исполь­зовали инс­тру­мент sccmhunter, он при­годил­ся в экс­плу­ата­ции SCCM и вза­имо­дей­ствии с его инфраструк­турой.

С его помощью мы успешно вош­ли в сис­тему и получи­ли адми­нис­тра­тив­ный дос­туп к фун­кци­ям SCCM.

Обработка критического события

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

По заданию мы соз­дали и заг­рузили вре­донос­ный скрипт, который раз­верну­ли через механиз­мы SCCM.

SCCM соз­дан для цен­тра­лизо­ван­ного управле­ния, поэто­му такой сце­нарий осо­бен­но опа­сен: зло­умыш­ленник может раз­нести вре­донос­ный код по мно­жес­тву узлов инфраструк­туры через легитим­ные механиз­мы адми­нис­три­рова­ния.

В ито­ге ком­про­мета­ция SCCM ста­ла одним из клю­чевых эта­пов ата­ки и дала нам воз­можность:

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

Этот шаг стал перелом­ным момен­том: пос­ле него ата­ку раз­вивали замет­но быс­трее и эффектив­нее.

Распространение вируса-шифровальщика

Зак­репив­шись во внут­реннем перимет­ре, мы начали искать узлы с кри­тич­ными дан­ными и сис­темы, которые откры­вают к ним дос­туп. Пер­вым делом обра­тили вни­мание на сер­вер резер­вно­го копиро­вания BACKUP.X.STF (10.154.32.166).

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

Анализ прав доступа в BloodHound

Для ана­лиза свя­зей в домене мы исполь­зовали BloodHound: он помог наг­лядно показать зависи­мос­ти меж­ду поль­зовате­лями, груп­пами и сер­висны­ми учет­ками.

Вы­ясни­лось, что поль­зовате­ли AMORRIS, MHARRIS и сер­вер BACKUP сос­тоят в груп­пе x\svc-backup-servers. У этой груп­пы есть пра­во PrincipalsAllowedToRetrieveManagedPassword для gMSA-акка­унта x\svc-backup$.

Это озна­чало, что учас­тни­ки груп­пы мог­ли получить пароль gMSA-акка­унта — точ­нее, его пред­став­ление, — а это уже кри­тичес­ки важ­ный шаг для даль­нейше­го раз­вития ата­ки.

Извлечение учетных данных gMSA

Мы обра­тили вни­мание на важ­ный нюанс: в груп­пу вхо­дил компь­ютер, а не поль­зователь. Зна­чит, извлечь пароль мож­но было толь­ко из кон­тек­ста кон­крет­ной сис­темы.

К это­му момен­ту мы уже получи­ли при­виле­гии SYSTEM, поэто­му решили работать с LDAP от име­ни компь­юте­ра.

Пос­коль­ку LDAP на кон­трол­лере домена дос­тупен толь­ко из внут­ренне­го сег­мента, мы под­няли тун­нель:

• под­няли SOCKS5-прок­си через Chisel;
• за­вер­нули тра­фик в Proxychains.

Пос­ле это­го запус­тили ути­литу gMSADumper:

Доступ к бэкап-серверу

Пос­ле это­го мы про­вери­ли пра­ва получен­ной учет­ки и выяс­нили, что svc-backup$ может обра­щать­ся к фай­ловым шарам на сер­вере BACKUP.

Мы под­клю­чились к сер­веру и наш­ли инте­рес­ный защищен­ный архив.

Ар­хив выг­рузили на машину ата­кующе­го для даль­нейше­го ана­лиза.

Восстановление пароля от архива

Что­бы рас­паковать архив, сна­чала приш­лось подоб­рать пароль. Для это­го мы исполь­зовали клас­сичес­кую связ­ку инс­тру­мен­тов:

Пос­ле брут­форса вос­ста­нови­ли пароль и получи­ли дос­туп к содер­жимому архи­ва.

Внут­ри лежали учет­ные дан­ные поль­зовате­ля support в откры­том виде.

Обработка критического события

С получен­ными учет­ными дан­ными мы под­клю­чились к целево­му сер­веру.

Что­бы выпол­нить задание, нам нуж­но было раз­вернуть и запус­тить вре­донос — шиф­роваль­щик. Мы заг­рузили бинар­ник stf-malware в каталог /tmp и запус­тили:

Пос­ле запус­ка мал­вари дан­ные на целевой сис­теме зашиф­ровались — это уже тянет на кри­тичес­кий инци­дент.

Несанкционированное изменение инвентаризационных записей

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

Разведка и доступ к целевому хосту

На эта­пе пред­варитель­ной раз­ведки мы прос­каниро­вали сеть и с помощью раз­ных инс­тру­мен­тов наш­ли дос­тупные хос­ты и сер­висы.

По­лучив хеш учет­ной записи support, мы про­вери­ли, не пере­исполь­зуют ли ее в инфраструк­туре. На нес­коль­ких узлах эти учет­ки ока­зались валид­ными (Pwn3d!), и мы смог­ли аутен­тифици­ровать­ся на хос­те CCUMINGS.

Зак­репив­шись на этом узле, мы под­няли прок­си через уже уста­нов­ленный канал KiberC2 и получи­ли дос­туп к сег­ментам сети, до которых нель­зя было дотянуть­ся нап­рямую, вклю­чая хост 10.154.32.197.

Поиск SQL-инъекций

Раз­бирая веб‑интерфейс целево­го хос­та, мы наш­ли фор­му логина, которая отправ­ляла SQL-зап­росы в бэкен­дную базу без нор­маль­ной филь­тра­ции вход­ных дан­ных.

Это ука­зыва­ло на потен­циаль­ную уяз­вимость клас­са SQL injection.

Что­бы про­верить гипоте­зу, мы перех­ватили зап­рос и под­готови­ли его к авто­мати­чес­кому ана­лизу.

Эксплуатация через sqlmap

Хо­тя уяз­вимость мож­но было экс­плу­ати­ровать вруч­ную, мы уско­рили про­цесс с помощью sqlmap, передав ему сох­ранен­ный HTTP-зап­рос.

Sqlmap под­твер­дил SQL-инъ­екцию и открыл дос­туп к более прод­винутым сце­нари­ям экс­плу­ата­ции. Мы запус­тили режим --os-shell и смог­ли выпол­нять коман­ды пря­мо на сер­вере.

Пос­ле генера­ции полез­ной наг­рузки мы дос­тавили shell через Burp Suite, прок­сируя тра­фик.

Получение удаленного доступа

Экс­плу­ата­ция уяз­вимос­ти дала нам инте­рак­тивный дос­туп к сис­теме.

Извлечение учетных данных

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

С най­ден­ными учет­ными дан­ными под­клю­чились к базе дан­ных.

Анализ структуры базы данных

Что­бы разоб­рать­ся в струк­туре дан­ных, мы сде­лали выбор­ку из таб­лицы product:

В таб­лице были све­дения о товар­ных позици­ях и их количес­тве.

Изменение данных: реализация НС

По усло­виям задания нуж­но было изме­нить количес­тво товара Wooden Pallets. Для это­го мы выпол­нили SQL-зап­рос:

Пос­ле зап­роса сис­тема изме­нила дан­ные, из‑за чего наруши­лась целос­тность учет­ной информа­ции.

Кри­тичес­кое событие успешно зафик­сирова­но.

Кража интеллектуальной собственности

Зак­репив­шись во внут­реннем перимет­ре, мы про­дол­жили искать узлы с цен­ными дан­ными. Еще на эта­пе раз­ведки наш­ли хост 10.154.32.132 с под­нятым HTTP File Server (HFS).

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

Раз у нас уже была точ­ка опо­ры на хос­те CCUMINGS и нас­тро­енное прок­сирова­ние, мы смог­ли работать с этим узлом.

Обнаружение и анализ уязвимостей

Ана­лиз сер­виса HFS показал, что он уяз­вим к CVE-2024-23692 — template injection.

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

Уяз­вимость поз­воля­ет:

• от­пра­вить спе­циаль­но сфор­мирован­ный HTTP-зап­рос без аутен­тифика­ции;
• вы­пол­нить про­изволь­ную коман­ду на целевой сис­теме;
• до­бить­ся уда­лен­ного выпол­нения кода (RCE).

Та­ким обра­зом, этот сер­вис был пря­мой точ­кой ком­про­мета­ции хос­та.

Эксплуатация уязвимости

Для экс­плу­ата­ции мы взя­ли готовый скрипт и пус­тили тра­фик через заранее нас­тро­енный прок­си — pivot через CCUMINGS:

Пос­ле выпол­нения этих команд:

1. Соз­дали новую учет­ную запись.
2. До­бави­ли поль­зовате­ля в груп­пу Administrators.

Так мы получи­ли пол­ный адми­нис­тра­тив­ный дос­туп к сис­теме.

Получаем доступ к системе

Пос­ле соз­дания учет­ной записи мы под­клю­чились к хос­ту через WinRM:

По­лучив инте­рак­тивный дос­туп, мы смог­ли работать с фай­ловой сис­темой и вытас­кивать дан­ные.

Поиск и извлечение данных

Во вре­мя ана­лиза содер­жимого хос­та наш­ли файл scada.txt.

В фай­ле лежали учет­ные дан­ные поль­зовате­ля из про­мыш­ленно­го сег­мента SCADA — логин и пароль в откры­том виде.

Утечка данных с компьютера руководителя компании

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

Для прод­вижения даль­ше мы исполь­зовали учет­ные дан­ные, которые рань­ше сня­ли с backup-сер­вера. Сна­чала нуж­но было понять, к каким хос­там мож­но под­клю­чить­ся уда­лен­но.

Поиск доступных узлов

Мы прос­каниро­вали внут­реннюю сеть и про­вери­ли, где дос­тупен сер­вис WinRM, который час­то исполь­зуют для уда­лен­ного адми­нис­три­рова­ния Windows-сис­тем.

Ска­ниро­вание показа­ло, какие хос­ты при­нима­ют уда­лен­ное под­клю­чение с име­ющи­мися учет­ными дан­ными.

Доступ к рабочей станции

С валид­ными учет­ными дан­ными мы под­клю­чились к одной из целевых сис­тем по WinRM и получи­ли инте­рак­тивный дос­туп к рабочей стан­ции поль­зовате­ля.

На этом эта­пе важ­но пом­нить: если исполь­зовать легитим­ные учет­ные записи, шанс спа­лить­ся замет­но ниже, потому что такие дей­ствия выг­лядят как обыч­ная активность адми­нис­тра­тора.

Поиск конфиденциальных данных

По­лучив дос­туп, мы начали раз­бирать фай­ловую сис­тему. В пер­вую оче­редь про­вери­ли поль­зователь­ские катало­ги — осо­бен­но C:\Users\d_mullen\Documents.

В этой дирек­тории наш­ли файл sensitive_data.txt с кон­фиден­циаль­ной информа­цией о работе ком­пании.

Критическое событие в действии

Уда­лось открыть файл и извлечь его содер­жимое — зна­чит, задание выпол­нено, а кри­тичес­кое событие успешно сра­бота­ло.

В этом сце­нарии нам уда­лось:

• ис­поль­зовать учет­ные дан­ные, получен­ные ранее;
• пе­реме­щать­ся по сети (lateral movement);
• по­лучить дос­туп к рабочей стан­ции при­виле­гиро­ван­ного поль­зовате­ля;
• най­ти и выг­рузить кон­фиден­циаль­ную информа­цию.

Этот кейс показы­вает: даже без экс­плу­ата­ции допол­нитель­ных уяз­вимос­тей зло­умыш­ленник может добить­ся серь­езно­го резуль­тата, если гра­мот­но выс­тро­ит цепоч­ку ата­ки и пов­торно исполь­зует учет­ные дан­ные.

Получение учетных данных оператора

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

Раз­вивая ата­ку, мы получи­ли дос­туп к рабочей стан­ции поль­зовате­ля CCUMMINGS. На рабочем сто­ле наш­ли исполня­емый файл, который, веро­ятно, свя­зан с вре­донос­ной активностью.

Файл выг­рузили на машину ата­кующе­го для даль­нейше­го ана­лиза.

Анализ вредоносного файла

Для ана­лиза подой­дут клас­сичес­кие инс­тру­мен­ты реверс‑инжи­нирин­га — IDA Pro или Ghidra. Но ког­да вре­мени в обрез, мож­но пой­ти дру­гим путем и под­клю­чить ИИ.

В ито­ге мы под­робно разоб­рали, как работа­ет этот файл, и выяс­нили, что это кей­лог­гер.

Прог­рамма уме­ла делать вот что:

• ус­танав­ливала гло­баль­ный хук кла­виату­ры через SetWindowsHookExW;
• пе­рех­ватыва­ла нажатия кла­виш;
• пре­обра­зовы­вала нажатия в сим­волы через ToAscii;
• фор­мирова­ла имя выход­ного фай­ла по текущей дате;
• за­писы­вала перех­вачен­ные дан­ные в файл.

Так­же уда­лось выяс­нить тех­ничес­кие харак­терис­тики:

• фор­мат фай­ла: PE32+ (Windows x86-64 GUI);
• ха­рак­терные импорты: SetWindowsHookExW, UnhookWindowsHookEx, CallNextHookEx, GetKeyboardState, GetKeyState, ToAscii;
• крип­тогра­фичес­кие API: CryptAcquireContextW, CryptGenRandom, CryptReleaseContext;
• debug path: C:\repos\Keylogger\x64\Release\Keylogger.pdb;
• SHA-256: 77edc57ed685749e594a82f83f9e1036a73d79410b95893c851890813da64c6b.

Ста­ло ясно: этот файл скрыт­но собира­ет учет­ные дан­ные поль­зовате­лей.

Определяем путь хранения данных

Ана­лиз бинаря показал, что перех­вачен­ные дан­ные сох­раня­ются во вре­мен­ной дирек­тории поль­зовате­ля.

Речь имен­но о логах нажатий кла­виш (keystroke logs), которые собира­ет кей­лог­гер.

Путь мож­но получить через API-фун­кцию GetTempPathW.

Извлечение логов

В дирек­тории с вре­мен­ными фай­лами мы наш­ли файл с име­нем по дате: 2026-01-19.

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

Анализ и декодирование данных

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

• дан­ные раз­биты на бло­ки по 23 бай­та;
• об­работ­ка идет с кон­ца фай­ла;

Как декоди­рует­ся один блок:

Пос­ле декоди­рова­ния:

• пос­ледова­тель­ность раз­ворачи­вает­ся;
• сим­волы 0x08 (backspace) уда­ляют­ся, что­бы вос­ста­новить кор­рек­тный поль­зователь­ский ввод.

Здесь исполь­зует­ся прос­тая XOR-обфуска­ция, так что о крип­тогра­фичес­кой стой­кос­ти речи не идет.

Добываем учетные данные

По это­му алго­рит­му мы написа­ли дек­риптор — скрипт для рас­шифров­ки — и вос­ста­нови­ли дан­ные, которые вво­дил поль­зователь.

В ито­ге получи­ли учет­ные дан­ные опе­рато­ра SCADA:

• user: 3ZMBq8SNcRf04dDl.

Те­перь у нас есть учет­ные дан­ные уже двух поль­зовате­лей SCADA, так что мож­но перехо­дить к финаль­ному эта­пу — ата­кам на про­мыш­ленный сег­мент.

SCADA

Каскадный простой в производстве металла

По­лучив учет­ные дан­ные опе­рато­ров и зак­репив­шись во внут­реннем перимет­ре, мы переш­ли к сле­дующе­му эта­пу — ата­ке на про­мыш­ленный сег­мент (OT).

Для это­го мы исполь­зовали про­межу­точ­ный узел дос­тупа (jump host) — через него мы вхо­дили в тех­нологи­чес­кую сеть и работа­ли с изо­лиро­ван­ными SCADA-сис­темами.

Разведка в технологической сети

С это­го узла мы прос­каниро­вали дос­тупные хос­ты в про­мыш­ленном сег­менте и наш­ли машины из SCADA-инфраструк­туры, через которые идет вза­имо­дей­ствие с про­мыш­ленны­ми кон­трол­лерами.

Клю­чевым узлом ока­зал­ся хост 10.154.33.3. Мы под­клю­чились к нему с помощью учет­ных дан­ных опе­рато­ра, которые получи­ли рань­ше (3ZMBq8SNcRf04dDl).

Анализ архитектуры SCADA

По­лучив дос­туп, мы изу­чили интерфейс SCADA и дос­тупные эле­мен­ты управле­ния. Выяс­нилось, что сис­тема свя­зана с про­мыш­ленным кон­трол­лером (PLC), который управля­ет подачей руды на про­изводс­твен­ной линии.

Ес­ли смот­реть с точ­ки зре­ния атак, тут есть нес­коль­ко воз­можных век­торов воз­дей­ствия:

• из­менение логики SCADA-про­екта;
• из­менение дан­ных в базе;
• пря­мое воз­дей­ствие на PLC.

Пер­вые два вари­анта не сра­бота­ли: мешали огра­ниче­ния дос­тупа, а нап­рямую пов­лиять на парамет­ры про­цес­са не получа­лось. Поэто­му мы перек­лючились на работу с кон­трол­лером нап­рямую.

Обнаружение PLC

Что­бы понять, по какому каналу идет обмен с PLC, мы про­ана­лизи­рова­ли сетевые соеди­нения:

В ито­ге наш­ли откры­тый порт 102/TCP — его исполь­зует про­токол Siemens S7 для свя­зи с кон­трол­лерами SIMATIC S7-1200.

Это под­твер­дило, что тех­нологи­чес­ким про­цес­сом управля­ют нап­рямую через PLC.

Определение областей памяти для работы

Что­бы изме­нить парамет­ры PLC, сна­чала нуж­но было разоб­рать­ся, в каких областях памяти хра­нят­ся управля­ющие зна­чения.

В кон­трол­лерах Siemens исполь­зуют так называ­емые Data Blocks (DB), в которых хра­нят­ся парамет­ры:

• DBW — сло­во (2 бай­та);
• DBX — отдель­ный бит;

Мы исполь­зовали спе­циаль­ный ска­нер, что­бы опре­делить активные БД. В ито­ге наш­ли учас­тки памяти, которые отве­чают за ско­рость кон­вей­ера.

Воздействие на PLC

Па­рамет­ры меняли самопис­ным скрип­том, который обща­ется с PLC по про­токо­лу S7.

По заданию нуж­но было уве­личить ско­рость кон­вей­ера подачи руды. Для это­го мы изме­нили зна­чение в соот­ветс­тву­ющем бло­ке дан­ных (Data Block):

Зна­чение 32767 — мак­симум для это­го парамет­ра, и оно рез­ко уско­рило работу обо­рудо­вания.

Обработка критического события

Пос­ле изме­нений сис­тема замети­ла ано­малию: кон­вей­ер разог­нался до недопус­тимой ско­рос­ти, из‑за чего слу­чилась ава­рия и про­изводс­тво вста­ло.

Так мы смо­дели­рова­ли кри­тичес­кий инци­дент — кас­кадный прос­той про­изводс­тва.

Этот кейс показы­вает, как ком­про­мета­ция IT-инфраструк­туры бьет по тех­нологи­чес­ким про­цес­сам и при­водит к реаль­ным сбо­ям на про­изводс­тве

Сбой в работе доменной печи

Зак­репив­шись в SCADA-сег­менте, мы про­дол­жили работу с тех­нологи­чес­кой сетью. Опи­раясь на уже най­ден­ные узлы, перек­лючились на дру­гой хост в SCADA: 10.154.33.35.

Под­клю­чились с помощью уже получен­ных учет­ных дан­ных опе­рато­ра.

Анализ интерфейса SCADA

Пос­ле вхо­да в сис­тему наш­ли новый интерфейс для управле­ния домен­ной печью.

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

Определяем параметры PLC

Как и в пре­дыду­щем сце­нарии, про­цес­сом управлял PLC SIMATIC S7-1200, поэто­му даль­ше мы работа­ли нап­рямую с кон­трол­лером.

Что­бы опре­делить, какие области памяти задей­ство­ваны — Data Blocks, — мы сно­ва вос­поль­зовались ска­нером:

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

Атака на технологический процесс

Ана­лиз логики SCADA показал: один из клю­чевых эле­мен­тов управле­ния — кла­пан подачи ресур­сов в печь.

Что­бы спро­воци­ровать кри­тичес­кое событие, нуж­но было нарушить штат­ный режим работы. Сде­лать это мож­но было, изме­нив нуж­ный параметр в ПЛК.

Мы поменя­ли зна­чение DBW18 = 512.

Этот параметр управлял сос­тоянием кла­пана. Пос­ле сме­ны зна­чения кла­пан зак­рылся, и тех­нологи­чес­кий про­цесс пошел с наруше­ниями.

Обработка критического события

Из‑за наших дей­ствий сис­тема замети­ла откло­нение от нор­маль­ной работы, и домен­ная печь дала сбой.

В ито­ге мы успешно реали­зова­ли кри­тичес­кое событие — «Сбой в работе домен­ной печи».

Дополнительный вектор атаки

Ког­да мы коп­нули логику кон­трол­лера глуб­же, наше вни­мание прив­лекла сис­тема Water Pumps — она охлажда­ет обо­рудо­вание и помога­ет ему работать ста­биль­но.

Ма­нипу­ляции с этой сис­темой мог­ли при­вес­ти к еще более серь­езным пос­ледс­тви­ям — вплоть до перег­рева и ава­рий­ных ситу­аций.

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

Взрыв из-за критической концентрации взрывчатых веществ в воздухе

Пос­ле успешной ата­ки на тех­нологи­чес­кие про­цес­сы домен­ной печи мы про­дол­жили работу с тем же SCADA-узлом 10.154.33.35.

К это­му момен­ту мы уже зак­репились в сис­теме и разоб­рались, как работа­ет PLC. Теперь мож­но было перей­ти к более слож­ному сце­нарию — спро­воци­ровать ава­рию с потен­циаль­но раз­рушитель­ными пос­ледс­тви­ями.

Разбор сценария атаки

Раз­работ­чики добави­ли допол­нитель­ную защиту: что­бы выз­вать кри­тичес­кое событие, нуж­но было выпол­нить дей­ствия в опре­делен­ной пос­ледова­тель­нос­ти.

Сце­нарий сос­тоял из двух эта­пов:

1. От­клю­чение сис­темы кон­тро­ля.
2. Из­менение парамет­ров тех­про­цес­са: нап­ример, откры­тие кла­пана.

По­ка работа­ла сис­тема кон­тро­ля, изме­нить парамет­ры не получа­лось: защит­ные механиз­мы авто­мати­чес­ки бло­киро­вали опас­ные сос­тояния.

Отключаем систему контроля

Для пер­вого эта­па мы исполь­зовали най­ден­ные ранее области памяти PLC:

В этих бло­ках хра­нились парамет­ры, которые отве­чали за сос­тояние сис­темы кон­тро­ля.

Наш скрипт изме­нил зна­чение нуж­ного бита:

В резуль­тате сис­тема кон­тро­ля отклю­чилась, а защит­ные огра­ниче­ния сня­ли.

Влияние на технологический процесс

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

Как и в пре­дыду­щем сце­нарии, кла­паном управля­ли через параметр DBW18. Мы изме­нили его зна­чение, откры­ли кла­пан и запус­тили некон­тро­лиру­емую подачу веществ в сис­тему.

Обработка критического события

В ито­ге:

• сис­тему кон­тро­ля отклю­чили;
• кла­пан откры­ли;
• кон­цен­тра­ция веществ начала быс­тро рас­ти.

Си­туация дош­ла до кри­тичес­кой точ­ки: из‑за пре­дель­ной кон­цен­тра­ции взры­воопас­ных веществ в воз­духе про­изо­шел взрыв.

Бонус: захват домена

Раз­вивая ата­ку, мы реали­зова­ли еще один сце­нарий — пол­ный зах­ват домена Active Directory. Для это­го мы исполь­зовали связ­ку уяз­вимос­тей CVE-2021-42278 и CVE-2021-42287, которая экс­плу­ати­рует осо­бен­ности аутен­тифика­ции Kerberos.

Суть уязвимостей

CVE-2021-42278 (Name Impersonation) свя­зана с некор­рек­тной обра­бот­кой атри­бута sAMAccountName в Active Directory.

Обыч­но:

• учет­ные записи компь­юте­ров окан­чива­ются сим­волом $— например, DC$;
• кон­трол­лер домена по это­му приз­наку отли­чает их от дру­гих типов учет­ных записей.

Но из‑за сла­бой валида­ции зло­умыш­ленник может:

• пе­реиме­новать учет­ную запись;
• уб­рать сим­вол $;
• сде­лать так, что­бы учет­ная запись выг­лядела как кон­трол­лер домена.

CVE-2021-42287 — уяз­вимость в Kerberos KDC (Key Distribution Center), из‑за которой он некор­рек­тно обра­баты­вает зап­росы на выдачу тикетов.

Вмес­те эти уяз­вимос­ти поз­воля­ют:

• по­лучить TGT (Ticket Granting Ticket) от име­ни кон­трол­лера домена;
• вы­дать себя за любого поль­зовате­ля;
• доб­рать­ся до прав вплоть до Domain Admin.

Эксплуатация уязвимости

Для ата­ки мы взя­ли уже ском­про­мети­рован­ную учет­ную запись x.stf/s_marshall_admin — на прак­тике подой­дет любая учет­ка с нуж­ными пра­вами.

Даль­ше выпол­нили такой скрипт:

Этот скрипт про­водит ата­ку на Kerberos и исполь­зует нес­коль­ко клю­чевых парамет­ров:

• -dc-host DC.x.stf — кон­трол­лер домена;
• -spn cifs/dc.x.stf — сер­вис, для которо­го зап­рашива­ется Kerberos-тикет;
• -impersonate administrator — поль­зователь, от име­ни которо­го выпол­няет­ся impersonation;
• x.stf/s_marshall_admin — учет­ная запись, с которой запус­кает­ся ата­ка;
• -hashes — NTLM-хеш вмес­то пароля для Pass-the-Hash.

Пос­ле запус­ка скрип­та:

1. Ма­нипу­ляция име­нем учет­ной записи (CVE-2021-42278).
2. По­луче­ние Kerberos-тикета с повышен­ными при­виле­гиями (CVE-2021-42287).
3. Соз­дание TGT от име­ни адми­нис­тра­тора домена.

Используем полученный TGT

Пос­ле успешной экс­плу­ата­ции мы получи­ли Kerberos-тикет и исполь­зовали его для даль­нейшей аутен­тифика­ции.

Для это­го мы сох­ранили его в перемен­ной окру­жения:

Даль­ше под­клю­чились к хос­ту через него:

Результат

Мы получи­ли дос­туп к домену с пра­вами адми­нис­тра­тора.

В ито­ге этот сце­нарий помог нам ском­про­мети­ровать аутен­тифика­цию Kerberos, выдать себя за адми­нис­тра­тора домена и получить пол­ный кон­троль над Active Directory.

Итоги

От­бороч­ные на Standoff 17 получи­лись для нас насыщен­ными: за неделю мы прош­ли путь от внеш­ней раз­ведки и пер­вых точек вхо­да до ком­про­мета­ции внут­ренних сис­тем, биз­нес‑сер­висов и SCADA-сег­мента. По ходу ата­ки исполь­зовали мис­конфи­ги, экс­плу­ата­цию уяз­вимос­тей, фишинг, пос­тэкс­плу­ата­цию, боковое переме­щение и работу с SCCM и PLC.

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