{
	"id": "e3340185-894d-4bfb-b21a-1c7fab5736ea",
	"created_at": "2026-04-06T00:14:07.117619Z",
	"updated_at": "2026-04-10T13:11:39.03531Z",
	"deleted_at": null,
	"sha1_hash": "a713aced8c30e377da7a4f30f3da3c9a56f70df0",
	"title": "Where is the Origin QAKBOT Uses Valid Code Signing",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 920510,
	"plain_text": "Where is the Origin QAKBOT Uses Valid Code Signing\r\nBy By: Hitomi Kimura Oct 27, 2022 Read time: 10 min (2662 words)\r\nPublished: 2022-10-27 · Archived: 2026-04-05 15:09:58 UTC\r\nA threat actor, QAKBOT, along with EMOTET, has been one of the most active threat actors over the past few years, with\r\nnumerous reports regarding its actions since it was first observed in 2007. We have reported some of them in the past,\r\nhowever, there are two things that come to mind regarding this threat. Namely, how Black Basta ransomware operators have\r\nused QAKBOT as a means of entry, and how they used the vulnerability, CVE-2022-30190, called Follina.\r\nWe have recently observed their use of modules with valid code signing by valid certificates that were issued from public\r\ntrusted certificate authorities. This indicates that the threat actor has the private key of the certain valid certificate that was\r\nused for the code signing.\r\nFor further information, here is one of the infection timelines that we have observed:\r\nFigure 1. Infection Timeline\r\nThe following sections will discuss what we have found and how to counter this threat actor’s method, which was actively\r\nobserved during June-July 2022.\r\nKey findings\r\nChecking the modules related to QAKBOT shows multiple samples that have been signed with multiple valid code signing\r\ncertificates. A look at the abused certificates also reveals that they were not issued to non-existent organizations for abuse,\r\nbut rather valid certificates issued to real existent organizations through proper process.\r\nhttps://www.trendmicro.com/en_us/research/22/j/where-is-the-origin-qakbot-uses-valid-code-signing-.html\r\nPage 1 of 7\n\nThis is not the first time we have observed the abuse of valid code signing certificates but is still uncommon and noteworthy\r\nthat a single threat actor continues to obtain multiple valid code signing certificates and their private keys intermittently.\r\nThe origin of the certificate and private key is currently unknown, but there are at least two possibilities:\r\n1. Using a traditional approach, which involves dumping and stealing private keys from infected computers\r\nQAKBOT was interested in gathering data related to certificates as mentioned in our past research, and it had\r\nthe capabilities to do so, allowing the threat actors to steal them if the victim does not use hardware tokens for\r\nkey generation in the certificate issuance steps. Also, they sometimes use Mimikatz in their operation. It has\r\nbuilt-in functions for dumping certificates and private keys.\r\nHowever, it remains unclear if they were active in private key dumping in their operation, since the threat\r\nactors may have received the certificates directly through abuse of the certificate issuance process rather than\r\nthrough private key dumps.\r\n2. Abusing the certificate issuance process, including possible identity theft\r\n The certificates being abused were issued to micro companies, including some that are unrelated to\r\ntechnology like farmers.\r\nWe also found some unusual details in the information contained in the abuse certificates:\r\nThe same free email service was used with different certificates.\r\nThe domain name of the email address was assigned a new IP address right before the certificate was\r\nissued.\r\nCode signing is used to build trust, but security teams need to be aware that an abuse of trust should be observed. Since a\r\nvalid code signing is not enough to determine that a module is safe, it might be needed to check the certificates one step\r\ndeeper, with the expectation that a malware may have a valid code signing.\r\nRevisiting the history of code signing malware and how they activate\r\nWe have most recently published a report on a case in which a legitimate anti-cheat driver with a valid code signing was\r\nabused to bypass privileges. There have been other cases that involve the abuse of code signing certificates and private keys\r\nin the past.\r\nOne of the earliest high-profile cases would be back in 2010 in the form of Stuxnet, which used valid code signing\r\ncertificates and private keys stolen from several real existing companies.\r\nThe Flameopen on a new tab malware is another notable case in which fakes were crafted used hash collision. In that case,\r\nan MD5 hash collision crafted one of the most trusted certificates, a Microsoft code signing certificate, which then was used\r\nto sign the APT malware. This technique was very sophisticated but could be identified because the details of the certificate\r\ndiffered from the original.\r\nIn addition to what was mentioned above, our research back in 2018 covered other ways to obtain valid trusted certificates.\r\nThe research found that threat actors could mimic a legitimate organization to obtain a certificated issued by a trusted\r\ncertificate authority (CA), and those certificates and private keys are sold on the black market.\r\nFinally, a research by Kim Doowon of the University of Maryland, presented at the Conference on Computer and\r\nCommunications Security Conference (CSS’17), “Certificate Malware: Measuring Breaches of Trust in the Windows Code-Signing PKIopen on a new tab,” found 72 certificates with stolen private keys, 22 certificates issued by identity theft from\r\nlegitimate companies, and five certificates issued to shell companies at that time. The report identified 188,421 malware\r\ncases and analyzed 14,221 code-signed malware cases from their dataset: 10+ positive samples that had been submitted to\r\nVirusTotal from at least the period including StuxNet – 2010 through 2017, excluding PUAs.\r\nhttps://www.trendmicro.com/en_us/research/22/j/where-is-the-origin-qakbot-uses-valid-code-signing-.html\r\nPage 2 of 7\n\nThe number of abused certificates, which amounted to 72 in seven years, may seem fewer than expected. However, it shows\r\nthat the QAKbot threat actor is even more actively retrieving certificates and private keys, as we have observed at least\r\nseven certificates in use by QAKbot in just two months (June to July 2022) when this activity was most active.\r\nOn the MITRE websiteopen on a new tab, we can review past operations where code signing abuse has been observed. We\r\ncan also see a number of cases of APTs using specific few certificates. QAKbot was able to obtain access to multiple\r\nlegitimate certificates on-and-off for several years.\r\nThe kinds of certificates QAKbot use\r\nLooking at the sample observed in the timeline at the beginning of this article, it seems to be a micro-company that exists in\r\nthe Czech Republic. The email address included in the certificate used a free email service. There was another abused\r\ncertificate that used this free email service.\r\nFigure 2. An example of an abused certificate that used a free email service\r\nOne of the peculiar details is the way the domain name would be assigned a new IP address the same time the certificate was\r\nissued. At the same time, the domain name does not host any contents related to the company. Those can be indicators that\r\nmake us suspect that the certificate was issued through an unusual procedure.\r\nFigure 3. An example of an abused certificate using an email address with a domain name similar to their\r\ncompany name, but with a “co” top-level domain (TLD)\r\nIt is not a single issuer problem. A certificate for a company registered in the UK as a micro-company from an issuer other\r\nthan those listed is also abused. \r\nhttps://www.trendmicro.com/en_us/research/22/j/where-is-the-origin-qakbot-uses-valid-code-signing-.html\r\nPage 3 of 7\n\nFigure 4. An example of an abused certificate issued by another certificate authority\r\nOrigins of the abused certificates\r\nThe origins of these certificates are currently unknown, but we can suspect two possibilities:\r\nQAKbot has a function for enumerating and dumping certificates and private keys, thus having the capability to steal them\r\nif the victim does not use hardware tokens for key generation in the certificate issuance steps. Our analysis shows that they\r\nare using APIs like PFXExportCertStore(), which is used for dumping private keys.\r\nFigure 5. QAKbot calls PFXExportCertStore() for dumping private keys\r\nCobalt Strike, which they sometimes use for their operations, includes a built-in Mimikatz, which provides certificate and\r\nprivate key dumping capabilities. However, it still remains unclear if they were actually active for private key dumping in\r\ntheir operation.\r\nThe certificates being abused were then issued to micro-companies, including some unrelated to technology. The possibility\r\nof the abuse of certificate issuance process could include possible identity theft. From the observed abused certificates, it\r\nseems as if the attacker is impersonating a legitimate organization and is directly issued certificates by public trusted CAs.\r\nAnother certificate that was issued to a company registered to farmers was also observed. Although it is not unthinkable for\r\nthem to have been issued the certificate for their business, it is also possible that the threat actor stole their identity, used it,\r\nand/or abused the issuance process to be directly issued the valid certificates by the public trusted CAs. \r\nhttps://www.trendmicro.com/en_us/research/22/j/where-is-the-origin-qakbot-uses-valid-code-signing-.html\r\nPage 4 of 7\n\nFigure 6. An example of an abused certificate issued for a farmer’s company\r\nProtecting users’ private keys\r\nIn this case, the assumption that the threat actor was directly issued certificates through abuse of the certificate issuance\r\nprocess is more strongly suspected than the stealing of the private key, but the protection of private keys on the user side is\r\nstill a challenge.\r\nIn the use of code signing certificates, private key protection on the user side has been enhanced over time, but it still has a\r\nlong way to go before it can be classified as foolproof.\r\nAs mentioned above, we can see in QAKbot a function to retrieve victim’s private keys using the PFXExportCertStore()\r\nAPI, which can only export private keys if they are stored in the Windows Certificate Store with an exportable flag. In other\r\nwords, if key generation was performed using a hardware token that meets certain criteria (IC card, HSM, TPM, etc.), the\r\nprivate key is not stored in the Windows Certificate Store, so no method is provided to export and reuse the private key\r\nsince it is stored within the token.\r\nThere is a document, “Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing\r\nCertificates(v.3.1)open on a new tab” that defines things related to code signing certificates. This document is followed by\r\nCAs that issue code signing certificates and require CAs to encourage users to use tokens that meet the criteria to protect\r\ntheir private keys. According to this, prior to November 15, 2022, CAs must recommend to users that they protect their\r\nprivate keys with hardware tokens that meet the criteria and must obtain a representation from the user that they will protect\r\ntheir private key by using certified hard tokens or at least in a way to keep the key physically separate from computers until\r\na signing session can begin.\r\nSo far, we have confirmed that many companies that sell certificates for code signing issue them in a way that the key is\r\nstored on a smart card or other hardware device basically in which case the private key cannot be exported remotely.\r\nEven though everyone knows that hardware key generation provides stronger protection, software key generation that\r\nallows easy backup in the type of PKCS#12 files without the use of hardware tokens has remained popular on the user side.\r\nSome certificate issuers continue to provide this method as an option by to this day. As the last mile of protection, if the user\r\nactually imports it into the token and keeps it offline, it is left to the user themselves.\r\nThe scenario in which active abuses by threat actors are continuously observed is required to rethink the key generation and\r\ncertificate issuance methods. The baseline requirement will have stronger requirements for private key protection starting\r\nNovember 15, 2022. According to the Baseline Requirements, the CAs \"shall\" ensure the user's private key generation with\r\nhttps://www.trendmicro.com/en_us/research/22/j/where-is-the-origin-qakbot-uses-valid-code-signing-.html\r\nPage 5 of 7\n\na suitable hardware after the date. While this is a step forward compared to the scenario in which the last mile is left to the\r\nuser, the day when private key storage in software is no longer common may still be a little further away.\r\nHow is WebPKI doing?\r\nIn the previous sections, we mentioned the possibility of abuse of the certificate issuance process, which includes identity\r\ntheft. The problem that a threat actor may impersonate a real organization then being issued a certificate directly can also\r\nhappen in WebPKI, which gives TLS certificates used for HTTPS communications.\r\nWebPKI has introduced Certificate Transparency(CT) since around 2015, which means that the issuance of all public trusted\r\nserver certificates used for HTTPS is logged in the CT logs in public. This allows the CT logs to be verified by anyone from\r\nthe internet and helps detect the issuance of certificates that the domain name owner is unaware of.\r\nThus, while WebPKI can use the CT logs to check for unexpected issues of certificates for organizations, however, code\r\nsigning certificates cannot be checked in the same way because the CT mechanism has not been introduced for code signing\r\ncertificates.\r\nRegarding certificate revocation\r\nTo counter the abuse of certificates that have already been issued, the one of the options is to revoke the certificates.\r\nAccording to research made by Doowon Kim and Bum Jun Kwon in 2018 titled “The Broken Shield: Measuring Revocation\r\nEffectiveness in the Windows Code-Signing PKIopen on a new tab,” even if a code signing certificate is revoked, the\r\nsignature may remain valid due to the specifics of the revocation and verification method, which is a mechanistic challenge.\r\nAll certificates observed to have been abused in this case have been revoked at this time.\r\nHow to counter abused code signing certificates\r\nFor users:\r\nFirst, protect your private keys. The people who perform code signing store their private keys for code signing certificates\r\nusing modern best practices. The private key is stored with the appropriate hard token and stays offline until just before the\r\nsigning process begins. Modern practice also provides a service to store private keys and sign in the cloud.\r\nSecond, protect your identity. While the origin of the abused certificate is currently unknown, victims may have been\r\nimpersonated in the name of the company completely unknown to them, and the certificates issued to them may have been\r\nabused. Thus, it would be imperative if we could carefully monitor for strange things happening around us related to identity\r\ntheft. It will take some time for things to unravel but protecting yourself while the certificate issuers figure out why this is\r\nhappening will be key to avoiding abused certificate issuance.\r\nIt is possible that the threat actor has acquired a domain name similar to the company name of a real company and is using\r\nthe fact that they own the domain name to get a certificate issued. Unfortunately, there is currently no effective way to check\r\nthis case since unlike WebPKI, CT has not been implemented for code signing certificates.\r\nDetection and monitoring of abuse of trust\r\nSecurity teams need to be aware that an abuse of trust has been observed. Since a valid code signing is not enough to\r\ndetermine that a module is benign, it might be needed to check things closer, to be assured that the one with a valid code\r\nsigning is not a malware impersonating a legitimate module. \r\nhttps://www.trendmicro.com/en_us/research/22/j/where-is-the-origin-qakbot-uses-valid-code-signing-.html\r\nPage 6 of 7\n\nThe certificates confirmed to have been abused in this case had the following attributes:\r\nHad company names unrelated to technology\r\nIssued to micro-companies around the world\r\nUsed a free email service for its email address\r\nUsed an email address that contains a domain name that looks like a company name, but the domain name\r\ndoes not host any content\r\nThe top-level domain of the domain name used is not common for enterprise, like “co”\r\nAssigned a new IP address just before the certificate was issued\r\n Fortunately, these certificates can be figured to be unusual if they are carefully checked.\r\nConclusion and Trend Micro solutions\r\nQAKbot is trying to evolve into a much more intrusive malware. Its use of valid code signatures can make it hard to\r\ndetermine which files are real, and its persistence can cause further danger to machines and the network that it is connected\r\nto while the certificate issuers find a way to counteract what the trojan is doing.\r\nSince QAKbot can originate from an Excel file, make sure that macros are disabled in Microsoft applications. In addition,\r\ncheck the sender and the format of the email address to prevent email spoofing. For further protection, install Trend Micro\r\nDeep Discoveryproducts, which contains an email inspection tool. For endpoints, Trend Micro Vision Oneproducts can\r\ndetect possible persistence since QAKbot drops in via .DLL files.\r\nWith additional insights by Byron Gelera.\r\nIndicators of Compromise\r\nTrojan.Win32.QAKBOT.DRSO adadda4d61188c53c25323a3561db52d14a5dbb2585a53e18b33882f1013b9ee\r\nTrojanSpy.Win32.QAKBOT.YXCGSZ 78bc13074087f93fcc8f11ae013995f9a366b6943330c3d02f0b50c4ae96c8a7\r\nTrojanSpy.Win32.QAKBOT.SMYXCFJZ 42bc9b623f70e46d6aab4910d8c75221aecf89a00756a61b21f952eea13a446c\r\nTrojanSpy.Win32.QAKBOT.YXCCBZ 37e973699f119ce5a2047281aa6f52429bc15164abdfe110f3340ee02d4c21b5\r\nTrojanSpy.Win32.QAKBOT.SMYXCFHZ 362e56855844fb2be3dfae4b566ab676f6ec681fad1c1a2e8eb6d245d56b83f5\r\nTrojanSpy.Win32.QAKBOT.YXCCQZ 20839bc89ca241bcd77ea69a2e36e40d7c1bd0dd91952502de8cd1db6fe771e1\r\nTrojanSpy.Win32.QAKBOT.SMYXCFJZ 1beb6f15f403fe31392012b506ce1bb38424482d3e8123f0f80ae439484fffe7\r\nTags\r\nSource: https://www.trendmicro.com/en_us/research/22/j/where-is-the-origin-qakbot-uses-valid-code-signing-.html\r\nhttps://www.trendmicro.com/en_us/research/22/j/where-is-the-origin-qakbot-uses-valid-code-signing-.html\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.trendmicro.com/en_us/research/22/j/where-is-the-origin-qakbot-uses-valid-code-signing-.html"
	],
	"report_names": [
		"where-is-the-origin-qakbot-uses-valid-code-signing-.html"
	],
	"threat_actors": [
		{
			"id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d",
			"created_at": "2022-10-25T16:07:24.139848Z",
			"updated_at": "2026-04-10T02:00:04.878798Z",
			"deleted_at": null,
			"main_name": "Safe",
			"aliases": [],
			"source_name": "ETDA:Safe",
			"tools": [
				"DebugView",
				"LZ77",
				"OpenDoc",
				"SafeDisk",
				"TypeConfig",
				"UPXShell",
				"UsbDoc",
				"UsbExe"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434447,
	"ts_updated_at": 1775826699,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a713aced8c30e377da7a4f30f3da3c9a56f70df0.pdf",
		"text": "https://archive.orkl.eu/a713aced8c30e377da7a4f30f3da3c9a56f70df0.txt",
		"img": "https://archive.orkl.eu/a713aced8c30e377da7a4f30f3da3c9a56f70df0.jpg"
	}
}