Microsoft рассказала, как атаковавшим SolarWinds удалось скрыть операции

Microsoft рассказала, как атаковавшим SolarWinds удалось скрыть операции

Microsoft рассказала, как атаковавшим SolarWinds удалось скрыть операции

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

В декабре Microsoft и FireEye обнаружили бэкдор, который использовался  в атаке на SolarWinds. Он получил имя Sunburst (или Solorigate). Чуть позже эксперты Crowdstrike доложили о ещё нескольких вредоносах: Sunspot, Teardrop.

«Есть одна упущенная деталь в сложной цепочке атак — передача процесса от бэкдора Solorigate к загрузчику Cobalt Strike», — гласит новый пост Microsoft. — «Как показало наше расследование, атакующие убедились в том, что эти два компонента максимально разделены. Так они хотели уйти от детектирования».

Специалисты также считают, что киберпреступная группировка начала деятельность в мае 2020 года и при этом «потратила месяц на выбор жертвы и подготовку вредоносных семплов и инфраструктуры командных центров (C2)».

В Microsoft подчеркнули, что злоумышленники уделили особое внимание скрытности — каждая деталь учитывалась и обдумывалась с целью избежать обнаружения своего присутствия в системах жертв. Именно по этой причине атакующие максимально разделили выполнение загрузчика Cobalt Strike и процесс SolarWinds.

«Расчёт киберпреступников был следующим: даже если бы они потеряли имплант Cobalt Strike из-за детектирования, бэкдор SolarWinds всё равно остался бы в тени», — продолжает Microsoft.

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

Бинарники преступники переименовывали и пытались замаскировать под уже установленные в системе программы.

Десятки WordPress-плагинов оказались с бэкдором после смены владельца

У владельцев сайтов на WordPress новый повод проверить список установленных плагинов. Сразу десятки расширений оказались отключены после того, как в них нашли бэкдор, через который на сайты могла подгружаться вредоносная нагрузка.

По данным основателя Anchor Hosting Остина Гиндера, проблема затронула плагины разработчика Essential Plugin.

После смены владельца в исходный код этих расширений добавили скрытый вредоносный механизм. Несколько месяцев он никак себя не проявлял, а в начале апреля 2026 года активировался и начал использовать сайты с установленными плагинами для распространения вредоносного кода.

Масштаб истории неприятный. На сайте Essential Plugin говорится о 400 тысячах установок и более 15 тысячах клиентов, а данные каталога WordPress указывают, что затронутые плагины использовались как минимум на десятках тысяч активных сайтов. При этом WordPress уже пометил их как «permanent closure», то есть расширения убраны из каталога окончательно.

 

Особенно тревожно здесь то, что атака выглядела как классическая компрометация цепочки поставок. Пользователь ставит вроде бы привычный и рабочий плагин, а проблема появляется уже после того, как его купил новый владелец и изменил код. Гиндер отдельно обращает внимание, что WordPress не уведомляет администраторов сайтов о смене владельца плагина.

По данным The Next Web и Anchor Hosting, речь шла примерно о 30+ плагинах, а вредоносный код был внедрён ещё в августе 2025 года. Активировался он только спустя около восьми месяцев.

RSS: Новости на портале Anti-Malware.ru