Pentest Red Team Techniques - Defense Evasion

[dEEpEst]

Compile After Delivery​

Adversaries may attempt to make payloads difficult to discover and analyze by delivering files to victims as uncompiled code. Text-based source code files may subvert analysis and scrutiny from protections targeting executables/binaries. These payloads will need to be compiled before execution before execution; typically via native utilities such as csc.exe or GCC/MinGW.

Source code payloads may also be encrypted, encoded, and/or embedded within other files, such as those delivered as a Phishing. Payloads may also be delivered in formats unrecognizable and inherently benign to the native OS (ex:EXEs on macOS/Linux) before later being (re)compiled into a proper executable binary with bundled compiler and execution framework.

Example:

The .NET Framework includes a mechanism called the Code Document Object Model (CodeDOM) that enables developers of programs that emit source code to generate source code in multiple programming languages at run time, based on a single model that represents the code to render. Sometimes developers need it, and .NET Framework makes it possible. For example, the following C# code compiles the C# code assigned to the "code" variable during execution and runs it.

Here is a sample code with C#

Any part from the "string code" section will get compiled and executed when the application runs.

Reference:

This link is hidden for visitors. Please Log in or register now.

 

[dEEpEst]

Indicator Removal from Tools​

Adversaries may remove indicators from tools if they believe their malicious tool was detected, quarantined, or otherwise curtailed. They can modify the tools by removing the indicator and using the updated version that is no longer detected by the target's defensive systems or subsequent targets that may use similar systems.

A good example of this is when malware is detected with a file signature and quarantined by anti-virus software. An adversary who can determine that the malware was quarantined because of its file signature may modify the file to explicitly avoid that signature, and then re-use the malware.

Example:

This demo is very easy to follow Malware usually gets detected because of Signatures, these are in the AV Database and when the malware touches disk the AV compares it signature to its known DataBase.

For example I will grab the hash of a common payload from msfvenom

Now with a Hex Editor Tool I will change just 1 Hex Decimal and the Hash will completely change

Hash has changed

For Demo purposes I broke the functionality of this payload to demonstrate the hash changing but after some work and testing you can actually change the Hex without breaking functionality. With this there is no need to completely re-write tools or payloads and just remove the offending strings from the binary. In that manner the Hash value will change and be undetectable.

 

[dEEpEst]

Masquerading​

Adversaries may attempt to manipulate features of their artifacts to make them appear legitimate or benign to users and/or security tools. Masquerading occurs when the name or location of an object, legitimate or malicious, is manipulated or abused for the sake of evading defenses and observation. This may include manipulating file type, and giving legitimate task or service names.

Renaming abusable system utilities to evade security monitoring is also a form of Masquerading.

 

[dEEpEst]

Invalid Code Signature​

Adversaries may attempt to mimic features of valid code signatures to increase the chance of deceiving a user, analyst, or tool. Code signing provides a level of authenticity on a binary from the developer and a guarantee that the binary has not been tampered with. Adversaries can copy the metadata and signature information from a signed program, then use it as a template for an unsigned program. Files with invalid code signatures will fail digital signature validation checks, but they may appear more legitimate to users and security tools may improperly handle these files.

Unlike Code Signing, this activity will not result in a valid signature.

Example

CarbonCopy a tool built by paranoidninja for spoofing Digital Signatures, signatures like these can actually bypass AV and pass undetected by analysts because they provide a level of authenticity. See 2 payloads with and without a Digital Signature.

Now will check out the digitally signed one a little more to check what it contains.

A Digital Signature not installed of course this is why we see that it cannot be verified.

We have the option to install this certificate of course with proper permissions but here I am just trying to demonstrate how this "Signature" can provide some level of authenticity since it is Signed by Microsoft, of course a solid analyst can see that this has been valid from a recent Date. So how can we build this digitally signed binary, with CarbonCopy.

Above we see a successful spoofed Signature the requirements for this is very simple the website we are trying to spoof its signature the port the target payload and an output file.

You will also need OSSLSignedCode tool to be installed.

References:

This link is hidden for visitors. Please Log in or register now.

 

[dEEpEst]

Right-to-Left-Override​

