Проверяли защиту — нашли атаку. Как пентестеру перестроиться на сценарий Incident Response. И почему для клиента это важнее, чем самый качественный отчет
Криминалисты поневоле
Этичный хакинг, он же пентест, — всегда прогулка по лезвию ножа. Ты действуешь как злоумышленник, но с благой целью: по заказу клиента найти у него уязвимости и указать на них прежде, чем слабостями ИБ-периметра заказчика воспользуются киберпреступники. Как правило, исследование движется по накатанной и нередко дает предсказуемые результаты. Вот здесь давно не обновляемая операционная система. Тут — слабые пароли. Там недокументированные API. В публичном облаке — забытые тестовые стейджинги. Все предельно понятно.
Но однажды обычный пентест вдруг пошел не по плану. В процессе согласованного «вторжения» мы обнаружили: внутри клиентского ИБ-периметра уже кто-то побывал. И этот кто-то не просто заглянул из любопытства. Он закрепился, оставил шпионский инвентарь, настроил доступы и тянет за ниточки, чтобы использовать инфраструктуру клиента в своих интересах.
Мы приняли решение взять на себя больше, чем обычно берет команда пентеста. Из проверки защиты для отчета в формате «вот уязвимость, а вот рекомендация» работа превратилась в настоящее киберрасследование, приправленное совокупностью мер быстрого реагирования на сам факт присутствия хакеров. Так мы совершенно спонтанно примерили на себя роль ИБ-криминалистов, хотя на старте проекта о ней даже не помышляли.
Часть первая. Плановый прорыв с неплановыми находками
Несколько лет назад, в разгар активной эксплуатации набора уязвимостей ProxyLogon в Microsoft Exchange, наша команда проводила комплексный пентест для крупной компании. Цель — получить права администратора домена, доступ к системе резервного копирования и найти возможность скопировать конфиденциальную информацию. Цепочка стандартная: CVE-2021-26855 (SSRF) → CVE-2021-27065 (загрузка файлов) → и вот мы уже на почтовом сервере Exchange с правами SYSTEM.
Успех? Несомненно. Далее мы начали классическое закрепление в инфраструктуре: искали пути к другим системам, изучали внутреннюю сеть, пытались разместить свои инструменты для обратных подключений (reverse shell). И именно здесь нас ждал первый тревожный сигнал. В ключевых каталогах, куда обычно прописывается автозагрузка или куда удобно скидывать исполняемые файлы (например, C:\ProgramData, временные каталоги IIS), мы обнаружили незнакомые исполняемые файлы и библиотеки. Их имена не соответствовали ни нашим инструментам, ни стандартному софту сервера.
Часть вторая. «Коллега, я вас вижу»
Быстрый статический анализ файлов, проверка цифровых подписей (точнее, их отсутствия) и обзор сетевых соединений сервера не оставили сомнений: мы наткнулись на следы чужой активности. На Exchange уже жили несколько инструментов удаленного доступа: от привычных бэкдоров на C++ до более хитрых скриптовых имплантов.
Получился настоящий «зоопарк», который обычно означает одно из двух: либо сервер уже пережил несколько независимых атак, либо злоумышленники сознательно держат набор разных инструментов — на случай, если один из них обнаружат и попытаются заблокировать.
План пентеста в этот момент мгновенно устарел. Перед нами встала двуединая задача.
Во-первых, не навредить. Любое действие могло указать злоумышленнику, что его заметили. Сам факт обнаружения с большой долей вероятности подтолкнул бы хакеров к попытке замести цифровые следы, важные для расследования. Что при наличии разнообразного инвентаря можно было бы сделать несколькими способами.
Во-вторых, вернуть контроль. Клиент хотел знать не только о найденных уязвимостях, но и о признаках полноценного компрометирующего проникновения, чтобы перейти от «проверки на прочность» к расследованию, локализации и очистке инфраструктуры.
Часть третья. Смена ролей: от белых хакеров к исследователям
Мы немедленно согласовали с заказчиком изменение юридических аспектов пентеста и привели документы в соответствие новым обстоятельствам. Клиент разрешил и приветствовал расширение полномочий команды: формат пентеста официально дополнили реагированием на инцидент (Incident Response).
После этого приоритет сместился с эксплуатации уязвимостей на восстановление картины происходящего. Мы подняли и начали разбирать логи Exchange, журналы Windows (Security, System, PowerShell) и IIS. Фокус был на поиске аномалий. Ими могли стать необычное время активности, подозрительные учетные записи, серии успешных и неуспешных попыток входа, следы запуска команд и скриптов.
Следующий шаг — артефакты и «точки закрепления». Мы искали, где именно размещались инструменты удаленного доступа, как они сохранялись после перезагрузки (службы, планировщик заданий, автозагрузка через реестр) и куда уходили соединения, то есть на какие внешние адреса были настроены управляющие серверы (C2).
Параллельно мы собирали динамическую карту атаки почти в реальном времени: накладывали действия злоумышленников на хронологию: как и когда они вошли через ту же уязвимость (ProxyLogon), насколько быстро развернули инструменты, когда пытались перемещаться по сети и добраться до данных.
Работали предельно осторожно. Мы исходили из того, что в любой момент злоумышленники могут заметить изменения в системе — и тогда начнут заметать следы или ускорят свои действия. Такой расклад сильно усложнил бы и расследование, и восстановление контроля.
Осторожность была вознаграждена: свою часть работы мы выполнили, не вызвав никаких подозрений у «коллег».
Часть четвертая. Ликвидация последствий
После того как мы зафиксировали ключевые артефакты и собрали доказательства, команда вместе с заказчиком перешла к этапу локализации и очистки: нужно было убрать следы чужого присутствия и закрыть ту самую дверь, через которую, собственно, и проникли незваные гости.
В первую очередь мы удалили обнаруженные посторонние исполняемые файлы и скрипты — аккуратно, с сохранением копий и контрольных сумм для возможного дальнейшего расследования. Затем очистили механизмы закрепления: записи в реестре, задачи и службы, которые обеспечивали автозапуск вредоносных компонентов.
Параллельно закрыли первопричину инцидента — накатили обновления Exchange, устранив уязвимость, через которую злоумышленники получили доступ.
Отдельный блок рекомендаций касался кибергигиены после инцидента. Мы настоятельно посоветовали заказчику сменить пароли привилегированных учетных записей, рассмотреть внедрение двухфакторной аутентификации, провести аудит сети на предмет вторичных точек доступа. И для верности усилить мониторинг. Просто чтобы убедиться, что скрытых «закладок» не осталось и злоумышленник не предпримет попытку повторного входа.
Заключение: уроки неплановой операции
Ретроспективно я могу сказать, что мы сработали правильно. Но «в моменте» каждое решение приходилось принимать с учетом множества реальных и вероятных обстоятельств. Работа шла круглые сутки. Команде пришлось изрядно понервничать, и это нормально: в таких ситуациях цена ошибки слишком высока. Зато если нам снова предстоит похожая комбинированная операция, мы уже знаем, как действовать.
Выводы, которые мы сделали вместе с клиентом
1. Пентест — не гарантия отсутствия угроз. Это снимок уязвимостей на момент проверки. Проверка тестированием на проникновение становится шагом к практической (то есть эффективной) кибербезопасности, только когда ее результаты принимаются как руководство к реализации в рамках общего процесса ИБ. То есть пентест — повод для разговора об улучшении ИБ, но никак не справка об отсутствии рисков.
2. Гибкость — ключевое качество. Готовность быстро перестроить работу под новые, более острые обстоятельства критически важна. Чем разнообразнее опыт сотрудников, тем выше шансы для пентест-команды «вывезти» такой сложный кейс.
3. Обнаружение следов чужой атаки — несомненный успех, но никак не провал. Мы выполнили главную задачу: нашли скрытую проблему, которая уже наносила реальный ущерб. Заказчик получил конкретный план выхода из кризиса. В его случае это намного более весомое приобретение, чем констатация статуса корпоративной ИБ.
4. EDR и мониторинг действительно решают. Итог проекта лучше любых аргументов показал заказчику необходимость развертывания системы класса Endpoint Detection and Response. При ее наличии найденные нами RAT, вероятно, удалось бы обнаружить гораздо раньше.
Доказательство того, что уязвимостью уже пользуется некая третья сторона в интересах, не понятных заказчику пентеста, — самая ценная находка пентестера. Но она же ставит исполнителя услуг этичного взлома перед непростым выбором: ограничиться своей непосредственной задачей или выйти за ее рамки и стать первым, кто окажет клиенту реальную помощь прямо сейчас.
Опция «помочь немедленно» предполагает максимум ответственности. Но именно она наиболее полно раскрывает пожелание от клиента к «кибербезопасникам»: спасать прямо сейчас, пока не стало совсем плохо.