SIP:它们基本上是SubjectInterfacePackages的实现,它允许CryptAPI与文件的特定部分进行交互,以便在文件上放置、获取、计算和验证数字签名。换句话说,这就是Windows处理文件之间的Authenticode数字签名的方式。他们告诉CryptAPI如何散列文件以及将签名放在哪里。
1.根据文件魔数,尝试确定该文件是PE,编录文件,CTL还是cabinet文件。如果是任何这些文件类型,它将返回以下相应的SIPGUID:
CAAB8-8E78-11D0-8C47-00C04FCEE-PE
DEA43-8E59-11D0-8C47-00C04FCEE-Catalog
9BA61D3F-E73A-11D0-8CD2-00C04FCEE-CTL
CAABA-8E78-11D0-8C47-00C04FCEE-Cabinet
2.如果文件不匹配任何以前的文件类型,它将调用CryptEnumOIDFunction.aspx函数,传递它的功能名称为“CryptSIPDllIsMyFileType”和“CryptSIPDllIsMyFileType2”。这些功能分别对应于以下注册表项的查找:
HKLM\SOFTWARE\[WOWNode]\Microsoft\Cryptography\OID\EncodingType0\CryptSIPDllIsMyFileType\Allsub-GUIDs
HKLM\SOFTWARE\[WOWNode]\Microsoft\Cryptography\OID\EncodingType0\CryptSIPDllIsMyFileType2\Allsub-GUIDs随着CryptEnumOIDFunction枚举每个SIPGUID注册表子项,它将从“FuncName”和“Dll”列出的注册表键值中调用DLL导出函数。
信任提供者:对指定对象执行信任验证操作,SIP仅负责数字签名应用、检索和散列计算、验证。应用于文件的数字签名的存在是无意义的,除非某些标准被实际验证。这就是信任提供者发挥作用的地方——除了内置到所需的信任提供者中的标准之外,还可以根据调用者指定的参数组合对WinVerifyTrust进行验证。
截止到Windows10,有以下信任提供者存在:
一旦负责处理特定文件/二进制Blob格式的签名的SIP通过其各自的GUID标识符被识别,WinVerifyTrust就会知道如何从该文件中获取数字签名并验证其计算出的哈希对嵌入在数字中的签名哈希签名。为实现这一点,WinVerifyTrust在注册表中调用以下函数:
SIP签名检索功能位置:
HKLM\SOFTWARE\[WOWNode]\Microsoft\Cryptography\OID\EncodingType0\CryptSIPDllGetSignedDataMsg\{SIPGuid}
Dll
FuncName
SIP哈希验证函数:
HKLM\SOFTWARE\[WOWNode]\Microsoft\Cryptography\OID\EncodingType0\CryptSIPDllVerifyIndirectData\{SIPGuid}
Dll
FuncName
作为此技术的一部分,攻击者可能会尝试手动编辑这些注册表项(例如:Regedit)或使用Regsvr32使用合法注册过程。
附上攻击成功后系统日志所展示的内容:
修改注册表时间:
利用Regesver32事件:
缓解措施:1.检查OID、Trust注册表项,查看是否有新增的可疑项的建立,或者dll文件的修改。2.检查主机是否存在通过新建立的OID、Trust签名了新的恶意文件或者代码。
预览时标签不可点收录于话题#个上一篇下一篇转载请注明地址:http://www.abmjc.com/zcmbwh/907.html