SolarWinds Orion: предупреждения FireEye, изоляция серверов и охота за аномальными DNS

Несколько дней назад получили от FireEye уведомление об аномальной сетевой активности в инфраструктурах, где установлен SolarWinds Orion. Детали скудные, конкретной CVE нет, но тон достаточно серьёзный, чтобы не ждать официального разбора. Начали с того, что есть.

SolarWinds Orion - распространённая платформа сетевого мониторинга, которую используют многие наши клиенты. Серверы Orion работают с высокими привилегиями, имеют доступ к сетевому оборудованию и часто торчат в DMZ или напрямую в интернет для управления удалёнными площадками. Это делает их интересной точкой входа - и хорошим местом для наблюдения за тем, что вообще происходит в инфраструктуре.

Что конкретно нас насторожило

Предупреждение FireEye описывало несколько паттернов:

• Исходящие DNS-запросы с серверов Orion к нестандартным доменам - не к тем, что обычно используются для NTP, WSUS или телеметрии SolarWinds.
• HTTP-соединения к внешним хостам в нерабочие часы, без явной корреляции с задачами мониторинга.
• Повышение привилегий - попытки использовать учётные данные Orion за пределами самого Orion.

Ни один из этих сигналов сам по себе не является однозначным взломом. SolarWinds Orion вполне легитимно делает DNS-запросы, обращается к внешним ресурсам, и его сервисные аккаунты имеют широкие права. Проблема в аномалиях - запросы к доменам, которых не было вчера, трафик, которого нет в базовом профиле.

Что сделали первым делом

Изоляция серверов Orion - не полное отключение, а сегрегация. На уровне firewall ограничили исходящий трафик до явного белого списка: официальные серверы лицензирования SolarWinds, NTP, WSUS, SNMP-опрашиваемые устройства. Всё остальное - в deny с логированием. Это моментально убрало «шум» и позволило сосредоточиться на том, что пытается пробиться через запрет.

На серверах включили расширенное аудит-логирование Windows:

• Process Creation (EventID 4688) с командной строкой - чтобы видеть, что запускается от имени сервисных аккаунтов Orion.
• Network connections (Sysmon EventID 3) если Sysmon уже стоял, или добавили его туда, где не было.
• DNS Client logs - Windows DNS Client пишет в Debug log каждый запрос; включается через wevtutil sl Microsoft-Windows-DNS-Client/Debug /e:true.

Последнее оказалось особенно полезным. DNS-клиент логирует каждый запрос с именем процесса - это позволяет отфильтровать запросы именно от процессов SolarWinds и посмотреть, что именно они спрашивают.

Анализ DNS: что искали

Собрали DNS Debug Log за несколько дней до введения ограничений и проанализировали:

Get-WinEvent -LogName 'Microsoft-Windows-DNS-Client/Debug' |
    Where-Object { $_.Message -match 'solarwinds|orion|snmp' } |
    Select-Object TimeCreated,
        @{n='Query';e={$_.Properties[0].Value}},
        @{n='PID';e={$_.Properties[2].Value}} |
    Group-Object Query |
    Sort-Object Count -Descending

Большинство запросов - ожидаемые: api.solarwinds.com, update.solarwinds.com, стандартные Microsoft-домены. Но в нескольких инфраструктурах нашлись запросы к доменам с DGA-подобными именами - длинные псевдослучайные строки в поддоменах .avsvmcloud.com и похожих зон. Такой паттерн - характерный признак C2-коммуникации через DNS.

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

Что пока неясно

Природа компрометации - неизвестна. Мы не знаем, это уязвимость в самом Orion, скомпрометированное обновление, или что-то на уровне конкретной конфигурации. Официальных сообщений от SolarWinds нет. FireEye делится индикаторами, но без объяснения механики.

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

Параллель с supply chain

Несколько недель назад мы писали о supply chain атаках через npm и PyPI - и там же отмечали, что вектор «вредоносный код в доверенном пакете» работает не только для open source. SolarWinds Orion - коммерческий продукт, и если вектор компрометации окажется именно в обновлении, это будет принципиально иной масштаб проблемы. Корпоративное ПО с широкими привилегиями, которое обновляется автоматически - это огромная поверхность атаки.

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

Состояние сейчас

Ситуация не закрыта. Orion-серверы изолированы, логирование расширено, команды клиентов уведомлены. Ждём либо официальных индикаторов от SolarWinds и FireEye, либо появления в публичных threat-feed-ах чего-то конкретного по этим доменам.

Если есть SolarWinds Orion в инфраструктуре - разумно сделать то же самое: проверить исходящий DNS-трафик от серверов Orion, временно ограничить исходящие соединения до белого списка и включить Process Creation logging на этих хостах. Это не требует ждать официального advisory - это стандартная реакция на предупреждение об аномалиях от надёжного источника. Помочь с аудитом и настройкой детектирующего логирования - в нашей практике не редкость.