TL;DR (really?): Members of Distributed COM Users or Performance Log Users Groups can trigger from remote and relay the authentication of users connected on the target server, including Domain Controllers. #SilverPotato
TL;DR（真的吗？）：分布式 COM 用户或性能日志用户组的成员可以从远程触发并中继目标服务器上连接的用户（包括域控制器）的身份验证。#SILVERPOTATO
Remember my previous article? My insatiable curiosity led me to explore the default DCOM permissions on Domain Controllers during a quiet evening…
还记得我之前的文章吗？我永不满足的好奇心促使我在一个安静的夜晚探索域控制器上的默认 DCOM 权限……
Using some custom Powershell scripts, I produced an Excel sheet with all the information I needed.
使用一些自定义 Powershell 脚本，我生成了一个包含我需要的所有信息的 Excel 工作表。
You can’t imagine the shock I felt when I discovered these two Application Id’s
你无法想象当我发现这两个应用程序 ID 时我所感受到的震惊
The first one, sppui with ID: {0868DC9B-D9A2-4f64-9362-133CEA201299}, seemed very interesting because it was impersonating the Interactive user. Combined with the permissions granted to Everyone for activating this application from remote, this could potentially lead to some unexpected privilege escalation, don’t you think?
第一个是 ID：{0868DC9B-D9A2-4f64-9362-133CEA201299} 的 sppui，看起来非常有趣，因为它模拟了交互式用户。结合授予每个人从远程激活此应用程序的权限，这可能会导致一些意外的权限提升，您不觉得吗？
The output of the DCOMCNFG tool confirmed my analysis:
DCOMCNFG 工具的输出证实了我的分析：
But wait, this does not mean Everyone can activate this DCOM Application remotely. We have to look also at the default limits for Everyone:
但是等等，这并不意味着每个人都可以远程激活此DCOM应用程序。我们还必须查看每个人的默认限制：
Everyone can only activate and launch locally… but… there are these two interesting groups, Distributed COM Users and Performance Log Users who can launch and activate the application remotely:
每个人都只能在本地激活和启动……但。。。有两个有趣的组，分布式 COM 用户和性能日志用户，他们可以远程启动和激活应用程序：
Combined with Everyone’s permission this sounds really interesting! But before going further, what is this application sspui?
结合每个人的许可，这听起来非常有趣！但在进一步讨论之前，这个应用程序 sspui 是什么？
With the magic Oleview tool, we can get much more information:
使用神奇的 Oleview 工具，我们可以获得更多信息：
This app has the following CLSID F87B28F1-DA9A-4F35-8EC0-800EFCF26B83 – SPPUIObjectInteractive Class, and runs as a Local Server :
此应用程序具有以下 CLSID F87B28F1-DA9A-4F35-8EC0-800EFCF26B83 – SPPUIObjectInteractive 类，并作为本地服务器运行：
slui.exe is related to the License Activation Service and exposes some interfaces:
slui.exe与许可证激活服务相关，并公开了一些接口：
At first glance, the methods implemented seem not very interesting from an Attacker perspective.
乍一看，从攻击者的角度来看，实现的方法似乎不是很有趣。
However, we have this DCOM object running in the context of the interactive user, accessible remotely by members of these two groups. So, why not attempt coercing authentication using our *potato exploit? If successful, we could intercept the authentication of the user connected to the Domain Controller, who should theoretically be a Domain Admin, correct 
?
但是，我们在交互式用户的上下文中运行此 DCOM 对象，这两个组的成员可以远程访问。那么，为什么不尝试使用我们的 *potato 漏洞进行强制身份验证呢？如果成功，我们可以拦截连接到域控制器的用户的身份验证，理论上应该是域管理员，对吗 ？
This is very similar to what I did in ADCCoercePotato, except for the fact that we may need to implement also the cross-session activation if we want to specify a specific session ID where the user is logged in.
这与我在 ADCCoercePotato 中所做的非常相似，除了如果我们想指定用户登录的特定会话 ID，我们可能还需要实现跨会话激活。
I won’t go too much into the details; @splinter_code and I have discussed this argument so many times 
我不会过多地介绍细节;@splinter_code和我已经讨论过很多次 这个论点
The key point is that there are two authentication processes: the first occurs during the oxid resolve call, while the second takes place when the victim attempts to contact the malicious endpoint.
关键点是有两个身份验证过程：第一个发生在 oxid resolve 调用期间，而第二个发生在受害者尝试联系恶意端点时。
First AUTH 首次身份验证
I obviously tried the first one, and without too much effort, was able to trigger and intercept the NTLM authentication of a Domain Admin connected to the target Domain Controller.
我显然尝试了第一个，并且没有付出太多努力，就能够触发和拦截连接到目标域控制器的域管理员的 NTLM 身份验证。
For testing purposes, I impersonated my user “simple”, a regular domain user and member of the “Performance Log Users” domain group:
出于测试目的，我模拟了我的用户“simple”，一个普通的域用户和“性能日志用户”域组的成员：
I used my new “SilverPotato” tool, a modified version of ADCSCoercePotato:
我使用了我的新“SilverPotato”工具，这是ADCSCoercePotato的修改版本：
In this case, with -m, I specified the IP address of the target domain controller, and with -k, the IP of the Linux box where the socat redirector and ntlmrelayx were running:
在本例中，我用 -m 指定了目标域控制器的 IP 地址，用 -k 指定了运行 socat 重定向器和 ntlmrelayx 的 Linux 机器的 IP：
And yes, it worked! I got the authentication of Administrator connected on the first session (I did not specify the session ID).
是的，它奏效了！我在第一个会话上连接了管理员的身份验证（我没有指定会话 ID）。
I decided to relay the authentication to the SMB service of the ADCS server (but it’s just an example…), which by default has no signing enabled, and dumped the local SAM database:
我决定将身份验证中继到 ADCS 服务器的 SMB 服务（但这只是一个示例…），默认情况下未启用签名，并转储了本地 SAM 数据库：
With the NT hash of the local Administrator, I could access the ADCS Server via Pass The Hash, backup the Private/Public key of the CA, and the get CRL configuration.
使用本地管理员的 NT 哈希，我可以通过传递哈希访问 ADCS 服务器，备份 CA 的私钥/公钥，并获取 CRL 配置。
Side note: Of course, there are other methods to achieve remote code execution on the target server. For instance, I utilized ntlmrelay to copy my malicious wbemcomn.dll file with a reverse shell into the c:\windows\system32\wbem directory. This file was subsequently loaded under different conditions, granting me a shell with SYSTEM, Network Service, or logged-in User privileges
旁注：当然，还有其他方法可以在目标服务器上实现远程代码执行。例如，我利用 ntlmrelay 将带有反向 shell 的恶意 wbemcomn.dll 文件复制到 c：\windows\system32\wbem 目录中。此文件随后在不同的条件下加载，授予我一个具有 SYSTEM、Network Service 或登录用户权限的 shell
After this, with ForgeCert tool, I was able to request a certificate on behalf Domain Administrator with the backup file of the CA.
在此之后，使用 ForgeCert 工具，我能够代表域管理员使用 CA 的备份文件请求证书。
Finally, request a TGT with Rubeus and logon to the Domain Controller as Administrator
最后，向 Rubeus 请求 TGT 并以管理员身份登录域控制器
second auth 第二次身份验证
Afterward, I attempted to exploit the second authentication, which is more or less what we implemented in our RemotePotato0.
之后，我尝试利用第二个身份验证，这或多或少是我们在 RemotePotato0 中实现的。
However, to my surprise, the resulting impersonation level in this case was limited to Identify, which is useless against SMB or HTTP, and unusable against LDAP/LDAPS because of the sign flag… 
然而，令我惊讶的是，在这种情况下，生成的模拟级别仅限于 Identify，它对 SMB 或 HTTP 毫无用处，并且由于符号标志而对 LDAP/LDAPS 不可用……
Otherwise, it could have presented a great opportunity to use Kerberos relay instead of NTLM, given that the Service Principal Name (SPN) was within the attacker’s control.
否则，它可能会提供使用 Kerberos 中继而不是 NTLM 的绝佳机会，因为服务主体名称 （SPN） 在攻击者的控制范围内。
kerberos relay in first auth?
KERBEROS 中继在第一次身份验证中？
In theory, you could specify the Service Principal Name (SPN) in the first call in the security bindings strings of the “dualstring” array of the Marshalled Interface Pointer:
从理论上讲，可以在第一次调用中指定服务主体名称 （SPN） 在封送接口指针的“dualstring”数组的安全绑定字符串中：
typedef struct tagSECURITYBINDING
{
unsigned short wAuthnSvc; // Must not be 0
unsigned short wAuthzSvc; // Must not be 0
unsigned short aPrincName; // NULL terminated
} SECURITYBINDINGI specified the SPN with the -y switch:
我用 -y 开关指定了 SPN：
But my tests were unsuccessful, I always got back the SPN: RPCSS/IP in the NTLM3 message:
但是我的测试不成功，我总是在 NTLM3 消息中返回 SPN：RPCSS/IP：
A few days ago, James Forshaw pointed out to me the potential for Kerberos relay via OXID resolving, by exploiting the marshaled target info trick detailed in his post under the “Marshaled Target Information SPN” section.
几天前，James Forshaw 向我指出了通过 OXID 解析实现 Kerberos 中继的潜力，它利用了他在“封送目标信息 SPN”部分下的帖子中详述的封送目标信息技巧。
I attempted some tests but quickly gave up, using the excuse that I’m just too lazy .. so I’ll leave it up to you!
我尝试了一些测试，但很快就放弃了，借口是我太懒了 ......所以我就交给你了！
conclusion 结论
At this point, I know I have to answer the fateful question: Did you report this to MSRC?
在这一点上，我知道我必须回答一个决定性的问题：你有没有向MSRC报告这件事？
Obviously, yes! I’ll spare you the disclosure timeline. In short, MSRC confirmed the vulnerability and initially marked it as a critical fix. However, about a month later, they downgraded it to moderate severity. Their final verdict was: After careful investigation, this case has been assessed as moderate severity and does not meet MSRC’s bar for immediate servicing.
显然，是的！我就不赘述了。简而言之，MSRC确认了该漏洞，并最初将其标记为关键修复程序。然而，大约一个月后，他们将其降级为中等严重程度。他们的最终结论是：经过仔细调查，此案被评估为中等严重程度，不符合MSRC的立即服务标准。
So, I feel free to publish this finding
所以，我随时发表这个发现
I’m not going to release the source code for now, but crafting your own should be a breeze, wouldn’t you agree?
我现在不打算发布源代码，但制作自己的源代码应该是一件轻而易举的事，你不同意吗？
This “vulnerability” has been probably around for years, and it’s surprising that nobody has made it public.
这个“漏洞”可能已经存在多年了，令人惊讶的是，没有人将其公开。
So how dangerous is it?
那么它有多危险呢？
Hard to say, especially since membership in groups like “Distributed COM Users” and “Performance Log Users” isn’t exactly commonplace, especially domain-wide. Also, the “Distributed COM Users” group is sometimes considered a tier 0 asset
很难说，特别是因为“分布式 COM 用户”和“性能日志用户”等组的成员身份并不常见，尤其是在域范围内。此外，“分布式 COM 用户”组有时被视为第 0 层资产
But think about it: the ability to coerce and relay the (NTLM) authentication of highly privileged accounts from remote, is incredibly risky. It’s another valid reason to include privileged accounts in the Protected Users group!
但想想看：从远程强制和中继高特权帐户的 （NTLM） 身份验证的能力是非常危险的。这是在“受保护的用户”组中包含特权帐户的另一个正当理由！
Another point to consider is that this method applies to the local “Distributed COM Users” and “Performance Log Users” groups too. So, it really depends on who is logged into the server at the time…
要考虑的另一点是，此方法也适用于本地“分布式 COM 用户”和“性能日志用户”组。所以，这真的取决于当时谁登录了服务器......
I would recommend carefully reviewing the memberships of these and until MS won’t fix this vulnerability, definitely consider these groups tier 0!
我建议仔细检查这些组的成员资格，直到 MS 无法修复此漏洞，请务必考虑这些组的第 0 层！
What’s next after SilverPotato? Well, there’s another interesting one, but this was classified as an Important Privilege Escalation so I have to wait for the fix…
SilverPotato之后的下一步是什么？好吧，还有另一个有趣的，但这被归类为重要权限升级，所以我必须等待修复......
Last but not least, as usual, thanks to James Forshaw @tiraniddo and Antonio Cocomazzi @splinter_code for their precious help.
最后但并非最不重要的一点是，像往常一样，感谢 James Forshaw @tiraniddo 和 Antonio Cocomazzi @splinter_code 的宝贵帮助。
That’s all 就这样
