NotPetya hit organisations on 27 June 2017 after attackers pushed a malicious update through M.E.Doc, a Ukrainian accounting program. It then spread using stolen credentials and unpatched Windows file sharing. It behaved like destructive malware rather than ransomware. Flat networks, shared admin passwords and trusted update channels were the weak points.
What is the timeline?
- 14 March 2017: Microsoft released the MS17-010 patch that closes the SMBv1 flaws NotPetya later used, according to CISA.
- 14 April 2017: CISA's alert says the M.E.Doc software had been backdoored as early as this date.
- 18 May 2017: ESET noticed a separate file-encrypting malware whose activity began right after M.E.Doc ran.
- 27 June 2017: the Petya-like outbreak hit Ukraine and other countries. CISA was notified of events in multiple countries that day.
- 30 June 2017: ESET published its analysis, concluding the attackers had access to M.E.Doc's update server and pushed a malicious update that installed without user action.
- 15 February 2018: CISA revised its alert to note the US government's public attribution of NotPetya to the Russian military.
How did it get in?
ESET first suspected phishing through M.E.Doc's internal messaging, then concluded the update server itself had been compromised. It found a password-protected PHP backdoor on the vendor's server. The lesson is uncomfortable: customers did the right thing by installing an update from their vendor, and that was the delivery path.
How did it spread once inside?
CISA describes two main mechanisms.
- Stolen credentials. A modified credential-dumping tool collected Windows logins, which were reused with WMIC or PsExec to run code on other machines. CISA calls this the first and usually most effective method.
- SMBv1 exploits. EternalBlue and EternalRomance hit unpatched systems.
ESET adds that companies outside Ukraine were infected through VPN links to branches or partners there. The malware overwrote the master boot record and encrypted files, and ESET found the encryption flawed, so recovery was not possible. CISA notes there was no evidence that the decryption key was tied to the victim ID.
What did CISA recommend?
Patch with MS17-010, disable SMBv1 and block the related ports at the boundary, apply least privilege to admin accounts, restrict WMI and block PsExec, block workstation-to-workstation traffic, segment networks, keep tested backups, and treat any machine with M.E.Doc installed as suspicious. It advised against paying a ransom.
What to do
- Segment the network so one infected laptop cannot reach every server. Test it by trying.
- Remove shared local admin passwords. Unique per-machine credentials break the credential-reuse path.
- Retire SMBv1 and review which legacy protocols still run.
- Treat vendor updates as an attack path. Stage them to a small group first, verify signatures where offered, and know which vendors update themselves.
- Map your connections to partners and subsidiaries. Document which VPN links bring in traffic you do not control.
- Keep offline, tested backups and rebuild images, so recovery does not depend on the infected estate.
- Inventory software that auto-updates from small vendors. These are the quiet single points of failure.
Safeguard's SBOM and dependency inventory help with item 7 for the software you build and ship, and the same discipline of listing what updates itself applies to bought-in tools.
Quick check
Was NotPetya ransomware?
CISA describes it as behaving more like destructive malware, since there was no evidence the encryption key related to the victim ID, and ESET found the file encryption flawed.
How did the malicious code reach victims?
Through a compromised update server for the M.E.Doc accounting software, which pushed a backdoored update that installed automatically, per ESET and CISA.
Sources
- CISA alert TA17-181A, Petya ransomware
- ESET, TeleBots are back: supply chain attacks against Ukraine (30 June 2017)
Last reviewed: 18 October 2026.
