Отчёт по физическому пентесту: структура и находки

На проекте для логистической компании мы прошли от парковки до серверной за 22 минуты: bump-key на служебном входе, tailgating за курящим сотрудником через незаблокированную дверь, дальше по коридору без единой камеры. Фото открытых стоек на скрытую камеру, drop-box в свободный порт коммутатора - и на выход тем же маршрутом. Вся операция заняла два часа от подъезда до отъезда. Отчёт - три недели. Потому что отчёт по физическому пентесту, который реально двигает заказчика к исправлениям, требует в разы больше работы, чем само проникновение. И вот тут большинство red team операторов проваливаются: факт проникновения доказан, но документ невозможно передать ни facility-менеджеру, ни службе охраны - никто не понимает, что конкретно чинить.

Почему отчёт по физическому пентесту - отдельный документ​

В сетевом пентесте finding привязан к IP-адресу, порту, конкретному CVE - всё однозначно и воспроизводимо. В физическом пентесте finding привязан к зоне объекта, времени суток, поведению конкретного охранника, модели замка, прошивке СКУД-контроллера. Контекст шире на порядок, а впихнуть его в стандартный шаблон - не выйдет.

Ключевые отличия от сетевых и web-отчётов:

• Невоспроизводимость. Нельзя «повторить эксплойт» - охрана уже предупреждена, замок сменили, сотрудника проинструктировали. Quality evidence (фото, видео, таймстэмпы) здесь критичнее, чем в любом другом типе пентеста.
• Множество аудиторий. Один документ читают CISO, начальник охраны, facility-менеджер, HR (если задействована социальная инженерия) и юристы. У каждого свои вопросы.
• Юридическая чувствительность. Отчёт фиксирует действия, которые без договора квалифицировались бы как уголовное преступление. Каждая формулировка должна быть точной и не создавать рисков ни для заказчика, ни для исполнителя.
• Привязка к физическому пространству. Вместо IP-адресов - этажи, корпуса, помещения, двери с инвентарными номерами. Без поэтажного плана с пометками отчёт теряет половину ценности.

Специалисты VikingCloud и TCM Security правильно говорят: главная проблема любого пентест-отчёта - разрыв между тем, что тестировщик считает очевидным, и тем, что понимает читатель. В физическом пентесте этот разрыв максимален. Заказчик часто не представляет, как клонируется RFID-пропуск или работает tailgating на практике. Для него «прошли через дверь» - это абстракция. А для нас - конкретная последовательность из семи шагов, каждый из которых нужно задокументировать.

Структура отчёта пентест: обязательные разделы​

Структура отчёта по результатам физического тестирования отвечает на три вопроса: «Что мы проверяли?», «Что нашли?», «Что с этим делать?» Всё остальное - обвязка для юристов и процессов.

Титульный лист, scope и модель нарушителя​

Титульный лист содержит название заказчика, даты проведения работ, гриф конфиденциальности, контактные данные команды и ответственного со стороны заказчика. Выглядит формальностью - но при разборе инцидента через полгода эти данные понадобятся юридическому отделу. TCM Security рекомендует также вести контроль версий на обложке, если отчёт проходит несколько итераций редактирования.

Сразу за титульным листом идёт Confidentiality Statement - обязательства сторон по обращению с документом. В физическом пентесте этот раздел критичнее, чем в сетевом: фотографии уязвимых зон объекта, маршруты проникновения, данные о реакции охраны - утечка любого из этих элементов создаёт прямую угрозу.

Scope фиксирует:

• Какие объекты тестировались - адреса, корпуса, этажи, конкретные помещения
• Какие зоны исключены и почему
• Временные окна работ: рабочие часы, ночные смены, выходные
• Допустимые методы: социальная инженерия, клонирование пропусков, вскрытие замков, установка имплантов
• Ограничения: запрет на применение силы, запрет на деструктивные методы, запрет на действия, создающие угрозу жизни и здоровью
• Наличие get-out-of-jail letter - документа, который оператор предъявляет в случае задержания охраной

Модель нарушителя - конкретный профиль с чётко определёнными возможностями, а не абстрактный «злоумышленник». Примеры профилей:

