Доверяй, но проверяй: история расследования инцидента на основе OSINT

Меня зовут Анастасия Гаранжа, я аналитик центра мониторинга и реагирования на инциденты МТС RED SOC.

Недавно мы столкнулись с любопытной атакой, которая ещё раз показала, что оперативность выявления инцидентов кибербезопасности почти всегда зависит от экспертности и скорости реакции аналитиков. А вот автоматизация и даже OSINT иногда бессильны, а такой случай может оказаться критическим.

f975972375b617145a53611c9be8280e.png

Одно из основных и самых критичных свидетельств, что мы имеем дело с инцидентом информационной безопасности, — срабатывание по базе индикаторов компрометации (Indicators of compromise, IoC).

Основные индикаторы — это IP-адреса и хеш-суммы вредоносных файлов.

Такие IP-адреса идентифицируют:

  • C&C-серверы

  • домены и сайты, с которых происходит распространение вредоносных файлов

  • адреса, с которых производится сканирование портов для поиска уязвимостей

Хеш-сумма файла — уникальный идентификатор любого файла. Поэтому сработка по хешу в базе IoC однозначно указывает на вредоносность объекта.

База индикаторов компрометации — это основа для автоматизации выявления инцидентов ИБ. При этом, если какое-то средство защиты, например, антивирус — сообщает об угрозе, но в базе IoC её нет, аналитик из команды SOC должен провести расследование. Делать это надо максимально быстро — во-первых, скорость реагирования часто определяет, насколько компания в итоге пострадает от атаки, а во-вторых, у SOC есть сроки выдачи информации об инциденте и рекомендаций по противодействию, прописанные в договоре с заказчиком.

Один из первичных инструментов аналитика при расследовании события информационной безопасности в любом SOC — поиск информации в открытых источниках — OSINT. Чаще всего мы обращаемся к следующим сайтам:

  • virustotal.com — служба, функционирующая с 2004 года. Virus Total аккумулирует информацию о реакции различных антивирусов на какой-либо файл или ресурс. Сейчас Virus Total использует 70+ антивирусов различных вендоров. Но стоит учитывать, что информация от вендоров в Virus Total попадает не моментально по разным причинам. Поэтому бывают ситуации, когда реакция антивирусного ПО есть, а «интернет ещё пустой»

  • otx.alienvault.com — публичная база индикаторов компрометации, действующая с 2012 года. Основана на данных, получаемых от пользователей

  • abuseipdb.com — публичная база «отзывов» об IP-адресах, основанная на репортах пользователей

Инцидент

Всё началось 10 января 2024 года, когда антивирус обнаружил в инфраструктуре заказчика подозрительный файл C:\Windows\System32\fundapiext.dll с хеш-суммой 39C87D0ACF4B3BD569C385156CBBB4C6B92A36BB01337C616C6425F135428573.

Лог обнаружения от 10 января 2024 года

Лог обнаружения от 10 января 2024 года

На момент расследования в открытых источниках ещё не было информации ни о файле с названием fundapiext.dll, ни упоминаний такого хеша, а сигнатура UDS: Trojan.Win64.Agent.a — слишком общая и размытая и говорит нам лишь о том, что найденный вредонос рассчитан на платформы Windows 32 и 64 бит.

Датой первой загрузки этого файла на VirusTotal числится 30 января 2024 года, но какое-то время он ещё провисел в «зелёном» статусе, поскольку информация от вендоров ещё не поступила. Данные о детектировании данного файла как вредоносного появились на VirusTotal только в конце февраля 2024 года и то без подробностей о поведении и связях (вкладки Relations и Behavior).

 А на Alient Vault информации нет и на конец апреля.

Датой поведенческого анализа файла на VT значится 6 марта 2024 года

Датой поведенческого анализа файла на VT значится 6 марта 2024 года

Статус файла fundapiext.dll на otx.alienvault.com по состоянию на 25.04.2024

Статус файла fundapiext.dll на otx.alienvault.com по состоянию на 25.04.2024

