The update closed an entry route
On 2 March 2021, Microsoft disclosed attacks against on-premises Exchange Server and released fixes for four vulnerabilities: CVE-2021-26855, CVE-2021-26857, CVE-2021-26858 and CVE-2021-27065. Its account described access to email and installation of additional malware. Exchange Online was not affected by those on-premises vulnerabilities.
The attack chain became widely known as ProxyLogon. Microsoft's later updates described exploitation by multiple actors beyond the initially reported HAFNIUM campaign. That is why a product finding should not automatically become a threat-actor attribution: the vulnerable software and the identity of the party using it are different questions.
For a server already exposed before the fix, patch completion answered whether the original vulnerability remained available. It did not establish that a previously installed web shell or another follow-on access path had disappeared.
Ask three different questions of the same server
Was it exposed? Establish the product release, relevant patch state and reachable interfaces over the period in question. A current inventory cannot reconstruct an earlier internet exposure unless the associated change records exist.
Was it used? Review the appropriate server, web and security records using current vendor investigation guidance. Keep findings tied to the source and retention window. Suspicious requests, a matching artefact and confirmed attacker execution are not interchangeable observations.
What persisted? Assess the application and host state, identities and integrations that could have been affected. Do not describe a machine as clean merely because one filename was not present. An indicator list covers known observations, not every possible action on a compromised server.
| Evidence gap | Consequence for the conclusion |
|---|---|
| Logs begin after the patch | They cannot rule out earlier exploitation |
| The host was rebuilt without preservation | Later analysis may lose artefacts needed to establish the sequence |
| Only external requests were reviewed | Host execution and follow-on access remain separate questions |
| Only the current release was recorded | The historical exposure window remains uncertain |
Treat the mailbox role as a source of leverage
An email system contains conversations, attachment histories and information about ongoing business processes. Its administrative relationships can extend beyond delivery of messages. The value of the system to an intruder is therefore not captured by whether users can send mail again.
Ask service owners which privileged accounts, connectors and administrative workflows touched the affected environment. Protect the response team's access route before replacing credentials. Coordinate changes with dependent services so that an urgent security action does not become an unexplained chain of application failures.
The MOVEit campaign provides a useful later comparison. Both cases require separating software remediation from investigation of data access and persistence. Their vulnerability mechanics and application roles differ: a file-transfer service and an email server are not interchangeable containment problems.
A handover that the next team can use
A server version is a starting point, not a clean bill of health
In an authorised Exchange Management Shell, administrators can read the registered server identities and displayed versions:
Get-ExchangeServer |
Select-Object Name, AdminDisplayVersion
Interpret the result using Microsoft's current build and update documentation. This coarse version record does not, alone, establish every installed security update, the state of an application process or the outcome of a compromise assessment. Capture the specific update evidence required for that server release rather than assuming the displayed version answers all three questions.
An inventory should also identify who owns the server and where its logs are retained. The person able to update Exchange may not administer the load balancer, endpoint protection or central log platform. Establishing those contacts before maintenance can preserve records that would otherwise disappear during a rebuild.
Write a finding that can survive a handover
Compare two synthetic examples. “No web shell found” omits the search scope and relevant period. “The documented artefact review covered these locations on the preserved image; web access logs were available for this interval; earlier requests remain unresolved” explains what the investigation can support.
The second form does not require publishing sensitive paths or raw mailbox material. Keep detailed evidence internally and publish only the scope, method and conclusions appropriate to the audience. Technical precision and data minimisation are compatible when the report distinguishes its public narrative from its evidence store.
Assign a follow-up owner to any limitation that could change the return-to-service decision. Other limitations may remain in the historical record without blocking restoration. The important point is that this is an explicit decision based on impact and available evidence, rather than uncertainty disappearing when a ticket is closed.
Keep the evidence period in a machine-readable field as well as the narrative. A receiving team should be able to compare it with the exposure interval without guessing which timezone or server the author meant.
A restoration handover should contain the known vulnerable interval, remediation evidence, records preserved, findings reviewed, access paths addressed and unresolved questions. Give each unresolved item an owner. This is more actionable than a single green status labelled Exchange patched.
If an organisation has only partial records, state the resulting limit explicitly. The point is not to attach a standard uncertainty paragraph to every incident; it is to explain the specific decision the missing evidence prevents. For example, expired web logs may prevent establishing which requests reached the application, while endpoint records may still support conclusions about later process execution.
The enduring operational lesson is that recovery has at least two completion criteria: the application is fit to resume service, and the investigation has addressed the authority the intruder may have retained. A team may reach those decisions at different times. Keeping them separate makes the remaining work visible.