{
	"id": "15bb1441-9879-4206-bd60-4acc72375e27",
	"created_at": "2026-04-06T00:19:13.664535Z",
	"updated_at": "2026-04-10T13:12:23.466943Z",
	"deleted_at": null,
	"sha1_hash": "21427719aeec5aef0b5762e392899f01746300be",
	"title": "Floki Bot and the stealthy dropper | Malwarebytes Labs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 305110,
	"plain_text": "Floki Bot and the stealthy dropper | Malwarebytes Labs\r\nBy Malwarebytes Labs\r\nPublished: 2016-11-09 · Archived: 2026-04-05 14:34:24 UTC\r\nFloki Bot, described recently by Dr. Peter Stephenson from SC Magazine, is yet another bot based on the leaked\r\nZeus code. However, the author came up with various custom modifications that makes it more interesting.\r\nAccording to the advertisements announced on the black market, this bot is capable of making very stealthy\r\ninjections, evading many mechanisms of detection. We decided to take a look at what are the tricks behind it. It\r\nturned out, that although the injection method that the dropper uses is not novel by itself, but it comes with few\r\ninteresting twists, that are not so commonly used in malware.\r\nAnalyzed sample\r\n5649e7a200df2fb85ad1fb5a723bef22 – dropper \u003c- main focus of this analysis\r\ne54d28a24c976348c438f45281d68c54 – core module –  bot 32bit\r\nd4c5384da41fd391d16eff60abc21405 – core module –  bot 64bit\r\nNOTE: The core modules depend on a data prepared by the dropper and they crash while run independently.\r\nThe Floki Dropper\r\nThe Floki dropper looks simple and it has been found in wild without any outer protection layer. It has 3 resources\r\nwith descriptive names – bot32, bot64, and key:\r\nWhen we try to observe its activity, we can see it making an injection into explorer.\r\nIndeed, when we attach the debugger to the newly created explorer process, we can see some alien\r\ncode implanted – it is written on three additional memory areas with full permissions (RWE):\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/11/floki-bot-and-the-stealthy-dropper/\r\nPage 1 of 8\n\nHowever, when we trace the API calls, we cannot find any reference to a function that will write the code into the\r\nexplorer process. Fragment of the trace:\r\n[...] 28a8;called module: C:Windowssystem32kernel32.dll:CreateProcessW 210f;called module: C:Windowss\r\nWe can see that a new process is created, and it’s context is being changed – that suggests manipulation – but\r\nwhere is the write? In order to find an answer to this question, we will take a deep dive inside the code.\r\nInside\r\nAt the beginning, the dropper dynamically loads some of the required imports:\r\nThe used approach depicts, that the author was trying not to leave any artifacts that could allow for easy detection\r\nof what modules and functions are going to be used. Instead of loading DLLs by their names, it picks them\r\nenumerating all the DLLs in the system32 directory:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/11/floki-bot-and-the-stealthy-dropper/\r\nPage 2 of 8\n\nFor the sake of obfuscation, it doesn’t use string comparison. Instead, it calculates a checksum of each found\r\nname. The checksum is created by CRC32 from the name XORed with some hardcoded value, that is constant for\r\na particular sample (in the described sample it is 0x58E5):\r\nThe resulting checksums are compared with the expected value, till the appropriate module is found and loaded. In\r\nsimilar way the export table of a particular module is enumerated and the required functions are being resolved.\r\nAfter the initial imports load, exactly the same method is used to search NTDLL.DLL.\r\nAs we know, NTDLL.DLL provides an interface to execute native system calls. Every version of Windows may\r\nuse a different number of a syscall in order to do the same thing. That’s why it is recommended to use them via\r\nwrappers, that we can find among functions exported by NTDLL. For example, this is how the implementation of\r\nthe NtAllocateVirtualMemory may look on Windows 7:\r\nAnother variant, from Windows 8 looks a bit different:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/11/floki-bot-and-the-stealthy-dropper/\r\nPage 3 of 8\n\nThe common part is, that the number of the syscall to be executed is moved into the EAX register. The dropper\r\nloads NTDLL into the memory and extracts syscalls from selected functions:\r\n0 : NtCreateSection 1 : NtMapViewOfSection 2 : ZwAllocateVirtualMemory 3 : ZwWriteVirtualMemory 4 : N\r\nIt checks a beginning of each function’s code by comparing it with 0xB8, that is a bytecode for moving a value\r\ninto EAX:\r\nIf the check passed, the syscall value, that was moved into EAX, is extracted and stored in a buffer:\r\nThen, when the dropper wants to call some of the functions, it uses those extracted values. The number of the\r\nsyscall is fetched from the array where it was saved, and copied to EAX. Parameters of the function are pushed on\r\nthe stack. The pointer to the parameters is loaded into EDX – and the syscall is triggered by with the help of an\r\ninterrupt – INT 0x2E:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/11/floki-bot-and-the-stealthy-dropper/\r\nPage 4 of 8\n\nThat’s how the functions NtCreateSection, NtMapViewOfSection  and NtResumeThread are being called. Those\r\nwere the missing elements of the API calls’ trace, so it explains a lot!\r\nExample 1 –  dropper makes a call that is the equivalent of calling the function NtCreateSection:\r\nExample 2 – the dropper mapped a section by using a syscall – it is an equivalent of calling the function\r\nNtMapViewOfSection:\r\nOnce the memory is prepared, the shellcode is copied there:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/11/floki-bot-and-the-stealthy-dropper/\r\nPage 5 of 8\n\nAfter the preparations, those sections are mapped into the context of the explorer process, that has been created as\r\nsuspended. Using SetThreadContext, it’s Entry Point is being redirected to the injected memory page. When the\r\nexplorer process is being resumed, the new code executes and proceeds with unpacking the malicious core.\r\nAt this point of the injection, it’s malicious core is not yet revealed – it’s decryption process takes place inside the\r\nshellcode implanted in the explorer. This is also additional countermeasure that this dropper takes against\r\ndetection tools.\r\nAnother trick that this bot uses, is a defense against inline hooking – a method utilized by various monitoring\r\ntools. All the mapped DLLs are compared with their raw versions, read from the disk by the dropper. If any\r\nanomaly is detected, the dropper overwrites the mapped DLL by the code copied from it’s raw version. As a\r\nresults, the functions are getting “unhooked” and the monitoring programs are loosing the trace on the executed\r\ncalls. Example from Cuckoo – the unhooking procedure was executed after calling NtGetThreadContext – as a\r\nresult the sandbox lost control over executed calls:\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/11/floki-bot-and-the-stealthy-dropper/\r\nPage 6 of 8\n\nConclusion\r\nThe illustrated concept is not novel, however it was utilized in an interesting way. Many programs\r\ndetect malicious activity by monitoring API calls, that are most often misused by malware. Also,\r\napplications used for automated analysis hooks API functions, in order to monitor where and how\r\nthey are being used. The presented method allows to bypass them – at the same time being\r\nrelatively easy to implement.\r\nIn this case, the author didn’t use the full potential of the technique, because he could have implement all the\r\ninjection-related functions via direct syscalls – instead, he chose to use only some subset, related to writing into\r\nremote memory area. Some other syscalls has been loaded but not used – it may suggest that the product is still\r\nunder development. Creation of the new process and changing it’s context still could be detected via API\r\nmonitoring – and it was enough to rise alerts and make the dropper less stealthy than it was intended.\r\nAppendix\r\nhttps://www.evilsocket.net/2014/02/11/on-windows-syscall-mechanism-and-syscall-numbers-extraction-methods/\r\n– On Windows Syscall Mechanism and Syscall Numbers Extraction Methods\r\nThis was a guest post written by Hasherezade, an independent researcher and programmer with a strong interest\r\nin InfoSec. She loves going in details about malware and sharing threat information with the community. Check\r\nher out on Twitter @hasherezade and her personal blog: https://hshrzd.wordpress.com.\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/11/floki-bot-and-the-stealthy-dropper/\r\nPage 7 of 8\n\nSource: https://blog.malwarebytes.com/threat-analysis/2016/11/floki-bot-and-the-stealthy-dropper/\r\nhttps://blog.malwarebytes.com/threat-analysis/2016/11/floki-bot-and-the-stealthy-dropper/\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://blog.malwarebytes.com/threat-analysis/2016/11/floki-bot-and-the-stealthy-dropper/"
	],
	"report_names": [
		"floki-bot-and-the-stealthy-dropper"
	],
	"threat_actors": [],
	"ts_created_at": 1775434753,
	"ts_updated_at": 1775826743,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/21427719aeec5aef0b5762e392899f01746300be.pdf",
		"text": "https://archive.orkl.eu/21427719aeec5aef0b5762e392899f01746300be.txt",
		"img": "https://archive.orkl.eu/21427719aeec5aef0b5762e392899f01746300be.jpg"
	}
}