Windows访问令牌窃取攻防技术研究

阅读量    92207 |   稿费 200

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

0x00 前言

在本文中,我们介绍了访问令牌窃取的相关概念,以及如何在winlogon.exe上利用该技术从管理员上下文中模拟SYSTEM访问令牌。MITRE ATT&CK将该技术归为Access Token Manipulation(访问令牌操控)类别。

如果本地管理员账户因为某些组策略(Group Policy)设置无法获取某些权限,此时模仿SYSTEM访问令牌是非常有用的一种技术。比如,本地管理员组可能不具备SeDebugPrivilege权限,这样就能加大攻击者转储凭据或者与其他进程内存交互的难度。然而,管理人员无法从SYSTEM账户中撤销相关权限,因为这是操作系统正常运行的基础。因此,在加固环境中,SYSTEM访问令牌对攻击者而言具有非常高的价值。

了解操控访问令牌的概念后,我将介绍如何使用系统访问控制列表(SACL)来审计进程对象,以便检测恶意操控访问令牌的攻击行为。这种检测技术有一个缺点:防御方必须清楚哪些进程是攻击者的目标。

最后,本文探索了还有哪些SYSTEM进程可以替代winlogon.exe,用来实施访问令牌模拟攻击,我也介绍了寻找这些进程的方法以及相关知识点。

 

0x01 窃取访问令牌

备注:如果大家对访问令牌控制技术比较了解,想深入了解如何寻找其他可用的SYSTEM进程,那么可以直接跳过这一节。

我们可以使用如下Windows API来窃取并滥用访问令牌:OpenProcess()OpenProcessToken()ImpersonateLoggedOnUser()DuplicateTokenEx()以及CreateProcessWithTokenW()

图. 使用Windows API窃取访问令牌

OpenProcess()以进程标识符(PID)为参数,返回一个进程句柄,打开句柄时必须使用PROCESS_QUERY_INFORMATIONPROCESS_QUERY_LIMITED_INFORMATION或者PROCESS_ALL_ACCESS访问权限,这样OpenProcessToken()才能使用返回的进程句柄。

图. OpenProcess文档

OpenProcessToken()以进程句柄及访问权限标志作为参数,用来打开访问令牌所关联进程的句柄。我们必须使用TOKEN_QUERY以及TOKEN_DUPLICATE访问权限打开令牌句柄,才能与ImpersonateLoggedOnUser()配合使用。我们也可以只使用TOKEN_DUPLICATE访问权限打开令牌句柄,与DuplicateTokenEx()配合使用。

图. OpenProcessToken文档

利用OpenProcessToken()获取令牌句柄后,我们可以使用ImpersonatedLoggedOnUser(),使当前进程可以模拟已登录的另一个用户。该进程会继续模拟已登录的该用户,直到线程退出或者我们显示调用RevertToSelf()

图. ImpersonateLoggedOnUser文档

如果想以另一个用户身份运行进程,我们必须在OpenProcessToken()返回的令牌句柄上使用DuplicateTokenEx(),创建新的访问令牌。我们必须使用TOKEN_ADJUST_DEFAULTTOKEN_ADJUST_SESSIONIDTOKEN_QUERYTOKEN_DUPLICATE以及TOKEN_ASSIGN_PRIMARY访问权限来调用DuplicateTokenEx(),才能与CreateProcessWithTokenW()配合使用。DuplicateTokenEx()创建的访问令牌可以传入CreateProcessWithTokenW(),通过复制的令牌运行目标进程。

图. DuplicateTokenEx文档

图. CreateProcessWithTokenW文档

我整理了一些代码演示令牌操作过程,大部分代码借鉴了@kondencuotas发表过的一篇文章

大家可以访问此处下载我的测试代码。

 

0x02 利用winlogon.exe提升至SYSTEM权限

在今年早些时候,Nick Landers介绍了从本地管理员提升到NT AUTHORITY\SYSTEM的一种简单方法

 

在本地管理员(高完整性,high-integrity)上下文中,我们可以从winlogon.exe中窃取访问令牌,在当前线程中模拟SYSTEM,或者以SYSTEM运行新的进程。

图. 从winlogon.exe中窃取SYSTEM令牌

 

0x03 检测技术

根据官方描述

访问控制列表(ACL)是包含访问控制项(ACE)的一个列表。ACL中的每个ACE都标识了一个trustee结构,指定与trustee对应的访问权限(允许、拒绝或者审核)。可保护对象安全描述符可以包含两种类型的ACL:DACL以及SACL。

我们的检测技术基于SACL(系统访问控制列表)构建。我们可以在进程对象上设置SACL,在Windows Security Log中记录成功/失败的访问操作。

我们可以使用James Forshaw开发的NtObjectManager来轻松完成这个任务。在下文中,我们大量借鉴了James Forshaw的研究成果,文中提到了如何绕过对LSASS的SACL审计。在这篇文章的帮助下,我深入理解了SACL,也了解了如何使用NtObjectManager来控制SACL。

auditpol /set /category:"Object Access" /success:enable /failure:enable
$p = Get-NtProcess -name winlogon.exe -Access GenericAll,AccessSystemSecurity
Set-NtSecurityDescriptor $p “S:(AU;SAFA;0x1400;;;WD)” Sacl

来逐行分析上述代码。第一行启用系统审核功能,记录成功以及失败的对象访问操作。第二行以GenericAllAccessSystemSecurity访问权限获得winlogon.exe进程的句柄。我们需要AccessSystemSecurity权限才能访问SACL。

第三行应用ACE类型(AU)审核策略,为来自EveryoneWD)组的成功/失败(SAFA)访问生成安全事件。这里需要注意0x1400,这是对0x400PROCESS_QUERY_INFORMATION)以及0x1000PROCESS_QUERY_LIMITED_INFORMATION)进行按位取或(OR)后的结果。这些访问权限(以及PROCESS_ALL_ACCESS)可以用来从指定进程对象中获取访问令牌。

部署完SACL后,当使用特定访问权限访问winlogon.exe时我们应该能看到一些警告信息。

场景1:PROCESS_QUERY_INFORMATION

运行测试程序后,可以看到系统会生成EID(Event ID)4656,其中包括所请求的进程对象、发起访问请求的进程以及所请求的权限。“Access Mask”之所以为0x1400,是因为具备PROCESS_QUERY_INFORMATION访问权限的句柄也会被自动授予PROCESS_QUERY_LIMITED_INFORMATION访问权限。

场景2:PROCESS_QUERY_LIMITED_INFORMATION

我重新编译了测试程序,只请求PROCESS_QUERY_LIMITED_INFORMATION权限,然后重新运行程序。这次我们可以看到EID 4656事件,其中访问权限为0x1000,代表PROCESS_QUERY_LIMITED_INFORMATION访问权限。

 

此外,我们还可以看到EID 4663,表示我们的测试程序在请求句柄后,会尝试访问进程对象。因此,我们能通过搜索EID 4656以及EID 4663,以较高的准确率检测利用访问令牌的操作。

场景3:PROCESS_ALL_ACCESS

重新编译测试程序,使用PROCESS_ALL_ACCESS访问权限后,我们能看到与场景2相同的EID,其中在EID 4656中,可以看到有程序在请求其他访问权限。

这里值得注意的是,EID 4663中的“Access Mask”为0x1000,这代表PROCESS_QUERY_LIMITED_INFORMATION访问权限。此外,当我们使用PROCESS_QUERY_INFORMATION访问权限运行测试程序时,系统会生成EID 4656,但不会生成EID 4663.

 

0x04 寻找其他进程

除了winlogon.exe之外,我比较好奇是否有其他SYSTEM进程能够作为令牌窃取的目标。如果存在这种进程,那它们与无法被窃取令牌的其他SYSTEM进程相比有什么不同?

验证猜想

