How do you detect ProxyLogon exploitation on Microsoft Exchange servers?

What to look for in Exchange logs when ProxyLogon is being exploited

Detection starts with the web-facing Exchange surface itself. Look for suspicious requests to the vulnerable endpoints, especially sequences that do not fit normal administration or mailbox traffic, then check whether those requests are followed by file writes, web shell placement, or suspicious process execution on the server. The point is to identify the transition from initial access to post-exploitation activity, not just the exploit attempt.

For a broader hunting workflow, NHIMG’s Zero-Day and Exploited Vulnerabilities Guide is useful because ProxyLogon-style activity behaves like an actively exploited vulnerability event: you need exposure confirmation, then rapid log review, then compromise assessment.

Unusual external source IPs matter when they coincide with Exchange endpoint access patterns, but they become much more meaningful when paired with authentication anomalies, odd user-agent strings, or follow-on actions that suggest the attacker moved past scanning into execution. Correlation across IIS, Windows event logs and Defender telemetry is what turns scattered signals into a defensible detection story.

Which post-exploitation signals usually separate exploitation from noise?

The most useful distinction is between a single suspicious request and a chain of actions that show the server was actually used. New files in Exchange directories, unexpected web shells, command execution by atypical parent processes, new accounts, mailbox access that the account should not have, and evidence of internal reconnaissance all raise confidence. If you only see one of these, the case is weaker; if you see several in sequence, treat it as likely compromise.

Microsoft Exchange is often targeted because successful exploitation can quickly lead to remote code execution and then to broader control of the environment. Once that happens, the attacker may use the server to harvest credentials, access mailboxes, create persistence, or stage additional activity. That is why detection must cover both the initial exploit path and the downstream actions.

To anchor investigation, the NIST National Vulnerability Database is a useful reference point for CVE records and product context, while CISA Known Exploited Vulnerabilities Catalog confirms whether the issue is being actively exploited in the wild and helps prioritise response.

For attack-chain thinking, mapping the activity to the MITRE ATT&CK Enterprise Matrix helps analysts separate web exploit activity, credential access and lateral movement into a coherent sequence.

How should a SOC investigate and validate suspected compromise?

Start by scoping all Exchange servers and the time window of suspicious requests, then preserve the relevant logs before they roll or get overwritten. Validate whether the server wrote unexpected web-accessible files, spawned suspicious child processes, or generated authentication patterns that do not match normal admin behaviour. If the server touched mailboxes or directory services, extend the scope outward rather than treating the Exchange host as a standalone issue.

NHIMG’s Vulnerability Management Guide is useful here because detection only becomes actionable when it is tied to asset scope, prioritisation, verification and exception handling, not just alert triage.

If there is any sign of web shell placement or command execution, assume the attacker may have attempted persistence. Validate whether any accounts were created, modified, or used for mailbox access, and look for evidence of credential dumping, outbound connections or staging activity. At that point, detection has become incident response, not just hunting.

Risk and Threat Considerations

ProxyLogon is high-risk because a successful exploit against an internet-facing Exchange server can immediately become a platform for persistence, mailbox access, and broader internal compromise. The main threat is not the initial HTTP request, it is the attacker’s ability to turn that request into durable server control and then pivot into identity, mail and directory assets.

Failure mechanism: The exploit chain succeeds when external requests hit the vulnerable Exchange endpoint, server-side code execution follows, and the attacker is able to place or invoke a web shell, create accounts, or reuse the server’s trust relationships for further access.

Impact: Defenders may see only partial telemetry, while the attacker gains durable access, mailbox visibility, and a foothold for lateral movement or credential theft. If the server is compromised, treat connected accounts, sessions and downstream access paths as potentially exposed.

Practitioner Guidance

What to verify: Confirm whether suspicious endpoint access was followed by file creation, process execution, authentication anomalies or mailbox activity. A single malformed request is not enough to call compromise; a request plus post-exploitation signals usually is.

Decision rule: If you can tie the activity to web shell placement, account creation, or anomalous mailbox access, move from detection to containment and compromise assessment immediately. If the evidence stops at access attempts, keep hunting but separate the host from confirmed compromise.

Practitioner takeaway: The most reliable ProxyLogon detections come from correlating web, host and identity signals into a single timeline, because the exploit only matters operationally once it changes what the server can do.

Related resources from NHI Mgmt Group

• How do you detect web shells dropped on Microsoft Exchange servers?
• What should teams do first when exposed Microsoft Exchange servers are publicly reachable during active exploitation?
• What should incident responders do first when on-premises Exchange servers are exposed to ProxyLogon-style exploitation?
• What are the risks of using static credentials in MCP servers?