- Security
- A
How hackers bypassed 2FA and seized cloud infrastructure
In recent years, hybrid infrastructure has become the de facto standard. Companies are moving critical services to Azure, AWS, Google Cloud, or Yandex.Cloud while leaving on-prem AD as a trust point. Multifactor authentication is almost always enabled for access to cloud admin accounts, considered an insurmountable barrier.
In this material, I will discuss a case from investigative practice where attackers did not hack 2FA; they didn't have to. Instead, they found a way to legally enter the cloud under the session of an already authorized administrator. This technique is called Shadow RDP.
Initial Conditions
Hybrid setup: on-prem AD + Azure AD Connect
Critical data in Azure: VM, Storage
MFA is enabled for all privileged accounts
Stages of the Attack
Why Azure AD logs didn’t help immediately
Azure AD recorded one successful login with MFA in the morning. All subsequent actions appeared to be a continuation of the same session. The anomaly was only detected when analyzing the session duration >12 hours, even though the administrator was not working during the night.
Technical Details of Shadow RDP
Shadow RDP is a built-in feature of Windows 10/11 or Windows Server with the Remote Desktop Services Host (RDSH) role: one user connects to another's active session.
What hackers changed on the administrator's machine
Configured shadow connection mode
# full control over the session without consent request (mode 2)
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v Shadow /t REG_DWORD /d 2 /f
# Disable user notification about observation (optional)
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v ShadowNotification /t REG_DWORD /d 0 /f
Shadow Modes (values):
0 - disabled
1 - full control with permission
2 - full control without permission
3 - observation with permission
4 - observation without permission (used in the attack)
Configured Windows Defender Firewall rules
What events can be controlled in Windows logs:
Event ID 20508 - Shadow View Permission Granted
Event ID 20503 - Shadow View Session Started
Event ID 20504 - Shadow View Session Stopped
How hackers connected to the session.
mstsc /shadow:SESSION_ID /control /noConsentPrompt
Why is the attack difficult to detect?
Indicator | Normal behavior | During an attack |
Azure AD session duration | 8-9 hours | 24+ hours |
MFA requests | Every morning or when changing IP | None after takeover |
Login IP address | Office / VPN | The same as the admin's |
Processes on the station | Browser, PowerShell, RDP | Additionally: mstsc /shadow |
Activity time | Working hours (9:00-18:00) | Including night hours |
Which logs helped in the investigation.
Source | Event ID | What it records |
Security (admin station) | 4657 | Change of Shadow / ShadowNotification in the registry |
PowerShell Operational | 4103 | Set-ItemProperty for the registry |
TerminalServices-LocalSessionManager | 20503 | Start of shadow connection |
TerminalServices-LocalSessionManager | 20504 | End of shadow connection |
Azure AD Sign-in | - | Session duration |
Azure AD Sign-in | - | Absence of MFA requests when changing IP within the session |
Protective measures
1. Disable Shadow RDP where it is not needed (GPO)
2. Force logoff of RDP sessions (GPO)
“Limit the duration of remote desktop sessions” → for example, 8 hours
“End session when limit is reached” → Enabled
3. Conditional Access in Azure AD
“Authentication frequency” policy: repeat MFA every 1-2 hours
“Require re-authentication when IP changes” policy
Prohibition on "Keep me signed in" for privileged roles
4. Protection of the RDP Hosts
Enable Restricted Admin Mode (prevents credential transmission)
Enable Credential Guard
Use Remote Credential Guard for connections
5. Privileged Workstations (PAW / PAM)
Separate clean stations for cloud management
Forced reboot after each session
No internet access (except for cloud) and email from PAW
6. Monitoring (SIEM / SOAR)
Detection of registry changes
Detection of Event ID 20503 / 20504
Correlation of cloud events and no-perm
Combine logs from cloud and on-prem
Thus, MFA is a mandatory but insufficient element of protection. A session after a successful login is a new attack perimeter. If you do not control who is sitting at the keyboard during the session, how long the session lasts, and what processes are running on the admin station, then MFA will not save you.
Write comment