NotPetya: самая дорогая кибератака в истории

25 февраля 2026 г. • 10 min read

В конце июня 2017 года в Украине началось то, что на первый взгляд выглядело как «обычный ransomware»: компьютеры перезагружаются, файлы внезапно недоступны, на экране появляется требование выкупа.

Через несколько часов стало ясно: это не локальный инцидент. Это пожар.

Имя, которое запомнили, — NotPetya. До сих пор это символ того, как якобы «простая волна вредоносного ПО» может превратиться в событие, которое останавливает компании по всему миру и приносит ущерб на миллиарды.

В этом посте я хочу соединить две вещи:

Историю NotPetya: что произошло тогда и почему это стало настолько дорогим?
Практический взгляд: что это означает для «обычных» компаний сегодня — не только для Fortune 500?

Неприятное в NotPetya не в том, что он был «слишком сложным». Неприятное в том, что он пугающе реалистичен.

Почему я пишу об этом в 2026 году? Потому что сегодня мы обсуждаем deepfake‑фишинг на базе ИИ, но в реальном кризисе компании всё так же проваливаются на тех же банальных вещах, что и в 2017: отсутствие сегментации и бэкапы, которые подключены к той же «капельнице», что и продакшен.

NotPetya за 5 минут: что произошло?

Для понимания нужно разложить события по полочкам.

27 июня 2017 года NotPetya сначала появился в Украине, а затем очень быстро распространился по миру. Ключевую роль сыграло компрометированное обновление бухгалтерского софта, широко используемого в Украине (M.E.Doc). Вредонос попал внутрь не через «один глупый клик», а через механизм, который компании используют каждый день: обновления.

И это часто недооценивают: по сути, это была supply chain attack (атака через цепочку поставок). M.E.Doc — не случайная жертва, а идеальный рычаг, потому что обновления по дизайну считаются доверенными.

Урок на сегодня неприятный, но важный: вы можете идеально контролировать свою внутреннюю IT, но если компрометирован софт бухгалтера, подрядчика, ERP‑коннектор или инструмент третьей стороны — вы всё равно в зоне поражения. Риск supply chain — это не «про облака». Это очень конкретно про обновления.

Как только NotPetya оказывался в сети, речь шла уже не о единичных ПК, а о lateral movement (боковом перемещении):

Через SMB и известные уязвимости (включая EternalBlue / MS17-010 — эксплойт, утекший из набора инструментов NSA) NotPetya мог распространяться на другие Windows‑системы без участия пользователя.
Параллельно он использовал credential dumping (Mimikatz/LSASS), чтобы вытаскивать пароли/хеши из RAM и двигаться дальше уже с реальными админскими учётками.
Для удалённого выполнения применялись «обычные» админские инструменты (например, PsExec/WMI). Опасность в том, что эта смесь в логах может выглядеть как «нормальная эксплуатация».

Это и было «секретным соусом»: эксплойт для быстрых прыжков на новые системы, креды из памяти для настоящих привилегий — и масштабирование через встроенные средства.

Важно: патчи сами по себе не спасли бы. Даже если система была пропатчена от EternalBlue, она могла упасть, как только вредонос добыл где‑то в сети валидные админские креды/хеши.

NotPetya играл и со временем: он добавлял задержку и не устраивал «большой взрыв» (reboot/wipe) сразу, а лишь спустя некоторое время. Это усложняет обнаружение и, заодно, является классическим паттерном против sandboxes: вредонос не «детонирует» мгновенно, пока в фоне уже масштабируется.

Итог — ровно тот, что мы всегда видим:

Сначала несколько систем ведут себя «странно».
Затем резко «падает» целая площадка.
И если вы не реагируете очень быстро (разрывать сеть, блокировать аккаунты, закрывать границы сегментов), инцидент может стать мультисайтовым.

Почему «ransomware» был лишь маскировкой

NotPetya многие воспринимали как ransomware из‑за экрана с выкупом. Но технически и практически это было другое.

Ключевой момент: NotPetya по факту был вайпером. Цель — не заработать, а разрушить системы и остановить работу.

Это не придирка к словам. В инциденте разница огромна:

У классического ransomware (иногда) есть шанс на восстановление через ключи или переговоры.
У вайпера цель — «сломать». Перевод биткоинов не спасает.

У NotPetya есть ещё один технический штрих, который подчёркивает вайпер‑характер: он перезаписывал MBR (Master Boot Record) и шифровал MFT (Master File Table). А сама «ransomware‑логика» была реализована криво: показанный installation ID генерировался случайно и не был корректно связан с рабочим ключом расшифровки. То есть технически пути назад почти не существовало.

И именно поэтому NotPetya был настолько коварным: многие компании сначала запускали «ransomware‑плейбук», тогда как на деле требовался «disaster recovery‑плейбук».

