Большинство APT-группировок ломают периметр через эксплойты, supply chain или вредоносные вложения. APT42 атакует людей — и это не фигура речи, а прямое описание. Эта группировка, работающая на разведку Корпуса стражей исламской революции (IRGC-IO), неделями выстраивает доверительные отношения с жертвой: переписывается в WhatsApp, шлёт легитимные PDF, приглашает на реальные конференции. И только потом - ссылка на фишинговую страницу, которая перехватывает MFA-токен в реальном времени. Ни одного вредоносного вложения. Ни одного детектируемого эксплойта. Украденная сессия и полный доступ к Microsoft 365.
Дальше разберу полный kill chain APT42 - от первого сообщения в Telegram до эксфильтрации документов из OneDrive - с маппингом на MITRE ATT&CK, примерами детектирования в SIEM и объяснением, почему ваш TOTP-код не спасёт от Charming Kitten.
Кто стоит за APT42 и почему их оружие - доверие, а не малварь
APT42 - группа кибершпионажа, которую Mandiant (Google Cloud) формально описала в сентябре 2022 года и атрибутировала с умеренной степенью уверенности к разведывательному управлению IRGC (IRGC-IO). Активны как минимум с 2015-го. В разных отчётах фигурируют под кучей имён: Charming Kitten, Mint Sandstorm (раньше Phosphorus), TA453, Yellow Garuda, ITG18, CALANQUE, Damselfly, UNC788. Зоопарк алиасов - отдельная головная боль для аналитиков.Тут важно не путать APT42 с APT35. Обе группы аффилированы с IRGC, но работают по разным мандатам. По данным Mandiant и Hedgehog Security, APT35 ведёт долгосрочные операции с малварью, нацеленные на организации - компании, госинфраструктуру. APT42 - другая история. Они атакуют конкретных людей: журналистов, освещающих Иран, исследователей из аналитических центров, сотрудников НКО, правозащитников, представителей иранской диаспоры, политических консультантов, бывших чиновников.
Выбор целей напрямую отражает разведывательные потребности IRGC-IO: мониторинг внешних угроз Исламской Республике и подавление внутреннего инакомыслия. Жертвы выбираются не по месту работы, а по тому, кто они, что знают и с кем общаются. Это принципиально ломает модель защиты - стандартный корпоративный SOC бесполезен, когда атака идёт на личный Gmail журналиста.
По данным CyberScoop и Mandiant, APT42 подделывали бренды The Washington Post, The Economist, The Jerusalem Post, а также аналитических центров - Aspen Institute, McCain Institute и Washington Institute. Сами эти организации не были скомпрометированы - их имена использовались как обёртка для фишинговых приманок.
Kill chain APT42: от первого письма до компрометации облака
Разведка и имперсонация: недели работы до первого клика
APT42 начинает каждую операцию с разведки цели - копают публикации, контакты, профессиональные интересы. По MITRE ATT&CK это Spearphishing Link в контексте рекогносцировки (T1598.003, Reconnaissance), а создание ложных персон маппится на Impersonation (T1656, Defense Evasion).Операторы создают фейковые аккаунты журналистов, организаторов конференций, коллег-исследователей. Выходят на контакт через email, WhatsApp или Telegram - каналы, которые жертва воспринимает как личные и доверенные. Первые сообщения не содержат ничего вредоносного. Приглашение дать комментарий для статьи. Предложение выступить на конференции. Просьба прочитать черновик исследования. Чистая социальная инженерия.
Вот как это выглядит на практике. По данным Mandiant, в одном из задокументированных случаев операторы APT42 представились иранским кинорежиссёром и одновременно контрибьютором Fox News, разместив легитимный документ о правах женщин на DropBox. В другом - использовали документ-приманку «The Secrets of Gaza Tunnels», эксплуатируя интерес к израильско-палестинскому конфликту. Документы не содержали малвари. Они нужны были для одного - выстроить доверие.
Именно этот паттерн - легитимный контент для построения rapport, а затем фишинговая ссылка - отличает APT42 от атак, которые привык детектировать среднестатистический SOC. Нет вредоносного вложения - нет сработки антивируса. Нет подозрительного URL в первом письме - нет блокировки почтового шлюза. Красота, если смотреть со стороны атакующего.
Spear phishing и credential harvesting: три кластера инфраструктуры
Когда доверие выстроено, APT42 переходит к сбору учётных данных. По отчёту Google Cloud, группа использует Spearphishing Link (T1566.002, Initial Access) через три отдельных кластера инфраструктуры:Кластер A маскируется под СМИ и аналитические центры. Тайпосквоттинговые домены в зонах
.top, .online, .site, .live, .press - домены с кучей слов через дефис (типа panel-live-check[.]online). Целевые страницы имитируют логин-формы Google, Microsoft, Yahoo.Кластер B маскируется под легитимные сервисы: Dropbox, Google Meet, LinkedIn, YouTube. Фишинговая инфраструктура размещается на Google Sites, OneDrive и Cloudflare Workers - трафик смешивается с легитимной активностью, и блокировка по домену не работает.
Кластер C заточен под целевой фишинг с генерацией MFA push-уведомлений.
По данным HawkEye, все кластеры используют фишинговые киты с перехватом MFA-токенов в реальном времени. Это тот самый элемент, из-за которого APT42 опасна для тех, кто считает MFA серебряной пулей.
Обход многофакторной аутентификации: почему TOTP бесполезен
Центральный элемент тактики APT42. По MITRE ATT&CK маппится на Multi-Factor Authentication Interception (T1111, Credential Access) и Multi-Factor Authentication Request Generation (T1621, Credential Access).APT42 применяет два метода обхода MFA, задокументированных Google Cloud:
Метод 1 - перехват MFA-токена через клонированный сайт. Жертва вводит логин, пароль и TOTP-код на фишинговой странице. Инфраструктура APT42 мгновенно пересылает данные на настоящий сервис (Google, Microsoft), устанавливая сессию до истечения срока действия токена. По данным Mandiant, метод иногда давал сбои - токен успевал протухнуть.
Метод 2 - генерация MFA push-уведомлений. После получения логина и пароля операторы инициируют вход на реальном сервисе, который шлёт push-уведомление на устройство жертвы. Жертва, ожидающая подтверждения от «легитимного» сервиса, одобряет запрос. По отчёту Google Cloud, этот метод «succeeded» - работал.
Технически это adversary-in-the-middle (AiTM). Если вы хоть раз разворачивали EvilGinx2 или Modlishka в лабе - механика идентична: reverse proxy стоит между жертвой и реальным сервисом, транслирует весь трафик и перехватывает сессионный cookie после успешной аутентификации. Разница в том, что APT42 не использует публичные фреймворки - их фишинговые киты кастомные и регулярно обновляются. Я считаю, что именно кастомность китов - причина, по которой их так тяжело детектить на уровне WAF.
Ключевой вывод: TOTP-коды (Google Authenticator, Microsoft Authenticator в режиме кода), SMS-коды и даже push-уведомления от этого вектора не защищают. Единственная категория MFA, устойчивая к AiTM - фишинг-резистентные методы: FIDO2-ключи безопасности (YubiKey) и passkeys. Они привязаны к origin домена и криптографически не позволяют передать секрет на фишинговую страницу.
Компрометация облачных учётных записей: действия после перехвата сессии
После получения доступа APT42 работает исключительно через встроенные функции облачных сервисов. По MITRE ATT&CK: Cloud Accounts (T1078.004, Defense Evasion / Persistence / Initial Access), Steal Web Session Cookie (T1539, Credential Access), Remote Email Collection (T1114.002, Collection).По данным HawkEye и Mandiant, задокументированное поведение после компрометации:
- Регистрация собственного аутентификатора MFA на аккаунте жертвы - для персистентного доступа
- Доступ к Microsoft 365: чтение переписки в Outlook, скачивание документов из OneDrive и SharePoint
- Эксфильтрация файлов на OneDrive-аккаунт, замаскированный под аккаунт организации жертвы
- VPN и анонимизирующая инфраструктура для взаимодействия со скомпрометированной средой
- Встроенные функции и open-source инструменты - никакой малвари внутри облачной среды
TAMECAT и NICECURL: бэкдоры для целей с высокой ценностью
Когда одних украденных учёток недостаточно - скажем, нужен персистентный доступ к локальной системе - APT42 разворачивает кастомные бэкдоры. По данным Mandiant и The Hacker News, группа использует два основных инструмента:TAMECAT - бэкдор на PowerShell, работающий преимущественно в памяти. Доставляется через spear phishing с вредоносными макро-документами. По данным HawkEye: использует PowerShell для выполнения произвольных команд и загрузки C#-контента, оценивает среду на наличие антивирусных продуктов и адаптирует метод развёртывания, шифрует коммуникации с C2-сервером (задокументированный ключ:
kNz0CXiP0wEQnhZXYbvraigXvRVYHk1B), минимизирует forensic-артефакты за счёт исполнения в памяти. В общем, старается не наследить.NICECURL (он же BASICSTAR) - бэкдор на VBScript. Доставляется через вредоносные LNK-файлы, маскирующиеся под формы обратной связи по интервью или документы-вложения. Умеет скачивать дополнительные модули через
curl.exe, выполнять произвольные команды через HTTPS и вытаскивать данные из скомпрометированной системы.По данным Volexity, NICECURL засветился в серии атак на экспертов по ближневосточной политике в сентябре-октябре 2023 года.
Важный контекст: эти бэкдоры - не основной инструмент APT42. Группа предпочитает credential harvesting без малвари. TAMECAT и NICECURL достают из арсенала только для высокоприоритетных целей, когда нужен глубокий персистентный доступ к локальной машине.
Детектирование APT42 в облачных логах и SIEM
Этого раздела нет ни в одной русскоязычной статье по APT42. Разберём конкретные индикаторы.
Что искать в Microsoft 365 Audit Log и Azure AD Sign-in Logs
На основе задокументированного поведения APT42 (HawkEye, Mandiant) - приоритетные события для мониторинга:
- Регистрация нового MFA-аутентификатора. Событие
Update userилиUser registered security infoв Azure AD Audit Log. Новый метод MFA регистрируется в течение часов после подозрительного входа - красный флаг. - Входы с анонимизирующей инфраструктуры. IP-диапазоны VPN-сервисов, Tor exit nodes, хостинг-провайдеры (не резидентные ISP). Фильтр в Azure AD:
Sign-in logs → Location → ISP contains "hosting". - Массовый доступ к файлам OneDrive/SharePoint. События
FileDownloadedиFileSyncDownloadedFullв Microsoft 365 Unified Audit Log. APT42 экспортирует документы пакетно - если кто-то за час стянул 200 файлов из SharePoint, это не нормальное поведение пользователя. - Создание правил пересылки почты. Событие
New-InboxRuleв Exchange Online. Классический приём для персистентного доступа к переписке.
Код:
let timeframe = 1h;
AuditLogs
| where OperationName == "User registered security info"
| join kind=inner (
SigninLogs
| where ResultType == 0
| where RiskLevelDuringSignIn in ("medium", "high")
| where TimeGenerated > ago(timeframe)
) on UserPrincipalName
| project TimeGenerated, UserPrincipalName, IPAddress, Location, OperationNameСетевые индикаторы: домены и паттерны
На основе IOC-листов (1275.ru, HawkEye):- Домены с тайпосквоттингом в зонах
.top,.online,.site,.live,.press - Паттерн именования: куча слов через дефис (
panel-live-check[.]online) - Легитимные платформы как хостинг: Google Sites, Cloudflare Workers, OneDrive
- C2-коммуникации через SOAP API по HTTP (характерно для GHAMBAR/BROKEYOLK)
- URL-паттерны
tempuri.orgв C2-трафике бэкдоров
hardship-management[.]com:4373, nvidia-update[.]com:5050, update-driversonline[.]bid, update-microsoft[.]bid.Что проходит мимо стандартных правил
Стандартные SIEM-правила APT42 не поймают, и вот почему:- Нет вредоносных вложений - нет сработки антивируса и sandbox
- Фишинговые ссылки на легитимных платформах (Google Sites) - веб-прокси пропускает
- Пост-компрометационная активность через легитимные облачные функции - endpoint ничего аномального не видит
- Вход с украденным session cookie может вообще не генерировать MFA-событие
Практические рекомендации: как закрыть вектор identity-based атак APT42
Отсортировано по impact - от наиболее эффективных к дополнительным.1. FIDO2/passkeys вместо TOTP и push-уведомлений. Единственная мера, полностью закрывающая вектор AiTM-фишинга. FIDO2-ключ криптографически привязан к origin домена - фишинговая страница на
google-login[.]site не получит ответ, предназначенный для accounts.google.com. Для высокорисковых сотрудников - обязательно. Google Advanced Protection Program и Microsoft Entra ID поддерживают enforcement FIDO2.2. Conditional Access Policies в Azure AD / Google Workspace. Ограничение входов по геолокации, типу устройства, compliance-статусу. Блокировка входов с анонимизирующих IP. Требование managed device для доступа к критичным данным.
3. Мониторинг регистрации новых MFA-методов. Автоматический алерт при добавлении нового аутентификатора - особенно если это происходит после входа из нового местоположения. Тот KQL-запрос выше - стартовая точка.
4. Awareness-тренинги, имитирующие тактику APT42. Не стандартные «не кликайте на подозрительные ссылки», а симуляции многоэтапной социальной инженерии: фейковое приглашение на конференцию, серия легитимных писем, потом ссылка на credential harvesting. Большинство сотрудников сломаются на третьем письме - и это нормально, для того и тренировки.
5. Token lifetime и session management. Сокращение времени жизни сессионных токенов, Continuous Access Evaluation (CAE) в Microsoft 365, привязка токенов к конкретному устройству.
6. Верификация контактов через независимые каналы. Если «журналист Washington Post» пишет вам в Telegram - проверьте его через редакцию. APT42 вкладывается в персоны, но не может контролировать телефон редакции.
| Мера защиты | Закрывает AiTM-фишинг | Закрывает push-бомбинг | Сложность внедрения |
|---|---|---|---|
| FIDO2/passkeys | Да | Да | Средняя |
| TOTP (Google Authenticator) | Нет | Нет | Низкая |
| SMS-коды | Нет | Нет | Низкая |
| Push MFA (Duo, MS Authenticator) | Нет | Частично (number matching) | Низкая |
| Conditional Access + managed device | Частично | Нет | Высокая |
Вопрос к читателям
APT42 перехватывает сессии через AiTM, и FIDO2 закрывает этот вектор на уровне аутентификации. Но есть нюанс: если атакующий уже утянул session cookie через T1539, Conditional Access Policy без привязки к device compliance не заблокирует доступ из его браузера.У кого из вас в Azure AD настроен Continuous Access Evaluation (CAE) с
strictEnforcementMode для Microsoft 365? Какие Conditional Access Policies вы применяете для блокировки replay украденных токенов - signInFrequency с привязкой к compliant device, tokenProtection в preview, или другая связка? Покажите конфигурацию, которая реально работает в проде - а не ту, что красиво смотрится в документации Microsoft.
Последнее редактирование модератором:
