Пентест принято мерить по количеству найденных дыр. По‑хорошему мерить надо бы по другому: что осталось после команды. Работает ли инфраструктура, не разошлись ли данные, не прилетело ли тем, кого в проекте вообще не было.
Я работаю в Singleton Security. Ниже 5 ошибок, после которых проект превращается в проблему. Часть я видел со стороны, часть слышал в кулуарах на конференциях, где такое рассказывают охотно, а в отчётах не пишут никогда. Два случая наши собственные: упавший сервер и домен, который не надо было регистрировать. Свои разбирать проще, про них хотя бы точно знаешь, как всё было.
1. Полез за скоуп
Скоуп это список того, что вам разрешили трогать. Всё остальное трогать нельзя, даже если оно стоит рядом и всем своим видом напрашивается.
Звучит банально. На практике граница уезжает сама, и обычно без всякого умысла:
В разведке всплывает поддомен, которого в перечне не было;
Целевой домен смотрит на shared‑хостинг, а там на том же IP ещё десяток чужих сайтов;
Сервис живёт в облаке, и вы формально стучитесь в инфраструктуру провайдера;
Кусок периметра принадлежит подрядчику заказчика, а не заказчику;
За время проекта у компании поменялся внешний адрес.
Дальше начинается неприятное. За пределами согласованного периметра у вас нет авторизации, а без неё вы ничем не отличаетесь от того, кого сами же пришли изображать. В нашей практике такие эпизоды разбирают через ст. 272 УК РФ, а если задели объект КИИ, то через 274.1, где санкции ощутимо жёстче.
И тут надо сказать вслух то, о чём в отрасли говорят с 2024 года и всё никак не договорят: отдельного закона, который выводил бы пентест из‑под «компьютерных» статей, у нас до сих пор нет. Инициативы про статус белых хакеров обсуждают, единого режима не приняли. Так что защищает вас только бумага.
Отсюда простые вещи. Скоуп фиксируйте письменно, с датой. Расширение тоже письменно: «мы тут ещё вот это глянем, ок?» в мессенджере за документ не сойдёт. Перед стартом прогоните адреса через whois, ASN, реверс на shared‑хостинг, спросите, чьё это железо вообще. И держите allow‑list в конфиге инструмента, а не в голове: сканер, которому скормили /24 вместо /32, это классика, на которой обжигались все.
И отдельная история азарт. Ну кто из нас не хотел докрутить найденную уязвимость ещё чуть‑чуть? Вот на этом «чуть‑чуть» периметр и уезжает незаметнее всего. Зрелость команды видна как раз в этот момент, а не в момент находки.
2. Уронил сервер
Как‑то мы получили bind shell на сервере заказчика и подняли на нём meterpreter, чтобы было удобнее работать. Всё шло штатно ровно до попытки поднять SOCKS‑прокси. Сетевые интерфейсы ушли в down, хост отвалился.
Сообщили заказчику сразу же, не пытаясь чинить втихую и не дожидаясь, пока это заметят у него. Через десять минут сервис поднялся. Отделались просьбой быть аккуратнее.
Могло быть хуже, и я это отлично понимаю. В момент запуска команды мы не знали, чем этот сервер был для бизнеса. Легаси без поддержки, самописный сервис, железка, которую не перезагружали годами: у любого заказчика такого добра хватает, и как назло именно оно обслуживает что‑нибудь критичное. Вывод из этого я для себя сделал такой: цену эксперимента прикидывать надо до запуска команды. Meterpreter тут ни при чём.
Юридически падение прода это в первую очередь убытки (ст. 15 и 393 ГК РФ) плюс то, что вы сами себе прописали в договоре. Если под руку попал объект КИИ, разговор пойдёт уже не про гражданское право.
Что помогает: делить действия на обратимые и те, после которых что‑то может не встать; запрещённые категории воздействий прописывать в договоре заранее (DoS, брутфорс с блокировкой учёток, массовые изменения данных, работа в пик); держать контакт эскалации на нерабочее время. И логировать себя с таймстемпами. Не ради отчёта. Ради того, чтобы через два дня показать: активность в 03:40 не наша.
А если всё‑таки сломали, говорите сразу. Скрытая авария из технической проблемы превращается в вопрос доверия, а доверие чинится куда дольше сервера.
3. Утащил лишнего
Дамп клиентской базы, выгруженный «для доказательства», перестаёт быть доказательством ровно в тот момент, когда вы его выгрузили. Дальше это просто чужие персональные данные у вас на диске.
Чувствительны тут, кстати, не одни логины с паролями. Описание непропатченной дыры в периметре это готовая инструкция для того, кто найдёт её раньше заказчика.
Правовая рамка тут шире, чем многие думают:
ст. 183 УК РФ про коммерческую, налоговую и банковскую тайну;
ст. 272.1 УК РФ, работает с декабря 2024 года, про незаконные сбор, хранение, использование и передачу компьютерной информации с персональными данными. Для нас это прямое попадание, тот самый дамп;
ст. 137 УК РФ, если в руки попали данные о частной жизни. Актуально для социотехники и OSINT;
ст. 13.11 КоАП РФ с оборотными штрафами за утечки.
Теперь про то, на каком основании мы вообще ковыряемся в чужих персональных данных. Они остаются данными заказчика, отвечает за них он, как оператор. Подрядчик работает с ними по его поручению, и вот это поручение как раз и даёт нам законное право их получать и обрабатывать. Отдельным документом или разделом договора: какие данные, зачем, на какой срок, когда уничтожаем. NDA его не заменяет, он вообще про другое: про неразглашение, а не про право обработки. То есть бумага не связывает вам руки, она их развязывает.
По практике всё сводится к скучному. Доказательств собирайте столько, сколько нужно и ни строчкой больше: скриншот с замазанными значениями, число записей, структура таблицы. Пароли в отчёт хешем или маской. Обмен внутри команды по контролируемым каналам, а не через личный телеграм и уж тем более не через первый попавшийся файлообменник. Отчёт заказчику зашифрованным, пароль отдельно. Артефакты после проекта удалять, при необходимости с актом.
4. Ущерб третьим сторонам
Договор описывает отношения двоих: вас и заказчика. Но в периметре проекта регулярно оказываются третьи, которые ничего не подписывали. Владельцы брендов. Почтовики и хостеры. Регистраторы. Иногда обычные люди. Формально всё внутри согласований, фактически риск уехал на того, кого в переговорной не было.
Чаще всего это вылезает на подборе доменов для фишинга.
Как это было у нас
Под планировавшуюся рассылку мы зарегистрировали домен, похожий на домен «Лаборатории Касперского», и подготовили страницу, повторявшую оформление ресурсов вендора. С точки зрения договора всё чисто: границы согласованы, работаем в интересах заказчика.
До рассылки дело не дошло. Специалисты «Лаборатории Касперского» нашли домен своим мониторингом раньше, чем кампания стартовала, и вышли на нас. Мы с их позицией согласились, инфраструктуру сняли, а процесс подбора доменов у себя переделали.
Проблема тут не в том, чем всё кончилось, а в самой конструкции. Домен, мимикрирующий под известного вендора, живёт своей жизнью и за пределами вашего проекта. Он светится в мониторинге самого вендора, оседает в фидах threat intelligence и блок‑листах, а после старта рассылки может попасть и к людям, которые к тестируемой компании отношения не имеют. Ни один из этих сценариев не сработал. Но риск всё это время лежал на тех, кто согласия не давал.
И есть сюжет шире нашего случая. Страница с предложением обновить средство защиты бьёт ровно по тому рефлексу, который отрасль годами воспитывала у пользователей: обновляйся вовремя, вендору доверяй. Каждый такой эпизод понемногу этот рефлекс разрушает, а расплачиваться будем все скопом, и мы в том числе.
Чем это может грозить на самом деле
Уголовные составы, которые приходят в голову первыми, к санкционированному тесту обычно не липнут: там нужны признаки, которых при работе по договору нет. А вот гражданский трек вполне реален. Обозначение, сходное до степени смешения с чужим товарным знаком, в доменном имени это ст. 1484 ГК РФ, и правообладатель может требовать компенсацию и аннулирование домена.
Только до юристов дело обычно не доходит, потому что раньше прилетает всё остальное:
Регистратор разделегирует домен по жалобе, и кампания рассыпается на середине;
Ваши домены и сети оседают в блок‑листах и фидах, а это уже проблема следующих проектов, не этого;
История уезжает в отраслевые центры реагирования, и объясняться приходится уже не по‑соседски;
Заказчик получает мусорную статистику: часть писем не дошла, часть зарезали, выводы делать не из чего.
Если в кампании есть исполняемый файл
Хуже всего чужой бренд сочетается с нагрузкой. Файл, который качается со страницы, оформленной под стороннюю компанию, снаружи выглядит как настоящая атака на эту компанию. По отдельности оба риска управляемы. Вместе получается совсем другая история.
Дальше включается автоматика, и вы на неё уже никак не влияете. Образец уходит в антивирусные базы и песочницы, хеши и домен разлетаются по фидам. Файл спокойно покидает периметр: сотрудник переслал коллеге, залил на публичную проверку, и вот его уже изучают посторонние люди без всякого контекста. А связку «чужой бренд плюс исполняемый файл» сторонний наблюдатель понесёт не к вам поговорить, а в центры реагирования и правоохранительные органы.
Правовая рамка тут тоже строже: средства для несанкционированного доступа или обхода защиты это ст. 273 УК РФ, и санкционированность работ сама собой не подразумевается.
Что с этим делать
Домены брать производные от бренда самого заказчика, с его письменного согласия, либо нейтральные. «Обновление корпоративного портала» работает не хуже «обновления антивируса».
Чужие бренды не трогать без письменного согласия правообладателя. Никаких «да мы всего на неделю».
Домен перед регистрацией прогонять на сходство с чужими товарными знаками. Пять минут против нескольких месяцев переписки потом.
Инфраструктуру закрывать allow‑list’ом по внешним IP заказчика, ссылки делать с уникальными токенами, от индексации закрываться.
Вести реестр арендованного: домен, проект, ответственный, дата снятия. Снимать сразу после кампании, а не когда кончится оплаченный период.
И если третью сторону всё‑таки задели, идите на контакт первыми. Инфраструктура, о которой вендор узнал не от вас, читается им совершенно иначе.
5. Устроил людям проверку на прочность
В социотехнике объект проверки живые люди. Согласование вы получили от компании, а участвуют в этом сотрудники, которые ни о чём не знают. Отсюда два последствия, которых обычно никто не планирует.
Первое: испорченные отношения внутри компании. Сценарии про сокращения, задержку зарплаты или болезнь родственника дают отличную конверсию, чего уж. И запоминаются надолго, тоже отлично.
Второе неприятнее. Если после теста сотрудников наказали, следующий настоящий инцидент вам никто не эскалирует. Люди усвоили: сообщать о нажатой ссылке опасно. Поздравляю, вы только что ухудшили защищённость компании, которую пришли проверять.
Что помогает: согласовывать сценарии с юристами и HR до запуска, причём в конкретных формулировках, а не «ну, что‑нибудь про почту». Темы вокруг личных трагедий и денежных страхов исключать. Разведку вести по публичным профессиональным источникам, а личные аккаунты, личные устройства и данные из утечек оставить в покое. Результаты отдавать агрегированно. И обязательно делать дебриф: людям нужно узнать, что это была проверка, что именно сработало и как в следующий раз распознать. Тест без обучения бессмысленное упражнение.
Чек‑лист перед стартом
Скоуп зафиксирован письменно, адреса проверены, облачные ограничения учтены.
Подписаны договор, NDA, авторизационное письмо.
Согласованы окна работ, запрещёнка, контакты эскалации и порядок экстренной остановки.
Исходящие IP переданы заказчику, вопрос с уведомлением мониторинга решён.
Домены проверены на чужие товарные знаки и внесены в реестр с датой снятия.
Определены каналы хранения и передачи данных, сроки и порядок уничтожения.
Заведён cleanup‑лист, согласован формат отчёта.
Вместо заключения
Все 5 пунктов скучные. Ни одного технического челленджа, сплошные бумажки, реестры и согласования, то есть ровно та часть работы, на которой экономят в первую очередь.
Забавно, что после ухода команды заказчик оценивает именно её. Работает ли инфраструктура, лежат ли данные там, где лежали, не прилетело ли кому‑то со стороны, можно ли отдать отчёт в работу без переводчика. Найденные уязвимости к этому моменту уже закрыты и подзабыты.
Если у вас есть свои грабли из этой категории, расскажите в комментариях. Чужие всегда дешевле собственных.
