PPL

随着凭证导出被攻击者的滥用，微软也开发出了相应的防御措施，例如 PPL。对于 IT 管理员，PPL 非常容易部署，是一个 quick-win。虽然 PPL 是可以被绕过的，但还是给导出凭证的操作增添了额外的难度。我们之前说过，Windows 有 4 种完整度等级，而 PPL，则是更高级的，这意味着即便是 SYSTEM 权限也无法访问被 PPL 保护的进程，而 lsass 支持 PPL保护。我们可以在注册表的如下位置添加 RunAsPPL 从而启用 PPL。

对于启用了 PPL 的主机 SRV01，无论是用 nanodump 还是 mimikatz 或其他类似工具，我们都无法正常导出 lsass 进程。nanodump 的报错告诉我们，无法获得对 lsass.exe 进程的句柄，即便我们已经是 SYSTEM 特权了。

PID 748 正是 lsass.exe

那么，我们可以怎么绕过 PPL 的限制呢？具备管理员权限后，我们当然可以删除 RunAsPPL 的注册表然后重启，但这样对于提取 lsass.exe 中的凭证也无意义可言了。既然 PPL 是驱动级的，那么我们自然可以通过加载签名的驱动来反制。但是，编写这样的驱动并为其签名，并不是一个门槛很低的选项。因此，我们可以去加载存在任意代码执行的脆弱驱动，例如 RTCore64.sys。该驱动存在 CVE-2019-16098 的漏洞，因为允许用户读写任意内存、IO端口等，因此会导致高特权下的代码执行，进而可被用于绕过微软的驱动签名 (默认情况下只允许加载签名的驱动) 策略部署恶意代码。

类似的驱动还有 PROCEXP152.SYS

因此，我们可以通过加载这些脆弱的且具有签名的驱动，实现内核级的代码执行而绕过 PPL。PPLControl (https://github.com/itm4n/PPLcontrol) 正是利用了脆弱的驱动从而实现 PPL 的绕过。我们需要得到 RTCore64.sys 这个驱动文件，以及编译后的 PPLcontrol.exe。

一并上传到 Srv01 上，加载驱动并运行：

sc.exe create RTCore64 type= kernel start= auto binPath= C:\windows\tasks\RTCore64.sys DisplayName= "control"
net start RTCore64

列举受保护的进程，我们发现本地安全机构也在其中。

记录下其 PID，然后将 PPL 保护给脱离。

这样，我们就能导出 lsass.exe 中的凭证了。

恢复 LSA 的 PPL 保护，这样我们再次不能从 lsass.exe 中导出凭证了。

实际上，我们甚至可以从用户态绕过 PPL。PPLDump (https://github.com/itm4n/PPLdump) 就是这么一个工具。它利用了一个技巧，使得系统创建一个新的任意的已知 DLL。PPL 并不检查已知 DLL 的数字签名，因此从而进行了 DLL 劫持攻击并在 PPL 中实现代码执行。该工具随着去年的一次更新补丁而失效，但遇到不那么新的系统是可以尝试的。PPLmedic (https://github.com/itm4n/PPLmedic) 也是一款在用户态就能绕过 PPL 的工具。nanodump 都集成了这 2 个工具的功能，因此我们并不需要单独去下载和编译 它们了。

在 Srv01 上，PPLdump 的方法成功了，而 PPLmedic 却失败了。