То, что атака была про разрушение, а не про деньги, также вписывается в позднюю атрибуцию: несколько правительств публично связывали NotPetya с российскими государственными акторами.

10 млрд долларов: почему это стало таким дорогим?

Если смотреть только на ярлык «ransomware», ущерб кажется странным: «ну так восстановитесь из бэкапа».

На практике NotPetya оказался таким дорогим в первую очередь потому, что ударил туда, где бюджеты часто недоинвестируют: доступность.

Главный расход — не сам вредонос, а простой.

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

Именно поэтому NotPetya часто называют «самой дорогой кибератакой в истории». В отчётах общий ущерб оценивают примерно в 10 млрд долларов США.

Это видно и по цифрам отдельных компаний: Merck, FedEx (включая TNT Express) и Mondelez в своих отчётах прямо писали, что это был не «IT‑вопрос», а бизнес‑вопрос с последствиями для выручки, затрат и способности поставлять.

NotPetya оставил и крупный юридический шлейф: компании спорили со страховщиками. Некоторые страховщики пытались отказать в выплатах, квалифицируя атаку как «Act of War» (то есть государственно направленную). Широко обсуждался, например, спор Mondelez со своим страховщиком. Урок для компаний актуален до сих пор: покрывает ли ваша киберстраховка атаки госактеров или сработает war exclusion?

Апдейт для «про»: кейс Mondelez был окончательно закрыт в 2023 году. После этого (и вообще после NotPetya) рынок во многих местах ужесточил формулировки: в ряде полисов атаки «state‑motivated» теперь определяются гораздо уже или прямо исключаются. Это превращает киберстрахование в реальный финансовый риск, если не читать и не понимать условия.

И ещё: даже если вы «просто восстанавливаете IT», в реальности вы упираетесь в зависимости.

Один из самых известных примеров — Maersk: речь была не о нескольких зашифрованных файлах, а о восстановлении критичных систем, идентичностей и операционной IT, чтобы порты и логистика вообще смогли снова работать.

История стала легендой, потому что она идеально показывает хрупкость идентичностей и бэкапов: Maersk фактически потерял весь глобальный Active Directory — кроме одного Domain Controller в Гане, который в момент атаки был офлайн из‑за отключения электричества. Этот «Lucky Punch» стал случайным офлайн‑бэкапом: только благодаря этому физическому серверу удалось восстановить глобальный AD и ускорить recovery.

В итоге страдает не только «IT», но и бизнес напрямую:

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

Вот почему сумма такая высокая: экран с выкупом — симптом. Реальный ущерб — простой.

Практический сценарий: что я ожидал бы в «обычной» компании

Я намеренно опишу случай без голливудщины. Не «госактер против бигтеха», а вполне реалистичный сценарий для среднего бизнеса.

Представьте среднюю компанию:

Один главный офис и небольшой второй.
Классика Windows: AD, файловые серверы, несколько VM, ERP.
Плюс системы, к которым не хочется прикасаться: контроллеры оборудования, старая спец‑софтина, «Windows Server 2008 какой‑то», потому что вендор так и не обновил.
Бэкапы есть: ежедневно на NAS, еженедельно — ещё на второй носитель/систему.

И вот важный момент:

Эта компания не «плохо защищена», потому что все некомпетентны. Просто эксплуатация и время почти всегда побеждают.

Патчи откладываются из‑за плотного производства. Сегментация — «потом», потому что VLAN‑ы требуют работы. Локальные админ‑пароли исторически сложились. NAS, конечно, в сети — иначе restore слишком неудобен.

Таймлайн (реалистично, без драмы)

Во вторник утром прилетает обновление. Это может быть поставщик, инструмент подрядчика, коннектор — что‑то, что обновляется автоматически. Или компрометация у партнёра, у которого есть VPN‑доступ.

08:10: первые клиенты становятся нестабильными. Ребут тут, странная ошибка там.
08:25: первый файловый сервер начинает тормозить. Растёт нагрузка на helpdesk.
08:40: «с доменом что‑то не так». Логины медленные, GPO ведут себя странно.
09:00: админ логинится «быстро посмотреть». Часто это момент, когда lateral movement резко ускоряется.
09:20: целая площадка фактически офлайн.

И вот что понимаешь по‑настоящему только потом:

Если в этот момент не сделать жёсткое отсечение, ущерб растёт не линейно, а экспоненциально.

И, конечно, возникает вечный вопрос:

«Надо платить?»

В случае NotPetya горькая правда была такой: даже если захотите — это, скорее всего, не решение. Психологически это важно: нужно сразу переходить к «перестройке», а не к «расшифровке».

Чем дольше ждёте — тем больше систем придётся строить заново. Чем больше систем заново — тем дольше аварийный режим. Чем дольше аварийный режим — тем дороже.

Что действительно больно

