I Solemnly Swear My Driver Is Up to No Good: Hunting for Attestation Signed Malware

The public key used for the attestation signing (Appendix C: POORTRY Certificate Details) contains two object identifiers (OIDs) of interest within the key usage value:

X509v3 Extended Key Usage:
                1.3.6.1.4.1.311.10.3.5, 1.3.6.1.4.1.311.10.3.5.1, Code Signing

RFC 5280 Section 4.2.1.12 defines Extended Key Usage (EKU). The EKU values in this signature help identify which method was used to sign this file and what purposes this signing certificate may be used for. The values defined show that this certificate is used in the Windows Hardware Compatibility driver signing process and is used specifically for attestation signed drivers. Table 1 shows the OID descriptions.

The connection between the POORTRY sample, the attestation certificate, and the numerous legitimate samples signed with this certificate led Mandiant to assess with high confidence that this malware was verified via the Windows Hardware Compatibility process.

RFC 2315 for the PKCS #7 v1.5 specification defines a SignerInfo content type, which for Authenticode signed PEs contains several interesting structures that can be used to identify samples related to the initially identified POORTRY driver (6fcf56f6ca3210ec397e55f727353c4a).

The field of interest, programName , is contained in the SpcSpOpusInfo attribute, which is specific to Authenticode. Mandiant assesses with high confidence that the programName field (hereafter referred to as Program Name) for attestation signed drivers contains identifiable information about the individual hardware vendor who submitted the driver for attestation signing.

SpcSpOpusInfo
  SpcSpOpusInfo is identified by SPC_SP_OPUS_INFO_OBJID
  (1.3.6.1.4.1.311.2.1.12) and is defined as follows:
  SpcSpOpusInfo ::= SEQUENCE {
    programName  [0] EXPLICIT SpcString OPTIONAL,
    moreInfo     [1] EXPLICIT SpcLink OPTIONAL,
  } --#public--

  SpcSpOpusInfo has two fields:
    programName
      This field contains the program description:
      If publisher chooses not to specify a description, the SpcString
      structure contains a zero-length program name.
      If the publisher chooses to specify a
      description, the SpcString structure contains a Unicode string.
    moreInfo
      This field is set to an SPCLink structure that contains a URL for
      a Web site with more information about the signer. The URL is an
      ASCII string.

大连纵梦网络科技有限公司

This field becomes an important artifact for identifying additional associated samples, and by pivoting on the Program Name, Mandiant identified eleven new suspicious files, including an additional POORTRY sample.

The programName field for attestation signed drivers appears to be populated by the X.509 Subject Organization Name (O) of the EV Code Signing certificate used to sign the initial CAB submission to the WHCP portal. This is corroborated by the high amount of malicious detections for samples associated with this Organization Name and other corresponding Program Name values on VirusTotal and within other Mandiant data sets. At time of writing, we have not been able to confirm with Microsoft that this is the exact mechanism for how the programName field is populated for attestation signed drivers.

All the observed corresponding EV code signing certificates were issued by Digicert. Over time certificate serial 01:15:3e:7a:3c:8d:c5:0b:3d:23:c8:ba:31:d3:70:52 was revoked, however several others appear to have not been revoked (bolded in Table 4). These corresponding Extended Validation certificates were used to sign launchers for SOGU malware utilized by Temp.Hex as well as signed distributions of the open source Fast Reverse Proxy tool, which has been used by suspected Iranian state-sponsored threat actors in intrusions observed by Mandiant.

Utilizing the OIDs and certificate data, YARA rules were developed to collect additional attestation signed drivers.

Examining these additional attestation signed drivers led to 57 suspicious samples that shared program names that were observed in malicious binaries (Appendix B: Indicators of Interest). These samples were spread across nine different program names.

Qi Lijun
Luck Bigger Technology Co., Ltd
XinSing Network Service Co., Ltd
Hangzhou Shunwang Technology Co.,Ltd
福州超人
北京弘道长兴国际贸易有限公司
福建奥创互娱科技有限公司
厦门恒信卓越网络科技有限公司
大连纵梦网络科技有限公司

Figure 7: Identified Program Names on suspicious attestation signed samples

Malicious Driver Signing as a Service

The suspicious samples identified through this investigation have led to multiple development environment artifacts, specifically program database (PDB) paths, implying multiple different development environments and potentially multiple different malware authors.

Mandiant has previously observed scenarios when it is suspected that groups leverage a common criminal service for code signing. This is not a new phenomenon, and has been documented by the Certified Malware project at the University of Maryland in 2017. This is what Mandiant believes is occurring with these suspicious attestation signed drivers and related EV signed samples.

