Анализ фишинга в песочнице ANY.RUN: разбор письма и восстановление цепочки заражения

По данным Verizon DBIR 2025, фишинг — начальный вектор в 36% подтверждённых инцидентов. На L1-смене в SOC (Security Operations Center — центр мониторинга безопасности, куда стекаются алерты со всей инфраструктуры) примерно каждый третий тикет — подозрительное письмо с вложением. Большинство оказывается безвредным спамом, но примерно одно из двадцати — реальное начало компрометации. Разница между «спам» и «первая ступень атаки» определяется тем, что аналитик делает с письмом в первые пять минут. Дальше покажу свой рабочий workflow: как провожу анализ фишинга в песочнице ANY.RUN — от загрузки .eml-файла до восстановления полной цепочки заражения по сетевым индикаторам.

Зачем SOC-аналитику песочница для разбора фишинговых писем

Песочница (sandbox) — изолированная виртуальная среда, где можно безопасно запустить подозрительный файл или открыть ссылку. Всё, что происходит внутри, не затрагивает рабочую инфраструктуру. ANY.RUN — облачная интерактивная песочница, которую используют более 15 000 организаций для sandbox анализа вредоносного ПО и фишинга.

Зачем это нужно именно для фишинговых писем? Статический анализ — проверка хешей, сигнатур и заголовков без запуска файла — ловит известные угрозы. Но современные фишинговые вложения часто используют обфускацию: намеренное запутывание кода, чтобы антивирус не смог прочитать содержимое. В терминах MITRE ATT&CK (открытая база тактик и техник атак; каждая техника имеет идентификатор вида T1027) это техника T1027, Obfuscated Files or Information. Такие вложения раскрывают поведение только при реальном исполнении.

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

Бизнес-логика атакующего проста: фишинг — самый дешёвый способ доставки инфостилеров (infostealers — программы, ворующие пароли, куки, данные банковских карт). По данным IBM X-Force 2025, инфостилеры составляют 32% всех образцов вредоносного ПО. Это самый распространённый тип malware. Одно успешное письмо окупает всю кампанию.

Типичная цепочка фишинговой атаки:

Задача аналитика — пройти эту цепочку в обратном порядке: от письма к C2-серверу, собирая индикаторы компрометации на каждом шаге.

Загрузка фишингового письма в ANY.RUN и настройка среды

Предусловия: аккаунт на any.run (бесплатный тариф доступен с публичными анализами) и подозрительное письмо в формате .eml или .msg (стандартные форматы экспорта из почтовых клиентов — Outlook, Thunderbird и др.).

Шаг 1. Создаём задачу. Заходим на app.any.run, нажимаем «New task», выбираем «Submit File» и загружаем .eml-файл. ANY.RUN распознаёт почтовые форматы и отображает структуру письма: заголовки, тело, вложения.

Ожидаемый результат: файл принят, в интерфейсе появляется имя файла и его тип.

Шаг 2. Настраиваем виртуальную машину. Для большинства анализов вложений фишинговых писем я выбираю Windows 10 64-bit. Причина банальная — это самая распространённая ОС в корпоративной среде, и вредоносы чаще всего рассчитаны именно на неё. Если вложение — APK-файл (приложение Android), ANY.RUN поддерживает отдельную Android-среду.

Шаг 3. Запускаем. Нажимаем «Run». Песочница поднимает виртуальную машину и открывает письмо. В верхней части экрана появляется таймер оставшегося времени.

Параметры виртуальной машины, которые важны

Три настройки, от которых зависит полнота результатов:

Сеть. По умолчанию включён реальный интернет — вредонос сможет связаться с C2. Это нужно для восстановления цепочки заражения. Альтернатива — FakeNet (имитация сети): безопаснее, но C2-связь не состоится и часть поведения останется скрытой. Я почти всегда оставляю реальную сеть — иначе анализ получается неполным.

MITM-прокси (HTTPS). Песочница подставляет свой сертификат и расшифровывает HTTPS-соединения на лету. Без MITM вы увидите только факт подключения к IP-адресу на порту 443, но не содержимое запросов. С MITM — расшифрованные POST-запросы с украденными данными. Для анализа credential-stealing атак это критично. Запомните: без MITM вы знаете, что данные ушли, но не можете доказать что именно.

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

Разбор фишингового письма: заголовки, тело, вложение

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

Заголовки письма. Поле «From» может содержать спуфинг — подделку отправителя. Отображаемое имя говорит «DHL Express International», а реальный адрес принадлежит совершенно другому домену. В типичных фишинговых кейсах письмо якобы от DHL приходит с адреса в домене, не связанном с логистикой. Атакующие нередко целятся в supply chain (цепочку поставок), используя реальные деловые связи жертвы.

Тело письма. Обращаю внимание на элементы давления («your package requires immediate action»), корпоративный стиль и ссылки. GenAI-инструменты генерируют фишинговые письма в 11.4 раза быстрее при сопоставимом качестве (IBM X-Force 2025), а CrowdStrike фиксирует двукратный рост вредоносного использования GenAI для социальной инженерии в 2024 году. Грамматических ошибок в фишинге становится всё меньше — отличать по кривому русскому уже не получится.

