countries, i.e. Poland • Source of the infection: M.E.Doc – tax accounting software company in Ukraine • Initial vector: a malicious update • As it turned out, the attackers resided on the M.E.Doc servers months before the outbreak
the malware at first. • Among the researchers it was refered as: Petya, Petya.A, NotPetya, ExPetr, Nyetya, EternalPetya, Petna, GoldenEye, PetrWrap... • In the later annoucements, attackers refered to it as Petya.A/NotPetya https://www.youtube.com/watch?v=Vor9sWpJQHw
with selected extensions (using AES + RSA) https://www.youtube.com/watch?v=Vor9sWpJQHw 3ds 7z accdb ai asp aspx avhd back bak c cfg conf cpp cs ctl dbf disk djvu doc docx dwg eml fdb gz h hdd kdbx mail mdb msg nrg ora ost ova ovf pdf php pmf ppt pptx pst pvi py pyc rar rtf sln s ql tar vbox vbs vcb vdi vfd vmc vmdk vmsd vmx vsdx vsv work xls xlsx xvd zip
see the malware scanning our LAN, in order to spread to other machines... 5. Master Boot Record is overwritten with the malicious bootloader and the kernel, that is meant to deploy the low level attack after the reboot https://www.youtube.com/watch?v=Vor9sWpJQHw
extensions 2. Low level attack: encrypts Master File Table, making disk inaccassible 3. Spreads itself on other machines in the LAN (using i.e. NSA’s „Eternal” exploits) https://www.youtube.com/watch?v=Vor9sWpJQHw
can do it as well But Petya has a unique feature: it attacks a bootloader, and then encrypts low-level structures on the disk (Master File Table) – making disk unreadable Do you remember last year’s Petya? https://blog.malwarebytes.com/cybercrime/2017/07/keeping-up-with-the-petyas- demystifying-the-malware-family/
(Goldeneye) • Each version introduced improvements • Latest versions were not decryptable Do you remember last year’s Petya? https://blog.malwarebytes.com/cybercrime/2017/07/keeping-up-with-the-petyas- demystifying-the-malware-family/
overwrites the disk’s beginning with Petya kernel • Encrypts files with selected extensions, one by one •Petya kernel • perform the disk encryption (MFT) https://blog.malwarebytes.com/cybercrime/2017/07/keeping-up-with-the-petyas- demystifying-the-malware-family/
extensions 2. Low level attack: encrypts Master File Table, making disk inaccassible 3. Spreads itself on other machines in the LAN (using i.e. NSA’s „Eternal” exploits) https://blog.malwarebytes.com/cybercrime/2017/07/keeping-up-with-the-petyas- demystifying-the-malware-family/
as: C:\Windows\perfc.dat Run by: rundll32.exe <path>,#1 • aeee996fd3484f28e5cd85fe26b6bdcd – a legitimate app incorporated by the malware: PsExec • Mimikatz-like components for stealing credentials (they are used for further spreading the malware in the LAN) • 2813d34f6197eb4df42c886ec7f234a1 – 32 bit version • 7e37ab34ecdcc3e77e24522ddfd4852d – 64 bit version • f3471d609077479891218b0f93a77ceb – the low level part (Petya MBR + kernel)
look at the differences... Conclusion: it is a Petya, but not a legitimate strain – not recompiled from the original source. The Petya kernel was pirated and stolen from the original author. Missing optimizations. This assembly code can never be generated if the code was recompiled. https://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-yet-another-stolen- piece-package/
successfuly collected money •Not really, because paying the ransom cannot help a victim The victim ID is a random string, generated BEFORE the encryption key is made Conclusion: the attackers deliberately decided not to preserve the key https://blog.malwarebytes.com/threat-analysis/2017/06/eternalpetya-lost-salsa20-key/
i.e. Satana ransomware, that was deployed in wild on a small scale, was also unfinished... https://blog.malwarebytes.com/threat-analysis/2016/06/satana-ransomware/ It reads user input, but never process it. Original MBR cannot be recovered.
Petya.A/NotPetya tried to reimplement some features of the original Petya by their own, i.e. preserving the original MBR obfuscated by XOR with 0x7 Conclusion: redundant efforts in case of destructive intentions The original MBR is preserved in the sector 34 Accurate imitation of the original Petya’s behavior
on Ukraine already happened in the past, so it may be their continuation... • However: if the ransomware is just a cover, why the authors didn’t finish the cover? The fact of not preserving the key could be easily obfuscated, i.e. pretending that it is sent to a dead CnC server... https://en.wikipedia.org/wiki/December_2015_Ukraine_power_grid_cyberattack
from the NSA: ETERNALBLUE, ETERNALROMANCE + DOUBLEPULSAR injector with minor modifications 2. Using conventional tools: PsExec, Wmic Conclusion: the infector is written by professionals Similarly to WannaCry ransomware, that used ETERNALBLUE https://blogs.technet.microsoft.com/mmpc/2017/06/27/new-ransomware-old-techniques-petya-adds-worm-capabilities/ https://www.esentire.com/blog/a-closer-look-at-petyasnotpetyas-network-spreading-code/
global list •Multiple sources: 1. command line argument (-h <ip>) 2. Scanning ports 139 and 445 in LAN 3. DHCP servers and clients (DhcpEnumServerClients) 4. Cached ARP entries (GetIpNetTable) 5. Active TCP connections (GetExtendedTcpTable) 6. ActiveDirectory domain (NetServerEnum) https://blogs.technet.microsoft.com/mmpc/2017/06/27/new-ransomware-old-techniques-petya-adds-worm-capabilities/ https://www.esentire.com/blog/a-closer-look-at-petyasnotpetyas-network-spreading-code/ Conclusion: very scrupulous in finding network targets
tool for dumping credentials https://blogs.technet.microsoft.com/mmpc/2017/06/27/new-ransomware-old-techniques-petya-adds-worm-capabilities/ https://www.esentire.com/blog/a-closer-look-at-petyasnotpetyas-network-spreading-code/ used for lateral movements credentials are sent to the malware over a pipe...
flags are set depending on: • options1: based on privileges • options2: Installed AV products: avp.exe (Kaspersky), ccSvcHst.exe (Symantec), NS.exe (Norton Security) Conclusion: the behavior of the malware may vary on various machines https://blog.nviso.be/2017/06/30/recovering-custom-hashes-for-the-petyanotpetya-malware/
• No, if avp.exe (Kaspersky AV) is detected, it does not write the Petya kernel at the beginning of the disk... Instead, it overwrites those sectors with random data • No MFT encryption deployed https://securelist.com/no-free-pass-for-expetr/79008/ avp.exe detected -> options2 &= 0xFFFFFFF7 = -9 (4th bit is cleared) If avp detected, the buffer is written, but not filled with Petya’s code 8 = 1000b (check 4-th bit)
the options that are checked... Conclusion: some of the conditional flags are not implemented – it may be a hint that the malware is not finished and got released prematurely (tests?) Options2 checked: 1,2,4,8,16 avp.exe detected -> options2 &= 0xFFFFFFF7 = -9 (4th bit is cleared) NS.exe or ccSvcHst.exe detected -> options2 &= 0xFFFFFFFB = -5 (3rd bit is cleared)
not possible • Plaintext attack on the ciphertext: • Possible due to an error in implementation of Salsa20. • Yet, may be difficult in real life scenarios... • There is a tool by CrowdStrike: https://www.crowdstrike.com/blog/decrypting- notpetya-tools-for-recovering-your-mft-after-an-attack/ • Forensically carving files out of the disk... Conclusion: there is no perfect solution allowing to recover MFT and got all the data back.