В апреле 2026 года ShinyHunters выложили на своём leak-сайте дамп Amtrak - национального железнодорожного оператора США. По данным Have I Been Pwned, утечка затронула 2 147 679 записей: email-адреса, имена, физические адреса и тикеты техподдержки. Сами хакеры заявляли о 9,4 млн записей - классический приём давления на жертву, завышение объёма раза в четыре.
Но Amtrak тут - лишь одна строчка в длинном списке. С середины 2025 года ShinyHunters методично проходятся по клиентам Salesforce. По данным отчёта Confidence Staveley, кампания затронула около 91 компании: Google, Workday, Allianz Life, Qantas, Chanel. И вот что интересно - ни в одном из этих случаев атакующие не эксплуатировали уязвимости в самой платформе Salesforce. Они эксплуатировали людей.
Дальше - реконструкция kill chain атаки на Amtrak, маппинг на MITRE ATT&CK и конкретные шаги для обнаружения подобного в вашем Salesforce-окружении. Без «лучших практик» - только то, что реально сработает (или должно было сработать у Amtrak).
ShinyHunters хакеры атаки: кто стоит за кампанией
ShinyHunters на сцене с 2020 года. За это время группировка прошла путь от массовой кражи данных с перепродажей на форумах до целенаправленного вымогательства у крупняка. Google Threat Intelligence Group (GTIG) отслеживает их под кластерами UNC6040 (вишинг и эксфильтрация) и UNC6240 (вымогательство).С атрибуцией всё ещё веселее: ShinyHunters и Scattered Spider (UNC3944) работают в связке. По данным Obsidian Security, исследователи зафиксировали пересечение IOC и тактик двух групп при атаках на Salesforce-окружения. Автор Databreaches.net Dissent Doe, имеющая верифицированный канал с лидером ShinyHunters, получила прямое подтверждение. В одной из переписок лидер заявил: «They've been working with us. Despite everyone's efforts to halt the Salesforce-related attacks, we continue to attack multi-billion- to multi-hundred-billion-dollar companies daily».
Для тех, кто строит detection rules, это означает одно: разделять TTPs Scattered Spider и ShinyHunters - ошибка. Вишинг, SIM-свопинг, злоупотребление OAuth - одна операционная модель, один зоопарк техник.
Salesforce breach утечка: анатомия атаки от звонка до дампа
Разберём по шагам, как атака выглядит изнутри - от первого звонка до момента, когда CRM-данные уже у атакующего. Реконструкция основана на технических описаниях Varonis, Obsidian Security и advisory ФБР от 12 сентября 2025 года.Фаза 1: разведка и подготовка
Перед звонком атакующие делают домашнюю работу. По данным Varonis, UNC6040 использует комбинацию живых звонков и автоматизированных телефонных систем с предзаписанными меню. Эти системы помогают собрать разведданные: названия внутренних приложений, контакты IT-поддержки, текущие проблемы в компании. Всё это - убедительный контекст для следующей фазы.В случае Amtrak атакующие, вероятнее всего, таргетировали англоязычный персонал. Кампания ShinyHunters последовательно фокусируется на англоязычных подразделениях мультинациональных корпораций, как отмечает SalesforceBen.
Фаза 2: вишинг и установка вредоносного Data Loader
Атакующий звонит сотруднику, представляясь IT-поддержкой. Используя собранные на разведке данные - имя реального сотрудника саппорта, номер тикета, название внутреннего приложения - оператор выстраивает доверие. Звучит примитивно, но когда звонящий знает номер твоего последнего тикета и имя твоего тимлида, скептицизм тает быстро.Дальше жертву просят установить «обновлённую версию» Salesforce Data Loader - легитимного инструмента для массового импорта и экспорта данных. Модифицированная версия маскируется под другим именем. Varonis фиксировал случаи с названием «My Ticket Portal».
Ключевой момент: атакующий на своей стороне инициирует OAuth Device Flow через собственный экземпляр Data Loader. Это генерирует короткий
user_code устройства.Фаза 3: злоупотребление OAuth Device Code Flow
Жертву направляют на легитимную страницу авторизации Salesforce (например,login.salesforce.com/setup/connect). Просят ввести connection code или напрямую авторизовать Connected App - модифицированную версию Data Loader, зарегистрированную атакующим (по описанию GTIG, июнь 2025). С точки зрения жертвы - стандартная процедура подключения приложения. С точки зрения атакующего - жертва только что авторизовала вредоносный Connected App.После ввода кода и подтверждения доступа Salesforce выпускает access token на экземпляр Data Loader атакующего. Токен позволяет действовать от имени жертвы, обходя MFA - потому что аутентификация уже завершена легитимным пользователем. MFA прошла. Галочка стоит. Токен ушёл не туда.
Фаза 4: эксфильтрация CRM-данных
Получив OAuth-токен, атакующий через Salesforce API выполняет массовые SOQL-запросы к объектам CRM: Contact, Account, Case, Lead. В случае Amtrak были выгружены email-адреса, имена, физические адреса и тикеты техподдержки - 2,1 млн записей по данным HIBP.Экспорт через Data Loader API выглядит как легитимная операция - это штатный инструмент, который администраторы используют каждый день. Именно поэтому инцидент часто остаётся незамеченным до момента получения вымогательского письма. Лично я считаю это самым элегантным элементом всей цепочки - атакующий использует ваш же инструмент, ваш же API, и всё это выглядит как обычный рабочий день.
Фаза 5: extortion кибервымогательство
По данным Obsidian Security, вымогательство иногда происходит спустя месяцы после компрометации. ShinyHunters публикует требования на leak-сайте с дедлайном и угрозой публикации данных. В случае Amtrak группировка заявила об объёме в 9,4 млн записей, угрожая массовой публикацией.Incident response разбор атаки: маппинг TTPs на MITRE ATT&CK
Каждая фаза атаки маппится на конкретные техники MITRE ATT&CK. Таблица ниже - основа для построения detection rules, а не абстрактное упражнение в классификации.| Фаза атаки | Техника ATT&CK | Тактика | Что искать в логах |
|---|---|---|---|
| Вишинг, получение доступа через сотрудника | Cloud Accounts (T1078.004) | Initial Access, Persistence | Новый Connected App, логин из нетипичной геолокации |
| Авторизация вредоносного Connected App | Steal Application Access Token (T1528) | Credential Access | OAuthToken grant событие с неизвестным AppId |
| SOQL-запросы к CRM-объектам | Customer Relationship Management Software (T1213.004) | Collection | Bulk API export, массовые query к Contact/Case |
| Выгрузка данных через API | Data from Cloud Storage (T1530) | Collection | ApiTotalUsage всплеск, аномальный объём download |
| Промежуточное хранение | Remote Data Staging (T1074.002) | Collection | Экспорт в нестандартные S3-бакеты |
| Вывод данных | Exfiltration to Cloud Storage (T1567.002) | Exfiltration | Исходящий трафик на неизвестные облачные хранилища |
Обратите внимание: в этой цепочке нет Exploit Public-Facing Application (T1190). Атакующие не ломают Salesforce - они злоупотребляют штатными механизмами через скомпрометированную сессию. Salesforce в advisory от 7 августа 2025 года подчеркнула: инциденты «not due to any known vulnerability in our technology». На заборе, конечно, тоже много чего написано - но тут они правы: уязвимость не в коде, а в архитектуре OAuth Device Flow и в людях.
Data breach timeline: хронология в контексте кампании
Атака на Amtrak - одно звено в длинной цепи. Timeline показывает масштаб и скорость эскалации.| Дата | Событие |
|---|---|
| Октябрь 2024 | Начало активности UNC6040 по данным ФБР (FLASH alert IC3) |
| Май 2025 | Компрометация Adidas через «стороннего CRM-провайдера» |
| Июнь 2025 | SalesforceBen публикует первое расследование кампании |
| 30 июня 2025 | Qantas обнаруживает аномальную активность в Salesforce-среде |
| 16 июля 2025 | Утечка Allianz Life - 1 115 061 запись (HIBP) |
| 6-7 августа 2025 | Утечки Chanel, Pandora; Salesforce публикует advisory |
| 11 августа 2025 | Google подтверждён как жертва кампании |
| 19 августа 2025 | Salesforce ужесточает политику Connected Apps |
| 26 августа 2025 | Farmers Insurance: 1,1 млн пострадавших клиентов |
| 27 августа 2025 | Обнаружена атака через Salesloft Drift - новый вектор |
| 12 сентября 2025 | ФБР выпускает FLASH alert о вишинг-кампаниях на Salesforce-окружения; Mandiant связывает TTPs с кластерами UNC6040 (вишинг) и UNC6395 (Salesloft Drift OAuth token theft) - связь UNC6395 с ShinyHunters не подтверждена GTIG |
| Октябрь 2025 | ShinyHunters заявляют о краже почти 1 млрд записей Salesforce |
| 10 октября 2025 | ФБР изымает домен BreachForums |
| 7 января 2026 | Panera Bread - 5 112 502 записи через Microsoft Entra SSO (отдельный инцидент, не через Salesforce OAuth Device Flow) |
| 6 марта 2026 | Aura - 903 080 записей (по данным leak-сайта ShinyHunters, независимо не верифицировано) |
| 31 марта 2026 | ShinyHunters заявляют о компрометации Cisco (Salesforce + AWS) (по данным leak-сайта, независимо не верифицировано) |
| 3 апреля 2026 | ShinyHunters публикуют заявление о взломе Amtrak - 2 147 679 записей |
Между первым известным инцидентом (май 2025) и атакой на Amtrak (апрель 2026) - почти год непрерывной кампании. Десятки организаций скомпрометированы, арсенал расширяется: от чистого вишинга до компрометации сторонних интеграций. Параллельно кластер UNC6395 эксплуатировал Salesloft Drift OAuth token theft, хотя его прямая связь с ShinyHunters/UNC6040 официально не подтверждена GTIG (сообщается о пересечении инфраструктуры и IOC).
Утечка данных клиентов: что именно украли у Amtrak
По данным HIBP, утечка Amtrak включает четыре класса данных:Email-адреса - основа для целевого фишинга и credential stuffing (T1110.004). Учитывая существующие combo-листы вроде Exploit.In (593 млн пар email/пароль), эти адреса немедленно попадают в ротацию автоматических перебиралок.
Имена - в связке с email повышают эффективность spear-phishing.
Физические адреса - для Amtrak это особенно болезненно: привязка к маршрутам и станциям создаёт контекст для убедительных фишинговых сценариев. «Ваш билет на маршрут Washington–New York отменён, подтвердите возврат» - и жертва кликает, потому что она действительно ездит этим маршрутом.
Тикеты техподдержки - самый опасный класс. Содержат детали обращений, имена агентов, внутреннюю терминологию. Это готовая база для следующей волны вишинга - уже против клиентов или партнёров Amtrak. Круг замыкается.
Salesforce security уязвимости: что искать в Event Monitoring
Если ваша организация использует Salesforce и Salesforce Event Monitoring (Shield), ниже - конкретные артефакты, указывающие на описанную цепочку атак. Не «лучшие практики», а то, что должно было сработать в случае Amtrak - но, вероятнее всего, не было настроено.Connected App OAuth Events
Первый сигнал - появление нового Connected App. Тип событияConnectedAppEvent фиксирует создание и авторизацию приложений. Ищите события с ACTION = 'authorize' для приложений, которых нет в вашем whitelist.
Код:
SELECT EventDate, Username, ConnectedAppId, Action, SourceIp
FROM ConnectedAppEventLog
WHERE Action = 'authorize'
AND CreatedDate = LAST_N_DAYS:7
ORDER BY EventDate DESCAPI Usage Anomalies
После получения токена атакующий гонит массовые API-запросы. Salesforce логирует это вApiTotalUsage. Нормальный паттерн Data Loader - предсказуемые объёмы в рабочее время. Аномалия - взрывной рост API-вызовов с конкретного Connected App, особенно к объектам Contact, Case, Account.Login Events
LoginEvent фиксирует параметры аутентификации. В контексте этой атаки смотрите на поле LoginType со значениями, содержащими OAuth (точное значение для Device Code Flow не задокументировано в Salesforce Object Reference - верифицируйте в вашей org). Дополнительно проверяйте ConnectedAppEventLog по Action = 'authorize' как более надёжный индикатор Device Flow.
Код:
SELECT EventDate, Username, SourceIp, LoginType, AuthMethodReference
FROM LoginEvent
WHERE LoginType LIKE '%OAuth%'
AND CreatedDate = LAST_N_DAYS:30
-- NB: точное значение LoginType для Device Code Flow не задокументировано;
-- верифицируйте в вашей org через: SELECT LoginType FROM LoginEvent GROUP BY LoginTypeSupply chain attack CRM: чеклист hardening для Salesforce
Конфигурационные действия, которые снижают вероятность успеха описанной атаки. Приоритет - от критичных к дополнительным.Критические меры
1. Аудит Connected Apps. Setup → Connected Apps OAuth Usage. Выгрузите полный список. Для каждого: проверьте AppId, дату создания, кто авторизовал, текущий статус. Неизвестные - блокировать немедленно. SalesforceBen рекомендует использовать Manage App Policies для настройки Permitted Users и принудительного high assurance session.2. Запрет самостоятельной установки Connected Apps. Уберите возможность для рядовых пользователей добавлять Connected Apps без одобрения администратора. Одна настройка - и вся атака разваливается: даже если сотрудник введёт код, приложение не авторизуется без approval flow.
3. Ограничение OAuth-scope. Для каждого легитимного Connected App - минимальный OAuth-scope. Приложению для синхронизации контактов не нужен
full scope. Задайте api, refresh_token и только необходимые объекты. Принцип наименьших привилегий - он и для OAuth работает.4. Enable API Access Control. Salesforce позволяет ограничить API-доступ whitelist-ом Connected Apps. Включаете - и только явно разрешённые приложения могут выполнять API-вызовы. Всё остальное молча отваливается.
Рекомендуемые меры
5. Session Policy для MFA step-up. Session Security Level = High Assurance для всех операций с Bulk API. Это потребует повторной MFA-верификации при попытке массового экспорта, даже при наличии валидного OAuth-токена.6. IP-restriction для Connected Apps. Привяжите каждый Connected App к диапазону IP-адресов, с которых он должен работать. Токен, полученный атакующим, окажется бесполезным с чужого IP.
7. Мониторинг Bulk API export. Алерт в SIEM на всплески Bulk API export (свыше N записей за операцию). Пороговое значение зависит от нормального паттерна вашей организации - универсальной цифры нет, считайте свой baseline.
8. Программа awareness по вишингу. Стандартные тренинги по фишингу не покрывают голосовой вектор. По данным Mandiant (GTIG), нормализация удалённого IT-саппорта и аутсорсинга сделала сотрудников более восприимчивыми к звонкам от «незнакомого IT». Простая процедура: сотрудник перезванивает в IT через официальный номер, а не продолжает входящий разговор. Звучит банально - но именно это ломает kill chain на самом раннем этапе.
Lessons learned кибератака: почему стандартные защиты не работают
Кампания ShinyHunters вскрыла системную проблему: классическая модель «закрыть уязвимости, поставить MFA, развернуть EDR» бесполезна, когда атакующий не ломает ничего технического.MFA не помогает. OAuth Device Code Flow спроектирован так, что пользователь аутентифицируется на легитимном сайте Salesforce. MFA проходит успешно - потому что её проходит легитимный пользователь. Токен после этого уходит атакующему. Это не обход MFA в техническом смысле - это злоупотребление архитектурой OAuth. MFA сделала своё дело и ушла довольная. А данные ушли в другую сторону.
EDR не видит угрозу. На рабочей станции жертвы нет малвари. Data Loader - легитимный инструмент. Все действия через штатный веб-интерфейс Salesforce. Endpoint-уровень не генерирует ни одного алерта. Тишина.
SIEM без правильных источников слеп. Если в SIEM не заведены Salesforce Event Monitoring логи - вы не увидите ни авторизацию Connected App, ни аномальный API-usage, ни подозрительный LoginType. Многие организации подключают к SIEM сетевые логи, EDR, но игнорируют SaaS-телеметрию. «Salesforce же защищён» - знакомая логика? У Amtrak, Chanel и Google она тоже была знакомой.
По данным SalesforceBen, «many companies do not name Salesforce directly when they reveal the incidents, instead opting for phrasing like "third-party CRM"». Реальный масштаб кампании больше, чем публично известно. Если ваша организация использует Salesforce и вы до сих пор не проверили Connected Apps - вопрос не «если», а «когда» вы узнаете о проблеме из вымогательского письма.
Вопрос к читателям
У кого из вас Salesforce Event Monitoring подключён к SIEM? Конкретный вопрос: какойEventType из Shield Event Monitoring вы используете для детекта OAuth Device Flow - LoginEvent с фильтром по LoginType LIKE '%OAuth%' (точное значение для Device Flow требует верификации в вашей org), или ConnectedAppEventLog по Action = 'authorize', или оба? И какой SIEM correlation rule срабатывает при появлении нового Connected App не из whitelist - поделитесь структурой правила (источник, условие, severity). Лично мне интересно, сколько из вас вообще видят Connected App events в своём SIEM - подозреваю, что ответ будет неутешительным.
