Атака на ReliaQuest закончилась не утечкой клиентских данных, а неприятной, но показательной демонстрацией того, как ломают даже тех, кто сам продает защиту. Один сотрудник компании ввел учетные данные на поддельной SSO-странице и подтвердил MFA-запрос, после чего злоумышленник получил временный view-only доступ к панели идентификации Okta. Для русскоязычных ИТ-команд это важный сигнал: если у атакующего уже есть логин, пароль и подтвержденная сессия, дальше все решают не презентации про zero trust, а реально настроенные ограничения на уровне устройств и доступа к приложениям.
Об инциденте сообщает BleepingComputer. По данным издания, атакующий обзванивал сотрудников ReliaQuest и выдавал себя за члена внутренней команды безопасности. Цель была довольно приземленной: заставить жертву открыть фальшивую страницу единого входа, спрятанную за CDN, и ввести корпоративные учетные данные. По информации источников BleepingComputer, использовался домен-двойник reliaquest.claims, а в телефонной атаке звучало имя реального сотрудника службы безопасности. Это уже не классический фишинг из серии «вам пришла странная ссылка», а аккуратно собранный сценарий с вишингом, брендингом и хорошим пониманием внутренних процессов цели.
Один из сотрудников на уловку все же попался. Он ввел пароль на поддельной странице и одобрил push-уведомление MFA, фактически сам открыв злоумышленнику дверь в свой Okta-аккаунт. Но дальше сработали защитные механизмы, которые у многих компаний до сих пор либо не включены, либо живут только в дорожной карте. ReliaQuest заявляет, что доступ был строго view-only: атакующий видел панель идентификации, но не смог зайти в приложения и системы компании. Попытки пройти дальше блокировались за счет device-trust controls, то есть проверок доверия к устройству. Компания также утверждает, что клиентские данные не были затронуты, другие учетные записи не скомпрометированы, а признаков закрепления в инфраструктуре не обнаружено. После инцидента ReliaQuest завершила сессии злоумышленника, отозвала скомпрометированный пароль, сбросила токены аутентификации и дополнительно проверила fidelity контролей, device trust и on-network access начиная с 21 августа.
Отдельный слой иронии добавляет имя вероятного противника. За атакой, по всей видимости, стоит группировка ShinyHunters, известная по вымогательским и компрометационным кампаниям. Незадолго до этого исследователи самой ReliaQuest предупреждали, что ShinyHunters регистрирует домены в зоне .claims по шаблону company.claims, чтобы маскироваться под help desk и ИТ-службы компаний. Пост команды Threat Research в X позже был удален, но успел вызвать ответ от недавно созданного аккаунта, который связывают с атакующими. В ответе была фраза в духе «кто на кого охотится» и скриншоты, похожие на скомпрометированный Okta SSO-аккаунт сотрудника ReliaQuest. Затем те же изображения появились на leak-сайте ShinyHunters. Любопытно, что сама группировка, по данным BleepingComputer, описала масштаб инцидента почти теми же словами, что и компания: доступ был только на просмотр, до бизнес-приложений, клиентских данных и закрепления в системе дело не дошло. Редкий случай, когда у вендора и у шантажистов почти совпадает пресс-релиз.
Для отрасли здесь важна не драма вокруг громкого имени, а механика атаки на ReliaQuest. Мы снова видим сценарий, в котором стартовая точка не zero-day и не сложная эксплуатация уязвимости, а вполне бытовая социальная инженерия плюс усталость пользователя от push-уведомлений. Если сотрудника можно убедить, что он разговаривает с внутренней безопасностью, то пароль и MFA уже не выглядят непробиваемой стеной. Значит, реальная зрелость защиты измеряется не только наличием SSO и двухфакторки, а тем, что происходит после первичной компрометации. Есть ли ограничения на основе доверенного устройства? Разрешен ли доступ к чувствительным приложениям только с управляемых endpoints? Можно ли быстро отозвать сессии и токены? Видно ли, что пользователь внезапно зашел через lookalike-домен и CDN, а затем пытается открыть административную панель?
Для российских разработчиков, продуктовых команд и ИТ-руководителей история полезна еще и как напоминание о слабом месте корпоративной автоматизации. Чем удобнее внутренний доступ, тем выше цена ошибки на первом шаге. Многие компании долго спорят о паролях, passkeys и UX многофакторной аутентификации, но забывают, что help desk давно стал поверхностью атаки. Если в компании нет жесткого протокола для звонков от ИБ, нет понятного способа верифицировать запрос сотруднику поддержки и нет запрета на переход по ссылкам из устных инструкций, атака на ReliaQuest легко превращается в локальный кейс с уже менее приятным финалом. Особенно если доступ к административным консолям построен по принципу «авторизовался в IdP — значит, почти везде свой».
Этот инцидент неприятен для ReliaQuest именно потому, что компания специализируется на кибербезопасности. Но в этом и практическая ценность кейса: он показывает, что даже профильный вендор можно зацепить на человеческом уровне, а потом остановить только глубиной уже внедренных контролей. Главный вопрос теперь не в том, сумеет ли ShinyHunters придумать еще один домен в зоне .claims, а в том, сколько компаний за пределами рынка ИБ действительно готовы пережить такой же вход через валидные учетные данные и подтвержденный MFA без доступа злоумышленника к приложениям и данным.