Хроника одного пентеста

С чего начался пентест

К началу описываемых событий команда уже завершила внешний этап тестирования. Специалисты проверили, насколько хорошо ИТ-инфраструктура компании защищена от атак из интернета, и передали заказчику результаты.

Следующим этапом стал внутренний пентест в формате black box — «чёрного ящика». При таком подходе Следующим этапом стал внутренний пентест в формате black box — «чёрного ящика». При таком подходе специалист получает минимальный объём исходной информации и действует примерно в тех же условиях, в которых оказался бы внешний нарушитель.

В область проверки вошли:

• возможность попасть в офис без действующего пропуска;
• действия охраны и сотрудников ресепшена;
• доступность переговорных и технических помещений;
• реакция сотрудников на незнакомые устройства и подозрительные сообщения;
• защищённость внутренних рабочих станций;
• устойчивость корпоративных учётных записей;
• возможность получить повышенные привилегии;
• глубина потенциального продвижения по внутренней сети.

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

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

Подготовка к внутреннему пентесту

Офис заказчика занимал три нижних этажа бизнес-центра. На входе находились электронные турникеты, за которыми следовали пост охраны и ресепшен.

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

• устройство для проверки защищённости электронных пропусков и бесконтактных меток;
• компактный одноплатный компьютер;
• тестовый веб-сервер с имитацией корпоративного интерфейса;
• несколько USB-накопителей с контролируемой тестовой нагрузкой.

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

Это не означало, что все подготовленные методы обязательно будут применены. Во время пентеста специалисты обычно формируют несколько гипотез и последовательно проверяют их. Если один способ не работает, команда переходит к другому, не выходя за согласованные границы.

Как во время пентеста удалось попасть в офис

Первая попытка: электронный пропуск

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

Попытка не удалась: сотрудник быстро убрал бейдж. Для гарантированного копирования пришлось бы получить физический доступ к пропуску, а это уже выходило за допустимые границы пентеста.

Сценарий остановили и перешли к менее технологичному, но более распространённому способу — имитации личности действующего сотрудника.

Этот эпизод показывает, почему пентест нельзя сводить к заранее прописанной последовательности команд. Реальная проверка защищённости всегда содержит элемент неопределённости. Специалист должен оценивать ситуацию и выбирать следующий допустимый сценарий в зависимости от реакции людей и систем.

Поддельный бейдж оказался убедительнее технологии

Ещё на этапе внешнего тестирования команда нашла в открытых источниках сведения об одном из сотрудников технической поддержки заказчика. На основе этой информации подготовили бейдж с его именем и фотографией пентестера.

На проходной специалист показал бейдж охраннику и сообщил, что забыл электронный пропуск. Охрана связалась с ресепшеном компании. Сотрудник ресепшена подтвердил, что человек с указанным на бейдже именем действительно работает в организации.

Охранник попросил предъявить паспорт. Пентестер ответил, что документ остался дома, и снова показал корпоративный бейдж. После непродолжительного разговора охранник записал данные с бейджа в журнал и пропустил посетителя.

Каждый участник процесса выполнил часть привычной процедуры:

• охранник проверил наличие бейджа;
• ресепшен подтвердил существование сотрудника;
• сведения о посетителе внесли в журнал.

Однако никто не подтвердил, что перед ними находится именно тот человек, чьё имя указано на бейдже. Несколько формально выполненных действий не сложились в полноценную проверку личности. Однако никто не подтвердил, что перед ними находится именно тот человек, чьё имя указано на бейдже. Несколько формально выполненных действий не сложились в полноценную проверку личности.

Физическая безопасность зависит не только от турникетов и электронных пропусков. Важнее то, как сотрудники действуют при исключениях: забытом пропуске, отсутствии документа, визите подрядчика или просьбе провести человека «на несколько минут».

Что происходило внутри офиса во время пентеста

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

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

Для внутреннего пентеста такие зоны особенно интересны:

• в переговорных остаётся подключённое оборудование;
• на кухнях и в общих зонах сотрудники менее внимательны;
• на свободных столах могут находиться документы и рабочие устройства;
• технического специалиста с кабелем или небольшим устройством редко воспринимают как угрозу;
• незнакомый человек может объяснить своё присутствие обслуживанием оборудования.

По пути пентестер оставил подготовленные USB-накопители на нескольких столах и рядом с кофейной машиной. Это был дополнительный сценарий проверки, но основной вектор пентеста к этому моменту уже сместился в сторону оборудования для видеоконференций.

Как ВКС-терминал стал точкой входа во время пентеста

В переговорных комнатах находились большие экраны для проведения видеоконференций. Они работали в режиме киоска: пользователь видел только интерфейс приложения и не взаимодействовал напрямую с операционной системой.

С точки зрения сотрудника это просто экран для запуска встречи. С точки зрения специалиста по пентестам — полноценный компьютер, подключённый к внутренней инфраструктуре. по пентестам — полноценный компьютер, подключённый к внутренней инфраструктуре.