首先,我想看一下是否有其他进程可以用来窃取SYSTEM令牌。我以运行在高完整性上下文的本地管理员身份暴力枚举了所有SYSTEM进程(包括svchost.exe),找到了能够窃取SYSTEM令牌的其他一些进程。这些进程为lsass.exeOfficeClickToRun.exedllhost.exe以及unsecapp.exe。我将这些进程标识为“友好型”进程。

图. 从unsecapp.exe中窃取SYSTEM令牌

在遍历SYSTEM进程的过程中,我注意到对有些进程执行OpenProcess()操作时会返回拒绝访问错误(“System Error – Code 5”),导致后续执行失败。

对于某些SYSTEM进程,OpenProcess()会执行成功,但执行OpenProcessToken()时会出现拒绝访问错误。后面我将研究一下为什么会出现这种问题。

澄清原因

我的目标是找到允许令牌操作的SYSTEM进程在安全设置上存在哪些不同,我决定比较一下winlogon.exe以及spoolsv.exe。这两个进程都是SYSTEM进程,但我只能从winlogon.exe中窃取SYSTEM访问令牌。

Session ID

我使用Process Explorer打开这两个进程,尝试手动探索这两者之间的不同点。我记得Nick在推特中提到过winlogon.exe的“Session ID”为1,这是最大的不同。

我将该进程与其他“友好型”进程作比较,发现其他进程的Session ID都为0。不幸的是,这并不是我想寻找的不同点。

图. 比较两个“友好型”进程的Session ID

Process Explorer中的高级安全设置

我决定深入分析winlogon.exe以及spoolsv.exe在高级安全设置(Advanced Security Settings)上的区别。我注意到这两者在管理员组的高级权限上有所不同。对于winlogon.exe,管理员组具备“Terminate”、“Read Memory”以及“Read Permissions”权限,而spoolsv.exe上的管理员组并不具备这些权限。

我试着在spoolsv.exe上应用所有权限,然后尝试窃取访问令牌。不幸的是,这种方法并不能弹出SYSTEM命令行窗口。

我试着再次启动/停止进程,想看一下进程启动时能否应用这些权限,同样以失败告终。

Get-ACL

我决定在PowerShell中使用Get-ACL来观察winlogon.exe以及spoolsv.exe所对应的安全描述符。

图. winlogon.exespoolsv.exe对应的Get-ACL结果

这两个进程对应的OwnerGroup以及Access似乎完全相同。接下来我决定使用ConvertFrom-SddlString来解析SDDL(Security Descriptor Definition Language,安全描述符定义语言),来分析其中的不同点。

图. winlogon.exespoolsv.exe对应的SDDL

BUILTIN\Administrators组对应的DiscretionaryAcl似乎相同。这里我有点无计可施,但还是想最后看一下Process Explorer。

TokenUser以及TokenOwner

再次在Process Explorer中观察高级安全设置,我发现所有“友好型”进程的Owner字段对应的都是本地管理员组。

图. winlogon.exeunsecapp.exe对应的TokenOwner字段

我将这个字段与无法窃取访问令牌的其他SYSTEM进程作比较,我发现Owner的确是一个不同的因素。

图. spoolsv.exesvchost.exeTokenOwner字段

我的小伙伴(@jaredcatkinson)还提到一点,Process Explorer中的Owner字段实际上对应的是TokenOwner,并且我们可以使用GetTokenInformation()来提取该信息。

我还在GitHub上找到一个非常方便的PowerShell脚本(Get-Token.ps1),可以用来枚举所有进程以及线程令牌。

图. 利用Get-Token.ps1解析出来的winlogon.exe所对应的令牌对象

观察winlogon.exe,我们可以看到UserName以及OwnerName字段的值有所不同。分析该脚本的具体实现,我发现这些字段对应的是TOKEN_USER 以及 TOKEN_OWNER 结构。

TOKEN_USER结构标识与访问令牌相关的用户,TOKEN_OWNER标识利用该访问令牌创建的进程的所有者。这似乎是允许我们从某些SYSTEM进程中窃取访问令牌的主要不同点。

前面提到过,对于某些SYSTEM进程,OpenProcess()可以执行成功,但OpenProcessToken()会返回拒绝访问错误。现在我可以回答这个问题,这是因为我并不是这些进程的TOKEN_OWNER

如下一行代码可以用来解析Get-Token的输出,寻找UserNameSYSTEM,但OwnerName不为SYSTEM的对象。然后抓取每个对象的ProcessNameProcessID信息。

Get-Token | Where-Object {$_.UserName -eq ‘NT AUTHORITYSYSTEM’ -and $_.OwnerName -ne ‘NT AUTHORITY\SYSTEM’} | Select-Object ProcessName,ProcessID | Format-Table

非常棒,我们应该能够从这些SYSTEM进程中窃取访问令牌,模拟SYSTEM访问令牌。接下来让我们验证一下这个猜想。

我手动遍历了这个PID列表,发现大多数进程的确能够用于控制访问令牌,然而还是存在一些例外进程。

图. 对wininit.execsrss.exe执行OpenProcess()时会返回拒绝访问错误

Protected Process Light

前面提到过,某些SYSTEM进程在我调用OpenProcess()时,会返回拒绝访问错误,无法窃取令牌。我使用Process Explorer观察这些进程,发现了可能解释该行为的一个共同属性:PsProtectedSignerWinTcb-Light

仔细阅读Alex Ionescu发表的一篇研究文章以及StackOverflow上的一篇文章,我了解到这个Protected属性与PPL(Protected Process Light)有关。

如果指定的访问权限为PROCESS_QUERY_LIMITED_INFORMATION,那么PPL只允许我们在该进程上调用OpenProcess()。我们的测试程序需要以PROCESS_QUERY_INFORMATION访问权限来调用OpenProcess(),以便返回的句柄能够与OpenProcessToken()配合使用,因此这样就会出现“System Error — Code 5”(拒绝访问)错误。

在测试检测机制时,我了解到OpenProcessToken()所需的最小访问权限为PROCESS_QUERY_LIMITED_INFORMATION,这与微软提供的官方描述有所不同。我修改了调用OpenProcess()期间所需的访问权限,最终成功拿到了SYSTEM级别的命令提示符。

 

0x05 测试结果

当我们使用PROCESS_QUERY_INFORMATION访问权限对某些SYSTEM进程调用OpenProcess()时,我们可以成功窃取这些进程的访问令牌。这些进程包括:

dllhost.exe
lsass.exe
OfficeClickToRun.exe
svchost.exe(只适用于某些PID)
Sysmon64.exe
unsecapp.exe
VGAuthService.exe
vmacthlp.exe
vmtoolsd.exe
winlogon.exe

对于受PPL保护的某些SYSTEM进程,如果我们以PROCESS_QUERY_LIMITED_INFORMATION访问权限调用OpenProcess(),还是能够窃取访问令牌,这些进程包括:

csrss.exe
Memory Compression.exe
services.exe
smss.exe
wininit.exe

其中有些进程可能与我的Windows开发环境有关,我建议大家在自己的环境中进行测试。

 

0x06 总结

稍微总结一下,我们可以从winlogon.exe中窃取访问令牌,模拟SYSTEM上下文。在本文中,我深入介绍了如何利用SACL以及Windows安全日志来检测对访问令牌的操作行为。

我也尝试寻找与winlogon.exe包含相似属性的其他SYSTEM进程,本文重点介绍了寻找这些进程的方法,最终找到了能够窃取访问令牌的其他SYSTEM进程。此外,我还深入研究了为什么某些进程能够用于操控访问令牌,而有些令牌无法完成该任务的具体原因。

为了从SYSTEM进程中窃取访问令牌,该进程必须满足如下条件:

  • 如果想在某个进程上调用OpenProcessToken(),那么BUILTIN\Administrator必须为TokenOwner
  • 如果SYSTEM进程受PPL(Protected Process Light)保护,那么我们必须使用PROCESS_QUERY_LIMITED_INFORMATION访问权限来调用OpenProcess()

希望大家能从本文中了解关于Windows API、SACL、Windows进程、Windows令牌以及控制访问令牌的一些知识

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多