📚 Это часть 3 серии “Управление уязвимостями для самых маленьких” - практического руководства по VM с нуля. Главы самостоятельны, но если хочется по порядку - оглавление и все части серии тут.
Статистика по наиболее атакуемым векторам и уязвимостям
Чтобы грамотно защищаться, надо понимать, как именно ломают. В этом разделе разберем самые частые векторы атак и самые эксплуатируемые уязвимости. Сначала посмотрим на мировую картину, потом на российскую.
Данные взяты из авторитетных открытых источников: Verizon Data Breach Investigations Report (DBIR), база CVE от MITRE, отчеты Mandiant, Check Point и российских компаний (Positive Technologies, BI.ZONE, “РТК-Солар” / Solar).
А что там за рубежом?
Главных векторов атак пять. Пройдем по каждому.
Социальная инженерия и фишинг. Человек по-прежнему остается самым слабым звеном. В отчете Verizon DBIR из года в год повторяется одна мысль: человеческий фактор присутствует в подавляющем большинстве инцидентов. Парадокс в том, что самое уязвимое звено - топ-менеджмент. Эти люди знают много конфиденциального и при этом часто выведены из-под общих правил безопасности: им делают исключения, отключают двухфакторную аутентификацию, не трогают их устройства. Фишинг остается самым массовым инструментом обмана: поддельные письма и сайты выманивают логины, пароли и финансовые данные.
Вредоносное ПО и программы-вымогатели. Шифровальщики стали настоящей эпидемией. По данным Verizon DBIR 2026, программы-вымогатели присутствуют почти в половине всех взломов - 48% [1]. Логика проста: зашифровали данные, потребовали выкуп. Но картина меняется. По тому же отчету, 69% жертв в итоге не заплатили, а медианная сумма выкупа за год упала почти вдвое. Бизнес научился восстанавливаться из резервных копий и все чаще отказывается кормить вымогателей. Хотя для небольшой компании без нормальных бэкапов шифровальщик по-прежнему нередко означает конец.
Подбор учетных данных (брутфорс). Автоматизированные инструменты перебирают миллиарды комбинаций логинов и паролей, эксплуатируя главную человеческую слабость - повторное использование паролей. “RockYou2024” о чем-то говорит? Это крупнейшая в истории утечка паролей: в июле 2024 года в сеть выложили почти 10 миллиардов уникальных паролей. Звучит апокалиптично. Но если копнуть, окажется, что в 2021 году был “RockYou2021” с базой на 8,4 миллиарда, а новая просто его дополнила. Паника продается лучше фактов. Вывод простой: смените пароль на всякий случай. А лучше придумайте себе алгоритм генерации уникального пароля под каждый ресурс или пользуйтесь менеджером паролей. Давайте приведу пример алгоритма по которому я придумываю пароли (ахахахах да да, конечно, прям и рассказал, напишу выдуманный алгоритм, но чтобы было понятно):
Пароль делим на четыре части:
Постоянный секрет
Основа которую берем по сайту
Символ
Конец, который тоже берем по сайту
Пока ничего не понятно?) Сначала придумаем постоянный секрет, проще всего использовать фразу которую вы всегда будете помнить, например: “Мой первый автомобиль Lada куплен в 1992”. Берем только первые и на латинице, в заменяем на # и обязательно с заглавной буквы получаем: “Mpalk#1992”. Основа по сайту - первые две буквы названия ресурса с заглавной буквы. Символ сделаем тире “-”. А конец пароля будет заключаться в количестве букв в названии ресурса + последняя буква названия ресурса. А теперь разберем на примере mail.ru, gmail и habr.:
Mail.ru - Mpalk#1992 + Ma + - + 4l = Mpalk#1992Ma-4l
Gmail.com - Mpalk#1992 + Gm + - + 5l = Mpalk#1992Gm-5l
Habr.com - Mpalk#1992 + Ha + - + 4r = Mpalk#1992Ha-4r
Каждый пароль: 10+ символов, верхний/нижний регистр, цифры, спецсимвол, уникален для сайта, и при этом полностью восстанавливается в уме — нужно помнить только секрет и пару правил. Пользуйтесь)
Эксплуатация уязвимостей на периметре. И вот мы добрались до главного героя книги. Злоумышленники массово эксплуатируют известные уязвимости, для которых патч уже выпущен, но не установлен. Это и есть самое обидное: дыру закрыли, лекарство есть, а его не приняли.
И тут важное обновление картины. Если в первых отчетах DBIR эксплуатация уязвимостей была на третьих-четвертых ролях, то динамика последних лет драматична. В DBIR 2024 на эксплуатацию уязвимостей приходилось около 14% взломов, в DBIR 2025 - уже 20% (рост на 34% за год, обогнали фишинг), а в DBIR 2026 - 31%, и это первое место за всю 19-летнюю историю отчета [1]. Эксплуатация уязвимостей обошла и фишинг, и кражу учетных данных. Mandiant в M-Trends рисует ту же картину: эксплойты - вектор номер один первоначального доступа (33% случаев) [2].
Самые знаменитые “долгожители” среди эксплуатируемых уязвимостей:
CVE-2021-44228 (Log4Shell) - критическая уязвимость в библиотеке Apache Log4j 2, позволяющая удаленно выполнить код. Обнаружена в конце 2021 года и до сих пор активно эксплуатируется из-за того, что Log4j встроена буквально везде. Классика жанра “уязвимость, которая никогда не умрет”.
CVE-2020-1472 (Zerologon) - уязвимость в протоколе Microsoft Netlogon, позволяющая злоумышленнику выдать себя за любой компьютер, включая контроллер домена. Раскрыта в 2020 году, но из-за медленного патчинга оставалась угрозой годами.
Уязвимости в граничных устройствах - VPN-шлюзах, firewall, почтовых серверах. По данным DBIR 2025, атаки на edge-устройства выросли почти в 8 раз за год, а медиана времени от публикации уязвимости до начала массовой эксплуатации для них - 0 дней [1]. Ноль. Эксплуатируют сразу. Имена этих устройств в последние годы не сходят со страниц бюллетеней: Ivanti, Fortinet, Palo Alto, Citrix, Cisco. Чего стоит одна Citrix Bleed (CVE-2023-4966) - она отдавала злоумышленнику сессионные токены в обход пароля и двухфакторки, через нее ломали и банки, и логистические компании. А китайская группировка Salt Typhoon, по разным оценкам, через дыры в пограничном оборудовании дотянулась до сетей более чем 600 организаций по всему миру [9].
Вывод по мировой статистике: фишинг и вредоносное ПО стабильно высоко, но именно неустраненные уязвимости стали главным двигателем успешных атак. Патчи доступны, организации их не ставят, злоумышленники этим пользуются.
Да какая разница, что там за рубежом, а у нас как?
А у нас, по данным проектов Positive Technologies, ситуация двойственная.
Лучше всех защищены крупнейшие технологические компании (ИТ-гиганты, провайдеры облаков и ЦОДов). На втором месте - финансовые организации: они традиционно вкладываются в безопасность и обязаны следовать отраслевым стандартам ЦБ. И есть хорошая новость: ситуация на периметре улучшается. У постоянных клиентов, для которых пентесты проводятся регулярно, заметно ускорился патч-менеджмент - компании возвращаются все более защищенными.
Но у тех, кого проверяют впервые, встречаются кейсы, от которых хватаешься за голову. В одной компании мы нашли на периметре уязвимость возрастом 6 лет. В другой - 11 лет. Одиннадцать лет уязвимость висела на периметре, доступная из интернета. Это не техническая проблема, это вопрос культуры ИБ.
Самый популярный способ преодоления периметра в российских пентестах - эксплуатация уязвимостей в веб-приложениях. Многие компании отдают разработку и поддержку сайтов на аутсорс, а без должного контроля и обновлений такие приложения быстро превращаются в открытую дверь. Самый яркий отечественный кейс - массовые взломы через уязвимости в “1С-Битрикс” в 2022-2023 годах.
Несмотря на тренд импортозамещения, до сих пор верно правило: “внутренние пентесты - это Microsoft Active Directory”. Главная задача внутреннего пентеста чаще всего - получить максимальные привилегии в домене. В лидерах атак - эксплуатация службы сертификации (AD CS) и злоупотребление правами доступа между объектами домена (abusing ACL/ACE). Отдельная боль - уязвимости в Microsoft Exchange: этот почтовый сервер высоко привилегирован, и его захват часто означает компрометацию всего домена.
Цифры отрезвляют. По данным пентестов Positive Technologies, около 96% компаний остаются уязвимы к внешним атакам, а при получении доступа во внутреннюю сеть в практически 100% случаев удается установить полный контроль над доменом [3]. В отдельных проектах на захват домена уходило меньше рабочего дня: рекордные шесть с половиной часов от первого шага до прав администратора. И снова: компании, которые регулярно проводят пентесты и внедряют рекомендации, повышают защищенность кардинально. Те, кто не проводит, живут с уязвимостями десятилетиями.
Общий поток атак на Россию растет год от года. Драйверы те же, что в мире: социальная инженерия и фишинг, вредоносное ПО (с большой долей шпионского ПО и шифровальщиков), эксплуатация уязвимостей в ПО (особенно в популярных CMS), сетевые атаки и компрометация учетных записей.
Методика ФСТЭК рекомендует устранять критические уязвимости в течение 24 часов с момента обнаружения, а уязвимости высокого уровня - в течение 7 дней. Приказ ФСТЭК № 117 с 1 марта 2026 года делает эти сроки обязательными для государственных систем [4]. Это не бюрократическая придирка. По данным Mandiant, среднее время от публикации уязвимости до рабочего эксплойта сократилось до 5 дней [2]. А VulnCheck подсчитал: почти треть свежих уязвимостей начинают эксплуатировать в первые сутки после раскрытия, и около 29% тех, по которым эксплуатация подтверждена, шли в ход еще до публичного раскрытия [5]. То есть к моменту выхода новости о дыре вас уже могли просканировать. Сутки на критическую уязвимость на периметре - это не “строго”, это реалистично.
Общий вывод: и в мире, и в России картина сходится. Главные векторы - социальная инженерия, вредоносное ПО, эксплуатация уязвимостей и компрометация учеток. А значит, и защита нужна комплексная: обучение сотрудников, строгая парольная политика и зрелое управление уязвимостями.
Уязвимости нулевого дня
Уязвимость нулевого дня (zero-day) - это уязвимость, для которой еще не существует официального патча. Они особенно опасны: злоумышленники могут атаковать системы до того, как разработчик вообще узнает о проблеме. Название говорит само за себя: у защитников было ноль дней на подготовку.
Чтобы воспользоваться такой уязвимостью, создают эксплойт нулевого дня - программу, которая эксплуатирует дыру и выполняет произвольный код в целевой системе.
Почему они появляются. Главная причина - несовершенство процесса разработки ПО. Даже при тщательном тестировании и аудите кода нельзя найти все уязвимости. Плюс не у всех разработчиков есть ресурсы и мотивация искать дыры в собственном продукте.
Как обычно публикуют уязвимости. В норме исследователь находит уязвимость, передает информацию вендору, тот выпускает патч, и только после этого факт уязвимости раскрывается публично. Это называется координированным раскрытием. Чтобы вендоры не тянули с патчами вечно, исследователи ставят дедлайны: например, Google Project Zero дает разработчикам 90 дней, после чего публикует информацию независимо от того, готов патч или нет. Для критических уязвимостей, которые могут привести к массовым атакам, срок сокращают до 7 дней.
Темная сторона рынка. Не все уязвимости попадают к вендорам. Есть компании-брокеры, которые скупают zero-day. Долгое время эталоном был Zerodium: он покупал эксплойты и перепродавал их, в том числе спецслужбам, а за рабочую цепочку под свежий iPhone предлагал до 2,5 миллиона долларов. К 2025 году Zerodium фактически свернул публичную деятельность, но рынок никуда не делся - наоборот, ставки только выросли. Российский брокер Operation Zero, появившийся в 2021 году, объявил, что готов платить до 20 миллионов долларов за полную цепочку под Android или iOS [8]. Это в разы больше прежних расценок Zerodium. Покупателей такие конторы называют почти открыто: государственные структуры и спецслужбы. Проблема все та же - купленная уязвимость остается незакрытой и идет в дело против конкретных целей.
Примеры zero-day:
CVE-2019-0708 (BlueKeep) - уязвимость в службе удаленного рабочего стола (RDP) в Windows, позволявшая выполнить произвольный код. Настолько опасная, что Microsoft выпустила патчи даже для давно неподдерживаемых Windows XP и Windows Server 2003
CVE-2018-20250 (WinRAR) - уязвимость в архиваторе WinRAR, позволявшая распаковать файл в произвольное место, например в автозагрузку, чтобы вредонос запустился после перезагрузки
Как снизить риск zero-day:
Обновляйте ПО как можно быстрее. Многие “zero-day” становятся “однодневными” сразу после выхода патча, и тут все решает скорость установки
Используйте средства защиты - антивирус, EDR, которые могут заблокировать попытку эксплуатации даже неизвестной уязвимости по поведению
Применяйте IDS/IPS - системы обнаружения и предотвращения вторжений ловят аномалии в трафике
Анализируйте код, если вы разработчик: статические, динамические и интерактивные анализаторы (SAST/DAST/IAST) находят уязвимости на ранних этапах
Уязвимости веб-приложений и OWASP Top 10
Веб-уязвимости - самый популярный способ проникновения хакеров в инфраструктуру. Логика понятна: веб-приложения стоят на периметре и принимают на себя первый удар. А отданные на аутсорс и заброшенные сайты - вообще подарок для атакующего.
Ориентир в мире веб-безопасности - OWASP Top 10. OWASP (Open Worldwide Application Security Project) - некоммерческая организация, которая раз в несколько лет публикует список из десяти самых опасных классов уязвимостей веб-приложений. Список строится на анализе реальных данных: частота возникновения уязвимостей плюс тяжесть последствий. Последнее обновление вышло в 2025 году, и оно заметное: появились две новые категории, а привычная многим SSRF из отдельного пункта переехала внутрь контроля доступа. Разбираем свежую версию по порядку, от самого частого к менее частому.
1. Нарушение контроля доступа (Broken Access Control)
Самая распространенная категория, и в 2025 году она снова на первом месте. Возникает, когда проверка прав пользователя выполняется неправильно или не полностью, и пользователь может делать то, на что у него нет прав.
Примеры: проверка прав есть только на фронтенде, но не на сервере (атакующий обходит клиентскую часть и обращается к серверу напрямую); обычный пользователь может выполнять запросы для администраторов; авторизованный пользователь редактирует или удаляет чужие записи. Последствия - несанкционированный доступ к чужим данным, утечки, нарушение работы системы.
Сюда же в версии 2025 переехала SSRF (подделка запросов на стороне сервера) - раньше это был отдельный, десятый пункт, а теперь ее считают частным случаем нарушения контроля доступа. Суть: приложение позволяет пользователю указать адрес, к которому обратится сам сервер (классика - загрузка аватара по ссылке). Злоумышленник подсовывает внутренний адрес и гоняет сервер туда, куда снаружи хода нет: дергает внутренние сервисы, сканирует сеть в поисках открытых портов, читает локальные файлы. Защита - фильтровать и валидировать URL, контролировать перенаправления, держать подверженные SSRF серверы подальше от критичных систем.
2. Небезопасная конфигурация (Security Misconfiguration)
Поднялась с пятого места на второе. Те самые “мисконфиги”. Типовые ошибки: стандартные параметры и пароли после установки, отсутствие требований к сложности паролей, оставленные файлы и папки по умолчанию, незакрытые админ-панели, неотключенные устаревшие модули. Зная версию веб-сервера или CMS, атакующий легко находит готовые эксплойты.
Защита: менять стандартные настройки и пароли, удалять неиспользуемые компоненты, следовать рекомендациям вендора по харденингу, проверять конфигурацию автоматизированными инструментами (в России это, например, MaxPatrol HCC, RedCheck, ScanOVAL).
3. Сбои в цепочке поставок ПО (Software Supply Chain Failures)
Сразу в тройке лидеров, и под новым именем. Раньше этот пункт назывался скромнее - “уязвимые и устаревшие компоненты”. Теперь его расширили до всей цепочки поставок, и правильно сделали: вы зависите не от одного своего кода - под капотом всегда чужие библиотеки, фреймворки, пакеты, образы контейнеров, инструменты сборки. И слабым звеном может стать любое из них.
Что сюда входит: устаревшие и неуправляемые компоненты (ОС, веб-серверы, СУБД, библиотеки, CMS), скомпрометированные или поддельные пакеты в публичных репозиториях, взломанный конвейер сборки, обновления, прилетающие непонятно откуда. Если ПО больше не поддерживается разработчиком, оно автоматически становится уязвимым - подумайте о замене.
Защита: инвентаризируйте и регулярно обновляйте все компоненты, тяните их только из официальных источников, выкидывайте неиспользуемое (меньше компонентов - меньше поверхность атаки), ведите SBOM - “список ингредиентов” приложения, к которому мир приходит как к стандарту. Через цепочку поставок прошли самые громкие атаки последних лет, от SolarWinds до отравленных пакетов в npm и PyPI.
4. Сбои криптографии (Cryptographic Failures)
Опустилась со второго места на четвертое - но радоваться нечему, криптографию не стали реже ломать, просто соседние категории вырвались вперед. Неправильное применение криптографии или устаревшие методы. Ключевые проблемы:
Незащищенное соединение. Передача данных по HTTP вместо HTTPS позволяет любому в той же сети перехватить логин, пароль или данные карты. HTTPS с актуальным TLS-сертификатом шифрует трафик и делает перехват бесполезным.
Устаревшие хеш-функции. MD5 и SHA-1 давно скомпрометированы, использовать их для паролей нельзя.
Ключи по умолчанию. Стандартные ключи шифрования из коробки - все равно что не шифровать вовсе.
Радужные таблицы (rainbow tables). Предвычисленные таблицы для обратного хеширования. Если пароли хранятся как простые хеши без “соли”, атакующий быстро восстановит исходники. Защита - соль (случайные данные, добавляемые к паролю перед хешированием) и медленные функции хеширования с большим числом итераций (bcrypt, Argon2).
5. Внедрение (Injection)
Одна из самых опасных категорий, хоть в рейтинге и съехала с третьего места на пятое. Когда приложение недостаточно контролирует пользовательский ввод, злоумышленник может “подсунуть” в него команды. Классика - SQL-инъекция: в поле ввода добавляются специальные символы и команды, и система выполняет их, выдавая данные из других таблиц или вовсе отдавая контроль над сервером (удаленное выполнение кода, RCE).
Меры защиты: проверять и валидировать все входные данные (поля форм, заголовки запросов, JSON, API, куки), использовать параметризованные запросы, применять анализаторы кода (SAST/DAST/IAST), экранировать опасные символы.
6. Небезопасный дизайн (Insecure Design)
Самая коварная категория: проблема не в коде, а в архитектуре. Код может быть написан идеально, но если на этапе проектирования забыли про проверку, дыра останется. Примеры:
Пополнение счета. Нет проверки на положительную сумму - злоумышленник вводит отрицательное число, и списание превращается в зачисление.
Восстановление аккаунта. При входе требуется двухфакторная аутентификация, а при восстановлении пароля - нет. Атакующий идет через восстановление и обходит 2FA.
Бронирование слотов. Нет проверки личности - скрипт занимает все свободные слоты, и настоящие клиенты остаются ни с чем.
Защита: продумывать сценарии атак на этапе проектирования, создавать библиотеку типовых безопасных решений, валидировать все на стороне сервера.
7. Сбои аутентификации (Authentication Failures)
В 2025 году из названия убрали слово “идентификация”, но разобраться в трех понятиях, которые вечно путают, все равно полезно:
Идентификация - кто ты (ввод логина).
Аутентификация - докажи, что это правда ты (пароль, а лучше многофакторная аутентификация с кодом из SMS или пуша).
Авторизация - что тебе можно (какие данные ты можешь смотреть и менять).
Риски: перебор логинов при отсутствии защиты, простые пароли (admin/admin), массовый брутфорс с одного IP, повторное использование старых паролей, бесконечные сессии. Меры: блокировка после нескольких неудачных попыток, запрет на простые и повторные пароли, тайм-ауты сессий, многофакторная аутентификация.
8. Нарушение целостности ПО или данных (Software or Data Integrity Failures)
Категория про доверие к коду и данным, которые вы не удосужились проверить. Пример: приложение тянет обновление или библиотеку и не сверяет ее подпись и контрольную сумму - а подменить файл по дороге уже дело техники. Сюда же небезопасная десериализация: когда данные из ненадежных источников (куки, сессии, запросы) превращаются в объекты без всякой проверки, через это нередко удается выполнить чужой код.
Защита: проверять цифровые подписи и контрольные суммы компонентов и обновлений, жестко контролировать доступ к системе сборки (CI/CD), валидировать данные при десериализации.
9. Сбои логирования и оповещения (Security Logging and Alerting Failures)
В 2025 году “мониторинг” в названии заменили на “оповещение”, и это честнее: какой толк от журналов, если на тревожное событие никто не реагирует? Без журналов вы слепы - не увидите атаку в реальном времени и не расследуете инцидент задним числом. Важно: собирать журналы со всех систем, анализировать аномалии (например, серию неудачных входов), настроить оповещения и реально на них реагировать, дублировать журналы в отдельное хранилище (чтобы атакующий не затер следы), фильтровать шум и регулярно проверять, что вся эта машинерия вообще работает.
10. Ненадлежащая обработка исключительных ситуаций (Mishandling of Exceptional Conditions)
Это новая категория 2025 года - такой строки в списке раньше не было. Речь о том, как приложение ведет себя, когда что-то пошло не так: ошибка, сбой, неожиданный ввод. Бед тут две.
Первая - слишком болтливые сообщения об ошибках. Когда приложение вываливает пользователю полный стектрейс, путь к файлам, версию софта или кусок SQL-запроса, оно своими руками рисует атакующему карту местности.
Вторая и она опаснее - поведение “fail open”. Это когда при сбое система не запирается, а наоборот распахивается. Отвалилась проверка прав - пустим всех. Лег антифрод - пропустим платеж. Принцип “непонятно, значит разрешить” в безопасности недопустим: при любом сбое система должна закрываться, а не открываться.
Защита: обрабатывать ошибки предсказуемо, прятать от пользователя внутренние детали (их - в журнал, наружу - короткое нейтральное сообщение), проектировать отказы по принципу “fail closed” - в случае сомнений запрещать.
Истории самых дорогих уязвимостей
Несколько уязвимостей вошли в историю кибербезопасности благодаря масштабу ущерба.
CVE-2017-0144 (EternalBlue) - уязвимость в протоколе SMB от Microsoft. На ее основе работали два самых разрушительных вредоноса в истории:
WannaCry (май 2017): шифровальщик поразил, по оценке Europol, более 200 000 компьютеров в 150 странах. Среди пострадавших - Национальная служба здравоохранения Великобритании (NHS), Renault, FedEx. Ущерб оценивают в миллиарды долларов.
NotPetya (июнь 2017): использовал ту же уязвимость, ущерб оценивается примерно в 10 миллиардов долларов. Сильнее всех пострадали Maersk, Merck и Mondelez. Самое горькое: патч для EternalBlue Microsoft выпустила за два месяца до WannaCry. Кто поставил - уцелел.
CVE-2014-0160 (Heartbleed) - уязвимость в библиотеке OpenSSL, которая защищает огромную часть интернет-трафика. Позволяла вытягивать данные прямо из памяти серверов: пароли, ключи шифрования. Под риском оказались сотни тысяч серверов, компаниям пришлось массово менять сертификаты. Суммарные затраты - сотни миллионов долларов.
CVE-2010-2568 (Stuxnet) - червь, атаковавший промышленные системы управления. Использовался для саботажа иранской ядерной программы и стал первым публично известным примером кибероружия, которое нанесло физический ущерб оборудованию.
CVE-2021-44228 (Log4Shell) - уже знакомая нам уязвимость в Apache Log4j. Из-за вездесущности библиотеки затронула миллионы систем по всему миру. Затраты на устранение и обновления, по оценкам, исчисляются миллиардами долларов с учетом трудозатрат и простоев.
CVE-2023-34362 (MOVEit Transfer) - уязвимость в популярной программе для передачи файлов. Весной 2023 года группировка Cl0p превратила ее в конвейер: вместо точечного взлома злоумышленники прошлись разом по всем, у кого MOVEit торчал наружу. Итог - более 2700 организаций и данные свыше 90 миллионов человек [7]. Среди пострадавших BBC, British Airways, государственные ведомства, университеты. Это новый почерк массовых атак: одна уязвимость, поточная эксплуатация, сотни жертв за считаные недели.
Нельзя не упомянуть и громкие утечки, по которым нет официального подтверждения, была ли там эксплуатация уязвимостей, но масштаб впечатляет:
Marriott (2018): компания сообщила о компрометации системы бронирования Starwood. Сначала называли цифру до 500 миллионов гостей, позже ее уточнили примерно до 383 миллионов. Утекли имена, номера паспортов, адреса, даты рождения.
DDoS-атака на Dyn (2016): провайдер DNS подвергся одной из крупнейших DDoS-атак в истории (с помощью ботнета Mirai из зараженных IoT-устройств). На несколько часов “легли” Twitter, Spotify, Reddit и десятки других сервисов.
Equifax (2017): утечка данных около 147 миллионов граждан США. Что важно для нашей темы: причиной стала именно неустраненная уязвимость в Apache Struts (CVE-2017-5638), патч для которой вышел за два месяца до взлома. Хрестоматийный пример того, к чему приводит промедление с патчем.
Yahoo (2013-2014): в результате серии инцидентов скомпрометированы данные всех 3 миллиардов учетных записей. Крупнейшая утечка в истории.
Каждый из этих инцидентов оставил долгосрочные последствия. И почти за каждым стоит одна и та же история: уязвимость, которую можно было закрыть вовремя.
А как у вас?
Какая уязвимость дольше всего “жила” у вас на периметре, прежде чем ее закрыли? Делитесь рекордами (анонимно, конечно).
📚 Источники и ссылки
Источники главы
Verizon Data Breach Investigations Report 2024, 2025, 2026. https://www.verizon.com/business/resources/reports/dbir/
Mandiant (Google Cloud), M-Trends 2025 и Time-to-Exploit Trends. https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2025
Positive Technologies, результаты пентестов 2023-2024 гг. https://www.ptsecurity.com/ru-ru/research/analytics/
Методика оценки уровня критичности уязвимостей ФСТЭК России (ред. от 30.06.2025); приказ ФСТЭК России от 11.04.2025 № 117 (вступает в силу 01.03.2026).
VulnCheck, State of Exploitation Report (данные за 2025 год). https://www.vulncheck.com/
OWASP Top 10. https://owasp.org/Top10/
CISA, Advisory AA23-158A (#StopRansomware: Cl0p / MOVEit Transfer). https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-158a
SecurityWeek, Russian Zero-Day Acquisition Firm Operation Zero (2023). https://www.securityweek.com/russian-zero-day-acquisition-firm-offers-20-million-for-android-ios-exploits/
CISA, Advisory AA23-325A (Citrix Bleed, CVE-2023-4966); отчеты об активности Salt Typhoon. https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-325a
CVE-статистика 2024-2025 гг. по данным CVE.org / NVD. https://www.cve.org/
Навигация по серии: ⬅️ Предыдущая: Гл. 2. Управление уязвимостями по-русски · 📑 Оглавление серии · Следующая: *Гл. 4. Купили сканер - но процесса нет* ➡️
Если у вас в инфраструктуре что-то устроено иначе - расскажите в комментариях. Зашло - подписывайтесь, чтобы не пропустить следующую часть.
