前言
两周前，我发布了几个利用INF文件（.inf）来“获取并执行”远程脚本组件文件（.sct）的“pass-thru”技术。通常，这些方法的实例可能会被滥用，以绕过应用程序白名单（AWL）策略（例如，默认的AppLocker策略），从而阻止基于主机的安全产品，以一种隐蔽的方式来保证持久性。此外，本文还关注了一些其他“获取与执行”技术，并提出了关于防御方式的一些观点。我们建议在阅读本文之前，先回顾第一部分（ https://bohops.com/2018/02/26/leveraging-inf-sct-fetch-execute-techniques-for-bypass-evasion-persistence/ ）。在介绍本文中的INF-SCT方法之前，我们会重新讨论一些前面的主题：
InfDefaultInstall
IExpress
IEadvpack.dll (LaunchINFSection)
IE4uinit
回顾Setupapi.dll (InstallHinfSection)和Advpack.dll (LaunchINFSection)
Setupapi.dll (InstallHinfSection) – InfDefaultInstall.exe
在2017年DerbyCon主题为“逃避自动运行”的演讲（ https://github.com/huntresslabs/evading-autoruns/blob/master/Evading_Autoruns_Slides.pdf ）中，来自HuntressLab的KyleHanslovan和ChrisBisnett展示了几种INF-SCT技术。我认为其中的Setupapi.dll (InstallHinfSection)可以用于此类调用，但是我并没有提及他们发现的InfDefaultInstall，因此我就与他们的研究方向相偏离。借助于这个二进制文件，我们可以通过以下的基本命令来实现INF-SCT有效载荷的执行：
infdefaultinstall.exe [path to file.inf]
如下面截屏所示，该命令执行后，我们的有效载荷calc.exe（计算器程序）被成功启动，同时在测试过程中弹出了一个错误消息：
我们运行SysInternals Strings，对InfDefaultInstall进行了快速分析。结果表明，这个二进制文件依赖于调用Setupapi.dll和InstallHinfSection的字符集兼容性变体来实现执行操作：
Advpack.dll (LaunchINFSection) – CMSTP.exe
在上一篇文战中，我们讨论了使用NickTyrer的CMSTP方法和Advpack.dll (LaunchINFSection)方法来执行INF-SCT。这两种方法密切相关，如下面截图所示，展现的是使用Strings进行CMSTP分析的过程：
在其背后，CMSTP实际上利用了Advpack.dll和LaunchINFSection的变体。
使用IEexpress、IEadvpack.dll (LaunchINFSection) 和IE4uinit的INF-SCT执行
IEexpress
IExpress.exe是一个用于创建自解压安装包的实用工具，自Windows 2000以来一直捆绑在Windows之中。通过我们的查看，该工具仍然存在于Windows 10和Windows 2016中。 IExpress可以作为（带有开关的）命令行工具被调用，也可以以逐步向导的形式独立启动。
有趣的是，IExpress可以将一个INF文件（包含适当的指令以调用SCT）添加到用于打包的文件列表中。在逐步向导完成后，创建子解压缩的伪指令（SED）文件和生成的压缩可执行文件（在这里，是否生成SED文件是可选的）。通过命令行或GUI调用可执行文件，将会启动捆绑的INF用于有效载荷传递，如下面截图所示：
在命令行模式下，IExpress可以使用正确配置的SED，创建相同的可执行文件：
iexpress.exe /n [path to file.sed]
*注意：由IExpress.exe创建的有效载荷可执行文件都是未签名的。
IEadvpack.dll (LaunchINFSection)
在搜索感兴趣的DLL函数过程中，我发现有重复的LaunchINFSection条目。正如在我们之前文章中所分析的那样，这是使用rundll32/advpack.dll调用的函数。就在这个时候，我发现了IEadvpack.dll：
借助于已经掌握的知识，我用非常相似的命令对这一发现进行了测试：
rundll32.exe ieadvpack.dll,LaunchINFSection test.inf,,1,
不出我们的所料，最终INF-SCT成功执行。
*注意：与Advpack.dll一样，IEadvpack.dll/LaunchINFSection可以绕过默认的AppLocker规则。
IE4uinit
受InfDefaultInstall和CMSTP“字符串分析”的启发，我决定中遍历Windows二进制文件，搜索“IEadvpack”：
在结果中，我发现了一个名为ie4uinit.exe的有趣二进制文件。通过Google搜索，我找到了这个MSDN页面（ https://blogs.msdn.microsoft.com/askie/2012/09/13/things-to-do-when-troubleshooting-internet-explorer-terminal-server-and-profiles-issues/ ）。该文章指出，IE4Uinit是与Active Setup配合使用，并且在登陆过程中首次创建用户配置文件（或者每次强制配置文件）时运行。此外，还存在几个命令开关，如下面截图所示：
运行SysInternals Strings后，我发现IE4uinit调用一个名为ieuinit.inf的INF文件：
ieuinit.inf的实例保存在System32和SysWOW64目录下。需要特别说明的是，如果没有正确的权限（和一些命令行操作技巧），这些文件通常都不能被编辑。然而，我们可以通过一些方法来解决这一问题：
1、至少在我们字符串分析过程的上下文中，不存在到ieuinit.inf的完整/静态路径。这也就意味着，我们可以调用ieuinit.inf的一个实例，只要它与ie4uinit.exe的一个实例在同一目录即可。
2、即使作为非特权用户，我们也可以轻松将这些文件从System32目录中复制出来，在用户可写入的目录中编辑所需的INF文件，然后测试SCT有效载荷的执行情况。
接下来，让我们将这些文件复制到工作目录，并更新相应的INF文件：
在这个示例中，导入的INF指令会调用一个标记为DefaultInstall.Windows7的部分，该部分启动MSIE4RegisterOCX.Windows7。这就是我们添加scrobj.dll/SCT URL有效载荷的位置：
接下来，让我们尝试使用在MSDN博客中看到的一个用于调用有效载荷的开关——ie4uinit.exe –BaseSettings：
该尝试成功，我们目前就可以成功执行有效载荷。在下一节中，我们来详细介绍这一方面。
*注意：在跨平台测试的过程中，我发现我有一台机器无法在MSIE4RegisterOCX.Windows7段中调用该脚本。在使用scrobj.dll/SCT条目添加了新段 (FunRun)后，我修改了DefaultInstall.Windows7段，并添加了UnregisterOCXs以指向FunRun段。事实证明，端到端的调用时成功的。如果有人在尝试测试此方法过程中出现问题，那么可以按照如上步骤进行。造成这一问题的根源尚不确定。
IE4uinit的逃避和持久性
为了更好地进行尝试（和欺骗），我们可以将相应的文件复制到C:WindowsTasks，因为默认情况下任何经过身份验证的目录都可以对该目录执行写入操作。现在，我们通过为IE4uinit创建一个运行密钥，来进行持久性和逃避的概念验证联系（在AutoRuns情景中）：
打开AutoRuns程序并删除Hide Windows Entries过滤器后，我们便可以深入到Run Key条目：
IE4uinit是一个签名的Microsoft Windows二进制文件，C:windowsTasks是一个特殊的目录（特别是在选择了Schedule Task的情况下）。最重要的是，即使删除了Windows条目筛选器，也无法发现修改后的INF（带有SCT有效载荷）存在。再重新登录到主机之后，SCT有效载荷将会启动calc.exe（例如我在Windows 10 Surface Pro平板电脑上所演示的）：
防御方式
在此前文章中提及的防御方式仍然适用。请注意，INF属性（指令、头部名称等）以及文件名都可能会被修改为有迷惑性的内容。
从监测的角度来看，我们深入讨论“AutoRuns分析”，并重点留意错误的二进制文件，是因为二进制的签名不能代表一切，我们必须观察命令的开关、参数以及目录路径。
同时，也可以使用强制执行应用程序白名单（AWL）策略。一旦超过了默认规则，那么就应该减少敏感文件中弱目录的权限。
InvalidOperator指出，IExpress二进制文件可能会在执行时写入Run或RunOnce键，这一特性可能有助于IOC监测。
结论
感谢各位读者认真阅读本篇文章。在下一部分中，我们将重点介绍Microsoft AWL技术，同时也会涉及到其他一些话题。如果各位读者有任何疑问、意见或反馈，请随时与我们联系。