{ "id": "540c804d-bc17-4cae-94f8-556f8cf15883", "created_at": "2026-04-06T01:31:47.697Z", "updated_at": "2026-04-10T03:24:29.976914Z", "deleted_at": null, "sha1_hash": "a4343d0293f9b2a61f929be6996f48811f7166ca", "title": "DirtyMoe: Code signing certificate", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1428450, "plain_text": "DirtyMoe: Code signing certificate\r\nBy Threat Research TeamThreat Research Team\r\nArchived: 2026-04-06 00:41:51 UTC\r\nAbstract\r\nThe DirtyMoe malware uses a driver signed with a revoked certificate that can be seamlessly loaded into the\r\nWindows kernel. Therefore, one of the goals is to analyze how Windows works with a code signature of Windows\r\ndrivers. Similarly, we will be also interested in the code signature verification of user-mode applications since the\r\nuser account control (UAC) does not block the application execution even if this one is also signed with a revoked\r\ncertificate. The second goal is a statistical analysis of certificates that sign the DirtyMoe driver because the\r\ncertificates are also used to sign other malicious software. We focus on the determination of the certificate’s\r\norigin, prevalence, and a quick analysis of the top 10 software signed with these certificates.\r\nContrary to what often has been assumed, Windows loads a driver signed with a revoked certificate. Moreover, the\r\nresults indicate that the UAC does not verify revocation online but only via the system local storage which is\r\nupdated by a user manually. DirtyMoe certificates are used to sign many other software, and the number of\r\nincidents is still growing. Furthermore, Taiwan and Russia seem to be the most affected by these faux signatures.\r\nOverall, the analyzed certificates can be declared as malicious, and they should be monitored. The UAC contains a\r\nsignificant vulnerability in its code signature verification routine. Therefore, in addition to the usual avoidance of\r\ndownloading from usual sources, Windows users should also not fully rely on inbuilt protections only. Due to the\r\nflawed certificate verification, manual verification of the certificate is recommended for executables requiring\r\nelevated privileges.\r\n1. Introduction\r\nThe DirtyMoe malware is a complex malicious backdoor designed to be modularized, undetectable, and\r\nuntrackable. The main aim of DirtyMoe is cryptojacking and DDoS attacks. Basically, it can do anything that\r\nattackers want. The previous study, published at DirtyMoe: Introduction and General Overview, has shown that\r\nDirtyMoe also employs various self-protection and anti-forensics mechanisms. One of the more significant\r\nsafeguards, defending DirtyMoe, is a rootkit. What is significant about the rootkit using is that it offers advanced\r\ntechniques to hide malicious activity on the kernel layer. Since DirtyMoe is complex malware and has undergone\r\nlong-term development, therefore, the malware authors have also implemented various rootkit mechanisms. The\r\nDirtyMoe: Rootkit Driver post examines the DirtyMoe driver functionality in detail.\r\nHowever, another important aspect of the rootkit driver is a digital signature. The rootkits generally exploit the\r\nsystem using a Windows driver. Microsoft has begun requiring the code signing with certificates that a driver\r\nvendor is trusted and verified by a certification authority (CA) that Microsoft trusts. Nonetheless, Windows does\r\nnot allow the loading of unsigned drivers since 64-bit Windows Vista and later versions. Although the principle of\r\nthe code signing is correct and safe, Windows allows  loading a driver that a certificate issuer has explicitly\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-3/\r\nPage 1 of 15\n\nrevoked the used certificate. The reasons for this behavior are various, whether in terms of performance or\r\nbackward compatibility. The weak point of this certificate management is if malware authors steal any certificate\r\nthat has been verified by Microsoft and revoked by CA in the past. Then the malware authors can use this\r\ncertificate for malicious purposes. It is precisely the case of DirtyMoe, which still signs its driver with stolen\r\ncertificates. Moreover, users cannot affect the codesign verification via the user account control (UAC) since\r\ndrivers are loaded in the kernel mode.\r\nMotivated by the loading of drivers with revoked certificates, the main issues addressed in this paper are analysis\r\nof mechanism how Windows operates with code signature in the kernel and user mode; and detailed analysis of\r\ncertificates used for code signing of the DirtyMoe driver.\r\nThis paper first gives a brief overview of UAC and code signing of Windows drivers. There are also several\r\nobservations about the principle of UAC, and how Windows manages the certificate revocation list (CRL). The\r\nremaining part of the paper aims to review in detail the available information about certificates that have been\r\nused to code signatures of the DirtyMoe driver.\r\nThus far, three different certificates have been discovered and confirmed by our research group as malicious.\r\nDrivers signed with these certificates can be loaded notwithstanding their revocation into the 64-bit Windows\r\nkernel. An initial objective of the last part is an analysis of the suspicious certificates from a statistical point of\r\nview. There are three viewpoints that we studied. The first one is the geological origin of captured samples signed\r\nwith the malicious certificate. The second aspect is the number of captured samples, including a prediction factor\r\nfor each certificate. The last selected frame of reference is a statistical overview about a type of the signed\r\nsoftware because the malware authors use the certificates to sign various software, e.g., cracked software or other\r\npopular user applications that have been patched with a malicious payload. We have selected the top 10 software\r\nsigned with revoked certificates and performed a quick analysis. Categories of this software help us to ascertain\r\nthe primarily targeted type of software that malware authors signed. Another significant scope of this research is\r\nlooking for information about companies that certificates have probably been leaked or stolen.\r\n2. Background\r\nDigital signatures are able to provide evidence of the identity, origin, and status of electronic documents, including\r\nsoftware. The user can verify the validity of signatures with the certification authority. Software developers use\r\ndigital signatures to a code signing of their products. The software authors guarantee via the signature that\r\nexecutables or scripts have not been corrupted or altered since the products have been digitally signed. Software\r\nusers can verify the credibility of software developers before run or installation.\r\nEach code-signed software provides information about its issuer, and an URL points to the current certificate\r\nrevocation list (CRL) known as the CRL Distribution Point. Windows can follow the URL and check the validity\r\nof the used certificate. If the verification fails, the User Account Control (UAC) blocks software execution that\r\ncode-signature is not valid. Equally important is the code-signature of Windows drivers that use a different\r\napproach to digital signature verification. Whereas user-mode software signatures are optional, the Windows\r\ndriver must be signed by a CA that Windows trusts. Driver signing is mandatory since 64-bit Windows Vista.\r\n2.1 User Account Control and Digital Signature\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-3/\r\nPage 2 of 15\n\nWindows 10 prompts the user for confirmation if the user wants to run software with high permission. User\r\nAccount Control (UAC) should help to prevent users from inadvertently running malicious software or other types\r\nof changes that might destabilize the Windows system. Additionally, UAC uses color coding for different\r\nscenarios – blue for a verified signature, yellow for an unverified, and red for a rejected certificate; see Figure 1.\r\nFigure 1: UAC of verified, unverified, and rejected software requiring the highest privileges\r\nUnfortunately, users are the weakest link in the safety chain and often willingly choose to ignore such warnings.\r\nWindows itself does not provide 100% protection against unknown publishers and even revoked certificates. So,\r\nuser’s ignorance and inattention assist malware authors.\r\n2.2 Windows Drivers and Digital Signature\r\nCertificate policy is diametrically different for Windows drivers in comparison to other user-mode software. While\r\nuser-mode software does not require code signing, code signing is mandatory for a Windows driver; moreover, a\r\ncertificate authority trusted by Microsoft must be used. Nonetheless, the certificate policy for the windows drivers\r\nis quite complicated as MSDN demonstrates [1].\r\n2.2.1 Driver Signing\r\nHistorically, 32-bit drivers of all types were unsigned, e.g., drivers for printers, scanners, and other specific\r\nhardware. Windows Vista has brought a new signature policy, but Microsoft could not stop supporting the legacy\r\ndrivers due to backward compatibility. However, 64-bit Windows Vista and later has to require digitally signed\r\ndrivers according to the new policy. Hence, 32-bit drivers do not have to be signed since these drivers cannot be\r\nloaded into the 64-bit kernels. The code signing of 32-bit drivers is a good practice although the certificate policy\r\ndoes not require it.\r\nMicrosoft has no capacity to sign each driver, more precisely file, provided by third-party vendors. Therefore, a\r\ncross-certificate policy is used to provide an instrument to create a chain of trust. This policy allows the release of\r\na subordinate certificate that builds the chain of trust from the Microsoft root certification authority to multiple\r\nother CAs that Microsoft accredited. The current cross-certificate list is documented in [2]. In fact, the final driver\r\nsignature is done with a certificate that has been issued by the subordinate CA, which Microsoft authorized.\r\nThe examples of the certificate chain illustrates Figure 2 and the following output of signtool ;\r\nsee Figure 3.\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-3/\r\nPage 3 of 15\n\nFigure 2: Certification chain of one Avast driver\r\nFigure 3: Output of signtool.exe for one Avast driver\r\n2.2.2 Driver Signature Verification\r\nFor user-mode software, digital signatures are verified remotely via the CRL list obtained from certificate issuers.\r\nThe signature verification of Windows drivers cannot be performed online compared with user-mode software\r\nbecause of the absence of network connection during the kernel bootup. Moreover, the kernel boot must be fast\r\nand a reasonable approach to tackle the signature verification is to implement a light version of the verification\r\nalgorithm.\r\nThe Windows system has hardcoded root certificates of several CAs and therefore can verify the signing\r\ncertificate chain offline. However, the kernel has no chance to authenticate signatures against CRLs. The same is\r\napplied to expired certificates. Taken together, this approach is implemented due to kernel performance and\r\nbackward driver compatibility. Thus, leaked and compromised certificates of a trusted driver vendor causes a\r\nsevere problem for Windows security.\r\n3. CRL, UAC, and Drivers\r\nAs was pointed out in the previous section, CRL contains a list of revoked certificates. UAC should verify the\r\nchain of trust of run software that requires higher permission. The UAC dialog then shows the status of the\r\ncertificate verification. It can end with two statuses, e.g., verified publisher or unknown publisher [3], see Figure\r\n1.\r\nHowever, we have a scenario where software is signed with a revoked certificate and run is not blocked by UAC.\r\nMoreover, the code signature is marked as the unknown publisher (yellow titled UAC), although the certificate is\r\nin CRL.\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-3/\r\nPage 4 of 15\n\n3.1 Cryptographic Services and CRL Storage\r\nCryptographic Services confirms the signatures of Windows files and stores file information into the C:\\Users\\\r\n\u003cuser\u003e\\AppData\\LocalLow\\Microsoft\\CryptnetUrlCache folder, including the CRL of the verified file. The\r\nCryptnetUrlCache folder (cache) is updated, for instance, if users manually check digital signatures via\r\n“Properties -\u003e Digital Signature” or via the signtool tools, as Figure 3 and Figure 4 illustrate. The certificate\r\nverification processes the whole chain of trust, including CRL and possible revocations deposits in the cache\r\nfolder.\r\nFigure 4: List of digital signature via Explorer\r\nAnother storage of CRLs is Certificate Storage accessible via the Certificate Manager Tool; see\r\nFigure 5. This storage can be managed by local admin or domain.\r\nFigure 5: Certificate Manager Tool\r\n3.2 CRL Verification by UAC\r\nUAC itself does not verify code signature, or more precisely chain of trust, online; it is probably because of\r\nsystem performance. The UAC codesign verification checks the signature and CRL via CryptnetUrlCache and\r\nthe system Certificate storage . Therefore, UAC marks malicious software, signed with the revoked\r\ncertificate, as the unknown publisher because CryptnetUrlCache is not up-to-date initially.\r\nSuppose the user adds appropriate CRL into Certificate Storage manually using this command:\r\ncertutil -addstore -f Root CSC3-2010.crl\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-3/\r\nPage 5 of 15\n\nIn that case, UAC will successfully detect the software as suspicious, and UAC displays this message: “An\r\nadministrator has blocked you from running this app.” without assistance from Cryptographic Services and\r\ntherefore offline.\r\nThe Windows update does not include CRLs of cross-certificate authorities that Microsoft authorized to codesign\r\nof Windows files. This fact has been verified via Windows updates and version as follow:\r\nWindows Malicious Software Removal Tool x64 – v5.91 (KB890830)\r\n2021-06 Cumulative update for Windows 10 Version 20H2 for x64-based System (KB5003690)\r\nWindows version: 21H1 (OB Build 19043.1110)\r\nIn summary, UAC checks digital signatures via the system local storage of CRL and does not verify code\r\nsignature online.\r\n3.3 Windows Driver and CRL\r\nReturning briefly to the codesign of the Windows driver that is required by the kernel. The kernel can verify the\r\nsignature offline, but it cannot check CRL since Cryptographic Services and network access are not available at\r\nboot time.\r\nTurning now to the experimental evidence on the offline CRL verification of drivers. It is evident in the case\r\ndescribed in Section 3.2 that UAC can verify CRL offline. So, the tested hypothesis is that the Windows kernel\r\ncould verify the CRL of a loaded driver offline if an appropriate CRL is stored in Certificate Storage . We used\r\nthe DirtyMoe malware to deploy the malicious driver that is signed with the revocated certificate. The\r\ncorresponding CRL of the revoked certificate has been imported into Certificate Storage . However, the driver\r\nwas still active after the system restart. It indicates that the rootkit was successfully loaded into the kernel,\r\nalthough the driver certificate has been revoked and the current CRL was imported into Certificate Storage .\r\nThere is a high probability that the kernel avoids the CRL verification even from local storage.\r\n4. Certificate Analysis\r\nThe scope of this research are three certificates as follow:\r\nBeijing Kate Zhanhong Technology Co.,Ltd.\r\nValid From: 28-Nov-2013 (2:00:00)\r\nValid To: 29-Nov-2014 (1:59:59)\r\nSN: 3c5883bd1dbcd582ad41c8778e4f56d9\r\nThumbprint: 02a8dc8b4aead80e77b333d61e35b40fbbb010a0\r\nRevocation Status: Revoked on 22-May-2014 (9:28:59)\r\nCRL Distribution Point: http://cs-g2-crl.thawte.com/ThawteCSG2.crl\r\nIoCs:\r\n88D3B404E5295CF8C83CD204C7D79F75B915D84016473DFD82C0F1D3C375F968\r\n376F4691A80EE97447A66B1AF18F4E0BAFB1C185FBD37644E1713AD91004C7B3\r\n937BF06798AF9C811296A5FC1A5253E5A03341A760A50CAC67AEFEDC0E13227C\r\n \r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-3/\r\nPage 6 of 15\n\nBeijing Founder Apabi Technology Limited\r\nValid From: 22-May-2018 (2:00:00)\r\nValid To: 29-May-2019 (14:00:00)\r\nSN: 06b7aa2c37c0876ccb0378d895d71041\r\nThumbprint: 8564928aa4fbc4bbecf65b402503b2be3dc60d4d\r\nRevocation Status: Revoked on 22-May-2018 (2:00:01)\r\nCRL Distribution Point: http://crl3.digicert.com/sha2-assured-cs-g1.crl\r\nIoCs:\r\nB0214B8DFCB1CC7927C5E313B5A323A211642E9EB9B9F081612AC168F45BF8C2\r\n5A4AC6B7AAB067B66BF3D2BAACEE300F7EDB641142B907D800C7CB5FCCF3FA2A\r\nDA720CCAFE572438E415B426033DACAFBA93AC9BD355EBDB62F2FF01128996F7\r\n \r\nShanghai Yulian Software Technology Co., Ltd. (上海域联软件技术有限公司)\r\nValid From: 23-Mar-2011 (2:00:00)\r\nValid To: 23-Mar-2012 (1:59:59)\r\nSN: 5f78149eb4f75eb17404a8143aaeaed7\r\nThumbprint: 31e5380e1e0e1dd841f0c1741b38556b252e6231\r\nRevocation Status: Revoked on 18-Apr-2011 (10:42:04)\r\nCRL Distribution Point: http://csc3-2010-crl.verisign.com/CSC3-2010.crl\r\nIoCs:\r\n15FE970F1BE27333A839A873C4DE0EF6916BD69284FE89F2235E4A99BC7092EE\r\n32484F4FBBECD6DD57A6077AA3B6CCC1D61A97B33790091423A4307F93669C66\r\nC93A9B3D943ED44D06B348F388605701DBD591DAB03CA361EFEC3719D35E9887\r\n4.1 Beijing Kate Zhanhong Technology Co.,Ltd.\r\nWe did not find any relevant information about Beijing Kate Zhanhong Technology company. Avast captured 124\r\nhits signed with the Beijing Kate certificates from 2015 to 2021. However, prediction to 2021 indicates a\r\ndownward trend; see Figure 6. Only 19 hits have been captured in the first 7 months of this year, so the prediction\r\nfor this year (2021) is approx. 30 hits signed with this certificate.\r\nFigure 6: Number of hits and prediction of Beijing Kate\r\nNinety-five percent of total hits have been located in Asia; see Table 1 for detailed GeoIP distribution of the last\r\nsignificant years.\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-3/\r\nPage 7 of 15\n\nTable 1: Geological distribution of Beijing Kate certificates\r\nThe malware authors use this certificate to sign Windows system drivers in 61 % of monitored hits, and Windows\r\nexecutables are signed in 16 % of occurrences. Overall, it seems that the malware authors focus on Windows\r\ndrivers, which must be signed with any verified certificates.\r\n4.2 Beijing Founder Apabi Technology Limited\r\nThe Beijing Founder Apabi Technology Co., Ltd. was founded in 2001, and it is a professional digital publishing\r\ntechnology and service provider under Peking University Founder Credit Group. The company also develops\r\nsoftware for e-book reading like Apabi Reader [4].\r\nThe Beijing Founder certificate has been observed, as malicious, in 166 hits with 18 unique SHAs. The most\r\nrepresented sample is an executable called “Linking.exe” which was hit in 8 countries, most in China; exactly 71\r\ncases. The first occurrence and peak of the hits were observed in 2018. The incidence of hits was an order of\r\nmagnitude lower in the previous few years, and we predict an increase in the order of tens of hits, as Figure 7\r\nillustrates.\r\nFigure 7: Number of hits and prediction of Beijing Founder\r\n4.3 Shanghai Yulian Software Technology Co., Ltd.\r\nThe Shanghai Yulian Software Technology Co. was founded in 2005, which provides network security guarantees\r\nfor network operators. Its portfolio covers services in the information security field, namely e-commerce,\r\nenterprise information security, security services, and system integration [5].\r\nThe Shanghai Yulian Software certificate is the most widespread compared to others. Avast captured this\r\ncertificate in 10,500 cases in the last eight years. Moreover, the prevalence of samples signed with this certificate\r\nis on the rise, although the certificate was revoked by its issuer in 2011. In addition, the occurrence peak was in\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-3/\r\nPage 8 of 15\n\n2017 and 2020. We assume a linear increase of the incidence and a prediction for 2021 is based on the first months\r\nof 2021. And therefore, the prediction for 2021 indicates that this revoked certificate will also dominate in 2021;\r\nsee the trend in Figure 8. We have no record of what caused the significant decline in 2018 and 2019.\r\nFigure 8: Number of hits and prediction of Shanghai Yulian Software\r\nThe previous certificates dominate only in Asia, but the Shanghai Yulian Software certificate prevails in Asia and\r\nEurope, as Figure 9 illustrates. The dominant countries are Taiwan and Russia. China and Thailand are on a close\r\nhinge; see Table 2 for detailed country distribution, several countries selected.\r\nFigure 9: Distribution of hits in point of continent view for Shanghai Yulian Software\r\nTable 2: Geological distribution of Shanghai Yulian Software certificate\r\nAs in previous cases, the malware authors have been using Shanghai Yulian Software certificates to sign Windows\r\ndrivers in 75 % of hits. Another 16 % has been used for EXE and DLL executable; see Figure 10 for detailed\r\ndistribution.\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-3/\r\nPage 9 of 15\n\nFigure 10: Distribution of file types for Shanghai Yulian Software\r\n4.3.1 Analysis of Top 10 Captured Files\r\nWe summarize the most frequent files in this subchapter. Table 3 shows the occurrence of the top 10 executables\r\nthat are related to user applications. We do not focus on DirtyMoe drivers because this topic is recorded at\r\nDirtyMoe: Rootkit Driver.\r\nTable 3: The most common occurrence of the file names: hit count and number of countries\r\nWe have identified the five most executables signed with Shanghai Yulian Software certificate. The malware\r\nauthors target popular and commonly used user applications such as video editors, communication applications,\r\nand video games.\r\n1) WFP_Drive.sys\r\nThe WFP driver was hit in a folder of App-V (Application Virtualization) in C:\\ProgramData . The driver can\r\nfilter network traffic similar to a firewall [6]. So, malware can block and monitor arbitrary connections, including\r\ntransferred data. The malware does not need special rights to write into the ProgramData folder. The driver and\r\nApp-V’s file names are not suspicious at first glance since App-V uses Hyper-V Virtual Switch based on the WFP\r\nplatform [7].\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-3/\r\nPage 10 of 15\n\nNaturally, the driver has to be loaded with a process with administrator permission. Subsequently, the process\r\nmust apply for a specific privilege called SeLoadDriverPrivilege (load and unload device drivers) to successful\r\ndriver loading. The process requests the privilege via API call EnablePriviliges that can be monitored with\r\nAVs. Unfortunately, Windows loads drivers with revoked certificates, so the whole security mechanism is\r\ninherently flawed.\r\n2) LoginDrvS.sys\r\nFurther, the LoginDrvS driver uses a similar principle as the WFP driver. The malware camouflages its driver in a\r\ncommonly used application folder. It uses the LineageLogin application folder that is used as a launcher for\r\nvarious applications, predominantly video games. LineageLogin is implemented in Pascal [8]. The\r\nLineageLogin itself contains a suspicious embedded DLL. However, it is out of this topic. Both drivers\r\n(WFP_Drive.sys and LoginDrvS.sys) are presumably from the same malware author as their PDB paths indicate:\r\nf:\\projects\\c++\\win7pgkill\\amd64\\LoginDrvS.pdb (10 unique samples)\r\nf:\\projects\\c++\\wfp\\objfre_win7_amd64\\amd64\\WFP_Drive.pdb (8 unique samples)\r\nSimilar behavior is described in Trojan.MulDrop16.18994, see [9].\r\n3) Denuvo64.sys\r\nDenuvo is an anti-piracy protection technique used by hundreds of programming companies around the world\r\n[10]. This solution is a legal rootkit that can also detect cheat mode and other unwanted activity. Therefore,\r\nDenuvo has to use a kernel driver.\r\nThe easy way to deploy a malicious driver is via cracks that users still download abundantly. The malware author\r\npacks up the malicious driver into the cracks, and users prepare a rootkit backdoor within each crack run. The\r\nmalicious driver performs the function that users expect, e.g., anti-anti cheating or patching of executable, but it\r\nalso services a backdoor very often.\r\nWe have revealed 8 unique samples of Denuvo malicious drivers within 1046 cases. The most occurrence is in\r\nRussia; see Figure 11. The most hits are related to video game cracks as follows: Constructor, Injustice 2, Prey,\r\nPuyo Puyo Tetris, TEKKEN 7 – Ultimate Edition, Total War – Warhammer 2, Total.War – Saga Thrones of\r\nBritannia.\r\nFigure 11: Distribution of Denuvo driver across the countries\r\n4) WsAP-Filmora.dll\r\nWondershare Filmora is a simple video editor which has free and paid versions [11]. So, there is a place for cracks\r\nand malware activities. All hit paths point to crack activity where users tried to bypass the trial version of the\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-3/\r\nPage 11 of 15\n\nFilmora editor. No PDB path has been captured; therefore, we cannot determine the malware authors given other\r\nsamples signed with the same certificates. WsAP-Filmora.dll is widespread throughout the world (73 countries);\r\nsee the detailed country distribution in Figure 12.\r\nFigure 12: Filmora DLL distribution across the countries\r\n5) μTorrent.exe\r\nμTorrent is a freeware P2P client for the BitTorrent network [12]. Avast has detected 417 hits of malicious\r\nμTorrent applications. The malicious application is based on the original μTorrent client with the same\r\nfunctionality, GUI, and icon. If a user downloads and runs this updated μTorrent client, the application’s behavior\r\nand design are not suspicious for the user.\r\nThe original application is signed with Bit Torrent, Inc. certificate, and the malicious version was signed with\r\nShanghai Yulian Software certificate. Everyday users, who want to check the digital signature, see that the\r\nexecutable is signed. However, information about the signature’s suspiciousness is located in details that are not\r\nvisible at first glance, Figure 13.\r\nFigure 13: Digital signatures of original and malicious μTorrent client\r\nThe malicious signature contains Chinese characters, although the sample’s prevalence points to Russia.\r\nMoreover, China has no hits. Figure 14 illustrates a detailed country distribution of the malicious μTorrent\r\napplication.\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-3/\r\nPage 12 of 15\n\nFigure 14: Distribution of μTorrent client across the countries\r\n4.3.2 YDArk Rootkit\r\nWe have found one Github repository which contains a YDArk tool that monitors system activities via a driver\r\nsigned with the compromised certificate. The last sign was done in May 2021; hence it seems that the stolen\r\ncertificate is still in use despite the fact that it was revoked 10 years ago. The repository is managed by two users,\r\nboth located in China. The YDArk driver has been signed with the compromise certificates by ScriptBoy2077,\r\nwho admitted that the certificate is compromised and expired by this note:\r\n“I have signed the .sys file with a compromised, expired certificate, may it is helpful to those my friends who don’t\r\nknow how to load an unsigned driver.”\r\nThe private key of the compromised certificate is not available on the clearnet. We looked for by the certificate\r\nname, serial number, hashes, etc.; hence we can assume that the certificate and private key can be located in the\r\ndarknet and shared within a narrow group of malware authors. Consequently, the relationship between YDArk,\r\nmore precisely ScriptBoy2077, and the DirtyMoe driver is compelling. Additionally, C\u0026C DirtyMoe servers are\r\nalso located in most cases in China, as we described in DirtyMoe: Introduction and General Overview.\r\n5. Discussion\r\nThe most interesting finding of this research was that Windows allows loading drivers signed with revoked\r\ncertificates even if an appropriate CRL is locally stored. Windows successfully verifies the signature revocation\r\noffline for user-mode applications via UAC. However, if Windows loads drivers with the revoked certificate into\r\nthe kernel despite the up-to-date CRL, it is evident that the Windows kernel avoids the CRL check. Therefore, it is\r\nlikely that the missing implementation of CRL verification is omitted due to the performance at boot time. It is a\r\nhypothesis, so further research will need to be undertaken to fully understand the process and implementation of\r\ndriver loading and CRL verification.\r\nAnother important finding was that the online CRL is not queried by UAC in digital signatures verification for\r\nuser-mode applications, which require higher permission. It is somewhat surprising that UAC blocks the\r\napplications only if the user manually checks the chain of trust before the application is run; in other words, if the\r\ncurrent CRL is downloaded and is up-to-date before the UAC run. So, the evidence suggests that neither UAC\r\ndoes not fully protect users against malicious software that has been signed with revoked certificates.\r\nConsequently, the users should be careful when UAC appears. \r\nThe DirtyMoe’s driver has been signing with three certificates that we analyzed in this research. Evidence\r\nsuggests that DirtyMoe’s certificates are used for the code signing of other potentially malicious software. It is\r\nhard to determine how many malware authors use the revoked certificates precisely. We classified a few clusters\r\nof unique SHA samples that point to the same malware authors via PDB paths. However, many other groups\r\ncannot be unequivocally identified. There is a probability that the malware authors who use the revoked\r\ncertificates may be a narrow group; however, further work which compares the code similarities of signed\r\nsoftware is required to confirm this assumption. This hypothesis is supported by the fact that samples are\r\ndominantly concentrated in Taiwan and Russia in such a long time horizon. Moreover, leaked private keys are\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-3/\r\nPage 13 of 15\n\noften available on the internet, but the revoked certificates have no record. It could mean that the private keys are\r\npassed on within a particular malware author community.\r\nAccording to these data, we can infer that the Shanghai Yulian Software Technology certificate is the most\r\ncommon use in the wild and is on the rise, although the certificate was revoked 10 years ago. Geological data\r\ndemonstrates that the malware authors target the Asian and European continents primarily, but the reason for this\r\nis not apparent; therefore, questions still remain. Regarding types of misused software, the analysis of samples\r\nsigned with the Shanghai Yulian Software certificate confirmed that most samples are rootkits deployed together\r\nwith cracked or patched software. Other types of misused software are popular user applications, such as video\r\ngames, communication software, video editors, etc. One of the issues is that the users observe the correct behavior\r\nof suspicious software, but malicious mechanisms or backdoors are also deployed.\r\nIn summary, the DirtyMoe’s certificates are still used for code signing of other software than the DirtyMoe\r\nmalware, although the certificates were revoked many years ago.\r\n6. Conclusion\r\nThe malware analysis of the DirtyMoe driver (rootkit) discovered three certificates used for codesign of\r\nsuspicious executables. The certificates have been revoked in the middle of their validity period. However, the\r\ncertificates are still widely used for codesign of other malicious software.\r\nThe revoked certificates are principally misused for the code signature of malicious Windows drivers (rootkits)\r\nbecause the 64bit Windows system has begun requiring the driver signatures for greater security. On the other\r\nhand, Windows does not implement the verification of signatures via CRL. In addition, the malware authors abuse\r\nthe certificates to sign popular software to increase credibility, whereas the software is patched with malicious\r\npayloads. Another essential point is that UAC verifies the signatures against the local CRL, which may not be up-to-date. UAC does not download the current version of CRL when users want to run software with the highest\r\npermission. Consequently, it can be a serious weakness.\r\nOne source of uncertainty is the origin of the malware authors who misused the revoked certificates. Everything\r\npoints to a narrow group of the author primarily located in China. Further investigation of signed samples are\r\nneeded to confirm that the samples contain payloads with similar functionality or code similarities.\r\nOverall, these results and statistics suggest that Windows users are still careless when running programs\r\ndownloaded from strange sources, including various cracks and keygens. Moreover, Windows has a weak and\r\nineffective mechanism that would strongly warn users that they try to run software with revoked certificates,\r\nalthough there are techniques to verify the validity of digital signatures.\r\nThreat Research Team\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-3/\r\nPage 14 of 15\n\nThreat Research Team\r\nA group of elite researchers who like to stay under the radar.\r\nSource: https://decoded.avast.io/martinchlumecky/dirtymoe-3/\r\nhttps://decoded.avast.io/martinchlumecky/dirtymoe-3/\r\nPage 15 of 15", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://decoded.avast.io/martinchlumecky/dirtymoe-3/" ], "report_names": [ "dirtymoe-3" ], "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": 1775439107, "ts_updated_at": 1775791469, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/a4343d0293f9b2a61f929be6996f48811f7166ca.pdf", "text": "https://archive.orkl.eu/a4343d0293f9b2a61f929be6996f48811f7166ca.txt", "img": "https://archive.orkl.eu/a4343d0293f9b2a61f929be6996f48811f7166ca.jpg" } }