Апрель 2026 года. McGraw Hill подтверждает утечку 13,5 млн записей - имена, email, телефоны, физические адреса. Тремя днями ранее ShinyHunters заявляют о взломе Amtrak - 2,1 млн записей с адресами и тикетами поддержки. По данным Have I Been Pwned, оба инцидента зафиксированы в первой декаде апреля. В тот же период Salesforce публикует advisory об активной кампании: атакующие массово сканируют Experience Cloud и вытягивают данные через Guest User - без единого логина.
Контакты, адреса, тикеты поддержки - классический набор объектов любой CRM. Если ваша организация хранит подобное в Salesforce, вопрос не в том, станете ли вы целью, а в том, обнаружите ли мисконфигурации Salesforce раньше атакующих.
Тут нет zero-day. Нет сложной эксплуатации. Ошибки конфигурации существуют годами, и теперь их эксплуатируют в промышленных масштабах. Дальше - конкретная цепочка атаки, пошаговая инструкция аудита вашего Salesforce-окружения и чек-лист hardening-мер, закрывающих основные векторы утечки данных Salesforce.
Почему мисконфигурации Salesforce - критическая проблема для защиты CRM в облаке
Salesforce - не просто CRM, а платформа, на которой компании строят клиентские порталы, партнёрские кабинеты и базы знаний через Experience Cloud (бывший Community Cloud). Каждый такой сайт - публичная точка входа, проиндексированная Google, через которую внешние пользователи взаимодействуют с данными Salesforce-инстанса.Вся соль в модели разделённой ответственности: Salesforce отвечает за безопасность платформы, а за конфигурацию - вы сами. И тут возникает разрыв между документацией и тем, что реально творится в продакшне.
По данным Obsidian Security, в 2026 году группа атакующих запустила массовое сканирование публичных Experience Cloud сайтов модифицированной версией AuraInspector. Оригинальный инструмент (Google Mandiant) только находит уязвимые API-эндпоинты. Кастомная версия идёт дальше - вытягивает данные через GraphQL-интерфейс Salesforce, обходя ограничение в ~2000 записей, характерное для предыдущих техник.
Собранные данные - имена, телефоны, email, контактные записи - не самоцель. Согласно Obsidian Security, они становятся топливом для vishing-кампаний (голосовой фишинг): атакующие звонят жертвам, представляются IT-службой или руководством и используют украденные детали для убедительности при выманивании учёток и MFA-кодов.
Одна мисконфигурация Guest User Salesforce, открывающая список контактов, может стать первым звеном в цепочке до полноценного взлома SaaS-инфраструктуры.
Как атакующие эксплуатируют Salesforce Experience Cloud
Guest User: анонимный доступ, который существует всегда
Каждый сайт Experience Cloud имеет Guest User - специальный профиль для неаутентифицированных посетителей. Момент, который упускают администраторы: по исследованию Reco.ai, Guest User существует даже если в настройках сайта отключена опция «Guest users can see and interact with the site without logging in». Этот пользователь всё равно может взаимодействовать с сайтом через фреймворк Aura - JSON-протокол, лежащий в основе Lightning-компонентов.На заборе написано «доступ отключён», а Guest User спокойно дёргает API.
Настройка безопасности Salesforce в части Guest User сводится к тому, какие объекты и поля ему доступны через Sharing Rules. Предполагается, что администратор откроет только публичные данные - статьи базы знаний, каталог продуктов. На практике в аудитах я регулярно вижу другое:
- Sharing Rules без ограничений - дают Guest User доступ ко всем записям объекта, а не к конкретным
- Отсутствие Field-Level Security - даже при оправданном доступе к объекту чувствительные поля Phone, Email, Address остаются открытыми
- API Enabled на Guest User Profile - именно это разрешение позволяет программатически вытягивать данные через Aura и GraphQL
- Включённое Access Activities - Tasks и Events часто содержат внутренние заметки. По данным Reco.ai, это разрешение было включено по умолчанию, пока исследователи не показали Salesforce масштаб проблемы. Дефолт изменили, но на куче старых сайтов оно до сих пор активно
Aura-эндпоинты и GraphQL: техника Salesforce data exposure
Фронтенд Experience Cloud использует HTTP-эндпоинт/s/sfsites/aura для всех взаимодействий с сервером. Каждый запрос - POST с JSON-структурой, описывающей вызываемый метод (descriptor) и параметры. Токен со значением undefined - Guest User, анонимный вызов.По техническому анализу Varonis, атакующий использует последовательность дескрипторов для разведки и извлечения:
getConfigData- возвращает домен организации, CSP-настройки и перечень доступных объектовgetObjectInfo- показывает поля конкретного объекта, их конфигурацию и дочерние связиgetItems- перечисляет записи объекта (Account, Contact, Case)getRecord/getRecordWithFields- вытаскивает конкретные записи с расширенными полями и связанными объектами
JSON:
{
"actions": [{
"id": "1;a",
"descriptor": "aura://RecordUiController/ACTION$getObjectInfo",
"callingDescriptor": "UNKNOWN",
"params": {"objectApiName": "Account"}
}]
}/l/{encoded_json}. Сканируя их, атакующий узнаёт о кастомных Apex-методах и способах вызова.Отдельная головная боль - Apex-методы с директивой
without sharing. Согласно Reco.ai, они полностью игнорируют Sharing Rules, позволяя обойти ограничения доступа даже при корректной конфигурации правил. Исследователи Reco находили подобные мисконфигурации в компаниях из Fortune 500.GraphQL-эндпоинт доступен Guest User так же, как Aura, но позволяет извлекать данные без ограничения в 2000 записей. Именно GraphQL-вектор используется в активной кампании 2026 года.
Инструментарий атакующих: от sret до AuraInspector
Мисконфигурации Salesforce эксплуатируются не первый год. Хронология публичных инструментов (по данным Reco.ai):- 2021 - исследователь Nitay Bachrach (ныне в Reco) публикует первое описание техники извлечения данных через GraphQL-эндпоинт Salesforce
- 2022 - появление инструментов sret и cirrusgo в открытом доступе, эксплуатирующих те же мисконфигурации через различные API-методы
- 2025–2026 - команда Google Mandiant выпускает AuraInspector - первый публичный инструмент, использующий GraphQL для массового извлечения данных из мисконфигурированных Experience Cloud сайтов
Лично я смотрю на это так: AuraInspector - симптом, а не болезнь. Как подчёркивает Reco.ai, проблема в том, что организации годами эксплуатируют неправильно настроенные Salesforce-сайты. Инструмент лишь делает обнаружение и эксплуатацию тривиально простыми.
Для первичной разведки хватает Google dorks. Сайты Experience Cloud имеют характерные URL-паттерны -
/s/topic, /s/article, /s/contactsupport. Оператор inurl: в сочетании с названием целевой организации часто выдаёт публичные Experience-сайты прямо из поисковой выдачи. Никакой магии.Salesforce security audit: пошаговая инструкция
Требования к окружению
Salesforce hardening checklist: закрываем мисконфигурации
Отключение API-доступа и критичных разрешений Guest User
Самое результативное единичное действие. API Enabled на Guest User Profile - то, что превращает ошибку конфигурации в эксплуатируемый вектор атаки. Путь: Setup → Profiles → Guest User Profile → System Permissions → снимаем флаг API Enabled.Оговорка, и она критичная: некоторые Experience Cloud сайты зависят от гостевого API-доступа для работы Lightning-компонентов. Тестируйте в sandbox. Если API-доступ нельзя отключить полностью - все остальные контроли из этого чек-листа становятся обязательными. Без исключений.
Аналогично отключаем View All Users, Run Flows и Access Activities, если для них нет документированного бизнес-обоснования.
Настройка OWD и минимизация Sharing Rules
Последовательность действий для закрытия Salesforce data exposure:- Установить Default External Access = Private для всех объектов в Sharing Settings
- Пересмотреть каждую Sharing Rule для Guest User - удалить правила без документированного обоснования, заменить «все записи» на правила с конкретными критериями
- Для каждого оставшегося правила настроить Field-Level Security - скрыть чувствительные поля даже при необходимом доступе к объекту
- Включить Secure Guest User Record Access в Sharing Settings - это ограничивает Guest User доступом только к записям, явно расшаренным через Sharing Rules
- Установить Default Owner для записей Guest User - каждая запись должна иметь владельца для корректной работы правил доступа
Контроль видимости пользователей, файлов и самостоятельной регистрации
Portal User Visibility и Site User Visibility - обе настройки должны быть false. По данным Obsidian Security, при включённых значениях Guest User может перечислять внутренних пользователей организации - готовый список целей для социальной инженерии.Файлы с публичными ссылками: проверьте наличие файлов с sharing links, доступными без аутентификации. Объектным разрешениям уделяют основное внимание, а файлы - часто забываемый вектор утечки данных Salesforce.
Self-registration: если сайт не требует самостоятельной регистрации - отключайте. Путь: Setup → All Sites → выбираем сайт → Workspaces → Administration → Login & Registration - удаляем назначение страницы self-registration. Данные, доступные через Guest User, могут использоваться для создания портальных аккаунтов, эскалируя пассивный гостевой доступ в аутентифицированную сессию с более широкими правами. По сути - из «подглядывания» превращаем в «заходи, бери что хочешь».
Загрузка файлов Guest User - для большинства сайтов должна быть отключена. Включённая загрузка означает, что неаутентифицированный посетитель может записывать произвольный контент в вашу организацию.
Маппинг мисконфигураций Salesforce на MITRE ATT&CK
Атака на мисконфигурированный Experience Cloud покрывает несколько тактик и техник MITRE ATT&CK. Маппинг помогает настроить детекцию и приоритизировать защитные меры.| Этап атаки | Техника MITRE ATT&CK | Тактика |
|---|---|---|
| Обнаружение публичного Experience Cloud и доступ через Aura | Exploit Public-Facing Application (T1190) | Initial Access |
| Использование Guest User Profile для анонимного доступа | Cloud Accounts (T1078.004) | Initial Access, Defense Evasion |
| Перечисление пользователей организации через View All Users | Cloud Account (T1087.004) | Discovery |
| Перечисление Public Groups с Guest User | Cloud Groups (T1069.003) | Discovery |
| Извлечение записей Account, Contact, Case через Aura/GraphQL | Customer Relationship Management Software (T1213.004) | Collection |
| Доступ к файлам с публичными sharing links | Data from Cloud Storage (T1530) | Collection |
| Извлечение учётных данных из Tasks, Attachments | Credentials In Files (T1552.001) | Credential Access |
| Эскалация через self-registration и назначение ролей | Additional Cloud Roles (T1098.003) | Persistence, Privilege Escalation |
Техника T1213.004 (Customer Relationship Management Software) наиболее специфична для этого вектора - она описывает именно сбор данных из CRM-систем.
Для мониторинга настройте алерты в Salesforce Event Monitoring на аномальные паттерны API-вызовов от Guest User: массовые запросы к
/s/sfsites/aura и GraphQL-эндпоинту, необычные объёмы выгрузки. Setup Audit Trail зафиксирует изменения в Sharing Rules и Profile Permissions - проверяйте его регулярно на предмет несанкционированных модификаций.
Ограничения техники и контекст применимости
Описанные векторы атаки и методы аудита применимы к Salesforce Experience Cloud (Lightning) с активными Experience Sites. Если организация использует только внутренний Salesforce без публичных порталов - вектор через Guest User неприменим. Но проблемы Salesforce OWD sharing settings и внутренних Sharing Rules остаются актуальными для защиты от инсайдеров и скомпрометированных учёток.Отключение API Enabled может сломать сайт, если Lightning-компоненты используют серверные вызовы для рендеринга. Всегда тестируйте в sandbox. При невозможности отключить API-доступ - фокусируйтесь на минимизации Object Permissions и Field-Level Security как компенсирующих контролях.
SOQL-запросы для аудита прав доступа Salesforce могут вести себя по-разному в зависимости от версии API и edition (Enterprise, Unlimited). Запросы к
ObjectPermissions и PermissionSet доступны в API v49.0 и выше.Инструменты sret, cirrusgo и AuraInspector предназначены для легитимного аудита собственной инфраструктуры. Их использование против чужих экземпляров без письменного разрешения незаконно. В рамках red team или bug bounty убедитесь, что scope явно включает Salesforce-окружение.
Для организаций с большим количеством Experience Cloud сайтов ручной аудит может быть недостаточен. Стоит посмотреть в сторону решений класса SaaS Security Posture Management (SSPM) - AppOmni, Obsidian Security, Reco - которые автоматизируют непрерывный мониторинг конфигураций. Для систематического освоения аудита SaaS-платформ и облачной безопасности обратите внимание на профильные курсы Codeby.
Вопрос к читателям
У кого из вас в продакшне есть Salesforce Experience Cloud с активным Guest User Profile? Вот что интересно: если вы выполняли SOQL-запрос кObjectPermissions WHERE Parent.Profile.Name LIKE '%Guest%' AND PermissionsRead = true - сколько объектов оказалось доступно на чтение и были ли среди них Account или Case? Второй вопрос практичнее: кто настраивал мониторинг API-вызовов от Guest User (токен undefined) в Event Monitoring - какие пороговые значения количества запросов в минуту к /s/sfsites/aura вы выставили для алертов?
Последнее редактирование модератором:
