Доверяй, но проверяй: история расследования инцидента на основе OSINT
Меня зовут Анастасия Гаранжа, я аналитик центра мониторинга и реагирования на инциденты МТС RED SOC.
Недавно мы столкнулись с любопытной атакой, которая ещё раз показала, что оперативность выявления инцидентов кибербезопасности почти всегда зависит от экспертности и скорости реакции аналитиков. А вот автоматизация и даже OSINT иногда бессильны, а такой случай может оказаться критическим.
Одно из основных и самых критичных свидетельств, что мы имеем дело с инцидентом информационной безопасности, — срабатывание по базе индикаторов компрометации (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 года
На момент расследования в открытых источниках ещё не было информации ни о файле с названием fundapiext.dll, ни упоминаний такого хеша, а сигнатура UDS: Trojan.Win64.Agent.a — слишком общая и размытая и говорит нам лишь о том, что найденный вредонос рассчитан на платформы Windows 32 и 64 бит.
Датой первой загрузки этого файла на VirusTotal числится 30 января 2024 года, но какое-то время он ещё провисел в «зелёном» статусе, поскольку информация от вендоров ещё не поступила. Данные о детектировании данного файла как вредоносного появились на VirusTotal только в конце февраля 2024 года и то без подробностей о поведении и связях (вкладки Relations и Behavior).
А на Alient Vault информации нет и на конец апреля.
Датой поведенческого анализа файла на VT значится 6 марта 2024 года
Статус файла fundapiext.dll на otx.alienvault.com по состоянию на 25.04.2024
Итак, имеем файл, который антивирус детектирует как подозрительный, но в открытых источниках упоминаний о нём нет. Ложное срабатывание?
Начинаем расследование
Если оставить в такой ситуации алерт без внимания и закрыть как false positive, SOC может упустить настоящий инцидент. Хотя в момент обнаружения информации по объекту в открытых источниках ещё не было, а файл не проявлял какой-либо активности на хосте вовсе, мы понимали, это не значит, что он безвреден. А ждать неделями и даже месяцами, пока информация появится в открытых источниках, абсолютно нереально с точки зрения задач SOC. Поэтому мы начали расследование.
Обнаруженный файл fundapiext.dll в метаданных имел следующую информацию:
Информация об авторстве файла
Ничего не настораживает, метаданные создают впечатление, что файл легитимный. Однако мы пошли немного дальше и, поискав информацию в открытых источниках, выяснили, что библиотека cryptlib 3.4.3 устарела и уже не поддерживается. Также мы нашли оригинальный файл библиотеки ровно с таким же авторством в метаданных — cl64.dll.
Анализ оригинального файла на 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
Не похоже на поведение криптографической библиотеки. После чтения файла начинается деобфускация — «распутывание» кода.
А вот файл C:\ProgramData\Microsoft\Vault\cache871.db, в свою очередь, тесно переплетается с С:\Windows\System32\assocnet.inf:
Обнаружено обращение к файлу assocnet.inf
INF — конфигурационный файл, в котором содержатся домены С&C. К ним будет обращаться вредоносное ПО в ходе своей активности.
Декомпиляция файла 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 не детектировались открытыми источниками вовсе. Вот, например, результаты по доменам:
По IP-адресам даже на конец апреля такая же «зелёная» ситуация.
Вывод из этого случая можно сделать следующий: информацию из открытых источников при расследовании инцидентов применять можно, но нельзя полностью на неё опираться в вопросе безвредности файла или ресурса.
В сообществах по информационной безопасности есть практика составления конкретных списков dll-файлов, используемых хакерскими группами. И это, как показывает наш кейс, отчасти бесполезно. Злоумышленники легко могут переназвать файл или внести другие незначительные корректировки, чтобы изменить хеш-сумму.
Пример подобной публикации в популярном сообществе
Поэтому, если вы сталкиваетесь с потенциально вредоносным файлом, отсутствие информации о нём в подобных базах и других открытых источниках не повод не беспокоиться. Мы советуем всегда самостоятельно анализировать файл. Только это поможет точно понять, с чем вы имеете дело.
