How can security teams detect FoggyWeb?

What FoggyWeb detection looks like in Exchange environments

FoggyWeb detection is less about a single signature and more about spotting a chain of suspicious behaviour on Exchange servers. Teams should assume that the most useful signals will come from combining file, process, and network observations, especially on internet-facing systems where web shells or backdoors can be used to persist after initial compromise.

The practical question is whether Exchange has started behaving like an attacker foothold. That usually means the server is making changes it would not normally make, launching unusual child processes, or reaching out to destinations that do not match routine mail, directory, or administrative activity.

Because the behaviour is often blended into legitimate server activity, the highest-value detections are baselines plus anomaly review. A single odd event may be noise; a cluster of directory changes, process spawning, and outbound connections on the same host is much stronger evidence that a backdoor is present.

Files, processes, and network paths to watch

Start with the Exchange installation and web-accessible directories, because attacker tooling often lives where web-facing services can load it easily. Watch for new or modified files in those paths, especially if the timing does not align with a known patch, maintenance task, or approved change window.

Then review process ancestry. Child processes created by web server processes are a classic indicator of server-side execution abuse, because web services are not normally supposed to spawn administrative shells, scripting engines, or other interactive tooling during routine operation. When that happens, the issue is often not just a malicious file, but an execution path that is already under attacker control.

Network telemetry matters just as much. Outbound connections from Exchange to unfamiliar hosts, unusual ports, or destinations outside normal mail flow can indicate command-and-control, data staging, or follow-on access. MITRE ATT&CK Enterprise Matrix is useful for mapping those observations to common post-compromise behaviours such as execution, persistence, and credential access.

For teams building detections around server compromise, SANS Security Resources provides useful detection-engineering and incident-handling context for turning those raw signals into triage logic. If your environment relies on broader control mapping, NIST Cybersecurity Framework 2.0 helps organise the same problem under detect, respond, and recover workflows.

How to tell compromise from normal Exchange administration

The main challenge is separating malicious activity from legitimate administration. Exchange servers do create files, run maintenance tasks, and generate network traffic, so the detection standard should be behavioural context, not just event volume.

Look for inconsistency. A legitimate maintenance action usually has a change ticket, a known administrator, predictable timing, and a clear reason for touching the server. A FoggyWeb-style foothold is more likely to show up as unexpected modification of web-accessible content, process trees that do not match normal server roles, and authentication or mailbox activity that appears to originate from a hostile staging point rather than a trusted operator.

Correlate the signals over time. If file changes, suspicious process creation, and outbound connections occur together on the same host, the probability of compromise rises sharply. If the activity repeats after cleanup or appears on more than one Exchange server, treat it as a broader intrusion investigation rather than an isolated anomaly.

Risk and Threat Considerations

FoggyWeb-style activity is dangerous because it sits on top of an internet-facing, high-trust platform that often has deep access to mail, identity, and administrative functions. Once an attacker gets a web shell or backdoor on Exchange, that foothold can support persistence, credential harvesting, mailbox access, and further internal movement.

Failure mechanism: The defender misses weak but correlated indicators, such as altered Exchange web files, abnormal server-child process trees, and outbound traffic that does not fit normal messaging patterns, so the backdoor remains operational long enough to be used for follow-on access.

Impact: Attackers can retain durable control over Exchange, abuse trusted administrative paths, and use the server as a launch point for mailbox access, identity abuse, or broader compromise inside the environment.

Practitioner Guidance

What to prioritise: Treat internet-facing Exchange servers as high-value detection assets and prioritise telemetry that can tie file changes, process lineage, and network egress together. Single-event alerts are often too weak on their own; the useful signal is the combined pattern.

What to verify: Confirm whether suspicious activity lines up with approved maintenance, patching, or administrative work. If you cannot tie the activity to a known operator and a known change, treat it as potential compromise and preserve evidence before making disruptive changes.

Decision rule: If Exchange activity includes unexplained web-directory changes plus atypical child processes or external connections, escalate immediately for compromise assessment rather than waiting for a second independent alert.

Practitioner takeaway: The best FoggyWeb detection strategy is correlation, not single-signature hunting, because the backdoor is most visible when you compare Exchange behaviour against its normal administrative and mail-flow baseline.

Related resources from NHI Mgmt Group

• Guide: Malware Guide
• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?
• What is the difference between SAST and DAST for security teams?