"It has a vendetta against Kaspersky Lab.
If this malware finds running Kaspersky processes on the system, it writes junk to the first 10 sectors of the disk, and then reboots, bricking the machine completely."
lol
lol
Basically - if I get right the note - if you have some Kaspersky Lab software running the malware ONLY writes junk to the first 10 sectors and reboots, which basically means:
1) on MBR rebuild the MBR partitiontable entries from the existing (untouched) partition/volumes on disk
2) on GPT restore the partition table from the backup
Both are perfectly doable to restore the system in a full working condition.
It sounds more like a sort of (indirect) "vaccine", instead of getting a deadly influence, you get just a cold, a couple of aspirins and all is well (and the malware cannot spread from that machine to other machines on the network, since it rebooted to the junk and the OS is not running anymore).
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?
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.
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.)
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.
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.
btw frodobaggins not frodobegins
If the device isn't only useful as a brick afterwards, it's not bricking. Requiring reformatting or replacing a hard drive is hardly enough to do that in most circumstances.
I've seen people successfullu do this before after their super old ROOT disk gets corrupted exactly where the windows bootloader is...
1) MBR "style" partitioning:
in first sector of the disk there are at most 4 addresses pointing to the partitions on the disk (which may consist of primary partitions and as such volumes, or one of them may point to an extended partition that has a chain of EMBR's pointing to logical voluems inside it) It is trivial nowadays, using freely available software, to search the disk for the volumes and rebuild the partition tabel in the MBR.
2) GPT disk:
The first sector is only a "protective MBR" where in the partition table there is only one entry spanning from sector 2 up to the end of the disk (this can of course be rebuilt in no time). The issue is that the GPT partition table (i.e. addresses of the volumes) is in the following sectors (and the overwriting of 24 or 9 sectors will destroy the data for good, as normally only two sectors are used) and due to the peculiariries of the way these GPT entries are stored it is slightly more difficult to rebuild the data (though the actual volumes on disk can anyway be found and retrieved/imaged).
But - IMHO more or less the only good thing about GPT - the MBR and all GPT tables are automatically backed up to the end of the disk, so there is usually no need to rebuild anything, it is just a matter to properly restore the entries from the backup.
However, as you say, having data backed up is a better solution.
The Kaspersky condition in Petya is indeed unusual, but I would agree with the initial blog post that right now there isn't enough information to make even an educated guess. Kaspersky isn't just popular in Russia, it's consistently a top 3 world-wide, both for individual users and for businesses.
While I appreciate and even sometimes enjoy speculation such as this for fun, I agree with the F-Secure blog post that it is not useful in the current situation as there just isn't enough evidence to develop anything more than wild guesses.
[1] https://www.av-comparatives.org/wp-content/uploads/2017/01/s...
But it is also banned in Ukraine, where most targets were.
Anti-virus would be a brilliant way to gain access to millions of machines, send back "sample" files via specific user targeted updates...
If so (and again I'm starting this sentence with IF), being lenient on Kaspersky would have dual benefits of focusing the target Ukraine, provide a "cure" for any critical machines hit in Russia, and allow existing Kaspersky users to recover once the cure is known.
The Interesting thing here is if this was a trial run, I don't think you get another one. If there is another bit of malware that treads lightly on Kaspersky machines, or "accidentally" fails to activate on them then the gig is up.
Still speculation, but will be interesting to follow.
Source: https://blogs.technet.microsoft.com/mmpc/2017/06/29/windows-...
During malware initialization phase, this malware maintains a global variable that dictates its behavior. It alters its behavior based on the presence of processes related to certain antivirus applications running in the system.
Specifically, it looks for names of processes belonging to Kaspersky Antivirus and Symantec Antivirus and alters its behavior if it finds them.
Information controlling threats behavior is stored in a global variable (gConfig in the screenshots), which is then used to check during MBR modification.
If Kaspersky Antivirus process is found in the system or if the MBR infection is unsuccessful, the malware then proceeds to destroy the first 10 sectors of the hard drive.
Without any evidence, it's nothing but pure speculation and rumor-mongering.