The use of stolen or fraudulently obtained code signing certificates by threat actors has been a common tactic and providing these certificates or signing services has proven a lucrative niche in the underground economy. Mandiant has identified numerous threat actors and services advertising in a variety of languages, including English, Russian, and Chinese, that claim to provide code signing certificates or sign malware on behalf of threat actors. For example, while analyzing chat messages leaked by the Twitter user “@ContiLeaks,” Mandiant identified several instances where threat actors involved in Trickbot operations purchased code signing certificates from multiple threat actors, with observed pricing ranging between approximately $1,000-$3,000 USD for a single certificate.

While most of these advertisements only mention EV code signing certificates, we have identified a small number of discussions focused on signing drivers through WHQL. While most of these discussions lamented to the challenges presented by WHQL restrictions, we observed at least one actor who mentioned experience signing drivers with WHQL, and we have also identified multiple websites on the open Internet advertising WHQL driver signing services to enterprise businesses. While we are unable to link the signed payloads observed in this activity to any of the identified services, it’s plausible that actors are either enlisting services from underground forums or abusing commercial services to obtain signed driver malware.

A pattern emerges of suspected malicious attestation signed drivers that contain the programName corresponding to EV certificates that have also signed other suspected malicious samples. The Certificates appear to be issued primarily via Digicert and Globalsign to Chinese customers, indicating possible abuse of a Chinese market certificate reseller or signing service.

Given the different company names identified and the differing development environments Mandiant suspects there is a service provider getting these malware samples signed through the attestation process on behalf of the actors. Unfortunately, at this time, this assessment is stated with low confidence.

Hunting and Blocking

Attestation signing is a legitimate Microsoft program, and the resulting drivers are signed with legitimate Microsoft certificates. This makes execution-time detection difficult as Microsoft and most EDR tools will allow Microsoft signed binaries to load. Organizations must instead depend on behavioral detections to overcome the implicit trust granted to Microsoft-signed binaries and alert on suspicious or rootkit-like activities. For proactive hunts, however, there are numerous ways to search for these files.

YARA Rules and Descriptions

M_Hunting_Signed_Driver_Attestation_1

The OLEs allow detection to be implemented to identify any binary that is signed via the attestation process. This rule matches on the presence of the OLEs and the Microsoft Windows Hardware Compatibility Publisher certificate subject.

M_Win_Hunting_CertEngine_Attestation_ProgramName_1

The identified company names that were in the certificate program name can be used to home in on potentially suspicious samples. However, know that due to the nature of these certificates it is not true that all samples with the certificate are malicious, but simply have been abused in the past and warrant further investigation.

M_CertEngine_Malicious_Attestation_Signed_Driver

The VirusTotal dataset has additional data available for access via LiveHunt rules. This includes various tags and other metadata from the related sandbox execution. This information can be used to identify suspected malicious attestation signed binaries by combining the M_Hunting_Signed_Driver_Attestation_1 rule with the malicious count metadata.

M_Hunting_Win_ConventionEngine_PDB_Attestation_Multiple_1

As documented in the Definitive Dossier of Devilish Debug Details, PDB paths can be used to identify strings that are present within the malware.However, it’s important to remember that this is a consequence of the malware and malware developers, and not the certificate or signing process.

See Appendix A: YARA for the full list of detections.

Conclusion

The attestation signing process offloads the responsibility of verifying the identity of the requesting hardware or software vendor to the Certificate Authorities.  In theory this is a valid process as the CAs must follow agreed upon procedures to verify the identity of the requesting entity and the authority of the individual making the request to represent the software vendor. However, this process is being abused to obtain malware signed by Microsoft.

This is not a new occurrence; both GData and BitDefender released reports on Microsoft signed malicious drivers in 2021. “Microsoft signed a malicious Netfilter rootkit” and “Digitally-Signed Rootkits are Back – A Look at FiveSys and Companions” discussed malicious drivers signed via the same attestation process discussed in this blog post.

While this blog post has focused on POORTRY and the attestation signing process, Mandiant has observed other malware being signed via attestation. TEMPLESHOT is a malware family consisting of dropper, backdoor, a filter driver, and a protection driver. The TEMPLESHOT driver with MD5 48bf11dd6c22e241b745d3bb1d562ca1 has been observed in the wild and is signed via attestation.

Acknowledgements

Use of the Signify python library made automated analysis of Authenticode data extremely efficient. This content would not have been possible without the assistance of analysts across the Mandiant Intelligence and FLARE organizations.

Appendix A: YARA