• Внешний нарушитель без предварительных знаний об объекте (посетитель, курьер)
• Внешний нарушитель с результатами OSINT-разведки (знает расположение входов, расписание смен)
• Уволенный сотрудник с просроченным пропуском
• Подрядчик с легитимным доступом в нетехнические зоны

Каждая модель определяет свой набор TTPs и свой уровень ожиданий от результатов red team по физической безопасности.

Executive Summary для физической безопасности​

Executive Summary - единственный раздел, который гарантированно прочитает генеральный директор. Одна-две страницы без технического жаргона. Структура:

1. Общий уровень защищённости - одна фраза-вердикт: «Команда получила несанкционированный доступ в серверную и подключила устройство к корпоративной сети за 22 минуты без взаимодействия с сотрудниками»
2. Ключевые риски - не «обнаружена уязвимость СКУД», а «злоумышленник может подключить устройство удалённого доступа к корпоративной сети, обойдя все существующие физические барьеры»
3. Бизнес-последствия - привязка к конкретному ущербу: компрометация данных, нарушение непрерывности процессов, репутационные потери
4. Три главные рекомендации - приоритетные, понятные без контекста остального документа

Пишется plain language - без аббревиатур, без ссылок на номера findings. Руководитель должен оценить масштаб проблемы за две минуты чтения. HackTheBox в своих гайдах по отчётности формулируют точно: «Executive stakeholders use findings to understand risks to the business at large».

Findings: карточка находки с доказательной базой​

Каждый finding оформляется отдельной карточкой. Формат оформления находок пентеста, к которому я пришёл после нескольких итераций шаблона:


Критический момент: поле «Описание» пишется как пошаговая последовательность действий, а не как свободный нарратив. Не «мы подошли к двери и открыли её», а:

1. Наблюдение за разгрузочным доком 40 минут (14:00–14:40)
2. Идентификация сотрудника с RFID-картой формата EM4100
3. Считывание карты Proxmark3 на расстоянии 5 см при передаче коробки (14:32)
4. Запись дампа на T5577-болванку (14:34)
5. Проход через считыватель двери Д-14 клонированной картой (14:38)

Такой формат делает finding неоспоримым на разборе. Заказчик видит каждый шаг, привязанный ко времени и месту. Оспорить нечего.

Документирование физического проникновения​

Таймлайн операции и фиксация evidence​

Главная ошибка начинающих операторов - фиксировать результат, но не процесс. Написано «проникли в серверную», а таймлайна с точностью до минуты нет - на разборе это оспорят. Детальный аудит физической безопасности требует хронологической точности.

Формат таймлайна в отчёте:


Этот таймлайн - скелет всего отчёта. Из него генерируются findings, из findings - рекомендации для заказчика.

Фото и видео: что снимать и как хранить​

Доказательная база физического пентеста - фотографии и видеозаписи. Без них отчёт превращается в рассказ «а вот мы однажды зашли в серверную».

Что обязательно фиксировать:

• Момент преодоления барьера - видео прохода через турникет, открытия двери, прохождения СКУД
• Идентификаторы объектов - инвентарные номера дверей, модели замков, маркировка считывателей
• Состояние зон - незапертые серверные, пустующие посты охраны, открытые окна, оставленные без присмотра бейджи
• Установленные устройства - фото drop-box на месте подключения, подброшенных USB-носителей
• Реакция персонала - охрана не отреагировала (или отреагировала - тоже ценная информация)

Организация evidence на диске:
Каждый файл содержит EXIF-данные с геолокацией и временем. Файл metadata.txt дублирует информацию текстом на случай потери EXIF при передаче.

Отдельная история - социальная инженерия в отчёте. Если оператор использовал SE для прохода (представился курьером, сотрудником подрядчика), документирование физического проникновения такого типа требует баланса: нужно зафиксировать факт и способ, но не превращать отчёт в «досье» на конкретного человека. Формулировка «сотрудник ресепшен (должность, без ФИО) выписал гостевой пропуск без верификации звонком заказчику визита» - корректна. «Мария Иванова с ресепшен пропустила нас без вопросов» - нет. Социальная инженерия в отчёте фиксируется как уязвимость процесса, а не ошибка конкретного человека. Это принципиально - иначе заказчик вместо исправления процедуры уволит секретаря, и через месяц новый секретарь сделает то же самое.

