Рутинный мониторинг Censys - самоподписанные SSL-сертификаты на нестандартных портах - иногда подкидывает подарки. VPS с открытым directory listing, на котором валяются PHP-файлы фишингового кита, HTML-шаблон поддельной страницы авторизации Microsoft 365 и текстовый лог с парами email
assword, записанными с точностью до секунды. Вся раскрытая C2-панель фишинговой кампании - из-за одной ошибки в конфигурации Apache. От обнаружения до полной документации инфраструктуры атакующего - меньше часа, без единого активного эксплойта. Ниже - пошаговая методология: от первого запроса до построения полной карты command and control инфраструктуры.Бизнес-логика фишинговой атаки: зачем атакующему C2-панель
Фишинговая кампания - не одиночное письмо со ссылкой. Это инфраструктурная операция. По модели MITRE ATT&CK, атакующий проходит несколько этапов:- Resource Development: регистрация доменов - Domains (T1583.001, Resource Development) - и аренда серверов - Server (T1583.004, Resource Development) - под хостинг фишинговых страниц и C2-панель.
- Reconnaissance: сбор email-адресов и данных о жертвах - Credentials (T1589.001, Reconnaissance).
- Initial Access: доставка фишинговых ссылок - Spearphishing Link (T1566.002, Initial Access).
- Credential Access: захват учётных данных через поддельные веб-порталы - Web Portal Capture (T1056.003, Collection/Credential Access).
- Command and Control: управление кампанией и выгрузка украденных данных через веб-протоколы - Web Protocols (T1071.001, C2).
Собранные credential-ы - не конечная цель, а стартовая точка. Украденные учётные данные идут на Initial Access во внутренние системы организации. Цепочки эксплуатации вроде CVE-2025-49706 (Improper Authentication / Spoofing в SharePoint, CVSS 6.5 MEDIUM, CWE-287) + CVE-2025-49704 (Code Injection в SharePoint, CVSS 8.8 HIGH, CWE-94) показывают типичный вектор: фишинг -> credential -> доступ к корпоративному SharePoint -> выполнение кода -> ransomware. CVE-2025-49706 (auth bypass) даёт spoofing, через который атакующий получает привилегии (PR:L), нужные для эксплуатации CVE-2025-49704 (authenticated RCE). Обе добавлены CISA в KEV с ransomware-ассоциацией. Нюанс: для обеих уязвимостей существуют patch bypass - CVE-2025-53771 (для 49706, CVSS 6.5) и CVE-2025-53770 (для 49704, CVSS 9.8 CRITICAL, CWE-502, эксплуатация in the wild) - полноценная защита только с патчами для них. Фишинговая панель - первое звено этой цепочки.
Масштаб рынка credential-ов даёт понять мотивацию. Combo-list Exploit.In, опубликованный в октябре 2016, содержит 593 427 119 уникальных пар email
assword (по данным HIBP). Дамп mail.ru, появившийся в сентябре 2014, - 16 630 988 записей. Каждая фишинговая кампания пополняет эти базы. По данным отчёта Group-IB/CERT-GIB за 2022 год, зафиксировано свыше 59 000 фишинговых сайтов, около 7 000 из них нацелены на российских пользователей - рост вдвое за год. Глобально, согласно поквартальным отчётам APWG Phishing Activity Trends Report за 2022 год, суммарное число зафиксированных фишинговых атак - порядка 4,7 миллиона. За каждой кампанией стоит инфраструктура. И в каждой инфраструктуре - потенциальные OPSEC-провалы.Threat actor OPSEC: типовые провалы, раскрывающие C2-панели
В исследовании Hacktive Security точно сформулирована суть: катастрофические OPSEC-провалы - не результат одного гениального хода защитника. Это продукт накопления фундаментальных технических ошибок атакующего. Модель "смерть от тысячи порезов" - переиспользованный username, дефолтная конфигурация, незакрытый directory listing. Каждая мелочь по отдельности некритична, но в совокупности - прямой путь к атрибуции и раскрытию инфраструктуры.
Дефолтные конфигурации и открытый directory listing
Самая частая OPSEC-ошибка - оставить веб-сервер в дефолтной конфигурации. Apache httpd по умолчанию включаетmod_autoindex(mod_autoindex - Apache HTTP Server Version 2.4), который при отсутствии index.html показывает содержимое каталога. Атакующий загружает фишинговый кит, проверяет рендеринг страницы авторизации - но не проверяет корневой каталог. Shodan или Censys индексируют directory listing с полным списком PHP-файлов, конфигов и логов credential-ов. Подарок.Вторая разновидность - панели управления базами данных. phpMyAdmin, поставленный для работы с credential-логами, торчит на стандартном
/phpmyadmin/ без аутентификации или с дефолтными учётными данными.Отдельная категория - дефолтные настройки C2-фреймворков. Hacktive Security разбирает, как стандартные конфигурации создают уникальные сигнатуры: дефолтные SSL-сертификаты с характерным Subject/Issuer, стандартные HTTP-заголовки, типовые URI-паттерны. Фишинговые операции на таких фреймворках детектируются массовым сканированием именно по этим артефактам - достаточно одного запроса к Censys по fingerprint сертификата.
Ограничение: обнаружение через directory listing работает преимущественно против commodity-фишинга. Продвинутые группы закрывают панели за reverse proxy, VPN или
.htaccess с IP-фильтрацией. Против APT-операций нужна другая методология - мониторинг регистрации доменов в real-time и корреляция через passive DNS.Утечки через код и метаданные
Вторая категория - утечки через публичные сервисы. Разработчики фишинговых китов выкладывают фрагменты кода на GitHub или Stack Overflow для отладки. В исследовании Hacktive Security разбирается кейс Росса Ульбрихта (Silk Road), где связь между реальной личностью и псевдонимом установили через код, опубликованный на публичном форуме под username, привязанным к реальному email. Тот же паттерн работает с фишинговой инфраструктурой: атакующий публикует вопрос "почему PHP-скрипт не пишет в файл" - и в контексте вопроса раскрывает IP-адрес, версию сервера, структуру каталогов. Классика.IT-специалисты, публикующие детальные логи ошибок на форумах техподдержки, как отмечает ThreatNG Security, часто раскрывают версии серверов, уровни патчей и конкретные конфигурации. Для атакующего - список уязвимостей к эксплуатации. Для исследователя, отслеживающего фишинговую инфраструктуру, - возможность привязать сервер к конкретному оператору.
Метаданные в документах - ещё один источник. PDF и Office-файлы, загруженные на сервер как приманки, содержат имя автора, версию ПО и внутренний путь к файлу. Эти данные помогают связать кампании одного оператора между собой, даже если домены и IP-адреса полностью различаются.
Переиспользование инфраструктуры между кампаниями
Третий паттерн - переиспользование IP-адресов, доменов и SSL-сертификатов. Атакующий, развернувший фишинговую страницу на VPS, редко меняет сервер для следующей кампании. Один IP «светится» в нескольких базах репутации, а historical DNS-записи связывают домены, зарегистрированные с разницей в недели.Этот провал нарушает принцип изоляции инфраструктуры. Если исследователь находит один раскрытый сервер, через passive DNS и SSL-сертификаты он разматывает всю цепочку: какие домены резолвились на этот IP, какие сертификаты выпускались для связанных доменов, какие другие IP использовались тем же регистрантом. Одна раскрытая C2-панель превращается в карту десятков кампаний.
Свежий пример - фишинговая кампания, нацеленная на клиентов гостиниц в Люксембурге, зафиксированная CIRCL (Computer Incident Response Center Luxembourg) в июне 2026 года. Атакующие зарегистрировали серию доменов, имитирующих бренд отеля, на одном и том же VPS - связь между доменами прослеживается через WHOIS-паттерны и shared hosting. Лень - главный враг OPSEC.
Phishing kit анализ: разбор фишингового бэкенда
Структура типового фишингового кита
Фишинговый кит - ZIP-архив с набором файлов, из которых собирается поддельная страница авторизации и бэкенд для сбора учётных данных. Типовая структура:index.html/index.php- landing page, визуальная копия легитимного сервиса (Microsoft 365, Google Workspace, корпоративный портал).post.php/login.php- обработчик формы, принимающий POST-запрос с email и паролем жертвы.results.txt/log.txt- лог украденных credential-ов в plaintext./assets/,/css/,/img/- статические ресурсы, скопированные с легитимного сайта..htaccess- правила перенаправления и, в теории, ограничения доступа.
PHP:
// Пример для демонстрации концепции - типовой обработчик фишингового кита
$log = date('Y-m-d H:i:s') . "|" . $_POST['email'] . "|" . $_POST['pass'];
$log .= "|" . $_SERVER['REMOTE_ADDR'] . "|" . $_SERVER['HTTP_USER_AGENT'];
file_put_contents('results.txt', $log . "\n", FILE_APPEND);
header('Location: https://login.microsoftonline.com');results.txt. При открытом directory listing он доступен любому, кто знает URL. Именно он чаще всего становится первой находкой при анализе фишинговой инфраструктуры.Более продвинутые киты отправляют credential-ы на email атакующего через
mail() или в Telegram-бот через curl к api.telegram.org. Но даже тогда на сервере часто остаётся локальная копия лога - привычка писать бэкап сильнее OPSEC-дисциплины.Контекст применимости: описанная структура характерна для commodity-фишинга и mass-campaign операций. APT-группы используют более сложные бэкенды - на Go или Python, с шифрованием credential-ов и интеграцией с полноценными C2-фреймворками. Там нужен динамический анализ и реверс бинарных компонентов.
Декодирование ссылок: что именно хочет украсть атакующий
Фишинговые URL часто содержат закодированную информацию о жертве. Типичная ссылка видаhttps://phishing-domain.example/dXNlcm5hbWVAZG9tYWluLmxvY2Fs содержит Base64-закодированный email. Декодирование через CyberChef или echo 'dXNlcm5hbWVAZG9tYWluLmxvY2Fs' | base64 -d раскрывает username@domain.local.Это таргетированная атака: атакующий заранее знает email жертвы. На фишинговой странице поле email предзаполнено - жертве остаётся ввести только пароль. Конверсия выше, и одновременно остаётся артефакт для исследователя.
Кроме Base64, встречаются URL-encoded строки, HEX-кодирование и комбинированные схемы. CyberChef поддерживает автоматическое определение кодировки через режим "Magic" - он перебирает варианты и предлагает наиболее вероятную декодировку.
Исследование URL из раскрытой панели управления фишингом позволяет определить: количество целей (число уникальных URL), организации-жертвы (по доменам email), географию кампании (по временным меткам в логах) и её эффективность (соотношение сгенерированных ссылок к записанным credential-ам).
Infrastructure pivoting: от одного сервера к сети атакующего
Passive DNS и SSL-сертификаты как точки разворота
Обнаружение одного фишингового сервера - начало исследования, не конец. Infrastructure pivoting позволяет восстановить полную карту инфраструктуры атакующего через корреляцию косвенных данных.Три основных pivot-точки:
SSL-сертификаты. Если атакующий использовал Let's Encrypt, Certificate Transparency Logs содержат запись о каждом выпущенном сертификате. Поиск через crt.sh по паттерну доменного имени или email регистранта выявляет связанные домены. Самоподписанные сертификаты ещё информативнее - поля Subject и Issuer часто содержат повторяющиеся значения, уникальные для конкретного оператора. Censys позволяет искать серверы по fingerprint сертификата, раскрывая другие хосты с тем же сертификатом.
Passive DNS. SecurityTrails, PassiveTotal или VirusTotal хранят историческую привязку доменов к IP-адресам. Если
phishing-domain-1.example и phishing-domain-2.example резолвились на один IP с разницей в неделю - это один оператор. Обратный запрос (все домены, указывавшие на конкретный IP) часто раскрывает десятки кампаний.WHOIS и регистрационные данные. Несмотря на GDPR-редактирование WHOIS, атакующие нередко регистрируют домены через один аккаунт. Timestamp создания, nameserver-ы и регистратор становятся pivot-точками. Паттерн именования доменов (
login-microsoftonline-com-verify.example, microsoft365-auth-update.example) тоже создаёт кластеризуемую сигнатуру.Инструментарий для исследования фишинговой инфраструктуры
| Инструмент | Преимущества | Ограничения | Когда использовать | Когда не использовать |
|---|---|---|---|---|
| Shodan | Поиск по HTTP-заголовкам, баннерам, favicon hash | Бесплатный тариф ограничен, не все порты | Первичный поиск серверов по fingerprint кита | Анализ содержимого страниц |
| Censys | Глубокий анализ TLS-сертификатов, BigQuery | Медленнее для массовых запросов | Pivoting через Subject/Issuer сертификатов | Поиск по body HTTP-ответов |
| URLScan.io | Скриншот, DOM-дерево, сетевые запросы | Публичные сканы видны атакующему | Безопасный просмотр фишинговой страницы | Скрытое исследование |
| VirusTotal Graph | Визуализация связей IP - домены - файлы | Данные видны подписчикам | Построение карты инфраструктуры | Приватное расследование |
| CyberChef | Декодирование Base64, URL, HEX в браузере | Только ручная обработка | Разбор кодированных URL из писем | Массовый анализ тысяч ссылок |
| crt.sh | Поиск сертификатов через CT Logs, бесплатный | Только SSL/TLS-сертификаты | Обнаружение связанных доменов | Инфраструктура без SSL |
Практический запрос для Shodan - поиск серверов с характерными признаками доступа к панели управления фишингом:
Bash:
# Поиск серверов с open directory и характерными артефактами
shodan search 'http.title:"Index of /" http.html:"results.txt"' --fields ip_str,port,hostnamesresults.txt - типовое имя лога credential-ов. Обращение к публичному индексу Shodan и просмотр directory listing на веб-сервере не являются несанкционированным доступом.OPSEC самого исследователя. Этот момент часто упускают - и зря. Pentest Partners описывает показательный кейс: при расследовании фишинга blue team переслала подозрительное письмо IT-отделу. Сотрудники открыли его в десктопном Outlook при подключении через split tunnel VPN - атакующий собрал их NetNTLM-хэши через SMB-вызов, встроенный в тело письма. Хуже того - blue team загрузила URL фишинговой страницы на VirusTotal, и один из сторонних исследователей, обнаружив URL через VirusTotal, ввёл валидные учётные данные Microsoft 365 на фишинговой странице. Два OPSEC-провала за одно расследование - и оба на стороне защитников.
VirusTotal - инструмент с двунаправленной видимостью. Всё, что туда загружено, доступно подписчикам. Загрузка IoC до завершения исследования может спугнуть атакующего или раскрыть данные жертв.
Требования к окружению для анализа инфраструктуры атакующего
Минимальные требования:- ОС: любая (GNU/Linux предпочтительнее для CLI-инструментов), Kali Linux или Ubuntu 22.04+
- RAM: 4 ГБ минимум (инструменты не ресурсоёмкие, нагрузка на внешние API)
- Сеть: стабильный интернет, все инструменты работают через API
- VPN или Tor: для изоляции IP исследователя от инфраструктуры атакующего
- Аккаунты: бесплатные учётные записи Shodan, Censys, URLScan.io, VirusTotal (платные тарифы расширяют лимиты)
- CLI:
curl,whois,dig,openssl(предустановлены в большинстве Linux-дистрибутивов),jqдля парсинга JSON
- Виртуальная машина или Windows Sandbox для открытия подозрительных файлов (8 ГБ RAM на хосте)
- Burp Suite Community для ручного анализа HTTP-запросов фишинговых страниц
- Python 3.x с библиотеками
requests,jsonдля автоматизации pivot-запросов - Режим работы: только онлайн - все ключевые инструменты зависят от внешних сервисов
Ограничения техники и правовые рамки исследования
Если фишинговая кампания направлена на объекты КИИ, информирование НКЦКИ обязательно по ФЗ-187 "О безопасности критической информационной инфраструктуры" (ст. 2, определяющая понятие компьютерной атаки; ст. 14 о государственном контроле).
Большинство публикаций об анализе фишинговой инфраструктуры в русскоязычном сегменте остаются на уровне "проверьте SPF-запись и посмотрите заголовки письма". Для Security Awareness - годится. Для threat intelligence - примерно как изучать хирургию по школьному учебнику анатомии. Реальная ценность начинается за пределами входящего письма - на стороне инфраструктуры атакующего.
Парадокс в том, что OPSEC-ошибки фишинговых операторов - не дефицитный ресурс. Открытые directory listing, дефолтные конфигурации, credential-логи в plaintext - всё это массово обнаруживается через Shodan и Censys каждый день. Проблема не в обнаружении, а в обработке: большинство найденных панелей никто не документирует, IoC не передаются в CERT, инфраструктура продолжает работать до истечения срока аренды VPS. Тот же сервер потом переиспользуется для следующей кампании - и цикл повторяется.
Инструменты доступны, методология описана, правовые рамки допускают пассивное наблюдение. Не хватает систематической практики: регулярного мониторинга, стандартизированных форматов отчётов и налаженного канала передачи IoC тем, кто может заблокировать домен за минуты, а не за дни. Попробуйте запустить запрос из раздела про Shodan - и посмотрите, сколько открытых панелей найдётся прямо сейчас. Пока каждый исследователь работает в изоляции, фишинговые операторы будут продолжать совершать одни и те же ошибки - и оставаться безнаказанными.
Последнее редактирование модератором:
