在这篇文章中,我将介绍我在逆转Office的身份验证机制时发现的两个问题,并提供一些不需要删除内存的POC工具来帮助恢复存储的令牌。

微软账户服务

我必须承认,当我第一次开始研究这个问题时,删除我正在运行的Word进程的内存并没有发现文档签名eyJ0eX。这是当前工具用来识别活动令牌的主要方法,我在Windows登录时使用Microsoft 365帐户。

事实证明,Microsoft Account (MSA)的身份验证令牌处理方式与通常的Azure AD SSO帐户不同。

让我们从查看经过MSA验证的Office会话开始,启动Microsoft Office并查看加载的DLL。其中最突出的是MicrosoftAccountWAMExtension.dll。将这个DLL加载到Ghidra中,我们可以开始寻找为MSA帐户生成身份验证令牌的原因。

如果我们在这个DLL中寻找RPC调用,就可以看到一堆被定向到名为wlidsvc的服务:

1.png

不幸的是,微软并没有为RPC调用此服务提供IDL(或者根本没有提供很多信息),所以我们将不得不做一些逆向工程来解决这个问题。

让我们将WinDBG附加到wlidsc并监视正在进行的RPC调用。在任何Office进程中进行身份验证之后,我们看到第一个调用是RPC方法WLIDCCreateContext以创建上下文,然后是WLIDCAcquireTokensWithNGC,最后是一系列其他调用,我们将暂时忽略这些调用。

如果我们在后一种方法中添加一个断点,那登录到Office中的MSA帐户会导致命中:

2.png

步进式(Stepping )直到我们点击ret并检查填充的参数,在参数12的内存区域中会显示一些有趣的东西。

3.png

对我来说,这确实是一个象征!如果我们打开像Fiddler这样的代理,我们会看到它与Office访问web服务时使用的身份验证令牌格式相匹配:

4.png

那么,我们如何从我们自己的工具中调用它呢?让我们使用James Forshaw的NtObjectManager生成一个可以使用的存根。

5.png

生成的RPC存根根据Windows版本的不同而不同,这是毫无价值的,例如,在Windows 10中,我们发现字段计数在输入结构上发生了变化,因此,如果你收到可怕的(0x800706F7) - The stub received bad data. 错误,请多家留意。

使用RPC客户端存根创建一个快速的C#应用程序,我们将重播我们之前观察到的入站RPC调用,并添加参数,这将给我们提供如下内容:

6.png

如果我们称之为:

7.png

由于这是MSA身份验证请求,我们将不得不使用Substrate等服务来访问Microsoft 365服务。旋转一个代理并在Office中导航是确定调用什么以及这些web服务采用什么参数的最佳方式。但你可以看到,passport令牌返回后,我们可以很好地进行身份验证和交互:

8.png

令牌缓存

现在我们已经了解了如何恢复MSA,那么Azure AD呢?通过Lee Christensen的帖子知道,我们可以很容易地按需请求新令牌,但是我们在Office进程中看到的缓存令牌被转储了,它们是如何在启动时加载的呢?

让我们提供一个新的主机并将我们的用户帐户与AzureAD相关联,然后登录到Office,再尝试找出令牌存储的位置。

9.png

为了确保我们在正确的轨道上,让我们从内存中转储一些字符串,并确保eyJ0eX签名存在。

10.png

我们再次深入搜索dll,但这次我们将重点关注Windows.Security.Authentication.Web.Core.dll。

这是一个WinRT库,因此我们需要深入Ghidra了解正在发生的事情。

AddWebTokenResponseToCache方法如下:

11.png

如果我们进一步研究,会发现此方法实际上负责将凭据缓存到序列化文件,这些文件可以在%LOCALAPPDATA%\Microsoft\TokenBroker\Cache中找到。

12.png

好的,让我们看看这些TBRES文件:

13.png

如果我们使用ProcMon,我们会看到这些文件确实在进程启动时被Office访问:

14.png

可以看到,这就是我们的身份验证信息存储的地方!查看JSON会发现一个IsProtected字段。在WinDBG中,我们将附加到Office,在CryptUnprotectData上添加断点并重新启动。果然,我们发现base64解密数据的内容被解密了。

15.png

JSON文件中我们特别感兴趣的字段是ResponseBytes,我添加了一个带有快速工具的repo,该工具可以解密这些文件,可以在这里找到。

在使用ProtectedData.Unprotect解密此数据后,我们看到了明文JWT。果然,解密它们会得到我们之前从内存中看到的相同信息:

16.png

来自不同提供者和应用程序的其他令牌也存储在这些文件中,包括MSA令牌,这也是毫无价值的。

现在我们知道了,Windows和Office用于Live和Azure的认证和缓存会话的几种不同方法。

POC可以在https://github.com/xpn/WAMBam上找到。

在这篇文章中,我将介绍我在逆转Office的身份验证机制时发现的两个问题,并提供一些不需要删除内存的POC工具来帮助恢复存储的令牌。

微软账户服务

我必须承认,当我第一次开始研究这个问题时,删除我正在运行的Word进程的内存并没有发现文档签名eyJ0eX。这是当前工具用来识别活动令牌的主要方法,我在Windows登录时使用Microsoft 365帐户。

事实证明,Microsoft Account (MSA)的身份验证令牌处理方式与通常的Azure AD SSO帐户不同。

让我们从查看经过MSA验证的Office会话开始,启动Microsoft Office并查看加载的DLL。其中最突出的是MicrosoftAccountWAMExtension.dll。将这个DLL加载到Ghidra中,我们可以开始寻找为MSA帐户生成身份验证令牌的原因。

如果我们在这个DLL中寻找RPC调用,就可以看到一堆被定向到名为wlidsvc的服务:

1.png

不幸的是,微软并没有为RPC调用此服务提供IDL(或者根本没有提供很多信息),所以我们将不得不做一些逆向工程来解决这个问题。

让我们将WinDBG附加到wlidsc并监视正在进行的RPC调用。在任何Office进程中进行身份验证之后,我们看到第一个调用是RPC方法WLIDCCreateContext以创建上下文,然后是WLIDCAcquireTokensWithNGC,最后是一系列其他调用,我们将暂时忽略这些调用。

如果我们在后一种方法中添加一个断点,那登录到Office中的MSA帐户会导致命中:

2.png

步进式(Stepping )直到我们点击ret并检查填充的参数,在参数12的内存区域中会显示一些有趣的东西。

3.png

对我来说,这确实是一个象征!如果我们打开像Fiddler这样的代理,我们会看到它与Office访问web服务时使用的身份验证令牌格式相匹配:

4.png

那么,我们如何从我们自己的工具中调用它呢?让我们使用James Forshaw的NtObjectManager生成一个可以使用的存根。

5.png

生成的RPC存根根据Windows版本的不同而不同,这是毫无价值的,例如,在Windows 10中,我们发现字段计数在输入结构上发生了变化,因此,如果你收到可怕的(0x800706F7) - The stub received bad data. 错误,请多家留意。

使用RPC客户端存根创建一个快速的C#应用程序,我们将重播我们之前观察到的入站RPC调用,并添加参数,这将给我们提供如下内容:

6.png

如果我们称之为:

7.png

由于这是MSA身份验证请求,我们将不得不使用Substrate等服务来访问Microsoft 365服务。旋转一个代理并在Office中导航是确定调用什么以及这些web服务采用什么参数的最佳方式。但你可以看到,passport令牌返回后,我们可以很好地进行身份验证和交互:

8.png

令牌缓存

现在我们已经了解了如何恢复MSA,那么Azure AD呢?通过Lee Christensen的帖子知道,我们可以很容易地按需请求新令牌,但是我们在Office进程中看到的缓存令牌被转储了,它们是如何在启动时加载的呢?

让我们提供一个新的主机并将我们的用户帐户与AzureAD相关联,然后登录到Office,再尝试找出令牌存储的位置。

9.png

为了确保我们在正确的轨道上,让我们从内存中转储一些字符串,并确保eyJ0eX签名存在。

10.png

我们再次深入搜索dll,但这次我们将重点关注Windows.Security.Authentication.Web.Core.dll。

这是一个WinRT库,因此我们需要深入Ghidra了解正在发生的事情。

AddWebTokenResponseToCache方法如下:

11.png

如果我们进一步研究,会发现此方法实际上负责将凭据缓存到序列化文件,这些文件可以在%LOCALAPPDATA%\Microsoft\TokenBroker\Cache中找到。

12.png

好的,让我们看看这些TBRES文件:

13.png

如果我们使用ProcMon,我们会看到这些文件确实在进程启动时被Office访问:

14.png

可以看到,这就是我们的身份验证信息存储的地方!查看JSON会发现一个IsProtected字段。在WinDBG中,我们将附加到Office,在CryptUnprotectData上添加断点并重新启动。果然,我们发现base64解密数据的内容被解密了。

15.png

JSON文件中我们特别感兴趣的字段是ResponseBytes,我添加了一个带有快速工具的repo,该工具可以解密这些文件,可以在这里找到。

在使用ProtectedData.Unprotect解密此数据后,我们看到了明文JWT。果然,解密它们会得到我们之前从内存中看到的相同信息:

16.png

来自不同提供者和应用程序的其他令牌也存储在这些文件中,包括MSA令牌,这也是毫无价值的。

现在我们知道了,Windows和Office用于Live和Azure的认证和缓存会话的几种不同方法。

POC可以在https://github.com/xpn/WAMBam上找到。

下面的伪代码或多或少地展示了SmartLocker非继承属性的最后一部分是如何工作的。

12.png

注意: 根据稍后如何使用此函数中的值来填充TraceLogging字符串,我们知道防御措施将评估过程的所有这一部分视为: Is防御措施Shell。

这或多或少就是我们通过在调用之后立即双击从资源管理器启动的进程所需要的:

13.png

CipCheckSmartlockerEAandProcessToken的情况就这样了,现在再说说CipExternalAuthorizationCallback。

现在,让我们说说Intelligent Security Graph所使用的代码段,它现在已被扩展以添加一些SAC功能。首先,将再次检查策略选项Intelligent Security Graph Authorization(智能安全图授权),如果未设置,函数将使用从CipCheckSmartlockerEAandProcessToken获取的值退出。如果该值在策略中处于活动状态(SAC策略就是这种情况),该函数将使用前面讨论的IsTrustedSigning来确定它是否应该继续。如果映像可信,将执行以下检查:

如果ValidatedSigningLevel等于“由使用AMPPL(7)的产品的AV签名”,并且策略的值为VerifiedAndReputableAllowAntiMalware,则分数将用值AllowAnti Malware(0x100000)进行异或运算,函数将返回。

如果映像不可信,则函数将继续查询防御措施。如上所述,向防御措施发出查询的函数是CiCatDbSmartlockerDefenderCheck。此函数将接收两个MPFILE_TRUST_EXTRA_INFO结构,一个填充请求数据,另一个接收回复数据。代码还将从FileObject传递FileName。MPFILE_TRUST_EXTRA_INFO结构如下所示。

14.png

双方之间的通信是使用RPC实现的,CI.dll将实现客户端,服务器将在cryptcatsvc.dll中实现。为了记录,RPC存根的IID是f50aac00-c7f3-428e-a022a6b71bfb9d43。

cryptcatsvc在服务CryptSvc中运行。在用于RPC服务器的发送函数中,我们重点关注以下函数:

s_SSCatDBSmartlockerDefenderCheck (Already present in 22H1);s_SSCatDBSmartlockerDefenderCheck2 (New to 22H2);s_SSCatDBSendSmartAppControlBlockToast;s_SSCatDBSendSmartAppControlSwitchEnforceToast;

SmartLockerDefenderCheck函数的v1和v2之间的最大区别在于,在v2中,该函数接受请求和回复MPFILE_TRUST_EXTRA_INFO作为其参数的一部分。这两个函数最终都调用了助手函数CatDBSmartlockerDefenderCheckHelper。

CI将从这些函数调用s_SSCatDBSmartlockerDefenderCheck2,它将首先加载MpClient.dll。

注意:在第一次执行时,将在防御措施配置中启用SmartLocker。该函数将调用MpClient导出的函数MpSmartLockerEnable。此函数只需注册Defender ELAM证书信息(打开Wdboot.sys的句柄并调用InstallELAMCertificateInfo),然后使用RPC从MpSvc.dll调用方法ServerMpEnableSmartLocker,它将检查防御措施配置中是否设置了SmartLockerMode,如果没有,它将写入。

打开库的句柄后,该函数将使用CI.dll提供的文件名来打开一个文件句柄,该句柄将被传递给MpClient导出的函数MpQueryFileTrustByHandle2,该函数只在来自于DefenderCheck2时被调用,如果是旧版本的DefenderCheck,则将调用MpQueryFileTrustByHandle。

在MpQueryFileTrustByHandle2内部,代码将使用该文件的句柄来创建文件映射,该文件映射将被防御程序用于对其进行内存扫描。下面的InSequence函数将通过从MpClient(客户端)到MpSvc(服务器)发出RPC调用来执行。显然,我们刚才看到的所有函数调用都接受CI.dll设置的MPFILE_TRUST_EXTRA_INFO作为参数的一部分。

ServerMpRpcMemoryScanStart:设置CMpMemScanContext和CMpMemScanEngineVfz(使用GetAttributeTrustCheck作为GetAttributions函数),并进行异步扫描;

ServerMpRpcMemoryScanQueryNotification:检索扫描信息;

ServerMpRpcMemoryScanClose:关闭并清除CMpMemScanContext。

这些函数的内部结构不在本文所讲的范围,我想强调的是,当启用SAC时,防御措施将主动扫描文件并进行云查询。

从扫描检索到的信息中有三个可能的信号:

0x31001:检索到的MPTRUST_INFO(IGS);

0x31002:检索到的MPFILE_TRUST_EXTRA_INFO(SAC);

0x4005:与RSIG_VIRINFO相关;

最后完成防御措施通信,下图显示了代码到达防御措施时客户端(CI)和服务器(cryptcatsvc)堆栈。

15.png

需要注意的是,如果我们的SAC处于强制状态,并且设备中没有互联网连接,则默认操作是阻止该进程,并且将显示一条通知,提示“智能应用程序控制无法验证此应用程序,请检查您的互联网连接,然后重试”。

返回外部授权回调,如果RPC调用失败,则未设置策略设置VerifiedAndReputableAllowUnknown,并且ValidateSigningLevel不是以下任何一项:

Microsoft Store signed app PPL (Protected Process Light)Microsoft Store-signedMicrosoft signedWindows signedOnly used for signing of the .NET NGEN compilerWindows Trusted Computing Base signed

然后将验证分数与值Unattainable(0x40000)进行异或运算,函数将返回。如果RPC调用成功,则将调用函数CiHandleDefenderSignals。顾名思义,此函数将处理防御措施发送回的消息。它将遍历返回的元素数,其中每个元素的类型为MPFILE_TRUST_EXTRA_INFO。根据ReplyType字段,它将执行不同的操作。更有趣的两种情况是:首先,当返回信任结果时。在该示例中,信息将指向MP_INFO_RESULT,其中的值将复制到验证上下文:

16.png

第二个有趣的示例是信息指向MP_NW_CONTROL枚举。在该示例中,根据控制命令,该功能将被禁用或切换到强制模式。这基本上将更新VerifiedAndReputablePolicyState RegKey,并更新WorkItem中的策略。

17.png

在我们从学习模式更改为强制模式的情况下,将发出对函数s_SSCatDBSendSmartAppControlSwitchEnforceToast的RPC调用。在此函数中,DLL wldap . DLL将被加载,然后调用函数WldpSendSmartAppControlSwitchEnforceToast。

从信号处理程序回来后,有一些细微差别。如果NW控制命令设置了标志IsUnfriendlyFile,则Score将更新为值UnfriendalyFile(0x80000),函数将返回。如果未设置标志,则TrustInfo和FileObject将被传递到带有标志0x82的函数CipSetFileCache中,这意味着EA $Kernel.Purge.CIpCache将用于存储此信息。

最后,需要根据防御程序返回的信任调整分数,有5个选项:

Trust == 1:分数将使用值0x202进行异或运算,不过我对这个值不太了解;

Trust == -1 (0xFFFFFFFF):如果策略设置VerifiedAndReputableAllowUnknown被设置,则分数将使用值AllowUnderknown(0x20000)进行异或运算;

Trust == -2 (0xFFFFFFFE):分数将使用值Malicious (0x80)进行异或运算;

Trust == -3 (0xFFFFFFFD):分数将用PUA(0x100)值进行异或运算;

任何其他情况下,分数将用值0x42进行异或运算。

这几乎就是外部授权回调的全部内容,现在我们回到调用外部授权回调时的SIPolicyValidateImageInternal!

SIPolicyValidateImageInternal

在进入外部授权回调之前,我们将讨论SIPolicyObjectValidationEngine函数如何遍历策略并调用内部SIPolicy ValidateImageInternal,后者稍后将调用外部auth回调。现在,调用回调后,我们返回到SIPolicyValidateImageInternal,并返回验证分数。如果启用了SAC,则该函数将继续评估分数,并将此分数传播到验证引擎分数,并根据该得分设置相应的NTSTATUS。

18.png

如上图所示,在大多数分支中,它会将相应的NTSTATUS设置为验证状态,然后跳转到我所称为ProcessDbgAndReprieve的状态。这只不过是一种检查内核调试器是否附加到调试器控制台中以记录策略冲突的方法。

19.png

如果未遵循前一个映像中的任何分支,或者分数为Unattainable但设置了AllowUnknown,则函数将继续根据策略规范评估对象。首先检查文件规范,这将在函数SIPolicyMatchFileRules内完成。此函数将接收以下参数:

具有要评估的文件规范的策略;

OriginalFileName;InternalName;FileDescription;ProductName;

我强烈建议阅读MSDN的“理解Windows防御应用程序控制(WDAC)策略规范和文件规范”一节,以了解更多关于策略规范和可用于它们的不同选项的内容。

与我们在第1部分中看到的Policy Secure Settings类似,该函数将使用作为key传递到函数bsearch的数据建立一个结构。关键结构具有以下原型:

20.png

bsearch函数的base和num将取自SI_POLICY结构。将策略解析为SI_policy结构时,将设置一个包含两个场景的数组。每个场景都包含其特定的文件规范、允许的签名者、拒绝的签名者和异常规范。如上所述,当调用SIPolicyMatchFileRules时,要评估的场景的特定数量被传递给函数。此数字将用作函数的索引,以了解要选取Scenarios数组的哪个元素。每个场景都由以下结构表示:

21.png

如果没有FileName级别的文件规范匹配,则函数将继续计算哈希级别的文件规范:

22.png

如果FileName或Hash匹配,则SIPolicyMatchFileRules返回TRUE,验证状态将设置为status_SYSTEM_INTEGRITY_POLICY_VIOLATION。

如果对SAC策略使用的哈希和文件名感兴趣,可以查看策略的FileRule标签下的整个列表。

如果没有匹配的文件规范,则下一步(如果映像已签名)是根据“拒绝”和“允许”签名者验证签名链信息。首先,将检查被拒绝的签名者。如果与前面相同的规范在此匹配,该函数将把验证状态设置为status_system_integrity_policy_violate。如果没有拒绝签名者规范匹配,代码将继续检查允许的签名者规范。在该示例中,如果存在匹配,则会清除以前的任何状态/分数。根据策略签名验证映像签名的过程主要在函数SIPolicyValidateChainAgainstSigner中完成。此函数将作为第一个参数接收映像的SI_CHAIN_INFO,并在@r8中接收POLICY_SIGNERS_DATA。

关于这个POLICY_SIGNERS_DATA结构,基本上SI_POLICY结构保留一个POLICY-SIGNERS_DATA数组。这些代表两种方案的所有Allow和Deny签名。代码知道哪些规范适用于哪个场景的方式,这意味着要使用POLICY_SIGNERS_DATA数组的哪个索引是非常聪明的。这是我之前在文件规范中没有解释的事情,所以现在是检查它的好时机。如果你返回并检查SI_POLICY_SCENARIO结构,将看到对于每个规范类型结构(file, Allow, Deny),都有一个SI_RULES结构,其中包含一个我称为IndexArray的字段。基本上,这是一个索引数组,用于指示该特定场景和规则必须使用包含数据的数组中的哪个索引。让我们看一个快速的伪代码片段,以便更好地理解这一点。

23.png

这可能不是百分之百准确的,因为我省略了很多在中间进行的检查。

为了更好地了解签名是如何验证的,接下来你可以找到POLICY_SIGNERS_DATA的原型,注意,这将适用于允许签名者和拒绝签名者。

24.png

通过查看SI_CHAIN_INFO和POLICY_SIGNERS_DATA,你可以或多或少地了解如何在SIPolicyValidateChainAgainstSigner函数中进行比较。最后,为了总结Signer规范的验证,下面是在SIPolicyValidateChainAgainstSigner条目处使用SAC强制策略验证ProcessHacker时记录的映像。

25.png

老实说,为了达到这张图片的目的,我不得不稍微修改代码流。因为在第一次签名检查时,Type将匹配,然后它将退出循环。之所以会实现这一点,是因为这个POLICY_SIGNERS_DATA中的信息比第一个检查的要多。在第一次选中时,唯一的填充值是Type(设置为0x14)。我已尝试查找有关此Type值的信息,但找不到任何信息。

因此,在为每个活动策略和补充策略运行整个过程之后,我们将返回函数CipApplySiPolicyEx,为每个BasePolicy提供一个CI_VALIDATION_RESULT。补充策略的结果将写入与BasePolicy相同的CI_VALIDATION_RESULT中。此时,该函数只会遍历验证结果,将这些结果存储在validation Context中。此外,此时SmartLocker事件将记录在函数CiLogSIPolicySmartlockerEvent中。此处可以记录四种类型的事件:

SmartlockerOperationalAudit (EventId: 3091)SmartlockerOperationalFailure (EventId: 3092)SmartlockerVerbose (EventId: 3088)SmartlockerOperationalSuccess (EventId: 3090)

26.png

我们几乎完成了,现在将进入调用堆栈,将验证状态传递到上面的函数。最后,我们将回到CI入口点CiValidateImageHeader,与之前一样,我们不会对这个函数进行过多讨论。关于SAC唯一有趣的一点是,如果SigningLevel匹配以下任何一项:

尚未检查签名级别;

文件未签名;

受Windows防御措施应用程序控制策略信任;

开发者签名代码;

SAC结果是允许执行,然后将使用函数CipInstrumentNightsWatchAllow记录操作。此函数可以为提供程序CodeIntegrity编写四个基于TraceLogging的事件。具有以下名称的NWActivityVerbose & CodeIntegrity.NWActivity。

27.png

执行此函数时,将记录QuestionableAllow或Allow。如果采用了记录QuestionableAllow的路径,那么如果所需数据可用,还将写入QuestionaleAllowSignatureInfo&OriginClaimData。

由于这些是基于跟踪日志记录的事件,我们需要使用一些特殊办法来捕获跟踪。值得庆幸的是,Matt已经做了所有艰苦的工作来研究和记录这类事件的过程。看了他的文章《Windows RE使用WPP和TraceLogging》后,我们可以使用powershell中的以下4行代码来启动ETW会话,该会话将捕获NWActivity和NWActovityVerbose提供程序。

28.png

开始跟踪并使用一些应用程序/安装程序后,你应该有一个可以用EventViewer打开的EventLog,你可以发现防御措施最终信任ProcessHacker之类的事情。

29.png

总结

就个人而言,我认为微软为提高操作系统的安全性而采取的措施是很好的,其最终目标是让用户更加安全。另一方面,我确实看到了SAC和Windows 10 S之间的一些相似之处。对于SAC,当设置为强制时,限制由具有数字签名的应用程序设置,如果没有签名,则由防御措施云认为可信的应用程序进行设置。

第一种选择,即使你知道数字签名可以很好地验证应用程序,许多开源项目或自由开发者负担不起,不幸的是,这给开发者带来了一些限制。

第二个选项,即对“智能云安全服务”的查询,这也是我希望微软提供更多信息的地方,因为基本上应用程序能否运行的决定将完全取决于微软。

下面的伪代码或多或少地展示了SmartLocker非继承属性的最后一部分是如何工作的。

12.png

注意: 根据稍后如何使用此函数中的值来填充TraceLogging字符串,我们知道防御措施将评估过程的所有这一部分视为: Is防御措施Shell。

这或多或少就是我们通过在调用之后立即双击从资源管理器启动的进程所需要的:

13.png

CipCheckSmartlockerEAandProcessToken的情况就这样了,现在再说说CipExternalAuthorizationCallback。

现在,让我们说说Intelligent Security Graph所使用的代码段,它现在已被扩展以添加一些SAC功能。首先,将再次检查策略选项Intelligent Security Graph Authorization(智能安全图授权),如果未设置,函数将使用从CipCheckSmartlockerEAandProcessToken获取的值退出。如果该值在策略中处于活动状态(SAC策略就是这种情况),该函数将使用前面讨论的IsTrustedSigning来确定它是否应该继续。如果映像可信,将执行以下检查:

如果ValidatedSigningLevel等于“由使用AMPPL(7)的产品的AV签名”,并且策略的值为VerifiedAndReputableAllowAntiMalware,则分数将用值AllowAnti Malware(0x100000)进行异或运算,函数将返回。

如果映像不可信,则函数将继续查询防御措施。如上所述,向防御措施发出查询的函数是CiCatDbSmartlockerDefenderCheck。此函数将接收两个MPFILE_TRUST_EXTRA_INFO结构,一个填充请求数据,另一个接收回复数据。代码还将从FileObject传递FileName。MPFILE_TRUST_EXTRA_INFO结构如下所示。

14.png

双方之间的通信是使用RPC实现的,CI.dll将实现客户端,服务器将在cryptcatsvc.dll中实现。为了记录,RPC存根的IID是f50aac00-c7f3-428e-a022a6b71bfb9d43。

cryptcatsvc在服务CryptSvc中运行。在用于RPC服务器的发送函数中,我们重点关注以下函数:

s_SSCatDBSmartlockerDefenderCheck (Already present in 22H1);s_SSCatDBSmartlockerDefenderCheck2 (New to 22H2);s_SSCatDBSendSmartAppControlBlockToast;s_SSCatDBSendSmartAppControlSwitchEnforceToast;

SmartLockerDefenderCheck函数的v1和v2之间的最大区别在于,在v2中,该函数接受请求和回复MPFILE_TRUST_EXTRA_INFO作为其参数的一部分。这两个函数最终都调用了助手函数CatDBSmartlockerDefenderCheckHelper。

CI将从这些函数调用s_SSCatDBSmartlockerDefenderCheck2,它将首先加载MpClient.dll。

注意:在第一次执行时,将在防御措施配置中启用SmartLocker。该函数将调用MpClient导出的函数MpSmartLockerEnable。此函数只需注册Defender ELAM证书信息(打开Wdboot.sys的句柄并调用InstallELAMCertificateInfo),然后使用RPC从MpSvc.dll调用方法ServerMpEnableSmartLocker,它将检查防御措施配置中是否设置了SmartLockerMode,如果没有,它将写入。

打开库的句柄后,该函数将使用CI.dll提供的文件名来打开一个文件句柄,该句柄将被传递给MpClient导出的函数MpQueryFileTrustByHandle2,该函数只在来自于DefenderCheck2时被调用,如果是旧版本的DefenderCheck,则将调用MpQueryFileTrustByHandle。

在MpQueryFileTrustByHandle2内部,代码将使用该文件的句柄来创建文件映射,该文件映射将被防御程序用于对其进行内存扫描。下面的InSequence函数将通过从MpClient(客户端)到MpSvc(服务器)发出RPC调用来执行。显然,我们刚才看到的所有函数调用都接受CI.dll设置的MPFILE_TRUST_EXTRA_INFO作为参数的一部分。

ServerMpRpcMemoryScanStart:设置CMpMemScanContext和CMpMemScanEngineVfz(使用GetAttributeTrustCheck作为GetAttributions函数),并进行异步扫描;

ServerMpRpcMemoryScanQueryNotification:检索扫描信息;

ServerMpRpcMemoryScanClose:关闭并清除CMpMemScanContext。

这些函数的内部结构不在本文所讲的范围,我想强调的是,当启用SAC时,防御措施将主动扫描文件并进行云查询。

从扫描检索到的信息中有三个可能的信号:

0x31001:检索到的MPTRUST_INFO(IGS);

0x31002:检索到的MPFILE_TRUST_EXTRA_INFO(SAC);

0x4005:与RSIG_VIRINFO相关;

最后完成防御措施通信,下图显示了代码到达防御措施时客户端(CI)和服务器(cryptcatsvc)堆栈。

15.png

需要注意的是,如果我们的SAC处于强制状态,并且设备中没有互联网连接,则默认操作是阻止该进程,并且将显示一条通知,提示“智能应用程序控制无法验证此应用程序,请检查您的互联网连接,然后重试”。

返回外部授权回调,如果RPC调用失败,则未设置策略设置VerifiedAndReputableAllowUnknown,并且ValidateSigningLevel不是以下任何一项:

Microsoft Store signed app PPL (Protected Process Light)Microsoft Store-signedMicrosoft signedWindows signedOnly used for signing of the .NET NGEN compilerWindows Trusted Computing Base signed

然后将验证分数与值Unattainable(0x40000)进行异或运算,函数将返回。如果RPC调用成功,则将调用函数CiHandleDefenderSignals。顾名思义,此函数将处理防御措施发送回的消息。它将遍历返回的元素数,其中每个元素的类型为MPFILE_TRUST_EXTRA_INFO。根据ReplyType字段,它将执行不同的操作。更有趣的两种情况是:首先,当返回信任结果时。在该示例中,信息将指向MP_INFO_RESULT,其中的值将复制到验证上下文:

16.png

第二个有趣的示例是信息指向MP_NW_CONTROL枚举。在该示例中,根据控制命令,该功能将被禁用或切换到强制模式。这基本上将更新VerifiedAndReputablePolicyState RegKey,并更新WorkItem中的策略。

17.png

在我们从学习模式更改为强制模式的情况下,将发出对函数s_SSCatDBSendSmartAppControlSwitchEnforceToast的RPC调用。在此函数中,DLL wldap . DLL将被加载,然后调用函数WldpSendSmartAppControlSwitchEnforceToast。

从信号处理程序回来后,有一些细微差别。如果NW控制命令设置了标志IsUnfriendlyFile,则Score将更新为值UnfriendalyFile(0x80000),函数将返回。如果未设置标志,则TrustInfo和FileObject将被传递到带有标志0x82的函数CipSetFileCache中,这意味着EA $Kernel.Purge.CIpCache将用于存储此信息。

最后,需要根据防御程序返回的信任调整分数,有5个选项:

Trust == 1:分数将使用值0x202进行异或运算,不过我对这个值不太了解;

Trust == -1 (0xFFFFFFFF):如果策略设置VerifiedAndReputableAllowUnknown被设置,则分数将使用值AllowUnderknown(0x20000)进行异或运算;

Trust == -2 (0xFFFFFFFE):分数将使用值Malicious (0x80)进行异或运算;

Trust == -3 (0xFFFFFFFD):分数将用PUA(0x100)值进行异或运算;

任何其他情况下,分数将用值0x42进行异或运算。

这几乎就是外部授权回调的全部内容,现在我们回到调用外部授权回调时的SIPolicyValidateImageInternal!

SIPolicyValidateImageInternal

在进入外部授权回调之前,我们将讨论SIPolicyObjectValidationEngine函数如何遍历策略并调用内部SIPolicy ValidateImageInternal,后者稍后将调用外部auth回调。现在,调用回调后,我们返回到SIPolicyValidateImageInternal,并返回验证分数。如果启用了SAC,则该函数将继续评估分数,并将此分数传播到验证引擎分数,并根据该得分设置相应的NTSTATUS。

18.png

如上图所示,在大多数分支中,它会将相应的NTSTATUS设置为验证状态,然后跳转到我所称为ProcessDbgAndReprieve的状态。这只不过是一种检查内核调试器是否附加到调试器控制台中以记录策略冲突的方法。

19.png

如果未遵循前一个映像中的任何分支,或者分数为Unattainable但设置了AllowUnknown,则函数将继续根据策略规范评估对象。首先检查文件规范,这将在函数SIPolicyMatchFileRules内完成。此函数将接收以下参数:

具有要评估的文件规范的策略;

OriginalFileName;InternalName;FileDescription;ProductName;

我强烈建议阅读MSDN的“理解Windows防御应用程序控制(WDAC)策略规范和文件规范”一节,以了解更多关于策略规范和可用于它们的不同选项的内容。

与我们在第1部分中看到的Policy Secure Settings类似,该函数将使用作为key传递到函数bsearch的数据建立一个结构。关键结构具有以下原型:

20.png

bsearch函数的base和num将取自SI_POLICY结构。将策略解析为SI_policy结构时,将设置一个包含两个场景的数组。每个场景都包含其特定的文件规范、允许的签名者、拒绝的签名者和异常规范。如上所述,当调用SIPolicyMatchFileRules时,要评估的场景的特定数量被传递给函数。此数字将用作函数的索引,以了解要选取Scenarios数组的哪个元素。每个场景都由以下结构表示:

21.png

如果没有FileName级别的文件规范匹配,则函数将继续计算哈希级别的文件规范:

22.png

如果FileName或Hash匹配,则SIPolicyMatchFileRules返回TRUE,验证状态将设置为status_SYSTEM_INTEGRITY_POLICY_VIOLATION。

如果对SAC策略使用的哈希和文件名感兴趣,可以查看策略的FileRule标签下的整个列表。

如果没有匹配的文件规范,则下一步(如果映像已签名)是根据“拒绝”和“允许”签名者验证签名链信息。首先,将检查被拒绝的签名者。如果与前面相同的规范在此匹配,该函数将把验证状态设置为status_system_integrity_policy_violate。如果没有拒绝签名者规范匹配,代码将继续检查允许的签名者规范。在该示例中,如果存在匹配,则会清除以前的任何状态/分数。根据策略签名验证映像签名的过程主要在函数SIPolicyValidateChainAgainstSigner中完成。此函数将作为第一个参数接收映像的SI_CHAIN_INFO,并在@r8中接收POLICY_SIGNERS_DATA。

关于这个POLICY_SIGNERS_DATA结构,基本上SI_POLICY结构保留一个POLICY-SIGNERS_DATA数组。这些代表两种方案的所有Allow和Deny签名。代码知道哪些规范适用于哪个场景的方式,这意味着要使用POLICY_SIGNERS_DATA数组的哪个索引是非常聪明的。这是我之前在文件规范中没有解释的事情,所以现在是检查它的好时机。如果你返回并检查SI_POLICY_SCENARIO结构,将看到对于每个规范类型结构(file, Allow, Deny),都有一个SI_RULES结构,其中包含一个我称为IndexArray的字段。基本上,这是一个索引数组,用于指示该特定场景和规则必须使用包含数据的数组中的哪个索引。让我们看一个快速的伪代码片段,以便更好地理解这一点。

23.png

这可能不是百分之百准确的,因为我省略了很多在中间进行的检查。

为了更好地了解签名是如何验证的,接下来你可以找到POLICY_SIGNERS_DATA的原型,注意,这将适用于允许签名者和拒绝签名者。

24.png

通过查看SI_CHAIN_INFO和POLICY_SIGNERS_DATA,你可以或多或少地了解如何在SIPolicyValidateChainAgainstSigner函数中进行比较。最后,为了总结Signer规范的验证,下面是在SIPolicyValidateChainAgainstSigner条目处使用SAC强制策略验证ProcessHacker时记录的映像。

25.png

老实说,为了达到这张图片的目的,我不得不稍微修改代码流。因为在第一次签名检查时,Type将匹配,然后它将退出循环。之所以会实现这一点,是因为这个POLICY_SIGNERS_DATA中的信息比第一个检查的要多。在第一次选中时,唯一的填充值是Type(设置为0x14)。我已尝试查找有关此Type值的信息,但找不到任何信息。

因此,在为每个活动策略和补充策略运行整个过程之后,我们将返回函数CipApplySiPolicyEx,为每个BasePolicy提供一个CI_VALIDATION_RESULT。补充策略的结果将写入与BasePolicy相同的CI_VALIDATION_RESULT中。此时,该函数只会遍历验证结果,将这些结果存储在validation Context中。此外,此时SmartLocker事件将记录在函数CiLogSIPolicySmartlockerEvent中。此处可以记录四种类型的事件:

SmartlockerOperationalAudit (EventId: 3091)SmartlockerOperationalFailure (EventId: 3092)SmartlockerVerbose (EventId: 3088)SmartlockerOperationalSuccess (EventId: 3090)

26.png

我们几乎完成了,现在将进入调用堆栈,将验证状态传递到上面的函数。最后,我们将回到CI入口点CiValidateImageHeader,与之前一样,我们不会对这个函数进行过多讨论。关于SAC唯一有趣的一点是,如果SigningLevel匹配以下任何一项:

尚未检查签名级别;

文件未签名;

受Windows防御措施应用程序控制策略信任;

开发者签名代码;

SAC结果是允许执行,然后将使用函数CipInstrumentNightsWatchAllow记录操作。此函数可以为提供程序CodeIntegrity编写四个基于TraceLogging的事件。具有以下名称的NWActivityVerbose & CodeIntegrity.NWActivity。

27.png

执行此函数时,将记录QuestionableAllow或Allow。如果采用了记录QuestionableAllow的路径,那么如果所需数据可用,还将写入QuestionaleAllowSignatureInfo&OriginClaimData。

由于这些是基于跟踪日志记录的事件,我们需要使用一些特殊办法来捕获跟踪。值得庆幸的是,Matt已经做了所有艰苦的工作来研究和记录这类事件的过程。看了他的文章《Windows RE使用WPP和TraceLogging》后,我们可以使用powershell中的以下4行代码来启动ETW会话,该会话将捕获NWActivity和NWActovityVerbose提供程序。

28.png

开始跟踪并使用一些应用程序/安装程序后,你应该有一个可以用EventViewer打开的EventLog,你可以发现防御措施最终信任ProcessHacker之类的事情。

29.png

总结

就个人而言,我认为微软为提高操作系统的安全性而采取的措施是很好的,其最终目标是让用户更加安全。另一方面,我确实看到了SAC和Windows 10 S之间的一些相似之处。对于SAC,当设置为强制时,限制由具有数字签名的应用程序设置,如果没有签名,则由防御措施云认为可信的应用程序进行设置。

第一种选择,即使你知道数字签名可以很好地验证应用程序,许多开源项目或自由开发者负担不起,不幸的是,这给开发者带来了一些限制。

第二个选项,即对“智能云安全服务”的查询,这也是我希望微软提供更多信息的地方,因为基本上应用程序能否运行的决定将完全取决于微软。

本文会详细分析Windows即将推出的最大安全功能——智能应用控制(Smart App Control,SAC)。“智能应用控制”功能是什么,为什么我认为它是 Windows 中最牛的安全功能之一。首先,SAC 会嵌入在操作系统中,启用后将阻止恶意或不受信任的应用程序。这与 AppLocker 非常相似。

在之前一篇文章中,我们看到了SAC是如何启用和初始化的。在本文中,我们将讨论SAC如何执行这些操作。即使SAC是一个新功能,该功能使用的大部分代码也已经在操作系统中了。我的意思是,在22H2之前的版本中,通过使用适当的策略规范,可以获得类似的行为。总之,SAC的最大变化是MS将激活特定的WDAC策略,类似于启用HVCI时,操作系统如何启用Driver Block Rule策略。

需要注意的是,因为我们在这篇文章中看到的很多内容在操作系统中已经存在了很长时间。AppLocker或AppID等功能利用了它。当然,有几个方面只适用于SAC,我一定会注意到这些。从好的方面来看,这篇文章的绝大多数可以推断出其他WDAC策略是如何评估的。

1.png

SAC运行

在本节中,我们将重点关注CI处理来自内核的验证请求所采取的步骤。我们将深入探讨此过程中涉及的主要例程,还将讨论CI使用的一些主要结构。正如我刚才提到的,这些步骤中的大多数并不是SAC独有的,无论启用哪种策略,都将采取这些步骤。如上图所示,我们看到有三个主要的评估来源。据我所知,这些要点与以下功能/策略规范有关,至于是选择使用一个或多个评估取决于策略规范。

OriginClaim (EAs or Token): 托管安装程序、AppLocker、SmartScreen和SAC;

Query 防御措施: Intelligent Security Graph (ISG) & SAC;

Policy FileRules: 通用于所有具有FileRule的策略。

2.png

在上一篇文章中,我们已经说过全局g_CiPolicyState具有位NW_ENABLED,这意味着SAC已启用,SAC策略(强制或评估)处于活动状态,并存储在g_SiPolicyCtx中。现在,让我们看看CI向内核提供的回调,看看内核的验证方式。以下函数建议执行某种类型的验证:

CiValidateImageHeader;
CiValidateImageData;
CiValidateFileAsImageType;
CiRevalidateImage;

在本文中,我将只关注CiValidateImageHeader。

CiValidateImageHeader

可以说,此函数是大多数CI验证的主要入口点。内核将从MiValidateSectionCreate中引用的SeValidateImageHeader调用此函数。CiValidateImageHeader将处理CI初始化的第2阶段,主要初始化minCrypt、ETW、Lookaside缓冲区等。一旦完成(只有一次),第一步是获取指定映像(CiGetActionsForImage)行为。此函数将根据诸如Requested SigningLevel之类的内容,或者如果对象来自受保护进程或系统进程,来确定将要进行的验证操作,这些操作是位字段枚举,但我不知道大多数值的含义.

操作进行后,函数就可以开始验证映像了。如果操作变量设置了位0(action_FILE_In_CACHE(0x1)),则CI将尝试获取之前为此FO设置的任何验证数据,并重新验证。

在本文中,我们不会涉及CI缓存及其验证原理。本质上,它将尝试获取内核EA:$Kernel.Purge.CIpCache或$Kernell.Purge.ESBCache(请参阅函数CipGetFileCache)。然后,它会将策略应用于CiApplyPolicyToSyntheticEa内的这些属性。这个例程最终将调用CipApplySiPolicyEx,我们稍后将详细讨论。

如果未设置“file in cache”属性,则会分配用于处理验证的主结构(CipAllocateValidationContext)。此结构用于所有类型的验证,例如,此上下文也用于HVCI验证(请参阅CiHvciSetValidationContextForHvci)。一旦分配了这个上下文,我看到UMCI验证会发生两个操作。

如果设置了位2(ACTION_PAGE_HASH(0x4)),验证函数为->CipValidatePageHash;

如果设置了位8(ACTION_FILE_HASH(0x100)),验证函数为->CipValidateFileHash。

CipValidateImageHash将接收发生操作的Validation函数作为函数指针。无论传递的是什么函数指针,PageHash还是FileHash,CipValidateImageHash最终都会调用它。在这两个验证函数中,CI都会使用被验证对象的信息更新验证上下文。诸如FileInfo(CipUpdateValidationContextWithFileInfo)、文件版本(CiGetFileResourceInformation)、嵌入签名(CipImageGetCertInfo)或对象哈希(Page CipCalculateHeaderHash或File CipCalpulateImageHash)。有了所有这些信息,代码将通过函数CipApplySiPolicyEx方法继续应用策略。

对于未签名映像的验证,验证函数将返回STATUS_INVALID_IMAGE_HASH,代码将进入CipApplySIPolicyUMCI,最终调用前面提到的CipApply SiPolicyEx。相反,对于签名文件,将从CiVerifyPageHashSignedFile或CiVerify FileHashSingedFile访问此函数。简单说明一下,这两个函数有它们的HVCI对应函数CiHvciXxx。

CipApplySiPolicyEx

顾名思义,此函数将把策略应用于正在验证的对象。该函数将首先设置两个结构,然后将其传递给验证引擎。一个结构将保存正在验证的ImageFile的信息,而另一个结构则包含“外部”授权过程所需的信息,我说“外部”授权是因为MS在验证对象的回调函数名中使用了“外部”授权这个词。

这两个结构将存储在Validation Context中,并且实际上都将被来自Validation Context的数据填充。其中一个包含映像数据,我命名为CI_VALIDATE_IMAGE_DATA,其中包含以下内容:

3.png

另一方面,外部授权结构(我将其命名为CI_EXTERNAL_AUTH)具有以下有趣的值:

4.png

在调用验证引擎例程之前,CipApplySiPolicyEx将设置一个结构数组,其中包含每个策略的验证结果,该数组的大小将等于活动策略的数量。我将此结构命名为CI_VALIDATION_RESULT,它具有以下字段:

5.png

最后,我们准备调用SIPolicyObjectValidationEngine,它具有以下原型:

6.png

这个例程将简单地遍历策略和补充策略,为每个策略调用内部例程SIPolicyValidateImageInternal。

内部验证例程的任务是调用外部授权回调,以从“外部源”获取验证分数。它将根据此分数,选择继续或不继续根据策略中的规范评估映像。我们将首先关注外部回调,设置为函数CipExternalAuthorizationCallback,然后我们将讨论如何评估策略规范。

从代码中我可以看到,这与MS在文件规范优先顺序一节中声明的有些不同。他们说“它将首先处理它找到的所有显式拒绝规范。然后,它将处理所有显式允许规范。如果不存在拒绝或允许规范,WDAC将检查托管安装程序EA。最后,如果这些集合都不存在,WDAC会回到ISG”。相反,在代码中,似乎在处理FileRule之前检查了托管安装程序和ISG(外部授权)。

CipExternalAuthorizationCallback

这个函数包含了SAC的核心功能,即使它从21H2到22H2没有太大的变化,当启用SAC时,有一些细节会造成很大的不同。尽管如此,我们将要讨论的大部分内容都将被AppLocker和ISG使用(并且已经被使用了),所以从好的方面来看,我们也将从中学习一些东西。为了概述我们是如何做到这一点的,下面是我们到达外部授权回调时的堆栈,用于验证未签名映像时的堆栈。

7.png

该函数将通过检查策略选项Intelligent Security Graph Authorization(智能安全图授权)或Managed Installer(托管安装程序)启动,如果这些选项都没有设置,则该函数将退出,SIPolicyValidateImageInternal将继续处理策略FileRule,我们将在稍后的章节中看到这一点。

如果设置了任何选项,下一步是根据签名级别确定映像是否可信。这是通过使用为映像获取的ValidatedSigningLevel,并将此值与全局变量g_CipWhichLevelComparisons内索引为0xC的位掩码进行比较来实现的。

请注意:全局变量g_CipWhichLevelComparisons存储了一个指向ulong数组的指针。每个值表示适用于此签名级别的比较级别。通常与已验证的签名级别一起使用,以确定映像的不同操作/选项。例如,对于等于“File Unsigned”(即数组中的索引1)的已验证签名级别,位掩码为0xFFFFFFFE,因此大多数情况下测试此位掩码时,结果都为正值。在其他情况下,如上所述,索引在代码中被硬编码为仅作用于与该索引的位掩码匹配的已验证签名级别。下表有望帮助理解g_CipWhichLevelComparisons和ValidatedSigningLevel之间的关系。

8.png

如上表所示,索引0xC表示位掩码0x5000,表示“Windows签名”和“Windows TCB签名”。此外,接下来的两个级别“仅用于.NET NGEN编译器的签名”和由使用AMPPL的产品的反病毒签名”也将包含在可信映像列表中。此时,函数将继续调用CipCheckSmartlockerEAandProcessToken以获得第一个验证分数。

我觉得这是一个讨论命名的好时机,希望微软的人能联系到我,并澄清命名。有人称之为Smart App Control和Nights Watch,也有人称之为AppLocker,内部名称似乎是SmartLocker。相同或非常相似的事物有4个不同的名称。这确实有点令人困惑。

该函数具有以下原型:

9.png

这个函数有两条路径,其中一条总是被执行,另一条基于boolean IsTrustedSigning。如果不受信任,那么下面的EA将被查询为正在验证的文件对象,它也试图从当前流程文件对象中获得相同的EA,但除了存储在验证上下文中,我没有看到它们在其他地方被使用。

$ Kernel.Smartlocker.Hash: 包含映像的哈希;

$ Kernel.Purge.Smartlocker.Valid: 布尔值是否有效;

$Kernel.Smartlocker.OriginClaim: 包含我命名为EA_ORIGIN_CLAIM的结构。

10.png

如果获得了有效的EA,那么将检查OriginClaim结构以确定图像的分数。Origin值将决定第一个分数,如果Origin == 0,则score |= 1,如果Origin == 1,则score |= 0x1002。

不过我对这方面了解不多。这很可能与WDAC在策略中设置托管安装程序选项时在AppLocker中使用的特殊规范集合有关。这很可能与在策略中设置托管安装程序选项时WDAC使用的AppLocker中的特殊规范集合有关。从我所看到的,我知道appid.sys确实设置了此EA,另一种设置此EA的方法是通过CI回调cisetcachedorigin声明。这个函数在发出带有标志0x2000的syscall NtSetCachedSigningLevel时被内核调用,当然不像调用这个syscall来设置EA origin声明那么容易,如果这个syscall以前的模式是UserMode,那么NtSetCachedSigningLevel2将确保请求来自一个受保护的进程。

下一步,无论我们是否检查了EA,都是获取存储在令牌对象中的OriginClaim。对于令牌对象,origin声明存储在令牌的SecurityAttributes列表中,这些属性存储为Authz SecurityAttributes,并且可以使用函数sequerysecurityattributeken按名称查询/检索。在本例中,将寻找两个安全属性:

SMARTLOCKER://ORIGINCLAIM;
SMARTLOCKER://SMARTSCREENORIGINCLAIMNOTINHERITED (New in 22H2, previously “SMARTLOCKER://SMARTSCREENORIGINCLAIM”)

首先将查找OriginClaim。如果发现,分数将相应调整。同样,我对这方面不太了解,也没有有关此声明的结构外观的信息 (appid.sys设置此值令牌)。

之后,将查询SmartScreen OriginClaim未继承属性,如果它被发现并设置标签CLAIM_DANGEROUS_EXT (0x80) (这不是官方名称),然后函数将继续检查ImageFile是否有被认为是危险扩展名。同样,在所有情况下,代码都将检查ImageFile是否具有InstallerExtension。对于安装程序扩展,它只会检查.msi,对于危险扩展的情况,这些值如下:

11.png

如果ImageFile与这些值中的任何一个匹配,则分数将设置为DangerousExtension (0x800),并通过调用CiCatDbSmartlockerDefenderCheck向防御措施发出查询,有关此函数稍后将详细讨论。

本文会详细分析Windows即将推出的最大安全功能——智能应用控制(Smart App Control,SAC)。“智能应用控制”功能是什么,为什么我认为它是 Windows 中最牛的安全功能之一。首先,SAC 会嵌入在操作系统中,启用后将阻止恶意或不受信任的应用程序。这与 AppLocker 非常相似。

在之前一篇文章中,我们看到了SAC是如何启用和初始化的。在本文中,我们将讨论SAC如何执行这些操作。即使SAC是一个新功能,该功能使用的大部分代码也已经在操作系统中了。我的意思是,在22H2之前的版本中,通过使用适当的策略规范,可以获得类似的行为。总之,SAC的最大变化是MS将激活特定的WDAC策略,类似于启用HVCI时,操作系统如何启用Driver Block Rule策略。

需要注意的是,因为我们在这篇文章中看到的很多内容在操作系统中已经存在了很长时间。AppLocker或AppID等功能利用了它。当然,有几个方面只适用于SAC,我一定会注意到这些。从好的方面来看,这篇文章的绝大多数可以推断出其他WDAC策略是如何评估的。

1.png

SAC运行

在本节中,我们将重点关注CI处理来自内核的验证请求所采取的步骤。我们将深入探讨此过程中涉及的主要例程,还将讨论CI使用的一些主要结构。正如我刚才提到的,这些步骤中的大多数并不是SAC独有的,无论启用哪种策略,都将采取这些步骤。如上图所示,我们看到有三个主要的评估来源。据我所知,这些要点与以下功能/策略规范有关,至于是选择使用一个或多个评估取决于策略规范。

OriginClaim (EAs or Token): 托管安装程序、AppLocker、SmartScreen和SAC;

Query 防御措施: Intelligent Security Graph (ISG) & SAC;

Policy FileRules: 通用于所有具有FileRule的策略。

2.png

在上一篇文章中,我们已经说过全局g_CiPolicyState具有位NW_ENABLED,这意味着SAC已启用,SAC策略(强制或评估)处于活动状态,并存储在g_SiPolicyCtx中。现在,让我们看看CI向内核提供的回调,看看内核的验证方式。以下函数建议执行某种类型的验证:

CiValidateImageHeader;
CiValidateImageData;
CiValidateFileAsImageType;
CiRevalidateImage;

在本文中,我将只关注CiValidateImageHeader。

CiValidateImageHeader

可以说,此函数是大多数CI验证的主要入口点。内核将从MiValidateSectionCreate中引用的SeValidateImageHeader调用此函数。CiValidateImageHeader将处理CI初始化的第2阶段,主要初始化minCrypt、ETW、Lookaside缓冲区等。一旦完成(只有一次),第一步是获取指定映像(CiGetActionsForImage)行为。此函数将根据诸如Requested SigningLevel之类的内容,或者如果对象来自受保护进程或系统进程,来确定将要进行的验证操作,这些操作是位字段枚举,但我不知道大多数值的含义.

操作进行后,函数就可以开始验证映像了。如果操作变量设置了位0(action_FILE_In_CACHE(0x1)),则CI将尝试获取之前为此FO设置的任何验证数据,并重新验证。

在本文中,我们不会涉及CI缓存及其验证原理。本质上,它将尝试获取内核EA:$Kernel.Purge.CIpCache或$Kernell.Purge.ESBCache(请参阅函数CipGetFileCache)。然后,它会将策略应用于CiApplyPolicyToSyntheticEa内的这些属性。这个例程最终将调用CipApplySiPolicyEx,我们稍后将详细讨论。

如果未设置“file in cache”属性,则会分配用于处理验证的主结构(CipAllocateValidationContext)。此结构用于所有类型的验证,例如,此上下文也用于HVCI验证(请参阅CiHvciSetValidationContextForHvci)。一旦分配了这个上下文,我看到UMCI验证会发生两个操作。

如果设置了位2(ACTION_PAGE_HASH(0x4)),验证函数为->CipValidatePageHash;

如果设置了位8(ACTION_FILE_HASH(0x100)),验证函数为->CipValidateFileHash。

CipValidateImageHash将接收发生操作的Validation函数作为函数指针。无论传递的是什么函数指针,PageHash还是FileHash,CipValidateImageHash最终都会调用它。在这两个验证函数中,CI都会使用被验证对象的信息更新验证上下文。诸如FileInfo(CipUpdateValidationContextWithFileInfo)、文件版本(CiGetFileResourceInformation)、嵌入签名(CipImageGetCertInfo)或对象哈希(Page CipCalculateHeaderHash或File CipCalpulateImageHash)。有了所有这些信息,代码将通过函数CipApplySiPolicyEx方法继续应用策略。

对于未签名映像的验证,验证函数将返回STATUS_INVALID_IMAGE_HASH,代码将进入CipApplySIPolicyUMCI,最终调用前面提到的CipApply SiPolicyEx。相反,对于签名文件,将从CiVerifyPageHashSignedFile或CiVerify FileHashSingedFile访问此函数。简单说明一下,这两个函数有它们的HVCI对应函数CiHvciXxx。

CipApplySiPolicyEx

顾名思义,此函数将把策略应用于正在验证的对象。该函数将首先设置两个结构,然后将其传递给验证引擎。一个结构将保存正在验证的ImageFile的信息,而另一个结构则包含“外部”授权过程所需的信息,我说“外部”授权是因为MS在验证对象的回调函数名中使用了“外部”授权这个词。

这两个结构将存储在Validation Context中,并且实际上都将被来自Validation Context的数据填充。其中一个包含映像数据,我命名为CI_VALIDATE_IMAGE_DATA,其中包含以下内容:

3.png

另一方面,外部授权结构(我将其命名为CI_EXTERNAL_AUTH)具有以下有趣的值:

4.png

在调用验证引擎例程之前,CipApplySiPolicyEx将设置一个结构数组,其中包含每个策略的验证结果,该数组的大小将等于活动策略的数量。我将此结构命名为CI_VALIDATION_RESULT,它具有以下字段:

5.png

最后,我们准备调用SIPolicyObjectValidationEngine,它具有以下原型:

6.png

这个例程将简单地遍历策略和补充策略,为每个策略调用内部例程SIPolicyValidateImageInternal。

内部验证例程的任务是调用外部授权回调,以从“外部源”获取验证分数。它将根据此分数,选择继续或不继续根据策略中的规范评估映像。我们将首先关注外部回调,设置为函数CipExternalAuthorizationCallback,然后我们将讨论如何评估策略规范。

从代码中我可以看到,这与MS在文件规范优先顺序一节中声明的有些不同。他们说“它将首先处理它找到的所有显式拒绝规范。然后,它将处理所有显式允许规范。如果不存在拒绝或允许规范,WDAC将检查托管安装程序EA。最后,如果这些集合都不存在,WDAC会回到ISG”。相反,在代码中,似乎在处理FileRule之前检查了托管安装程序和ISG(外部授权)。

CipExternalAuthorizationCallback

这个函数包含了SAC的核心功能,即使它从21H2到22H2没有太大的变化,当启用SAC时,有一些细节会造成很大的不同。尽管如此,我们将要讨论的大部分内容都将被AppLocker和ISG使用(并且已经被使用了),所以从好的方面来看,我们也将从中学习一些东西。为了概述我们是如何做到这一点的,下面是我们到达外部授权回调时的堆栈,用于验证未签名映像时的堆栈。

7.png

该函数将通过检查策略选项Intelligent Security Graph Authorization(智能安全图授权)或Managed Installer(托管安装程序)启动,如果这些选项都没有设置,则该函数将退出,SIPolicyValidateImageInternal将继续处理策略FileRule,我们将在稍后的章节中看到这一点。

如果设置了任何选项,下一步是根据签名级别确定映像是否可信。这是通过使用为映像获取的ValidatedSigningLevel,并将此值与全局变量g_CipWhichLevelComparisons内索引为0xC的位掩码进行比较来实现的。

请注意:全局变量g_CipWhichLevelComparisons存储了一个指向ulong数组的指针。每个值表示适用于此签名级别的比较级别。通常与已验证的签名级别一起使用,以确定映像的不同操作/选项。例如,对于等于“File Unsigned”(即数组中的索引1)的已验证签名级别,位掩码为0xFFFFFFFE,因此大多数情况下测试此位掩码时,结果都为正值。在其他情况下,如上所述,索引在代码中被硬编码为仅作用于与该索引的位掩码匹配的已验证签名级别。下表有望帮助理解g_CipWhichLevelComparisons和ValidatedSigningLevel之间的关系。

8.png

如上表所示,索引0xC表示位掩码0x5000,表示“Windows签名”和“Windows TCB签名”。此外,接下来的两个级别“仅用于.NET NGEN编译器的签名”和由使用AMPPL的产品的反病毒签名”也将包含在可信映像列表中。此时,函数将继续调用CipCheckSmartlockerEAandProcessToken以获得第一个验证分数。

我觉得这是一个讨论命名的好时机,希望微软的人能联系到我,并澄清命名。有人称之为Smart App Control和Nights Watch,也有人称之为AppLocker,内部名称似乎是SmartLocker。相同或非常相似的事物有4个不同的名称。这确实有点令人困惑。

该函数具有以下原型:

9.png

这个函数有两条路径,其中一条总是被执行,另一条基于boolean IsTrustedSigning。如果不受信任,那么下面的EA将被查询为正在验证的文件对象,它也试图从当前流程文件对象中获得相同的EA,但除了存储在验证上下文中,我没有看到它们在其他地方被使用。

$ Kernel.Smartlocker.Hash: 包含映像的哈希;

$ Kernel.Purge.Smartlocker.Valid: 布尔值是否有效;

$Kernel.Smartlocker.OriginClaim: 包含我命名为EA_ORIGIN_CLAIM的结构。

10.png

如果获得了有效的EA,那么将检查OriginClaim结构以确定图像的分数。Origin值将决定第一个分数,如果Origin == 0,则score |= 1,如果Origin == 1,则score |= 0x1002。

不过我对这方面了解不多。这很可能与WDAC在策略中设置托管安装程序选项时在AppLocker中使用的特殊规范集合有关。这很可能与在策略中设置托管安装程序选项时WDAC使用的AppLocker中的特殊规范集合有关。从我所看到的,我知道appid.sys确实设置了此EA,另一种设置此EA的方法是通过CI回调cisetcachedorigin声明。这个函数在发出带有标志0x2000的syscall NtSetCachedSigningLevel时被内核调用,当然不像调用这个syscall来设置EA origin声明那么容易,如果这个syscall以前的模式是UserMode,那么NtSetCachedSigningLevel2将确保请求来自一个受保护的进程。

下一步,无论我们是否检查了EA,都是获取存储在令牌对象中的OriginClaim。对于令牌对象,origin声明存储在令牌的SecurityAttributes列表中,这些属性存储为Authz SecurityAttributes,并且可以使用函数sequerysecurityattributeken按名称查询/检索。在本例中,将寻找两个安全属性:

SMARTLOCKER://ORIGINCLAIM;
SMARTLOCKER://SMARTSCREENORIGINCLAIMNOTINHERITED (New in 22H2, previously “SMARTLOCKER://SMARTSCREENORIGINCLAIM”)

首先将查找OriginClaim。如果发现,分数将相应调整。同样,我对这方面不太了解,也没有有关此声明的结构外观的信息 (appid.sys设置此值令牌)。

之后,将查询SmartScreen OriginClaim未继承属性,如果它被发现并设置标签CLAIM_DANGEROUS_EXT (0x80) (这不是官方名称),然后函数将继续检查ImageFile是否有被认为是危险扩展名。同样,在所有情况下,代码都将检查ImageFile是否具有InstallerExtension。对于安装程序扩展,它只会检查.msi,对于危险扩展的情况,这些值如下:

11.png

如果ImageFile与这些值中的任何一个匹配,则分数将设置为DangerousExtension (0x800),并通过调用CiCatDbSmartlockerDefenderCheck向防御措施发出查询,有关此函数稍后将详细讨论。

abstract_binary_brain_report-1200x600.jpg

勒索软件

季度趋势和亮点

2022年第三季度,知名勒索软件LockBit源代码被泄漏。如今,LockBit 3.0工具包已经被广泛攻击者广泛使用。与过去的其他勒索软件家族(如Babuk和Conti)类似,该勒索软件开始为与LockBit无关的其他组织提供服务。比如5月份发现的Bloody/B100dy,该组织于2022年9月将新推出的LockBit添加到了自己的武器库中。

对NAS(网络连接存储)设备的大规模攻击仍在继续。QNAP在2022年第三季度发布了关于Checkmate和Deadbolt感染的警告。Checkmate威胁通过SMB协议从互联网访问的文件,并受到弱帐户密码的保护。Deadbolt攻击了安装了Photo Station软件(一款照片管理软件)的易受攻击版本的设备。针对NAS的威胁仍然突出,因此我们建议保持这些设备无法从互联网访问,以确保数据的最大安全。

鲜为人知的AstraLocker和Yashma勒索软件的开发者发布了解密程序,并停止了这两个勒索软件的传播。黑客没有对此举做出解释,但这似乎与媒体报道的增加有关。

软件迭代

2022年第三季度,我们检测到17个新的勒索软件家族和14626个这种恶意软件类型的新修改。其中11000多人的攻击和Trojan-Ransom.Win32.Crypmod有关。

4.png

2021年第三季度至2022年第三季度软件迭代数量

被勒索软件木马攻击的用户数

2022年第三季度,卡巴斯基的产品和技术保护了72941名用户免受勒索软件攻击。

5.png

2022年第三季度被勒索软件木马攻击的用户数量

十大银行恶意软件家族

6.png

十大最常见的勒索软件木马家族

8.png

新型挖矿软件

2022年第三季度,卡巴斯基系统检测到153773个新的挖矿模式。其中超过14万个在7月和8月被发现,加上6月份的统计,这表明挖矿活动一直很猖獗。

9.png

挖矿软件攻击的用户数

在第三季度,挖矿软件攻击活动又增加了。

10.png

2022年第三季度挖矿软件攻击的用户数量

攻击者在网络攻击期间使用的易受攻击的应用程序

季度亮点

让我们从Microsoft Windows及其一些组件开始说起,研究人员发现了影响CLFS驱动程序的新漏洞:CVE-2022-30220,以及CVE-2022-25803和CVE-2022-17969,它们都是在野外被发现的。通过以特定方式操纵公共日志文件系统数据,攻击者可以使内核将自己的数据写入任意内存地址,从而允许网络攻击者劫持内核控制并提升其在系统中的特权。在Print Spooler服务中发现了几个漏洞:CVE-2022-22022、CVE-2022-30206和CVE-2022-3 0226。

这些漏洞允许在安装打印机时通过一系列操作提升系统权限。在客户端/服务器运行时子系统(CSRSS)(一个重要的Windows组件)中也发现了严重的漏洞。其中一些漏洞可用于权限升级(CVE-2022-22047、CVE-2022-2049和CVE-2022-2 2026),而CVE-20212-22038影响远程过程调用(RPC)协议,允许攻击者远程执行任意代码。在图形子系统中发现了CVE-2022-22034和CVE-2022-35750等一系列关键漏洞,也可以利用这些漏洞进行权限升级。请注意,以上大多数漏洞都需要在攻击者运行恶意软件之前在系统中进行防御。微软支持诊断工具(MSDT)被发现包含另外两个漏洞CVE-2022-34713和CVE-2022-35743,可以利用链接处理程序中的安全漏洞在系统中远程运行命令。

2022年第三季度检测到的大多数网络威胁仍然是与Microsoft SQL Server、RDP和其他服务的暴力强制密码相关的攻击。通过EternalBlue、EternalRomance和其他漏洞对Windows的脆弱版本进行网络攻击仍然很常见。通过Log4j库(CVE-2021-44228、CVE-2021-44832、CVE-2021-45046和CVE-2021-45105)中的漏洞利用网络服务和其他软件的尝试也在继续。

在Microsoft Windows网络文件系统(NFS)驱动程序中发现了几个漏洞。它们是CVE-2022-22028,它可能导致机密信息泄漏,还有CVE-2022-22029, CVE-2022-22039和CVE-2022-34715,攻击者可以使用它们在系统中(在内核上下文中)通过使用特别制作的网络数据包远程执行任意代码。发现TCP/IP栈包含关键漏洞CVE-2022-34718,该漏洞理论上允许利用IPv6协议处理程序中的错误远程利用目标系统。最后,值得一提的是CVE-2022-34724漏洞,该漏洞会影响Windows DNS Server,如果被利用,可能会导致拒绝服务。

Microsoft Exchange Server中的两个漏洞CVE-2022-41040和CVE-2022-4 1082受到了媒体的广泛报道。它们被统称为“ProxyNotShell”,指的是具有类似攻击技术的ProxyShell漏洞(目前已关闭)。研究人员在调查APT攻击时发现了ProxyNotShell漏洞:经过身份验证的用户可以利用漏洞提升其权限,并在MS Exchange服务器上运行任意代码。因此,攻击者可以窃取机密数据,加密服务器上的关键文件,以勒索受害者的钱财等。

2022年第三季度,恶意Microsoft Office文档再次成为检测最多的漏洞载体,占我们发现的漏洞的80%,尽管与第二季度相比,数量略有下降。这些检测大多是由针对以下漏洞的攻击引发的:

公式编辑器组件中的CVE-2018-0802和CVE-2017-11882,允许在处理公式时破坏应用程序内存,随后在系统中运行任意代码;

CVE-2017-0199,允许下载和运行恶意脚本文件;

CVE-2022-30190,也称为“Follina”,它利用Microsoft Windows支持诊断工具(MSDT)中的漏洞,在易受攻击的系统中运行任意程序,即使在保护模式下或宏被禁用时也是如此;

CVE-2021-40444,由于输入验证不充分,攻击者可以使用特殊的ActiveX模板部署恶意代码。

12.png

攻击者使用的漏洞情况

随后是针对浏览器的攻击,他们的份额达到6%,比第二季度高1%。我们将列出最严重的漏洞,所有漏洞都针对谷歌Chrome:

CVE-2022-2294,在WebRTC组件中,导致缓冲区溢出;

CVE-2022-2624,它利用PDF查看组件中的内存溢出漏洞;

CVE-2022-2295,一种类型混淆漏洞,允许攻击者远程攻击浏览器进程内存并在沙盒中运行任意代码;

CVE-2022-3075,一个与谷歌chrome浏览器中Mojo进程间通信组件输入验证不充分有关的漏洞,允许逃逸沙箱并在系统中运行任意命令。

由于许多现代浏览器都基于GoogleChromium,攻击者通常可以利用共享漏洞攻击其他浏览器,只要它们在一个引擎上运行。

在Microsoft Edge中发现了一系列漏洞。值得注意的是CVE-2022-33649,它允许通过绕过浏览器保护在系统中运行应用程序CVE-2022-33636和CVE-2022-3 5796,最终允许沙盒逃脱的条件漏洞CVE-2022-38012,它利用了一个应用程序内存损坏漏洞,产生了类似的结果。

Mozilla Firefox浏览器被发现包含与内存破坏相关的漏洞,这些漏洞允许在系统中运行任意代码:CVE-2022-38476,这是一个竞争条件漏洞,导致随后的自由使用场景,以及利用内存破坏的类似漏洞CVE-2022-3 8477和CVE-2022-28478。从我们的报告中可以看到,浏览器是网络攻击者的一个有吸引力的目标,因为它们被广泛使用,并允许攻击者在用户不知情的情况下远程渗透系统。也就是说,要利用浏览器漏洞并不容易,因为攻击者通常必须使用一系列漏洞来绕过现代浏览器的保护。

其余则是Android(5%),Java(4%)和Adobe Flash(3%)漏洞,其中针对Adobe Flash的漏洞是一种过时但仍在使用的技术。

对macOS的攻击

2022年第三季度出现了大量有趣的macOS恶意软件,特别是,研究人员发现了名为Operation In(ter)ception的活动,这些攻击是由 Lazarus Group 的成员实施的。Lazarus Group 是朝鲜最大的黑客组织,黑客一直在通过加密货币交易所提供诱人的工作机会来吸引macOS 用户。黑客将恶意软件伪装成来自流行的加密货币交易所的招聘信息,使用精心设计且看起来合法的诱饵PDF文档来宣传空缺职位,该恶意软件伪装成包含Coinbase和Crypto.com职位摘要的文件。

CloudMensis是一个用Objective-C编写的间谍程序,它使用云存储服务作为C&C服务器,并与ScarCruft操作的RokRAT Windows恶意软件共享一些特性。

XCSSET的创建者将他们的工具集改编为macOS Monterey,并从Python 2迁移到Python 3。

第三季度,网络黑客也开始利用开源工具进行攻击。7月份发现了两个使用虚假VPN应用程序和虚假Salesforce更新的活动,这两个活动都是基于Sliver框架构建的。

除此之外,研究人员还宣布了一项新的发现:LuckyMouse组织用中文即时通讯应用MiMi的恶意mod攻击Windows、Linux和macOS用户。

macOS的前20大威胁

13.png

与往常一样,卡巴斯基macOS安全解决方案用户遇到的最大威胁排名前20位的主要是广告软件。AdWare.OSX.Amc.e连续第二季度蝉联榜首。该应用程序显示虚假的系统漏洞消息,提供购买完整版本来修复这些漏洞。第二名和第三名分别来自adware . osx . pirit和AdWare.OSX.Agent家族。

物联网攻击

物联网威胁统计

2022年第三季度,攻击卡巴斯基蜜罐的设备中有四分之三使用了Telnet协议。

15.png

2022年第3季度,按攻击设备的唯一IP地址数量划分的受攻击服务分布

大多数针对卡巴斯基蜜罐的攻击都是通过Telnet控制的。

16.png

通过Telnet的物联网设备十大威胁

17.png

通过web资源进行的攻击

本节中的统计数据基于Web Anti-Virus,当从恶意/受感染的网页下载恶意对象时,它会保护用户。网络攻击者故意创建这些网站,他们可以用用户创建的内容(如论坛)感染被黑客入侵的合法资源以及网络资源。

2022年第三季度,卡巴斯基解决方案阻止了来自全球在线资源的956074958次攻击。共有251288987个唯一URL被Web防病毒组件识别为恶意。

abstract_binary_brain_report-1200x600.jpg

勒索软件

季度趋势和亮点

2022年第三季度,知名勒索软件LockBit源代码被泄漏。如今,LockBit 3.0工具包已经被广泛攻击者广泛使用。与过去的其他勒索软件家族(如Babuk和Conti)类似,该勒索软件开始为与LockBit无关的其他组织提供服务。比如5月份发现的Bloody/B100dy,该组织于2022年9月将新推出的LockBit添加到了自己的武器库中。

对NAS(网络连接存储)设备的大规模攻击仍在继续。QNAP在2022年第三季度发布了关于Checkmate和Deadbolt感染的警告。Checkmate威胁通过SMB协议从互联网访问的文件,并受到弱帐户密码的保护。Deadbolt攻击了安装了Photo Station软件(一款照片管理软件)的易受攻击版本的设备。针对NAS的威胁仍然突出,因此我们建议保持这些设备无法从互联网访问,以确保数据的最大安全。

鲜为人知的AstraLocker和Yashma勒索软件的开发者发布了解密程序,并停止了这两个勒索软件的传播。黑客没有对此举做出解释,但这似乎与媒体报道的增加有关。

软件迭代

2022年第三季度,我们检测到17个新的勒索软件家族和14626个这种恶意软件类型的新修改。其中11000多人的攻击和Trojan-Ransom.Win32.Crypmod有关。

4.png

2021年第三季度至2022年第三季度软件迭代数量

被勒索软件木马攻击的用户数

2022年第三季度,卡巴斯基的产品和技术保护了72941名用户免受勒索软件攻击。

5.png

2022年第三季度被勒索软件木马攻击的用户数量

十大银行恶意软件家族

6.png

十大最常见的勒索软件木马家族

8.png

新型挖矿软件

2022年第三季度,卡巴斯基系统检测到153773个新的挖矿模式。其中超过14万个在7月和8月被发现,加上6月份的统计,这表明挖矿活动一直很猖獗。

9.png

挖矿软件攻击的用户数

在第三季度,挖矿软件攻击活动又增加了。

10.png

2022年第三季度挖矿软件攻击的用户数量

攻击者在网络攻击期间使用的易受攻击的应用程序

季度亮点

让我们从Microsoft Windows及其一些组件开始说起,研究人员发现了影响CLFS驱动程序的新漏洞:CVE-2022-30220,以及CVE-2022-25803和CVE-2022-17969,它们都是在野外被发现的。通过以特定方式操纵公共日志文件系统数据,攻击者可以使内核将自己的数据写入任意内存地址,从而允许网络攻击者劫持内核控制并提升其在系统中的特权。在Print Spooler服务中发现了几个漏洞:CVE-2022-22022、CVE-2022-30206和CVE-2022-3 0226。

这些漏洞允许在安装打印机时通过一系列操作提升系统权限。在客户端/服务器运行时子系统(CSRSS)(一个重要的Windows组件)中也发现了严重的漏洞。其中一些漏洞可用于权限升级(CVE-2022-22047、CVE-2022-2049和CVE-2022-2 2026),而CVE-20212-22038影响远程过程调用(RPC)协议,允许攻击者远程执行任意代码。在图形子系统中发现了CVE-2022-22034和CVE-2022-35750等一系列关键漏洞,也可以利用这些漏洞进行权限升级。请注意,以上大多数漏洞都需要在攻击者运行恶意软件之前在系统中进行防御。微软支持诊断工具(MSDT)被发现包含另外两个漏洞CVE-2022-34713和CVE-2022-35743,可以利用链接处理程序中的安全漏洞在系统中远程运行命令。

2022年第三季度检测到的大多数网络威胁仍然是与Microsoft SQL Server、RDP和其他服务的暴力强制密码相关的攻击。通过EternalBlue、EternalRomance和其他漏洞对Windows的脆弱版本进行网络攻击仍然很常见。通过Log4j库(CVE-2021-44228、CVE-2021-44832、CVE-2021-45046和CVE-2021-45105)中的漏洞利用网络服务和其他软件的尝试也在继续。

在Microsoft Windows网络文件系统(NFS)驱动程序中发现了几个漏洞。它们是CVE-2022-22028,它可能导致机密信息泄漏,还有CVE-2022-22029, CVE-2022-22039和CVE-2022-34715,攻击者可以使用它们在系统中(在内核上下文中)通过使用特别制作的网络数据包远程执行任意代码。发现TCP/IP栈包含关键漏洞CVE-2022-34718,该漏洞理论上允许利用IPv6协议处理程序中的错误远程利用目标系统。最后,值得一提的是CVE-2022-34724漏洞,该漏洞会影响Windows DNS Server,如果被利用,可能会导致拒绝服务。

Microsoft Exchange Server中的两个漏洞CVE-2022-41040和CVE-2022-4 1082受到了媒体的广泛报道。它们被统称为“ProxyNotShell”,指的是具有类似攻击技术的ProxyShell漏洞(目前已关闭)。研究人员在调查APT攻击时发现了ProxyNotShell漏洞:经过身份验证的用户可以利用漏洞提升其权限,并在MS Exchange服务器上运行任意代码。因此,攻击者可以窃取机密数据,加密服务器上的关键文件,以勒索受害者的钱财等。

2022年第三季度,恶意Microsoft Office文档再次成为检测最多的漏洞载体,占我们发现的漏洞的80%,尽管与第二季度相比,数量略有下降。这些检测大多是由针对以下漏洞的攻击引发的:

公式编辑器组件中的CVE-2018-0802和CVE-2017-11882,允许在处理公式时破坏应用程序内存,随后在系统中运行任意代码;

CVE-2017-0199,允许下载和运行恶意脚本文件;

CVE-2022-30190,也称为“Follina”,它利用Microsoft Windows支持诊断工具(MSDT)中的漏洞,在易受攻击的系统中运行任意程序,即使在保护模式下或宏被禁用时也是如此;

CVE-2021-40444,由于输入验证不充分,攻击者可以使用特殊的ActiveX模板部署恶意代码。

12.png

攻击者使用的漏洞情况

随后是针对浏览器的攻击,他们的份额达到6%,比第二季度高1%。我们将列出最严重的漏洞,所有漏洞都针对谷歌Chrome:

CVE-2022-2294,在WebRTC组件中,导致缓冲区溢出;

CVE-2022-2624,它利用PDF查看组件中的内存溢出漏洞;

CVE-2022-2295,一种类型混淆漏洞,允许攻击者远程攻击浏览器进程内存并在沙盒中运行任意代码;

CVE-2022-3075,一个与谷歌chrome浏览器中Mojo进程间通信组件输入验证不充分有关的漏洞,允许逃逸沙箱并在系统中运行任意命令。

由于许多现代浏览器都基于GoogleChromium,攻击者通常可以利用共享漏洞攻击其他浏览器,只要它们在一个引擎上运行。

在Microsoft Edge中发现了一系列漏洞。值得注意的是CVE-2022-33649,它允许通过绕过浏览器保护在系统中运行应用程序CVE-2022-33636和CVE-2022-3 5796,最终允许沙盒逃脱的条件漏洞CVE-2022-38012,它利用了一个应用程序内存损坏漏洞,产生了类似的结果。

Mozilla Firefox浏览器被发现包含与内存破坏相关的漏洞,这些漏洞允许在系统中运行任意代码:CVE-2022-38476,这是一个竞争条件漏洞,导致随后的自由使用场景,以及利用内存破坏的类似漏洞CVE-2022-3 8477和CVE-2022-28478。从我们的报告中可以看到,浏览器是网络攻击者的一个有吸引力的目标,因为它们被广泛使用,并允许攻击者在用户不知情的情况下远程渗透系统。也就是说,要利用浏览器漏洞并不容易,因为攻击者通常必须使用一系列漏洞来绕过现代浏览器的保护。

其余则是Android(5%),Java(4%)和Adobe Flash(3%)漏洞,其中针对Adobe Flash的漏洞是一种过时但仍在使用的技术。

对macOS的攻击

2022年第三季度出现了大量有趣的macOS恶意软件,特别是,研究人员发现了名为Operation In(ter)ception的活动,这些攻击是由 Lazarus Group 的成员实施的。Lazarus Group 是朝鲜最大的黑客组织,黑客一直在通过加密货币交易所提供诱人的工作机会来吸引macOS 用户。黑客将恶意软件伪装成来自流行的加密货币交易所的招聘信息,使用精心设计且看起来合法的诱饵PDF文档来宣传空缺职位,该恶意软件伪装成包含Coinbase和Crypto.com职位摘要的文件。

CloudMensis是一个用Objective-C编写的间谍程序,它使用云存储服务作为C&C服务器,并与ScarCruft操作的RokRAT Windows恶意软件共享一些特性。

XCSSET的创建者将他们的工具集改编为macOS Monterey,并从Python 2迁移到Python 3。

第三季度,网络黑客也开始利用开源工具进行攻击。7月份发现了两个使用虚假VPN应用程序和虚假Salesforce更新的活动,这两个活动都是基于Sliver框架构建的。

除此之外,研究人员还宣布了一项新的发现:LuckyMouse组织用中文即时通讯应用MiMi的恶意mod攻击Windows、Linux和macOS用户。

macOS的前20大威胁

13.png

与往常一样,卡巴斯基macOS安全解决方案用户遇到的最大威胁排名前20位的主要是广告软件。AdWare.OSX.Amc.e连续第二季度蝉联榜首。该应用程序显示虚假的系统漏洞消息,提供购买完整版本来修复这些漏洞。第二名和第三名分别来自adware . osx . pirit和AdWare.OSX.Agent家族。

物联网攻击

物联网威胁统计

2022年第三季度,攻击卡巴斯基蜜罐的设备中有四分之三使用了Telnet协议。

15.png

2022年第3季度,按攻击设备的唯一IP地址数量划分的受攻击服务分布

大多数针对卡巴斯基蜜罐的攻击都是通过Telnet控制的。

16.png

通过Telnet的物联网设备十大威胁

17.png

通过web资源进行的攻击

本节中的统计数据基于Web Anti-Virus,当从恶意/受感染的网页下载恶意对象时,它会保护用户。网络攻击者故意创建这些网站,他们可以用用户创建的内容(如论坛)感染被黑客入侵的合法资源以及网络资源。

2022年第三季度,卡巴斯基解决方案阻止了来自全球在线资源的956074958次攻击。共有251288987个唯一URL被Web防病毒组件识别为恶意。

Earth Preta组织从3月开始就在全球肆虐,其开发的恶意软件家族包括TONEINS、TONESHELL和PUBLOAD。Earth Preta又名Mustang Panda或Bronze President。该组织的攻击对象包括但不限于缅甸、澳大利亚、菲律宾、日本等国家。

趋势科技的研究人员最近发现Earth Preta滥用虚假谷歌账户,通过鱼叉式网络钓鱼电子邮件传播恶意软件,这些电子邮件最初存储在一个存档文件(如rar/zip/jar)中,并通过Google Drive链接传播。然后诱骗用户下载并触发恶意软件执行TONEINS、TONESHELL和PUBLOAD。PUBLOAD之前已被报道,我们会在本文将其与TONEINS和TONESHELL联系起来,后者是该组织在其活动中新使用的恶意软件家族。

此外,攻击者利用不同的技术来逃避检测和分析,如代码混淆和自定义异常处理程序。我们还发现,鱼叉式网络钓鱼邮件的发件人和Google Drive链接的所有者是相同的。根据用于诱骗受害者的样本文件,我们还认为,攻击者能够对目标组织进行研究,并可能事先对其进行破坏,从而使其变得熟悉,这在之前被泄露的账户名称的缩写中有所显示。

在这篇文章中,我们讨论了Earth Preta的活动及其策略、技术和程序(TTP),包括新的安装程序和后门。

受害目标分析

根据我们对这一威胁的监测,诱饵文件是用缅甸文写成的,内容是“仅限内部”。文件中的大多数主题都是国家间有争议的问题,包含“机密”或“机密”等词 ,这可能表明,攻击者将缅甸政府作为他们的第一个立足点。这也可能意味着,攻击者在攻击之前就已经对特定的政治对象进行了破坏,Talos研究人员此前也注意到了这一点。

攻击者利用窃取的文件作为诱饵,诱骗与缅甸政府机构有合作关系的目标组织下载并执行恶意文件。受害者涵盖了世界范围内广泛的组织和垂直领域,其中亚太地区的受害者集中度更高。除了在缅甸开展合作的政府办事处外,随后的受害者还包括教育和研究行业等。除了以涉及特定组织的正在进行的国际事件为诱饵之外,攻击者还用与色情材料有关的标题引诱个人用户下载。

2.png

Earth Preta的目标行业分布

攻击进程

Earth Preta使用鱼叉式网络钓鱼邮件作为攻击的第一步。如前所述,一些邮件的主题和内容讨论地缘政治话题,而其他邮件可能包含耸人听闻的主题。我们观察到,我们分析的所有电子邮件中都嵌入了Google Drive链接,这表明用户可能会被诱骗下载恶意文件。文件类型包括压缩文件,例如.rar、.zip和.jar。访问链接后,我们了解到文件包含恶意软件TONEINS、TONESHELL和PUBLOAD。

4.png

有关会议记录的电子邮件文档,可能是从先前的攻击中窃取的

鱼叉式网络钓鱼电子邮件

通过分析电子邮件的内容,发现Google Drive链接被用来诱骗受害者。电子邮件的主题可能为空,或者可能与恶意文件同名。攻击者没有将受害者的地址添加到电子邮件的“收件人”标题中,而是使用了假电子邮件。同时,真实受害者的地址被写在“CC”标题中,可能会逃避安全分析,延缓调查。使用开源情报(OSINT)工具GHunt来探测“收件人”部分中的那些Gmail地址,我们发现了这些虚假账户,其中几乎没有信息。

此外,我们观察到一些发件人可能是来自特定组织的电子邮件帐户。受害者可能会相信这些邮件是由可信的合作伙伴发送的,这增加了收件人选择恶意链接的机会。

虚假文件

我们还发现了一些与缅甸政府对象相关或与之合作的组织有关的虚假文件。其中包含了缅甸和中国大使馆之间的粗略会面时间表。另一份文件与日本科学促进协会(JSPS)有关,该协会为研究人员提供在日本进行研究交流的机会。值得注意的是,压缩文件附件中主要是图片。用于下一层侧加载的恶意DLL和可执行文件也包含在其中。

5.png

有关政府会议(左)及海外研究交流(右)的虚假文件样本

此外,还有其他内容主题多样的诱饵文件,包括地区事务和色情内容。但是,当受害者打开这个文件夹中的假文档文件时,没有相应的内容出现。

其他攻击途径

我们观察到至少三种类型的攻击途径,包括通过Google Drive链接、Dropbox链接或其他托管文件的IP地址分布在世界各地的30多个诱饵文件。在我们收集的大多数样本中,都有合法的可执行文件,以及侧加载的DLL。诱饵文件的名称在每个案例中都有所不同。在接下来的部分中,我们将以其中一些为例,介绍每一个的TTP。

DLL侧加载

在该示例中,有三个文件:“~”, Increasingly confident US is baiting China.exe和libcef.dll。值得注意的是,诱饵文件和可执行文件的名称可能不同,详细信息将在下一节中介绍。

6.png

诱饵文件

7.png

PUBLOAD文件中的诱饵文件

可以看出“~”文件是一个诱饵文件。Increasingly confident US is baiting China.exe是一个合法的可执行文件(最初名为adobe_licensing_wf_helper.exe,即adobe licensing wf helper)。这个可执行文件将侧载恶意的libeff .dll并触发导出函数cef_api_hash。

首次执行时,可执行文件尝试通过复制.exe文件和移动libcef.dll(趋势科技将其命名为Trojan.W32.PUBLOAD)。

8.png

恶意活动

快捷链接

恶意文件包含三个文件:New Word Document.lnk、putty.exe和CefBrowser.dll。特别是,DLL和可执行文件被放置在名为“_”的多层文件夹中。

9.png

攻击者利用.lnk文件通过使用WinRAR解压缩文件来安装恶意文件。完整的命令行如下所示。

10.png

Pputty.exe伪装成一个正常的可执行文件,其原始文件名为AppXUpdate.exe。当它被执行时,它会加载CefBrowser.dll,并在它的导出函数CCefInterface::SubProcessMain中执行主例程。它还滥用schtask来实现持久性。

10.png

恶意软件

在这次活动中,研究人员识别出使用了以下恶意软件,即PUBLOAD、TONEINS和TONESHELL。

Trojan.Win32.PUBLOAD

PUBLOAD是一个可以从其指挥控制(C&C)服务器下载下一级有效负载的stager。该恶意软件于2022年5月由Cisco Talos首次披露。

一旦.dll被执行,它首先通过调用OpenEventA来检查相同的进程是否已经在运行。根据Barberousse发布的推文,一些值得注意的事件名称被识别为Twitter上其他网络安全研究人员的用户名,如“moto_sato”、“xaacrazyman_armyCIAx”和“JohnHammondTeam”。值得注意的是,这些研究人员与PUBLOAD没有任何关系,只是被二进制文件中的攻击者有意提及。

14.png

PUBLOAD中特殊事件名称的示例

持久性分析

PUBLOAD在

1. 添加注册表运行项

15.png

2. 创建计划任务

16.png

反分析技术:带有回调的API

PUBLOAD恶意软件在内存中的AES算法中解密shellcode。shellcode是通过创建线程或使用不同的API调用的。API可以接受回调函数的参数,作为触发shellcode的替代方法。我们观察到一些利用API的情况,包括GrayStringW、EnumDateFormatsA和LineDDA,可以将其视为绕过反病毒监视和检测的技术。

17.png

PUBLOAD中的shellcode回调示例

18.png

接受回调函数的API

C&C协议

解密的PUBLOAD shell代码收集计算机名和用户名作为第一个信标的有效负载。有效负载将使用预定义的RC4 (Rivest Cipher 4)密钥进行加密。在撰写本文时,到目前为止我们看到的所有阶段都共享相同的密钥。

加密后,stager使用特定的字节序列作为其数据包的标头。它在加密数据之前加上神奇的字节“17 03 03”和有效负载大小。

19.png

PUBLOAD恶意软件中使用的RC4密钥(顶部)和数据包主体(底部)

20.png

PUBLOAD中的请求数据包格式

stager还检查响应包是否具有相同的魔术标头“17 03 03”。在内存中下载的有效负载将被视为一段shellcode,并将直接执行。

值得注意的调试字符串

在2022年初,我们发现了一些嵌入调试字符串的PUBLOAD示例。它们被用来分散分析人员对主要感染程序的注意力。

21.png

PUBLOAD中分散注意力的调试字符串

Trojan.Win32.TONEINS

Trojan.Win32.TONEINS是TONESHELL后门的安装程序。安装程序将TONESHELL恶意软件放入%PUBLIC%文件夹,并为其建立持久性。TONEINS恶意软件通常出现在诱饵文件中,在大多数情况下,TONEINS DLL的名称是libcef.DLL。恶意例程通过调用其导出函数cef_api_hash来触发。

TONEINS恶意软件被混淆,可能会减慢恶意软件分析的速度。它的控制流中包含大量垃圾代码,并且有大量无用的XOR指令,似乎暗示这些指令用于解码字符串。经过检查,我们发现这些混淆的代码是从开源存储库中重用的。

23.png

TONEINS中的代码混淆

安装程序通过使用以下schtasks命令建立TONESHELL后门的持久性:

24.png

被释放的TONESHELL恶意软件的文件名大小写不同,计划任务的名称也不同。建立持久性后,TONESHELL将合法的可执行文件和恶意的DLL复制到%PUBLIC%文件夹,其中两个文件的名称在诱饵存档中都以“~”开头。在本示例中,~$220220817.docx是用于DLL侧加载的合法可执行文件,而~$20220617(1).docx是要安装的TONESHELL后门DLL。

25.png

带有虚假文件扩展名的文件

Backdoor.Win32.TONESHELL

TONESHELL恶意软件是本次活动中使用的主要后门。它是一个shellcode加载器,在内存中使用一个32字节的密钥加载和解码后门shellcode。在早期版本的TONESHELL中,它具有来自TONEINS恶意软件的功能,包括建立持久性和安装后门。然而,最新版本的TONESHELL是一个独立的后门,没有任何安装程序功能(例如文件~$Talkpoints.docx)。它也以类似于TONEINS恶意软件的方式被混淆,表明攻击者继续更新武器库以绕过检测。

反分析:进程名称检查

为了确保TONESHELL被正确安装,Backdoor.Win32.TONESHELL首先检查进程路径是否与预期路径匹配。如果是,则自定义异常处理程序可能会触发恶意代码。

26.png

TONESHELL中的进程名称检查

反分析:c++中的自定义异常处理程序

有趣的是,攻击者使用自定义异常处理程序的实现隐藏了实际的代码流。将根据进程名称检查的结果调用不同的异常处理程序,通过调用_CxxThrowException触发异常来继续恶意例程。调用后,C++运行时将从ThrowInfo结构一直到_msRttiDscr结构中的CatchProc成员找到相应的异常处理程序,其中包含真正的恶意代码。在此示例中,异常处理程序位于偏移量0x10005300处。这种技术不仅隐藏了执行流,而且还停止了分析师调试器的执行。

27.png

C++中异常处理的数据工作流;黄色圆圈中的CatchProc成员是要调用的恶意异常处理程序

28.png

异常处理程序中的主要恶意例程

反分析:ForegroundWindow检查

查看最近的TONESHELL示例,我们注意到与早期版本相比,添加了新的反沙盒技术。较新的版本调用GetForegroundWindow API两次并检查是否有任何窗口切换。如果环境是沙盒,两个调用将获得相同的窗口句柄,因为大多数沙盒中不涉及人工交互,导致前台窗口不更改。此外,作为一种反沙盒和延迟执行技术,恶意例程只有在前台窗口已经切换了第五次时才会被触发。

29.png

更新的TONESHELL示例中的GetForegroundWindow检查

30.png

第五个窗口开关触发的恶意例程

Shellcode解码

触发恶意异常处理程序后,它开始解码下一阶段的TONESHELLshellcode。要解码shellcode,它首先在与0x7D的XOR运算中解码一个32字节的密钥,然后该密钥将用于解码shellcode主体。

31.png

解码前(中间)和解码后(底部)32字节密钥(顶部)和TONESHELLshellcode的示例

不断改进的变体

我们发现了TONESHELLshellcode的几种变体:

32.png

TONESHELL变体之间的差异

变体A

TONESHELL在设计上支持多达10个C&C服务器,但在我们F发现的所有示例中,只使用了一个C&C服务器。在连接到C&C服务器之前,它使用受害者的卷序列号和计算机名生成一个受害者ID(变量unique_id),或者使用一个随机生成的GUID。

33.png

查找TONESHELL中支持的10个C&C服务器

34.png

在TONESHELL变体A中用于生成受害者ID的算法

在第一个信标中,它从受害者的设备收集以下数据并将其发送到C&C服务器:

当前进程ID;

卷序列号;

用户名;

计算机名称;

产品名称;

操作系统位;

进程列表;

TONESHELL通过原始TCP进行通信,请求标头和响应标头以特定的神奇字节序列“17 03 03”开头。根据我们的研究,这个神奇的标头被用于所有TONESHELL TCP变体和已识别的PUBLOAD恶意软件。数据包中的有效负载将用RC4算法加密。在此变体中,其请求包格式如下:

35.png

TONESHELL变体A中的请求数据包格式

36.png

TONESHELL中的数据包头检查(所有TCP变体和stager)

后门支持各种功能,包括文件上传、文件下载、文件执行和横向移动。我们还注意到它的内部字符串是自解释的。事实上,这个恶意软件以其命令“TOnePipeShell”中的拼写错误命名为TONESHELL。下表显示了它的所有命令:

37.png

TONESHELL变体A中的命令代码

变体B

TONESHELL变体B与变体A略有不同,其中受害者ID是由tick计数、用户名和计算机名生成的。

38.png

TONESHELL变体B中受害者ID生成的不同算法

后门的协议也不同。数据包中的有效负载用随机32字节密钥编码,每个数据包的密钥都不同。每当发出新请求时,都会生成新密钥。

39.png

TONESHELL变体B中的请求数据包格式

40.png

在TONESHELL变体B中,在发出请求之前,有效载荷将被编码在异或操作中

此变体中的命令代码如下:

41.png

TONESHELL变量B中的命令代码

变体C

研究人员从VirusTotal(SHA256:521662079c1473adb59f2d7134c8c1d76841f2f9b9e6e181aa54df25715a09)中找到了一个转储的TONESHELLshellcode。分析表明,它的工作原理与其他变体相似,但使用的C&C协议是HTTP。这似乎是TONESHELL的早期版本,因为该样本是在2021年9月上传的,并对第一个信标使用POST方法。以下数据是从受害者的计算机收集的:

内存大小;

用户名;

计算机名称;

磁盘大小;

操作系统位;

产品名称;

42.png

TONESHELL变体C中的第一个HTTP信标请求

受害者的ID(由第一个信标中的“Guid”标头指定,随后在“Cookie”标头中使用)也由随机Guid生成。主体也在RC4中加密,命令代码与变体B非常相似,如下所示:

43.png

TONESHELL变体C中的命令代码

研究人员观察到最近几个月来有几个TONESHELL和TONEINS恶意软件样本被上传到VirusTotal目前研究人员已收集了几个Google Drive链接,例如770d5b60d8dc0f32941a6b530c9598df92a7ec76b60309aa8648f9b3a3f3cca5。

44.png

在野外找到的Google Drive链接示例,其中包含TONESHELL和TONEINS

通常,我们将这些下载链接视为首次攻击方式。Google Drive直接下载链接的格式为https[:]//drive.google.com/uc?id=gdrive_file_id&export=download。gdrive_file_id是此特定文件的唯一标识符。通过修改URL:https[:]//drive.google.com/file/d/gdrive_file_id/view,我们可以切换到web查看器以检查其文件内容及其所有者。

在详细信息面板中,我们可以找到此文件的所有者,通过将鼠标悬停在图标上,我们可以获得电子邮件地址。

445.png

Google Drive的web浏览器

46.png

文件所有者的姓名和电子邮件地址

我们可以使用这个特定的电子邮件帐户进行进一步的研究。例如,经过我们的调查,我们知道攻击者滥用了相同的电子邮件地址,将诱饵文件存储在Google Drive中,并发送钓鱼电子邮件。如果我们在监控日志中搜索这个特定的电子邮件地址,我们可能会发现更多分布式恶意软件。

总结

本次活动中观察到的TTP与Secureworks提到的活动类似。两个活动都滥用.lnk文件来触发恶意软件。与Secureworks报告的观察结果相比,趋势科技在此次活动中发现的文件具有相似的文件夹结构。

47.png

BRONZE PRESIDENT(左)和 Earth Preta(右)的文件夹结构类似

Bronze President利用带有回调函数参数的API来调用EnumThreadWindows等shellcode。PUBLOAD恶意软件中也使用了类似的技术。

此外,我们还发现了两个活动之间的联系:一个C&C服务器(98[.]142[.]251[.]29)可以与快捷方式文件关联。此快捷方式文件出现在一个诱骗文件 “EU 31st session of the Commission on Crime Prevention and Criminal Justice United Nations on Drugs and Crime.rar”(SHA256:09fc8bf9e2980ebec1977a8023e8a2940e6ad5004f48d07ad34b71ebf35b877)中,Secureworks报告也提到了这一点。我们使用工具LECmd解析快捷方式文件,在.lnk文件的元数据中找到了特定的C&C字符串,攻击者似乎使用了C&C字符串作为文件夹名。

48.png

 .lnk文件的元数据

(SHA256:a693b9f9ffc5f4900e094b1d1360f7e7b907c9c8680abfeace34e1a8e380f405)

Cisco Talos提到的感染链也与我们最近观察到的相似:

两者都使用schtasks和注册表运行项来实现持久性;

两者都使用良性可执行文件进行DLL侧加载;

最重要的是,报告中提到的stager在C&C通信协议中使用了与TONESHELL相同的标头(17 03 03)。

Earth Preta组织从3月开始就在全球肆虐,其开发的恶意软件家族包括TONEINS、TONESHELL和PUBLOAD。Earth Preta又名Mustang Panda或Bronze President。该组织的攻击对象包括但不限于缅甸、澳大利亚、菲律宾、日本等国家。

趋势科技的研究人员最近发现Earth Preta滥用虚假谷歌账户,通过鱼叉式网络钓鱼电子邮件传播恶意软件,这些电子邮件最初存储在一个存档文件(如rar/zip/jar)中,并通过Google Drive链接传播。然后诱骗用户下载并触发恶意软件执行TONEINS、TONESHELL和PUBLOAD。PUBLOAD之前已被报道,我们会在本文将其与TONEINS和TONESHELL联系起来,后者是该组织在其活动中新使用的恶意软件家族。

此外,攻击者利用不同的技术来逃避检测和分析,如代码混淆和自定义异常处理程序。我们还发现,鱼叉式网络钓鱼邮件的发件人和Google Drive链接的所有者是相同的。根据用于诱骗受害者的样本文件,我们还认为,攻击者能够对目标组织进行研究,并可能事先对其进行破坏,从而使其变得熟悉,这在之前被泄露的账户名称的缩写中有所显示。

在这篇文章中,我们讨论了Earth Preta的活动及其策略、技术和程序(TTP),包括新的安装程序和后门。

受害目标分析

根据我们对这一威胁的监测,诱饵文件是用缅甸文写成的,内容是“仅限内部”。文件中的大多数主题都是国家间有争议的问题,包含“机密”或“机密”等词 ,这可能表明,攻击者将缅甸政府作为他们的第一个立足点。这也可能意味着,攻击者在攻击之前就已经对特定的政治对象进行了破坏,Talos研究人员此前也注意到了这一点。

攻击者利用窃取的文件作为诱饵,诱骗与缅甸政府机构有合作关系的目标组织下载并执行恶意文件。受害者涵盖了世界范围内广泛的组织和垂直领域,其中亚太地区的受害者集中度更高。除了在缅甸开展合作的政府办事处外,随后的受害者还包括教育和研究行业等。除了以涉及特定组织的正在进行的国际事件为诱饵之外,攻击者还用与色情材料有关的标题引诱个人用户下载。

2.png

Earth Preta的目标行业分布

攻击进程

Earth Preta使用鱼叉式网络钓鱼邮件作为攻击的第一步。如前所述,一些邮件的主题和内容讨论地缘政治话题,而其他邮件可能包含耸人听闻的主题。我们观察到,我们分析的所有电子邮件中都嵌入了Google Drive链接,这表明用户可能会被诱骗下载恶意文件。文件类型包括压缩文件,例如.rar、.zip和.jar。访问链接后,我们了解到文件包含恶意软件TONEINS、TONESHELL和PUBLOAD。

4.png

有关会议记录的电子邮件文档,可能是从先前的攻击中窃取的

鱼叉式网络钓鱼电子邮件

通过分析电子邮件的内容,发现Google Drive链接被用来诱骗受害者。电子邮件的主题可能为空,或者可能与恶意文件同名。攻击者没有将受害者的地址添加到电子邮件的“收件人”标题中,而是使用了假电子邮件。同时,真实受害者的地址被写在“CC”标题中,可能会逃避安全分析,延缓调查。使用开源情报(OSINT)工具GHunt来探测“收件人”部分中的那些Gmail地址,我们发现了这些虚假账户,其中几乎没有信息。

此外,我们观察到一些发件人可能是来自特定组织的电子邮件帐户。受害者可能会相信这些邮件是由可信的合作伙伴发送的,这增加了收件人选择恶意链接的机会。

虚假文件

我们还发现了一些与缅甸政府对象相关或与之合作的组织有关的虚假文件。其中包含了缅甸和中国大使馆之间的粗略会面时间表。另一份文件与日本科学促进协会(JSPS)有关,该协会为研究人员提供在日本进行研究交流的机会。值得注意的是,压缩文件附件中主要是图片。用于下一层侧加载的恶意DLL和可执行文件也包含在其中。

5.png

有关政府会议(左)及海外研究交流(右)的虚假文件样本

此外,还有其他内容主题多样的诱饵文件,包括地区事务和色情内容。但是,当受害者打开这个文件夹中的假文档文件时,没有相应的内容出现。

其他攻击途径

我们观察到至少三种类型的攻击途径,包括通过Google Drive链接、Dropbox链接或其他托管文件的IP地址分布在世界各地的30多个诱饵文件。在我们收集的大多数样本中,都有合法的可执行文件,以及侧加载的DLL。诱饵文件的名称在每个案例中都有所不同。在接下来的部分中,我们将以其中一些为例,介绍每一个的TTP。

DLL侧加载

在该示例中,有三个文件:“~”, Increasingly confident US is baiting China.exe和libcef.dll。值得注意的是,诱饵文件和可执行文件的名称可能不同,详细信息将在下一节中介绍。

6.png

诱饵文件

7.png

PUBLOAD文件中的诱饵文件

可以看出“~”文件是一个诱饵文件。Increasingly confident US is baiting China.exe是一个合法的可执行文件(最初名为adobe_licensing_wf_helper.exe,即adobe licensing wf helper)。这个可执行文件将侧载恶意的libeff .dll并触发导出函数cef_api_hash。

首次执行时,可执行文件尝试通过复制.exe文件和移动libcef.dll(趋势科技将其命名为Trojan.W32.PUBLOAD)。

8.png

恶意活动

快捷链接

恶意文件包含三个文件:New Word Document.lnk、putty.exe和CefBrowser.dll。特别是,DLL和可执行文件被放置在名为“_”的多层文件夹中。

9.png

攻击者利用.lnk文件通过使用WinRAR解压缩文件来安装恶意文件。完整的命令行如下所示。

10.png

Pputty.exe伪装成一个正常的可执行文件,其原始文件名为AppXUpdate.exe。当它被执行时,它会加载CefBrowser.dll,并在它的导出函数CCefInterface::SubProcessMain中执行主例程。它还滥用schtask来实现持久性。

10.png

恶意软件

在这次活动中,研究人员识别出使用了以下恶意软件,即PUBLOAD、TONEINS和TONESHELL。

Trojan.Win32.PUBLOAD

PUBLOAD是一个可以从其指挥控制(C&C)服务器下载下一级有效负载的stager。该恶意软件于2022年5月由Cisco Talos首次披露。

一旦.dll被执行,它首先通过调用OpenEventA来检查相同的进程是否已经在运行。根据Barberousse发布的推文,一些值得注意的事件名称被识别为Twitter上其他网络安全研究人员的用户名,如“moto_sato”、“xaacrazyman_armyCIAx”和“JohnHammondTeam”。值得注意的是,这些研究人员与PUBLOAD没有任何关系,只是被二进制文件中的攻击者有意提及。

14.png

PUBLOAD中特殊事件名称的示例

持久性分析

PUBLOAD在

1. 添加注册表运行项

15.png

2. 创建计划任务

16.png

反分析技术:带有回调的API

PUBLOAD恶意软件在内存中的AES算法中解密shellcode。shellcode是通过创建线程或使用不同的API调用的。API可以接受回调函数的参数,作为触发shellcode的替代方法。我们观察到一些利用API的情况,包括GrayStringW、EnumDateFormatsA和LineDDA,可以将其视为绕过反病毒监视和检测的技术。

17.png

PUBLOAD中的shellcode回调示例

18.png

接受回调函数的API

C&C协议

解密的PUBLOAD shell代码收集计算机名和用户名作为第一个信标的有效负载。有效负载将使用预定义的RC4 (Rivest Cipher 4)密钥进行加密。在撰写本文时,到目前为止我们看到的所有阶段都共享相同的密钥。

加密后,stager使用特定的字节序列作为其数据包的标头。它在加密数据之前加上神奇的字节“17 03 03”和有效负载大小。

19.png

PUBLOAD恶意软件中使用的RC4密钥(顶部)和数据包主体(底部)

20.png

PUBLOAD中的请求数据包格式

stager还检查响应包是否具有相同的魔术标头“17 03 03”。在内存中下载的有效负载将被视为一段shellcode,并将直接执行。

值得注意的调试字符串

在2022年初,我们发现了一些嵌入调试字符串的PUBLOAD示例。它们被用来分散分析人员对主要感染程序的注意力。

21.png

PUBLOAD中分散注意力的调试字符串

Trojan.Win32.TONEINS

Trojan.Win32.TONEINS是TONESHELL后门的安装程序。安装程序将TONESHELL恶意软件放入%PUBLIC%文件夹,并为其建立持久性。TONEINS恶意软件通常出现在诱饵文件中,在大多数情况下,TONEINS DLL的名称是libcef.DLL。恶意例程通过调用其导出函数cef_api_hash来触发。

TONEINS恶意软件被混淆,可能会减慢恶意软件分析的速度。它的控制流中包含大量垃圾代码,并且有大量无用的XOR指令,似乎暗示这些指令用于解码字符串。经过检查,我们发现这些混淆的代码是从开源存储库中重用的。

23.png

TONEINS中的代码混淆

安装程序通过使用以下schtasks命令建立TONESHELL后门的持久性:

24.png

被释放的TONESHELL恶意软件的文件名大小写不同,计划任务的名称也不同。建立持久性后,TONESHELL将合法的可执行文件和恶意的DLL复制到%PUBLIC%文件夹,其中两个文件的名称在诱饵存档中都以“~”开头。在本示例中,~$220220817.docx是用于DLL侧加载的合法可执行文件,而~$20220617(1).docx是要安装的TONESHELL后门DLL。

25.png

带有虚假文件扩展名的文件

Backdoor.Win32.TONESHELL

TONESHELL恶意软件是本次活动中使用的主要后门。它是一个shellcode加载器,在内存中使用一个32字节的密钥加载和解码后门shellcode。在早期版本的TONESHELL中,它具有来自TONEINS恶意软件的功能,包括建立持久性和安装后门。然而,最新版本的TONESHELL是一个独立的后门,没有任何安装程序功能(例如文件~$Talkpoints.docx)。它也以类似于TONEINS恶意软件的方式被混淆,表明攻击者继续更新武器库以绕过检测。

反分析:进程名称检查

为了确保TONESHELL被正确安装,Backdoor.Win32.TONESHELL首先检查进程路径是否与预期路径匹配。如果是,则自定义异常处理程序可能会触发恶意代码。

26.png

TONESHELL中的进程名称检查

反分析:c++中的自定义异常处理程序

有趣的是,攻击者使用自定义异常处理程序的实现隐藏了实际的代码流。将根据进程名称检查的结果调用不同的异常处理程序,通过调用_CxxThrowException触发异常来继续恶意例程。调用后,C++运行时将从ThrowInfo结构一直到_msRttiDscr结构中的CatchProc成员找到相应的异常处理程序,其中包含真正的恶意代码。在此示例中,异常处理程序位于偏移量0x10005300处。这种技术不仅隐藏了执行流,而且还停止了分析师调试器的执行。

27.png

C++中异常处理的数据工作流;黄色圆圈中的CatchProc成员是要调用的恶意异常处理程序

28.png

异常处理程序中的主要恶意例程

反分析:ForegroundWindow检查

查看最近的TONESHELL示例,我们注意到与早期版本相比,添加了新的反沙盒技术。较新的版本调用GetForegroundWindow API两次并检查是否有任何窗口切换。如果环境是沙盒,两个调用将获得相同的窗口句柄,因为大多数沙盒中不涉及人工交互,导致前台窗口不更改。此外,作为一种反沙盒和延迟执行技术,恶意例程只有在前台窗口已经切换了第五次时才会被触发。

29.png

更新的TONESHELL示例中的GetForegroundWindow检查

30.png

第五个窗口开关触发的恶意例程

Shellcode解码

触发恶意异常处理程序后,它开始解码下一阶段的TONESHELLshellcode。要解码shellcode,它首先在与0x7D的XOR运算中解码一个32字节的密钥,然后该密钥将用于解码shellcode主体。

31.png

解码前(中间)和解码后(底部)32字节密钥(顶部)和TONESHELLshellcode的示例

不断改进的变体

我们发现了TONESHELLshellcode的几种变体:

32.png

TONESHELL变体之间的差异

变体A

TONESHELL在设计上支持多达10个C&C服务器,但在我们F发现的所有示例中,只使用了一个C&C服务器。在连接到C&C服务器之前,它使用受害者的卷序列号和计算机名生成一个受害者ID(变量unique_id),或者使用一个随机生成的GUID。

33.png

查找TONESHELL中支持的10个C&C服务器

34.png

在TONESHELL变体A中用于生成受害者ID的算法

在第一个信标中,它从受害者的设备收集以下数据并将其发送到C&C服务器:

当前进程ID;

卷序列号;

用户名;

计算机名称;

产品名称;

操作系统位;

进程列表;

TONESHELL通过原始TCP进行通信,请求标头和响应标头以特定的神奇字节序列“17 03 03”开头。根据我们的研究,这个神奇的标头被用于所有TONESHELL TCP变体和已识别的PUBLOAD恶意软件。数据包中的有效负载将用RC4算法加密。在此变体中,其请求包格式如下:

35.png

TONESHELL变体A中的请求数据包格式

36.png

TONESHELL中的数据包头检查(所有TCP变体和stager)

后门支持各种功能,包括文件上传、文件下载、文件执行和横向移动。我们还注意到它的内部字符串是自解释的。事实上,这个恶意软件以其命令“TOnePipeShell”中的拼写错误命名为TONESHELL。下表显示了它的所有命令:

37.png

TONESHELL变体A中的命令代码

变体B

TONESHELL变体B与变体A略有不同,其中受害者ID是由tick计数、用户名和计算机名生成的。

38.png

TONESHELL变体B中受害者ID生成的不同算法

后门的协议也不同。数据包中的有效负载用随机32字节密钥编码,每个数据包的密钥都不同。每当发出新请求时,都会生成新密钥。

39.png

TONESHELL变体B中的请求数据包格式

40.png

在TONESHELL变体B中,在发出请求之前,有效载荷将被编码在异或操作中

此变体中的命令代码如下:

41.png

TONESHELL变量B中的命令代码

变体C

研究人员从VirusTotal(SHA256:521662079c1473adb59f2d7134c8c1d76841f2f9b9e6e181aa54df25715a09)中找到了一个转储的TONESHELLshellcode。分析表明,它的工作原理与其他变体相似,但使用的C&C协议是HTTP。这似乎是TONESHELL的早期版本,因为该样本是在2021年9月上传的,并对第一个信标使用POST方法。以下数据是从受害者的计算机收集的:

内存大小;

用户名;

计算机名称;

磁盘大小;

操作系统位;

产品名称;

42.png

TONESHELL变体C中的第一个HTTP信标请求

受害者的ID(由第一个信标中的“Guid”标头指定,随后在“Cookie”标头中使用)也由随机Guid生成。主体也在RC4中加密,命令代码与变体B非常相似,如下所示:

43.png

TONESHELL变体C中的命令代码

研究人员观察到最近几个月来有几个TONESHELL和TONEINS恶意软件样本被上传到VirusTotal目前研究人员已收集了几个Google Drive链接,例如770d5b60d8dc0f32941a6b530c9598df92a7ec76b60309aa8648f9b3a3f3cca5。

44.png

在野外找到的Google Drive链接示例,其中包含TONESHELL和TONEINS

通常,我们将这些下载链接视为首次攻击方式。Google Drive直接下载链接的格式为https[:]//drive.google.com/uc?id=gdrive_file_id&export=download。gdrive_file_id是此特定文件的唯一标识符。通过修改URL:https[:]//drive.google.com/file/d/gdrive_file_id/view,我们可以切换到web查看器以检查其文件内容及其所有者。

在详细信息面板中,我们可以找到此文件的所有者,通过将鼠标悬停在图标上,我们可以获得电子邮件地址。

445.png

Google Drive的web浏览器

46.png

文件所有者的姓名和电子邮件地址

我们可以使用这个特定的电子邮件帐户进行进一步的研究。例如,经过我们的调查,我们知道攻击者滥用了相同的电子邮件地址,将诱饵文件存储在Google Drive中,并发送钓鱼电子邮件。如果我们在监控日志中搜索这个特定的电子邮件地址,我们可能会发现更多分布式恶意软件。

总结

本次活动中观察到的TTP与Secureworks提到的活动类似。两个活动都滥用.lnk文件来触发恶意软件。与Secureworks报告的观察结果相比,趋势科技在此次活动中发现的文件具有相似的文件夹结构。

47.png

BRONZE PRESIDENT(左)和 Earth Preta(右)的文件夹结构类似

Bronze President利用带有回调函数参数的API来调用EnumThreadWindows等shellcode。PUBLOAD恶意软件中也使用了类似的技术。

此外,我们还发现了两个活动之间的联系:一个C&C服务器(98[.]142[.]251[.]29)可以与快捷方式文件关联。此快捷方式文件出现在一个诱骗文件 “EU 31st session of the Commission on Crime Prevention and Criminal Justice United Nations on Drugs and Crime.rar”(SHA256:09fc8bf9e2980ebec1977a8023e8a2940e6ad5004f48d07ad34b71ebf35b877)中,Secureworks报告也提到了这一点。我们使用工具LECmd解析快捷方式文件,在.lnk文件的元数据中找到了特定的C&C字符串,攻击者似乎使用了C&C字符串作为文件夹名。

48.png

 .lnk文件的元数据

(SHA256:a693b9f9ffc5f4900e094b1d1360f7e7b907c9c8680abfeace34e1a8e380f405)

Cisco Talos提到的感染链也与我们最近观察到的相似:

两者都使用schtasks和注册表运行项来实现持久性;

两者都使用良性可执行文件进行DLL侧加载;

最重要的是,报告中提到的stager在C&C通信协议中使用了与TONESHELL相同的标头(17 03 03)。