ADG Оставить заявку
Блог Информационная безопасность 5 мин чтения

NotPetya: не вымогатель, а wiper - цепочка MeDoc -> EternalBlue -> Mimikatz -> MBR

27 июня волна накрыла Maersk, Rosneft, Merck. Разбираем цепочку заражения NotPetya и красные флаги, которые видны задним числом уже сейчас.

Контекст момента

NotPetya (27 июня 2017) - деструктивная псевдо-вымогательская атака через MeDoc, украинский вектор, wiper под маскировкой шифровальщика

27 июня около полудня по UTC начали приходить первые сообщения об остановке работы крупных компаний. К вечеру масштаб стал понятен: Maersk, Merck, Rosneft, Mondelez, несколько украинских банков и аэропорт Борисполь. Всё это - одна волна за несколько часов.

Первая реакция была предсказуемой: «WannaCry снова». Но довольно быстро стало ясно, что это не так. То, что распространялось 27 июня, использует ту же инфраструктуру - EternalBlue, SMBv1, - но логика принципиально другая. И именно эта разница делает случившееся куда хуже простого шифровальщика.

Откуда взялась точка входа

Первоначальный вектор - не фишинговое письмо и не открытый 445-й на периметре. Вектором оказался MeDoc - украинская бухгалтерская программа, де-факто обязательная для любой компании, работающей в Украине и сдающей отчётность в местные налоговые органы. Механизм обновления MeDoc был скомпрометирован, и в одном из плановых обновлений оказался trojanized-инсталлятор с бэкдором.

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

Именно поэтому удар оказался сконцентрированным в Украине и у компаний с украинским присутствием - не потому что они хуже защищены, а потому что у них был MeDoc.

Цепочка после первоначального заражения

Дальше начинается знакомая механика, но собранная иначе, чем WannaCry.

EternalBlue и Mimikatz работают вместе. После первичного заражения через MeDoc вредонос запускал два параллельных механизма распространения. Первый - EternalBlue по SMBv1 на 445, тот же, что использовал WannaCry. Второй - Mimikatz для извлечения credential из памяти LSASS и последующего lateral movement через легитимные административные протоколы: PsExec и WMIC.

Это ключевое отличие от WannaCry. WannaCry распространялся только через EternalBlue - значит, закрытый 445 или установленный MS17-010 его останавливал. Здесь если хотя бы один хост в сети заражён и на нём есть кешированные domain admin credentials - Mimikatz вытащит их и дальше пойдёт по сети через абсолютно легитимные каналы администрирования. Патч MS17-010 в этом сценарии помогает, но не достаточен.

MBR-вайпер, а не шифровальщик. Вредонос перезаписывает Master Boot Record кастомным загрузчиком и шифрует MFT (таблицу файлов NTFS). После перезагрузки машина показывает экран с требованием выкупа - внешне похоже на Petya 2016. Но в отличие от оригинального Petya здесь нет механизма расшифровки. Исследователи быстро установили, что идентификатор жертвы, который вредонос показывает на экране, генерируется случайно и не передаётся операторам. Заплатить нельзя физически - некому и некак это подтвердить.

Это означает, что перед нами wiper с интерфейсом вымогателя. Цель - уничтожение данных, а не монетизация. Выкуп на экране - маскировка или дымовая завеса.

Красные флаги в механике

Разбирая инцидент, несколько вещей бросаются в глаза сразу.

Mimikatz в арсенале - это другой класс угрозы. Инструмент извлекает plaintext-пароли и хеши из LSASS, если система не настроена иначе. Стандартная конфигурация Windows даёт Mimikatz всё, что ему нужно, включая domain admin hashes, если доменный администратор хоть раз логинился на этом хосте. Защита от этого вектора - Credential Guard (Windows 10/2016) и строгий контроль за тем, откуда домен-админы логинятся.

Цепочка обновлений как вектор атаки. До сих пор supply chain attack через vendor update - это что-то из разряда «теоретически возможно». Теперь это «случилось 27 июня». Вопрос о том, как организация верифицирует автоматические обновления от вендоров ПО, стал практическим, а не академическим.

Lateral movement через легитимные инструменты. PsExec и WMIC в корпоративной сети - это норма. SIEM-правила и IDS их не остановят, потому что не отличат легитимный деплой от вредоносного использования без дополнительного контекста. Это требует другого подхода: логирования командной строки, поведенческого анализа, ограничения того, с каких хостов вообще можно запускать PsExec.

Где это пересекается с аудитом

В рамках аудита безопасности NotPetya добавляет несколько позиций, которых раньше в типовом чеклисте не было или они были факультативными.

Privileged credential hygiene. Есть ли на хостах кешированные domain admin credentials? Логинятся ли администраторы доменного уровня на рабочие станции? Это напрямую влияет на то, насколько далеко уйдёт Mimikatz после первого заражённого хоста.

Политика автообновлений стороннего ПО. Кто и как верифицирует обновления? Есть ли staging-среда перед раскаткой на все машины? Для корпоративного ПО с широким охватом - это теперь не паранойя, а практический вопрос.

Изоляция хостов с широким административным доступом. Если MeDoc или аналог стоит на машинах бухгалтерии, а у тех же машин есть network reach до всей инфраструктуры - это прямой путь для lateral movement.

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

Контакт

Нужна такая же инженерная работа?

Опишите задачу и контекст. Ответим в течение рабочего дня, при необходимости подпишем NDA.