{
	"id": "e8f6b023-a6ec-4b53-8a2a-a2cd3d5c7dba",
	"created_at": "2026-04-06T00:20:11.450171Z",
	"updated_at": "2026-04-10T03:20:59.042122Z",
	"deleted_at": null,
	"sha1_hash": "3b934c3be089efdfbdc82fafb1780615b7237114",
	"title": "Why You Shouldn’t Completely Trust Files Signed with Digital Certificates",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 484085,
	"plain_text": "Why You Shouldn’t Completely Trust Files Signed with Digital\r\nCertificates\r\nBy Andrey Ladikov\r\nPublished: 2015-01-29 · Archived: 2026-04-05 14:32:41 UTC\r\nA digital certificate with a file is always seen as a token of its security. For users, a digital certificate is an\r\nindication that the file does not contain malicious code. Many system administrators develop their corporate\r\nsecurity policies by allowing users to launch only those files that are signed with a digital certificate. In addition,\r\nsome antivirus scanners automatically consider a file to be secure if it is signed with a valid digital certificate.\r\nHowever, users’ absolute trust in files signed with digital certificates encourages cybercriminals to search for\r\nvarious ways to have their malicious files signed with the same trusted digital certificates to help use them in their\r\ncriminal schemes.\r\nThis article looks into the main threats associated with signed files, and suggests practical methods of mitigating\r\nthe risks associated with launching them.\r\nCreating digital signatures for files\r\nBefore we explore the threats associated with using digital certificates, let us first look into the process when a file\r\nis signed with a digital certificate:\r\n1. 1 The software developer compiles the file.\r\n2. 2 A hash sum (MD5, SHA1, or SHA2) is calculated for the file.\r\n3. 3 That hash sum is encrypted with the software developer’s private key.\r\n4. 4 The obtained encrypted block of data and the digital certificate are added to the end of the file.\r\nThe digital certificate contains the software developer’s public key, which can be used to decrypt the message and\r\ncheck the file’s integrity. It also contains information with which the software developers’ authenticity can be\r\nhttps://securelist.com/why-you-shouldnt-completely-trust-files-signed-with-digital-certificates/68593/\r\nPage 1 of 8\n\nchecked.\r\nThe authenticity of the file’s manufacturer is confirmed with the help of the Certification Authority (CA). This\r\nentity certifies to other users that the public key that decrypts the hash sum and checks the file’s integrity does\r\nindeed belong to the developer in question. To do so, the CA signs the developer’s certificate and thus testifies that\r\nthe unique pair of public and private keys belongs to that particular developer. A certificate from the CA testifying\r\nthat the file is authentic is also added to the end of the file alongside the developer’s certificate.\r\nCA certificates are verified by no one other than these entities. For Windows to trust the certificates issued by a\r\ncertain CA, that CA’s certificate must be placed into the operating system’s storage of certificates. The certificates\r\nof the most authoritative CAs have undergone an audit and are automatically included into the storage and are\r\ndelivered to users along with Windows updates. Certificates issued by other CAs can be added to the storage at the\r\ndiscretion of the user.\r\nThe use of trusted certificates by cybercriminals\r\nNow let’s look at attacks that can be carried out at each stage of signing a file. We are not interested in theoretical\r\nattacks based on the weaknesses of the encryption algorithms used to sign the file, but will concentrate instead on\r\nthe attack methods most often used by cybercriminals in practice.\r\nPlanting malicious code at the file compilation stage\r\nIn many large software companies, files are signed automatically immediately after the file compilation is\r\ncomplete. File compilation is done centrally on a dedicated Build server.\r\nIf cybercriminals gain access to a software manufacturer’s corporate network, they can use the corporate Build\r\nserver to compile a malicious file on it, so it automatically gets signed with the company’s digital signature. As a\r\nresult of this attack, cybercriminals obtain a malicious file signed with a valid digital certificate.\r\nIn practice this type of attack is quite rare because large software manufacturers have adequate security in place to\r\nprotect their Build servers. Nevertheless, there have been identified cases when targeted attacks were successfully\r\nconducted and malicious files were signed with a trusted company’s certificate.\r\nStealing a private key\r\nSometimes, cybercriminals succeed in penetrating a corporate network and gaining access to a private key used to\r\nsign files. With that key, they can sign any malicious file and pass it off as a file produced by a legal software\r\nmanufacturer.\r\nOne way to steal a private key is to use specialized malware created specifically for this purpose.\r\nAfter stealing a private key, the cybercriminal either uses it or sells it to someone else to use. The more famous the\r\nsoftware manufacturer from which the key was stolen, the more valuable the key will be among cybercriminals.\r\nSoftware from well-known manufacturers does not attract any suspicion from users and security administrators on\r\ncorporate networks.\r\nhttps://securelist.com/why-you-shouldnt-completely-trust-files-signed-with-digital-certificates/68593/\r\nPage 2 of 8\n\nAt the same time, large software manufacturer companies keep their private keys in dedicated, well-protected\r\nhardware modules, which makes it much more difficult to steal them.  As a result, private keys are typically stolen\r\nfrom smaller companies or private software manufacturers who do not pay enough attention to security.\r\nVulnerabilities in the algorithms that check executable file signatures\r\nFor an operating system to know which part of the file is supposed to contain the information about the presence\r\nof a digital certificate, the header of each signed executable file includes 8 bytes of data that contain information\r\nabout the location and the size of the digital certificate. These 8 bytes are ignored when checking the file’s\r\nsignature. If a block of data is added to the end of the file’s signature, and the size of the signature is increased by\r\nan appropriate amount, these changes also will also have no effect on the outcome of the signature check. This\r\nmakes it possible to gain extra space in a signed file where data can be added without affecting the outcome of a\r\nsignature check.\r\nThis algorithm is used actively in legal web installers: software developers who create these web installers modify\r\nthe size of the digital signature to make room for an additional block of data, so that the digital certificate block\r\nincludes a link to a file for that installer to download from the software developer’s page and install on the users’\r\nsystem. This is a practical approach for software developers because the installer does not have to be re-signed\r\neach time the link to the software distribution kit is changed: it is enough to simply change the link stored in the\r\ndigital signature block.\r\nCybercriminals, in turn, can use this algorithm for their own purposes. A cybercriminal takes a web installer for\r\nlegal software, and changes the link so a different distribution kit to be downloaded. The installer then downloads\r\nand installs malware on the user’s system. After that, the cybercriminal uploads the modified installer to software\r\ndistribution sites.\r\nhttps://securelist.com/why-you-shouldnt-completely-trust-files-signed-with-digital-certificates/68593/\r\nPage 3 of 8\n\nTo fix this vulnerability, Microsoft released a security update that enforces a rigorous check of each file’s digital\r\ncertificates. However, this update does not apply automatically because many software developers use the above\r\nalgorithm in their installers, and their software programs would be considered unsigned if this update was applied\r\nacross the board. The user can enable this update manually, if required.\r\nThe use of legally obtained certificates\r\nA few years ago, digital certificates were actively used by large software manufacturers that were legally\r\nregistered companies. Today, certificates are used increasingly often by individual software developers and small\r\ncompanies. The graph below shows how the number of certificates with which to sign software code known to\r\nKaspersky Lab changed over time. As can be seen, the number of certificates is steadily growing year on year.\r\nThe number of certificates verified by CAs and known to Kaspersky Lab\r\nThe procedure of purchasing a certificate to sign executable code is quite simple: individuals must present their\r\npassport details, and companies must present their registration details. Some certificate-issuing CAs make no\r\nfurther checks into the activities of the companies seeking to purchase the certificate. All a CA does is it issues a\r\ncertificate entitling the client to sign executable files, and verifies that the certificate has indeed been issued to the\r\nspecific person or company.\r\nThis enables cybercriminals to legally purchase a certificate to sign their malicious and/or potentially unwanted\r\nsoftware.\r\nIt is companies manufacturing potentially unwanted software that most often purchase certificates. On the one\r\nhand these companies do not manufacture malware programs, so they can legally purchase a digital certificate to\r\nhttps://securelist.com/why-you-shouldnt-completely-trust-files-signed-with-digital-certificates/68593/\r\nPage 4 of 8\n\nsign their software. On the other hand, they produce software annoys users. In fact, they get their software signed\r\nwith digital certificates precisely to encourage users to trust them.\r\nUntrusted certificates\r\nIn all cases described above, be it stealing a private key, compromising a company’s infrastructure and signing a\r\nfile with that company’s digital certificate, or purchasing a certificate with the intent of signing malware with it,\r\nthe end result is the same: a trusted certificate is used to sign a malicious file.\r\nTherefore, these certificates cannot be considered trusted in spite of the fact that their authenticity has been\r\nverified by a CA, as they were (or continue to be) used to sign malicious files. We will hereafter describe these\r\ncertificates as ‘untrusted’.\r\nIf a private key is stolen from a software developer, or a company’s infrastructure is compromised and a trusted\r\ncertificate is used to sign a malicious file, the CAs cease verifying the trustworthiness of the certificate that was\r\nearlier issued by them (a process also known as recalling the certificate). The speed of the CA’s reaction depends\r\non how soon it becomes known that the certificate has been used by somebody other than the legitimate developer.\r\nHowever, when a certificate was purchased to sign potentially unwanted software, the CAs do not always recall\r\nthe certificate. As a result the certificate could remain valid and be used to sign potentially dangerous software.\r\nThe following chart shows the proportions of untrusted certificates used to sign malware and potentially unwanted\r\nsoftware (Kaspersky Lab data).\r\nhttps://securelist.com/why-you-shouldnt-completely-trust-files-signed-with-digital-certificates/68593/\r\nPage 5 of 8\n\nBreakdown of untrusted certificate numbers by their type\r\nMethods of protection against launching software programs signed with untrusted\r\ncertificates\r\nWe have discussed the most popular cybercriminals techniques to get files signed with digital certificates.\r\nRecently we have seen an increasingly significant problem concerning malicious and potentially unwanted files\r\nbeing signed with digital certificates. In 2008, 1,500 certificates were later used to sign malware; in 2014, there\r\nwere more than 6,000 of these cases.\r\nhttps://securelist.com/why-you-shouldnt-completely-trust-files-signed-with-digital-certificates/68593/\r\nPage 6 of 8\n\nThe number of untrusted certificates known to Kaspersky Lab\r\nGiven the growing number of threats associated with malicious files signed with digital certificates, users and\r\nadministrator can no longer risk placing blind faith in signed files and just allow them to be launched simply\r\nbecause they have a digital certificate.\r\nHere are a few practical tips to reduce your chances of launching a new malware program that has a valid digital\r\ncertificate and hasn’t yet reached your anti-virus databases:\r\n1. 1\r\n1. 1.1 Only allow the launch of software programs signed by a reputable manufacturer.\r\nYou can substantially reduce the risk of infection on your computer by disabling the launch of all software\r\nprograms signed with digital certificates belonging to unknown software manufacturers. As described above,\r\ncertificates are most often stolen from smaller software companies.\r\n1. 1\r\n1. 1.1 Only allow programs to be launched after they are identified by their unique digital signature\r\nattributes.\r\nSeveral certificates issued to the same company may be distributed under the same name. If one of these\r\ncertificates is stolen from a reputable company, a check that automatically trusts well-known publishers would\r\nallow a file signed with a stolen certificate.\r\nTo prevent this from happening, before allowing programs signed with known certificates to launch, it is\r\nnecessary to check other attributes as well as the certificate name. These attributes might be the serial number or\r\nhttps://securelist.com/why-you-shouldnt-completely-trust-files-signed-with-digital-certificates/68593/\r\nPage 7 of 8\n\ncertificate fingertip (hash sum). Serial numbers are only unique within the range of certificates issued by a single\r\nCA, so we recommend checking this along with the company that issued the certificate in the first place.\r\n1. 1\r\n1. 1.1 Activate the MS13-098 security update.\r\nFor experienced users and system administrators, it is advisable to enable update MS13-098 – it fixes an error\r\nwhich enables the inclusion of additional data in a signed file without tampering with the file’s signature. To read\r\nmore about how to activate this update, follow this link to Microsoft Security Center.\r\n1. 1\r\n1. 1.1 Do not install certificates from unknown CAs into your security storage.\r\nIt is not a good idea to install root certificates from unknown CAs into your storage. If you do so, any files signed\r\nwith a certificate confirmed by that specific CA will subsequently be considered trusted.\r\n1. 1\r\n1. 1.1 Use a trusted certificates database from a security software manufacturer.\r\nSome security software manufacturers, including Kaspersky Lab, include a database of trusted and untrusted\r\ncertificates in their products; this database is updated on a regular basis along with the anti-virus databases. With\r\nthis database, you will receive prompt updates about as-yet unrecalled certificates used to sign malware and/or\r\npotentially unwanted software. Files signed with untrusted certificates from this database require enhanced\r\nmonitoring by the security product.\r\nThe database of trusted certificates includes certificates from reputable software publishers that were used to sign\r\ntrusted software programs. If a certificate is listed in this database, it is a strong indicator that corporate\r\napplication control can allow the application to launch.\r\nIf this kind of database is included in a security product it will help make the administrator’s job easier, sparing\r\nthem the need to create and maintain an in-house database of trusted certificates.\r\nThe number of digital certificates used to sign malware and/or potentially unwanted software is doubling every\r\nyear on average. That is why it is vital that companies exercise ever greater control over signed files with the help\r\nof security product tools, and follow the above security policies.\r\nSource: https://securelist.com/why-you-shouldnt-completely-trust-files-signed-with-digital-certificates/68593/\r\nhttps://securelist.com/why-you-shouldnt-completely-trust-files-signed-with-digital-certificates/68593/\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://securelist.com/why-you-shouldnt-completely-trust-files-signed-with-digital-certificates/68593/"
	],
	"report_names": [
		"68593"
	],
	"threat_actors": [],
	"ts_created_at": 1775434811,
	"ts_updated_at": 1775791259,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/3b934c3be089efdfbdc82fafb1780615b7237114.pdf",
		"text": "https://archive.orkl.eu/3b934c3be089efdfbdc82fafb1780615b7237114.txt",
		"img": "https://archive.orkl.eu/3b934c3be089efdfbdc82fafb1780615b7237114.jpg"
	}
}