Невыдуманная история расследования одного инцидента

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

С чего все начиналось

При входе в веб-интерфейс RuSIEM пользователь попадает на страницу дашбордов, где у него есть возможность оценить общее состояние системы и ее ключевые параметры. В нашем случае оператор обратился к виджету "Исходящие порты", где увидел подозрительную цифру 8888, которая появилась в облаке исходящих сетевых соединений. Так как данный порт публично не закреплен за распространенными сетевыми службами, это вызвало интерес со стороны службы безопасности (см. рис.1)

Рис. 1. Подозрительный порт 8888 в виджете "Исходящие порты"

Одновременно система выдала алерты "Подозрительный запуск приложений через WMI" и "Sysmon: Подозрительный запуск приложений через WMI" – инциденты, которые могут указывать на злонамеренные действия.

После исследования интерактивного виджета, который выявил несколько событий от систем межсетевого экранирования, оператор нашел соединения на подозрительный порт 8888 адреса 185.188.183.96, исходящие от рабочей станции oc.analitik.local 172.16.0.143. Данные события отображались в системе, так как ранее в RuSIEM были заведены логи со всех рабочих станций инфраструктуры, а также журналы коммутационного оборудования (см. рис. 3)

Рис. 3. Соединения на подозрительный порт 8888

Далее аналитик обратился к карточке инцидента, в которой был перечислен набор необходимых для старта расследования данных, а именно: хост источника событий, симптом, указывающий на создание нового процесса, имена пользователей запустившегося и родительского процессов, а также MITRE ID – указатель на технику MITRE ATT&CK, изучив которую, можно понять, чем опасен данный инцидент. Выявить угрозу помог продвинутый метод детектирования по сетевым артефактам, который заложен в правило корреляции RuSIEM. В данном случае мы увидели подозрительный запуск процесса через WMI – техника MITRE ATT&CK T1047. На станции oc.analitik.local запустился новый неизвестный процесс rdte152.exe, причем через Windows Management Interface (WMI) в служебном интерфейсе, который используют сетевые администраторы для управления инфраструктурой. Еще одной подозрительной деталью стало имя пользователя "rat" ("крыса"), так как несоответствие общепринятому именованию учетных записей может быть обусловлено традиционным сленгом хакерских группировок (см. рис. 4). IP-адрес, по которому происходило соединение, отсутствовал в базах IoC (индикаторы компрометации) и не вызвал подозрений ни у средств обнаружения вторжений, ни у антивирусного программного обеспечения. Проверив его на сайте virustotal.com, оператор все же подтвердил опасения (см. рис. 3). При ближайшем рассмотрении событий межсетевого экрана станции oc.analitik.local обнаружилось ПО, осуществившее попытку сетевого взаимодействия – rdte152.exe. Сравнив PID процесса из инцидента "Подозрительный запуск приложений по WMI" и PID процесса из события сетевого экрана, аналитик сделал вывод, что обнаруженные RuSIEM события и инцидент связаны, так как указывают на один и тот же подозрительный процесс.

Рис. 4

Для реагирования на инцидент была задействована ИТ-служба, которая срочно заблокировала учетную запись "rat" в домене и запретила на файрволе соединения с адресом 185.188.183.96. Следующий шаг – поиск информации о запуске процесса на станции через RuSIEM. Оператор создал запрос к системе для поиска по Host=172.16.0.143, process.id = 5988 (его нашли в событии межсетевого экрана станции) и event.id:1 (код события "Создание процесса").

Система нашла событие от службы расширенного мониторинга Windows – SYSMON, который сохраняет hash исполняемого файла, что позволило оператору:

• оперативно оценить программу на сайтах типа virustotal.com, не имея доступа к исполняемому файлу;

• определить повторный запуск этой программы даже в случае ее переименования.

При подробном рассмотрении события в системе RuSIEM мы видим несколько артефактов, представленных в полях таксономии события.

• ПО было запущено через интерфейс Windows Management Instrumentation (WMI).

Удаленный запуск приложений по протоколу WMI очень опасен для инфраструктуры, потому что процессы запускаются с повышенными правами и могут использоваться абсолютно на всех рабочих станциях. Чтобы блокировать источник, необходимо определить станцию, с которой произошла атака.

Для этого оператор провел поиск событий на станции по тегу 0х6D114 – идентификатора входа. Сгруппировав сотни разрозненных событий по симптомам (symptoms.id), RuSIEM представила в читаемом виде антологию происходящего.

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

Дальнейшие действия оператора SOC, специалистов ИБ и ИТ по изоляции вовлеченных станций, нахождению точек входа и нейтрализации последствий привели к успешному закрытию инцидента.

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

Использование базовых индикаторов компрометации, таких, как hash файлов, ip-адреса и доменные имена тоже бывает неэффективно – хакеры могут применять «одноразовые» сборки вредоносов и новые адреса для каждой конкретной атаки, обманывая системы защиты. Оперативно отреагировать на подобные угрозы в этом случае поможет грамотно настроенная SIEM-система.