О таких устройствах команда узнала ещё во время внешнего этапа проверки и подготовила соответствующий сценарий. Вход в корпоративный сервис видеоконференций выполнялся с использованием учётной записи Windows Active Directory. Кроме пользовательской формы, система имела административный интерфейс, применявшийся для настройки и обслуживания.

Это создавало сразу несколько рисков:

• вспомогательный сервис был связан с основной доменной инфраструктурой;
• терминал находился в доступной переговорной;
• к его корпусу и USB-портам можно было подойти без дополнительного контроля;
• привычный интерфейс вызывал доверие;
• технические сбои на таком оборудовании воспринимались как рядовое событие.

Вспомогательные системы часто получают меньше внимания, чем серверы, рабочие станции и внешние сервисы. Однако именно они могут стать точкой входа во время внутреннего пентеста.

Подмена знакомого интерфейса

На компактном одноплатном компьютере заранее подготовили тестовый веб-сервер. При подключении к ВКС-терминалу устройство имитировало сетевой адаптер и открывало страницу, визуально похожую на интерфейс корпоративной системы.

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

Пентестер дождался момента, когда переговорная опустела, подключил устройство и активировал подготовленный интерфейс.

В данном случае сработала не сложность технического решения, а его соответствие привычному контексту. Сотрудники ожидали увидеть на экране форму корпоративной системы и поэтому В данном случае сработала не сложность технического решения, а его соответствие привычному контексту. Сотрудники ожидали увидеть на экране форму корпоративной системы и поэтому не воспринимали повторный запрос логина и пароля как нечто необычное.

Подобные сценарии проверяют не только внимательность пользователей. Они показывают, насколько архитектура компании способна ограничить последствия ошибки. Даже если сотрудник ввёл пароль в поддельную форму, многофакторная аутентификация, сегментация сети и контроль аномальных входов должны не позволить нарушителю свободно использовать полученные данные.

Как в ходе пентеста были получены учётные записи

Когда сотрудники начали перебирать пароли

В процессе пентеста выяснилось, что некоторые сотрудники после неудачной попытки входа вводили не только свою основную пару логин — пароль. Они пробовали другие известные им учётные данные, В процессе пентеста выяснилось, что некоторые сотрудники после неудачной попытки входа вводили не только свою основную пару логин — пароль. Они пробовали другие известные им учётные данные, включая данные коллег.

В результате команда получила настолько большой набор учётных записей, что на проверку связанных с ними прав доступа потребовалось ещё несколько дней.

Такое поведение обычно объясняется желанием быстро решить проблему. Пользователь предполагает, что ошибся в пароле, выбрал не ту учётную запись или столкнулся с временным сбоем. Вместо сообщения в ИТ-службу он начинает последовательно проверять доступные комбинации.

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

Компрометация действующих учётных записей особенно опасна: действия злоумышленника могут выглядеть как обычная работа сотрудника. MITRE ATT&CK отдельно рассматривает использование валидных учётных записей как способ первоначального доступа, повышения привилегий и перемещения между системами.

«Обратитесь к системному администратору»

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

Сотрудники последовали этой рекомендации.

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

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

В ходе пентеста были получены две учётные записи с повышенными привилегиями. Их прав оказалось достаточно, чтобы признать внутреннюю инфраструктуру компании полностью скомпрометированной. В ходе пентеста были получены две учётные записи с повышенными привилегиями. Их прав оказалось достаточно, чтобы признать внутреннюю инфраструктуру компании полностью скомпрометированной.

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

Результаты внутреннего пентеста

За один день активной фазы команда получила:

• 52 учётные записи сотрудников с логинами и паролями;
• данные нескольких личных аккаунтов в почтовых сервисах и социальных сетях;
• две административные учётные записи с повышенными привилегиями;
• доступ к облачному хранилищу записей видеоконференций, включая совещания руководства;
• возможность входа в другие рабочие приложения с помощью повторно используемых паролей.

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

Примерно половина полученных комбинаций применялась сотрудниками более чем в одной системе. Из-за этого компрометация одного интерфейса открывала доступ к дополнительным корпоративным сервисам.

Именно глубина возможного продвижения отличает пентест от простого обнаружения уязвимости. Именно глубина возможного продвижения отличает пентест от простого обнаружения уязвимости. Заказчику важно знать не только о существовании слабого места, но и о том, к каким бизнес-последствиям оно способно привести.

Почему защита не остановила атаку

Компрометация стала результатом не одной критической ошибки, а сочетания нескольких факторов. Компрометация стала результатом не одной критической ошибки, а сочетания нескольких факторов.

Доверие к внешнему контексту

Бейдж, уверенное поведение и правдоподобное объяснение создали образ действующего сотрудника. Охрана и ресепшен подтвердили отдельные детали, но не проверили личность посетителя целиком.

Отсутствие контроля исключительных ситуаций

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

Недостаточная сегментация сети

ВКС-терминал находился в той же доверенной среде, что и более критичные ресурсы. Получение доступа к вспомогательной системе создавало возможность дальнейшего продвижения.