Оценка рисков физической безопасности​

Шкала severity для физических находок​

CVSS создавалась для программных уязвимостей и плохо ложится на физический контекст. Нет понятия «вектор атаки: сетевой» для вскрытого замка. Но заказчик ожидает формализованную оценку, а не «это серьёзно, поверьте».

Адаптированная шкала, которую я применяю в отчётах:


По данным TCM Security, включение informational findings (в том числе позитивных) укрепляет доверие заказчика: вы показываете не только проблемы, но и то, что работает. «Контроль доступа в зону R&D эффективен: попытка прохода с клонированной картой отклонена, охрана отреагировала в течение 40 секунд» - такой finding стоит больше, чем кажется. Он демонстрирует объективность, и заказчик перестаёт воспринимать отчёт как «список обвинений».

Привязка находок к MITRE ATT&CK​

Маппинг физических находок на MITRE ATT&CK решает две задачи: даёт единый язык для коммуникации red team и blue team, а также показывает, как физический initial access превращается в сетевую атаку.

Техники, релевантные физическому red team:


В карточке finding указывается конкретная техника с T-кодом. Это позволяет SOC-аналитикам на стороне заказчика сопоставить результаты физического пентеста с detection-правилами: есть ли алерт на подключение нового USB-устройства (T1091)? Сработает ли NAC при появлении неизвестного MAC-адреса на порту серверного коммутатора (T1200)? На практике ответ почти всегда «нет» - и это отдельный finding.

Рекомендации по физической безопасности для заказчика​

Формулировки, которые facility-менеджер поймёт​

Главная болезнь раздела рекомендаций - формулировки, адресованные в пустоту. «Усилить контроль доступа» - это пожелание, а не задача. Такое можно в стратегию на пять лет написать, но не в операционный документ. Red team отчёт заказчику превращается в реальные изменения только тогда, когда каждая рекомендация содержит три элемента: что сделать, кто делает, как проверить.


Каждая рекомендация адресована конкретному человеку. Без этого документ ляжет на стол CISO и там останется - CISO не меняет замки и не тренирует охранников.

Таблица приоритетов исправлений​

В конце отчёта - сводная таблица, которую заказчик может распечатать и раздать ответственным:


Сроки обсуждаются с заказчиком при передаче отчёта и фиксируются как обязательства. Через согласованный период проводится ретест конкретных findings - не всего периметра заново, а точечная проверка.

Пример отчёта физический пентест: полная карточка​

Эта карточка отвечает на все вопросы: что произошло, как именно, какие доказательства, к чему ведёт и что делать. Ни один пункт нельзя оспорить на разборе - каждый шаг задокументирован с привязкой ко времени, месту и evidence.

За семь лет физического red team я сдал порядка сорока отчётов. Первые десять были технически безупречны и бесполезны. Заказчик читал, кивал, клал документ в папку - и через год вызывал нас снова с теми же дырами. Проблема была не в находках, а в адресности формулировок. «Рекомендуется усилить контроль» - это не задача, это пожелание на Новый год. «Заменить считыватель EM4100 на DESFire EV3 на двери Д-14, ответственный Иванов, срок 60 дней, критерий верификации - невозможность считывания Proxmark3» - вот это задача, которую можно поставить в трекер и проконтролировать.

Физический пентест без такого отчёта - дорогой аттракцион для совета директоров. Документ, который после разбора разлетается на тикеты в трёх подразделениях - инструмент, окупающий проект за первый квартал. Большинство операторов тратят 90% энергии на проникновение и 10% на документ. По моему опыту, соотношение должно быть обратным. Самый красивый bypass двери ничего не стоит, если через месяц дверь всё ещё открыта тем же способом. А она будет открыта, если finding написан так, что facility-менеджер не понял, какой именно замок менять.