Playbook реагирования на supply chain атаку: изоляция, сброс credentials, lateral movement

Сегодня CISA выпустила Emergency Directive 21-01 - требование ко всем федеральным агентствам США немедленно отключить или изолировать любой экземпляр SolarWinds Orion. Не обновить, не патчнуть, не поставить в режим мониторинга - отключить физически или сетевым образом. Директива не рекомендательная, а обязательная. Для федеральных агентств - 48 часов. Это другой масштаб реакции, чем мы обычно видим.

После нашего разбора SUNBURST к нам пришли с практическим вопросом: хорошо, у клиента есть Orion, хеш совпал - что делать дальше в каком порядке? Стандартный IR-план на такую ситуацию не очень подходит: это не ransomware, не утечка базы, не дефейс. Это supply chain компрометация с неизвестным временем присутствия, широкими привилегиями Orion в сети и неопределённым lateral movement. Вот что мы отработали как последовательность.

Шаг 1: изоляция сервера управления

Первое - и это не обсуждается - физическая или сетевая изоляция Orion-сервера. Не выключение, именно изоляция: выключение уничтожает содержимое RAM, которое нужно для форензики.

# На управляемом коммутаторе - порт Orion-сервера в blackhole VLAN
# Или через Windows Firewall прямо на хосте, если нет доступа к коммутатору
New-NetFirewallRule -DisplayName "ISOLATE-ALL-OUT" `
    -Direction Outbound -Action Block -Enabled True
New-NetFirewallRule -DisplayName "ISOLATE-ALL-IN" `
    -Direction Inbound -Action Block -Enabled True

После изоляции - дамп памяти немедленно. SUNBURST и потенциально присутствующий TEARDROP могут держать в RAM данные о полученных командах и C2-коммуникации. WinPmem, Magnet RAM Capture, или любой другой инструмент, который есть под рукой. Дамп делается на внешний носитель или сетевой шар, который после этого тоже изолируется.

Шаг 2: сброс всех credentials

Это самый болезненный и самый важный шаг. SolarWinds Orion для своей работы требует учётные записи с широкими правами: доступ к Active Directory, доступ к серверам через WMI и WinRM, SNMP community strings, API-ключи к сторонним системам. Всё это потенциально скомпрометировано.

Список того, что сбрасываем в первую очередь:

• Service accounts Orion - все учётки, от имени которых работали сервисы Orion. Сброс пароля + проверка членства в группах: часто за время работы они обрастают лишними правами.
• Аккаунты администраторов, имевших доступ к серверу Orion - все. Не «вероятно имевших», а все, у кого был любой доступ за период работы заражённой версии.
• Пароль krbtgt - дважды, с интервалом больше времени жизни TGT (обычно 10 часов). Это стандартная процедура при любой компрометации с AD-доступом: сбрасываем возможность использования любых Kerberos-тикетов, выданных до сброса.
• SNMP community strings на всём сетевом оборудовании, которое мониторил Orion. Orion знал их все.
• API-ключи и сервисные пароли в конфигах Orion - экспортируем конфиг, смотрим что там хранилось.

# Сброс krbtgt - первый раз
Set-ADAccountPassword -Identity krbtgt -Reset `
    -NewPassword (ConvertTo-SecureString -AsPlainText "$(New-Guid)$(New-Guid)" -Force)

# Ждём 10+ часов, затем второй сброс
# Второй сброс нужен потому что контроллеры домена реплицируют
# и старый хеш ещё некоторое время актуален

Параллельно - список всех систем, к которым у Orion был сетевой доступ. Это потенциальная поверхность lateral movement.

Шаг 3: анализ lateral movement через Event Log

Здесь начинается то, что занимает основное время. Нужно понять: SUNBURST просто бекониловал через DNS, или C2 успел прислать команды и началось движение по сети?

Смотрим на Event Log хостов, которые были в зоне видимости Orion. Event ID, которые нас интересуют:

• 4624 / 4625 (Logon / Logon Failure) - логины от имени service accounts Orion или с IP-адреса Orion-сервера в период заражённой версии. Временной диапазон: с даты установки заражённой версии по дату изоляции.
• 4648 (Explicit Credential Logon) - использование явных credentials, часто признак lateral movement.
• 4768 / 4769 (Kerberos TGT/TGS requests) - нетипичные запросы тикетов от service accounts в нерабочее время.
• 7045 (New Service Installed) и 4697 - создание новых сервисов, один из типичных механизмов persistence.

# Запросы логинов с IP Orion-сервера на всех DC за период
$orionIP = "10.0.1.50"  # IP вашего Orion
$start = [DateTime]"2020-03-01"  # дата установки заражённой версии

Get-WinEvent -ComputerName dc01 -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4624, 4648
    StartTime = $start
} | Where-Object {
    $_.Properties[18].Value -eq $orionIP -or
    $_.Properties[8].Value  -eq $orionIP
} | Select-Object TimeCreated,
    @{n='Account';e={$_.Properties[5].Value}},
    @{n='SourceIP';e={$_.Properties[18].Value}}

Если в организации стоит SIEM - запрос туда, а не руками по каждому DC. Но если SIEM не было - Event Log на DC хранится по умолчанию до 20 МБ на канал, и за несколько месяцев он мог перезаписаться. Это одна из причин, почему мы после Zerologon начали рекомендовать увеличение размера Security Log до 1 ГБ.

Zero-trust как ответ на этот класс атак

Emergency Directive CISA - это реакция на факт. Нас интересует следующий вопрос: что структурно мешает такой атаке, если превентивно?

Ключевой принцип zero-trust применительно к Orion-подобным системам: никакой хост не получает неявно широких привилегий только потому, что он «trusted management server». Конкретно:

• Микросегментация - Orion должен иметь доступ только к портам и протоколам, необходимым для мониторинга конкретного хоста. Не «весь трафик от management VLAN разрешён». WMI на один набор хостов, SNMP на другой, и это задокументировано в firewall-политике, а не в голове у сетевика.
• Least privilege для service accounts - сервисная учётка Orion не должна быть Domain Admin. У многих так, потому что так написано в quick start guide вендора. Не принимаем.
• Мониторинг исходящего трафика от management-серверов - если Orion делает DNS-запросы к avsvmcloud.com, это должно быть видно. DNS-логирование на серверах мы обсуждали в посте про supply chain атаки применительно к другому контексту, но принцип тот же.

Компрометация management-системы страшна именно потому, что такие системы традиционно имеют привилегии, которые «нужны для работы». Zero-trust говорит: пересмотри, что именно нужно, и выдай ровно это. Тогда компрометация Orion - это компрометация Orion, а не всей инфраструктуры.

Форензика по нашим инцидентам продолжается. То, что мы описали - это playbook первых 48-72 часов. Аудит привилегий и микросегментация - то, что клиентам предстоит делать после, когда горячая фаза закончится.