Как мы искали хакеров в сетевом трафике на The Standoff

Сводка по атакам из PT NAD за весь период кибербитвы The Standoff

Мы продолжаем освещать работу команды SOC (подробнее о ней в нашей предыдущей статье) на прошедшей кибербитве The Standoff. Сегодня пойдет речь о результатах мониторинга с помощью NTA-системы PT Network Attack Discovery (PT NAD), разработанной компанией Positive Technologies и выявляющей атаки на периметре и внутри сети.

За шесть дней PT NAD зафиксировал больше 8 млн атак, среди которых 778 уникальных. Большинство обнаруженных атак результат активности различных сетевых сканеров и автоматизированных сканеров уязвимостей. В нашем случае под атакой подразумевается срабатывание правила обнаружения на вредоносный сетевой трафик.

Проникновение во внутреннюю сеть

Любая атака начинается с разведки. Напомню: было 29 команд атакующих, и всем нужно было разведать инфраструктуру. Мы получили гигантский поток срабатываний на внешних периметрах компаний.

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

Атак во внутренней инфраструктуре офисов было меньше. Мы зафиксировали около 340 000 атак, уникальными из них было 313. В эту выборку, конечно, снова попали различные сканы, но они запускались уже более точечно.

Ниже я привел топ-15 инструментов, используемых атакующими. Статистика собрана на основе HTTP-заголовков клиентов в сетевом трафике, срабатываний наших правил обнаружения и публичного набора Emerging Threats.

Топ-15 инструментов, которые использовали атакующие

За счет разбора сетевых протоколов до уровня L7 и хранения сырого трафика PT NAD позволяет аналитикам ИБ выявлять еще больше угроз. Например, первая инфраструктура, в которую проникли атакующие, был офис нефтедобывающей компании Nuft. Мы увидели атаки, производимые с адресов серверного сегмента офиса. При изучении сетевого трафика стало понятно, что у части серверов был открыт 445-й порт во внешнюю сеть. Атакующие смогли подобрать пароль локального администратора на этих серверах. На скриншоте успешная сессия с NTLM-аутентификацией под локальным администратором на одном из серверов офиса Nuft.

Успешное подключение из внешней сети к серверу под локальной учетной записью по протоколу SMB

Чуть позже мы увидели атаку с применением техники OS Credential Dumping: DCSync с этого сервера. Для ее проведения нужна учетная запись с правами доменного администратора. В этом случае атака проводилась с учетной записи nuft\scanmaste, которая принадлежала команде защиты и входила в группу администраторов домена. Это означало компрометацию домена.

Атака DCSync

Ближе к концу противостояния одна команда атакующих пыталась подобрать пароль к GitLab-серверу банка Bank of FF по протоколу SSH. За счет механизма разбора протокола SSH мы легко отследили эту попытку атаки.

Подбор пароля к SSH-серверу

В итоге у атакующих получилось успешно аутентифицироваться на сервере.

Успешная интерактивная сессия по протоколу SSH

Разведка внутренней инфраструктуры

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

Получение информации о локальных пользователях на контроллере домена

Мы установили, что атакующие подключились к компьютеру пользователя по протоколу RDP через RDG-сервер. Это означало, что у них был пароль данного пользователя. В попытках выяснить, откуда атакующие его получили, мы отправились изучать сетевую активность, предшествующую атаке. Нам удалось обнаружить подозрительные соединения по протоколу HTTP. Подключения выполнялись во внешнюю сеть по IP-адресу, а не имени хоста. URL был похож на веб-клиент почтового сервера. Запрос был сделан методом POST, а это значит, что пользователь что-то отправлял на сервер.

Аутентификация на поддельном веб-сервере

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

Маскировка атакующих

Некоторые команды атакующих проявляли креативные способности при проведении своих атак. Так, одна из команд зарегистрировала доменное имя standoff356[.]com. Это доменное имя использовалось для связи с их подконтрольным сервером, например для установки реверс-шелла. Но мы все равно заметили этот подвох.

Реверс-шелл на сервер, маскирующийся под часть инфраструктуры организаторов, ч. 1Реверс-шелл на сервер, маскирующийся под часть инфраструктуры организаторов, ч. 2

В выделенном фрагменте видна активность реверс-шелла атакующих. Правило просигнализировало нам о наличии подозрительного контента в сетевом трафике, исходящем с сервера из сегмента DMZ офиса Nuft, который часто встречается при использовании RAW TCP реверс-шелла.

Продвижение и закрепление

Популярной техникой атакующих было разворачивание собственных прокси-серверов на захваченных узлах в инфраструктуре офисов. В дальнейшем хакеры использовали цепочки таких прокси для доступа к серверам во внутренней инфраструктуре. Некоторые команды тоже проявляли креативность, но весьма своеобразным способом: через неприличные пароли. В приведенной ниже сессии мы видим туннелирование через протокол SOCKS5. Учетная запись для подключения к прокси-серверу olololo. Внутри туннелировался DCERPC-трафик от имени пользователя nuft\Administrator. В сессии происходило выполнение команд через модуль Impacket WMIExec. Мы видим, что атакующие закреплялись в системе через создание задачи на запуск их прокси-сервера. При этом задачу они маскировали под службу обновления WSUS.

Удаленное выполнение команд через WMI

Также мы видим, что Exchange-сервер был лишь промежуточным, а команда исполнялась на узле 172.20.62.6.

Адрес назначения в SOCKS5-туннеле

Фишинг

При проведении фишинговых атак атакующие также пытались выделиться и придумать нестандартные имена для файлов. На скриншоте мы видим отправку письма с вложением, которое определилось в PT Sandbox как троян-загрузчик.

Письмо с вредоносным вложением

Выводы

В статье я постарался разобрать наиболее примечательные моменты прошедших киберучений. Чем дальше атакующие проникали в инфраструктуру тем сложнее становилось отличать их активность от легитимной. Большинство реализованных рисков по краже данных на финальной стадии выполнялись с использованием легитимных механизмов. К тому же, в реальных инфраструктурах зачастую отсутствует стопроцентное покрытие средствами защиты, установленными на узлах. Добиться покрытия, анализируя сетевой трафик, гораздо проще, так как достаточно настроить его зеркалирование с сетевого оборудования. При распутывании инцидентов PT NAD позволял нам максимально подробно отслеживать действия атакующих за счет хранения метаданных всех сессий и сырого трафика. В комбинации с другими нашими продуктами MaxPatrol SIEM, PT Application Firewall и PT Sandbox мы смогли добиться максимального покрытия инфраструктуры нашего виртуального полигона и на протяжении всех шести дней успешно отслеживали действия атакующих как в сети, так и на узлах.

Автор: Алексей Леднев, заместитель руководителя отдела экспертных сервисов и развития экспертного центра безопасности Positive Technologies (PT Expert Security Center)