{
	"id": "640f6983-f94e-44b6-a686-e98b55b00f26",
	"created_at": "2026-04-06T00:15:40.017865Z",
	"updated_at": "2026-04-10T13:12:38.307546Z",
	"deleted_at": null,
	"sha1_hash": "2c1c85445621bb6908a80958839030683a8e0a2d",
	"title": "Digging into BokBot’s Core Module",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1445151,
	"plain_text": "Digging into BokBot’s Core Module\r\nBy Shaun Hurley - James Scalise\r\nArchived: 2026-04-05 14:09:00 UTC\r\nIntroduction\r\nBokBot, developed and operated by the actor named LUNAR SPIDER, was first observed in 2017 and the\r\nCrowdStrike’s Falcon® Overwatch™ and Falcon Intelligence™ teams have analyzed these infections to ensure\r\ncustomers are both protected and informed. Recently, BokBot infections have become more prevalent due to\r\ndistribution campaigns through the Emotet malware, which is associated with MUMMY SPIDER. The BokBot\r\nmalware provides robust functionality, such as:\r\nCommand and control of a system\r\nProcess execution\r\nRegistry editing\r\nWrite to the file system\r\nLogging\r\nPolymorphism and other obfuscations\r\nTamperProofing\r\nModular\r\nCredential theft\r\nIntercepting proxy\r\nRemote control via VNC\r\nIn addition, BokBot has been seen downloading and executing binary code from other malware families: for\r\nexample, the Azorult infostealer. This blog post will dig into the technical details of BokBot’s main module.\r\nSubsequent blog posts will cover the additional downloaded modules.\r\nBokBot Container Execution\r\nBokBot comes packed inside a crypter. The crypter goes through several stages before finally unpacking the\r\nBokBot binary and injecting it into svchost.exe. Here is a quick rundown of the different stages:\r\nStage 1 (crypter)\r\nDecode stage 2 and execute\r\nStage 2 (crypter)\r\nDecodes shellcode and execute\r\nStage 3 (shellcode)\r\nHollows out the base process image\r\nDecodes the core process injection PE\r\nOverwrites the base process image with the core process injection PE\r\nhttps://www.crowdstrike.com/blog/digging-into-bokbots-core-module/\r\nPage 1 of 23\n\nStage 4 (process injection)\r\nExecutes the process injection code\r\nLaunches svchost.exe child process\r\nInjects BokBot as a headless PE image into the child process\r\nAll of the behaviors relevant to the CrowdStrike® Falcon platform occur in stage 4. The primary focus for the\r\nfollowing section is the unique method in which BokBot is injected into the child process.\r\nProcess Injection\r\nIn order to bypass antivirus (AV) detections for process hollowing, BokBot hooks several Windows API functions,\r\nexecutes the hooking code, and then removes the hook.\r\nSimulating Process Hollowing\r\nIn order to simulate process hollowing, the ZwCreateUserProcess routine is hooked. BokBot calls\r\nZwProtectVirtualMemory to modify the permissions of the routine to PAGE_READWRITE . Next, the first five\r\nopcodes (bytes) are replaced with the opcodes for a JMP \u003caddress of hooking code\u003e instruction.\r\nPermissions are restored, and then CreateProcessA is called.\r\nFigure 1: Hooking ZwCreateUserProcess Once CreateProcessA is called, a function call chain leads to calling\r\nZwCreateUserProcess and then the hooking code, as shown in Figure 1. At this point, no process has been\r\ncreated. The hooking code will complete the creation of the child process by removing the hook from the\r\nZwCreateUserprocess routine, and then the non-hooked ZwCreateUserProcess procedure is called. This will\r\ncreate the child process, but execution doesn’t begin until CreateProcessInternal returns. The rest of the hook\r\nroutine will decode and inject the embedded BokBot binary into the child svchost.exe process.\r\nCode Injection\r\nhttps://www.crowdstrike.com/blog/digging-into-bokbots-core-module/\r\nPage 2 of 23\n\nPrior to injecting the code, the BokBot PE is decompressed and loaded into the local process memory. Once\r\nloaded, the following Windows procedures are used to allocate and write to the svchost child process:\r\nAfter the main BokBot module has been written to the child process, the steps to execute the BokBot code will\r\nbegin.\r\nCode Execution\r\nBokBot uses a novel technique to get the code to execute inside of the child process. Using the same APIs as\r\nearlier, the dropper hooks RtlExitUserProcess in the child process. Since svchost.exe is launched without\r\narguments, it will terminate immediately. As the process attempts to exit, it will call the hooked\r\nRtlExitUserProcess , thus executing the BokBot payload.\r\nFigure 2: Executing BokBot with RtlExitUserProcess Hook\r\nThere is one more task for the hooking routine to complete before CreateProcessInternalW resumes execution.\r\nInjecting a Context Data Structure\r\nhttps://www.crowdstrike.com/blog/digging-into-bokbots-core-module/\r\nPage 3 of 23\n\nAfter the BokBot payload is injected into the child process, a context data structure is written to the child process.\r\nThis context contains all of the data necessary to ensure that BokBot’s main module is able to execute without\r\nissue:\r\nWindows Procedure Addresses\r\nntdll.ZwAllocateVirtualMemory\r\nntdll.ZwWriteVirtualMemory\r\nntdll.ZwProtectVirtualMemory\r\nntdll.ZwWaitForSingleObject\r\nntdll.LdrLoadDll\r\nntdll.LdrGetProcedureAddress\r\nntdll.RtlExitUserProcess\r\nntdll.ZwCreateUserProcess\r\nntdll.RtlDecompressBuffer\r\nntdll.ZwFlushInstructionCache\r\nLoad address for payload\r\nPath to the dropper binary\r\nC2 URLs\r\nProject ID\r\nThis data is collected throughout the lifetime of the dropper process. In addition, a similar structure will be written\r\nto the child processes of BokBot as it downloads and execute modules. After injection, CreateProcessInternalW\r\nresumes, and the dropper process exits. BokBot’s main module starts the initialization phase.\r\nBokBot Initialization\r\nPrior to executing the primary loop to communicate with the C2, BokBot goes through several initialization steps\r\nto prepare itself for C2 communication. Initialization occurs in the following steps:\r\nRemove the RtlExitUserProcess hook\r\nCreate a memory-mapped file to store logging data\r\nExecute BokBot as the logged-on user (if the current process is running as System)\r\nSuppress error windows\r\nCollect System information\r\nWindows version information\r\nUser SID\r\nMember of a domain\r\nUnique ID generation\r\nPrevent multiple executions\r\nInstall BokBot on the host\r\nInject existing downloaded modules into child processes\r\nSome of these steps are covered in more details inside the following sections.\r\nhttps://www.crowdstrike.com/blog/digging-into-bokbots-core-module/\r\nPage 4 of 23\n\nSilence Errors\r\nTo prevent error windows from informing the victim of an issue, BokBot sets the error mode of the process to\r\n0x8007, which corresponds to the following:\r\nThis will disable most error notices that are generated when a process crashes.\r\nGenerating Unique IDs\r\nBokBot uses several unique IDS that are generated earlier on during process execution. These values are passed to\r\nthe C2 (command and control), used as a key for RC4, and passed to child processes.\r\nProject ID\r\nIn addition to injecting the main BokBot module into svchost, the dropper also injects a chunk of binary data that\r\nprovides context for BokBot to execute, including the Project ID. These unique Project ID values appear to be\r\nused to identify infections that correspond to distribution campaigns. The Project ID is a four-byte value.\r\nBot ID\r\nBot IDs are unique to specific instances for a user on an infected host. The value is used as an encryption key and\r\nas a seed in the generation of the unique values that BokBot needs for a variety of purposes, such as the generation\r\nof pseudo-random strings for file and event names. This will be discussed further in subsequent sections. The Bot\r\nID is generated in one of the two following ways:\r\nSecurity ID (SID) of the account name\r\nSystem time in a file time format\r\nSince both values are 64-bit, no matter which method is used, the value is split into two 32-bit chunks and\r\nXORed.\r\nID Hash\r\nIn addition to this Bot ID, a simple hash is generated that can be used to verify the validity of both the Bot ID and\r\nthe Project ID. This hash is generated using the Bot ID and the Project ID, in the following manner:\r\nhttps://www.crowdstrike.com/blog/digging-into-bokbots-core-module/\r\nPage 5 of 23\n\nThis value will be passed along with the Project ID and the Bot ID as part of the C2 URL parameters. If this\r\nrequest is invalid, infected hosts will not receive any instructions from the C2.\r\nC2 Hostname Initialization\r\nBokbot contains an encoded list of C2 hostnames that were provided as part of the context data structure that was\r\ninjected by the dropper. The C2 list within that structure is decoded using a key that was also provided by the\r\ncontext, and then re-encoded using a new key that was generated using an rdtsc instruction, and stored as an array\r\nof pointers.\r\nPrevent Multiple Executions\r\nA unique global named event is generated using the Bot ID. A successful call to CreateEvent is proceeded with a\r\ncall to GetLastError . If the malware is already executing, the last error is ERROR_ALREADY_EXISTS , and the\r\nprocess exits.\r\nInstallation\r\nDuring installation, the BokBot dropper binary is written to an installation directory, and a scheduled task is\r\ncreated for persistence. The installation directory is created in the following root directory:\r\nc:\\ProgramData\r\nThe installation directory name is unique and generated using the Bot ID. Once the directory is created, the\r\noriginal dropper file is renamed (also using the Bot ID as a seed) and written to the directory. Because the Bot ID\r\nis based on system information, using it as a seed ensures that the malware will always generate the same\r\ninstallation path and filename on a particular host. After generating the installation directory name, BokBot needs\r\nto generate a filename for the BokBot binary that is going to be written to that directory. The following Python\r\ncode reproduces the algorithm that BokBot uses to generate the filename, and various other strings.\r\nhttps://www.crowdstrike.com/blog/digging-into-bokbots-core-module/\r\nPage 6 of 23\n\nThe str_id value in the script is a hard-coded integer that is used with the Bot ID to generate consistent strings.\r\nFor instance, using a Bot ID of 0x2C6205B3 and str_id of 2 always results in ayxhmenpqgof , but switching to a\r\nstr_id of 6 results in bwjncm. The following is an example of the installation path: C:\\ProgramData\\\r\n{P6A23L1G-A21G-2389-90A1-95812L5X9AB8}\\ruizlfjkex.exe A scheduled task is created to execute at\r\nwindows logon. The task name is generated in the same manner as the installation directory:\r\nTask Name: {Q6B23L1U-A32L-2389-90A1-95812L5X9AB8}\r\nTrigger: Logon\r\nAction: Start a program\r\nDetails: BokBot dropper path\r\nC2 Communication\r\nBokBot communicates with C2 servers via HTTPS requests, passing various values to the server through URL\r\nparameters and via POST data. The URL request data is not encrypted or obfuscated beyond the SSL/TLS used by\r\nthe server. The following sections detail parameters required by all requests, some additional optional parameters,\r\nand the bot registration process.\r\nRequired C2 Request/Response Parameters\r\nEvery request/response will have these parameters sent to the server. These will provide the C2 with information\r\nthat identifies the request/response type and to uniquely identify the infected machine:\r\nTable 1 describes these parameters in greater detail.\r\nhttps://www.crowdstrike.com/blog/digging-into-bokbots-core-module/\r\nPage 7 of 23\n\nTable 1: Required URI Parameters\r\nThe URL path often changes between versions: For instance, version 100-102 used /data100.php instead of\r\n/in.php.\r\nAdditional C2 Request Parameters\r\nBokBot contains a communication thread that loops continuously until the process exits, retrieving instructions\r\nfrom the C2 server. These requests include several additional parameters, detailed in Table 2, in addition to those\r\nalready described. These parameters are not sent when a machine sends the result of a command issued by the C2,\r\nsuch as when uploading a screenshot.\r\nhttps://www.crowdstrike.com/blog/digging-into-bokbots-core-module/\r\nPage 8 of 23\n\nTable 2: Additional BokBot C2 Request URI Parameters\r\nThe following URL parameters showcase an example of the initial connection to the C2:\r\nIn this example, there are no web injects, no C2 URLs, and no modules have been downloaded, therefore the\r\nhighlighted parameters are either zero or empty. An initial timestamp has been generated, and the version number\r\nis static.\r\nInitial Bot Registration\r\nA registration request is combined with the standard C2 URL parameters that are sent to the C2 with each request.\r\nAfter the initial request, the C2 server will send commands back to the victim, signaling it to download web\r\ninjects, updated C2 hostnames, executable modules, or to perform other tasks. The initial registration URL\r\ncontains parameters related to system information. The following string is an example:\r\nhttps://www.crowdstrike.com/blog/digging-into-bokbots-core-module/\r\nPage 9 of 23\n\nTable 3 describes the registration URI parameters.\r\nTable 3: Registration Request URI Parameters\r\nThe following is an example of a registration request (in red) and a response from the C2 (in blue) containing\r\ncommands for the infected host:\r\nhttps://www.crowdstrike.com/blog/digging-into-bokbots-core-module/\r\nPage 10 of 23\n\nC2 Commands\r\nThis section will cover the command requests made by the C2. Each command from the C2 takes the following\r\nformat:\r\nThe following commands are available in the current version of BokBot:\r\nhttps://www.crowdstrike.com/blog/digging-into-bokbots-core-module/\r\nPage 11 of 23\n\nNote that these command ID values may change between versions. As this list demonstrates, BokBot provides\r\noperators with a wide variety of options to interact with an infected machine.\r\nURL Download Command Handler\r\nA lot of commands trigger a command handler function that requires communication with either a C2 URL or\r\nanother URL specified in the server request arguments. If specified by the request, the data downloaded from the\r\ntarget URL will be written to a DAT. Whether or not the downloaded data is written to a DAT file, it will always\r\nbe processed by a callback function for one of the following C2 commands:\r\nStart a new executable module, restart current executable module\r\nUpdate web injects (either command)\r\nUpdate config\r\nUpdate BokBot\r\nWrite to a file\r\nDownload and execute a binary\r\nThe commands that use the C2 URL hostnames send a d URL parameter, such as the following example:\r\nThis value is typically set to 0; the file to download is specified by the g parameters.\r\nModules and DAT Files\r\nhttps://www.crowdstrike.com/blog/digging-into-bokbots-core-module/\r\nPage 12 of 23\n\nAll data received from the C2 that needs to persist between reboots is written out as a DAT file on the infected\r\nmachine. These files include:\r\nWeb inject configuration\r\nC2 configuration\r\nExternal modules\r\nEach file is encrypted and decrypted as needed by either the main module or the child module, using the Bot ID as\r\nthe key. Each module is given a unique tag.\r\nUnique Tag Generation\r\nBokBot assigns unique tag values for injected processes, downloaded modules, and the downloaded DAT files.\r\nThese tags are a convenient method for the executing BokBot process to identify external process resources. Tag\r\ngeneration is simple:\r\n18 – Web injects configuration file, statically defined in the binary\r\n19 – Reporting configuration file, statically defined in the binary\r\n20 – C2 configuration file, statically defined in the binary\r\n33-46 – Downloaded modules to be injected into child processes\r\nAssigned as needed in an incremental fashion\r\nNot necessarily a unique tag for what the module does\r\nDuring analysis of BokBot, these values will come up on a regular basis, including values to generate a unique\r\nfilename, as described later.\r\nDownloading DAT Files\r\nAs previously mentioned, DAT files are downloaded based on commands sent from the C2. Once the command is\r\nreceived from the C2, a command handler specific to this command is called to process the request. In response,\r\nthe infected machine notifies the C2 with the command that it is ready to receive an RC4-encrypted blob from the\r\nC2. Figure 3 illustrates the process of commands that download configuration files and modules.\r\nhttps://www.crowdstrike.com/blog/digging-into-bokbots-core-module/\r\nPage 13 of 23\n\nFigure 3: C2 Command to Trigger DAT File Download\r\nAn eight-byte RC4 key is prepended to the data buffer. Prior to writing the BLOB to a file, BokBot decrypts the\r\nfile, and then re-encrypts it using a new RC4 key based on the Bot ID.\r\nWrite to a File\r\nBokBot creates a new directory under C:\\ProgramData to store the DAT files. The directory name is generated\r\nusing the string generation algorithm described previously. DAT file names are generated using the unique tag\r\nvalue. This value is run through a string generation algorithm (also dependent on the Bot ID), which returns a\r\nunique filename for the DAT file.\r\nTable 4: Example of BokBot DAT Files Written During Analysis\r\nTable 4 references all of the DAT files that were written during the testing process used for writing this blog. In\r\nthis case, the installation directory is C:\\ProgramData\\yyyyyyyyiu\\. These DAT files are further handled based on\r\nthe specified type, depending on whether it is an executable module or a data file.\r\nExecutable Module\r\nhttps://www.crowdstrike.com/blog/digging-into-bokbots-core-module/\r\nPage 14 of 23\n\nBokBot has several executable modules that can be downloaded and injected into a svchost.exe child process.\r\nOnce the relevant DAT file is decoded using RC4, no additional decoding or decompression is necessary for the\r\nexecutable module DAT files. The executable module header contains information necessary to ID the module:\r\nThe rest of the file contains data necessary to load and execute the module, including the various portions of a PE\r\nfile along with a custom PE header.\r\nModule Injection and Execution\r\nExecutable modules are injected with a technique similar to the dropper, minus the hook of\r\nZwCreateUserProcess , and the child process start is suspended ( CREATE_SUSPENDED ). It’s a little closer to\r\ntraditional process migration with the addition of the RtlExitUserProcess hook.\r\nPE Image Loading\r\nBecause there is no standard PE header, the DAT file has to contain all of the relevant information (virtual sizes,\r\nrelocations, etc.) to properly map this binary into the child process. This data is part of the header of the DAT file.\r\nBokBot builds the binary in local process memory prior to injecting it into the child process.\r\nInjection\r\nInjection uses the same APIs as the dropper: ZwAllocateVirtualMemory, ZwWriteVirtualMemory,\r\nZwProtectVirtualMemory. After injection the process is resumed using ResumeThread.\r\nExecution Context Injection\r\nOnce again, an execution context structure is written to the child process, prior to execution. Some of the\r\ninformation contained in this context includes:\r\nBot ID\r\nProject ID\r\nC2 hostnames\r\nA URL path format string\r\nThis keeps everything consistent between the parent and child process. No new unique identifiers need to be\r\ngenerated, all of the encryption keys are going to be the same: same hostnames, and even the same URL path.\r\nConsistency between parent and child is necessary for the messages sent between the two, using inter-process\r\nhttps://www.crowdstrike.com/blog/digging-into-bokbots-core-module/\r\nPage 15 of 23\n\ncommunication (IPC). After a module is injected into a child process, the first four bytes of the decrypted DAT file\r\nare added to an array, used by BokBot to identify which modules are currently executing.\r\nData Files\r\nThe other DAT files contain data necessary to either communicate with a C2, or related to web injection.\r\nEssentially, these files provide whatever additional data the main BokBot process and the executable modules\r\nrequire to accomplish their job.\r\nConfig File\r\nThe config file contains all of the data necessary for the BokBot main module to maintain communication with the\r\nC2. Once the file is decrypted using the process-specific RC4 key, no additional decompression or decryption is\r\nnecessary.\r\nSignature Verification\r\nEach config file comes with a digital signature block, used to verify the integrity of the C2 hostname data. The\r\nsignature is verified based on the signature verification method outlined in the obfuscations section. The following\r\nis an example C2 configuration, with the signature block in red:\r\nWeb Inject Files\r\nThere are multiple web inject files. One contains all of the target URL and hostname data, and the second contains\r\nregex patterns, as well as the code to inject. These files are both RC4-encrypted and compressed.\r\nhttps://www.crowdstrike.com/blog/digging-into-bokbots-core-module/\r\nPage 16 of 23\n\nThese files are not parsed by the main BokBot binary, but rather by the intercepting proxy module. The zeus file\r\nmagic is verified, a buffer is allocated, and then the files are decompressed. A forthcoming blog post on the proxy\r\nmodule will cover decompression and usage of the web injection configuration files.\r\nCommunication with Child Processes\r\nMemory-mapped files and events are used by BokBot to communicate with all child processes that contain an\r\ninjected module. Through the process of leveraging named events with CreateEvent, OpenEvent , and\r\nOpenFileMapping , the BokBot main module is able to provide additional information to these child processes.\r\nShared Module Log\r\nModules write to the same shared memory-mapped file. The memory-mapped file is created using a shared name\r\nbetween the parent and child processes. Each process that can generate this name can use it to open the memory-mapped file, and to write data to the shared modules log. Further details are covered in the next section, and\r\nspecific data written will be covered in the separate module descriptions below. The main module is responsible\r\nfor clearing the log and sending the data to the C2.\r\nModule-Specific Communication\r\nBokBot’s main module often needs to issue commands to the child processes that contain injected module code.\r\nThe commands can trigger an update of module-specific data, or instruct the module to perform a specific\r\nfunction, such as harvest data from Outlook. Figure 4 outlines this process, although it will be further explained in\r\nthe subsequent sections.\r\nhttps://www.crowdstrike.com/blog/digging-into-bokbots-core-module/\r\nPage 17 of 23\n\nFigure 4: BokBot Communication Between Parent and Child Processes\r\nEvent Name Generation\r\nIn order for the BokBot main modules and the child process to communicate with events, unique names need to be\r\ngenerated and must consistent across all of the processes. Table 5 illustrates BokBot’s approach.\r\nhttps://www.crowdstrike.com/blog/digging-into-bokbots-core-module/\r\nPage 18 of 23\n\nTable 5: Event Name Structure\r\nThese events will be used by the parent and child processes to exchange data.\r\nBokBot Main Module\r\nThis process has the ability to communicate with all of the children of the injected modules. These communication\r\nall revolve around commands generated by the C2. Once a command that requires notification of an executable\r\nmodule child process is initiated, a named Q event is opened to ensure that the child process is ready to receive\r\nthe data. If this Q event does not exist, then the child process has not been started. BokBot injects the target\r\nmodule into a child process, and loops a check to see if the event can be opened. Once the Q event has been\r\nsuccessfully opened, BokBot creates a new named R event, creates a memory-mapped file (named M event),\r\nwrites data to the file, signals the open Q event, and waits for a response from the child process. After the child\r\nclears the R event, the memory-mapped file is unmapped, and all handles are closed.\r\nBokBot Executable Module\r\nAfter initialization, the child process will create a named Q event and wait until it is signaled by the parent\r\nprocess. Once signaled, the named R event is opened, and the data in the memory-mapped file is processed.\r\nData from the BokBot Parent\r\nBokBot’s main module writes some contextual information to the injected module, telling it to perform specific\r\nactions. These actions change based on the module receiving the data. The following commands are consistent\r\nbetween modules, but the actions performed may vary:\r\n0xFF00: Process exit with a 0x1122 code\r\n0xFF01: Check web injects or no operation\r\n0xFF02: Update C2 hostnames\r\nIn addition to a command, relevant data associated with a command is also processed based on whatever\r\ninstruction the command tells the injected module to accomplish. After the task assigned by the parent process has\r\ncompleted, the memory mapped file is unmapped, the R event is signaled, and all other open events are closed.\r\nObfuscations and TamperProofing\r\nBokbot uses several methods to obfuscate analysis:\r\nString obfuscation\r\nEncrypted DAT files from the server\r\nhttps://www.crowdstrike.com/blog/digging-into-bokbots-core-module/\r\nPage 19 of 23\n\nSignature verification\r\nPolymorphism\r\nString Obfuscation\r\nTo make analysis more difficult, significant strings have been XOR encoded using a shifting key algorithm. All\r\nencoded strings have the following structure:\r\nHere is the algorithm to decode the string (Python):\r\nSignature Verification\r\nSignature verification occurs under two circumstances: updated C2 urls, and updated BokBot binary. In both\r\ncases, the process is the same. The verification function receives two things: a 128-byte signature to verify, and\r\nthe data to verify. First, BokBot creates an MD5 hash of the data requiring verification. Next, an RSA public key\r\nembedded in the executing binary is importing via CryptImportKey . Once the hash is generated and the key\r\nimported, CryptVerifySignature is used to verify the signature. This may be an attempt to prevent some third\r\nparty from taking over or otherwise disrupting the botnet.\r\nPolymorphism\r\nEverytime BokBot is installed, prior to it being written to the install directory, the .text section of the binary is\r\nmodified with junk data and the virtual size is updated. A new checksum is generated to replace the current\r\nchecksum.\r\nhttps://www.crowdstrike.com/blog/digging-into-bokbots-core-module/\r\nPage 20 of 23\n\nHow CrowdStrike Falcon® Prevent™ Stops BokBot\r\nBokbot spawns a svchost child process, injects the main module, and that svchost process spawns and injects into\r\nmultiple child processes. The process tree in Figure 5 is an example of what BokBot looks like when process\r\nblocking is disabled in Falcon Prevent. As can be seen, several malicious child processes were launched by\r\nBokBot’s main module located inside of the first svchost process.\r\nFigure 5: BokBot Process Tree Without Process Blocking Enabled Without preventions enabled the customer will\r\nstill be notified of the malicious activity, but no action will be taken to prevent the behavior.\r\nSuspicious Process Blocking\r\nFalcon has the capability to prevent the execution of BokBot’s main module and all of the child modules. Turning\r\non process blocking in Falcon Prevent kills the BokBot infection at the parent svchost process. Looking at the\r\nprocess tree in the Falcon UI with process blocking enabled, shows an analyst that the svchost process was\r\nprevented. The block message (see Figure 7) that occurs with this preventative action explains why this process\r\nwas terminated.\r\nhttps://www.crowdstrike.com/blog/digging-into-bokbots-core-module/\r\nPage 21 of 23\n\nFigure 6: BokBot Process Tree with Process Blocking Enabled\r\nFigure 7: BokBot Process Block Message\r\nSuspicious process blocking is an example of malware prevention based on behavior. If the malware uses behavior\r\nthat has not been caught by Falcon’s indicators of activity, then Falcon can also prevent malware execution by\r\nleveraging either next-generation AV machine learning ,or intelligence collected by Crowdstrike’s Falcon\r\nIntelligence team.\r\nIn Summary\r\nBokBot is a powerful banking trojan that provides attackers with a robust feature set. One of the more unique\r\nfeatures of BokBot is the method in which it uses to communicate with its child modules. Additional blog posts\r\nfor BokBot are coming that will contain more information for the downloaded modules.\r\nBokBot Hashes\r\nThe following hashes were used in creation of this blog post.\r\nMITRE ATT\u0026CK Framework Mapping\r\nhttps://www.crowdstrike.com/blog/digging-into-bokbots-core-module/\r\nPage 22 of 23\n\nAdditional Resources\r\nRead a Security Intelligence article: “New Banking Trojan IcedID Discovered by IBM X-Force Research.”\r\nRead a Talos Blog: “IcedID Banking Trojan Teams up with Ursnif/Dreambot for Distribution.”\r\nDownload the 2018 CrowdStrike Services Cyber Intrusion Casebook and read up on real-world IR\r\ninvestigations, with details on attacks and recommendations that can help your organizations get better\r\nprepared.\r\nLearn more about CrowdStrike’s next-gen endpoint protection by visiting the Falcon platform product\r\npage.\r\nTest CrowdStrike next-gen AV for yourself: Start your free trial of Falcon Prevent™ today.\r\nSource: https://www.crowdstrike.com/blog/digging-into-bokbots-core-module/\r\nhttps://www.crowdstrike.com/blog/digging-into-bokbots-core-module/\r\nPage 23 of 23",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.crowdstrike.com/blog/digging-into-bokbots-core-module/"
	],
	"report_names": [
		"digging-into-bokbots-core-module"
	],
	"threat_actors": [
		{
			"id": "42a6a29d-6b98-4fd6-a742-a45a0306c7b0",
			"created_at": "2022-10-25T15:50:23.710403Z",
			"updated_at": "2026-04-10T02:00:05.281246Z",
			"deleted_at": null,
			"main_name": "Silence",
			"aliases": [
				"Whisper Spider"
			],
			"source_name": "MITRE:Silence",
			"tools": [
				"Winexe",
				"SDelete"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "e8e18067-f64b-4e54-9493-6d450b7d40df",
			"created_at": "2022-10-25T16:07:24.515213Z",
			"updated_at": "2026-04-10T02:00:05.018868Z",
			"deleted_at": null,
			"main_name": "Mummy Spider",
			"aliases": [
				"ATK 104",
				"Gold Crestwood",
				"Mummy Spider",
				"TA542"
			],
			"source_name": "ETDA:Mummy Spider",
			"tools": [
				"Emotet",
				"Geodo",
				"Heodo"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "c2385aea-d30b-4dbc-844d-fef465cf3ea9",
			"created_at": "2023-01-06T13:46:38.916521Z",
			"updated_at": "2026-04-10T02:00:03.144667Z",
			"deleted_at": null,
			"main_name": "LUNAR SPIDER",
			"aliases": [
				"GOLD SWATHMORE"
			],
			"source_name": "MISPGALAXY:LUNAR SPIDER",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "506404b2-82fb-4b7e-b40d-57c2e9b59f40",
			"created_at": "2023-01-06T13:46:38.870883Z",
			"updated_at": "2026-04-10T02:00:03.128317Z",
			"deleted_at": null,
			"main_name": "MUMMY SPIDER",
			"aliases": [
				"TA542",
				"GOLD CRESTWOOD"
			],
			"source_name": "MISPGALAXY:MUMMY SPIDER",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "7cfe3bc9-7a6c-4ee1-a635-5ea7b947147f",
			"created_at": "2024-06-19T02:03:08.122318Z",
			"updated_at": "2026-04-10T02:00:03.652418Z",
			"deleted_at": null,
			"main_name": "GOLD SWATHMORE",
			"aliases": [
				"Lunar Spider "
			],
			"source_name": "Secureworks:GOLD SWATHMORE",
			"tools": [
				"Cobalt Strike",
				"GlobeImposter",
				"Gozi",
				"Gozi Trojan",
				"IcedID",
				"Latrodectus",
				"TrickBot"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "475ea823-9e47-4098-b235-0900bc1a5362",
			"created_at": "2022-10-25T16:07:24.506596Z",
			"updated_at": "2026-04-10T02:00:05.015497Z",
			"deleted_at": null,
			"main_name": "Lunar Spider",
			"aliases": [
				"Gold SwathMore"
			],
			"source_name": "ETDA:Lunar Spider",
			"tools": [
				"BokBot",
				"IceID",
				"IcedID",
				"NeverQuest",
				"Vawtrak",
				"grabnew"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "eb5915d6-49a0-464d-9e4e-e1e2d3d31bc7",
			"created_at": "2025-03-29T02:05:20.764715Z",
			"updated_at": "2026-04-10T02:00:03.851829Z",
			"deleted_at": null,
			"main_name": "GOLD WYMAN",
			"aliases": [
				"Silence "
			],
			"source_name": "Secureworks:GOLD WYMAN",
			"tools": [
				"Silence"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "88e53203-891a-46f8-9ced-81d874a271c4",
			"created_at": "2022-10-25T16:07:24.191982Z",
			"updated_at": "2026-04-10T02:00:04.895327Z",
			"deleted_at": null,
			"main_name": "Silence",
			"aliases": [
				"ATK 86",
				"Contract Crew",
				"G0091",
				"TAG-CR8",
				"TEMP.TruthTeller",
				"Whisper Spider"
			],
			"source_name": "ETDA:Silence",
			"tools": [
				"EDA",
				"EmpireDNSAgent",
				"Farse",
				"Ivoke",
				"Kikothac",
				"LOLBAS",
				"LOLBins",
				"Living off the Land",
				"Meterpreter",
				"ProxyBot",
				"ReconModule",
				"Silence.Downloader",
				"TiniMet",
				"TinyMet",
				"TrueBot",
				"xfs-disp.exe"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "2ac83159-1d9d-4db4-a176-97be6b7b07c9",
			"created_at": "2024-06-19T02:03:08.024653Z",
			"updated_at": "2026-04-10T02:00:03.672512Z",
			"deleted_at": null,
			"main_name": "GOLD CRESTWOOD",
			"aliases": [
				"Mummy Spider ",
				"TA542 "
			],
			"source_name": "Secureworks:GOLD CRESTWOOD",
			"tools": [
				"Emotet"
			],
			"source_id": "Secureworks",
			"reports": null
		}
	],
	"ts_created_at": 1775434540,
	"ts_updated_at": 1775826758,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/2c1c85445621bb6908a80958839030683a8e0a2d.pdf",
		"text": "https://archive.orkl.eu/2c1c85445621bb6908a80958839030683a8e0a2d.txt",
		"img": "https://archive.orkl.eu/2c1c85445621bb6908a80958839030683a8e0a2d.jpg"
	}
}