Adversaries may use the right-to-left override (RTLO or RLO) character (U+202E) as a means of tricking a user into executing what they think is a benign file type but is actually executable code. RTLO is a non-printing character that causes the text that follows it to be displayed in reverse. For example, a Windows screensaver executable named March 25 \u202Excod.scr will display as March 25 rcs.docx. A JavaScript file named photo_high_re\u202Egnp.js will be displayed as photo_high_resj.png.

A common use of this technique is with Spearphishing Attachment/Malicious File since it can trick both end users and defenders if they are not aware of how their tools display and render the RTLO character. Use of the RTLO character has been in many targeted intrusion attempts and criminal activity. RTLO can be used in the Windows Registry as well, where regedit.exe display the reverse characters but the command line tool reg.exe does not by default.

Example:

Using a tool called Extension Spoofer from henriksb (

This link is hidden for visitors. Please Log in or register now.

)

It uses the RTLO to spoof extensions and it as well masquerades the binary by changing its Icon.

The tool is very simple, Run, Choose your Payload and Apply the Spoof extension and the Source Extension.

We hit Generate and our original file will change with the new extension and spoofed name as well.

This was a simple demonstration on how to apply this methodology to trick users in believing they are opening another file this may trick the majority of users since they see an Icon unrelated to EXE and an Extension that is known to not be malicious (

This link is hidden for visitors. Please Log in or register now.

).

 

[dEEpEst]

Rename System Utilities​

Adversaries may rename legitimate system utilities to try to evade security mechanisms concerning the usage of those utilities. Security monitoring and control mechanisms may be in place for system utilities adversaries are capable of abusing. It may be possible to bypass those security mechanisms by renaming the utility prior to utilization (ex: rename rundll32.exe). An alternative case occurs when a legitimate utility is copied or moved to a different directory and renamed to avoid detections based on system utilities executing from non-standard paths.

Example

This technique is very simple, will grab legitimate system utilities and just rename them, sometimes the logging or IDS are looking for specific strings that will prevent execution, but what if instead of calling runddl32 we call "dllexecute" this would be rundll32 but just renamed. The execution and functionality will still be the same but it would bypass defenses since the string is no longer rundll32.

Two different syntax but same results. Since rundll32 has just been renamed but its functionality hasn't been changed.

Sometimes renaming utilities is enough to bypass security, in a previous research, it seems that renaming your payload to MSBuild was enough to prevent Defender to scan your payload.

 

[dEEpEst]

Masquerade Task or Service​

Adversaries may attempt to manipulate the name of a task or service to make it appear legitimate or benign. Tasks/services executed by the Task Scheduler or systemd will typically be given a name and/or description. Windows services will have a service name as well as a display name. Many benign tasks and services exist that have commonly associated names that are similar or identical to those of legitimate ones.

Tasks or services contain other fields, such as a description, that adversaries may attempt to make appear legitimate.

Example:

Sometimes tricking the user that a normal task is being run to trick them that it’s a legitimate service.

 

[dEEpEst]

Match Legitimate Name or location​

Adversaries may match or approximate the name or location of legitimate files when naming/placing their files. This is done for the sake of evading defenses and observation. This may be done by placing an executable in a commonly trusted directory (ex: under System32) or giving it the name of a legitimate, trusted program (ex: svchost.exe). Alternatively, the filename given may be a close approximation of legitimate programs or something innocuous.

Adversaries may also use the same icon of the file they are trying to mimic.

Example:

Here I will mimic rundll32

For the untrained eye we see that they look quite similar in their name but the difference is that rundll32 is now typed with uppercase "i". This might look similar just typing it here rundll and rundII sometimes it also depends on the type of font it is being used.

 

[dEEpEst]

Indirect Command Execution​

Adversaries may abuse utilities that allow for command execution to bypass security restrictions that limit the use of command-line interpreters. Various Window utilities may be used to execute commands, possibly without invoking cmd. For example, Forfiles, the Program Compatibility Assistant (pcalua.exe), components of the Windows Subsystem for Linux (WSL), as well as other utilities may invoke the execution of programs and commands from a Command and Scripting Interpreter, Run window, or via scripts.

Adversaries may abuse these features for Defense Evasion, specifically to perform arbitrary execution while subverting detections and/or mitigation controls (such as Group Policy) that limit/prevent the usage of cmd or file extensions more commonly associated with malicious payloads.

Example

In this Demo using the forfiles utility which can select multiple files and run a command on them. It is typically used in batch jobs but it could be abused to execute arbitrary command or executable. The parameters "/p" and "/m" are used to perform a search in the windows directory "System32" and on the mask "calc.exe". Anything after "/c" parameter is the actual command that is executed.

Let's check process Explorer and see what happened.

We see here the our payload is a child process of the forfiles utility we can also use this with the Windows "Run" and eliminate the use of the command prompt

Even though it's still the child process of forfiles it tools different steps to execute. We also have the pcalua utility to execute commands as well

From the samples from pcaula this can execute binaries, DLL files they can be local and remote since the binary is proxy aware meaning we can also use UNC Paths.

I was searching for information on why the "-a" parameter but couldn't find any.

The User will receive a prompt to Run

Weird thing though is that the payload executes but Defender manages to Delete and Remove the Payload from the REMOTE SHARE!!.

That is the traffic from when the payload is accessed and being DELETED. Even with a normal payload with no obfuscation straight out of the box can give us a connection

PCALUA is nowhere in the Process Explorer since Defender Kills it but our connection is still active as it becomes its own process.

Reference:

This link is hidden for visitors. Please Log in or register now.

https://twitter.com/x/status/912659279806640128

 

[dEEpEst]

Impair Defenses​

Adversaries may maliciously modify components of a victim environment on order to hinder or disable defensive mechanisms. This not only involves impairing preventative defenses, such as firewalls and anti-virus, but also detection capabilities that defenders can use to audit activity and identify malicious behavior. This may also span both native defenses as well as supplemental capabilities installed by users and administrators.

Adversaries could also target event aggregation and analysis mechanisms, or otherwise disrupt these procedures by altering other system components.

 

[dEEpEst]

Disable or Modify Tools​

Adversaries may disable security tools to avoid possible detection of their tools and activities. This can take the form of killing security software or event logging processes, deleting Registry keys so that tools do not start at run time, or other methods to interfere with security tools scanning or reporting information.

Example:

A method that is great for evasion but very likely to get caught is to simply Disable the Tool for Detection in this sample I will disable Windows Defender to have our payloads safely stay in the target.

In the above image we can see that Defender is Enable. We can easily disable it with PowerShell

We can also use the GUI and defender it normally if we have an RDP session, there was a method to disable this through the Registry Keys but since of August 2020 this has been disabled and Windows Ignored this now

 

[dEEpEst]

Disable Windows Event Logging​

Adversaries may disable Windows event logging to limit data that can be leveraged for detections and audits. Windows event logs record user and system activity such as login attempts, process creating, and much more. This data is used by security tools and analysis to generate detections.

Adversaries may target system-wide logging or just that of a particular application. By disabling Windows event logging, adversaries can operate while leaving less evidence of a compromise behind.

Example:

We can also disable the eventlog service from the workstation this can be done with PowerShell but we will need to apply the -Force flag since this service has other services dependent from it.

We can confirm it with CMD as well and we see that it is unable to start since the service is also disabled, besides being stopped as well.

Set it back how it was is simple.

And a restart then all back to normal. As we can see this is a great method to hide our tracks and a progression done in an environment APT have a use for these techniques to evade Defenses

 

[dEEpEst]

Impair Command History Logging​

Adversaries may impair command history logging to hide commands they run in a compromised system. Various command interpreters keep track of the commands users type in their terminal so that users can retrace what they've done.

On Linux and macOS, command history is tracked in a file pointed to by the environment variable HISTFILE. When a user logs off a system, this information is flushed to a file in the user's home directory called ~/.bash_history. The HISTCONTROL environment variable keeps track of what should be saved by the history command and eventually into the ~/.bash_history file when a user logs out. HISTCONTROL does not exist by default on macOS, but can be set by the user and will be respected.

Adversaries may clear the history environment variable (unset HISTFILE) or set the command history size to zero (export HISTFILESIZE=0) to prevent logging of commands. Additionally, HISTCONTROL can be configured to ignore commands that start with a space by simply setting it to "ignorespace". HISTCONTROL can also be set to ignore duplicate commands by setting it to "ignoredups" which covers both of the previous examples. This meant that "ls" will not be saved but "ls" would be saved by history. Adversaries can abuse this to operate without leaving traces by simply prepending a space to all their terminal commands.

