Petya //NotPetya Survival Guide

Thank you cakos.

Normally I would assume that the "victim" tries to reboot several times.

Suppose that he finds then a friendly IT'er (with some forensics insight) my PC is infected! We all know that.

- He brings his system in; already rebooted several times for sure -yes, we know.
- We remove the HDD from the customers' machine;
- We attach this HDD to a clean PC, making sure that the new drive gets checked for viruses before accessing it.
- This avoids rebooting the customers' HDD.

Now that we have a "clean" HDD, what might we discover with regards to file extensions and/or encrypted files?

Suppose that he finds then a friendly IT'er (with some forensics insight) my PC is infected! We all know that…

From what I read, I suppose you can either boot the system with a Windows recovery disk and try to fix the MBR with the recovery console (cmd) if you are lucky, and see if it boots

bootrec /fixmbr
bootrec /fixboot

or plug it in another machine and start carving for files / partitions etc..

… I suppose you can either boot the system with a Windows recovery disk and try to fix the MBR with the recovery console (cmd) if you are lucky, and see if it boots

bootrec /fixmbr
….

No, that surely won't work, not without rebuilding the partition entries data.
The /fixmbr only writes the MBR CODE, not the DATA.
The MBR is overwritten by either the fake ransomware screen or by "junk" in case of Kaspersky files found, according to
https://labsblog.f-secure.com/2017/06/29/petya-i-want-to-believe/

In both cases both CODE and DATA are overwritten, so you have to rebuild the data by rewriting the partition entries (as an example TESTDISK or DMDE can do normally that) or - as you pointed out

or plug it in another machine and start carving for files / partitions etc..

BTW (it depends on the specific systems setup) there might be drive letter assignment issues when booting (after having fixed properly the MBR code and rebuilt the partition table data) because the disk signature will have been changed, so before attempting a reboot it is advised to get it from the Registry (DosDevices) and manually write it in the MBR.

@vdhee
Yep ) ,as we all know the only sensible thing to do in case of any hint of malware infection (which is to physically pull the power plug or physically remove batteries in case of a laptop as soon as possible and NOT reconnect power before having asked for assistance) will not be done by 99.99% of users. (
On the other hand, the above generically valid advice has been partially disproved by the recent WannaCry, in which case if you kept the system on (without rebooting and that malware did not force a reboot - differently from this Petya/Not Petya thingy) you had some (cannot say how many) chances to find the encryption/decryption key in memory.

jaclaz

No, that surely won't work, not without rebuilding the partition entries data.
The /fixmbr only writes the MBR CODE, not the DATA.
The MBR is overwritten by either the fake ransomware screen or by "junk" in case of Kaspersky files found, according to
https://labsblog.f-secure.com/2017/06/29/petya-i-want-to-believe/

I was quoting this blog post by MS - the second of the "Boot recovery options" - regarding the recovery console

blogs.technet.microsof...re-attack/.

Otherwise, I agree with you. And for someone who has no idea what hit him/her, its is a gamble how to proceed (keep it on, shut it down? break it? lol )

I was quoting this blog post by MS - the second of the "Boot recovery options" - regarding the recovery console

blogs.technet.microsof...re-attack/.

There is no "recovery console" reference?

You mean this?

Case 2 If system is non-UEFI, installed with Kaspersky Antivirus, and in a state where boot completely fails

The ransomware attempts to destroy the first 10 sectors of the \\\\.\\PhysicalDrive0 if Kaspersky Antivirus is found or if the MBR infection is unsuccessful. Thus, boot process hijack through malicious MBR hasn’t been completed so the MFT (Master File table) contents are intact and not encrypted by the threat. In this case, the partition table information is destroyed by the threat. Given that it stores critical information needed in the booting process, a traditional boot repair process may not work. Rebuilding the partition table may require consultation with an expert.

jaclaz

There is no "recovery console" reference?

You mean this?

Case 2

Yes and I went to check it again, and for a minute I though I was losing it from the heat roll until I checked the cached version (which I was looking at when I posted earlier) 😯

Case 2 If system is non-UEFI, installed with Kaspersky Antivirus, and in a state where boot completely fails

The ransomware attempts to destroy the first 10 sectors of the \\\\.\\PhysicalDrive0 if Kaspersky Antivirus is found. Thus, boot process hijack through malicious MBR hasn’t been completed. In this case, booting off a clean installation media, going to recovery console and performing the following commands has good chances of recovering the system and make it boot again (success depends on the specific initial disk sectors layout)

<recovery_console> bootrec /fixmbr

<recovery_console> bootrec /fixboot

https://https://blogs.technet.microsoft.com/mmpc/2017/06/29/windows-10-platform-resilience-against-the-petya-ransomware-attack/+&cd=4&hl=el&ct=clnk&gl=gr&client=firefox- b">webcache.googleusercontent.com/search?q=cachetxdJ5sVxeygJ https://blogs.technet.microsoft.com/mmpc/2017/06/29/windows-10-platform-resilience-against-the-petya-ransomware-attack/+&cd=4&hl=el&ct=clnk&gl=gr&client=firefox-b

Yes and I went to check it again, and for a minute I though I was losing it from the heat roll until I checked the cached version (which I was looking at when I posted earlier) 😯

Lol D , they (the good MS guys) either read our previous posts or independently managed to "put their act together" wink .

It's a very good thing that you had that web cache available. )

It should have been evident for anyone familiar with BIOS/MBR booting that once both data and code are destroyed (whole sectors) rewriting only the correct code will lead nowhere.

Also, in the context of Windows 10, there is no recovery console at all (only 2K and XP had it), you may appreciate how the current text now talks about a generic "traditional boot repair process".

It (the page modification) represents anyway a subtle/sneaky way to correct (wrong) information.

jaclaz

Lol D , they (the good MS guys) either read our previous posts or independently managed to "put their act together" wink .

lol lol

Also, in the context of Windows 10, there is no recovery console at all (only 2K and XP had it), you may appreciate how the current text now talks about a generic "traditional boot repair process".

😯 Yes there is - it either pops up after a failed boot, or you can revoke it by booting from a win10 setup disc/usb. Unless you mean the good old F8 key right after boot … well that died..

Yes there is - it either pops up after a failed boot, or you can revoke it by booting from a win10 setup disc/usb. Unless you mean the good old F8 key right after boot … well that died..

No, there isn't. roll

There is that thing there that is called "Recovery Environment" or WinRE (which is essentially a Preinstallation Environment or PE renamed), but there is not anymore the Recovery Console, since Vista.
http//www.proposedsolution.com/solutions/windows-7-or-vista-recovery-console/

The Recovery Console was a completely separate mini (really mini) OS
https://en.wikipedia.org/wiki/Recovery_Console
installed optionally on the hard disk as a "dual boot".

jaclaz