Как хакеры обошли 2FA и захватили облачную инфраструктуру

Введение 
В последние годы гибридная инфраструктура стала стандартом де‑факто. Компании перевозят критичные сервисы в 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 

Почему атаку сложно обнаружить? 

 

Какие логи помогли в расследовании. 

Меры защиты 

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 не спасет.