{
	"id": "0b119205-b26d-4f6a-888b-30ab71749319",
	"created_at": "2026-04-06T00:12:34.825909Z",
	"updated_at": "2026-04-10T13:12:31.757803Z",
	"deleted_at": null,
	"sha1_hash": "d740a6f39b9bf8f77cf650171962b6a287945340",
	"title": "Dissecting BokBot’s “Man in the Browser” | CrowdStrike",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2750687,
	"plain_text": "Dissecting BokBot’s “Man in the Browser” | CrowdStrike\r\nBy shaun.hurley.and.james.scalise\r\nArchived: 2026-04-05 22:36:11 UTC\r\nBokBot: Proxy Module\r\nThis article is a continuation of CrowdStrike’s recent blog, “Digging Into BokBot’s Core Module,” and provides a\r\ndetailed analysis of the inner workings of the BokBot proxy module — a complex piece of code written to trick\r\nvictims into sending sensitive information to a command and control (C2) server.\r\nOverview\r\nThe BokBot banking Trojan — also known as IcedID — was first observed in April 2017 and CrowdStrike has\r\nbeen tracking this threat ever since. BokBot has been used against financial institutions worldwide and is able to\r\naugment its capabilities by retrieving several modules, including one that runs a local proxy server. This proxy\r\nmodule is able to intercept and potentially manipulate web traffic with the goal of facilitating financial fraud. The\r\nBokBot core module downloads the proxy module, injects it into a spawned svchost child process, and the proxy\r\nmodule initializes itself in the target process. The following is a step-by-step analysis of how this process unfolds.\r\nModule Initialization\r\nPrior to standing up the proxy server thread, this module goes through an initialization process. Most of it is\r\nsimilar to the other BokBot modules — covered in the previous blog — and includes making errors less noisy,\r\nbuilding a list of C2s, and setting up named events for communicating with the parent process. The following\r\nsteps are taken prior to intercepting any traffic from a victim’s browser.\r\nWebinject Updates\r\nUser-mode asynchronous procedure call (APC) objects are used to trigger update events for the webinject data\r\nthat exists in process memory. During initialization, separate user APC objects are sent to the APC queue, one for\r\neach of the webinject DAT files (see previous blog). Each DAT file is decoded and stored in process memory, and\r\nwill be passed as a parameter to the APC callback function. Once the APC queue is processed, the web configs\r\nwill be parsed and loaded into process memory.\r\nC2 Communication Thread\r\nThe communication thread is signaled whenever there is collected data to be sent back to the C2. A signal event\r\noccurs when the injected malicious javascript sends a specific type of request to the proxy server (see: Browser\r\nPerspective section) . The data that is sent back can consist of harvested personal information, snapshots or proxy-related errors.\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 1 of 29\n\nProxy Server Initialization\r\nThe proxy server is bound to 127.0.0.1 on TCP port 57391. After the listener is set, a Windows Socket API (WSA)\r\nevent handler is registered using this socket to handle all connect/send/receive network requests.\r\nSSL Certificates\r\nIn order to perform a man-in-the-middle (MITM) attack on SSL connections, the proxy server needs to generate\r\nan SSL certificate, and insert it into the cert store. The certificate is created by calling\r\nCertCreateSelfSignCertificate, using the following hard-coded distinguished name (DN) values:\r\nA temporary cert store is created in memory and will eventually be written out to the following location, with a\r\nfilename that is generated using the Bot ID:\r\nC:\\Users\\jules\\AppData\\Local\\Temp\\D38D667F.tmp\r\nThe certificate store contains an SSL certificate for the webinject and C2 servers.\r\nOnce these steps have been completed, the proxy server is ready to intercept requests from the browser, but the\r\nbrowser has not been reconfigured to point to the proxy server.\r\nProxy Connections\r\nNow, whenever the browser attempts to connect to a website, that request is hijacked and first processed by the\r\nproxy server. This section covers how the connection states are managed, how SSL MITM works, and what\r\nactions are taken by the proxy server.\r\nManaging Connection State\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 2 of 29\n\nAll connections are managed by a series of data structures tied to WSA callback events that keep track of internal\r\ncommunication with the client, external communication with the target website, and to ensure the integrity of all\r\nthe requests handled by the proxy server.\r\nFigure 1: Proxy Connection State Architecture\r\nThe architecture diagram in Figure 1 summarizes the layout of relations between the proxy server components\r\nused to maintain the state of a proxy request.\r\nSSL Man in the Middle\r\nAny SSL request, where the URL matches a URL from the list of webinject targets, is hijacked by the proxy\r\ninserting itself into the communication using its own SSL certificate. The proxy server receives the request from\r\nthe victim and establishes an SSL connection using the proxy server’s SSL certificate. After that, the proxy server\r\nsends the request to the target website, and establishes an SSL connection between the proxy and the target\r\nwebsite. The response from the target is decrypted, and then encrypted using the proxy’s certificate. This response\r\nis sent to the victim, where the traffic will be decrypted using the proxy’s certificate.\r\nAn SSL context data-structure, similar to Figure 1, is used to maintain the state of the SSL traffic. See the\r\n“Ensuring Valid Certificates” section to understand how the browser is hooked to ensure that it sees these\r\ncertificates as valid.\r\nProxy Action\r\nIf the requested URL hostname does not match one of the webinjects, then the proxy server passes the HTTP\r\nrequests/responses between the infected host and the web server. However, if a URL matches one of the many\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 3 of 29\n\nwebsites targeted by the webinjects, then additional action is taken (see “Traffic Manipulation Proxy\r\nPerspective”).\r\nRedirecting Browsers to the Proxy\r\nAfter the proxy server has been initialized, any currently executing browser process will have to be configured to\r\nuse the proxy. To do this, BokBot injects code into the browser process. The injected code adds hooks into key\r\nfunctions, allowing it to hijack browser traffic.\r\nBrowser Process Selection\r\nA looping thread is spawned to iterate over all of the currently executing process names. To get a list of current\r\nprocesses, a list of BASIC_PROCESS_INFORMATION structures is generated using ZwQuerySystemInformation .\r\nProcess Identification\r\nOnce the list is generated, the module will attempt to identify browser processes. A hash of the process name is\r\nused to identify whether the process is one of the specific browser processes listed in Table 1.\r\nTable 1: Browser Identification by Hash\r\nThe hash is generated using a custom method, and then XORed with a constant value that varies between samples,\r\nso that the hash values differ between campaigns.\r\nProxy Configured Check\r\nOnce the browser has been identified an additional check is made to determine if this browser process has already\r\nhad the proxy configured by BokBot. To keep track of every browser process that has been injected into, a linked\r\nlist data structure is created (Figure 2). The entire list is walked, checking to see if both the process ID and the\r\nprocess creation time exist in the list. If the browser is not in the list, then a new list item is created that contains\r\nthe target process ID and target process creation time.\r\nFigure 2: Linked List of Browsers Processes Using the Proxy\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 4 of 29\n\nAn additional check is made by attempting to open up a named event. After the code is injected, a named event is\r\ncreated by the browser process. The naming scheme is generated in a similar manner as was discussed in the\r\nprevious blog about BokBot’s main module, however, the process ID is appended to the end of the name. The\r\nmodule calls OpenEvent and if the returned error code is ERROR_FILE_NOT_FOUND , the injection code continues.\r\nOpening the Process and Additional Checks\r\nOpenProcess is called to open a handle to the browser process. BokBot checks to see if the process is WOW64,\r\nand if so, different procedures are used that will yield the same result. To be thorough, another check is made to\r\ndetermine if the process has already been configured:\r\nZwQueryInformationProcess and ReadProcessMemory are used to get the process environment strings.\r\nEach string is checked to see if this exists: v313235373937=true\r\nThe 3132353739 is an ascii representation of the BotID.\r\nNo injection occurs if this environment string exists.\r\nBrowser Process Injection and Code Execution\r\nThe proxy configuration code is injected in the same manner as BokBot’s child process injection method (see the\r\nblog on BokBot’s main module), except for two things: OpenProcess is called to connect to the process, and a\r\nhook is added for ZwWaitForSingleObject . This means that as soon as the browser executes\r\nZwWaitForSingleObject , the injected code executes:\r\nThe hook is removed, the proxy is configured and the ZwWaitForSingleObject call is completed to maintain\r\nprocess execution.\r\nContext Structure\r\nThe context data structure is injected into the browser process and provides the proxy configuration code with the\r\nnecessary information to properly configure the proxy.\r\nBrowser Proxy Configuration Code\r\nThe “configuration code” is actually a series of procedure hooks that are used to insert the proxy module into the\r\ncommunication channel:\r\nCertVerifyCertificateChainPolicy\r\nCertGetCertificateChain\r\nconnect (ws2_32.dll)\r\nBrowser specific functions:\r\nInternet Explorer: MSAFD_ConnectEx\r\nFirefox: SSL_AuthCertificateHook\r\nChrome: ws2_32.WSAEventSelect\r\nInserting the Hooks\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 5 of 29\n\nMost of the hooks are inserted by walking the export table of the target module, hashing the procedure name, and\r\nthen comparing that hash against a static value. If these hashes match, then the hook can be placed.\r\nTable 2: Hash for Hooked Function Names\r\nTo get the address for MSAFD_ConnectEx , a different method is used and is discussed in the “Internet Explorer:\r\nMSAEFD_ConnectEx” section.\r\nWinsock2 Connect Hook\r\nThe Winsock2 hook intercepts all AF_INET network traffic that uses the connect API to send network traffic\r\n(Firefox and IE). The socket is set to non-blocking mode, using\r\nioctlsocket\r\nand a new connect call is sent to the proxy server. Once a connection is established, a 12-byte packet\r\ncontaining the following data is sent to the proxy server:\r\nThese 12 bytes are parsed and stored in the PROXY_SESSION_CONTEXT data structure (Figure 1). The result of the\r\nhooked call is a network file descriptor. Any network call that uses this file descriptor will be sent to the proxy\r\nserver. Whichever browser made the call will be unaware of the proxy intercepting the traffic.\r\nHooking Browser-Specific Functions\r\nThe next set of hooks are dependent on the target browser. Essentially, whether or not it is a browser-specific\r\nlibrary or a MS shared module, each browser handles requests in a different manner.\r\nInternet Explorer: MSAFD_ConnectEx\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 6 of 29\n\nSimilar to the previous connect hook, this function swaps out the original socket with a socket that contains the\r\nconnection data for the proxy server. The procedure address is not located in the export table of mswsock.dll, so\r\nthe address is acquired by calling WSAIoctl socket with the IO Control Code of\r\nSIO_GET_EXTENSION_FUNCTION_POINTER (0xC8000006).\r\nFireFox: SSL_AuthCertificateHook\r\nFirefox uses the SSL_AuthCertificateHook callback function to authenticate a certificate. SECSuccess (null) is\r\nreturned if the certificate is authenticated. BokBot attempts to hook this function in the “nss3.dll” module and if\r\nthat fails, it will patch the same function in “ssl3.dll.”\r\nThe hook always returns SECSuccess .\r\nGoogle Chrome: WSAEventSelect\r\nIn addition to the ws2_32.connect procedure being hooked, BokBot adds an additional hook in the ws_32.dll\r\nmodule in WSAEventSelect . The hook grabs the socket and the event object for every connection event\r\n( FD_CONNECT ). This data will be processed by the call to the hooked connect procedure.\r\nGoogle Chrome: connect\r\nEssentially, this hook does the same thing as what is covered in the previous section on the connect hook for IE\r\nand Firefox. The main difference is that all connection events collected by the WSAEventSelect hook are\r\nprocessed by this hook.\r\nEnsuring Valid Certificates\r\nOnce browser traffic is redirected to the proxy, the malware must prevent browser certificate errors from\r\ninforming the user that requests are being intercepted. To ensure that the certificates are both verified and trusted,\r\ntwo procedures are hooked: CertVerifyCertificateChainPolicy and GetCertificateChain .\r\nCertificate Chain Verification\r\nCertificate chains are verified by calling CertVerifyCertificateChainPolicy . This procedure returns a Boolean\r\nfunction to signify whether or not a specific chain is valid. BokBot hooks this function to ensure that all attempts\r\nto verify SSL certificate chains ( CERT_CHAIN_POLICY_SSL ) will always return TRUE .\r\nCertificate Chain Context Trust\r\nIn order to ensure that the browser sees that the certificates are trusted, BokBot hooks the GetCertificateChain\r\nprocedure. GetCertificateChain will construct a CERT_CHAIN_CONTEXT structure that contains an array of\r\nCERT_SIMPLE_CHAIN structures.\r\nEach one of these CERT_SIMPLE_CHAIN structures contains an array of CERT_CHAIN_ELEMNT data structures. These\r\ndata structures all contain a field, TrustStatus , used to convey potential issues with the certificate chain. To\r\nensure success, the TrustStatus field needs to be modified to ensure all certificates in the chain are trusted.\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 7 of 29\n\nTrustStatus is a structure comprised of a field that identifies errors with the certificate ( ErrorStatus ) and a\r\nfield that contains an information status for the ticket ( InfoStatus ).\r\nPatching these two fields within each structure will trick the browser into believing that the certificates are all\r\ntrusted. First, ErrorStatus is set to indicate that there is no error with the certificate or chain:\r\nThis value is set the same for all of the data structures. The InfoStatus fields, however, are different between\r\nthe CERT_CHAIN_ELEMENT structure, CERT_CHAIN_CONTEXT and CERT_SIMPLE_CHAIN structures:\r\nOnce these two values are set, the certificate chain will be seen as trusted by the browser.\r\nProxy C2 Communication\r\nThe majority of the communication passed between the proxy server and the C2 will be comprised of either\r\nexfiltrated data or error messages for debugging. Table 3 contains the URI\r\n(Uniform Resource Identifier) parameters that are passed with every request. The data sent will be covered in the\r\nfollowing section.\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 8 of 29\n\nTable 3: C2 URI Parameters\r\nThe following is an example of the request headers:\r\nIn this case, the request body contains the following Zlib compressed data:\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 9 of 29\n\nThe request body decompresses to the following:\r\nTraffic Manipulation: Proxy Perspective\r\nBokBot’s proxy module relies on traffic manipulation to steal a victim’s sensitive information. Web traffic\r\ngenerated by a victim’s browser is matched against a list of target URLs (webinjects), and if matched, the proxy\r\ntakes one of the following actions: redirect to a decoy website (webfake); scrape the page; screenshot the page; or\r\nignore. In addition, the response to the request is matched to determine if either HTML or Javascript is injected\r\ninto the page and served back to the victim.\r\nFigure 3: BokBot WebFake Process Overview\r\nWeb Injection DAT Files\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 10 of 29\n\nThe DAT files downloaded by the BokBot main module are structured binary files that contain a list of target\r\nURLs, target HTML/Javascript code blocks, and the Javascript/HTML code blocks to be injected. During the\r\ninitialization process, this structured data is broken into multiple lists for each of the webinject categories. The\r\nwebinject category lists are built out of a series of webinject types. Once parsed, each element has the following\r\nstructure:\r\nPage Scraping\r\nThe page-scraping processing functions perform a match on either the URL or on the HTML body to determine if\r\nthe webpage’s information should be scraped and sent to the C2. Page scraping targets banking account display\r\npages to grab the target’s account information.\r\nTypes 33, 34\r\nEither an exact URL string or a regex is used to match the victim’s requested URL. Once a match is made, both\r\nthe HTML body and the matched URL are sent to the C2. Each of the targeted URLs are related to pages that\r\ncontain the victim’s account information, for example:\r\nchaseonline.chase.com/gw/secure/ena\r\nclient.schwab.com/Accounts/Summary/Summary.aspx\r\nType 64\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 11 of 29\n\nThis scans the webpage body looking for text (“Account Balance,” “Current Balance,” etc.) related to account\r\nbalances, security challenge questions and other personal data. If located, the URL, the HTML body and the\r\nmatched text are compressed and sent to the C2.\r\nScreenshots\r\nScreenshots are generated when a URL matches on a Type 49 inject. Screenshots are taken using the Windows\r\nGDI+ API. A bitmap is generated, written to a tmp file, read into a buffer, compressed, and then sent to the C2.\r\nBitmaps are written to the local temp directory under AppData and the filename is a unique string of alpha\r\ncharacters.\r\nExample: AppData\\Local\\Temp\\alksfjlkdsfk.tmp\r\nAlthough no concrete examples came with the webinjects of the BokBot versions used to generate this report, it is\r\nbelieved that these screenshots will contain sensitive details related to commercial and banking accounts.\r\nCode Injection\r\nCode injection works by either matching\r\na URL, or doing a match and replace on an HTML element.\r\nTypes 17 and 19\r\nTypes 17 and 19 are used to hide elements within a page, grab form data, inject code, replace code, and to make\r\nthe webfake experience more believable for the victim. The difference between these two types is that Type 17\r\ndoesn’t rely on regex to match and replace HTML and Javascript.\r\nType 81\r\nType 81 is a list of URLs that are ignored entirely by the proxy server. The purpose is to avoid complications that\r\ncould come up when injecting into advertisements and chat or email clients. Rather than deal with handling this\r\ncode, the requests and responses are forwarded to the victim or the target by the proxy, without modification.\r\nWebfake Phishing Site\r\nBokBot uses the webinjects to create a replica of the original target website. These replica websites are called\r\nwebfakes. URIs are rewritten to forward the traffic to the webfake site. This section covers each of the injection\r\ntypes used to redirect traffic to a webfake. The web browser is not aware that traffic is being redirected to the\r\nwebfake.\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 12 of 29\n\nFigure 4: BokBot WebFake Example\r\nType 50\r\nType 50 requests perform exact matches (no regex) on URIs received from the client. Whenever a match occurs,\r\nthe URL is rewritten to point toward the webfake site, and the request is sent to the replica page. The response to\r\nthat request is parsed by the proxy server and sent back to the victim.\r\nType 51\r\nTo match individual icon/gif/bitmap/other names, regex match and replace is leveraged:\r\nRegex to match: ^https:\\/\\/www\\.amazon\\.{2,5}\\/.*\\/style\\/images\\/(.*)\\.(png'|gif)$\r\nReplacement URI: hxxps://hospirit\u003c.\u003ecom/amazon/style/images/$1.$2\r\nIP Address for hospirit\u003c.\u003ecom: 185.68.93.136\r\nThis regex will replace the values “$1” and “$2” with the name of the PNG or GIF file. This rewritten request is\r\nwhat will be sent out of the proxy server.\r\nType 52\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 13 of 29\n\nType 52 requests appear to check a URL for a substring and then extract that data, but the BokBot samples used to\r\nbuild this report did not contain a Type 52 rewrite.\r\nURL Rewrite Bypass\r\nIt would become an issue if the same webfake process is used every time a victim attempts to log into a targeted\r\nwebsite. Once the victim’s information has been collected, there is no longer a need to rewrite URLs to point\r\ntowards the webfake site. Instead, the request should be sent, unmodified, to the real website. To ensure this\r\nhappens, BokBot, maintains a list of subkeys located under the HKCU\\Software\\Classes\\CLSID registry key. For\r\nthis to work, a unique name needs to be generated for each of the target sites. Each of the inject types included in\r\nthis category contains a Webfake Template field, for example:\r\nThe highlighted value is used as a seed to generate a unique registry key name (covered in more detail in the\r\n“Verification Requests” section). Each of the target sites contains either a value similar to the one highlighted\r\nabove, or a simple identifier that uses the URL hostname (e.g., “amazon”).\r\nIf the registry subkey exists, the proxy server sends a request to the C2 to determine if the request should be\r\nrewritten. If the response from the C2 is anything other than one of the two bytes — “0x2D” or “0x2B” — the\r\nlegitimate URL will not be rewritten to point to the webfake site.\r\nVerification Requests\r\nVerification requests are generated by the Bot API javascript (covered further down) and are used to either send\r\ndata to the C2, or to insert/delete/query a value in the registry. Multiple verification request types are used, each\r\none is processed by the proxy server.\r\nTable 4: Verification Commands\r\nType 96\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 14 of 29\n\nIn order to either display a “Site Down for Maintenance” message or present the victim with a legitimate website\r\n(bypass the URL rewrite request), the Bot API injected javascript code can generate these Type 96 banknameS\r\nrequests.\r\nThe values passed to the body of this request will be written to the registry and checked both by the Bot API and\r\nduring execution of the code that handles the URL redirection request types.\r\nEach site is provided a unique ID that is sent to the proxy server via the banknameS parameter. This value is used\r\nto generate a UUID, which will be the name of the registry key. All of these entries are created under the\r\nfollowing registry path: HKCU\\Software\\Classes\\CLSID . After the key is created, the value located in the body of\r\nthe Type 96 request is hashed and written to the ( Default ) value field in the registry subkey.\r\nTypes 97 and 98\r\nBoth Type 97 and 98 verifications will be generated by the Bot API’s injected javascript, and will perform an\r\naction on the registry key that was created by the Type 96 request. Type 97 queries the registry to see if the value\r\nexists, and Type 98 will delete the key.\r\nType 100\r\nVerification Type 100 is either passed directly to the C2 (Type 2) or the request tells the proxy server to interact\r\nwith the C2 (Type 1) in some manner.\r\nThese requests are either HTTP POST or HTTP GET requests that contain the information collected from the\r\nmalicious javascript code.\r\nPutting it All Together\r\nLet’s take an example using the cashanalyzer website inject: First, the proxy server receives a request from a web\r\nbrowser to access www.cashanalyzer.com. The proxy cycles through the various webinject lists to match the URL.\r\nA match is found.\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 15 of 29\n\nThe proxy server takes the 2299737dfa5c070dc29784f1219cd511 value from the first part of the Webfake\r\nTemplate field and uses it to generate a UUID to determine if a “Site Down For Maintenance” page is set (see the\r\n“Verification Requests” section). If it exists, a request is sent to the C2 to determine if the block page should be\r\nupdated with a new time or removed. Once the block page check has been made, the proxy server takes the rest of\r\nthe Webfake Template and replaces the front:// string with the web protocol (HTTP/HTTPS) and the\r\nreplacement URL hospirit.com/cashanalyzer . The URL path and query, content/main?\r\na=2299737dfa5c070dc29784f1219cd511\u0026b=#gid#\u0026c=#id# , is appended to the end of the URL. The Project ID and\r\nthe Bot ID values replace the #gid# and #id# parameter value tokens, respectively.\r\nThis request is sent to the webfake. A response is sent and additional checks are made to determine if anything\r\nmatches one of the inject types. In this case, no match was found and the response will be forwarded back to the\r\nvictim’s browser without modification. The browser is not aware of the redirection and the original requested URL\r\nis still visible in the browser address bar. As the browser renders the response, additional requests will be sent to\r\nload dependant javascript files from the webfake. In this case, main.js is loaded from the webfake. The browser\r\nrequests to download the javascript file from the redirected website and, once again, the proxy server performs the\r\nwebinject match routines. As a result, a Type 19 match is found.\r\nThe “Code to Inject” value will be injected into the main.js code when the redirected website responds to the\r\nrequest. Now all of the necessary components are in place to collect the target’s account information. Once form\r\ndata is collected, Validation Type 100 requests are sent and processed by the proxy server. These requests are\r\nPOST requests with the form data contained within the request body. Once processed by the proxy, the form data\r\nwill be sent to the C2 by signaling the C2 communication thread.\r\nThe request parameters can be parsed by referring back to the “Proxy C2 Communication” section. There are\r\nmultiple variations of how webinjects are handled by the proxy server. However, this example is sufficient to\r\nshowcase the entire workflow.\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 16 of 29\n\nTraffic Manipulation: Browser Perspective\r\nDue to the multitude of variations for the injected javascript API, and rather than attempting to abstract and\r\npresent the high-level processes each inject has in common, this section will focus only on continuing the\r\ncashanalyzer.com example introduced in the previous section. This analysis can be used to understand how the\r\nother injects work. The first couple of sections will cover how the site interacts with the victim, the proxy and the\r\nC2. After that is covered, the “Putting it All Together” section will connect the separate pieces.\r\nBot API: Core Javascript Module\r\nAs previously mentioned, the\r\nmain.js file contains the Bot API code. This code provides everything necessary to interact with the proxy, the\r\nC2 and the webpage HTML elements, to ensure that the victim has a seamless experience while entering the\r\naccount information.\r\nToken States\r\nA token state is a numerical indicator used to identify what action the Bot API should take next. There are five\r\ntoken states:\r\nTable 5: Token States\r\nAs an example, if there is some sort of error, the token state is set to either 3 or 4, and this will trigger the logic in\r\nthe javascript to call the viewBlock method (next section) and load the “Site Down for Maintenance” page.\r\nPage View Architecture\r\nIn order to ensure that the correct information is collected in the proper order, the Bot API relies on a traditional\r\nview/controller architecture. In this case, the controller is the attacker-controlled webfake site. The Bot API client\r\nnotifies the C2 that it is ready to receive a command, the server responds with a command, and this command is\r\nused to load the next page view.\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 17 of 29\n\nTable 6: Page View Commands\r\nOnce the command is received by the Bot API, the CSS display field of the relevant HTML element is modified to\r\ndisplay this code block. A typical session using the webfake will take the following steps:\r\n1. Login page view is loaded\r\n1. Victim enters the account information and submits the form\r\n2. A wait page is displayed as the login form is processed\r\n2. Security token page view is loaded\r\n1. Victim enters the security token\r\n2. A wait page is displayed as the security token form is processed\r\n3. First name/last name/phone number page view is loaded\r\n1. Victim enters this information\r\n2. Another wait page is displayed as this form is processed\r\nAn example of this will be covered in the “Putting it All Together” section below.\r\nWait Pages\r\nAfter the victim attempts to log in to the website, there is an idle period as the proxy forwards the request to the\r\nwebfake site, and that site forwards the request to the legitimate website.\r\nTo avoid causing any concern, the Bot API displays a wait page.\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 18 of 29\n\nFigure 5: Post-Login Wait Page\r\nThere are multiple versions of this site, one for each step of the account information collection process: login\r\ninformation; security token information; security question answers; and the form that collects the victim’s name\r\nand address.\r\nCommunication: Bot API Requests to the C2\r\nCommands are forwarded to the C2 on behalf of the Bot API by the proxy server using Validation Type 100\r\nrequests. Contained within these requests is a base64-encoded string. This string decodes to a series of parameters\r\nin JSON format.\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 19 of 29\n\nTable 7 describes the meaning of each of these parameters. In this case, the Bot API is notifying the C2 that the\r\npage has not been initialized (invalid).\r\nTable 7: URL Parameters for Bot API C2 Communication\r\nHeartbeat (Type 1) requests are sent out at regular intervals by the Bot API. These requests are used as a means to\r\nmaintain constant communication with the C2 and provide a medium for the Bot API to receive commands.\r\nCommunication: C2 Responses to the Bot API\r\nResponses from the C2 contain commands specifying what actions the Bot API should take, based on the initial\r\nrequest. After each form submission, a command is received from the C2 telling the Bot API which page to load\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 20 of 29\n\nnext. These responses are also base64-encoded JSON.\r\nIn this case, the command ID is “99” and it is telling the Bot API to reload the original site. This will reset all of\r\nthe forms, clear any site blocks and load the original page. Table 8 covers the various fields of the C2 response:\r\nTable 8: C2 Response Fields\r\nAs can be seen, the id field lines up with the view commands table (Table 6) covered in the “Page View\r\nArchitecture” section.\r\nSite Maintenance Page\r\nWhenever the token state of the Bot API is set to “3” or “4,” an error page stating that there are technical issues is\r\ndisplayed (Figure 6). The token is set to one of those two states whenever there is an issue communicating with\r\nthe C2, the webfake, the proxy server, or if an error occurs when the webfake communicates with the real website.\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 21 of 29\n\nFigure 6: BokBot Proxy “Site Down for Maintenance” Page\r\nThe fix date is generated by adding one hour to the current time. After displaying the website, this timestamp is set\r\nin the registry by sending a Type 96 Verification request. Once the timer expires, a Type 98 Verification request is\r\nsent to delete the block time from the registry.\r\nLogging\r\nThe Bot API is constantly sending logging data back to the C2 as base64-encoded JSON. The following is the\r\ndecoded JSON object:\r\nThis chunk of data has a series of key:value pairs, where the h key contains the log, as a value . The logs are\r\ndescriptive and useful for the malicious actor.\r\nPutting it All Together\r\nInitial Browser Request\r\nThe victim’s browser sends a request for cashanlyzer.com, and that request is intercepted by the proxy, rewritten,\r\nsent to the webfake site, and the response is sent from the proxy to the victim. The page content also contains the\r\nfollowing javascript code to load a javascript file from the attacker-controlled site:\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 22 of 29\n\nThis main.js request is forwarded by the proxy and has the following code injected into the response:\nThis code will call the String.prototype.init method that is defined in main.js . In this case, the init method\ncontains the malicious Bot API javascript module, and will end up calling the main function to initialize and load\nthe webfake site.\nFigure 7: Cashanalyzer Fake Login Page\nAfter checks are performed to determine if a block page needs to be loaded, the Bot API calls the viewStep\nmethod and passes it the string “login.” The string passed to this method is the element id of the HTML\n\nobject that contains the login form.\nThis display field of this element will be switched from none to block and the login page is displayed (Figure\n7). Now the victim can enter the login information and click “continue.” All of the data entered is placed into a C2\nrequest structure and sent to the webfake site.\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\nPage 23 of 29\n\nThe first highlighted section above is the user account credentials, and the second is the logging information. This\r\ninformation notifies whoever is on the other end that the login view was loaded, and that the last view is the wait\r\npage. The wait page that the victim is seeing churns as the Bot API continuously sends heartbeat requests, waiting\r\nfor the response from the webfake site.\r\nAfter processing is finished, the webserver responds with a command to disable the login page, and make the next\r\npage viewable. In this case, the command is to load the user contact information form.\r\nThe rest of the steps are self explanatory: The subsequent actions consist of forms leading to a wait time, followed\r\nby additional forms until the last step is reached.\r\nWrapping Up the Process\r\nOnce all of the information has been collected, the Bot API sends a Validation Type 96 request to the proxy server:\r\nHowever, instead of a timestamp, the value being set in the registry is the string “true,” as highlighted below.\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 24 of 29\n\nThis request instructs the proxy server to create the ‘ HKCU\\Software\\Classes\\CLSID\\{7570CC99-D32B-6883-1375-\r\n9D2881583EFB) ' registry key with the ( Default )value, set to a four-byte binary value.\r\nOnce this is set, any further attempt to access bypasses any attempt to rewrite the URL (inject Types 50, 51, 52),\r\nand will load the legitimate website. To load the legitimate website, the page is refreshed and now the victim will\r\nbe able to login to the legitimate cashanalyzer.com website. Of course, if any of the other webinjects match on the\r\nsite, other actions will be taken (collecting account balance data, etc.).\r\nHow CrowdStrike Falcon® Prevent Stops BokBot\r\nCrowdStrike® CrowdStrike Falcon® Prevent™ next-generation antivirus successfully stops BokBot when\r\nprocess blocking is enabled, as explained in the following. BokBot spawns a svchost child process, injects the\r\nmain module, and that svchost process spawns and injects into multiple child processes. The process tree in Figure\r\n8 is an example of what BokBot looks like when viewed using Falcon Prevent with process blocking is disabled.\r\nAs shown below, several malicious child processes were launched by BokBot’s main module, located inside of the\r\nfirst svchost process.\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 25 of 29\n\nFigure 8: BokBot Process Tree Without Process Blocking Enabled\r\nWithout preventions enabled, the customer will still be notified of the malicious activity, but no action will be\r\ntaken to prevent the behavior automatically.\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 (Figure 9), an analyst sees that the svchost process\r\nwas prevented. The block message (Figure 10) that occurs with this preventative action explains why this process\r\nwas terminated.\r\nFigure 9: BokBot Process Tree With Process Blocking Enabled\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 26 of 29\n\nFigure 10: 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 attack (IOAs), then Falcon can also prevent malware execution\r\nby leveraging either next-generation AV machine learning or intelligence collected by the Crowdstrike Intelligence\r\nteam.\r\nIndicators\r\nBokBot Hashes\r\nThe following hashes were used in creation of this blog post.\r\nFile Hash File\r\n87d37bc073d4d045d29e9c95806c7dcf83677697148e6b901c7a46ea7d5f552e BokBot Container\r\n2c331edaadd4105ce5302621b9ebe6808aecb787dd73da0b63882c709b63ce48 BokBot Container\r\n7e05d6bf0a28233aa0d0abfa220ef8834a147f341820d6159518c9f46f5671b7 BokBot Container\r\n961f7bada0c37c16e5ae7547d9b14b08988942af8d4a155ad28e224ece4fa98e BokBot Container\r\nc992229419759be2ecaddcfd2d0ce26ce3cddca823a4c4875564316b459b05eb BokBot Container\r\n88e41cc6bd4ec57bcabf67f15566475e1ee3ff7667b73f92ac81946f8564e6d9 BokBot Proxy DAT\r\nec205babdc4422888c3c29daa2f3d477315a2a136a2bd917947cd2184cdce406 BokBot Proxy DAT\r\nFile Locations\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 27 of 29\n\nPath Details\r\n%PROGRAMDATA%\\{UUID}\\.exe Bokbot main binary\r\n%PROGRAMDATA%\\}\\.dat Bokbot DAT File\r\nRegistry\r\nPath Details\r\nHKCU\\Software\\Classes\\CLSID\\{UUID) Block Site and Rewrite bypass data\r\nNetwork Listeners\r\nPort Service Name Details\r\nTCP 57391 svchost.exe Proxy Server Port\r\nAttacker Controlled Sites\r\nHostnames\r\nsegregory\u003c.\u003ecom\r\ntybalties\u003c.\u003ecom\r\nwaharactic\u003c.\u003ecom\r\nambusted\u003c.\u003espace\r\noverein\u003c.\u003espace\r\nexterine\u003c.\u003espace\r\nstradition\u003c.\u003espace\r\nstocracy\u003c.\u003espace\r\nugrigo\u003c.\u003espace\r\nyorubal\u003c.\u003espace\r\nportened\u003c.\u003espace\r\ncoultra.space\r\nparchick.space\r\nexhausines.space\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 28 of 29\n\nharactice.space\r\nacquistic.space\r\nAdditional Resources\r\nLearn about the collaboration among eCrime groups that may be driving these attacks: \"New Evidence\r\nProves Ongoing WIZARD SPIDER / LUNAR SPIDER Collaboration,\" and \"Sin-ful SPIDERS: WIZARD\r\nSPIDER and LUNAR SPIDER Sharing the Same Web.\"\r\nDownload the 2021 CrowdStrike Global Threat Report\r\nDownload the 2018 CrowdStrike Services Cyber Intrusion Casebook and read up on real-world IR\r\ninvestigations, with details on attacks and preventative recommendations.\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/bokbots-man-in-the-browser-overview/\r\nhttps://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/\r\nPage 29 of 29",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.crowdstrike.com/blog/bokbots-man-in-the-browser-overview/"
	],
	"report_names": [
		"bokbots-man-in-the-browser-overview"
	],
	"threat_actors": [
		{
			"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": "f6f91e1c-9202-4497-bf22-9cd5ef477600",
			"created_at": "2023-01-06T13:46:38.86765Z",
			"updated_at": "2026-04-10T02:00:03.12735Z",
			"deleted_at": null,
			"main_name": "WIZARD SPIDER",
			"aliases": [
				"TEMP.MixMaster",
				"GOLD BLACKBURN",
				"DEV-0193",
				"UNC2053",
				"Pistachio Tempest",
				"DEV-0237",
				"Storm-0230",
				"FIN12",
				"Periwinkle Tempest",
				"Storm-0193",
				"Trickbot LLC"
			],
			"source_name": "MISPGALAXY:WIZARD SPIDER",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "bc119938-a79c-4e5f-9d4d-dc96835dfe2e",
			"created_at": "2024-06-04T02:03:07.799286Z",
			"updated_at": "2026-04-10T02:00:03.606456Z",
			"deleted_at": null,
			"main_name": "GOLD BLACKBURN",
			"aliases": [
				"ITG23 ",
				"Periwinkle Tempest ",
				"Wizard Spider "
			],
			"source_name": "Secureworks:GOLD BLACKBURN",
			"tools": [
				"BazarLoader",
				"Buer Loader",
				"Bumblebee",
				"Dyre",
				"Team9",
				"TrickBot"
			],
			"source_id": "Secureworks",
			"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": "63061658-5810-4f01-9620-7eada7e9ae2e",
			"created_at": "2022-10-25T15:50:23.752974Z",
			"updated_at": "2026-04-10T02:00:05.244531Z",
			"deleted_at": null,
			"main_name": "Wizard Spider",
			"aliases": [
				"Wizard Spider",
				"UNC1878",
				"TEMP.MixMaster",
				"Grim Spider",
				"FIN12",
				"GOLD BLACKBURN",
				"ITG23",
				"Periwinkle Tempest",
				"DEV-0193"
			],
			"source_name": "MITRE:Wizard Spider",
			"tools": [
				"TrickBot",
				"AdFind",
				"BITSAdmin",
				"Bazar",
				"LaZagne",
				"Nltest",
				"GrimAgent",
				"Dyre",
				"Ryuk",
				"Conti",
				"Emotet",
				"Rubeus",
				"Mimikatz",
				"Diavol",
				"PsExec",
				"Cobalt Strike"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "e6a21528-2999-4e2e-aaf4-8b6af14e17f3",
			"created_at": "2022-10-25T16:07:24.422115Z",
			"updated_at": "2026-04-10T02:00:04.983298Z",
			"deleted_at": null,
			"main_name": "Wizard Spider",
			"aliases": [
				"DEV-0193",
				"G0102",
				"Gold Blackburn",
				"Gold Ulrick",
				"Grim Spider",
				"ITG23",
				"Operation BazaFlix",
				"Periwinkle Tempest",
				"Storm-0230",
				"TEMP.MixMaster",
				"Wizard Spider"
			],
			"source_name": "ETDA:Wizard Spider",
			"tools": [
				"AdFind",
				"Agentemis",
				"Anchor_DNS",
				"BEERBOT",
				"BazarBackdoor",
				"BazarCall",
				"BazarLoader",
				"Cobalt Strike",
				"CobaltStrike",
				"Conti",
				"Diavol",
				"Dyranges",
				"Dyre",
				"Dyreza",
				"Dyzap",
				"Gophe",
				"Invoke-SMBAutoBrute",
				"KEGTAP",
				"LaZagne",
				"LightBot",
				"PowerSploit",
				"PowerTrick",
				"PsExec",
				"Ryuk",
				"SessionGopher",
				"TSPY_TRICKLOAD",
				"Team9Backdoor",
				"The Trick",
				"TheTrick",
				"Totbrick",
				"TrickBot",
				"TrickLoader",
				"TrickMo",
				"Upatre",
				"bazaloader",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434354,
	"ts_updated_at": 1775826751,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d740a6f39b9bf8f77cf650171962b6a287945340.pdf",
		"text": "https://archive.orkl.eu/d740a6f39b9bf8f77cf650171962b6a287945340.txt",
		"img": "https://archive.orkl.eu/d740a6f39b9bf8f77cf650171962b6a287945340.jpg"
	}
}