Забудьте всё, что вы знали о журналах безопасности. Два десятилетия мы жили под утешительной, хотя и часто слепой, верой в то, что логи не лгут. Вся наша система безопасности — SIEM, аналитика поведения пользователей, автоматизированные плейбуки — построена на фундаменте различения неудачного входа от успешного. И что происходит, когда злоумышленник может подделать вход, который выглядит совершенно легитимным в вашей среде Entra ID (ранее Azure AD)? Мы говорим об успешном событии аутентификации, которое, казалось бы, прошло через MFA и политики условного доступа, но при этом не коснулось ни одного байта ваших реальных данных. Это та самая тревожная реальность, которую обнаружила Varonis Threat Labs, и, честно говоря, это из тех вещей, которые не дают спать старому волку.
Непосредственная угроза может заключаться не в краже данных, но каковы дальнейшие последствия для вашей операции безопасности, вашего бюджета и самой целостности ваших данных? Это куда более коварные вещи.
Cross-Tenant ROPC: Лог без входа
Хитрость, как оказалось, кроется в специфическом нюансе протокола Resource Owner Password Credentials (ROPC) и «кросс-теннантной» архитектуре. Суть такова: злоумышленник получает в руки действительное имя пользователя и пароль вашей организации (назовём её Tenant A). Обычно ваши надёжные MFA или устаревшие блокировки протоколов захлопнули бы дверь. Но этот вектор атаки умён. Вместо того чтобы пытаться войти в Tenant A напрямую, злоумышленник использует те же учётные данные для аутентификации в другом, гораздо более разрешительном теннанте (Tenant B).
Вот где начинается вся путаница.
Ваш теннант (Tenant A), тот, на который нацелились, проверяет пароль. Бум. Создаётся событие «Sign-in: Success». Тем временем другой теннант (Tenant B), с которым злоумышленник на самом деле общается, проверяет свои собственные политики условного доступа. Поскольку у Tenant B нет проблем с этим пользователем или этими учётными данными, аутентификация проходит гладко. Итог? Ваша SIEM загорается, как рождественская ёлка, с гордостью заявляя об успешном входе, который, казалось бы, обошёл все ваши с таким трудом созданные защиты. Для многих средств мониторинга — дело сделано. Пользователь вошёл, проблем нет. Кроме, конечно, того, что теперь проблем огромное количество.
Отравление колодца: настоящая опасность
Даже несмотря на то, что злоумышленник не имеет прямого доступа к вашим файлам, потому что он застрял в Tenant B, последствия для вашей позиции безопасности, скажем так, весьма тревожны. Путаница — лучший друг злоумышленника в этом современном цирке безопасности.
Итак, как это отравляет колодец?
Во-первых, обратите внимание на ваши модели User and Entity Behavior Analytics (UEBA) и машинного обучения. Эти системы предназначены для изучения того, что такое «норма». Затапливая ваши логи тысячами этих фальшивых «успешных» входов — из малоизвестных геолокаций, с IP-адресов, которые вы никогда раньше не видели, с немыслимой скоростью — злоумышленник фактически обучает ваши модели игнорировать реальные угрозы. Представьте, что ваша система помечает вход пользователя из 50 разных стран за час как просто очередную аномалию, а не как критический индикатор компрометации. Это создаёт столько шума, что полностью маскирует реальную атаку, происходящую в тени. Хуже того, системы безопасности могут начать реагировать на эти фантомные оповещения, потенциально нарушая работу критически важных производственных систем на основе данных, не имеющих под собой реальной основы.
Налог на SOC: кровь, пот и слёзы ради призраков
Каждый из этих ложных срабатываний имеет свою цену, и платится она временем аналитиков и бюджетом. Аналитик безопасности замечает «успешный» вход с заведомо плохого IP. Что происходит? Он вступает в действие. CISO получает панический звонок. Учётная запись пользователя блокируется. Часы и часы тратятся на расследование взлома, которого, технически говоря, никогда на самом деле не произошло. Злоумышленник может автоматизировать это. Написать скрипт. Затопить ваши системы тысячами таких «призрачных логинов» каждый день. Это не просто раздражает; это изощрённая атака типа «отказ в обслуживании», направленная конкретно на ваш самый ценный и самый дорогой ресурс: ваших человеческих аналитиков. Вы вынуждены тратить бюджет и людские ресурсы, гоняясь за фантомами.
Кошмары с соблюдением нормативных требований? О, ещё бы.
Как вы объясните аудитору, что ваши логи показывают 500 «успешных» входов от пользователя X, все без MFA, хотя MFA должна быть включена для каждой учётной записи? Целостность ваших логов? Вдребезги. Вы смотрите не на истинную запись событий, а на искажённую, манипулированную версию реальности. И это, друзья мои, худший сценарий для сотрудника, отвечающего за соответствие требованиям.
Varonis поступили правильно, сообщив об этом Microsoft. И дай им бог здоровья, Microsoft оценили это как «низкую серьёзность». Их обоснование? Нет прямого доступа к данным, нет прямой компрометации. С чисто технической точки зрения, с точки зрения доступа к ресурсам, я понимаю. Но из окопов? Для CISO, пытающегося управлять SOC, для аудитора, пытающегося проверить вашу безопасность, серьёзность совсем не низкая.
С точки зрения SOC и аудита, обеспокоенность остаётся значительной: защитники могут по-прежнему интерпретировать эти события как свидетельство значимого доступа, вызывая расследования, оповещения и рабочие процессы реагирования на инциденты на основе телеметрии, которая не обязательно отражает компрометацию ресурсов.
Суровая правда заключается в следующем: статических логов больше недостаточно. Многие поставщики, да и сама Microsoft, смотрят на ROPC и видят «низкую серьёзность», потому что данные напрямую не были извлечены. Но реальная опасность кроется в контексте — или, скорее, в его полном отсутствии. Нам нужно перестать спрашивать: «Они вошли в систему?» и начать задавать сложные вопросы: «Получили ли они доступ к данным?» «Получили ли они доступ к ресурсу внутри нашего теннанта?» Если ваши инструменты безопасности следят только за входной дверью, их легко обмануть фальшивым звонком в дверь. Вам нужно знать, что происходит внутри дома.
Так что в следующий раз, когда будете создавать правило SIEM или просматривать оповещение, посыпайте эти журналы аутентификации щепоткой интеллектуальной осторожности. Они не всегда так честны, как кажутся.
Почему это важно для моего SOC?
Эта кросс-теннантная ROPC-атака является прямым ударом по операционной эффективности и точности вашего Центра операций безопасности. Она вооружает против вас сами данные, на которые опирается ваш SOC для обнаружения и реагирования на угрозы. Создавая тысячи «успешных» входов, которые обходят ваши основные средства контроля аутентификации (MFA, условный доступ), но не предоставляют доступа к реальным данным, злоумышленники генерируют поток ложных срабатываний. Это заставляет ваших SOC-аналитиков тратить драгоценное время на расследование несуществующих инцидентов, истощая ресурсы и бюджет. Более того, это искажает ваши модели UEBA и ML, подкармливая их обманчивыми данными, что потенциально маскирует реальные угрозы, представляя их как обычную активность. В конечном счёте, эта техника направлена не на прямую кражу данных, а на подрыв вашей способности обнаруживать, когда данные действительно находятся под угрозой.
Заменит ли это мою работу?
Нет, этот конкретный метод атаки напрямую не заменит вашу работу, но он, безусловно, сделает её сложнее и может снизить эффективность ваших существующих инструментов, если не принять должных мер. Цель этих «призрачных логинов» — перегрузить и запутать вашу команду безопасности и системы, а не устранить их. Основная работа аналитика безопасности — расследование, поиск угроз, реагирование на инциденты — остаётся критически важной. Однако эта атака подчёркивает необходимость более совершенных методов обнаружения, выходящих за рамки простых метрик «успех/неудача входа». Вам нужно будет сосредоточиться на проверке фактического доступа к ресурсам и данным в вашем теннанте, а не только на самом событии аутентификации. Это означает инвестирование в инструменты, обеспечивающие более глубокую видимость и контекст, и их настройку, а также, возможно, адаптацию ваших стратегий поиска угроз для поиска закономерностей обмана, а не просто прямого несанкционированного доступа.
🧬 Связанные идеи
- Читайте также: Жизненный цикл управления уязвимостями: от обнаружения до исправления
- Читайте также: [Захвати повествование] Боты склоняют вымышленное голосование в учениях
Часто задаваемые вопросы
Что делает протокол Resource Owner Password Credentials (ROPC)? ROPC — это устаревший поток аутентификации, при котором приложение напрямую обрабатывает имя пользователя и пароль. Он обычно считается менее безопасным, чем современные протоколы, такие как OAuth или OpenID Connect, поскольку он может легче раскрывать учётные данные приложениям и по своей природе не поддерживает многофакторную аутентификацию (MFA) легко.
Как работает эта кросс-теннантная атака в Entra ID? Злоумышленник использует действительные учётные данные пользователя для аутентификации в другом теннанте (Tenant B), отличном от его домашнего теннанта (Tenant A). Tenant A регистрирует это как «успех», потому что пароль действителен, даже если политики Tenant B являются теми, которые в конечном итоге разрешают (ограниченный) поток аутентификации. Это создаёт обманчивый журнал «успешного входа» в Tenant A без предоставления доступа к данным или ресурсам Tenant A.
Почему Microsoft называет это низкой серьёзностью? Оценка Microsoft, вероятно, сосредоточена на прямом воздействии: никакие пользовательские данные или ресурсы теннанта не скомпрометированы. С их точки зрения, основная цель безопасности — предотвратить несанкционированный доступ к данным и услугам. Поскольку этого не произошло, непосредственный риск считается низким. Однако статья утверждает, что воздействие на работу SOC, возможность аудита и потенциал маскировки реальных атак делают это серьёзной проблемой для защитников.
