На проверке Утечка Sound Radix: как атакующие скомпрометировали платформу поддержки клиентов

Скомпрометированы оказались не внутренние серверы компании, а сторонняя платформа поддержки клиентов - имена, email-адреса и пароли попали в открытый доступ и были добавлены в базу Have I Been Pwned. По данным Verizon DBIR, доля утечек с участием третьих сторон растёт год к году. Sound Radix стал ещё одним подтверждением: атакующие всё чаще идут не через основной периметр, а через SaaS-звено в цепочке обработки данных. Ниже - разбор вектора атаки, маппинг TTPs на MITRE ATT&CK и конкретные правила детекции для SIEM.

Хронология и факты утечки Sound Radix​

Sound Radix - небольшая компания с линейкой плагинов для аудиопродакшена. Не банк, не телеком, не критическая инфраструктура. И именно поэтому кейс показательный: если supply chain атака на платформу поддержки затронула бизнес такого масштаба, она затронет кого угодно. Подробнее - в нашем материале про атаки на цепочку поставок.

Что известно из раскрытия:

• Дата уведомления: 25 марта 2026 года
• Объём утечки: 292 993 записи
• Скомпрометированные данные: email-адреса, имена, пароли
• Точка компрометации: сторонняя платформа customer support (disclosure размещён на support.soundradix.com)
• Формат раскрытия: self-disclosure - компания самостоятельно уведомила пользователей

Self-disclosure утечки данных - шаг, на который решаются немногие. Большинство предпочитают тихо «починить и забыть». Sound Radix поступил иначе: уведомление опубликовано на портале поддержки, данные переданы в Have I Been Pwned.

Инцидент вписывается в устойчивый тренд. В январе 2026 года европейская DIY-платформа ManoMano сообщила о компрометации через подрядчика поддержки - утечка затронула порядка 37,8 млн записей, включая переписку клиентов с агентами (по данным Solar Dozor). В июле 2025 года Allianz Life подтвердила утечку 1,1 млн записей через сторонний облачный сервис. Паттерн один и тот же: третьесторонний сервис становится слабым звеном, через которое утекают клиентские данные.

Вектор атаки на customer support: от компрометации агента до эксфильтрации​

Бизнес-логика атаки: зачем ломают платформы поддержки​

Платформа поддержки - не просто интерфейс для тикетов. Через неё проходят данные, которые атакующий не вытащит из публичных источников:

• PII клиентов: имена, email, телефоны, иногда адреса и платёжные данные
• Учётные данные: пароли и токены, которые клиенты вставляют в текст обращения по неосторожности (и это происходит постоянно)
• API-ключи и конфигурации: при обращениях в техподдержку продукта
• Внутренняя переписка агентов: с деталями инфраструктуры, именами серверов, ссылками на внутренние системы

Для атакующего это точка входа с минимальным шумом. Не нужно ломать файрвол - достаточно скомпрометировать один аккаунт агента. Тот же отчёт Unit 42 фиксирует: риск supply chain вышел за пределы уязвимого кода - атакующие эксплуатируют доверенные SaaS-интеграции и инструменты вендоров для обхода периметра.

Нюанс, который упускают многие SOC-команды: EDR на рабочих станциях здесь не поможет. Вся активность происходит внутри SaaS-платформы - вход через браузер, экспорт через API, скачивание через штатный интерфейс. С точки зрения endpoint-агента (CrowdStrike Falcon, SentinelOne, Elastic Defend) это легитимный HTTPS-трафик к доверенному домену. Без мониторинга на уровне самой платформы компрометация третьестороннего сервиса остаётся невидимой - скомпрометированный аккаунт агента выглядит точно как настоящий.

TTPs атакующих: маппинг на MITRE ATT&CK​

Конкретный вектор первоначального доступа в случае Sound Radix не раскрыт полностью, но на основе разбора аналогичных инцидентов с helpdesk-платформами цепочка восстанавливается:

