Skip to content
Security Operations

Patching alone is not enough: Investigate your exposure windows


  • Patching alone is not enough
  • Timebox your exposure windows
  • Search your exposure windows for indicators of compromise, misuse, and persistence
  • Microsoft has published guidance for responders
  • Sophos has also published guidance for responders
  • Follow the Sophos Investigative Framework for observables
  • If you are compromised and need assistance, call our Rapid Response team
  • If you’re in the clear, review your threat detection and response capabilities ahead of the next attack


In the wake of the recent high-severity Microsoft Exchange vulnerabilities that have been exploited in-the-wild by Hafnium, DearCry, and an increasing number of other threat groups, it is essential to understand one simple fact: patching alone is not enough.

Patching protects you moving forward. It covers a hole through which an adversary could breach your network and gain a foothold inside. But a patch, in most cases, will do nothing to thwart an adversary who has already snuck in through that hole, abusing an unpatched vulnerability.

Make no mistake, patching is a crucial action to mitigate the risk of a software vulnerability, but when a vulnerability has become public knowledge or has been exploited in the wild before a patch is released, it is critical to threat hunt and analyze system activity throughout your exposure window.

Exposure windows

When a software vulnerability is publicly announced, an exposure window opens. The window is the time between two crucial events: the earliest sighting of an abuse of the vulnerability, and the time when you applied an available patch, or otherwise mitigated the threat.

An exposure window enables you to timebox when adversarial activity may have occurred and set about threat hunting between those points in time.

Your local exposure window is the time between the earliest indicator of attack (IOA) or indicator of compromise (IOC) identified within your network or at its edges, and the time you installed the relevant patch for the vulnerability. If there are no IOCs or IOAs in your network then the date of the vulnerability’s public disclosure can be used.

For many, web shells began appearing on their Exchange servers from February 27th 2021 onwards, as Hafnium and others began mass exploiting the vulnerabilities.

Your global exposure window begins with the earliest known abuse in-the-wild or the public disclosure of the vulnerability, whichever is earliest, and ends when you have installed the relevant patch.

Published intelligence reports show a variety of times which the global exposure window opened, with many security teams identifying successful exploitation in January 2021, however there is anecdotal commentary on social media that suggests exploitation may have been occurring as far back as November 2020.

For ProxyLogon/Hafnium, your local and global exposure levels will look something like this:

Timeboxing and hunting within your exposure window

Patching provides us with one of the necessary timestamps for timeboxing an exposure window – the time at which the window closed – however we also need to identify when that window opened.

We know that the global exposure window opened sometime between November 2020 and January 2021. However, identifying when the local exposure window opened requires IOCs or IOAs to be hunted for to identify whether a vulnerability has been abused and, if it has, extract timestamps from observables to aid timeboxing and subsequent threat hunts for adversarial activity.

Microsoft’s recent guidance for responders provides a detailed breakdown of how to identify whether you have been compromised via the recent Microsoft Exchange vulnerabilities.

From this guidance, one can extrapolate two major risks due to these vulnerabilities: unauthorized email access and the deployment of web shells.

Unauthorized email access

First you need to review the output of Test-ProxyLogon.ps1 and look for the presence of Cve-2021-26855.csv as this will indicate successful exploitation of the Server-side Request Forgery vulnerability.

If the .csv contains references in the AnchorMailbox column to /ews/exchange.asmx? this indicates an attacker may have exfiltrated email. To investigate, you will need to review the Exchange logs located in <Exchange install path>\V15\Logging\EWS

Deployment of web shells

Using the tools made available by Microsoft in their guidance for responders, or if you are using Sophos Intercept X EDR, leverage our guidance and queries, to identify the presence of web shells deployed by an adversary.

If web shells are present, you must review the possible command activity to reveal actions taken by the adversary.

Web shells enable an adversary to remotely issue commands to your server and orchestrate the rest of their attack. If they have successfully deployed one inside your network, it could be used for anything. Thus, we must reveal what an adversary did with that shell and understand what impact they may have had.

Adversarial activity

Use EDR technology, such as Sophos Intercept X EDR, to search throughout your exposure windows to identify adversarial activity. EDR provides us with a historic record of system telemetry like command executions and process activity which we can retrospectively search over.

First your local exposure window must be reviewed as this is your period of highest risk. Once complete and you have high confidence in your findings, your global exposure window should be reviewed.

Within each window, conduct a review of any and all activity seeking anomalous behavior, file access, lateral movement, privilege escalation, exfiltration, planting of additional code, configuration modifications, etc.

The most common scenario observed by Sophos Managed Threat Response (MTR) is where the parent process is w3wp.exe or umworkerprocess.exe with malicious activity stemming from these processes.

We have also seen a lot of on-the-fly compiling of C# .NET assemblies using csc.exe, and with this one you look in the following directory for suspicious DLLs:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\%

It is important to note that while the above behavior has been observed in multiple different networks by Sophos MTR, the nature of the vulnerabilities mean that there is potential for different scenarios to occur. We strongly recommend you use the timeboxing of your exposure windows to review all system activity, especially in close proximity and subsequent to the time the web shell was deployed by the adversary.

Sophos Investigative Framework

Maintaining focus during an investigation is no easy task. Analyzing data and following trails can lead you down many different rabbit holes. Keeping on goal requires a methodical approach.

In Sophos MTR, we use our own investigative framework that we refer to as Threat Detection and Response (or TDR for short). We’ve written about our framework before and the tools within will help you both during an investigation as well as preparing for the next potential incident.

Know your capabilities and limitations

Conducting investigations in the wake of major incidents like Hafnium/ProxyLogon requires time and expertise. For many organizations, being able to be certain there is no adversarial activity in their network is simple out of scope of their team’s current capability.

Should you believe yourself to be facing an active threat that has exploited the vulnerabilities in Microsoft Exchange, especially if you have been able to identify the presence of web shells, Sophos Rapid Response are here to assist and ensure adversaries are ejected from your network.

If you’re not facing an active threat but wish for an expert team to watch over your network 24/7, identifying, investigating, and responding to threats that have evaded your defenses, Sophos Managed Threat Response are here to help.

Finally, if you are one of the lucky organizations that has not had vulnerable Microsoft Exchange servers exploited and your investigation showed no sign of web shells or adversarial activity, take the time to review your threat detection and response capabilities ahead of the next attack.

Major incidents like ProxyLogon are powerful learning experiences and by understanding the threat vector and adversarial behavior exhibited post-exploitation, you can add invaluable detection and response capabilities to accelerate future investigations and prevent future threats.


I don’t know if you guys monitor this, but I had a webshell (I think?) in my inetpub directory, exactly where you said it would be. I removed that and thought I got everything, until I saw this post after the webinar and it mentioned looking in the .NET framework64 directory and I found these:

I renamed them to .old just incase they are legit (so I can move them back), but in the .compiled files are references to similarly named files in the /asp_client/ folder. I don’t recall exactly, but that’s probably where that webshell was. Thanks for this info!


Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!