Два крупных инцидента за полгода - Crunchyroll и Discord - и один вектор: Zendesk. Не zero-day в коде, не RCE, не что-то красивое. Обычная компрометация агентского аккаунта через аутсорсера.
В марте 2026 года Crunchyroll подтвердила утечку. По данным Have I Been Pwned - 1 195 684 email-адреса. Заявления атакующего о более широком наборе PII пока не подтверждены. Полугодом ранее тот же трюк сработал на Discord: группировка, идентифицированная в отчётах Rescana и BleepingComputer как Scattered Lapsus$ Hunters, предположительно удерживала доступ к Zendesk-инстансу около 58 часов. По заявлению атакующих - 1.6 ТБ данных, 8.4 миллиона тикетов, 5.5 миллионов затронутых пользователей. Цифры не подтверждены независимыми источниками; Discord признала инцидент, но оспорила масштаб.
Одна слепая зона мониторинга. Ниже - полный разбор kill chain утечки данных через Zendesk, конкретные detection-правила для SIEM и чеклист, который можно передать команде прямо сейчас.
Бизнес-логика атаки: зачем ломать систему поддержки
Zendesk - не "просто тикет-система". Это хранилище с прямым доступом к PII: имена, email, телефоны, платёжные данные, IP-адреса. В случае Discord - ещё и сканы паспортов и водительских удостоверений, загруженных для верификации возраста. Zendesk при этом интегрируется с Okta, Slack, внутренними API компании-клиента. По данным Rescana, интеграция с внутренними системами Discord позволяла делать миллионы API-запросов к внутренней базе через платформу поддержки. Zendesk работал как прокси к данным, которые сама Discord никогда не экспонировала наружу. Подробнее - в нашем руководстве по расследование кибератаки.Финансовая мотивация прямолинейна: по данным Rescana (требует независимой верификации), группа SLH предположительно потребовала от Discord $5 млн, позже снизив до $3.5 млн. Переговоры, по тем же данным, шли с 25 сентября по 2 октября 2025 года. Discord отказалась платить. Для атакующего helpdesk - одновременно точка сбора данных и рычаг давления: угроза публикации тикетов с паспортами создаёт давление, которого нет при обычной краже хешей паролей.
Регуляторный контекст: утечка сканов государственных удостоверений и платёжных данных попадает под GDPR (штраф до 4% глобального оборота), CCPA и 152-ФЗ. Для компании, чья служба поддержки обрабатывает документы пользователей, компрометация helpdesk - инцидент категории "критический" по любому стандарту классификации.
Kill chain взлома системы поддержки: от агента до эксфильтрации
Компрометация агентского аккаунта через BPO-провайдера
Ключевой момент обоих инцидентов: атака не эксплуатировала уязвимость в коде Zendesk. По данным BleepingComputer и Rescana, в случае Discord злоумышленники скомпрометировали учётную запись сотрудника аутсорсингового провайдера (BPO). Supply Chain Compromise (T1195) + Valid Accounts (T1078) - классика.Атакующие получили доступ к Zenbar - внутреннему инструменту Zendesk, через который агенты выполняют административные операции: поиск по пользователям, отключение MFA, просмотр телефонов и email. По данным Rescana, злоумышленники предоставили скриншоты доступа к панелям Kolide (device trust) и Okta (IAM) - это указывает на захват активной сессии или кражу учётных данных агента.
Параллельно, по данным вендорских отчётов threat intelligence (требует независимой верификации), финансово мотивированные группы используют аналогичную тактику: направляют сотрудников BPO на фишинговые страницы, имитирующие Okta и Zendesk, крадут содержимое буфера обмена для обхода MFA и регистрируют собственные устройства для persistent access. Домены следуют паттерну
<org>.zendesk-support<##>.com.Отдельная история - архитектурная уязвимость, описанная исследователями безопасности: при отсутствии SPF/DKIM/DMARC на почтовом домене компании-клиента Zendesk позволял получить доступ к тикетам через spoofed email. Zendesk закрыла дыру, но инцидент показал: вектор компрометации helpdesk шире, чем только фишинг на BPO.
Контекст для пентестера: если на проекте вы тестируете организацию с Zendesk и BPO-поддержкой - точка входа не в самом Zendesk, а в процессе аутентификации аутсорсера. Проверяйте: есть ли у BPO-агентов FIDO2/WebAuthn или только стандартный OTP, перехватываемый фишинг-китом.
Массовый сбор данных из тикетов (T1213)
После получения агентского доступа начинается Data from Information Repositories (T1213, Collection). В случае Discord атакующие собрали:- ~1.5 ТБ вложений к тикетам (сканы документов, скриншоты)
- ~100 ГБ расшифровок тикетов - порядка 8.4 млн записей
- Данные ~580 000 пользователей с платёжной информацией (тип оплаты, последние четыре цифры карты, история покупок)
- Порядка 70 000 изображений государственных удостоверений (по заявлению атакующих; Discord подтвердила значительно меньшее число, точная цифра не раскрыта)
/api/v2/tickets, /api/v2/search, /api/v2/ticket_audits. При наличии API-токена или OAuth-сессии агента нет архитектурного ограничения на объём выгрузки. Rate limits Zendesk (по документации - до 700 запросов/мин для Core API на Enterprise-плане, но Search API и Incremental Exports - всего 10 запросов/мин, при этом каждый запрос Incremental Export возвращает большой объём данных) рассчитаны на защиту от перегрузки, а не от авторизованной эксфильтрации.Вот в чём слепое пятно: разница между "агент видит один тикет" и "агент выгружает миллионы записей" на уровне API не контролируется по умолчанию.
Эксфильтрация через HTTPS (T1567)
Exfiltration Over Web Service (T1567): данные уходят через стандартный HTTPS - тот же канал, через который Zendesk API работает в штатном режиме. Для сетевого мониторинга это выглядит как легитимный трафик агента поддержки. По данным FireCompass, атакующие использовали автоматизированные скрипты с API-токенами из скомпрометированных аккаунтов.| Этап | Техника | MITRE ATT&CK | Описание в контексте инцидента |
|---|---|---|---|
| Initial Access | Supply Chain Compromise | T1195 | Компрометация BPO-провайдера |
| Initial Access / Persistence | Valid Accounts | T1078 | Использование легитимных кредов агента |
| Collection | Data from Information Repositories | T1213 | Массовая выгрузка тикетов и вложений |
| Exfiltration | Exfiltration Over Web Service | T1567 | Вывод данных через Zendesk API по HTTPS |
| Impact | Financial Theft | T1657 | Вымогательство с угрозой публикации |
Detection gap: почему dwell time превышает сутки
Dwell time в кейсе Discord - около 58 часов (по данным Rescana). Утечка данных Crunchyroll тоже обнаружена не мгновенно. Почему SOC не видит компрометацию helpdesk?
Zendesk Audit Trail не интегрирован в SIEM. Большинство организаций не отправляют логи Zendesk в Splunk, Elastic или MaxPatrol SIEM. Zendesk ведёт собственный Audit Log (Settings -> Account -> Audit Log), но он фиксирует только административные изменения, а не read-запросы к тикетам. Массовая выгрузка данных туда просто не попадает. Для детекции bulk read нужен Access Log (Enterprise) или сетевой мониторинг. Если ваш SOC не получает и эти события - вы слепы к этому вектору.
Нет baseline API-активности. Типичная нагрузка агента зависит от компании - baseline строится индивидуально. Когда аккаунт начинает делать тысячи API-запросов в час - это аномалия. Но без baseline у SOC нет порога для алерта. При допустимых сотнях запросов в минуту через один аккаунт можно выгрузить миллионы тикетов за двое суток - именно это и произошло в кейсе Discord.
Легитимный user-agent и канал. Запросы через Zendesk API с валидным токеном идут с предсказуемым user-agent по HTTPS. Для proxy или WAF это нормальная работа. Аномалию можно поймать только по объёму, геолокации или паттерну - а для этого нужна корреляция, которой нет.
BPO = неконтролируемый endpoint. Аутсорсинговый сотрудник работает со своего устройства, возможно из другой страны. Device trust (Kolide) и IAM (Okta) должны были остановить атаку - но в кейсе Discord атакующие получили доступ и к этим панелям. Либо полный захват сессии, либо компрометация устройства.
Обнаружение вторжения в SIEM: правила корреляции для Zendesk
Практические detection-правила, закрывающие описанные слепые зоны. Примеры для Splunk SPL - адаптируйте под ваш стек (Elastic KQL, MaxPatrol SIEM, KUMA, RuSIEM).Детекция аномального объёма API-запросов. Требуется предварительная интеграция Zendesk Audit Log в SIEM через API polling эндпоинта
/api/v2/audit_logs или webhook:
Код:
index=zendesk sourcetype=zendesk:audit source_type="ticket" action IN ("exported","update","destroy")
| bucket _time span=1h
| stats count as api_calls by actor_id, src_ip, _time
| where api_calls > 500
| eval severity=if(api_calls>5000,"critical","high")zendesk.audit.action с агрегацией по user.id и source.ip.Детекция геолокационных аномалий. Второй критичный сигнал - логин агента из нетипичной геолокации. В терминах D3FEND - User Geolocation Logon Pattern Analysis (D3-UGLPA). По данным Google Threat Intelligence Group, UNC6783 использовал анонимизирующие сервисы, создавая характерный паттерн смены геолокации:
Код:
index=zendesk sourcetype=zendesk:audit event_type="login"
| iplocation src_ip
| stats dc(Country) as country_count values(Country) as countries by actor_id
| where country_count > 1Детекция нетипичных административных действий. Мониторинг операций, которые обычный агент не делает: отключение MFA, массовый поиск по пользователям, доступ к эндпоинтам bulk export. В кейсе Discord атакующие через Zenbar отключали MFA и искали пользователей по телефонам. Корреляционное правило: если один аккаунт за короткий период выполняет и массовый экспорт тикетов, и административные действия - severity critical, немедленная блокировка сессии.
Детекция аномального upload/download ratio. D3FEND Per Host Download-Upload Ratio Analysis (D3-PHDURA). Агент, который загружает гигабайты вложений, но не отдаёт ничего в ответ - паттерн эксфильтрации. Мониторьте объём исходящего трафика на хосты Zendesk CDN (
*.zendesk.com) в привязке к конкретному пользователю.Привязка к Sigma: для T1078 (Valid Accounts) в SigmaHQ - 114 правил, включая
azure_ad_auth_sucess_increase.yml для детекции аномального роста успешных аутентификаций. Адаптируйте логику под Zendesk SSO через ваш IdP (Okta, Azure AD, Keycloak). Для T1213 (Data from Information Repositories) - 12 правил, включая opencanary_git_clone_request.yml. Но правила T1213 в SigmaHQ ориентированы на honeypot-события (OpenCanary) и GitHub audit. Для Zendesk придётся писать собственное detection-правило на основе объёмных метрик API.Hardening-чеклист: реагирование на инциденты ИБ с SaaS-платформами
Нумерованный список - можно передать инженеру или включить в отчёт по аудиту.Два инцидента за полгода показали одну архитектурную проблему: Zendesk воспринимается как "просто тикет-система", а не как критический узел с доступом к PII миллионов пользователей. SOC-команды вкладывают тысячи человеко-часов в мониторинг endpoint'ов и сетевого периметра, а SaaS-платформы третьих сторон остаются в мёртвой зоне.
По опыту расследований подобных инцидентов: проблема не в том, что Zendesk плохо защищён. Проблема в том, что организации не мониторят его вообще. Audit Log существует, API для его сбора существует - но логи Zendesk в SIEM попадают редко. Проверьте прямо сейчас: ваш SOC получает события из Zendesk? Если нет - у вас та же дыра, что была у Discord и Crunchyroll. Если у вас другой стек детекции - на codeby.net коллеги обсуждают адаптацию detection-правил под конкретные SaaS-платформы, включая Zendesk и Freshdesk.
Последнее редактирование модератором:
