I'm thinking that the malware world develops code on the same level as the rest of the coding world. So developing a robust MBR and network component that can use drop-in exploits would make sense.
Seems like the tough part would be setting up the whole chain such that you actually wind up with money in your own bank account without also setting up a big neon Arrest Me financial trail.
Not even malware gets proper QA these days....
When I read stuff like "Petya (binary edited)" I feel like a complete noob. Anyone care to elaborate how editing binaries would be done?
Sounds like a daunting task. Even on a normal program. Much more so on malware that is obfuscated to begin with. Just curious :-)
At any rate in general it just means that the binary version is directly modified instead of, say, modifying the source and recompiling it. When the source is not available you don't really have a choice.
It doesn't mean however that you'll just open a big binary dump of the program in emacs and start flipping bits manually. In general you'll first disassemble the code to figure out what it does, isolate the part that you want to modify, implement the modification and then you end up with a binary patch.
That's easier said than done though, reverse engineering a complex binary is very time consuming.
It reminded me of this anecdote: https://en.wikipedia.org/wiki/Wing_Commander_%28video_game%2...
>As development for Wing Commander came to a close, the EMM386 memory manager the game used would give an exception when the user exited the game. It would print out a message similar to "EMM386 Memory manager error..." with additional information. The team could not isolate and fix the error and they needed to ship it as soon as possible. As a work-around, one of the game's programmers, Ken Demarest III, hex-edited the memory manager so it displayed a different message. Instead of the error message, it printed "Thank you for playing Wing Commander."
And still ppl who crack games do it very often. They start with a obfuscated binary, decrypt it and patch it to remove the protection.
Very different from trying to figure out everything a program does.
Surely this is easier then a full understanding of the code?
CPUs have a fixed instruction set. Add, subtract, increment by 1, and so on. These instructions in turn are represented in machine language as a binary string, which represents signals that get sent to the CPU's processing center, the ALU (Arithmetic Logic Unit). The ALU has a number of input ports, with each one corresponding to a different fundamental operation.
There are a number of programs capable of taking an executable and providing a step-by-step breakdown in machine language (which makes sense intuitively because the machine has to do this for itself anyway in order to execute the program). So once you have the machine language instructions, you then study it to see what different sets of instructions are doing. This is made somewhat easier by the fact that computers run through instructions linearly (with the exception of jumps, but you also know that jumps represent some sort of logic operating on input, so those are informative as well).
Although this would take forever to do manually, there are programs that aid in breaking machine language into easier-to-understand chunks, like IDA.
Anyway, once you understand what different chunks of instructions are doing, then you can decide how you want to alter the program. You can use a hex editor for the actual editing (I assume professionals use something different, but some game modders use hex editors), which simply lets you change the individual bits on your drive (if this sounds impressive, realize that every time you save a file or something, that's what's going on at a large scale).
If you want a gentle, newbie-friendly introduction to CPUs which will make a lot of this stuff click better, I highly recommend the NAND to Tetris course, which has a video series on Coursera: https://www.coursera.org/learn/build-a-computer
There's probably a way to try it with tools you already know. Know vim for example?
cp /bin/grep ./mygrep
vim -b ./mygrep
[find a string to change, like something from the output of ./mygrep -V]
[don't change the length]
[change a few letters]
<esc>: %s/Free Software/Tree Software/g
Then you need to have an idea of the executable file format so that you can extract information from the respective file sections.
Of course, there are tools that will extract those sections. So manual work only occurs if the tools fail to do their work.
In the case of executables, reverse engineering tools like IDA give an helping hand.
Then it goes from there, with lots of Assembly love and knowledge of OS internals.
Radare is a free disassembler.
Hopper is good a good disassembler for Mac.
IDA is great, but very expensive.
Manual work happens almost always with weird malware and or packers. They almost always do something that makes trivial reversing harder.
If we open a file in a hex-editor, we may locate an embedded string, like this:
0180: 54 68 69 73 20 69 73 20 61 20 73 74 72 69 6E 67 00 This is a string.
Now we may obviously change some of the string, and even shorten it, by filling the rest by zero-bytes:
0180: 54 68 69 73 20 69 73 20 61 20 70 65 74 00 00 00 00 This is a pet....
The interesting thing about this is that we may change the content, but have to maintain the original length and order of the code, else the binary won't work any more. I guess, padding, like this, is what gives the editing away -- at least at the level of arguments and embedded data. (However, if there were some hash signatures checked by the runtime, we will run into some trouble with our edit.)
Just the same, we may edit any instruction code. Let's say, your hex-editor has a built-in disassembler module, displaying mnemonics next to the byte code, just like the ASCII text in the string example. Even while some of the code may be encrypted, there must be some top-level code which isn't, and we should be able to discern this from any obfuscated code. Now, say, we want to skip a call to a subroutine or module, by overwriting the call instruction by a few bytes representing a jump instruction to skip ahead. Notably, again, we'll have to maintain the overall length and byte order, leaving behind some unused bytes as a signature of this being edited code.
Historical note: Classic MacOS (up to System 9) used a separate resource fork for any content embedded in files and executables. There was also a free tool by Apple, ResEdit, for displaying and editing the various resources and so-called res-hacks were not uncommon. (E.g., you may have accessed the resource providing the label for a menu item and replace it by your own, etc. This worked generally great with most of the programs, while some rather expensive software obviously applied some checks, prohibiting edited versions from working.) There was also a disassembler module for ResEdit, allowing code edits like described above.
Gives pretty good insight into what steps go into this kind of work.
To get started reverse engineering, modifying binaries, linking, etc. you need to start with learning x86_64 assembly. There are some pretty good courses and tutorials online. Since there are only a few opcodes that are used frequently, it might help to search for "reverse engineering bomb lab" and go from there. Here is the first search result, maybe it is good, maybe not: http://zpalexander.com/binary-bomb-lab-phase-1/
It can something as simple as changing several bytes using a hex/bin editor or something more involved like disassembling the binary, patching the assembly and then assembling it back.
What about "have them publish a specially crafted transaction in Bitcoin blockchain using provided software"?
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)
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:
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
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.
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.
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.
I hope this field doesn't get too poluted by people looking for a thrill. The stakes start to be too high for that.
"It's sometimes the height of wisdom to feign stupidity.” -Cato 149 B.C. (that's right, people knew about this simple trick before Jesus was born, you bet humanity has refined on it since)
We forget there's more to attribution than what can be determined from the bits.
Yet no evidence is provided. Why would they want to hide it?
"Some of the payloads utilized by the network propagation component have compilation timestamps from February 2017. The compilation dates on these payloads don’t have any bearing on when the Eternal* exploits were implemented in the network propagation code."