Итак, имеем файл, который антивирус детектирует как подозрительный, но в открытых источниках упоминаний о нём нет. Ложное срабатывание?

Начинаем расследование

Если оставить в такой ситуации алерт без внимания и закрыть как false positive, SOC может упустить настоящий инцидент. Хотя в момент обнаружения информации по объекту в открытых источниках ещё не было, а файл не проявлял какой-либо активности на хосте вовсе, мы понимали, это не значит, что он безвреден. А ждать неделями и даже месяцами, пока информация появится в открытых источниках, абсолютно нереально с точки зрения задач SOC. Поэтому мы начали расследование.

Обнаруженный файл fundapiext.dll в метаданных имел следующую информацию:

Информация об авторстве файла

Информация об авторстве файла

Ничего не настораживает, метаданные создают впечатление, что файл легитимный. Однако мы пошли немного дальше и, поискав информацию в открытых источниках, выяснили, что библиотека cryptlib 3.4.3 устарела и уже не поддерживается. Также мы нашли оригинальный файл библиотеки ровно с таким же авторством в метаданных — cl64.dll.

9de993e5967bbc07c30eda2672b3393e.pngАнализ оригинального файла на Virus Total

Анализ оригинального файла на Virus Total

Однако у cl64.dll и fundapiext.dll различаются даты компиляции: 16.12.2015 у оригинального файла и 03.11.2022 — у исследуемого подставного.

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

Копаем глубже

В ходе реверс-инжиниринга файла fundapiext.dll аналитики МТС RED SOC вместе с коллегами из СICADA8 добыли следующую информацию:

для работы библиотеке fundapiext.dll нужен файл C:\ProgramData\Microsoft\Vault\cache871.db:

Обнаружено обращение к файлу cache871.db

Обнаружено обращение к файлу cache871.db

Не похоже на поведение криптографической библиотеки. После чтения файла начинается деобфускация — «распутывание» кода.

А вот файл C:\ProgramData\Microsoft\Vault\cache871.db, в свою очередь, тесно переплетается с С:\Windows\System32\assocnet.inf:

Обнаружено обращение к файлу assocnet.inf

Обнаружено обращение к файлу assocnet.inf

INF — конфигурационный файл, в котором содержатся домены С&C. К ним будет обращаться вредоносное ПО в ходе своей активности.

Декомпиляция файла assocnet.inf

Декомпиляция файла assocnet.inf

Так мы обнаружили следующие IoC:

Домены С&C:

IP-адреса:

  • 103.30.145[.]66

  • 222.165.255[.]196

  • 146.112.61[.]108

  • 14.63.166[.]22

После поиска добытых IoC в открытых источниках наша команда наткнулась на индикаторы компрометации, связанные с активностью под названием unc2970,  которую связывают с северокорейской группировкой Lazarus Group (она же Hidden Cobra или Zinc).

Индикатор sede.lamarinadevalencia[.]com в AlienVault как раз есть, но файл на хосте заказчика не проявлял какой-либо активности. А значит, обращение к IoC в сетевом трафике с этого хоста не детектировалось. Чтобы убедиться в принадлежности файла к вредоносам, нужно было оперативно декомпилировать найденный файл fundapiext.dll.

При этом остальные добытые из файла IoC не детектировались открытыми источниками вовсе. Вот, например, результаты по доменам:

d38e6501a68266b66e380d856b26ef90.pngb7cee07aadb1c0f533f29d93d079a078.pngbd33fab80f8717d01f13180845981870.png80ec5e23f1dcb75dceffee215e12d164.png

По IP-адресам даже на конец апреля такая же «зелёная» ситуация.

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

В сообществах по информационной безопасности есть практика составления конкретных списков dll-файлов, используемых хакерскими группами. И это, как показывает наш кейс, отчасти бесполезно. Злоумышленники легко могут переназвать файл или внести другие незначительные корректировки, чтобы изменить хеш-сумму.

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

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

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

© Habrahabr.ru