“Предположим, что до апреля 2025 года никто не заметил странную трафик-сигнатуру в своих сетях. Тихо, без спецопераций, без публичных отчётов компаний — так могло продолжаться ещё год после фактического обнаружения в декабре 2020 года.”

Что если SolarWinds не обнаружили бы ещё год?

С чего началось и как обычно воспринимается

Классическое повествование об SolarWinds выглядит так: в декабре 2020 года компания FireEye обнаружила подозрительную активность в своих сетях, связала её с троянским модулем в продукте Orion от SolarWinds, и затем началась масштабная международная кампания по выявлению заражённых систем. Цифры впечатляют: около 18 000 организаций получили обновление с вредоносным кодом, сотни из них были подвергнуты дальнейшей эксплуатации. Событие стало поводом для обсуждения supply-chain атак, доверия к коммерческому ПО и необходимости усиления мониторинга.

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

Неочевидные условия обнаружения

Почему инцидент раскрылся именно тогда? На это влияли несколько факторов, которые не всегда учитываются:

• Конкретная целевая сеть: активность была обнаружена в сети FireEye — компании, которая специализируется на угрозах и имеет соответствующие инструменты и экспертизу. Не каждый клиент SolarWinds обладал таким же уровнем мониторинга.
• Конкретный тип трафика: атака использовала механизмы, которые генерировали трафик, отличающийся от обычного для продукта Orion. Однако этот трафик мог быть маскирован под легитимные запросы к внешним ресурсам (например, к доменам, имитирующим службы обновлений).
• Временной фактор: атака уже находилась в активной фазе несколько месяцев. За это время у операторов могло накопиться достаточное количество логов для выявления паттернов, но их анализ не всегда проводится регулярно.

Если один из этих факторов отсутствовал — например, трафик был более тщательно замаскирован, или он не попал в сеть с глубоким мониторингом — обнаружение могло отложиться. Представьте, что вместо FireEye первой заметила что-то небольшая организация без SOC-а, которая решила, что это “глюк” системы и перезагрузила сервер. Инцидент мог остаться локальным и не стать публичным.

Что могло произойти за дополнительный год необнаруженного присутствия

Эволюция инструментов атаки

В первоначальной атаке использовался относительно простой бэкдор, который загружал дополнительные модули. За год необнаруженной работы атакующие могли:

• Развернуть более устойчивые механизмы persistence, встроенные не только в Orion, но и в другие компоненты инфраструктуры SolarWinds.
• Создать каналы для exfiltration данных, которые имитируют легитимный трафик резервного копирования или синхронизации с облачными службами.
• Адаптировать инструменты для целевых организаций в разных секторах, возможно, разработав специализированные модули для финансовых систем, энергетики или государственных структур.

Расширение охвата и глубины

Изначально атака затрагивала организации, которые использовали Orion. За дополнительный год:

• Список целевых организаций мог расшириться через естественный рост клиентской базы SolarWinds — новые клиенты автоматически получали заражённое обновление.
• Атакующие могли использовать уже установленный бэкдор для горизонтального перемещения внутри сетей крупных организаций, достигая систем, не связанных непосредственно с SolarWinds.
• Возможно, были разработаны методы эксплуатации других продуктов SolarWinds или даже механизмы воздействия на системы, интегрированные с Orion (например, системы мониторинга сети, SIEM).

Влияние на доверие к коммерческому ПО и регуляторику

Публичное раскрытие SolarWinds в декабре 2020 года вызвало волну регулятивных реакций: обновления требований к безопасности поставщиков ПО, усиление контроля за цепочками поставок, новые стандарты для государственных закупок. Если инцидент остался необнаруженным до, скажем, апреля 2025 года:

• Многие организации продолжали бы считать SolarWinds безопасным поставщиком, инвестируя в его продукты и расширяя их использование.
• Регулятивные изменения, связанные с supply-chain атаками, могли быть отложены или сформулированы менее решительно, поскольку не было яркого публичного примера.
• В России и других странах с локальными регуляторами (например, ФСТЭК) требования к проверке коммерческого ПО могли остаться в рамках традиционных сертификаций, без специального фокуса на риски цепочки поставок.

Технические последствия для инфраструктуры

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

Пример интеграции: Orion часто используется для мониторинга сети и систем. В случае глубокой интеграции, он может иметь доступ к данным конфигурации сетевых устройств, журналам безопасности, информации о инцидентах. За год организации могли:

• Развернуть Orion в качестве центрального элемента системы мониторинка, связав его с системами управления (например, через API).
• Настроить автоматические реакции на события, обнаруженные Orion — такие реакции могли быть использованы атакующими для манипуляции инфраструктурой.
• Внедрить Orion в среды, которые считаются высокозащищёнными (например, сегменты, предназначенные для обработки персональных данных по 152-ФЗ), увеличивая потенциальный ущерб.

[КОД: пример конфигурации API-интеграции Orion с внешней системой, который мог бы использоваться для автоматического реагирования — нужно показать, как бэкдор мог вмешиваться в этот процесс.]

Как могло произойти окончательное обнаружение в 2025 году

Предположим, инцидент не был обнаружен в 2020 году. Как он мог быть раскрыт позже? Вот несколько возможных сценариев:

• Внутреннее расследование в крупной организации: например, в банке или энергетической компании при глубоком аудите безопасности обнаружили несоответствия в трафике от систем мониторинга. Эти несоответствия могли быть связаны с другими инцидентами, что привело к обращению к поставщику.
• Случайное обнаружение в ходе тестирования: организация могла проводить тестирование на проникновение своей сети и случайно выявить аномальную активность, связанную с Orion.
• Регулятивный аудит: например, проверка ФСТЭК или аналогичного органа могла потребовать анализа всех компонентов инфраструктуры, включая коммерческое ПО, что привело к обнаружениям.
• Публичное раскрытие через утечку данных: если атакующие начали массовую exfiltration данных, одна из организаций могла заметить это и провести расследование, выявив источник.

Важно отметить, что в таком позднем раскрытии масштаб инцидента мог быть оценен гораздо выше, поскольку заражённые системы были интегрированы глубже и атака могла быть более развитой.

Что это значит для российского IT и регуляторики сегодня

Случай SolarWinds стал уроком, но урок этот мог быть получен позже и в другой форме. Для российского контекста это означает несколько практических выводов:

• Недостаточность сертификации ФСТЭК: сертификация продукта не гарантирует отсутствие бэкдоров или уязвимости в цепочке поставок. Необходимы дополнительные меры контроля за обновлениями и внутренними процессами поставщиков.
• Мониторинг трафика от коммерческого ПО: важно не только мониторить сетевой трафик вообще, но и конкретно трафик от систем управления, мониторинга и администрирования. Эти системы часто имеют широкие права и их трафик может быть пропущен как “легитимный”.
• Планирование на долгий срок: атака может оставаться необнаруженной годами. Поэтому меры защиты должны включать не только реактивные, но и проактивные элементы, такие как регулярный анализ логов интеграционных точек, аудит доверенных поставщиков и тестирование на наличие скрытых каналов.

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