{ "id": "b14522d3-ae95-4c2b-bc46-14153eda662f", "created_at": "2026-04-06T01:31:44.442341Z", "updated_at": "2026-04-10T13:11:40.26428Z", "deleted_at": null, "sha1_hash": "8c07515bff49058298298366cbfa89478d71b47f", "title": "Tracking 15 Years of Qakbot Development | ThreatLabz", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1057185, "plain_text": "Tracking 15 Years of Qakbot Development | ThreatLabz\r\nBy Javier Vicente Vallejo\r\nPublished: 2024-01-31 · Archived: 2026-04-06 00:10:49 UTC\r\nNetwork Communication\r\nQakbot has leveraged HTTP for C2 communication from the beginning. However, the network protocol on top of\r\nHTTP has changed significantly over the years with encryption, RSA signature verification, and the addition of a\r\nJSON-based message format.\r\nNetwork protocol and encryption\r\nQakbot has continuously updated its message protocol with version 19 being the latest. The protocol specifies the\r\nformat of the message. In version 3, Qakbot sent requests in a format similar to the following:\r\nprotoversion=9\u0026r=1\u0026n=kvtjmq970452\u0026os=6.1.1.7601.1.0.0100\u0026bg=b\u0026it=3\u0026qv=0300.288\u0026ec=1453922906\u0026av=0\u0026salt=qrTMyfvp\r\nHowever, this protocol format was later replaced with a JSON-based protocol with integer key values that denote\r\nspecific fields as shown below:\r\n{\r\n \"8\":1,\r\n \"5\":1035,\r\n \"1\":19, // protocol version\r\n \"59\":0,\r\n \"3\":\"obama259\",\r\n \"4\":1028,\r\n \"10\":1683022694,\r\n \"2\":\"kqsvfc505763\",\r\n \"6\":59661,\r\n \"14\":\"Xgd1KxZQKTHGB6IxwtIy2e0RAq4iFNE6w6\",\r\n \"7\":16759,\r\n \"101\":1,\r\n \"26\":\"WORKGROUP\",\r\n \"73\":0\r\n}\r\nThis encoding adds a layer of obfuscation for each of the message fields.\r\nQakbot’s network encryption has used RC4 with the key consisting of 16 random bytes concatenated with a\r\nhardcoded salt and hashed using SHA1. The most recent version of Qakbot now uses AES encryption with the key\r\nhttps://www.zscaler.com/blogs/security-research/tracking-15-years-qakbot-development\r\nPage 1 of 6\n\nconsisting of 16 random bytes concatenated with a hardcoded salt and hashed using SHA256. After encryption,\r\nthe data is Base64 encoded and prepended to a variable in the body of an HTTP POST request.\r\nDomain generation algorithm\r\nThe first versions of Qakbot only used hardcoded C2s as shown in Figure 7.\r\nFigure 7. Example of hardcoded Qakbot C2s\r\nHowever, in version 2.0.1 a DGA was added as a backup C2 channel in the event that the hardcoded C2s were\r\nunreachable. Qakbot used a time-based DGA to generate up to 5,000 C2 domains for a specific date interval as\r\nshown in Figure 8.\r\nhttps://www.zscaler.com/blogs/security-research/tracking-15-years-qakbot-development\r\nPage 2 of 6\n\nFigure 8. Qakbot DGA code\r\nInterestingly, some versions of Qakbot would generate fake domains if an analysis environment was detected in an\r\neffort to mislead researchers, as shown in Figure 9.\r\nhttps://www.zscaler.com/blogs/security-research/tracking-15-years-qakbot-development\r\nPage 3 of 6\n\nFigure 9. Example of Qakbot generating fake domains if network monitoring tools were detected\r\nData exfiltration to compromised FTP servers\r\nQakbot versions 3.0.0 and earlier used compromised FTP servers to exfiltrate data rather than sending the data\r\ndirectly to their C2 server. The FTP credentials were stored in Qakbot’s configuration files as shown below:\r\n22=:xxx@credsuser1.com::\r\n23=:xxx@credsuser2.com::\r\n24=:xxx@credsuser3.com::\r\n25=:xxx@credsuser4.com::\r\n26=\r\n3=1581496845\r\nThis design had an inherent weakness since anyone with the FTP credentials could potentially have accessed and\r\nrecovered the stolen information. To address this weakness, Qakbot was later updated to send the stolen data\r\ndirectly to Qakbot’s C2 infrastructure.\r\nUsing compromised systems as relays\r\nAfter version 3.2.4.8, Qakbot ceased using the DGA. Instead, Qakbot started using compromised systems\r\nthemselves as C2 servers, and embedded a list of IP addresses and port numbers in the malware configuration.\r\nhttps://www.zscaler.com/blogs/security-research/tracking-15-years-qakbot-development\r\nPage 4 of 6\n\nBefore version 4.0.3.2, the configuration file (stored as an encrypted resource) contained the list of IP addresses in\r\na text-based format:\r\n45.45.105.94;0;443\r\n86.107.20.14;0;443\r\n99.228.5.106;0;443\r\n184.191.62.24;0;995\r\n47.153.115.154;0;995\r\n206.169.163.147;0;995\r\n96.35.170.82;0;2222\r\n73.210.114.187;0;443\r\n75.70.218.193;0;443\r\n…\r\nHowever, after version 4.0.3.2, the Qakbot C2 list evolved into a binary format as shown in Figure 10.\r\nFigure 10. Qakbot C2 list binary format\r\nCommands\r\nIn the first versions of Qakbot, the server sent commands in a descriptive text-based format. The following\r\ncommands were supported in Qakbot versions 1.0 and 2.0:\r\ncertssave\r\nckkill\r\ncksave\r\nclearvars\r\ncron\r\ncronload\r\ncronsave\r\nforceexec\r\nftpwork\r\ngetip\r\ninstall3\r\ninstwd\r\nkill\r\nhttps://www.zscaler.com/blogs/security-research/tracking-15-years-qakbot-development\r\nPage 5 of 6\n\nkillall\r\nloadconf\r\nnbscan\r\npsdump\r\nreload\r\nrm\r\nsaveconf\r\nsleep\r\nsocks\r\nsxordec\r\nsxorenc\r\nsysinfo\r\nthkill\r\nthkillall\r\nuninstall\r\nupdate\r\nupdate_finish\r\nuploaddata\r\nvar\r\nwget\r\nIn order to obfuscate these commands, the Qakbot author replaced these string commands with integer values\r\nstarting in the later builds of version 3.\r\nAddition of RSA signature verification\r\nQakbot version 3.0.0.443 introduced RSA digital signatures (initially using the MatrixSSL library) to prevent\r\ntampering. This was especially important when the DGA and compromised systems were used as C2 servers.\r\nSource: https://www.zscaler.com/blogs/security-research/tracking-15-years-qakbot-development\r\nhttps://www.zscaler.com/blogs/security-research/tracking-15-years-qakbot-development\r\nPage 6 of 6\n\nThe first versions Figure 7. Example of Qakbot of hardcoded only used hardcoded Qakbot C2s as C2s shown in Figure 7. \nHowever, in version 2.0.1 a DGA was added as a backup C2 channel in the event that the hardcoded C2s were\nunreachable. Qakbot used a time-based DGA to generate up to 5,000 C2 domains for a specific date interval as\nshown in Figure 8. \n Page 2 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://www.zscaler.com/blogs/security-research/tracking-15-years-qakbot-development" ], "report_names": [ "tracking-15-years-qakbot-development" ], "threat_actors": [ { "id": "eb3f4e4d-2573-494d-9739-1be5141cf7b2", "created_at": "2022-10-25T16:07:24.471018Z", "updated_at": "2026-04-10T02:00:05.002374Z", "deleted_at": null, "main_name": "Cron", "aliases": [], "source_name": "ETDA:Cron", "tools": [ "Catelites", "Catelites Bot", "CronBot", "TinyZBot" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775439104, "ts_updated_at": 1775826700, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/8c07515bff49058298298366cbfa89478d71b47f.pdf", "text": "https://archive.orkl.eu/8c07515bff49058298298366cbfa89478d71b47f.txt", "img": "https://archive.orkl.eu/8c07515bff49058298298366cbfa89478d71b47f.jpg" } }