back

by masswerk·9y ago·view on hn ↗
As I read it, first there's user-mode encryption in every case. Then, admin-mode is attempted, and, when successful, either the first 10 sectors including the MBR are overwritten by garbage, in case Kapersky software was found, or there's a botched attempt to encrypt the first 25 disk sectors. Mind that user-mode and admin-mode tasks are apparently in separate modules and that the user-mode module is run first, while detecting the Kapersky lab process and overwriting the disk sectors requires admin mode.

To me, the "Kapersky branch" appears to be more destructive than the default branch.

Edit: Also, there have been reports of the malware scanning and transmitting any credentials stored on the machine, while in "encrypted mode." (Suggesting, there's still a functional basic system left in order to accomplish these tasks.) Couldn't it be for Kapersky AV still being able to detect this activity and hence rather bricking the machine than giving away some of the features early?

3 comments
Looking at MS analysis here: https://blogs.technet.microsoft.com/mmpc/2017/06/27/new-rans... https://blogs.technet.microsoft.com/mmpc/2017/06/29/windows-...

It seems confirmed that if the Kaspersky files are detected, only first 10 sectors of PhysicalDrive0 are overwritten, and NO encryption of the $MFT is performed, so the system is recoverable:

>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.

So the "Kaspersky branch" is much less destructive than the "normal" branch.

Now, the process as described in the MS analysis differs from the description provided by F-Secure.

MS: "[W]hen the malicious MBR starts, it loads additional code from sectors after the MBR, which in turn proceeds to encrypt the Master File Table (MFT). After the encryption process is complete, the user is presented with the following ransom message, which is different from the typical ASCII skull and crossbones shown by the original Petya"

(This suggest that first the MBR is overwritten conditionally and that the encryption happens on a reboot in this modified MBR.)

The F-Secure blog, on the other hand, suggests [edit: at least in my reading] that there's first a process running in user-mode doing the file encryption, followed by another step, in admin mode, attempting to modify the first disk sectors (including the MBR).

To me, the two sources (MS and F-Secure) are contradictory.

Edit: Can it be that the MS analysis is about the "double infection" of an already compromised machine, as described in the F-Secure blog? (Different teams may start at different points with their analysis. As the analysis proceeds, the patterns found by the various teams may merge into a single representation of the workings of the malware.)

I don't see as "contradicting", more like "still not fully defined".

1)The thingy runs and encrypts "in user mode" only a given set of file types (per list of extensions).

2)Then it tries to get "admin mode" and write to the MBR (and following sectors) some code capable on reboot to encrypt the $MFT BUT

3)at some point it checks if either a Symantec (if found does something that is irrelevant to the encryption) or a Kaspersky file/service if running, and if the Kaspersky file is found only overwrites MBR+9 sectors with "junk" that prevents from booting again the OS.

So, independently from step 1 (which in itself only affects some data), step 2 is "totally destructive", whilst the effects of step 3 are easily fixable and - once fixed - will allow normal access to files (either encrypted or non encrypted).

It does sound "strange" because the same kind of access is needed to write directly to the MBR and a few following "hidden" sectors no matter if you are writing highly sophisticated boot and encryption code or just junk, so - at face value - it seems exactly the contrary of what is the interpretation on F-Secure website, as those running a Kaspersky will have LESS damage.

Certainly more destructive for the 99.9% of owners who don't know what MBR or GPT is.
I don't get it, really, IF data can be recovered through a procedure (that BTW is not particularly difficult or new, even if the owners don't know what a MBR or a GPT is, any technician can recover a disk where only the first 10 sectors were filled with junk) the procedure is NOT destructive at all while encrypted files, particularly if encrypted with a "good enough" and "random" key are not recoverable at all.

Of course it may provoke delays/problems/whatever, but data is still there.

If the sequence is:

1) encrypt user files

2) get admin access and crypt MBR (in such a way that is not decryptable)

3) reboot

the "destructive part" is #1, the MBR can be rebuilt from scratch just fine (and possibly if the reboot is somehow prevented the encryption key may be recovered from RAM as it happened in some cases for Wannacry, in which case it is #3 that creates more damage).

The doubt is when the "Kaspersky vendetta happens", if it goes:

1) encrypt user files

2) get admin access and crypt MBR and 24 more sectors(in such a way that is not decryptable) OR check the presence of Kaspersky and write junk to first 10 sectors of disk

3) reboot

It doesn't anyway change anything, there is no real difference between rebuilding a MBR (or GPT) because it was crypted and rebuilding it because it was overwritten by junk data, but once you have rebuilt it, if the files are encrypted you have lost them all the same.

x2. Someone on the team probably had beef with Kaspersky and decided to hose the partition table of anyone using it. Hosing the partition table is a pretty poor way of minimizing damage because as you point out, 99.9% of people affected will be more affected if the partition table is hosed.
Or they just want people to turn off their Kapersky AV so as not to risk having their machine bricked.