SUNBURST: сверяем хеши DLL, гоняем DNS и изолируем три Orion-сервера

Сегодня FireEye опубликовал детальный технический разбор SUNBURST. То, о чём мы писали месяц назад как о «подозрительных DNS-запросах и аномальной активности», оказалось именно тем, чем казалось, - только масштаб хуже, чем предполагали.

Механика такая: обновления SolarWinds Orion версий 2019.4 через 2020.2.1, выходившие с октября 2019-го, содержали троянизированную DLL - SolarWinds.Orion.Core.BusinessLayer.dll. Загрузчик SUNBURST написан аккуратно: после установки он ждёт до двух недель, затем начинает DNS-резолвинг поддоменов avsvmcloud.com, кодируя в них информацию об инфраструктуре жертвы. C2 отвечает через CNAME, указывая на следующую стадию или давая команды. Всё это выглядит как нормальный DNS-трафик - никаких бинарных протоколов поверх HTTP, никаких экзотических портов.

У нас в октябре были инсталляции клиентов с запросами именно к avsvmcloud.com. Мы тогда это видели, но без IoC от FireEye не могли связать. Сейчас картина сложилась.

Что делаем прямо сейчас

Первый шаг - инвентаризация. Нам нужно знать, какие версии Orion стоят у каждого клиента и стоят ли они вообще. Часть инсталляций - собственные, часть - оказались в ведении самих клиентов, о которых мы знали краем уха. Собираем список.

FireEye опубликовал конкретные IoC: SHA-256 хеши заражённых DLL. Нас интересует в первую очередь SolarWinds.Orion.Core.BusinessLayer.dll в директории установки Orion (обычно C:\Program Files (x86)\SolarWinds\Orion\). Хеши из бюллетеня FireEye проверяем так:

# На каждом Orion-сервере
$dll = "C:\Program Files (x86)\SolarWinds\Orion\SolarWinds.Orion.Core.BusinessLayer.dll"
$hash = Get-FileHash $dll -Algorithm SHA256
Write-Output "$($hash.Hash)  $($hash.Path)"

Выводим хеш и сравниваем с опубликованным списком IoC. Если совпадение - сервер компрометирован с высокой вероятностью.

Параллельно - анализ DNS. DNS Debug Log, который мы включили ещё в ноябре на части серверов, сейчас даёт конкретный ответ: были ли запросы к avsvmcloud.com:

Get-WinEvent -LogName 'Microsoft-Windows-DNS-Client/Debug' |
    Where-Object { $_.Message -match 'avsvmcloud' } |
    Select-Object TimeCreated,
        @{n='Query';e={$_.Properties[0].Value}},
        @{n='ProcessId';e={$_.Properties[2].Value}}

Там, где DNS Client log не был включён - смотрим в SIEM, в firewall-логи, в прокси. avsvmcloud.com - конкретный домен, не pattern, его не пропустишь.

Что нашли: три сервера на изоляцию

По итогам проверки - три Orion-сервера с заражёнными DLL. Хеши совпали. На двух из трёх в DNS-логах есть обращения к avsvmcloud.com. На третьем логов нет, но хеш совпал - значит, DLL была, и что происходило дальше - неизвестно.

Все три сервера изолированы сетевым образом: firewall-правила режут весь исходящий трафик, кроме ICMP до gateway. Сети клиентов уведомлены. Orion не трогаем - любое изменение на хосте до форензики может затереть артефакты.

На изолированных серверах начали форензику:

• Дамп памяти - до перезагрузки, потому что SUNBURST может держать в памяти данные о C2 и полученных командах. Используем WinPmem для снятия образа.
• Копия файловой системы - образ диска через robocopy с флагами /B /COPYALL /MIR на изолированный NAS. Оригинальные timestamps не трогаем.
• Event Log в полном объёме - выгружаем все каналы через wevtutil epl в evtx-файлы. Security, System, Application, Sysmon если есть, PowerShell Operational.
• Список активных соединений на момент изоляции - netstat -anob с маппингом на процессы. Уже после изоляции, поэтому C2-соединений не будет, но список установленных сессий может дать зацепки.

Что ищем в форензике

SUNBURST, по описанию FireEye, не только DNS-беконит. После получения подтверждения от C2 он может загружать и выполнять следующие стадии - это уже TEARDROP, отдельный in-memory dropper. Следы его присутствия могут быть только в памяти и в Prefetch.

Смотрим:

• Prefetch (C:\Windows\Prefetch) - там могут быть следы запуска инструментов, которые SUNBURST скачал и запустил. Анализируем через PECmd или WinPrefetchView.
• PowerShell history - C:\Users\<user>\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt для каждого пользователя, логинившегося на сервер.
• Scheduled Tasks - SUNBURST мог создать задачи для persistence. schtasks /query /fo LIST /v > tasks.txt.
• VSS - Volume Shadow Copies могут содержать более ранние версии файлов до заражения и после, если даты снимков попадают в нужный диапазон.

Работа только начинается. У двух серверов есть DNS-обращения к avsvmcloud.com, что означает: C2 коммуникация была. Какие команды пришли в ответ - пока неизвестно. Без анализа памяти и полных логов говорить о scope компрометации рано.

Про масштаб происходящего

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

Месяц назад мы писали о supply chain атаках через npm и PyPI и там же отметили, что коммерческое ПО с широкими привилегиями - это огромная поверхность. SUNBURST это подтвердил в полной мере: троянизированный инсталляционный пакет с легитимной цифровой подписью SolarWinds, разосланный через официальные серверы обновлений, - это атака, против которой файрвол и антивирус бессильны по определению. Orion сам по себе имеет широкие привилегии в сети, и именно это делало его идеальной точкой для длительного скрытого присутствия.

Форензика на трёх серверах - это ближайшие дни. Дальше - разбор того, что произошло, и разговор с клиентами о следующих шагах. Если у вас есть SolarWinds Orion и нет уверенности в версии - аудит и проверка хешей - это первое, что нужно сделать сегодня, не завтра.