Меня зовут Анастасия Гаранжа, я аналитик центра мониторинга и реагирования на инциденты МТС 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Домены С&C:

• sede.lamarinadevalencia[.]com

• lesprivatsbmptn[.]com

• www[.]brtm[.]co[.]kr

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-файлов, используемых хакерскими группами. И это, как показывает наш кейс, отчасти бесполезно. Злоумышленники легко могут переназвать файл или внести другие незначительные корректировки, чтобы изменить хеш-сумму.

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