Задание по форензике DetectLog4j CyberDefenders

Сегодня рассмотрим интересное задание по форензики с площадки CyberDefenders, которое называется DetectLog4j. Я покажу, как извле­кать и анализировать арте­фак­ты из обра­за дис­ка Windows. Мы найдем следы экс­плу­ата­ции уяз­вимос­ти Log4Shell и изучим арте­фак­ты, которые указывают на ее исполь­зовании.

Еще по теме: Форензик кейс взлома серверов под управлением Linux

Задание по форензике DetectLog4j CyberDefenders

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

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

Для прохождения задания будут использоваться следующие инструменты:

• R-Studio — приложение для вос­ста­нов­ления информации с дис­ка.
• Jadx — инструмент для соз­дания исходно­го кода Java из фай­лов Apk и Android Dex.
• DIE — утилита для опре­деле­ния типов фай­лов.
• Программы Registry Explorer, MFTECmd.
• FTK Imager — инс­тру­мент для ана­лиза и получе­ния обра­зов дис­ка.
• Ути­литы FullEventLogView.

Получение информации об объекте исследования

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

От­крываем ути­литу FTK Imager и ­мон­тиру­ем исследуемый дис­к. Для это­го открываем вклад­ку File —> Image Mounting и в поле Image File выбира­ем образ Webserver.e01, добавим следующие нас­трой­ки:

Жмем Mount. Образ диска будет примонтирован и появится сле­дующая информа­ция.

У нас нет разрешений для получения доступа к системным файлам, поэтому будем использовать программу R-Studio и выг­рузим фай­лы реес­тра, SOFTWARE, SAM, SYSTEM в катало­ге:

Теперь у нас есть информа­ция из кус­та реес­тра SYSTEM. Заг­ружаем ее в ути­литу Registry Explorer, жмем File —> Load hive, после чего выбираем иссле­дуемый файл. Данные о вре­мен­ной зоне хра­нят­ся в клю­че TimeZoneKeyName, который расположен в вет­ви:

Вре­мен­ные мет­ки во вре­мен­ной зоне — Pacific Standart Time (UTC-8). Имя машины хра­нит­ся в клю­че:

Данные об IP-адре­се компьютера находятся в клю­че:

где {ea202436-8a31-4cb6-9b59-5be0c2bc1692} — иден­тифика­тор адап­тера.

Докумен­тацию о данном клю­че реес­тра найдете на официальном сайте Мелкомягких.

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

Информа­ция о доменом имени компь­юте­ра находится в ключе:

До­мен­ное имя компь­юте­ра — cyberdefenders.org. Изучаем вет­ку реес­тра SOFTWARE, что­бы получить данные об операционной системе. Заг­ружаем эту вет­ку реес­тра в ути­литу Reg Explorer. Вер­сия ОС и текущий номер сбор­ки в клю­че:

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

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

Он хра­нит информа­цию об уста­нов­ленных прог­раммах.

Находим инте­ресу­ющий нас про­дукт, в нашем слу­чае VMware.

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

Те­перь най­дем вер­сию биб­лиоте­ки логиро­вания Log4j. Для это­го перехо­дим в каталог:

И ищем файл log4j-core-2.11.2.jar. Вер­сия биб­лиоте­ки — 2.11.2. В этом же катало­ге хра­нит­ся файл кон­фигура­ции log4j2.xml, который содер­жит уро­вень логиро­вания жур­нала биб­лиоте­ки Log4j2.

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

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

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

Поиск точки входа

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

Уяз­вимость в про­дук­те VMware vCenter Server вер­сии 6.7 находит­ся в заголов­ке X-Forwarded-For на стра­нице вхо­да

где в качес­тве полез­ной наг­рузки переда­ется стро­ка:

Пос­ле уста­нов­ки соеди­нения с сер­вером зло­умыш­ленни­ка по про­токо­лу LDAP заг­ружа­ется вре­донос­ная наг­рузка, которую выпол­няет Powershell.exe.

Про­ана­лизи­руем логи VMware vCenter Server, рас­положен­ные в катало­ге:

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

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

Что­бы опре­делить, уяз­вим ли уста­нов­ленный в сис­теме про­дукт VMware vCenter Server, зло­умыш­ленник в качес­тве наг­рузки исполь­зовал адрес:

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

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

Методы постэксплуатации

Мы выяс­нили, что зло­умыш­ленник про­экс­плу­ати­ровал уяз­вимость CVE-2021-44228 в про­дук­те VMware vCenter Server 29.12.2021 в 01.50.50 UTC. Заг­рузим логи опе­раци­онной сис­темы, для это­го откро­ем ути­литу FullEventLogView, наж­мем File —> Choose Data Source и выберем каталог, в который выг­рузили логи иссле­дуемо­го обра­за из пап­ки:

Затем перей­дем на вклад­ку 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 в клю­че:

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

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

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

Мы получи­ли файл, содер­жащий пути ко всем объ­ектам фай­ловой сис­темы, а так­же мет­ки вре­мени. С исполь­зовани­ем поис­ка най­дем файл 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. Пос­ле декоди­рова­ния заг­ружа­ется файл с ресур­са

Про­вай­дер IP-адре­са 3.145.115.94 — Amazon Technologies Inc.

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

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

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

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

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

Что­бы сох­ранить пос­тоян­ное при­сутс­твие в сис­теме, зло­умыш­ленни­ки исполь­зовали вет­ку 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 и выг­рузим файл:

Откро­ем его в ути­лите jadx и най­дем зна­чение, хра­няще­еся в перемен­ной:

Заключение

По резуль­татам решения форензик-кейса DetectLog4j CyberDefenders мы научи­лись извле­кать из опе­раци­онной сис­темы 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.

Полезные ссылки:

• Особенности форензики в Windows 10
• Расследование взлома компьютера Windows