Endpoint Security Bypass
In this module, we’ll begin investigating how attackers avoid or get around endpoint security. Most modern systems have some form of security, like antivirus software, EDR platforms, or advanced AI-based detection. Attackers usually have three main ways to bypass these security measures.
Modifying existing tools to evade detection
Using tricks to make harmful code appear safe.
Changing their methods to use tools that reach their goals without triggering alarms.
Advanced attackers can often get around endpoint security, but it might take more than one attempt. In this module, we’ll explore techniques they use to bypass these systems, although they sometimes trigger alarms while trying to find a way that works.
DefenderCheck
We'll look at a way attackers modify malware to avoid detection by signature-based systems like Windows Defender. Many defenders still rely on these methods, so attackers often gather information about the victim's security setup. They test the malware on an offline system until it can bypass the protection. Once it works there, they know it will also work on the victim's system.
DefenderCheck is a tool that helps attackers. It scans a file on a Windows system using Windows Defender. If the file is flagged as malicious, DefenderCheck splits the file in two and scans each part separately, keeping only the part that triggers the alert. It keeps splitting and scanning until it finds the smallest piece that still gets flagged.
DefenderCheck looks at the Mimikatz program many times until it finds a 112-byte part that doesn’t trigger Windows Defender alerts when split further. This part has some text strings in it (like "doLocal" and "module not found"). An attacker can change this part using the source code or a hex editor, then keep scanning with Windows Defender until they have a version of Mimikatz that works without being detected.
Wrapping and Obfuscation
Attackers can avoid detection by using code wrapping and obfuscation. This method tricks both signature-based and behavioral analysis systems. In this attack, the attacker surrounds their malicious code with a new program, using a library to run it, often compiling it into a Windows executable.
This shows a C# program that uses IronPython to run hidden Python code directly in C#. Usually, Python needs its own interpreter to run, but IronPython lets you include Python code as a variable in a C# program and run it together, so no separate Python installation is needed.
An attacker can use a C# program to run any Metasploit payload made with msfvenom. By hiding the Meterpreter payload in the C# code, they can create a new executable using Microsoft Visual Studio.
In the author's experience, this method often avoids detection by many security tools because few look inside IronPython libraries to check for harmful code. However, these methods don’t stay effective for long. Security vendors find out about new attacker techniques and improve their tools to catch them. In response, attackers keep searching for new ways to hide their code, using different languages like Ruby, Rust, and Golang.
A complete example of this C# source code to evade endpoint detection is available at https://urls.sec504.org/mtngy.
Application Allow Lists
Many products exist for endpoint defense, but networks rely on vendors to update their systems against new threats. When a vendor finds a new way attackers can get around defenses, they create updates to detect it. However, until those updates are delivered, endpoints stay vulnerable. This cycle—attackers finding new bypasses and defenders adding detections—will likely keep happening.
A better way is to use an application allow list. This list specifies which programs can run based on their file hash, name, location, or signature. Only these approved programs can execute; all others are blocked.
Application allow lists are tough for defenders to manage because they often need updates when programs change (like new versions with different names or paths). However, they are a strong way to prevent attackers from running unauthorized programs. Many third-party security vendors offer this feature, and it’s also built into Windows 10 Enterprise and recent Windows Server versions through AppLocker.
When enabling AppLocker on Windows, admins can use a learning mode to see what executables users run and test policies before blocking. AppLocker logs all program activity in the event log, but the default log size is only 1 MB, limiting how much is stored. Defenders can increase the log size to 100 MB using the command: Limit-EventLog -LogName "Microsoft-Windows-AppLocker/EXE and DLL" -MaximumSize 100MB.
Windows Passwords: Mimikatz
Earlier, we talked about password attacks and the Mimikatz tool, which is used to steal passwords from Windows. Since it's popular with attackers, Microsoft created defenses like a Windows Defender check that blocks Mimikatz.
Mimikatz doesn’t need to run directly on the victim's system to steal passwords. It can grab passwords from memory, like from the LSASS process. Microsoft’s Procdump tool, which is trusted because it’s Microsoft-signed, can also capture memory from processes without being blocked by security tools like Windows Defender.
Mimikatz
Mimikatz can get passwords from LSASS by using a Procdump memory file with the sekurlsa::minidump command. This helps attackers avoid detection but needs more data transfer (about 50MB). It’s a popular alternative to running Mimikatz directly on the victim's system.
Living Off the Land (LOL)
When attackers have limited options on a compromised system, they use a method called Living Off the Land (LOL). Instead of bypassing security, they use built-in programs already allowed by the system to achieve their goals without adding new tools.
The LOLBAS project shows how attackers can use built-in tools on a system to achieve their goals. For example, instead of installing new software, attackers can use tools like Bitsadmin to move data or Certutil to download scripts. The project lists many similar ways attackers can use existing utilities on a compromised system.
Microsoft .NET InstallUtil
Attackers can bypass application allow lists by using unusual methods to run malware. For example, they can avoid AppLocker by using InstallUtil. AppLocker checks if a program is on the allow list before letting it run, focusing on process creation, script execution, and DLL loading. If a program isn't on the list, it won't run. AppLocker uses a set of default rules, including allowing all programs in the C:\Windows directory.
Validating the allow list only at process creation, DLL load, and script execution is done to save performance. Checking every thread or code in all processes would slow down Windows. However, this gives attackers a chance to bypass AppLocker and similar controls.
The .NET Install Utility (InstallUtil) is found in the C:\Windows\Microsoft.NET\Framework\VERSION folder, where VERSION depends on the .NET version. This tool installs and uninstalls programs from the command line and can run executables through reflection (loading the code into memory instead of creating a new process). AppLocker doesn’t properly check this reflection method, allowing attackers to run malicious code using an AppLocker-approved program. The attacker can hide the malicious code in the uninstall process, making the program appear safe until uninstalled.
Attackers try to bypass application allow lists with unusual code execution methods. InstallUtil isn’t malicious; it’s a Microsoft tool that can run code in a way that evades AppLocker security.
Linux Living Off the Land: Priv. Escalation
What can you do with sudo?
sudo -l
Are there uncommon SETUID files?
find / -perm -4000 -uid 0
Is Netcat installed?
which nc
Is Smbclient installed?
which smbclient
Any passwords in shell history?
find / -name "history"
Any passwords in web files?
grep -iR password /var/www
Any unprotected SSH keys?
cat /home/*/.ssh/
Linux systems have built-in security tools (like SELinux and IMA) and third-party options for endpoint protection, though they’re less common than on Windows. Attackers may try to bypass these protections by using Linux features to gain higher privileges or steal data. For instance, tools like sudo can give attackers limited access to run privileged commands. They may also look for files with the SETUID bit, which run with the owner’s privileges instead of the user’s, to escalate their access.
Attackers can use tools already on a hacked Linux system to target others, similar to methods used on Windows. For example, Netcat can create backdoors and scan networks. Tools like Smbclient can also help attackers move from a Linux system to attack Windows machines. These tools are often built into Linux, making them useful for attackers and allowed for use.
Attackers may try to steal passwords to access more resources. Files like shell history, web server logs, and SSH keys can help them bypass security and achieve their goals.
Let's jump into a Lightning Labs event to reinforce this learning objective.
1) One opportunity to escalate privileges on Linux and UNIX systems is to use Sudo in unanticipated ways. First, let's take a look at the privileges we have without Sudo. Run the id command to see your privileges.
In this output we see that we have fairly limited access to the system. We are a member of the sec504 group, and our username is sec504, but no additional group membership, and no special user ID privileges.
2) For demonstration purposes, try to get the contents of the /etc/shadow file.
As you might expect, we can't access the /etc/shadow file with our limited privileges.
3) Let's see if we can run the su command with Sudo like we have in other lab exercises. If we can run sudo su successfully, then we can use it to read the shadow file.
In this configuration, Sudo does not allow the sec504 user to run the su command. However, there may be other commands that we can run with Sudo.
4) To list the commands available to you with Sudo, run sudo -l.
In the output of sudo -l we see a line indicating that the sec504 user can run the /usr/bin/gdb command.
GDB is the GNU Debugger, a programming tool to debug software. Developers often need privileged access to GDB to debug processes running with privileges other than their own. On this system, the administrator is letting the sec504 user account run gdb as root through Sudo.
5) Run the sudo command again, this time directing it to run gdb.
This time we're allowed to use Sudo to run the gdb command as root. In normal use, developers will enter debugging commands here to troubleshoot software. However, we have another option.
Run the GDB help shell command at the prompt.
GDB supports the shell command, which allows a developer to start a command shell from GDB. Type the shell command.
6) Immediately we get the familiar root shell prompt. Because GDB is running with root privileges, any functionality started by GDB also inherits root privileges. Re-run the id command.
7) The id command reveals that we now have root access to the system. Retrieve the contents of the /etc/shadow file.
Endpoint Bypass: Defenses
Even skilled attackers can eventually bypass endpoint protection, but that doesn't mean we should stop using it. Defenders should invest in up-to-date EDR systems, use tools like application allow lists (e.g., AppLocker) to control what can run on the system, and combine them with threat hunting, logging, and monitoring. UEBA tools are also useful to track normal behavior and spot unusual activity, like a system running a program it hasn't used before.
The main benefit of these tools is not that they will always stop attackers right away. Often, they might stop an attacker at first, but then the attacker finds ways to get around the protections. However, the initial defense and logging are crucial for defenders to spot attacks in their organization. When combined with quick incident response when attacks are detected, EDR tools are very valuable. They help not only to stop initial attacks but also to find compromised systems that need further action.
Lab 5.1: Application Allow List Bypass
In this lab exercise we will evade Windows AppLocker, an application allow list tool by creating a custom program and executing code using Living off the Land (LOL) techniques. After the lab we will examine the system for Indicators of Compromise (IOC) that we can use to detect this attack in a production environment.
The Windows 10 VM has a default AppLocker policy. Let's enable the AppLocker service (appidsvc).
The goal is to bypass AppLocker and run a Meterpreter reverse TCP payload. Let's try running it from an admin PowerShell session.
We can't run meterpreter.exe. Let's list the AppLocker rules using Get-AppLockerPolicy.
This shows what's allowed by the AppLocker policy. Windows permits programs in Program Files, Windows folders, and some tools in C:\Tools. Anything else, like Netcat in C:\Tools\nc.exe, can't run.
An attacker may use allowed tools to reach their goals. Let's check if the .NET C# compiler (csc.exe) is available.
Windows often has multiple .NET versions. Here, we see several C# compiler versions. Let's test if the C# compiler runs from C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe.
Since csc.exe is in C:\Windows, AppLocker allows it. Now, let's search for the .NET Installer Tool the same way.
Both csc.exe and InstallUtil.exe are allowed by Windows AppLocker, giving attackers a chance to bypass the application allow list.
Let's switch to the Slingshot Linux VM, then go to the ~/labs/endpointbypass folder, and list the files.
The Shellcode.cs file is a simple C# program by Casey Smith that runs a Metasploit payload. Let's use cat to view its contents.
Let's see the Main function.
This code runs the Main function when compiled and executed, showing just one line of output with no special behavior.
The Shellcode.cs file seems harmless when run, just showing a message. But if the program is uninstalled, it runs a hidden Metasploit payload. This helps attackers avoid detection while keeping the malicious function.
The Shellcode.cs program is empty and needs a Metasploit payload to work. Let's use msfvenom to create a Meterpreter reverse TCP payload in C# format from your terminal.
Msfvenom shows the exploit code on the screen. Let's highlight from "byte[] buf =" to the closing "};" and copy it.
Let's paste the contents of the clipboard containing the Msfvenom payload by pressing in the Shellcode.cs file.
Let's set up the reverse TCP Meterpreter session using msfconsole. We can configure the Metasploit handler manually or use a provided script for quicker setup.
For this lab, the pre-made Shellcode.cs file is in the Windows VM at C:\Tools.
Let's use the .NET C# compiler to compile the Shellcode.cs file.
Let's run shellcode.exe from the PowerShell session.
This is the expected output, we can't run shellcode.exe directly due to the AppLocker policy.
Next, let's use the .NET Installer Tool to uninstall the shellcode.exe file.
Let's break down the command:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\InstallUtil.exe: This runs the .NET InstallUtil tool allowed by AppLocker.
logfile=: This sets a log file name; if left blank, no log file is created.
LogToConsole=false: This stops the output from showing in the attacker's console.
/U: This tells InstallUtil to run the uninstall routine.
shellcode.exe: This is the program name for the uninstall routine to bypass AppLocker restrictions.
Let's go back to Slingshot Linux and the Metasploit handler. We'll see a reverse TCP connection.
Let's take a look at the steps we applied as an attacker to bypass AppLocker.
AppLocker allows the .NET Installation Utility to run because it's in the C:\Windows folder, which is a default setting. This lets an attacker use installutil.exe to run a malicious uninstall feature. By adding harmful code to the uninstall function in Shellcode.cs, we were able to execute the Meterpreter payload.
This highlights a key point about endpoint protection: attackers can usually get around it, but not always on their first attempt. Let’s review the evidence incident responders can use to understand what happened.
AppLocker has a key benefit: it logs when programs run, noting the date and time in its event log. We can use the PowerShell Get-WinEvent command to get the latest entries from this log.
This shows entries from the AppLocker log for EXE and DLL execution. There are multiple event ID 8002 messages for allowed programs. One message shows the use of installutil.exe to bypass AppLocker, and another shows csc.exe being used to compile Shellcode.cs.
We’ll get info on the executables that AppLocker blocked. Blocked ones are recorded with event ID 8004. We can create a filter for just these blocked executables using Where-Object.
The oldest event is from 9/20/2024 at 5:09:27 PM, where meterpreter.exe was blocked. Let's use this information to create a report on the following events. In PowerShell, let's use Get-WinEvent with a filter to show all AppLocker execution events (8002 or 8004). We'll select the fields TimeCreated, Id, Message, ProcessId, and UserId, and save the results as an HTML report.
Next, let's open the HTML report using Start-Process and the report.
This shows the HTML report. It's not pretty, but it's useful for more timeline analysis.
Last updated
