The Exchange Heist: How Attackers Weaponize SSRF and NTLM Relay to Compromise Email Servers

If you ask any corporate IT administrator what keeps them up at night, Microsoft Exchange is almost guaranteed to be near the top of the list. Email servers are the crown jewels of enterprise communication; they hold confidential conversations, financial records, reset tokens, and directory schemas.

Because Exchange servers sit at the intersection of public accessibility and deep internal network integration, they have historically been prime targets for sophisticated threat actors. Remember the infamous ProxyLogon and ProxyShell campaigns? They weren't isolated accidents—they were masterclasses in exploiting complex protocol interactions. Let's pull back the curtain on how Server-Side Request Forgery (SSRF) and NTLM relay attacks collide to compromise enterprise email architecture.

The First Domino: Server-Side Request Forgery (SSRF)

To understand an Exchange exploit chain, you have to look at how the front end talks to the back end. Exchange uses a front-end proxy (running on Internet Information Services or IIS) to route incoming client web traffic to internal backend PowerShell and Exchange Web Services (EWS) endpoints.

An SSRF vulnerability occurs when an attacker sends a specially crafted, unauthenticated HTTP request to the front-end server that tricks the server into making an outbound connection to an internal service it normally shouldn't trust. The front-end server acts as an unwitting accomplice, blindly fetching data from the local network and handing it back to the external attacker.

The Pivot: NTLM Relay and Privilege Escalation

Once the SSRF opens the door to internal backend endpoints, attackers face a secondary hurdle: authentication. This is where NTLM relay mechanics come into play.

Microsoft Exchange heavily relies on Windows NTLM authentication protocols for internal service-to-service communication. If legacy NTLM is enabled, an attacker can intercept authentication challenges and relay them across the network. By tricking the Exchange server into authenticating against itself or another local service using high-privilege credentials (such as the local SYSTEM account), the attacker gains the ability to drop malicious files, write web shells into the Exchange directory, and execute arbitrary commands.

Hardening Exchange: Actionable Defense Strategies

Patching vulnerabilities as soon as Microsoft releases Cumulative Updates (CUs) and Security Updates (SUs) is non-negotiable. However, zero-days exploit unpatched windows. To protect your Exchange environment proactively, implement these hardening measures:

1. Enable Extended Protection for Authentication (EPA)

Microsoft heavily advocates for enabling Extended Protection for Authentication across all virtual directories on IIS. EPA significantly mitigates NTLM relay attacks by binding the authentication session to specific TLS channel characteristics.

2. Restrict OWA and EWS Exposure

Never expose Outlook on the Web (OWA) and Exchange Web Services directly to the open internet without an intervening zero-trust proxy, Web Application Firewall (WAF), or VPN requirement. Restricting administrative PowerShell access to internal jump boxes drastically shrinks the available attack window.

3. Audit PowerShell Logs & Inbox Rules

Deploy Microsoft Defender for Endpoint or equivalent EDR solutions to monitor for anomalous child processes spawned by IIS worker processes (w3wp.exe). Routinely audit automated inbox forwarding rules and script execution telemetry.

References & Further Reading

• Microsoft Security Response Center (MSRC): Exchange Advisory Portal
• CISA Cybersecurity Advisories on Microsoft Exchange Exploitation
• Microsoft Support: Extended Protection Guidance for Exchange
• OWASP Foundation: Server-Side Request Forgery Explanation
• Microsoft Learn: Defender XDR and Threat Protection Documentation