A strong indicator is an unexpected ASPX file in the Exchange web root, especially in the aspnet_client system_web path. Microsoft also provided PowerShell checks to look for known web shell patterns and related files. If those artifacts are present, the server should be treated as compromised, even if updates have already been applied.
What to look for after a Hafnium-style Exchange compromise
The most reliable signs are not general slowness or login anomalies, but filesystem and web-content artifacts that should never be there. In practice, defenders look for unexpected ASPX web shells, unusual files under the Exchange web root, and PowerShell or script-based indicators that match known post-exploitation activity.
A compromise finding matters even after patching, because Hafnium activity often left persistent access behind the original vulnerability window. If the artifact is present, the server should be treated as compromised rather than merely exposed.
Why the web root matters more than the patch level
Hafnium campaigns were notable because the initial intrusion was only the first step. After gaining access, attackers commonly staged web shells in Exchange directories so they could return, execute commands, and browse mailboxes or internal data later. That means a fully updated server can still be unsafe if the attacker’s foothold was never removed.
Administrators should therefore separate “patched” from “clean.” A patch closes the entry path, but it does not automatically remove malicious files, scheduled access, or any other persistence the attacker established before remediation.
Look closely at the Exchange web root and subdirectories that are internet-facing or commonly abused for web content. A file that does not belong to the installed Exchange version, has an odd name, or appears in a path that is normally static is much more suspicious than a simple service failure. Microsoft’s guidance on Exchange response and investigation remains the most direct operational reference for this class of finding, and the most relevant internal context for this topic is The 52 NHI Breaches Report because it illustrates how stolen access material and post-compromise persistence often travel together.
What investigators usually confirm before declaring the host compromised
The strongest confirmation is the presence of a known or unknown ASPX web shell in the Exchange web tree, especially under aspnet_client or a similarly abnormal location. Investigators also check for related script content, recently modified files, and artifacts that match Microsoft’s published detection commands and file patterns.
Another useful signal is whether the suspicious file was written during the same time window as public exploitation activity or during a period when the host was exposed to the relevant Exchange vulnerability. A file that appears after patching is still highly material if it predates remediation, because the attacker may already have used it to establish access.
Because compromise signs are often file-based rather than alert-based, absence of an IDS alarm does not clear the server. Current practice is to trust the artifact review first, then validate with logs, command history, and any related outbound activity that may show the attacker using the web shell.
Risk and Threat Considerations
Once an attacker has planted a web shell in Exchange, the server becomes a durable access point rather than a one-time intrusion. That creates a high likelihood of follow-on mailbox access, internal reconnaissance, credential harvesting, and lateral movement, even if the original exposure has been patched.
Failure mechanism: The attacker gains code execution through the Exchange flaw, drops a web shell into a writable web-accessible location, and uses it to re-enter the host on demand after the initial exploit window closes.
Impact: The server can remain an active compromise point, with exposure extending to email content, adjacent credentials, and downstream systems that trust the Exchange environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1505.003 — Web Shell | Exchange web shells are the core post-exploitation sign in this case. |
| Recommendation — Map suspicious ASPX files to web shell activity and hunt for follow-on access. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software | Unexpected web-root files are a monitored software integrity signal. |
| Recommendation — Use file-integrity monitoring to detect unauthorized Exchange web content changes. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Unexpected ASPX artifacts indicate integrity failure in Exchange web content. |
| Recommendation — Verify Exchange file integrity and remove or rebuild compromised content. | ||
Practitioner Guidance
What to verify: Confirm whether the suspicious ASPX file is truly out of place for the installed Exchange build and whether its timestamp aligns with the suspected intrusion window. If the file content matches a known web shell pattern, treat that as compromise evidence rather than a low-confidence anomaly.
Decision rule: If you find a web shell or equivalent malicious artifact, prioritize containment and evidence preservation over further tuning of the system. A clean patch or reboot does not make the host trustworthy if attacker-controlled code was already present.
What to prioritize: Reimage or fully rebuild the server when possible, rotate any credentials that may have been exposed, and review adjacent systems for signs of follow-on use. Exchange compromise is rarely isolated to the server itself.
Practitioner takeaway: For Hafnium-era Exchange incidents, the key question is not whether the vulnerability is fixed, but whether attacker persistence was left behind. File-system evidence inside the Exchange web root should drive the response.
Related resources from NHI Mgmt Group
- What are the signs that an on-premises Exchange server may already be under active attack?
- What should security teams do first when a GitLab server may already be compromised by ransomware or miner activity?
- What actions should I take if my OAuth tokens are compromised?
- What are the signs that Tomcat has already been compromised by a web shell campaign?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
