One entry point, more than one way to spread
The malware outbreak of 27 June 2017 is often placed beside WannaCry because both involved SMB exploits. That comparison leaves out the feature that changes containment planning. Microsoft and Mandiant described the initial distribution through a compromised M.E.Doc software update and subsequent movement using both exploits and stolen credentials. Closing the exploitable SMB path did not, by itself, remove the authority already available to the attacker.
Contemporaneous accounts used several names, including Petya, EternalPetya and Petya-like malware. CERT-EU's advisory was updated to describe wiping capability. A retrospective should retain that development in the evidence rather than presenting every early ransomware description as a complete account of the malware's purpose.
The operational problem was a trusted distribution path followed by several lateral movement routes. It required responders to consider which machines received code, which identities the code could acquire, and what those identities could reach.
Model credential reach as a second network
Network segmentation describes allowed connections. Credential reach describes where an account or token can exercise authority. The two overlap, but neither is an adequate substitute for the other.
Consider an administrative account used across several workstation groups. A firewall may divide those groups while a legitimate management service still permits that account to administer all of them. If the account becomes available to malware, the management route can connect otherwise distinct failure domains. This is an illustrative architecture scenario, not a claim about a particular NotPetya victim.
| Boundary | Review question | Useful owner |
|---|---|---|
| Software delivery | Who can alter an approved update or its delivery? | Application and supplier management |
| Administrative identity | Where can this account authenticate or execute? | Identity and endpoint administration |
| Remote management | Which approved tools cross segment boundaries? | Infrastructure operations |
| Recovery | Can restoration proceed without the affected identity system? | Service continuity team |
The review should include approved administration tools. Their legitimate role is exactly why their use cannot be dismissed as harmless during an intrusion.
Containment has to change authority as well as routing
An incident team can isolate hosts while an attacker still holds reusable credentials. It can also rotate credentials while a compromised management host immediately observes the replacements. Sequence matters.
Establish a trusted administration route before introducing replacement secrets. Identify the systems that could have observed privileged activity, isolate or rebuild them under the response plan, and coordinate credential replacement with the people who own the dependent services. Avoid leaving a recovery team to discover hard-coded service credentials through failed production jobs.
Do not equate use of a legitimate remote administration utility with proof that a specific malware family was present. Correlate the execution context, account history and surrounding artefacts. A good retrospective distinguishes the observed incident techniques from the organisation's own incident evidence.
Restore the minimum viable service first
Recovery order should follow dependencies, not the order in which machines entered the ticket queue. Identify the identity, naming, management and application functions required to restore a useful service. Decide which components must be rebuilt from trusted material before other machines are allowed to depend on them.
A backup catalogue is part of this plan, but so are the credentials and tools needed to restore it. If the same administrative identity can change both production and every recovery copy, the apparent separation may be weaker than the storage diagram suggests. Test access and restoration with synthetic data before relying on that boundary.
Inspect the administrative routes
Inspect the administrative surface you already have
On a supported Windows member system with the LocalAccounts module, this read-only pipeline enumerates the local administrators group by its well-known SID, avoiding an English group-name assumption:
Get-LocalGroup -SID 'S-1-5-32-544' |
Get-LocalGroupMember
Domain controllers and systems without that module require the appropriate directory or platform tools instead. The result is a local membership snapshot, not a list of every identity that can administer the machine. Domain policy, service identities and remote-management permissions may create additional routes.
Use the snapshot to identify shared or unexpected privileged memberships, then ask the identity team to establish their effective reach. Do not delete unfamiliar entries as an automated response to this example. An apparently redundant account may support a documented recovery function, and changing it requires the relevant owner.
The complementary network question is where approved management connections are allowed. Join these two maps using the actual service and account identifiers. A diagram with separate network zones is incomplete if one broadly privileged management identity connects them.
Check the recovery identity before the exercise
In a synthetic scenario, assume that the primary endpoint-administration account is unavailable. Ask which identity can restore a machine and which trusted device can use it. Then trace access to installation material, backups and recovery documentation.
If the exercise requires the very identity or management service being treated as compromised, record the circular dependency. Resolve it through the organisation's access and continuity process, with accountable owners and controlled recovery privileges. Creating an undocumented permanent administrator during the exercise would replace one problem with another.
This produces a concrete deliverable: a recovery route whose identities and dependencies are understood, rather than an assurance that backups exist somewhere.
WannaCry is a useful test of patch delivery and reachable legacy protocols. NotPetya adds the interaction between software delivery and credential-backed administration. SolarWinds later put another trusted management product at the centre of a compromise, with different malware and objectives.
For an architecture review, the common question is which trusted component can turn a local failure into wider authority. The answer might be an update service, a shared administrative identity or a management agent. Document the actual route. The name of the last major outbreak is a poor substitute for that map.