在探索“SilverPotato”滥用的DCOM对象时，我偶然发现了“ShellWindows” DCOM应用程序。这个应用程序与“ShellBrowserWindows”一起，在攻击安全社区中以使用具有管理员权限的远程实例化这些对象来执行横向移动而闻名。
然而，我很好奇是否标准用户可以在本地滥用它们。
DCOM 应用程序“ShellWindows”（应用程序 ID 为 {9BA05972-F6A8-11CF-A442-00A0C90A8F39}）被配置为在“Interactive”用户的身份下运行：
此应用程序上设置的权限是默认权限，这意味着交互用户至少可以在本地启动和激活 DCOM 应用程序：
让我们来看看 DCOM 应用程序是如何配置的，多亏了类型库，我们可以获得许多有用的信息：
该类由 explorer.exe 注册，激活器将使用这个类。暴露了几种方法：
ShellExecute() 是我们正在寻找的内容，因为它允许执行外部命令或应用程序。
现在，借助 Oleview 工具，让我们看看 explorer.exe 进程中的访问安全性是什么：
看起来很有前途，经过身份验证的用户具有执行权限（!!!???）
所以，简单回顾一下，我们有这个 DCOM 应用程序模拟交互用户。它由资源管理器进程托管，为经过身份验证的用户授予执行访问权限。
现在，如果我们可以执行跨会话激活，一个非特权用户可以代表另一个连接在不同会话中的用户激活对象，并调用 **ShellExecute()** 方法执行任意操作？
让我们在 PowerShell 中快速粗糙地完成这个 😉
我们是_user1_，在会话2中连接了一个_管理员_。我们可以使用_BindToMoniker()_调用在会话2中激活DCOM对象并执行_ShellExecute()_方法。例如，从管理员那里获取一个反向shell：
成功了！🙂
$obj = [System.Runtime.InteropServices.Marshal]::BindToMoniker("session:2!new:9BA05972-F6A8-11CF-A442-00A0C90A8F39")
$p=$obj.item(0).document.application
$p.ShellExecute("c:\temp\reverse.bat", "", "c:\windows", $null, 0)
现在来了有趣的部分：我尝试在另一个没有管理员权限的用户身上使用这种方法……猜猜发生了什么？
拒绝访问！这真的很奇怪，但快速检查访问安全性就能解释为什么我们被拒绝访问：
在这种情况下，资源管理器进程上的经过身份验证的用户权限丢失。如果进程以中间完整性级别运行，这是用户的标准行为 - 即使是管理员组的成员，因为启用了UAC - 他们也将缺少对该组的权限。
然而，真正的管理员在 UAC 禁用时，所有进程都在高完整性级别（High IL）下运行，在这种情况下，这些权限已设置！
这显然是一个bug。问题是，这个问题存在多久了？难道之前没有人发现过吗？也许是因为高IL的限制？
难说……
在 explorer.exe 中还有其他已注册的类，可能会被滥用：
我玩了一下 桌面壁纸，成功地更改了管理员的桌面背景图片 🙂
该案件显然已提交给MSRC，并且安全漏洞已在2024年7月的补丁星期二中修复，标记为重要的LPE，CVE-2024-38100。
现在在 explorer.exe 进程上也应用了正确的设置，且在高 IL 中生效。
就这样 😉