Введение
В последние годы гибридная инфраструктура стала стандартом де‑факто. Компании перевозят критичные сервисы в Azure, AWS,Google Cloud или Yandex.Cloud но оставляют on‑prem AD как точку доверия.Практически всегда многофакторная аутентификация (MFA) включена для доступа к административной учетной записи облака, считая ее непреодолимым барьером.
В этом материале я разберу кейс из практики расследований,вкотором злоумышленники не взламывали 2FA,им не пришлось, вместо этого они нашли способ легально войти в облако под сессией уже авторизованного администратора. Техника называется Shadow RDP.
Исходные условия
Гибридная связка: on-prem AD + Azure AD Connect
Критические данные в Azure: VM,Storage
MFA включено для всех привилегированных учетных записей
Этапы атаки
Почему логи Azure AD не помогли сразу
AzureAD зафиксировал один успешный вход сMFA утром. Все дальнейшие действия выглядели как продолжение той же сессии.Аномалия обнаружилась только при анализе длительности сессии >12 часов, хотя администратор не работал в ночное время.
Техническая детализация Shadow RDP
Shadow RDP - штатная возможность Windows 10/11 или Windows Server с ролью Remote Desktop Services Host (RDSH): один пользователь подключается к активному сеансу другого.
Что изменили хакеры на машине администратора
Настроили режим теневого подключения
# полный контроль за сессией без запроса согласия (режим 2)
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v Shadow /t REG_DWORD /d 2 /f
# Отключить уведомление пользователя о наблюдении (опционально)
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v ShadowNotification /t REG_DWORD /d 0 /f
Режимы Shadow (значения):
0 - запрещено
1 - полный контроль с разрешения
2 - полный контроль без разрешения
3 - наблюдение с разрешения
4 - наблюдение без разрешения (использовано в атаке)
Настроили правила Windows Defender Firewall
Какие события можно котролировать в журналах Windows:
Event ID 20508 - Shadow View Permission Granted
Event ID 20503 - Shadow View Session Started
Event ID 20504 - Shadow View Session Stopped
Как хакеры подключились к сессии.
mstsc /shadow:ID_сессии /control /noConsentPrompt
Почему атаку сложно обнаружить?
Признак |
Нормальное поведение |
Во время атаки |
Длительность сессии Azure AD |
8- 9 часов |
24+ часа |
MFA- запросы |
Каждое утро или при смене IP |
Отсутствуют после захвата |
IP- адрес входа |
Офис / VPN |
Тот же, что у админа |
Процессы на станции |
Браузер, PowerShell, RDP |
Дополнительно: mstsc /shadow |
Время активности |
Рабочее (9:00- 18:00) |
Включая ночные часы |
Какие логи помогли в расследовании.
Источник |
Event ID |
Что фиксирует |
Security (станция админа) |
4657 |
Изменение Shadow / ShadowNotification в реестре |
PowerShell Operational |
4103 |
Set- ItemProperty для реестра |
TerminalServices- LocalSessionManager |
20503 |
Начало теневого подключения |
TerminalServices- LocalSessionManager |
20504 |
Завершение теневого подключения |
Azure AD Sign- in |
- |
Длительность сессии |
Azure AD Sign- in |
- |
Отсутствие MFA- запросов при смене IP внутри сессии |
Меры защиты
1. Отключить Shadow RDP там, где он не нужен (GPO)
2. Принудительное завершение RDP- сессий (GPO)
«Ограничить продолжительность сеанса удаленных рабочих столов» → например, 8 часов
«Завершать сеанс при достижении ограничения» → Включено
3. Conditional Access в Azure AD
Политика «Частота проверки подлинности»: повторный MFA каждые 1- 2 часа
Политика «Требовать повторную аутентификацию при смене IP»
Запрет на «Оставаться в системе» (Keep me signed in) для привилегированных ролей
4. Защита самих RDP- хостов
Включить Restricted Admin Mode (запрещает передачу учетных данных)
Включить Credential Guard
Использовать Remote Credential Guard для подключений
5. Привилегированные рабочие станции (PAW / PAM)
Отдельные чистые станции для управления облаком
Принудительная перезагрузка после каждой сессии
Запрет на выход в интернет (кроме облака) и почту с PAW
6. Мониторинг (SIEM / SOAR)
Обнаружение изменения реестра
Обнаружение Event ID 20503 / 20504
Корреляция событий облака и no- perm
Объеденять логи с облака и on- prem
Таким образом, MFA -обязательный, но недостаточный элемент защиты. Сессия после успешного входа -это новый периметр атаки. Если вы не контролируете кто сидит за клавиатурой в сессии, сколько длится сессия, какие процессы запущены на станции администратора, то MFA не спасет.
Комментарии (9)
Ranlod
11.04.2026 17:25Я может не совсем понял статью, но вроде речь идет про перехват существующей сессии в локальной сети подрядчика и тут mfa вроде не при делах. Как и облачные хранилища не при делах, весь взлом происходил в сети подрядчика на его устройствах. Если я правильно понял.
Другой вопрос как так получилось что
MFA- запросы -> Отсутствуют после захвата
Т.е хакер отключил MFA в облаке? Если да то как он это смог сделать? Ведь для отключения MFA всегда нужен код подтверждения от MFA чего у хакера не было он был у оригинального админа.
Ну и присоединяюсь к вопросу выше, не понятно как хакер с обычной учетки подрядчика смог заполучить себе доступ админскгого уровня если речь про облако?
fisht Автор
11.04.2026 17:25Добрый день!
Статья не про то, как они осуществили первый вход в инфру и как они продвигались и повышали свои привилегии в системе, а про то, как сделали переход из no-prem в облако. Хакеры получили полный доступ к no-prem среде, но доступа к управлению облаком у них не было. Из пункта 6 в этапе атаки говорится, что их цель зайти на Azure portal, на котором установлена MFA, для управления облачными ресурсами.Портал Azure— это веб‑консоль для управления ресурсами Microsoft Azure. Он позволяет создавать, администрировать и отслеживать различные облачные ресурсы: от простых веб‑приложений до сложных инфраструктурных решений. С помощью портала можно управлять подпиской Azure через графический интерфейсОсновные возможностиСоздание ресурсов.Портал предоставляет мастера и шаблоны для быстрого развёртывания виртуальных машин, баз данных, хранилищ, сетей и других сервисов.Управление ресурсами.Можно изменять настройки существующих ресурсов, масштабировать их, управлять доступом и правами.Мониторинг и оповещения.Интеграция с Azure Monitor позволяет отслеживать состояние сервисов в реальном времени, настраивать оповещения и анализировать метрики.Управление затратами.Встроенные инструменты аналитики помогают отслеживать расходы, оптимизировать бюджет и избегать непредвиденных затрат.Безопасность.Поддержка управления доступом на основе ролей (RBAC), интеграция с Azure Security Center для мониторинга соответствия требованиям безопасности.Панели мониторинга.Возможность создавать настраиваемые панели для визуализации ключевых ресурсов и метрик. Панели можно сохранять, клонировать и делиться с другими пользователями.Совместная работа.Поддержка совместной работы с контролем доступа для разных пользователей и команд.
В процессе расследования, мы обнаружили, что хакеры нашли компьютер администратора, который отвечал за управление облаком. Но как получить доступ к облаку, ведь там же 2FA!Злоумышленниками были произведены действия с компьютером администратора (смотри статью) и они стали ждать...
долго ждать, когда администратор войдет в свой браузер, откроет портал Azure, введет логин и пароль + 2FA, а еще не закроет сессию в конце своего рабочего дня.
mayorovp
11.04.2026 17:25Ну, это у вас просто злоумышленник был того уровня, когда нужен ручной доступ. Скрипт в планировщике или там расширение в браузере - и никаких RDP для управления облаком не потребуется вообще.
2FA защищает от кражи пароля, а не от доступа с подконтрольной злоумышленнику машины.
vselubyat
11.04.2026 17:25Простая гигиена мне кажется решила бы вопрос, даже на этапе юзер-менеджмента
Почему изменения привелегий на захваченных узлах остались без внимания?
Почему утечка подрядчика осталась без внимания? У него вообще должен был оставаться какой-то доступ к инфраструктуре?
Это все риторические вопросы, у вас простой пример, как фирма платит за безопасность так или иначе
mayorovp
Что-то ваше описание атаки оставляет одни вопросы без ответов…
Shadow RDP что, вообще никаких паролей для входа не просит? Не верю…
Откуда у атакующего взялся доступ чтобы настраивать реестр? Для этого же права администратора нужны? И если они права администратора у него уже были, зачем вообще понадобилось воровать сеанс?
Судя по описанию, mstsc был запущен на вашем сервере. Почему именно так? И откуда у злоумыгленника взялась учётная запись чтобы запускать mstsc на сервере?
fisht Автор
На момент атаки у злоумышленников уже были права Domain Admin в on-prem среде.
Перемещение по сети не представляло проблем. Злоумышленники не могли получить доступ к облаку, так как на админской учетке была установлена 2FA.
itoolsy
Так это самое интересное - как они domain admin получили, имея только rdp от пользователя. Дальше - не интересно, ибо все ключи у них уже есть.
propell-ant
А там на картинке:
"Компрометация учетных данных подрядчика через старую утечку ..." - no comments.
Но статья про то, что в "умелых" руках 2FA не спасает, это (для меня например) неожиданно.
lyric
Del, промахнулся с веткой