Сегментация не должна ограничиваться разделением сети на несколько крупных зон. Доступ необходимо выдавать с учётом роли пользователя, состояния устройства и конкретного ресурса. Принципы Zero Trust предполагают отказ от автоматического доверия только на основании нахождения пользователя или устройства внутри корпоративного периметра.

Использование общих учётных записей

Связь видеоконференц-сервиса с основными учётными записями Active Directory увеличила последствия фишинга. Для специализированного оборудования целесообразно использовать отдельные профили с минимально необходимыми правами.

Повторное использование паролей

Одинаковые пароли применялись в нескольких рабочих, а иногда и личных сервисах. В результате одна полученная комбинация могла открыть сразу несколько систем.

Надёжная парольная политика должна исключать повторное использование паролей. Для хранения уникальных комбинаций следует применять корпоративный менеджер паролей.

Отсутствие многофакторной аутентификации

Одного пароля оказалось достаточно для входа в критичные сервисы. MFA не устраняет риск социальной инженерии полностью, но значительно ограничивает использование украденного пароля. В первую очередь многофакторная аутентификация необходима для административных учётных записей, удалённого доступа, почты и облачных хранилищ. Для критичных систем предпочтительны устойчивые к фишингу методы аутентификации, на что также указывает CISA.

Привычка к постоянным сбоям

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

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

Охрана отвечала за проходную, ИТ-служба — за оборудование, а сотрудники — за проведение встреч. Но никто не контролировал сценарий целиком: от появления неизвестного человека до подключения постороннего устройства и ввода административных данных.

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

Какие меры могли остановить сценарий пентеста

Чему должен научить такой пентест

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

После завершения работ заказчику необходимо получить:

1. описание подтверждённых сценариев проникновения;
2. перечень систем и данных, к которым удалось получить доступ;
3. оценку возможных последствий для бизнеса;
4. приоритизированный список уязвимостей и организационных недостатков;
5. рекомендации по устранению причин, а не только отдельных признаков;
6. план повторной проверки после внесения изменений.

Подход, при котором тестирование завершается анализом результатов и подготовкой мер защиты, соответствует логике руководства NIST SP 800-115 по проведению проверок информационной безопасности.

Если в ходе пентеста обнаруживаются системные расхождения между документами, архитектурой и реальными действиями сотрудников, область проверки целесообразно расширить до аудита информационной безопасности.

Почему одного обучения сотрудников недостаточно

После подобных кейсов легко сделать вывод, что причиной инцидента является невнимательность персонала. Это лишь часть проблемы.

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

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

Необходима эшелонированная защита:

• понятные инструкции для сотрудников;
• простая процедура сообщения о подозрительном событии;
• многофакторная аутентификация;
• минимальные привилегии;
• сегментация инфраструктуры;
• контроль подключаемых устройств;
• регистрация и анализ событий;
• защита административных учётных записей;
• регулярная проверка фактической работы мер безопасности.

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

Чек-лист для самостоятельной проверки

Компания может начать с нескольких вопросов:

• Можно ли попасть в офис без действующего электронного пропуска?
• Как охрана проверяет личность человека, который забыл документы?
• Кто имеет физический доступ к компьютерам в переговорных?
• Защищены ли USB-порты и другие интерфейсы служебного оборудования?
• Используются ли отдельные учётные записи для ВКС, терминалов и вспомогательных сервисов?
• Включена ли MFA для администраторов, почты, облачных систем и удалённого доступа?
• Могут ли пользователи применять один пароль в нескольких сервисах?
• Разделены ли пользовательские и административные привилегии?
• Ограничено ли перемещение между сегментами внутренней сети?
• Регистрируются ли подозрительные входы и подключения новых устройств?
• Знают ли сотрудники, куда сообщить о необычном запросе пароля?
• Проверяют ли администраторы физические подключения при диагностике оборудования?
• Проводился ли внутренний пентест после последних изменений инфраструктуры?
• Проверено ли устранение замечаний, найденных во время предыдущего тестирования?

Если на несколько вопросов нет однозначного ответа, это повод включить соответствующие процессы в следующий пентест или внутренний аудит.

Частые вопросы о пентесте

Чем пентест отличается от сканирования уязвимостей?

Сканер ищет известные технические недостатки по заданным правилам. Пентест проверяет, можно ли объединить несколько ошибок в полноценный сценарий атаки и получить доступ к значимым ресурсам. При этом специалист анализирует не только наличие уязвимости, но и возможные последствия её эксплуатации.

Всегда ли пентест включает социальную инженерию?

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

Может ли пентест нарушить работу систем?

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

Как часто нужно проводить пентест?

Единой периодичности для всех организаций нет. Повторная проверка особенно важна после изменения внешнего периметра, запуска нового сервиса, переноса инфраструктуры, изменения схемы удалённого доступа или устранения ранее найденных уязвимостей.

Достаточно ли один раз устранить найденные проблемы?

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

Что в итоге

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

• личность посетителя проверили формально;
• переговорное оборудование оставалось физически доступным;
• знакомый интерфейс вызвал доверие;
• сотрудники вводили несколько �