Makerbot replicator 1 extruder upgrade
49 comments
Monero mining hardware comparison 2017
It is being spread via spam and exploit kits. Even though it is based on ZeuS, FlokiBot shows a lot of interesting improvements, new features like RAM scraping, a custom dropper, and seems to have borrowed some lines of code from the Carberp leak. FlokiBot and its dropper have many both standard and uncommon obfuscation techniques, we will focus on demystifying them and showing how to deobfuscate them statically using IDA and IDAPython scripts.
Since you find most of these techniques in a lot of recent malwares, I think it's a good exercise. I decided to take a look at FlokiBot after reading about its dropper in this nice article by hasherezade: While most articles on FlokiBot focus on its dropper, I will also try to get into a bit more details and talk about the FlokiBot payload ; we will see that it has some interesting features and is not your usual ZeuS rip-off, even though most of the code comes from the ZeuS and the Carberp leaks.
Still better than reversing ransomware anyway. VirusTotal Analysis , Hybrid-Analysis. The dropper loads its modules by hashing library names and comparing them with hardcoded hashes. Two methods were implemented to retrieve dll names: By doing so, only addresses of functions are visible to a debugger, making the analysis of the code pretty tough since we are not able to see which API are being called.
A way to deobfuscate this is shown below, in the next part. Another interesting thing by FlokiBot and the dropper is the way they call some functions of the native API. They are a bit different than other API in their implementation, as they make use of syscalls and more particularly the int 0x2e. The following screenshot shows how they are implemented in ntdll:. As we can see, the syscall value is put in eax 0x15 for NtAllocateVirtualMemory on my Windows 7 bit and arguments are passed through edx.
A full list of those syscall numbers for x86 and bit Windows can be found on this page: Here is what dwSyscallArray looked like on my VM, after all the syscall numbers were extracted by the dropper:. Whenever FlokiBot needs to call one of these native functions, it will call its own functions that directly retrieve the syscall number from the dwSyscallArray, pass arguments and trigger the interrupt 0x2E the same way it is implemented in ntdll.
This is why you won't see any call traces of these API and monitoring tools that hook them will be unable to monitor the calls. An interesting feature of FlokiBot is that both the dropper and the payloads have an unhooking routine.
The idea is to uninstall hooks written by monitoring tools, sandboxes and AV. Even though this is not the first time a malware uses such a feature, Carberp had one to hide from Trusteer Rapport and Carbanak more recently for example, it is pretty rare and worth noticing.
In this part I will describe how FlokiBot performs unhooking. First, FlokiBot gets a handle to the ntdll. As a result, FlokiBot has two versions of the lib mapped in its memory: Now that the correct permissions are set, FlokiBot pushes the address of the code section of the mapped clean DLL and the imported one and calls its unhooking routine.
Since it needs to overwrite some data in its memory to delete the hooks, the malware has to change memory protections of the imported NTDLL code export section. It does so by calling NtProtectVirtualMemory with an int 0x2E and the corresponding syscall it previously extracted 0x4D on my version of Windows.
We can see that a part of the code section becomes writable if a hook is spotted:. The unhooking function can be described with these three steps: As a consequence, most monitoring tools, AV and sandboxes will fail to keep track of the malware calls. This is particularly useful if you want to avoid automated analysis from online sandboxes like malwr.
The dropper has 3 resources with explicit names: For my sample, the key is:. You can find a Python script to dump the payloads and their config on the Talos Group Github here: Note that they don't execute properly on their own since they are supposed to be injected in a process and need some data written in memory by the dropper. We will describe this injection in the next part.
The dropper doesn't inject its payload into explorer. Instead, it writes and executes a shellcode that will decrypt and decompress the payload inside the process memory. That's unusual and interesting.
The dropping process is summed up by this picture by Talos Intelligence:. The first shellcode written in explorer. This second stage is the one responsible of extracting the bot payloads, decrypting and uncompressing them. All this happens in explorer. I implemented the hashing process in Python, verified that the two imported DLL are indeed kernel32 and ntdll, and adapted my Python script to parse their export table and try to resolve the API names the function is importing.
I ran the script and got the following API:. Finally, the context of the suspended remote thread is modified so that its EIP points on the first shellcode, and the thread is resumed.
The payload is based on the well-known and already analyzed ZeuS trojan so I won't detail everything. As for the dropper, I will focus on the deobfuscating parts and the improvements implemented in FlokiBot.
I ran the ConfigDump. First, we notice some important functions of the payload being reused from the dropper. Producing a Rizzo signature of the dropper and loading it in the payload allow IDA to identify and rename quite a few functions.
The idea is to reimplement the hashing process in Python, hash all API exported by the DLL FlokiBot loads, and then compare them with the hashes we collected in the code. If there is a match, we use IDAPython to rename the function, making the disassembly more and more readable.
Most of the interesting strings are encrypted using a XOR with their own one-byte key, which is similar to what ZeuS or Fobber Tinba evolution used. An encrypted string is represented by the following structure:. Here is the full Python script I wrote to deobfuscate the payload: It was designed for static analysis, you don't have to start any debugger for the script to work. It does the following:. The bot copies itself to C: Based on ZeuS, FlokiBot uses the same kind of structure array to store its hooks, with a slightly different structure:.
We end up with the following table:. Most of them are standard hooks installed by ZeuS and most banking malwares. We will see their uses in the next parts.
If the hash of the DLL that is being loaded by the browser matches with either hash of nss3. Chrome Webinjects are not implemented yet. Floki protects its hooks by putting a hook and filtering calls on NtProtectVirtualMemory to prevent tools like AV from restoring the original functions.
Obviously, this isn't very efficient since you can't constantly monitor the memory, you will miss on a lot of potential PAN in between scans. To overcome this issue, after Floki injected itself into a process, it will also puts a hook on NtFreeVirtualMemory so that it looks for track2 PAN whenever the process wants to free a chunk of memory and before it is actually freed.
This way, it is far likely to miss PAN. When it finds track2 data, Floki will try to identify issuers by looking at the beginning of the PAN. A full list of Issuer Identification Number can be found on this very informative page: Floki doesn't look at the whole IIN 6 digits but only checks the first digit and see if it matches with those issuers:.
Our string deobfuscation script helps identify the followind explicitly-named commands:. Cybercriminals have been using remote desktops more and more since ATS became way too complex to code and too hard to deploy. This way, they get a full access to an infected computer to learn about the target and its habits and perform fraudulent tasks such as money transfer manually.
FlokiBot is yet another malware kit based on ZeuS, with some pieces of code directly taken from the Carberp leak. Nevertheless, its dropper, its unhooking routine and its PoS malware feature make it an interesting malware to analyse. Also, its obfuscation techniques are simple enough to be reversed statically with some IDA scripts without making use of AppCall.