Этап	Техника MITRE ATT&CK	ID	Применимость
Initial Access	Phishing	T1566	Фишинг на агента с поддельной страницей SSO платформы
Initial Access	Exploit Public-Facing Application	T1190	Эксплуатация уязвимости в веб-интерфейсе
Persistence	Valid Accounts	T1078	Долгосрочное использование скомпрометированных учётных данных агента
Credential Access	Unsecured Credentials	T1552	Извлечение токенов и API-ключей из текста тикетов
Collection	Customer Relationship Management Software	T1213.004	Массовый экспорт записей через API или интерфейс экспорта
Collection	Data from Local System	T1005	Сбор данных из вложений к тикетам
Exfiltration	Exfiltration Over C2 Channel	T1041	Вывод данных через стандартные HTTP(S)-каналы
Defense Evasion	Indicator Removal	T1070	Очистка аудит-логов в панели администратора

T1213.004 (Customer Relationship Management Software) описывает сбор данных именно из CRM и аналогичных систем. В контексте helpdesk это означает: штатный API экспорта тикетов - полноценный инструмент для эксфильтрации. Не exploit и не zero-day, а документированный endpoint, вызванный с валидным токеном. По документам - легитимный запрос. На практике - слив базы.

Главная проблема для реагирования: шаги от Persistence до Exfiltration выглядят как легитимная работа агента поддержки. Экспорт тикетов, массовый просмотр клиентских карточек, выгрузка отчётов - штатные операции. Без установленного baseline эти действия не генерируют алертов.

Detection аномалий в SaaS-платформах поддержки​

Конкретные правила корреляции. Предполагается, что логи платформы поддержки пересылаются в SIEM через webhook, API или syslog-коннектор. Примеры ниже - для Splunk SPL, но логика адаптируется под Elastic KQL или другой стек. Названия полей (action, src_ip, user) зависят от конкретной платформы - адаптируйте под формат ваших логов.

Сценарий: понедельник, 9:15 утра​

В Splunk прилетает алерт - один из агентов за последний час экспортировал через API втрое больше записей, чем весь отдел за предыдущую неделю. Нет заявки от руководства на массовую выгрузку, нет миграции данных в расписании. Потенциальная эксфильтрация через скомпрометированный аккаунт - нужно блокировать токен и начинать расследование.

Правило для обнаружения аномального объёма экспорта:

index=helpdesk_logs action="export" OR action="bulk_download"
| bin _time span=1h
| stats count as export_count by user, _time
| sort user, _time
| streamstats avg(export_count) as avg_exp stdev(export_count) as sd_exp by user window=168 current=false
| where export_count > (avg_exp + 3*sd_exp) AND export_count > 10

Параметр current=false в streamstats исключает текущий интервал из расчёта среднего и стандартного отклонения - это снимает проблему self-inclusion bias, когда аномальный всплеск сам попадает в baseline и завышает порог срабатывания. Окно window=168 покрывает неделю при часовом бине. Минимальный порог count > 10 отсекает шум от низкоактивных аккаунтов.

Правило для детекции создания OAuth-токенов из нетипичных источников:

index=helpdesk_logs (action="oauth_token_created" OR action="api_key_generated")
| iplocation src_ip
| where NOT cidrmatch("10.0.0.0/8", src_ip) AND NOT cidrmatch("172.16.0.0/12", src_ip)
| stats count by user, src_ip, Country, _time

Цель - зафиксировать создание API-токена с IP-адреса за пределами корпоративной сети или VPN. В штатном режиме токены генерируются из внутренней подсети. Токен из «чужой» геолокации - повод для немедленной блокировки и разбора.

Чеклист правил корреляции для SIEM​

Готовый чеклист для включения в playbook реагирования на инциденты с платформой поддержки:

