Health-ISAC 24 июля предупредила медицинские и медтех-компании о росте успешных атак ShinyHunters. Для ИТ- и ИБ-команд новость важна не только самим фактом новой волны, а маршрутом атаки: злоумышленники все чаще заходят не через серверы, а через IT-поддержку, сброс MFA и захват SSO-учетной записи, после чего быстро проходят по подключенным облачным сервисам.
Организация пишет, что группа делает ставку не на классический шифровальщик, а на кражу данных для вымогательства. Проще говоря, если атакующие получают доступ к Microsoft Entra, Okta или Google SSO, они получают не один ящик, а короткий путь к Microsoft 365, SharePoint, Salesforce и другим системам, где уже лежат нужные им файлы.
Схема атаки идет через IT-поддержку и SSO
В предупреждении Health-ISAC описан повторяющийся сценарий: голосовая социальная инженерия, затем сброс пароля или MFA, потом захват SSO-учетной записи и быстрая выгрузка данных из SaaS-сервисов. Организация отдельно подчеркивает, что именно SSO в таких инцидентах становится центральной точкой управления доступом, а основной ущерб возникает уже на этапе массовой кражи данных из облака.
Это совпадает с тем, что BleepingComputer и Mandiant писали о ShinyHunters раньше: группа использует звонки от имени IT-поддержки и фишинговые страницы, которые помогают в реальном времени вытягивать логины, пароли и коды MFA. В части атак злоумышленники также злоупотребляли доверенными OAuth-связками и доступом к сторонним сервисам. То есть речь не о «хитром одном баге», а о дисциплинированной работе по самому слабому месту компании — процедурам восстановления доступа.
Health-ISAC не раскрыла, сколько именно организаций попали под эту волну и за какой период она выросла. При этом организация отдельно оговаривает важную деталь: не каждое заявление самих ShinyHunters о краже данных подтверждено. Но для защитников это не меняет сути: паттерн с захватом учетной записи и проходом по облачным системам повторяется слишком часто, чтобы считать его разовой историей.
Главная точка отказа — сброс MFA и перевыпуск устройств
Самая полезная часть предупреждения касается не «усиления защиты вообще», а конкретного узкого места. Health-ISAC советует ломать цепочку в момент, когда сотрудник или специалист поддержки меняет пароль, сбрасывает MFA или регистрирует новое устройство. Для таких запросов рекомендуют обязательную проверку личности по отдельному каналу связи: например, обратный звонок на заранее подтвержденный номер, а для привилегированных учетных записей — еще и согласование с руководителем.
Отсюда же рекомендация, которую стоит брать почти дословно: не менять параметры доступа во время входящего звонка. Сначала заявка, потом проверка личности, только затем действие. Для руководителей, администраторов, ИБ-команд и финансовых подразделений правила должны быть еще жестче. Иначе даже хорошая защита периметра мало поможет: если служба поддержки по звонку перевыпускает фактор MFA, злоумышленник уже почти внутри.
Вторая опора — фишинг-устойчивая MFA. Health-ISAC советует переводить группы риска на FIDO2- или WebAuthn-ключи и по возможности отказываться от SMS- и голосовой аутентификации. Регистрацию новых факторов MFA организация предлагает ограничивать дополнительными условиями: управляемое устройство, политики условного доступа и другие признаки доверенного контекста.
Для рынка СНГ сигнал вполне прикладной
Эта история касается не только американского здравоохранения. У любой компании с плотным набором SaaS-сервисов логика та же самая: один захваченный доступ к SSO может открыть путь к почте, документам, CRM, внутренним вики, таск-трекерам и файловым хранилищам. Для разработчиков и платформенных команд это повод пересмотреть OAuth-разрешения, права сервисных учетных записей и журналы событий в облаке. Для бизнеса вывод еще проще: инцидент с одной учетной записью давно перестал быть проблемой одного сотрудника.
На ближайшие 30–60 дней разумный минимум выглядит так: ужесточить процедуры IT-поддержки, включить фишинг-устойчивую MFA для групп риска, проверить политики условного доступа и убедиться, что команда умеет быстро отзывать сессии, токены и доступ к SaaS после компрометации. Если такой сценарий не отработан заранее, атакующие обычно двигаются быстрее внутренних процессов.
Следующий логичный шаг для рынка — перестать считать SSO удобной дверью и начать относиться к нему как к активу уровня доменного контроллера.
Оригинал предупреждения: Health-ISAC. Дополнительный контекст по техникам группы: BleepingComputer и разбор Mandiant.