Вложение. Типичные форматы: исполняемые файлы (.exe), архивы (.zip), PDF, HTML-файлы (.html, .htm, .shtm). Расширение .shtm — вариант HTML, который реже блокируется почтовыми фильтрами; атакующие это знают и активно используют. В песочнице вложение открывается кликом внутри изолированной ВМ — это безопасно.

Детонация вложения и дерево процессов

Детонация — контролируемый запуск подозрительного файла в изолированной среде. После открытия вложения ANY.RUN записывает все действия: создание процессов, файловые операции, изменения реестра Windows, сетевые соединения.

Ключевой инструмент — дерево процессов (process tree). Оно показывает, какой процесс запустил какой. Пример для HTML-фишинга:

• Почтовый клиент открывает .eml
• .eml содержит .shtm-вложение — открывается в браузере
• Браузер отображает фишинговую форму ввода пароля
• При вводе данных — POST-запрос на внешний сервер

В более сложных сценариях вложение содержит макрос (T1059.005 — Visual Basic). Тогда дерево процессов показывает запуск cmd.exe (T1059.003 — Windows Command Shell), powershell.exe (T1059.001 — PowerShell) или wscript.exe (T1059.005 — Visual Basic при запуске .vbs-скриптов; также классифицируется LOLBAS как LOLBin для T1564.004 — NTFS File Attributes). Если видите такое — вложение активно выполняет код на машине, и это уже не «подозрительное», а «вредоносное».

ANY.RUN помечает подозрительные процессы цветовыми маркерами и иконками репутации. Дерево процессов — первое, что стоит изучить после завершения анализа.

Восстановление цепочки заражения по сетевым индикаторам

Сетевая активность — главный источник IOC (Indicators of Compromise — индикаторы компрометации: IP-адреса, домены, хеши файлов, URL, по которым можно обнаружить атаку в инфраструктуре). Анализ сетевых индикаторов компрометации позволяет восстановить полную цепочку: куда обращался вредонос, что скачивал, кому отправлял данные.

DNS и HTTP: где искать следы C2-сервера

Вкладка «Network» в ANY.RUN показывает все сетевые соединения с репутационными метками: зелёная — известный безопасный ресурс, знак вопроса — неизвестный, метка угрозы — вредоносный. Эти инструменты анализа фишинговых атак экономят минуты при триаже.

Что ищем в анализе вредоносного трафика:

DNS-запросы к нетипичным доменам. Вредонос часто обращается к доменам в дешёвых TLD (доменных зонах верхнего уровня) — .top, .xyz, .buzz. По данным ANY.RUN TI Lookup, зона .top входит в число наиболее злоупотребляемых для вредоносной активности, включая DGA-домены (Domain Generation Algorithm — автоматическая генерация доменных имён, затрудняющая блокировку). Если видите DNS-запрос к чему-то вроде a8x3kd.top — это почти наверняка DGA.

HTTP-запросы с данными жертвы. POST-запрос, содержащий введённые логин и пароль (credential harvesting — сбор учётных данных), — прямое доказательство кражи. В одном задокументированном кейсе данные отправлялись через легитимный сервис сбора форм, что затрудняет детект по репутации домена. Домен чистый, а данные утекли — неприятный сюрприз.

Соединения на порту 443. Вредоносы маскируют связь с C2 под обычный HTTPS-трафик (T1071.001 — Web Protocols). Без расшифровки видна только пара IP-адресов.

MITM-прокси для расшифровки трафика

Если при первом запуске MITM не был включён и в логах видны подозрительные HTTPS-соединения — перезапускаем анализ с включённым MITM-прокси. Да, это лишние минуты. Но без расшифровки отчёт будет неполным.

После перезапуска в сетевых логах появляется содержимое запросов. Типичные находки при выявлении C2-сервера в песочнице:

• POST-запрос с телом email=victim@company.com&password=... — credential harvesting
• GET-запросы к внешнему серверу за дополнительным payload (T1105 — Ingress Tool Transfer)
• Ответы сервера с закодированными командами (T1140 — Deobfuscate/Decode Files or Information — расшифровка данных при получении)

Это и есть восстановление цепочки заражения malware: от клика по вложению через исполнение кода к сетевому взаимодействию с инфраструктурой атакующего. Каждый шаг — отдельный IOC из сетевого трафика.

Извлечение IOC и маппинг на MITRE ATT&CK

После завершения анализа ANY.RUN собирает все индикаторы компрометации на вкладке «IOC». Типичный набор из одного фишингового сэмпла:

JA3S-хеш стоит отдельного пояснения. Это отпечаток того, как TLS-сервер отвечает на подключение — у каждого C2-фреймворка отпечаток уникальный. По данным ANY.RUN TI Lookup, поиск по одному JA3S-хешу, ассоциированному с Cobalt Strike, возвращает сотни и тысячи связанных системных событий. Когда IP-адреса и домены уже сменились, JA3S-хеш — один из немногих способов найти тот же C2 в новой обёртке. Для threat hunting (проактивного поиска угроз) это незаменимо.

Вкладка «ATT&CK» автоматически маппит обнаруженное поведение на техники. Для фишингового сценария с вложением типичный набор:

• T1566.001 — Spearphishing Attachment (доставка)
• T1204.002 — Malicious File (жертва открыла файл)
• T1027 — Obfuscated Files or Information (обфускация вложения)
• T1071.001 — Web Protocols (связь с C2 по HTTP/HTTPS)
• T1105 — Ingress Tool Transfer (загрузка дополнительного payload)
• T1497.001 — System Checks (проверка на sandbox — вредонос пытается обнаружить виртуальную среду и прекратить работу)

AI Summary в ANY.RUN генерирует текстовое резюме анализа — полезно для быстрого ознакомления и оформления инцидент-репорта.

Экспорт результатов. ANY.RUN выгружает IOC в форматах STIX и MISP JSON (стандартные форматы обмена данными об угрозах), которые принимает большинство SIEM-систем (SIEM — Security Information and Event Management: Splunk, Elastic, QRadar — платформы для сбора и корреляции событий безопасности). Также доступна выгрузка PCAP (полный дамп сетевого трафика) для глубокого PCAP анализа фишинга в Wireshark.

ANY.RUN умеет генерировать AI Sigma Rules — готовые правила детектирования, которые можно скопировать в SIEM или EDR для обнаружения аналогичного поведения на других хостах.

После экспорта IOC полезно проверить, обращался ли ещё кто-то в инфраструктуре к обнаруженному C2-домену. Пример запроса в Splunk:

index=proxy OR index=dns
(query="подозрительный-домен.top" OR url="*подозрительный-домен.top*")
| stats count by src_ip, dest, _time
| sort -_time

Замените подозрительный-домен.top на реальный домен из вкладки IOC. Результат покажет внутренние IP-адреса (src_ip), обращавшиеся к этому домену. Если хостов больше одного — масштаб инцидента шире, чем одно письмо, и пора эскалировать.

Типичные ошибки при анализе фишинга в песочнице

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

Запуск на рабочем хосте. Самая опасная ошибка — открыть подозрительное вложение на своей машине «чтобы быстро глянуть». Даже при наличии EDR вы создаёте реальный инцидент вместо контролируемого анализа. Не надо так.

Анализ без MITM. Credential-stealing атаки отправляют данные по HTTPS. Без MITM-прокси вы увидите факт соединения, но не докажете кражу учётных данных — а это критично для инцидент-репорта и дальнейших действий (сброс паролей, уведомление пользователя).

Публичный анализ с внутренними данными. Бесплатный тариф ANY.RUN делает результаты анализа публичными. Если загружаемое письмо содержит внутренние данные компании — имена сотрудников, внутренние домены из заголовков — анализ увидят все. Для внутренних расследований нужен приватный режим (тарифы Hunter или Enterprise).

Остановка на вердикте. ANY.RUN выдаёт вердикт «malicious» или «no threats detected». Но вердикт — начало работы, а не её конец. Задача аналитика — извлечь IOC, восстановить цепочку, проверить масштаб по SIEM и оформить отчёт.

Игнорирование anti-sandbox техник. Некоторые вредоносы проверяют, не запущены ли они в виртуальной среде (T1497.001 — System Checks), и если обнаруживают sandbox — прекращают работу. Заголовки письма подозрительные, а вложение «ничего не делает»? Это повод для повторного анализа с другими параметрами ВМ, а не для закрытия тикета.

По моим наблюдениям за три года на L1-L2, порядка 80% фишинговых писем, попадающих в SOC, детектятся автоматикой ещё до создания тикета. Проблема — в оставшихся 20%, которые прошли фильтры. Аналитик, умеющий работать с песочницей, за 10 минут восстанавливает цепочку, вытаскивает IOC и блокирует C2 на файрволе. Тот, кто нажимает «forward to vendor», ждёт ответа сутки — а за это время инфостилер уже выгрузил куки из браузера жертвы.

Меня тревожит другое: порог входа в создание фишинговых атак падает быстрее, чем порог входа в их анализ. GenAI делает письма убедительнее. Фишинговые киты вроде Tycoon2FA и Rockstar2FA, описанные в отчётах Sekoia и Microsoft в 2023–2024 годах, автоматизируют обход двухфакторной аутентификации. А в командах SOC по-прежнему считают нормальным, что L1 не умеет работать с sandbox и отправляет всё наверх. Мой прогноз: через год-два навык sandbox-анализа фишинга станет обязательным для найма на L1 — как сейчас обязателен базовый SIEM.

Формула на бумаге понятна, но реальный навык формируется только на живых сэмплах: разбираешь десяток-другой фишинговых писем в ANY.RUN — и вдруг обнаруживаешь, что читаешь сетевые логи не вспоминая, какая вкладка за что отвечает. Если ищешь джуниор-роль в SOC — IB Basics закрывает базу за пару месяцев, а десяток разобранных сэмплов в песочнице дают что показать на собеседовании.