Shadow RDP bypasses MFA in Azure

Shadow RDP: How Attackers Hijack Cloud Admin Sessions

Attackers bypassed MFA in a hybrid on-prem AD + Azure setup using Windows' built-in Shadow RDP feature. They slipped into an active admin session without re-authenticating, gaining full control over Azure resources. The breach flew under the radar in Azure AD logs until someone spotted the session lasting over 12 hours.

Attack Conditions and Initial Red Flags

The hybrid setup featured on-prem Active Directory synced via Azure AD Connect. Critical assets like VMs and storage lived in Azure, with MFA enforced on all privileged accounts.

Azure AD logged just one successful MFA login that morning. All follow-up actions looked like a seamless extension of that session. The red flag? An unusually long session—over 12 hours—with no overnight admin activity.

| Indicator | Normal Behavior | During Attack |

|----------|-----------------|---------------|

| Azure AD Session Duration | 8–9 hours | 24+ hours |

| MFA Prompts | Every morning or IP change | None after hijack |

| IP Address | Office/VPN | Same as admin's |

| Processes | Browser, PowerShell, RDP | + mstsc /shadow |

| Activity Time | 9:00 AM–6:00 PM | Overnight hours |

Technical Breakdown of Shadow RDP

Shadow RDP is a native Windows 10/11 and Server feature (with RDSH role) that lets you join another user's active session.

Attackers tweaked the admin workstation's registry for stealthy access:

# Full control without consent prompt (mode 2)
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v Shadow /t REG_DWORD /d 2 /f

# Disable observation notification
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v ShadowNotification /t REG_DWORD /d 0 /f

Shadow modes:

• 0 — Disabled
• 1 — Full control with permission
• 2 — Full control without permission
• 3 — View-only with permission
• 4 — View-only without permission (used in this attack)

They also adjusted Windows Defender Firewall rules for RDP ports.

Session hijack command: mstsc /shadow:SESSION_ID /control /noConsentPrompt.

Key Windows Log Events

Monitor these Event IDs to spot Shadow RDP:

• Event ID 20508 — Shadow View Permission Granted
• Event ID 20503 — Shadow View Session Started
• Event ID 20504 — Shadow View Session Stopped

Other logs for investigation:

| Source | Event ID | Captures |

|--------|----------|----------|

| Security (admin workstation) | 4657 | Shadow/ShadowNotification registry changes |

| PowerShell Operational | 4103 | Set-ItemProperty for registry |

| TerminalServices-LocalSessionManager | 20503 | Shadow session start |

| TerminalServices-LocalSessionManager | 20504 | Shadow session end |

| Azure AD Sign-in | — | Session duration |

| Azure AD Sign-in | — | No MFA on IP change |

Defenses and Countermeasures

• GPO to Disable Shadow RDP: Set Shadow=0 on non-essential hosts.
• Limit RDP Sessions: GPO "Set time limit for active but idle Terminal Services sessions" — 8 hours, with forced disconnect.
• Azure AD Conditional Access:

* MFA frequency: Every 1–2 hours.

* Re-auth on IP changes.

* Block "Keep me signed in" for privileged roles.

• Harden RDP Hosts:

* Restricted Admin Mode.

* Credential Guard.

* Remote Credential Guard.

• PAW/PAM Workstations: Isolated admin machines, reboot after use, no internet/email.
• SIEM/SOAR Monitoring:

* Registry changes.

* Event IDs 20503/20504.

* Correlate cloud and on-prem logs.

Key Takeaways

• MFA won't save you from session hijacks—focus on session duration and process monitoring.
• Shadow RDP is a legit feature; detect it via registry tweaks and Event IDs 20503+.
• Hybrid environments demand correlating Azure AD and Windows logs.
• Conditional Access with frequent MFA is your baseline against session hijacking.
• PAW shrinks your endpoint attack surface.

— Editorial Team