import "pe"
rule M_Hunting_Signed_Driver_Attestation_1
{
    meta:
        author = "Mandiant"
        date_created = "2022-10-20"
            date_updated = "2022-04-24"
            revision = "2" //Refined OID descriptions and variable names
        description = "Find driver signed via Microsoft attestation signing only (no EV certificate signing outside of Microsoft Windows Hardware Compatibility Publisher)" //https://learn.microsoft.com/en-us/windows-hardware/drivers/dashboard/code-signing-attestation
    strings:
        $whql_attest_oid = {2b0601040182370a030501} //OID 1.3.6.1.4.1.311.10.3.5.1, Windows Hardware Driver Attested Verification -- "szOID_ATTEST_WHQL_CRYPTO"      
        $spc_statement_type = {2b060104018237020115} //OID 1.3.6.1.4.1.311.2.1.21, SPC_INDIVIDUAL_SP_KEY_PURPOSE_OBJID
        $spc_sp_opus_info_oid = {2b06010401823702010c} //OID 1.3.6.1.4.1.311.2.1.12, SPC_SP_OPUS_INFO_OBJID
    condition:
        pe.signatures[0].subject == "/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Hardware Compatibility Publisher" and
        $whql_attest_oid and
        $spc_sp_opus_info_oid and
        $spc_statement_type
}

import "pe"
rule M_Win_Hunting_CertEngine_Attestation_ProgramName_1
{
    meta:
        author = "Mandiant"
        date_created = "2022-10-20"
            date_updated = "2022-04-24"
            revision = "2" //Refined OID descriptions and variable names; Corrected Unicode UTF-16 bytes for unicode programName variables
        description = "Find driver signed via Microsoft attestation signing only with one of the identified company names of interest."
    strings:
        $whql_attest_oid = {2b0601040182370a030501} //OID 1.3.6.1.4.1.311.10.3.5.1, Windows Hardware Driver Attested Verification -- "szOID_ATTEST_WHQL_CRYPTO"
        $spc_statement_type = {2b060104018237020115} //OID 1.3.6.1.4.1.311.2.1.21, SPC_INDIVIDUAL_SP_KEY_PURPOSE_OBJID
        $spc_sp_opus_info_oid = {2b06010401823702010c} //OID 1.3.6.1.4.1.311.2.1.12, SPC_SP_OPUS_INFO_OBJID
$unicode1 = {59278FDE 7EB568A6 7F517EDC 79D16280 67099650 516C53F8}
            $unicode2 = {51 00 69 00 20 00 4c 00 69 00 6a 00 75 00 6e}
            $unicode3 = {4c 00 75 00 63 00 6b 00 20 00 42 00 69 00 67 00 67 00 65 00 72 00 20 00 54 00 65 00 63 00 68 00 6e 00 6f 00 6c 00 6f 00 67 00 79 00 20 00 43 00 6f 00 2e 00 2c 00 20 00 4c 00 74 00 64}
            $unicode4 = {58 00 69 00 6e 00 53 00 69 00 6e 00 67 00 20 00 4e 00 65 00 74 00 77 00 6f 00 72 00 6b 00 20 00 53 00 65 00 72 00 76 00 69 00 63 00 65 00 20 00 43 00 6f 00 2e 00 2c 00 20 00 4c 00 74 00 64}
            $unicode5 = {48 00 61 00 6e 00 67 00 7a 00 68 00 6f 00 75 00 20 00 53 00 68 00 75 00 6e 00 77 00 61 00 6e 00 67 00 20 00 54 00 65 00 63 00 68 00 6e 00 6f 00 6c 00 6f 00 67 00 79 00 20 00 43 00 6f 00 2e 00 2c 00 4c 00 74 00 64}
            $unicode6 = {54 00 41 00 20 00 54 00 72 00 69 00 75 00 6d 00 70 00 68 00 2d 00 41 00 64 00 6c 00 65 00 72 00 20 00 47 00 6d 00 62 00 48}
            $unicode7 = {798f 5dde 8d85 4eba}
            $unicode8 = {5317 4eac 5f18 9053 957f 5174 56fd 9645 8d38 6613 6709 9650 516c 53f8}
            $unicode9 = {798f 5efa 5965 521b 4e92 5a31 79d1 6280 6709 9650 516c 53f8}
            $unicode10 = {53a6 95e8 6052 4fe1 5353 8d8a 7f51 7edc 79d1 6280 6709 9650 516c 53f8}
    condition:      
        $whql_attest_oid and
        $spc_sp_opus_info_oid and
        $spc_statement_type and
        pe.signatures[0].subject == "/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Hardware Compatibility Publisher" and
        (1 of ($unicode*))
}

