{
	"id": "e7f6bf81-cb63-492d-9d95-bdeef290d79a",
	"created_at": "2026-04-06T00:08:11.798266Z",
	"updated_at": "2026-04-10T13:12:37.918508Z",
	"deleted_at": null,
	"sha1_hash": "13aa8444334f57aee755e5679807c3e9ec96975f",
	"title": "Deep Analysis of a QBot Campaign - Part II | FortiGuard Labs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2146121,
	"plain_text": "Deep Analysis of a QBot Campaign - Part II | FortiGuard Labs\r\nBy Xiaopeng Zhang\r\nPublished: 2020-07-08 · Archived: 2026-04-05 16:31:25 UTC\r\nFortiGuard Labs Threat Research Analysis\r\nAffected platforms:      Microsoft Windows\r\nImpacted parties:         Windows Users\r\nImpact:                         Collects sensitive information from victims’ computers\r\nSeverity level:               High\r\nBackground on this Recently Discovered QBot Campaign\r\nThis is the second part of the analysis of a recently discovered QBot campaign. In the first part, I explained how a captured\r\nWord document downloaded the original QBot payload, what it did to start compromising its victim’s device, as well as\r\nwhat complicated techniques it used to protect itself from being identified. In Part II, I will look at how the core module\r\ncollects data from a victim’s device, how it extracts submodules, how it injects its injection-module into other processes, and\r\nother malicious behaviors.\r\nAs a reminder, QBot is a malware originally focused on logging information related to finance-related websites. It is capable\r\nof monitoring the browsing activities of an infected computer, as well as steal other critical information.\r\nIn that first part of our analysis, we showed how QBot decrypted a core module called “307” from the resource section. It\r\nthen deployed that core module in the memory of “explorer.exe” process, and finally, its entry point function was called by\r\nthe ASM instruction call [ebp+var_10], as shown in Figure 1.1.\r\nFigure 1.1. Calling the core module’s entry point\r\nIn this second part of the analysis, I will focus on what malicious things QBot does, what data it obtains from a victim’s\r\ndevice, and how it connects to its C2 server.\r\nQBot Core Module Executes in Explorer.exe\r\nThe core module starts a thread. Its entire work will start from the main thread function.  Figure 2.1 is the pseudo code of\r\nDllEntryPoint(). This entry point is called first, and it calls API CreateThread() to start the main thread function.\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-qbot-campaign\r\nPage 1 of 12\n\nFigure 2.1. The pseudo code of DllEntryPoint of the core module (resource “307”)\r\nIn the main thread function, it creates a named pipe called \\\\.\\pipe\\mavrihvusp. This name will vary on different devices\r\nbecause it is generated from the device environment and user name. It then starts a thread to monitor and handle the data\r\nwhen someone connects to this pipe.\r\nFor persistence, it adds its main process into the Auto-Run group of the system registry. To do this, it creates a thread whose\r\ncallback function calls API RegOpenKeyExW(). RegSetValueExW() then adds a string value item under the sub-key\r\n“HKCU\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run”. This enables QBot to automatically run as the infected\r\ndevice restarts.\r\nFigure 2.2, below, shows the Auto-Run item for QBot. The name is a random string, and the string value is the full path of\r\nQBot from its home folder.\r\nFigure 2.2. The Auto-Run item added in the System Registry\r\nBesides adding itself into the Auto-Run group, QBot installs itself into the system Task Scheduler with a function whose\r\nfunction index is 08. It executes the command “C:\\Windows\\system32\\schtasks.exe” with the parameters “/create /tn {task-name} /tr \\\"QBot-full-path\\\" /sc HOURLY /mo 5 /F” to create one new item. It then executes the QBot process every 5 hours\r\nto achieve persistence on the victim’s device. Figure 2.3 shows the QBot task having just been installed.\r\nFigure 2.3. Installed task for QBot in the Task Schedule\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-qbot-campaign\r\nPage 2 of 12\n\nQBot’s configuration data block is encrypted and saved in both resource “308” and the mavrihvu.dat file from its home\r\nfolder, which is loaded into memory in the main thread function. It contains many value pairs (key name= key value) to\r\ncontrol and help QBot to work, such as Variant ID, QBot installation time, last active C2 server, victim’s login name, the\r\npublic IP address of victim’s device, and many feature switch flags. The configuration data block is frequently accessed\r\nthroughout the QBot.\r\nOther than the main thread, QBot creates many worker threads, where the thread functions perform a variety of functions,\r\nwhich I will explain in the following sections. \r\nFigure 2.4. The main thread and many worker threads\r\nFigure 2.4 displays the main thread and other worker threads. When a worker thread starts, it sets the thread priority to\r\n“below normal” by calling API SetThreadPriority(), which is why they have the “Priority” setting “32 – 1”. \r\nWidely Spread QBot within the Local Network\r\nQBot is then able to spread itself on a victim’s local area network (LAN). This feature runs in a worker thread, and it\r\nenumerates the network computers on the victim’s device. \r\nIt then makes a connection to one network computer and copies the QBot EXE file onto its sharing folder. The target file\r\nname is random, as shown in Figure 2.5, which is the just copied QBot named “azamzcifut.exe”.\r\nFigure 2.5. QBot copied onto a shared folder of one network computer\r\nTo do this, it calls a number of APIs, such as WNetOpenEnumW(), WNetEnumResourceW(),\r\nNetShareEnum(),OpenSCManagerW(), WNetAddConnection2W(), and so on. \r\nNext, it starts a Windows service on the remote computer by calling the APIs CreateServiceW() and StartServiceW(). Figure\r\n2.6 is a screenshot of QBot when it is about to call CreatServiceW(), as well as its parameters.\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-qbot-campaign\r\nPage 3 of 12\n\nFigure 2.6. Creating a Windows service on a remote computer\r\nAfter the API StartServiceW() is called, the created Windows service on the remote machine starts to run, and QBot is\r\nexecuted on the remote computer in background.\r\nFinally, QBot remotely deletes both the created service (since it has executed QBot) and the copied QBot file to erase its\r\nfootprints. It repeats this same process on all of the other network computers to spread QBot widely.\r\nSending Packets to C2 Server\r\nMany threads work together to establish connections to the C2 server. A thread function decrypts the C2 server list from\r\nresource “311” within the core module. Figure 3.1 displays a partial C2 server list that has been RC4 decrypted.\r\nFigure 3.1. The C2 server list in the decrypted resource “311”\r\nThere are 150 IP and Port pairs in total from resource “311”. One pair of them consists of “IP;0;Port”, for instance:\r\n“72.214.55.147;0;995”. QBot repeats picking a C2 server from the list in a loop, and attempts connecting to them until a\r\nconnection is established. It then records the active C2 server into the configuration block and updates it to the file\r\nmavrihvu.dat as well. In the configuration block, key “45” saves the IP address, while key “46” saves the Port number,\r\nwhich are used when other thread functions send data to C2 server.\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-qbot-campaign\r\nPage 4 of 12\n\nThe data between QBot and C2 server are in JSON format and encrypted over SSL protocol. The request URL is\r\n“https[:]//IP:Port/t3”, such as “hxxps://72[.]214[.]55[.]147:995/t3”. QBot sends data using the “POST” method to the C2\r\nserver. The first packet looks something like: “{\"8\":9,\"1\":17,\"2\":\"rvhdls712290\"}”.\r\nThe values of key names “8” and “1” are constant numbers indicating the packet type. The value of key “2” is\r\n“rvhdls712290”, which can be treated as the victim’s ID because it was generated from the victim’s user name. The plaintext\r\ndata is RC4 encrypted and then base64 encoded.\r\nFigure 3.2. QBot sends data to C2 server\r\nAs can be seen in Figure 3.2, QBot was about to send the base64-encoded first packet to a C2 server. The data size is 0x50.\r\nWhen the response packet comes, QBot then performs the reverse process – which is base64 decoding and RC4 decryption –\r\nto get the plaintext data. The first response packet from C2 server looks like the following:\r\n“{\"8\":5,\"16\":1613570569,\"39\":\"M2vqgbtrjwKrllf29InHGznAwG3SnStzKegq3LTb\",\"38\":1}”\r\nQBot then records the value of key “16” in a global variable that is a Unix epoch time, and parses the value of key “38”.\r\nNote: In the other parts of this analysis, I will ignore the encryption or decryption process, and only focus on the plaintext\r\ndata.\r\nFigure 3.3. QBot sending more data to the C2 server\r\nQBot next sends another packet to C2 server, as shown in Figure 3.3. This packet contains QBot basic information, like\r\nvariant ID “spx97”, variant version “127”, and the core module creation time, which is in key “10”. It also contains\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-qbot-campaign\r\nPage 5 of 12\n\ninformation from the victim’s device, such as the Windows version in key “23”, the Windows name in key “24”, Processor\r\ninformation, Domain name, User name, installed Anti-Virus software in key “31”, QBot full path in key “57”, the current\r\nprocess “explorer.exe” that QBot injected, as well as a full list of currently running processes in key “33”. The value of key\r\n“14” is a random string that is used to verify the data in the response packet.\r\nQBot also sends the following packet to the C2 server to see if it needs to be upgraded.\r\n“{\"8\":1,\"1\":17,\"2\":\"rvhdls712290\",\"3\":\"spx97\",\"4\":804,\"5\":127,\"10\":\"1586971769\",\"6\":40396,\"7\":99854,\"14\":\"IZpI9ARmSpWOyXuQFppgXpuz\r\nThe server parses the packet and may reply with a packet of type “8”:6 that includes a new version of QBot. The new QBot\r\nis base64 encoded and sealed in key “20”. This packet has a key, “19”, whose value is 19, is a function index that will be\r\ncalled to handle the new QBot.\r\nFigure 3.4 is a partial section of the packet “8”:6. You can check out the key values that I explained earlier.\r\nThe value of key “15” is a base64 encoded verification data that is related to key “14” in the request packet. It’s a SHA1\r\nvalue of the transformed “14” value.\r\nFigure 3.4. The packet with new QBot\r\nAfter it passes the verification of key “15”, it continues to call the indexed function (key “19”) to base64-decode the new\r\nQBot, and then saves it to a local file. It then executes the new QBot with parameter “/W”, which checks if it runs on a\r\ndebug, checks the validity of the core module (i.e “307” resource) by extracting resource “307”, and further extracts\r\nresource “308” to see if they work well. It then exits with exit code 0x6F if it passed the check and the current QBot detects\r\nthe exit code. If it is not 0x6F, it drops the new QBot file and asks for another one from the C2 server. Otherwise, it replaces\r\nthe current QBot file with the new one, which is then executed. \r\nFinally, before the current QBot exits its host process “explorer.exe”, it sends an “8”:2 packet to inform the C2 server of the\r\nstatus, as shown below.\r\n\"{\"8\":2,\"1\":17,\"2\":\"rvhdls712290\",\"3\":\"spx97\",\"18\":1,\"40\":0}”.\r\nCollecting Software Information and Certificates from the Victim’s Device\r\nQBot starts three worker threads. In the first thread function, QBot calls a number of APIs to read out installed certificates\r\nand private keys from the victim’s device. The related APIs are exported from Crypt32.dll:\r\nCertEnumSystemStore(), CertOpenStore(), CertGetCertificateContextProperty(), CertDuplicateCertificateContext(),\r\nCertGetNameStringW(), CertGetCertificateContextProperty(), CertGetEnhancedKeyUsage(), CryptFindOIDInfo(),\r\nCryptAcquireCertificatePrivateKey(), CertCreateCertificateChainEngine(), CertAddCertificateContextToStore(),\r\nPFXExportCertStore(), CertEnumCertificatesInStore(),  and so on.\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-qbot-campaign\r\nPage 6 of 12\n\nFigure 4.1. Installed certificates in my analysis device\r\nAPI CertEnumSystemStore() calls a call-back function to repeat obtaining all the certificates, one by one, as shown in\r\nFigure 4.1. It puts one obtained certificate in a structure block, gets RC4 encrypted, and saves it to a file named\r\n“mavrihvu32.dll” in its home folder (“%AppData%\\Microsoft\\Vhdktrbeex\\” in my test environment.)\r\nFigure 4.2. A certificate is about to perform RC4 encryption\r\nFigure 4.2 displays one obtained certificate in a data structure, where “t=c1” is the data type, “time=” is the obtained time,\r\n“cert_name=” is the name of certificate, and “cert_data=” is the binary data of the certificate in hex, which is about to\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-qbot-campaign\r\nPage 7 of 12\n\nperform RC4 encryption. It then appends one encrypted certificate block to the file “mavrihvu32.dll”. As a result, the file\r\ncontent consists of many different encrypted certificate blocks.\r\nBefore calling those API functions to obtain certificates, it makes some hooks to APIs such as DialogBoxParamW(),\r\nMessageBoxW(). Calling them will pop up a warning or information box for the victim, which might be called during\r\ncalling those certificate APIs. QBot uses several hook functions to receive and stop the warning or information box from\r\ndisplaying to the victim. \r\nThe second worker thread collects information about the installed software on the victim’s device. It navigates to the sub-key “HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Uninstall” in the system registry, which contains all installed\r\nsoftware information. QBot collects the software name and version information and puts them into a structure with some\r\nbasic information about the victim’s device. Below is an example of the data.\r\nt=i1 time=[09:59:06-15/05/2020] ext_ip=[{public IP}] dnsname=[?] hostname=[{computer name}] user=[] domain=[]\r\nis_admin=[YES] os=[6.1.1.7601.1.0.0100] qbot_version=[0324.127] install_time=[09.28.44-14/05/2020] exe=\r\n[C:\\Windows\\explorer.exe] prod_id=[NULL] iface_0=[10.0.2.15/10.0.2.15] UP]  soft=[Microsoft Visual Studio 2015 XAML\r\nVisual Diagnostics;14.0.25431|Windows Espc Resource Package;14.0.23107|Google Chrome;81.0.4044.138|FileZilla\r\nClient 3.38.1;3.38.1|…]\r\nAs you may have noticed, this information contains a data type (“t=i1”) about collected certification, QBot installation time,\r\nvictim’s public IP, OS version, QBot version, current process name, local IP information, as well as an amount of collected\r\nsoftware information (“soft=[{software name};{version}|{others} …]”).\r\nFinally, QBot appends this data to the file “mavrihvu32.dll” where it already has the obtained certificates data. It then\r\ncompresses the entire content of “mavrihvu32.dll” with zlib and saves it into a new file called “cmavrihvu32.dll”.\r\nMeanwhile, it deletes the old file “mavrihvu32.dll” and runs up a third thread, a transmission thread whose function index is\r\n0x15, to send the collected data to a C2 server.\r\nFigure 4.3. QBot sending the file content of cmavrihvu32.dll.\r\nFigure 4.3 is a screenshot of QBot sending cmavrihvu32.dll to its C2 server in the transmission thread. The packet type is\r\n“8”:7, and the total packet size is 0x824C9. This time, the URL of the C2 server is “hxxps://173[.]3[.]132[.]17:995/t3”. The\r\nvalue of key “36” is the file content of cmavrihvu32.dll, which is both RC4 encrypted and base64 encoded.\r\nOnce all of the above the work is done, it deletes the “cmavrihvu32.dll” file as well.\r\nLoading a Submodule by the Core Module\r\nThis is where things begin to get more interesting. We observed that QBot can now obtain additional data from its C2 server,\r\nwhich can then be saved into local files. In my analysis device, the files were “pfllperc.myt”, “ebofekzl.utb”. Figure 5.1\r\nshows the two local files.\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-qbot-campaign\r\nPage 8 of 12\n\nFigure 5.1. Two received files in QBot’s home folder\r\nThe file names are random, but unique for each device. They are generated from the device information and user name.\r\n“pfllperc.myt” contains two Dll files (submodules) that are base64 encoded and RC4 encrypted. They can be processed in an\r\nindex function once QBot receives the packets. Nevertheless, a more regular way to process this submodule is that QBot\r\nloads them from the local file in the core module. This is also my way to analyze them. \r\nThe file is processed in the core module’s main thread function, where it decrypts the file and extracts submodules into\r\nmemory. It then loads into a newly created process, such as “explorer.exe”, just like how the core module is loaded in\r\n“explorer.exe”. The submodule’s entry point is called at last.\r\nThe submodule (injector) that runs in “explorer.exe” contains two binary resources, which are the same module for different\r\nplatforms: \"RES_DATA_1\" is for 32-bit platform and \"RES_DATA_2\" is for 64-bit. They are both Dll files (injection-modules), which will be injected into other processes to run. My analysis environment is a 32-bit Windows 7. Therefore, the\r\nresource \"RES_DATA_1\" is extracted into the memory.\r\nNext, the submodule enumerates the running processes and tries to inject the “RES_DATA_1” (injection-module) into them\r\nand execute as quickly as it can (because it has no permission to inject into those high level processes).\r\nTo do this, it calls several APIs, such as CreateToolhelp32Snapshot(), Process32First(), and Process32Next(), and it calls a\r\ncallback function to do the injection once one process is captured. Figure 5.2 displays a pseudo code of it doing this.\r\nFigure 5.2. Pseudo code to enumerate the running processes\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-qbot-campaign\r\nPage 9 of 12\n\nIn the callback function, it copies the injection-module into a new memory space of the target process. It also reads the file\r\n“ebofekzl.utb” and copies its content into the target process too. Decrypting the file “ebofekzl.utb”, we can see it contains a\r\nlarge number of groups of JavaScript code that could be injected into some web pages that the victim is on. \r\nIt then copies a local function into the target process and calls the API CreateRemoteThread to run it in a remote thread. The\r\nfunction is a loader that is used to quietly load the copied injection-module into an executable and execute it in the target\r\nprocess. Its argument is a data block that includes some basic information, like the base address of the copied injection-module, the file content of “ebofekzl.utb”, the QBot process full path, and so on.\r\nThe injector module performs these steps to inject the injection-module into a process, and it then executes within them to\r\nsteal more useful information from the victim. In addition, the injector module enumerates the processes every second\r\n(Sleep(1000)) for the upcoming processes.\r\nInjection-Modules at Work on a Victim’s Device\r\nOnce the injection-module executes in a target process, it makes a group of hooks to key APIs. These include\r\nTranslateMessage(), GetClipboardData(), GetMessage(), HttpSendRequest(), InternetReadFile(), InternetReadFileEx(),\r\nInternetQueryDataAvailable(), HttpOpenRequest(), HttpSendRequestEx(), and InternetWriteFile(). It also includes some\r\nAPIs from nss3.dll or nspr4.dll for FireFox, including PR_OpenTCPSocket(), PR_Read(), and PR_Write(), as well as\r\nseveral APIs for Chrome.\r\nThe local hook function definitions for some of the hooked API functions are shown in Figure 6.1.\r\nFigure 6.1 Partial list of the hook function definitions\r\nThrough the local hook function of GetClipboardData() and TranslateMessage(), QBot is able to obtain the victim’s data\r\nfrom the system clipboard, as well as keystrokes (key logger).\r\nTo analyze how it does this, I opened a Notepad application and copied \u0026 pasted something into it so the data was in the\r\nsystem clipboard. The local hook function actually captures the clipboard data earlier than Notepad, and the injection-module puts the data into following structure:\r\nt=kb time=[11:33:54-11/06/2020] p=[C:\\Windows\\system32\\notepad.exe] t=[Untitled - Notepad] b=[my account:\r\n11111111111\u003c0D\u003e\u003c0A\u003epw: my_password]\r\n“t=kb” is data type, “time” is record time, “p” is the full path of the process where the paste happened, “t” is the title of the\r\napplication, “b” is the data that I had copy \u0026 pasted into the Notepad. Keylogger records have the same structure as the\r\nclipboard, except that the value of “b” is replaced with what the victim types.\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-qbot-campaign\r\nPage 10 of 12\n\nNext, the data is RC4 encrypted and saved into a local file, named “mavrihvu32.dll”. Are you familiar with this file? Yes, it\r\nwas used to store the collected certificates and installed software from the victim’s device, which I explained earlier. The\r\nsame process occurs here: the injection-module keeps recording data and saving it to this file, and meanwhile, the\r\ntransmission thread in the core module keeps reading this file and compressing it with zlib into the file “cmavrihvu32.dll”.\r\nAnd finally, it is sent to the C2 server within packet “8”:7 (refer to Figure 4.3 for more information.) By the way, the\r\ntransmission thread (function index 0x15) starts from time to time to check if “mavrihvu32.dll” exists.\r\nQBot provides three groups of APIs for most popular browsers, such as Google Chrome, Microsoft IE, Microsoft Edge, and\r\nMozilla Firefox.\r\nFigure 6.2. An entire injection data block for one website\r\nFigure 6.2 shows one injected data block for one website whose URL is in the “set_url” item. Let me explain when and how\r\nthe injected data is processed. When the victim is accessing a website that matches the one defined in “set_url”, the local\r\nhook function obtains the response html source code. It then finds the “\u003chead\u003e” label that defines between “data_before”\r\nand “data_end” in the html source code. The injection-module modifies the html source code and injects the JavaScript code\r\nbetween “data_inject” and “data_end” into the labels “\u003chead\u003e” and “\u003c/head\u003e”. Finally, the local hook function replies with\r\nthe new html source code to the browser, where the injected malicious JavaScript code gets executed when the browser\r\ndisplays the page. \r\nNote: The entire data set used for injecting JavaScript data (“ebofekzl.utb”) is kept encrypted in the target process memory\r\nuntil it access to a website is completed. After going through the data, we determined that the campaign was intercepting\r\ndata destined to more than forty financial websites, two stock trading platforms, two online shopping websites, as well as\r\none telecommunications company. Fortinet has shared this intelligence with relevant law enforcement agencies.\r\nFigure 6.3. Malicious JavaScript code is injected into the html source code\r\nFigure 6.3 shows an example where the injected JavaScript code has been injected into the html source code within the red\r\nrectangle. I found this when I accessed an online shopping website in Microsft IE browser. The injection action is performed\r\nin a local hook function of the API InternetQueryDataAvailable(). As you can see, the victim ID “rvhd1s712290” was used\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-qbot-campaign\r\nPage 11 of 12\n\nin communication with the C2 server inside the malicious JavaScript code to help the C2 server recognize the victim, which\r\nis called “fakebotid” here. \r\nFor browsers Google Chrome and Mozilla Firefox, the injection action happens in different hook functions other than API\r\nInternetQueryDataAvailable() because they implement their own network communication API functions than those\r\nMicrosoft IE uses that are provided default by Windows OS. \r\nUpdates to This QBot Payload File\r\nAs I mentioned before, the QBot payload file has been frequently updated since I started analyzing this variant. The latest\r\nversion of the core module (resource “307”) was compiled on May 28, 2020. It has enriched its feature on detecting if it is in\r\nan analysis environment. For example, it added detecting if one of 37 different analysis tools are running, including\r\nFiddler.exe, Ollydbg.exe, lordpe.exe, regshot.exe, Autoruns.exe, dsniff.exe, VBoxTray.exe, x32dbg.exe, Tcpview.exe, and so\r\non. Once one of those processes is running, it returns 1 as the exit code of the process using the “/C” parameter that I\r\nexplained in Part I of this analysis.\r\nConclusion\r\nIn this analysis, I provided more details on how the core module collects data from the victim’s device, how the core module\r\nextracts submodules, as well as how it injects the injection-module into other processes. I also explained that QBot was able\r\nto collect system clipboard data and keystrokes from the victim’s device in real-time through the injection-module injected\r\nin many processes. And finally, I gave an example to show how it injects its malicious JavaScript into a web page.\r\nFrom my analysis, we can safely say that the developer of QBot is super careful. QBot performs numerous checks (for\r\nexample, with “/C, /W” parameters) before performing a malicious action. It also wipes its footprints from time to time to\r\nevade detection. All of the intermediate data is also encrypted, and files are deleted immediately after use.\r\nSolution\r\nThe C2 servers used by QBot are already added to FortiGuard IP reputation database. In addition, Fortinet customers\r\nrunning FortiGate are already protected because it already blocks all traffic to these C2 servers.\r\nFortiGuard Labs has also shared our findings with relevant law enforcement agencies in order to communicate the issues we\r\nidentified concerning targeted organizations.\r\nLearn more about FortiGuard Labs threat research and the FortiGuard Security Subscriptions and Services portfolio. Sign\r\nup for the weekly Threat Brief from FortiGuard Labs. \r\nLearn more about Fortinet’s free cybersecurity training initiative or about the Fortinet Network Security Expert\r\nprogram, Network Security Academy program, and FortiVet program.\r\nSource: https://www.fortinet.com/blog/threat-research/deep-analysis-qbot-campaign\r\nhttps://www.fortinet.com/blog/threat-research/deep-analysis-qbot-campaign\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.fortinet.com/blog/threat-research/deep-analysis-qbot-campaign"
	],
	"report_names": [
		"deep-analysis-qbot-campaign"
	],
	"threat_actors": [],
	"ts_created_at": 1775434091,
	"ts_updated_at": 1775826757,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/13aa8444334f57aee755e5679807c3e9ec96975f.pdf",
		"text": "https://archive.orkl.eu/13aa8444334f57aee755e5679807c3e9ec96975f.txt",
		"img": "https://archive.orkl.eu/13aa8444334f57aee755e5679807c3e9ec96975f.jpg"
	}
}