Контроллер домена лежит. Терминальные серверы уходят в синий экран один за другим, а триста сотрудников молча смотрят на неработающие АРМ. Это не атака хакеров. Это начался пентест.
К сожалению, такие истории иногда случаются. Один неосторожный запуск эксплойта, слишком агрессивное сканирование в пиковые часы или использование незнакомого инструмента в проде — и вот уже тестирование на проникновение приносит больше реального ущерба, чем гипотетическая угроза.
Меня зовут Дмитрий Калинин, я руковожу отделом по работе с уязвимостями информационных систем в Бастионе, и за годы практики я видел достаточно ошибок. Включая свои собственные.
Дальше расскажу реальные истории о том, как ZeroLogon чуть не уничтожил домен заказчика, как утренний запуск Nmap парализовал офис на несколько часов, и почему некоторые пентестеры могут быть опаснее хакеров. А затем разберем, какие точки отказа в корпоративной сети ломаются первыми и как не превратить аудит безопасности в производственную катастрофу.
Почему пентест — это хождение по канату
При обсуждении рисков пентеста сразу видна асимметрия в восприятии опасности. Пентестеры-новички часто не осознают, какой разрушительной силой обладают их инструменты. Заказчики же, наоборот, впадают в панику от фразы «потенциально деструктивные действия» и начинают сомневаться, а стоит ли вообще проверять инфраструктуру. Истина, как всегда, где-то посередине.
Даже опытные спецы могут недооценивать риски, когда берут в руки незнакомый инструмент, старый эксплойт в новой обертке или работают в непривычной, хрупкой среде. Но что, если что-то действительно пойдет не так?
В большинстве случаев в договоре на пентест не прописаны санкции за проблемы с доступностью сервисов, но на практике ответственность распределена между исполнителями и заказчиком:
Исполнитель отвечает за соблюдение технического задания и согласованного скоупа. Он обязан, как сапер, предупреждать о каждом потенциально опасном шаге.
Заказчик отвечает за подготовку инфраструктуры. Он должен предоставить актуальную информацию об активах и быть готовым к «нештатным ситуациям».
Чтобы минимизировать риски, мы всегда настаиваем на «подушке безопасности»:
свежие резервные копии критически важных систем;
список «неприкасаемых» — особо чувствительных участков инфраструктуры;
прямой канал оперативной связи с администраторами;
окна для «шумных» работ, когда инженеры наготове.
Главное правило простое: если исполнитель предупредил, а заказчик дал согласие — ответственность за последствия лежит на заказчике. Но хороший пентестер сделает все, чтобы этим правилом никогда не пришлось пользоваться. Вот только даже лучшие эксперты иногда ошибаются.
Дело о ZeroLogon
Даже если эксплойт использовался сотню раз — первый запуск в новом окружении лучше моделировать на тестовом стенде. Особенно если он может навредить инфраструктуре всей компании.
На одном из проектов я работал с ZeroLogon. Это, без преувеличения, один из самых элегантных и одновременно опасных эксплойтов для Active Directory. Он позволяет аутентифицироваться на контроллере домена (DC), воспользовавшись уязвимостью в протоколе Netlogon, и сбросить пароль компьютерной учетной записи самого контроллера домена. После чего вы можете выполнить атаку DCSync и получить учетные данные администратора домена.
Но есть нюанс. После этой атаки контроллер домена теряет доверие к остальным DC, и синхронизация изменений между ними останавливается. Пока не восс��ановишь пароль вручную, домен, считай, мертв.
Я знал об этом. Я уже работал с ZeroLogon, но делал это аккуратно, через отдельный Python-скрипт в режиме сканера. Сначала проверка, есть ли уязвимость. И только потом, руками и с разрешения заказчика, — атака. И вот в один прекрасный день я увидел, что ZeroLogon добавили в Metasploit Framework.
Я был уверен, что в Metasploit эксплойт по умолчанию работает в режиме проверки — check, как и многие другие модули. Но он просто брал и сбрасывал пароль учетной записи контроллера домена.
К счастью, в сети был второй DC. Я смог зайти на него, вытащить пароль от первого и откатить всё назад. Пронесло. Если бы контроллер был один — домен пришлось бы пересоздавать заново.
Нокаут от Nmap
На другом проекте мы сканировали внутреннюю сеть с помощью Nmap. Казалось бы, что может быть предсказуемее? Один раз выставляешь адекватные параметры сканирования и спокойно получаешь карту сети.
Мы специально решили запустить сканер рано утром, чтобы к началу рабочего дня уже иметь данные для анализа. Но около девяти начались странности. Сначала сотрудники заказчика пожаловались на «тормоза». Затем посыпались ошибки аутентификации. Потом — коллапс.
Что произошло? В 9 часов на работу пришли несколько сотен сотрудников компании. Они дружно заварили кофе, включили компьютеры, начали логиниться в домен, подключаться к файловым шарам и скачивать почту. А в это же время Nmap методично опрашивал тысячи IP-адресов и портов, создавая дополнительную волну трафика. Старенькое сетевое оборудование, работавшее на пределе, просто захлебнулось.
На восстановление ушло несколько часов. Инженеры винили нас, мы указывали на особенности blackbox-тестирования и неудачную сетевую архитектуру. Урок был болезненным для всех. Повторять не рекомендую.
Синий экран имени BlueKeep
Громкие заголовки — коварная штука. Видишь статью про «критическую RCE-уязвимость в Windows RDP» и думаешь: вот он, ключ от всех дверей.
Так было с BlueKeep. В 2019 году эта уязвимость наделала много шума. С легкой руки журналистов её окрестили «супер-эксплойтом» на всех профильных ресурсах. Microsoft даже выпустила экстренные патчи для древних систем вроде Windows XP.
Эксплойт действительно был мощным: выполнение произвольного кода без аутентификации через RDP. Но у него был один недостаток, о котором писали мелким шрифтом: низкий шанс успешного срабатывания, а при неудаче — гарантированный BSOD.
К счастью, кейс не наш, но я знаю некоторых пентестеров, которые просто копировали скрипты из GitHub и массово запускали на проде с предсказуемым результатом. Терминальные серверы падали один за другим, пользователи теряли доступ, администраторы ловили панику.
Анатомия катастрофы: что легче всего сломать в корпоративной сети?
Анализируя корпоративную инфраструктуру, всегда можно выделить несколько ключевых точек отказа, которые становятся мишенями для атак — как со стороны злоумышленников, так и во время пентестов.
Контроллеры домена
Контроллер домена — это сердце инфраструктуры: без него не работают аутентификация, политики безопасности, вся Active Directory. Поэтому атаки через протоколы SMB, RPC или RDP бьют по самому уязвимому месту. Особенно опасны эксплойты вроде ZeroLogon, EternalBlue, BlueKeep и SMBGhost — они не просто роняют систему, а ломают её логику, нарушая репликацию или повреждая базу данных AD.
LDAP-запросы и разведка
Если запустить BloodHound или ADExplorer без ограничений, производительность домена может упасть. DCSync или массовый сбор данных буквально душат контроллер: LDAP-запросы сыплются тысячами, требуя объекты, атрибуты, связи. В результате производительность падает, RDP зависает, групповые политики не применяются. Разведка незаметно превращается в DoS.
Подбирайте параметры утилит с умом, а если не уверены, что инфраструктура заказчика выдержит, можете порекомендовать настроить мониторинг аномальной активности и Rate Limiting для LDAP-запросов. Механизмы Quality of Service (QoS) также помогут отдать приоритет важным операциям домена, даже если кто-то запустил агрессивное сканирование.
Терминальные (RDS) серверы
RDS-серверы — любимая цель. Они часто доступны извне, на них много активных сессий. Эксплойты вроде BlueKeep и здесь частые гости, но падение терминального сервера — это прямой удар по бизнес-процессам. Поэтому атаки на эти активы нужно согласовывать и проводить ночью или в выходные.
Серверы 1С
Серверы 1С — отдельная головная боль. Часто это древние Windows Server 2003/2008 без патчей, уязвимые к самым простым атакам. Но если атака придется на момент, когда идут операции с базой — например, проводится обновление конфигурации или закрывается месяц, — последствия могут быть катастрофическими. Повреждение базы 1С — это остановка бухгалтерии, сорванная отчетность и парализованные расчеты. Без свежего бэкапа — это билет в один конец.
Сетевые устройства
Коммутаторы и файрволы — не такие уж и железные. Запустите Masscan с дефолтным --rate=1000000 или Nmap в режиме -T5 — и процессор какого-нибудь старенького Cisco просто сдастся. Устройство либо зависнет, либо уйдет в перезагрузку. Иногда это даже играет на руку: был случай, когда перегруженный коммутатор на время перестал фильтровать трафик, и сканер увидел сегменты сети, которые раньше были недоступны. Но чаще падение сетевого оборудования вызывает гнев админов.
Межсетевые экраны нового поколения тоже не железобетонные — их таблицы соединений быстро переполняются, особенно когда сканер устанавливает полноценные TCP-сессии вместо быстрого SYN-сканирования. Еще хуже, когда канал связи забивается трафиком сканирования под завязку: железо вроде работает, но данные теряются по дороге. Получается эффект «сеть то есть, то нет» — и непонятно, что происходит.
Отдельная песня — системы мониторинга. Они начинают плодить алерты бесконечным потоком, а в худшем раскладе просто захлебываются в событиях и падают.
Технические меры защиты — это зона ответственности заказчика: нужно проверить rate limiting на критических устройствах, распределить нагрузку между несколькими узлами, обеспечить мониторинг и провести стресс-тесты в контролируемых условиях. А вот организационные меры — ответственность обеих сторон. Нужны четкие регламенты сканирования: какая интенсивность допустима, в какие временные окна можно тестировать, что делать при проблемах.
ARP Spoofing и Responder
Проблема ARP Spoofing в том, что атакующий не всегда понимает, какой объем трафика он через себя пропускает. Если переборщить, получается DoS: пакеты теряются, VPN-сессии рвутся, админ теряет доступ к оборудованию и вынужден идти к нему ногами. К тому же в современных корпоративных сетях эта техника потеряла актуальность — многие коммутаторы поддерживают DHCP Snooping и Dynamic ARP Inspection, которые серьезно снижают её эффективность.
Responder, инструмент для эксплуатации уязвимостей LLMNR/NetBIOS, тоже не так безобиден. Генерируя лавину ложных ответов, он забивает канал и провоцирует клиентские машины на отправку Net-NTLM-ответов к подставному хосту. Дальше начинается перехват аутентификационных данных (хэшей), имен пользователей и прочей информации, которую можно использовать для развития атаки.
Сегодня Responder всё еще можно увидеть в арсенале пентестеров — скорее в силу привычки, чем из-за реальной эффективности. С ростом числа сетей, где отключены LLMNR/NetBIOS и включен SMB-signing, срабатывает он всё реже.
Оружие массового поражения в руках пентестера
В неопытных руках даже проверенные инструменты становятся опасны.
Нестабильные эксплойты. В Metasploit каждому модулю присвоен рейтинг (rank). Всё, что ниже Good, — потенциально опасно. Manual требует глубокого понимания, а Low или Average регулярно вызывают сбои.
Брутфорс, который блокирует всех. Утилиты вроде Kerbrute без флага
--safeначнут перебирать пароли для всех учетных записей в домене, включая служебные и администраторские. Политики блокировки сработают моментально, и половина офиса не сможет залогиниться.Инструменты «Auto PWN». Работают по принципу «стрельба по площадям». Metasploit в агрессивном режиме или готовые эксплойт-киты применяют всё подряд, не проверяя совместимость. Это самый быстрый способ не взломать систему, а обрушить ее.
SQLMap и слепые инъекции. Запустите sqlmap на боевой базе с параметрами
--risk=3 --level=5, и он начнет проверять опасные векторы, включая командыUPDATEиDELETE. Данные могут быть повреждены или удалены. На продакшене — только--risk=1 --level=1.
Золотые правила безопасного пентеста
Пентест — это всегда баланс между контролируемой агрессией и колоссальной ответственностью за чужую инфраструктуру. Чтобы этот баланс не нарушить, есть несколько правил — как для заказчика, так и для исполнителя.
Что нужно сделать заказчику перед пентестом:
Подготовиться заранее. Составьте список «неприкасаемых» — тех критичных хостов, падение которых ударит по бизнесу больнее всего. Сделайте свежие, проверенные бэкапы всех важных систем.
Определить «окна». Договоритесь о временных промежутках, когда пентестеры могут проводить «шумные» тесты под присмотром администраторов. Это защита от «утренних сюрпризов», когда все приходят на работу и узнают, что ночное сканирование что-то уронило.
Наладить коммуникацию. Организуйте прямой канал для связи с пентестерами.
Что должен помнить пентестер (всегда):
Самое опасное в нашем арсенале — не эксплойт и не сканер. Это сам пентестер. Его опыт, его усталость, его самонадеянность. Большинство проблем возникает не из-за отказа техники, а из-за человеческого фактора.
Самоуверенность. Когда опытный спец решает, что он-то точно знает, как этот эксплойт себя поведет, потому что «сто раз так делал».
Импровизация. Роковая фраза «а что, если попробовать вот этот флаг?» в командной строке, запущенной на продовом сервере заказчика.
Сжатые сроки. Когда дедлайн г��рит, появляется соблазн срезать углы: пропустить обязательные проверки, отключить «безопасный режим» или не следить за сетевой нагрузкой, потому что «отчет нужно сдать завтра».
Стремление к «вау-эффекту». Желание показать красивую, сложную атаку, которое перевешивает здравый смысл и оценку рисков.
Главный принцип: не делай в бою того, что не отработал на учениях. Любой может допустить ошибку. Поэтому правила предосторожности — это не перестраховка, а профессионализм. В конце концов, мы работаем с чужим бизнесом, а не просто взламываем железки.
Альтернативные подходы: когда ломать не обязательно
А нужно ли вообще проводить реальное вторжение с риском что-то уронить? Не всегда. Есть методики, которые позволяют проверить защиту компании без угрозы для её стабильности. Они полезны, когда инфраструктура сбоит или когда доверие между пентестерами и заказчиком только формируется.
Purple Teaming — совместная, открытая работа атакующей «красной» команды и защищающей «синей». Red Team не действует втайне, а объявляет: «Сейчас я буду пробовать атаку X». Blue Team в реальном времени смотрит на свои мониторы: сработал ли SIEM? Увидел ли EDR подозрительную активность? Почему WAF пропустил этот вектор? Такой подход снижает риски до нуля и позволяет мгновенно калибровать средства защиты, исправлять ложные срабатывания и понимать, какие техники атаки не детектируются.
Штабные учения (Tabletop Exercises). Этот формат идет еще дальше — мы вообще не трогаем прод. Команды безопасности, ИТ, DevOps и даже менеджмент собираются за одним столом и проигрывают сценарии. «Итак, к нам пришел шифровальщик. Что мы делаем в первые 15 минут? Кто кому звонит? Кто отключает сегмент сети? Кто отвечает за коммуникацию с руководством?» Используются блок-схемы, карты сценариев и коллективный опыт. Плюсы очевидны: нулевой технический риск и бесценная тренировка взаимодействия команд в условиях кризиса.
Но будем честны: даже самые продвинутые симуляции не заменят реальной проверки. Невозможно точно предсказать, как поведет себя старый коммутатор под нагрузкой или как отреагирует самописное приложение на нестандартный запрос. Нужен баланс.
Уроки для индустрии
Большинство инцидентов во время пентестов случаются не из-за злого умысла, а из-за нехватки опыта. Но вот парадокс: опыт не дается в теории, его зарабатывают на реальных проектах. А на реальных проектах цена ошибки может быть фатальной. Получается замкнутый круг.
Заказчики до первой аварии часто недооценивают риски, слепо доверяя подрядчику. Или, наоборот, контролируют каждый шаг, но не понимают сути угроз. Специалисты, в свою очередь, переоценивают свои силы, импровизируют и надеются на «авось».
Инструменты меняются. Metasploit устаревает — не потому, что он плохой, а потому, что отрасль развивается быстрее, чем методы обучения. На смену классическим эксплойтам приходят комплексные фреймворки, Red Team-симуляции, Purple Team-форматы и десятки новых C2-платформ. Но без наставников даже лучший набор инструментов бесполезен. Безопасность — это не только знание CVE и флагов в консоли, но и подход: постепенное усложнение задач, осознанная работа, понимание своих действий.
Чтобы отрасль росла, нужны менторы. Люди, которые уже набили свои шишки и могут объяснить новичку, где нужно идти осторожно, а где можно наступить увереннее. Которые не просто делятся знаниями, а формируют правильное мышление.
Отдельно стоит сказать о стендовом тестировании. Именно там безопасники могут спокойно экспериментировать, проверять гипотезы и видеть, как система реагирует на их действия. Это место, где можно ошибаться без последствий — и понять, как не ошибиться в проде.
Главный урок: безопасность начинается не с инструментов, а с культуры. С уважения к чужой инфраструктуре, данным и бизнесу. Если это понимание закрепится на всех уровнях — от начинающих специалистов до CISO и заказчиков — у индустрии появится шанс не просто вырасти, а повзрослеть.
Бастион — защищаем бизнес от киберугроз
t.me/bastiontech — делимся собственным опытом, экспертизой, результатами исследований и прогнозами