On Windows systems, the PSReadLine module tracks commands used in all PowerShell sessions and writes them to a file ($env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\Consolehost_history.txt by default). Adversaries may change where these logs are saved using Set-PsReadLineOption -historySavePath {(FilePATH)}. This will cause ConsoleHost_history.txt to stop receiving logs. Additionally, it is possible to turn off logging to this file using the PowerShell command Set-PSReadlineOption -HistorySaveStyle SaveNothing.

Example:

Since cmd has history logging when you hit F7

Unfortunately for IT people this is only available in the current session once you close cmd the log disappears, but PowerShell we have the ConsoleHost File Log that we previously explained. TO disable the logging is simple.

 

[dEEpEst]

Disable or Modify System Firewall​

Adversaries may disable or modify system firewalls in order to bypass controls limiting network usage. Changes could be disabling the entire mechanism as well as adding, deleting, or modify particular rules. This can be done numerous ways depending on the operating system, including via command-line, editing Windows Registry keys, and Windows Control Panel.

Modifying or disabling a system firewall may enable adversary C2 communications, lateral movement, and/or data exfiltration that would otherwise not be allowed.

Example:

Adversaries may modify or disable these firewall rules so that traffic is allowed Inbound/Outbound form the Workstation this can be helpful in Lateral Movement, Exfiltration or just Communication with our C2

In the upper image we see our default settings for our Firewall you see that all Inbound Connections are not allowed but can have outbound connections, we see that their state is ON to disable we do the following.

As we can see the user receives a pop-up warning that the firewall has been turned off.

Firewall Disabled now any outbound and inbound connections are available and other techniques that allow adversaries to achieve malicious intent is also available now.

 

[dEEpEst]

Indicator Blocking​

An adversary may attempt to block indicators or events typically captured by sensors from being gathered and analyzed. This could include maliciously redirecting or even disabling host-based sensors, such as Event Tracing for Windows (ETA), by tampering settings that control the collection and flow of event telemetry. These settings may be stored on the system in configuration files and/or in the Registry as well as being accessible via administrative utilities such as PowerShell or Windows Management Instrumentation.

ETW interruption can be achieved multiple ways, however most directly by defining conditions using the PowerShell Set-EtwTraceProvider cmdlet or by interfacing directly with the Registry to make alterations.

In the case network-based reporting of indicators, an adversary may block traffic associated with reporting to prevent central analysis. This may be accomplished by many means, such as stopping a local process responsible for forwarding telemetry and/or creating a host-based firewall rule to block traffic to specific hosts responsible for aggregating events, such as security information and event management (SIEM) products.

Reference:

This link is hidden for visitors. Please Log in or register now.

 

[dEEpEst]

Indicator Removal on Host​