import "vt"
import "pe"
rule M_CertEngine_Malicious_Attestation_Signed_Driver
{
    meta:
        author = "Mandiant"
        date_created = "2022-10-20"
            date_updated = "2022-04-24"
            revision = "2" //Refined OID descriptions and variable names
        description = "Find driver signed via Microsoft attestation signing only and greater than 3 malicious hits in VirusTotal."
    strings:
        $whql_attest_oid = {2b0601040182370a030501} //OID 1.3.6.1.4.1.311.10.3.5.1, Windows Hardware Driver Attested Verification -- "szOID_ATTEST_WHQL_CRYPTO"
        $spc_statement_type = {2b060104018237020115} //OID 1.3.6.1.4.1.311.2.1.21, SPC_INDIVIDUAL_SP_KEY_PURPOSE_OBJID
        $spc_sp_opus_info_oid = {2b06010401823702010c} //OID 1.3.6.1.4.1.311.2.1.12, SPC_SP_OPUS_INFO_OBJID
    condition:
        for any tag in vt.metadata.tags : ( tag == "signed" ) and
        pe.signatures[0].subject == "/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows Hardware Compatibility Publisher" and
        vt.metadata.analysis_stats.malicious > 3 and
        $whql_attest_oid and
        $spc_sp_opus_info_oid and
        $spc_statement_type
}

rule M_Hunting_Win_ConventionEngine_PDB_Attestation_Multiple_1
{
    meta:
        author = "Mandiant"
            date_created = "2022-10-20"
        description = "Looking for PDB path strings that has been observed in malicious samples which were attestation signed"
    strings:
        $anchor = "RSDS"
        $pdb1 = /RSDS[x00-xFF]{20}[a-zA-Z]:.{0,250}gamehacks.{0,250}boot_driver.{0,250}.pdbx00/ nocase
        $pdb2 = /RSDS[x00-xFF]{20}[a-zA-Z]:.{0,250}MyDriver1.{0,250}wfp_vpn.{0,250}.pdbx00/ nocase
        $pdb3 = /RSDS[x00-xFF]{20}[a-zA-Z]:.{0,250}FilDriverx64_win10.{0,250}.pdbx00/ nocase
        $pdb4 = /RSDS[x00-xFF]{20}[a-zA-Z]:.{0,250}RedDriver_win10.{0,250}.pdbx00/ nocase
        $pdb5 = /RSDS[x00-xFF]{20}[a-zA-Z]:.{0,250}sellcode.{0,250}MyDriver.{0,250}.pdbx00/ nocase
        $pdb6 = /RSDS[x00-xFF]{20}[a-zA-Z]:.{0,250}Usersljl11{0,250}.pdbx00/ nocase
        $pdb7 = /RSDS[x00-xFF]{20}[a-zA-Z]:.{0,250}RkDriver64.{0,250}MyDriver1.{0,250}.pdbx00/ nocase
        $pdb8 = /RSDS[x00-xFF]{20}[a-zA-Z]:.{0,250}ApcHelper.{0,250}TSComputerManager.{0,250}.pdbx00/ nocase
    condition:
        (uint16(0) == 0x5A4D) and uint32(uint32(0x3C)) == 0x00004550 and filesize < 20MB and $anchor and (1 of ($pdb*))
}

Appendix B: Indicators of Interest

Attestation Signed Binaries with Suspicious Program Name Values

This table is sorted by Signature Date. Signature Date is an authenticated attribute, containing the timestamp of signing. Sorting by this date allows readers to view how the programName is used and changed over time.

One sample (688c138fffbb4e7297289433c79d62f5) does not have a Signature Date, and this is likely due to binary tampering including the use of VMProtect after signing and other modifications.

Signed POORTRY Samples

The following table includes signed POORTRY samples.

Extended Validation Signed Samples

The following table includes samples signed by EV certificates where the Organization Name is 大连纵梦网络科技有限公司.

Suspicious Attestation Signed Samples

The following list of MD5s are attestation signed binaries that have been identified as suspicious by numerous security solutions. While each one may not be directly malicious, they warrant an investigation should they be present in an environment.

Appendix C: POORTRY Certificate Details

The following certificate details are extracted from the certificate signing to the POORTRY sample. However, note that this is a legitimate attestation signing Microsoft certificate. Note that some details were removed for brevity.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            33:00:00:00:57:ee:4d:65:9a:92:3e:7c:10:00:00:00:00:00:57
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Windows Third Party Component CA 2014
        Validity
            Not Before: Jun  7 18:08:06 2022 GMT
            Not After : Jun  1 18:08:06 2023 GMT
        Subject: C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Windows Hardware Compatibility Publisher
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
               Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Extended Key Usage:
                1.3.6.1.4.1.311.10.3.5, 1.3.6.1.4.1.311.10.3.5.1, Code Signing
            X509v3 Subject Key Identifier:
                41:8F:FB:78:B4:1F:1F:7F:19:8E:36:12:08:D0:22:76:6B:58:FA:29
            X509v3 Subject Alternative Name:
                DirName:/OU=Microsoft Operations Puerto Rico/serialNumber=232147+470769
            X509v3 Authority Key Identifier:
                keyid:C8:3A:9C:A7:4A:C3:23:F2:25:7E:B9:DA:AB:29:53:0E:54:00:C3:A1

Source: https://www.mandiant.com/resources/blog/hunting-attestation-signed-malware