Через несколько часов становится ясно: это не «восстановим пару файлов». Это «перестраиваем Active Directory и ключевые системы».

И вы обнаруживаете:

Бэкапы были онлайн и тоже пострадали.
Документация не актуальна.
Не хватает «golden images» для быстрого reimage.
Админские креды были везде.
Никто никогда не тренировался сегментировать площадку за 30 минут.

Вот здесь IT‑инцидент превращается в корпоративный кризис.

Что SOC делает иначе сегодня (и при чём тут ИИ)

В большом SOC ежедневно обрабатываются миллиарды событий из множества источников. Это уже не «админ смотрит логи», а индустриальный процесс: сенсоры, корреляция, автоматизация и человеческий анализ.

Интересна роль:

ИИ/автоматизация как первая линия: сортирует, коррелирует, ищет паттерны, отфильтровывает очевидное.
Люди как 2/3 линия: критические или неоднозначные кейсы забирают аналитики, принимают решения и координируют response.

Это звучит «для корпораций», но вывод полезен и для небольших компаний:

Вам не нужно строить SOC. Но нужен тот же подход:

Собирайте сигналы (EDR, firewall, auth‑логи).
Определите, что является «нормой».
И имейте процесс, который реагирует за минуты, а не за дни.

NotPetya уже в 2017 был настолько быстрым, что человек не успевал «реагировать достаточно быстро», когда распространение запускалось. Поэтому ценность ИИ — не «ещё быстрее», а в том, чтобы раньше заметить аномалию в шуме (например, если в 03:00 внезапно 500 машин хотят говорить по SMB). Эти минуты решают: увидеть раньше, ограничить раньше, изолировать раньше.

И дальше — подход, который всё чаще становится стандартом:

Assume breach.

Планируйте так, будто атакующий уже внутри. Не из паранойи, а из прагматизма.

Что я считаю минимумом сегодня (без enterprise‑бюджета)

Если вы хотите унести из NotPetya одну мысль, пусть будет эта:

NotPetya — это не «одна уязвимость». Это цепочка слабостей, которые усиливали друг друга.

Хорошая новость: именно поэтому базовые меры могут снять огромное количество риска.

1) Патчи и управление экспозицией (по‑настоящему)

Критические обновления Windows (особенно вокруг SMB) не должны ждать «когда‑нибудь».
Всё, что доступно извне, — приоритет.
Если нужен legacy — хотя бы в сегмент, с чёткими правилами.

2) Сделать lateral movement болезненным

Разделить админ‑аккаунты (повседневный vs админский).
Уникальные локальные админ‑пароли на устройство (LAPS).
Не оставлять WMI/PsExec открытыми везде.
Ограничить SMB там, где это не нужно.

3) Сегментация, но прагматично

Не нужно «идеального» Zero Trust завтра. Но:

Клиенты, серверы, бэкапы и OT/производство не должны быть в плоской сети.
Domain Controller — это tier 0: защищать соответствующе.
Восток‑Запад трафик требует не меньшего внимания, чем интернет‑трафик.

4) Бэкапы: offline, immutable, проверенные

Скажу так, как часто вижу в проектах:

Бэкап, который постоянно доступен на запись и постоянно онлайн, в инциденте часто оказывается не бэкапом.

3-2-1 — хороший старт.
Immutable storage (или offline‑носители) меняют правила игры.
Тесты восстановления обязательны. Не «у нас есть бэкапы», а «мы отрепетировали restores».

5) Runbooks и «kill switch» для площадок

Вам не нужен 80‑страничный регламент. Но нужна ясность:

Кто решает, что площадка отключается?
Как быстро блокировать аккаунты?
Что поднимать в первую очередь (AD, DNS, DHCP, VPN, ERP)?

И да: это нужно тренировать, иначе в кризисе не сработает.

Reality check: в NotPetya самым эффективным шагом часто было не «ещё один инструмент», а физически разорвать. Про Maersk есть рассказы, что сотрудники бегали по офисам и выдёргивали питание/кабели из свитчей, чтобы остановить распространение. Звучит примитивно, но иногда это и есть лучшая high‑tech‑защита, когда счёт идёт на секунды.

Итог

NotPetya — один из лучших примеров того, почему безопасность не заканчивается на «у нас есть антивирус».

Он был разрушительным не потому, что был магией. А потому, что бил по очень обычным слабостям:

доверие к обновлениям
слишком лёгкий lateral movement
недостаток сегментации
бэкапы слишком близко к продакшен‑сети

И именно поэтому он так важен для «обычных» компаний.

Инвестируйте не только в инструменты, но и в устойчивость: видимость, быстрый response и способность чисто восстанавливаться. Это разница между «очень плохим днём» и «кварталом, который вы никогда не отыграете».

Источники и ссылки

До следующего раза, Joe