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

Written by: Mandiant Intelligence

During a recent Incident Response investigation, Mandiant discovered a malicious driver used to terminate select processes on Windows systems. In this case, the driver was used in an attempt to terminate the Endpoint Detection and Response (EDR) agent on the endpoint. Mandiant tracks the malicious driver and its loader as POORTRY and STONESTOP respectively. Soon after the initial discovery, Mandiant observed a POORTRY driver sample signed with a Microsoft Windows Hardware Compatibility Authenticode signature. Careful analysis of the driver’s Authenticode metadata led to a larger investigation into malicious drivers signed via the Windows Hardware Compatibility Program. The investigation found a wider issue:

• The malicious drivers are signed directly by Microsoft and identifying the original software vendor requires inspecting the signature with code
• Several distinct malware families, associated with distinct threat actors, have been signed with this process
• Mandiant identified at least nine unique organization names associated with attestation signed malware

This research is being released alongside a blog post by our colleagues at SentinelOne.

Code Signing and the Windows Hardware Compatibility Program

Relationships are built on trust. The same goes for the relationship we have with the software we rely on when using our computers every day; do I trust the execution of this program, and why? Software can be very opaque to end users; when it claims to be from Company X, what mechanisms exist to verify software’s trustworthiness?

[Queue John Cena walk-out music.]

Code signing has entered the ring.

Code signing is a means to ensure integrity and authenticity of a given file. Software vendors obtain certificates used for code signing from trusted Certificate Authorities (CA), who abide by standards set forth by the CA/Browser Forum and CA Security Council. These guidelines detail requirements, which include verifying the legal existence and identity of the company, and that the requestor of the certificate is authorized to act on behalf of the software vendor they claim to represent.

This certificate is then used to sign the software and provide a level of trust between the software and the operating system. Code signing enforcement policies differ per operating system and file type, from only allowing signed code to execute, to minimizing security warnings for execution of signed code, to purely serving as a digital signature denoting the authenticity of an application.

Microsoft’s code signing implementation for Windows binaries is known as Authenticode. Authenticode has several features specific to drivers and driver packages, and assists hardware vendors in getting their drivers signed properly via the Windows Hardware Compatibility Program.

“The Windows Hardware Compatibility Program is designed to help your company deliver systems, software and hardware products that are compatible with Windows and run reliably on Windows 10, Windows 11 and Windows Server 2022. The program also provides guidance for developing, testing and distributing drivers. Using the Windows Hardware Dev Center dashboard, you can manage submissions, track the performance of your device or app, review telemetry and much more.”

There are multiple phases to work through the Windows Hardware Compatibility Program process.

For operability on Windows 10 and later, drivers can be submitted to Microsoft for attestation signing.

In this attestation signing process, digital signatures are used to verify the integrity of submitted driver packages and to verify the identity of the software publisher who provided the driver packages. This process requires that the submitting organization sign their driver package with an Extended Validation (EV) certificate, which has enhanced identification requirements over other code-signing certificates and must use stronger encryption algorithms. These EV certificates are offered by a smaller circle of Certificate Authorities who have agreed to enhanced auditing requirements.

As an additional step, vendors can submit their driver for Hardware Lab Kit (HLK) testing, to become Windows Certified. When a driver receives attestation signing, it's not Windows Certified. An attestation signature from Microsoft indicates that the driver can be trusted by Windows, but because the driver has not been tested in HLK Studio, there are no assurances made around compatibility, functionality, and so on.

At a high level, there are 9 steps to submit an attestation signed driver within the compatibility program process.

1. Register for the Hardware Developer program
2. Identify or purchase an Extended Validation (EV) certificate
3. Download and install the Windows Driver Kit (WDK)
4. Create the CAB file that will be submitted for approval. The CAB file includes the driver itself, driver INF, symbol file, and catalog files.
5. Sign the CAB file with the EV certificate
6. Submit the EV signed CAB via the hardware dashboard
7. Microsoft will sign the driver
8. Download signed driver from the hardware dashboard
9. Validate and test the signed driver

The output of this process is an attestation signed driver.

Mandiant has continually observed threat actors use compromised, stolen, and illicitly purchased code-signing certificates to sign malware, lending legitimacy and subverting security controls such as application allow-listing policies. Attestation signed drivers take the trust granted to them by the CA and transfers it to a file whose Authenticode signature originates from Microsoft itself. We assess with high confidence that threat actors have subverted this process using illicitly obtained EV code signing certificates to submit driver packages via the attestation signing process, and in effect have their malware signed by Microsoft directly.

Threat Data and Observations

Mandiant has observed UNC3944 utilizing malware that has been signed via the attestation signing process. UNC3944 is a financially motivated threat group that has been active since at least May 2022 and commonly gains initial network access using stolen credentials obtained from SMS phishing operations. In some cases, the group’s post-compromise objectives have focused on accessing credentials or systems used to enable SIM swapping attacks, likely in support of secondary criminal operations occurring outside of victim environments.

UNC3944 has been observed deploying both STONESTOP and POORTRY as early as August 2022.

STONESTOP is a Windows userland utility that attempts to terminate processes by creating and loading a malicious driver. Mandiant tracks this malicious driver as POORTRY. POORTRY is a Windows driver that implements process termination and requires a userland utility to initiate the functionality. At driver entry it registers device \device\KApcHelper1 for interaction by user-space utilities like STONESTOP.

Mandiant has observed signed POORTRY drivers dating back to June of 2022 with a mix of certificates, including stolen certificates that have been widely circulated. Usage of POORTRY appears across different threat groups and is consistent with malware available for purchase or shared freely between different groups.

Unlike the earlier examples, many of which were improperly signed, this POORTRY sample is legitimately signed and verified with a Microsoft Windows Hardware Compatibility Publisher certificate. This is a Microsoft certificate that is used across the attestation program, and therefore is used extensively on legitimate binaries as well.

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
福州超人
北京弘道长兴国际贸易有限公司
福建奥创互娱科技有限公司
厦门恒信卓越网络科技有限公司
大连纵梦网络科技有限公司

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}\.pdb\x00/ nocase
        $pdb2 = /RSDS[\x00-\xFF]{20}[a-zA-Z]:\\.{0,250}MyDriver1.{0,250}wfp_vpn.{0,250}\.pdb\x00/ nocase
        $pdb3 = /RSDS[\x00-\xFF]{20}[a-zA-Z]:\\.{0,250}FilDriverx64_win10.{0,250}\.pdb\x00/ nocase
        $pdb4 = /RSDS[\x00-\xFF]{20}[a-zA-Z]:\\.{0,250}RedDriver_win10.{0,250}\.pdb\x00/ nocase
        $pdb5 = /RSDS[\x00-\xFF]{20}[a-zA-Z]:\\.{0,250}sellcode.{0,250}MyDriver.{0,250}\.pdb\x00/ nocase
        $pdb6 = /RSDS[\x00-\xFF]{20}[a-zA-Z]:\\.{0,250}Users\\ljl11{0,250}\.pdb\x00/ nocase
        $pdb7 = /RSDS[\x00-\xFF]{20}[a-zA-Z]:\\.{0,250}RkDriver64.{0,250}MyDriver1.{0,250}\.pdb\x00/ nocase
        $pdb8 = /RSDS[\x00-\xFF]{20}[a-zA-Z]:\\.{0,250}\\ApcHelper.{0,250}TSComputerManager.{0,250}\.pdb\x00/ 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