1. Аномальный экспорт записей - объём выгрузки за час превышает 3σ от baseline пользователя. Использовать streamstats с current=false для исключения текущего интервала из расчёта
2. Геоаномалия входа - агент входит из страны или региона, не совпадающего с историей за последние 30 дней. IOC: новая страна + активность в нерабочее время
3. API-активность вне рабочих часов - вызовы API платформы в 22:00–06:00 по локальному времени (исключение: 24/7-поддержка с отдельным расписанием и whitelisted аккаунтами)
4. Массовый просмотр карточек - более 100 уникальных клиентских записей за сессию без создания ответов. Порог зависит от baseline отдела - калибруйте по 2–4 неделям
5. Создание OAuth/API-токенов - каждое создание нового токена генерирует алерт на ревью, без автоматического approve
6. Повышение привилегий - изменение роли agent → admin на платформе - алерт высокого приоритета
7. Удаление или модификация аудит-логов - попытки очистки audit trail в административной панели (T1070, Indicator Removal)

Этот чеклист реализует принцип NIST CSF v2.0 DE.AE-01: установление и поддержание baseline сетевых операций и ожидаемых потоков данных. Без baseline правила бесполезны - соберите 2–4 недели логов для калибровки порогов до продакшена.

Third-party risk management: lessons learned после утечки​

Утечка Sound Radix - не про «слабые пароли» и не про отсутствие антивируса. Это про разрыв между тем, кто хранит данные клиентов, и тем, кто контролирует платформу хранения. Хардинг самого SaaS - зона ответственности вендора. А вот конфигурация, доступы и мониторинг интеграции - целиком на клиенте.

Чеклист контролей для vendor assessment SaaS-платформы поддержки:

1. Инвентаризация типов данных - какие именно данные проходят через платформу: PII, пароли, API-ключи, внутренние документы. Каждый тип - отдельная категория риска (NIST CSF ID.AM-01)
2. Ревью OAuth-scope - какие разрешения выданы интеграции. Принцип минимальных привилегий: read:tickets не должен подразумевать export:all_customers (NIST CSF PR.AA-01)
3. Пересылка логов в SIEM - вендор обязан предоставлять audit log API с детализацией до действия и IP. Нет такого API - blocker для контракта
4. MFA для всех агентов - обязательная двухфакторная аутентификация, включая сервисные аккаунты с API-доступом
5. Ротация токенов - API-ключи и OAuth-токены: ротация каждые 90 дней. Неротируемые токены - потенциальный IOC в будущих инцидентах
6. SLA на уведомление об инциденте - в договоре: вендор обязан уведомить в течение 24 часов. Без этого пункта об утечке вы узнаёте из Have I Been Pwned
7. Тестирование конфигурации интеграции - ежегодная проверка ролевой модели, API-доступов и интеграционных точек

Регуляторный контекст: компрометация стороннего сервиса​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

За последние два года я разбирал инциденты с тремя разными helpdesk-платформами, и в каждом случае корневая причина была не в уязвимости самого SaaS-продукта, а в отсутствии мониторинга на стороне клиента. Логи не пересылались в SIEM, OAuth-токены не ротировались по два-три года, API-доступ выдавался без ограничений по IP. Sound Radix показала правильный подход к раскрытию - self-disclosure через портал поддержки с передачей информации в HIBP. Но раскрытие постфактум не заменяет detection в реальном времени.

Большинство организаций крупнее Sound Radix до сих пор не включают SaaS-платформы поддержки в scope vendor assessment - они болтаются в слепой зоне между «это не наш сервер» и «но это наши данные». Я вижу здесь системную проблему: риски сторонних сервисов оценивают при подписании контракта и больше к ним не возвращаются. Ни ежеквартального аудита конфигурации, ни пересмотра scope OAuth-токенов, ни проверки - а пересылаются ли вообще логи в SIEM после того, как интеграция заработала.

Пока SaaS-интеграции остаются без собственного detection-слоя, атакующие будут использовать их как путь наименьшего сопротивления. Если в вашем SIEM нет правил под аномалии SaaS-интеграций - на codeby.net есть тред, где коллеги делятся Sigma-правилами и подходами к мониторингу third-party сервисов.