Adversaries may delete or alter generated artifacts on a host system, including logs or captured files such as quarantined malware. Locations and format of logs are platform or product-specific, however standard operating system logs are captured as Windows events or Linux/macOS files such as Bash History and /var/log/*.

These actions may interfere with event collection, reporting, or other notifications used to detect intrusion activity. This may compromise the integrity of security solutions by causing notable events to go unreported. This activity may also impede forensic analysis and incident response, due to lack of sufficient data to determine what occurred.

 

[dEEpEst]

Clear Windows Event Logs​

Adversaries may clear Windows Event Logs to hide the activity of an intrusion. Windows Event Logs are record of a computer's alert and notifications. There are three system-defined sources of events: System, Application, and Security, with five event types: Error, Warning, Information, Success Audit, and Failure Audit.

The event logs can be cleared with the following utility commands:

· Wevtutil cl system

· Wevtutil cl application

· Wevtutil cl security

These logs may also be cleared through other mechanisms, such as event viewer GUI or PowerShell

Example:

Adversaries with high permissions they can clear all their malicious steps taken in an environment, even though not the stealthiest but still a reliable way to remove tracks is to clear the Windows Event Logs, here is a sample on a Logon Event in Windows.

That is one example of a User login into the System and hunting for malicious activity, we also have some more in-depth examples with PowerShell we can enable Script Logging and have a detailed view on what is going on, adversaries tend to use PowerShell for it's In-Memory capability for fileless payloads.

In the above sample a user is invoking PowerShell with one common cmdlet to view what processes are running. So let's delete them some common ones "Security" from the logs and remove our tracks showing a clean slate.

Careful as you can see below an Event is Created as well that the logs have been cleared. It even says who did it and the time so be aware of this.

Of Course this is not a good thing to do in an environment you are assessing as you are trying to make the Blue Team better, remember be Ethical.

 

[dEEpEst]

Clear Command History​

In addition to clearing system logs, an adversary may clear the command history of a compromised account to conceal the actions undertaken during an intrusion. Various command interpreters keep track of the commands users type in their terminal so that users can retrace what they've done.

On Linux and macOS, these command histories can be accessed in a few different ways. While logged in, this command history is tracked in a file pointed to by the environment variable HISTFILE. When a user logs off a system, this information is flushed to a file in the user's home directory called ~/.bash_history. The benefit of this is that it allows users to go back to commands they've used before in different sessions.

On Windows hosts, PowerShell has two different command history providers: the built-in history and the command history managed by the PSReadLine module. The built-in history only tracks the commands used in the current session. The command history is not available to other sessions and is deleted when the session ends.

The PSReadLine command history tracks the commands used in all PowerShell sessions and writes them to a file ($env:APPDATA\Microsoft\PowerShell\PSReadLine\ConsoleHost_history.txt by default). This history since the file is not deleted when the session ends.

Adversaries may run the PowerShell command Clear-History to flush entire command history from a current PowerShell session. This, however, will not delete/flush the ConsoleHost_history.txt file. Adversaries may also delete the Consolehost_history.txt file or edit its contents to hide PowerShell commands they have run.

Example

In this Demo for simplicity I will show this in PowerShell such as Linux has its own history files of what commands have been used, PowerShell has something similar as well Console_History

We can see ithe location of this file with the Get-PSReadLineOption.

Now let's view what History does it have.

Adversaries can delete this file as well or empty it, to remove tracks on what has been done during the attack.

 

[dEEpEst]

File Deletion​

Adversaries may delete files left behind by the actions of their intrusion activity. Malware, tools, or other non-native files dropped or created on a system by an adversary it may leave traces to indicate to what was done within a network and how. Removal of these files can occur during an intrusion, or as part of a post-intrusion process to minimize the adversary's footprint.

There are tools available from the host operating system to perform cleanup, but adversaries may use other tools as well. Examples include native cmd functions such as DEL, secure deletion tools such as Windows Sysinternal Sdelete, or other third-party file deletion tools.

Example:

Sometimes adversaries need to delete their traces, and to remove their tracks, also their payloads so they don't get caught and have Security Engineers grab the payload and Reverse Engineer it, they want to avoid this so they don't create a signature and understand how the payload works.

Sometimes a simple del command you can use to remove the file completely and not have it stay in the Recycle Bin.

We see here that if we delete a file regularly as a normal User with it will move to the Recycle Bin

Sample

And using cmd it will not move to Recycle Bin

Of course this is just a very simple example we can use 3rd party tools to completely remove traces about our payload and can be harder to recover with the use of Forensic tools.

 

[dEEpEst]

Network Share Connection Removal​

Adversaries may remove share connections that are no longer useful in order to clean up traces of their operation. Windows shared drive and Windows Admin Shares connections can be removed when no longer needed. Net is an example utility that can be used to remove network share connections with the net use \system\share /delete command.

Example:

Adversaries can have the use of shares to move files, malware, or lateral move, they can also force authentication to capture hashes.

But in this sample let us see how an Adversary removes a share that contains malware and their Stolen Data.

In this scenario the Adversary gain access to Desktop-Alpha and has a share connected with Desktop-Bravo since this workstation contains all the goods, it is time to disconnect and remove it so that no traces are left back to our malware and sources

We use net to see our shares available in the compromised workstation

And we can see this in our GUI as well

Let's see our share what it has

File Content

Ok we have passwords let us remove the share so nobody else has access to this.

So we have a Z: Drive connected and our goal was to remove this, once successful we no longer see the share connected.