Floki Bot is a new malware variant that has recently been offered for sale on various darknet markets. It is based on the same codebase that was used by the infamous Zeus trojan, the source code of which was leaked in 2011. Rather than simply copying the features that were present within the Zeus trojan "as-is", Floki Bot claims to feature several new capabilities making it an attractive tool for criminals. As Talos is constantly monitoring changes across the threat landscape to ensure that our customers remain protected as threats continue to evolve, we took a deep dive into this malware variant to determine the technical capabilities and characteristics of Floki Bot.
During our analysis of Floki Bot, Talos identified modifications that had been made to the dropper mechanism present in the leaked Zeus source code in an attempt to make Floki Bot more difficult to detect. Talos also observed the introduction of new code that allows Floki Bot to make use of the Tor network. However, this functionality does not appear to be active for the time being. Finally, through the use of the FIRST framework during the analysis process, Talos was able to quickly identify code/function reuse between Zeus and Floki Bot. This made sample analysis more efficient and decreased the amount of time spent documenting various functions present within the Floki Bot samples we analyzed.
Talos worked in collaboration with Flashpoint during the analysis of Floki Bot. This collaborative effort allowed Talos and Flashpoint to quickly communicate intelligence data related to active campaigns distributing Floki Bot as well as data regarding the technical functionality present within the malware. Additionally, Talos is making scripts available to the open source community that will help malware analysts automate portions of the Floki Bot analysis process and make the process of analyzing Floki Bot easier to perform.
Floki Bot Details
The infection process used by Floki Bot is comprised of several steps. At a high level, this process is illustrated in the following diagram:
Figure 1: Inject Sequence of Malware Code
We started our analysis of Floki Bot using the following binary:
Once the malware is executed, it attempts to inject malicious code into 'explorer.exe' - the Microsoft Windows file manager. If it is unable to open 'explorer.exe', it will then inject into 'svchost.exe'. The first injection is simply a trampoline (step one in Figure 1). This trampoline performs two different calls. The first call is a 'Sleep()' for 100 milliseconds. The second call passes control to another payload function. The argument to that function is a structure with the initial sample's process ID, the decryption key for further binary payloads, and the pointer and size of the payload resource in the initial sample's address space. Curiously enough, though the initial sample has resources labeled 'bot32' and 'bot64', the sample we analyzed is hardcoded to only pass the address of the 'bot32' resource to the injected payload. The reversed code responsible for mapping the 'bot32', 'bot64' and 'key' resources is shown in Figure 2.
Figure 2: Mapping of 'bot32', 'bot64' and 'key' Resources
As you can see from the following screenshots, Figure 3 shows the code responsible for preparing the shellcode for the injection. This operation is performed in the initial binary. Figure 4 shows the result of the injection into the 'explorer.exe' process. We can clearly observe that the disassembly is based on the previous shellcode and contains the two calls described above. Specifically, the call at 0xA001F invokes the payload, which is the step two in Figure 1.
Figure 3: Shellcode Preparation
Figure 4: Disassembly of the Injected Shellcode
The next logical step is another injection which also happens within the 'explorer.exe' address space. This time the payload - the one executed after the trampoline - resolves the required APIs via the use of a CRC lookup and then maps the 'bot32' resource section from the initial binary.
The resource is encrypted with RC4, and can be decrypted with the 16 byte key data from the 'key' resource, which is passed as an argument to the injected code. Moreover, the resource is compressed with the LZNT1 algorithm, and is extracted by invoking RtlDecompressBuffer. Talos has created and is releasing a script called 'PayloadDump' which will extract these bot payloads. This bot is the final component and is the one containing the banking trojan functionality. It is flagged by many AV engines as a classic Zeus bot. The bot is loaded and injected into 'explorer.exe'. These steps are the labeled 3 and 4 in Figure 1.
At every stage, the malware uses hashing to obfuscate module and function names used in dynamic library resolution. Interestingly, the initial sample and the bot (bot32) executable use the same CRC32 implementation and XOR the result with a static key, in our case this was 0x5E58, while the payload uses the same CRC32 implementation but a different XOR key, in our case 0x3086. The names of the modules are converted to lowercase before the computation (Windows file names are traditionally case insensitive).
Currently, the 'bot32' resource is immediately recognized by more than 30 AV engines on Virustotal, with most of the detections identifying it as Zbot, while the 'bot64' resource is detected as malicious by only 10 AV engines. During our analysis, we extracted the sample from both a physical memory dump of the explorer.exe process (See the Memory Analysis section), as well as from the resource section of the initial binary. At first glance, this sample looks like a normal Zeus bot. The main difference is support for the Tor network that should be activated when the C2 domain specified in the malware configuration ends with '.onion' which is the pseudo TLD for Tor related domains.. When this is the case, a standard Tor proxy server is configured to listen on localhost:9050, as you can see in the screenshot below:
Figure 5: Floki Bot Tor Functionality
This feature appears to be under development and could not be activated in the samples Talos analyzed.
Floki Bot's Dropper/Loader
The loader used by Floki Bot is not encrypted. It also does not utilize any anti-debugging techniques. The loader does hide the system calls used to inject the malicious payload into other processes. The injection technique used by the Floki Bot loader has already been thoroughly documented here so we will not go into significant detail on how that process works.
Floki Bot communicates with C2 over an HTTPS connection. Interestingly, the malware author advertises an anti deep packet inspection feature. To achieve this, the bytes in network packets are packaged in BinStorage structures that are sent over HTTPS. Each byte in the BinStorage structure is XOR'd by the previous byte and then additionally encrypted with RC4. This functionality was also present in the leaked Zeus source code and is not new to Floki Bot. By breaking the HTTPS connection and decrypting the packet payloads, we noticed that the malware sends back information about the infected machine such as the computer name and the screen resolution. Floki Bot claimed it "cannot be detected by Deep-Packet-Inspection unlike Zeus", but the only major change to the leaked source code is Tor support, which was not found to be used by any samples found in the wild. Talos was able to decrypt Floki Bot network packets after intercepting them using mitmproxy as the malware does not use certificate pinning for its communications.
During our analysis we also performed a memory-based forensic analysis after infecting a VM with Floki Bot. In this way we used an opposite approach, starting our analysis from the end and then trying to rebuild the different steps of the infection process. First, we took a physical memory dump with win32dd and analyzed it with Volatility - a famous open source memory forensics framework. First we used the 'pslist' Volatility plugin. This plugin lists all processes by walking the double linked list connecting all of the _EPROCESS objects. Nothing suspicious was found from its output. We then used the 'netscan' plugin and it showed network activity from the 'explorer.exe' process, which is something that needed more investigation as it is definitely not normal to have network traffic from the file manager. Based on this finding, we ran 'malfind' on the 'explorer.exe' process and identified interesting traces and the PE file injected into the process. We dumped these artifacts and they matched the partial results of the reversing process. We could observe the trampoline, the payload and the PE file. In relation to the persistence mechanisms employed by Floki Bot, we identified some artifacts using 'filescan' and observed that the binary (with a random name) was also copied into the Startup folder.
Collaboration with Flashpoint
During our investigation into the Floki Bot malware, we leveraged a collaborative relationship with Flashpoint, who we worked with to gather intelligence information and share technical details regarding the malware samples, the campaigns that are currently using Floki Bot, and the darknet markets on which Floki Bot is being bought and sold. Flashpoint has been tracking several Floki Bot actors and campaigns. Flashpoint has also released a blog post that contains relevant intelligence information related to currently active Floki Bot campaigns operating globally. The Flashpoint post can be found here.
Using FIRST to Analyze Floki Bot
During the analysis process, Talos leveraged the Function Identification and Recovery Signature Tool (FIRST) and associated IDA Python plugin to collect and document functionality present within the Floki Bot samples that were analyzed. FIRST is an open source framework recently released by Talos that allows malware analysts and researchers to collaborate and share analysis data related to the malicious functions present in malware samples.
Using FIRST enables quick and efficient analysis of malware as it minimizes the amount of time spent analyzing malicious code that has already been analyzed and documented. FIRST currently contains information for over 170,000 functions including: common libraries like Zlib and OpenSSL, leaked malware source code, and malicious Windows and Linux files analyzed by the community. It is particularly helpful when analyzing statically linked executables with thousands of library functions. Tools like Bindiff can be very useful, but they only let you compare a handful of files, and you have to find and obtain these files before you can do these comparisons. The FIRST plugin automatically looks for function similarities in each of the thousands of files submitted by the community.
IDA Pro uses FLIRT signatures to attempt to identify commonly used library functions, but it was unable to identify any functions in this sample of Floki Bot. IDA Pro's default response to unidentified functions is to name the functions according to the starting address. In this case we get 516 functions with generic names like "sub_402F34".
Figure 6: IDA Pro Function List before running FIRST
We queried FIRST, and within seconds had 128 functions labelled with meaningful names, prototypes, and comments. We can now instantly see what these functions do, and what arguments they take, even when those arguments are custom structures.
Figure 7: IDA Pro Function List after running FIRST
Many functions are difficult to classify without first analyzing their child-functions. Analysts often use a depth-first approach to label functions with obvious behaviors, then backtrack to the parent once they have a better understanding of the nested functions.
Figure 8: IDA Pro Showing Calls to Unknown Functions without FIRST
FIRST identified all of the functions in this example, and labeled them with their argument names and types. Functions now have comments showing these functions were from leaked Zeus source code, which gives us a substantial lead on where to find more info about the unidentified functions. Some functions not identified by FIRST are similar to functions in the Zeus source, but have been changed by modifications in the source code or compiler options.
Figure 9: The Same Function Labeled by FIRST
If you compared this Floki Bot executable with Zeus, you would see the sizes of the BASECONFIG structures are different, and the offsets for global variables have changed as well. One of FIRST's engines identified these functions despite modifications to these parameters. Thanks to FIRST, we are able to quickly find the chunk of leaked source code responsible for this function.
Figure 10: Leaked Function Source Code
All of the analysis data and function documentation that was created by Talos while analyzing Floki Bot samples have been made available via the public Talos FIRST server (beta). More information about the FIRST framework and how it can be used can be found here.
During the analysis process, Talos also created scripts to help automate portions of the analysis of Floki Bot, which are now being released to the open source community. These scripts enable analysts to dump the configuration parameters used by Floki Bot samples, as well as the Floki Bot payload itself.
PayloadDump - Extracts the final payload in PE32 format from the initial Floki Bot sample.
ConfigDump - Enables the extraction of the Floki Bot configuration parameters used by the sample.
These scripts can be downloaded from Github here.
Floki Bot is another example of what happens when the source code of successful malware kits gets leaked online. As we have seen several times since the Zeus source code became available, new malware variants based on this codebase continue to emerge. Floki Bot is unique in that the authors of this malware have put effort into expanding upon the functionality that was present in Zeus and have implemented new functionality making Floki Bot very attractive to criminals.
As Floki Bot is currently being actively bought and sold on several darknet markets it will likely continue to be seen in the wild as cybercriminals continue to attempt to leverage it to attack systems in an aim to monetize their efforts. As the leak of the Zeus source code continues to have ripple effects across the threat landscape, Talos will continue to monitor this and other threats that are actively being used in the wild to ensure that customers remain protected as new threats emerge or as existing threats change over time.
Additional ways our customers can detect and block this threat are listed below.
CWS or WSA web scanning prevents access to malicious websites and detects malware used in these attacks.
The Network Security protection of IPS and NGFW have up-to-date signatures to detect malicious network activity by threat actors.
Indicators of Compromise (IOCs)
Command and Control URLs: