Pentest Red Team Techniques - Defense Evasion

[dEEpEst]

TimeStomping​

Adversaries may modify file time attributes to hide new or changes to existing files. Timestomping is a technique that modifies the timestamps of a file (the modify, access, create, and change times), often to mimic files that have been modified or created by the adversary so that they do not appear conspicuous to forensic investigators or file analysis tools.

Timestomping may be used along with file name Masquerading to hide malware and tools.

 

[dEEpEst]

Hijack Execution Flow​

Adversaries may execute their own malicious payloads by hijacking the way operating systems run programs. Hijacking execution flow can be for the purposes of persistence, since this hijacked execution may reoccur over time. Adversaries may also use these mechanisms to elevate privileges or evade defenses, such as application control or other restrictions on execution.

There are many ways an adversary may hijack the flow of execution, including by manipulating how the operating system locates programs to be executed. How the operating locates libraries to be used by a program can also be intercepted. Locations where the operating system looks for programs/resources, such as file directories and in the case of Windows the Registry, could also be poisoned to include malicious payloads.

 

[dEEpEst]

Path Interception by Unquoted Path​

Adversaries may execute their ow malicious payloads by hijacking vulnerable 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:\unsafe path with pace\program.exe"). (stored in Windows Registry Keys)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 higher privileged process.

Example:

A very popular and well known technique usually some software have very minor but important configurations missing for example Quoting ("") a full path of a file or binary, we are aware that Windows has some folders that contain spaces in them (C:\Program Files\) and these folders or paths without a quote windows sees them as an End Line where that is a termination of a file name, here is the reason why it's necessary to quote the path so windows sees it as a complete path when a space(" ") is in the path name.

It's important to have these quoted paths since windows will not find the assigned file or binary when doing its search when a service is started, in this situation an attacker can take advantage of this and add a malicious payload on a path that come's before the intended one.

A very great tool that I recently have found and its output is very clean is PrivescCheck.

The output is user friendly and it even has an Highlighted section at the end of its run that puts everything tidied up for you so you can find the vulnerability.

Sample:

So let us pay attention to the Unquoted Path Result

Look at this Ccleaner is Unquoted and it’s a Service where the Path is Modifiable but we see that the C:\ Path is WRTIE accessible. But unfortunately as a User we don't have permissions to Start or Restart so what best option do we have, well I wouldn't call these Ethical but we can probably Crash the OS and have a force reboot ONLY if it's not possible to Restart as a User. But here for the sake of Demonstration I will Restart it as the Administrator and have my Payload executed.

 

[dEEpEst]

Service File permissions Weakness​

Adversaries may execute their own malicious payloads by hijacking the binaries used by services. Adversaries may use flaws in the permissions of Windows services to replace the binary that is executed upon service start. These service processes may automatically execute specific binaries as part of their functionality or to perform other actions. If the permissions on the file system directory containing a target binary, or permissions on the binary itself are improperly set, then the target binary may be overwritten with another binary using user-level permissions and executed by the original process. If the original process and thread are running under a higher permissions level, then the replaced binary will also execute under higher-level permissions, which could include SYSTEM.

Adversaries may use this technique to replace legitimate binaries with malicious ones as a means of executing code at a higher permissions level. If the executing process is set to run at a specific time or during a certain event (e.g., system bootup) then this technique can also be used for persistence.

Example:

In this situation a user has PERMISSIONS to designate or modify one of the services run by SYSTEM in this situation we see a normal service already stopped, in this example its Ccleaner, also info on the BinPath that shows where the binary is located in the Windows System.

What if a User has permissions to change this binPath?, simple it can have it point to the malicious payload and when this services is started it will run the malicious payload.

Same Result but a more simpler configuration modification.

 

[dEEpEst]

Path Interception by Search Order Hijacking​

Adversaries may execute their own malicious payloads by hijacking the search order used to load other programs. Because some programs do not call other programs using the full path, adversaries may place their own file in the directory where the calling program is located, causing the operating system to launch their malicious software at the request of the calling program.

Search order hijacking occurs when an adversary abuses the order in which Windows searches for programs that are not given a path. Unlike DLL Search Order hijacking, the search order differs depending on the method that is used to execute the program. However, it is common for Windows to search in the directory of the initiating program before searching through the Windows System directory. An adversary who finds a program vulnerable to search order hijacking(i.e., a program that does not specify the path to an executable) may take advantage of this vulnerability by creating a program named after the improperly specified program and placing it within the initiating program's directory.

For example, "example.exe" runs "cmd.exe" with the command-line argument net user. An adversary may place a program called "net.exe" within the same directory as example.exe, "net.exe" will be run instead of the Windows system utility net. In addition, if an adversary places a program called "net.com" in the same directory as "net.exe", then cmd.exe /C net users will execute "net.com" instead of "net.exe" due to the order of executable extensions defined under PATHEXT.

Search order hijacking is also common practice for hijacking DLL loads.

Example:

So in this example I created a simple C++ example.exe application which calls net.exe and uses the arguments net users.

This application is vulnerable to Search order Hijacking as since the program net.exe is not called with it's full path Windows is Searching for the program in its predetermined order that I have mentioned previously, take a look at the code:

I will execute example.exe in a regular directory where there is no malicious hijacking.

As you can see above the child processes from Example it called net.exe and windows found it in the %SystemRoot% Path.

So what happens when the program is called in a directory where there is a similar program named net.exe but it is actually our malicious payload?.

We can see it found our malicious payload that executes calc.exe and it runs that one instead, since one of the first paths it usually takes before finding it in C:\Windows\System32 is the current working directory.

Calc.exe is executed instead.

 

[dEEpEst]

Path Interception by PATH Environment Variable​

Adversaries may execute their own malicious payloads by hijacking environment variables used to load libraries. Adversaries may place a program in an earlier entry in the list of directories stored in the PATH environment variable, which Windows will then execute when it searches sequentially through that PATH listing in search of the binary that was called form a script or the command line.

The PATH environment variable contains a list of directories. Certain methods of executing a program (namely using cmd.exe or the command-line) rely solely on the PATH environment variable to determine the locations that are searched for a program when the path for the program is not given. If any directories are listed in the PATH environment variable before the Windows directory %SystemRoot%\System32 (e.g.: C:\Windows\System32), a program may be placed in the preceding directory that is named the same as a Windows program (such as cmd, PowerShell, or python), which will be executed when that command is executed from a script or command-line.

For example, if C:\example Path precedes C:\Windows\System32 is in the PATH environment variable, a program that is named net.exe and placed in C:\example Path will be called instead of the Windows system "net" when "net" is executed from the command-line.

Example:

It's possible to abuse the %Path% variable environment variable to elevate privileges as long as the user has permissions to (W) Write and it comes BEFORE C:\Windows\System32.

By using the set path= we can set the path we have control of.

Let us check our PATH variable and see how it looks

Ok so now I will add our malicious payload which in this case it's calc.exe replacing net.exe.

We add our new path and make sure this is before C:\Windows\System32.

Perfect, now I will run net.exe regularly and Calc should prompt instead.

 

[dEEpEst]

Executable Installer File Permissions Weakness​

Adversaries may execute their own malicious payloads by hijacking the binaries used by an installer. These processes may automatically execute specific binaries as part of their functionality or to perform other actions. If the permissions on the file system directory containing a target binary, or permissions on the binary itself, are improperly set, then the target binary may be overwritten with another binary using user-level permissions and executed by the original process. If the original process and thread are running under higher-level permissions, which could include SYSTEM.

Another variation if this technique can be performed by takin advantage of a weakness that is common in executable, self-extracting installers. During the installation process, it is common for installers to use a subdirectory within the %TEMP% directory to unpack binaries such as DLLs, EXEs, or other payloads. When installers create subdirectories and files they often do not set appropriate permissions to restrict write access, which allows for execution of untrusted code placed in the subdirectories or overwriting of binaries used in the installation process. This behavior is related to and may take advantage of DLL Search Order Hijacking.

Adversaries may use this technique to replace legitimate binaries with malicious ones as a means of executing code at a higher permissions level. Some installers may also require elevated privileges that will result in privilege escalation when executing adversary controlled code. This behavior is related to Bypass User Account Control. Several examples of this weakness in existing common installers have been reported to software vendors. If the executing process is set to run at a specific time or during a certain event (e.g., system bootup) then this technique can also be used for persistence.

Example

In this example I will demonstrate a simple install 7z1512.exe I will run Procmon in this situation and see what is going on when my Installer is executed.

I noticed that 7z Installer is looking for a DLL named TextShaping.dll and it is looking for it in the current working directory.

I will take the same approach as previous DLL examples and try to add this DLL with the proper architecture of the program which in this case is 32-bit

We run the installer again but this time we are placing our payload named properly as the DLL that the installer is trying to load, in this case TextShaping

This time no more TextShaping location issues:

And we receive a shell on our attacking machine.

Here I received Administrator Privileges on the machine as only Admins can install new software but of course there are many scenarios where we can actually gain user permissions if the user has specific permissions to install now programs on that machine as well. Remember that proper execution of the installer is not functional anymore and will seem suspicious that we can't install a program. We can take an approach of a Proxy DLL but that is something for another time, I demonstrate that technique in DLL Side Loading

 

[dEEpEst]

DLL Side-Loading​

Adversaries may execute their own malicious payloads by hijacking the library manifest used to load DLLs.

Adversaries may take advantage of vague references in the library manifest of a program by replacing a legitimate library with malicious one, causing the operating system to load their malicious library when it is called for by the victim program.

Program may specify DLLs that are loaded at runtime. Programs that improperly or vaguely specify a required DLL may be open to a vulnerability in which an unintended DLL is loaded. Side-loading vulnerabilities specifically occur when Windows Side-by-Side (WinSxS) manifests are not explicit enough about characteristics of the DLL to be loaded. Adversaries may take advantage of a legitimate program that is vulnerable by replacing the legitimate DLL with a malicious one.

Adversaries likely use this technique as a means of masking actions they perform under a legitimate, trusted system or software process.

Windows, like many operating systems, allows applications to load DLLs at runtime. Applications can specify the location of DLLs to load by specifying the location of DLLs to load by specifying a full path, using DLL redirection, or by using a manifest. If none of these methods are used, Windows attempts to locate the DLL by searching a predefined set of directories in a set of order.

Example:

I will work on the Winamp Program again, this time I won't be replacing any DLL files to load my payload but here I will be tricking the Program into load my DLL payload, usually to achieve this we would need a .manifest file to be modified and to point to our payload but here we will modify a legit DLL and add a "proxy DLL" to execute our payload and send the legitimate calls to the legit DLL as well. So here execution wouldn't even fail!

First we will search for a proper DLL, according to the hints the smaller the better. I will use Procmon again as well and search for a proper file that has a SUCCESS Result.

My victim is the nsutil.dll, usually we want to target files that have user-land access but in these situations most likely you will encounter a situation where Administrator Privileges are required.

Will grab nsutil and place it on the same folder as our payload.dll file and have a work from this awesome tool DLLSideLoader.

Will Import the PS1 Script onto our PowerShell Session and run the following syntax, if everything runs correctly you should see something like this:

Something I had troubles when using this method is I wasn't paying attention to the architecture of the software, I was mainly building my payload for a 64 Bit PC as this was my targeted machine, but in this situation we are targeting the program not the OS.

Will grab all of these files (payloadx86.dll, nsutil.dll and tmp2D86.dll and replace them where our legitimate program is located.

Once winamp is executed the nsutil will call tmp and proxy the execution onto our payloadx86 and move back to the legitimate calls so our program won't crash but we will also receive our reverse shell. (This is a Hit or Miss I managed to get it working sometimes and sometimes it wouldn't even open but will always receive a shell no matter the location of the binary as long as they were in the same location with the files)

Or we can also execute without having all of this replaced they can run in the same folder as long as these files are all together (remember dll hijacking the order it follows)

The same result for both situations.

##################################################################################################

References:

 

[dEEpEst]

DLL Search Order Hijacking​

Adversaries may execute their own malicious payloads by hijacking the search order used to load DLLs. Windows systems use a common method to look for required DLLs to load into a program, Hijacking DLL loads may be for the purpose of establishing persistence as well as elevating privileges and/or evading restrictions on file execution.

There are many ways an adversary can hijack DLL loads. Adversaries may plant trojan dynamic-link library files (DLLs) in a directory that will be searched before the location of a legitimate library that will be requested by a program, causing Windows to load their malicious library when it is called for by the victim program. Adversaries may also perform DLL preloading, also called binary planting attacks, by placing a malicious DLL with the same name as an ambiguously specified DLL in a location that Windows searches before the legitimate DLL. Often this location is the current working directory of the program. Remote DLL preloading attacks occur when a program sets its current directory to a remote location such as a Web share before loading a DLL.

Adversaries may also directly modify the way a program loads DLLs by replacing an existing DLL or modifying a .manifest or .local redirection file, directory, or junction to cause the program to load a different DLL.

If a search order-vulnerable program is configured to run at a higher privilege level, then the adversary-controlled DLL that is loaded will also be executed at the higher level. In this case, the technique could be used for privilege escalation from user to administrator or SYSTEM or from administrator to SYSTEM, depending on the program. Programs that fall victim to path hijacking may appear to behave normally because malicious DLLs may be configured to also load the legitimate DLLs they were meant to replace.

Let us see some examples:

In Windows Environments when an application or a service is starting it looks for a number of DLL's in order to function properly. If these DLL's doesn't exist or are implemented in an insecure way (DLL's are called without using a fully qualified path) then it is possible to escalate privileges by forcing the application to load and execute a malicious DLL File.

It should be noted that when an application needs to load a DLL it will go through the following order:

· The directory which the application is loaded.

· C:\Windows\System32

· C:\Windows\System

· C:\Windows

· The current working directory

· Directories in the system PATH environment variable

· Directories in the user PATH environment variable

A fast way to Hijack and Find any DLL Hijacking is using PowerSploits, Find-PathDLLHijack, Find-ProcessDLLHijack, Invoke-AllChecks. We can check that powersploit will tell us where the hijack is located and what command to use next to hijack the process immediately.

We will work with Administrator Privileges in this example, not completely necessary if you can find a user with misconfiguration permission where they are allowed to WRITE, crazy right!!?, who would do that!!?

Procmon

For this technique I will use Procmon, as this is a great toll to view what a program is loading at run time, there are also other great tools from PowerSploit that will verify this Vulnerability, other tools such as SharpUp from GhostPack it is a tool written in C#.

Our Process in this sample is Winamp.

Winamp is a media player for Microsoft Windows it was a very popular and widely used media player back in the early 2000's, in the version we are currently working on it contains a DLL Hijack vulnerability as it is trying to load many different DLL files inexistent in its current directory, we can verify this with Procmon.

Wow, many potential hijacks, so our next step is to choose a DLL we wish to hijack, I will use the DLL . I will use a DLL this time to receive a reverse shell. My focus will be on vcruntime140d.dll

What happens when the program cannot find the DLL, it start following an order to locate the DLL

Let us take a look and see what happens if I rename it, how will the order continue.

Now I will add this DLL to any of the other paths that are seen above see if it loads it and gives me a shell.

Once added:

We can simply start the process and check the results

And this time it did find it.

References:

 

[dEEpEst]

Hide Artifacts​

Adversaries may attempt to hide artifacts associated with their behaviors to evade detection. Operating systems may have features to hide various artifacts, such as important system files and administrative task execution, to avoid disrupting user work environments and prevent users from changing files or features on the system. Adversaries may abuse these features to hide artifacts such as files, directories, user accounts, or other system activity to evade detection.

Adversaries may also attempt to hide artifacts associated with malicious behavior by creating computing regions that are isolated from common security instrumentation, such as through the use of virtualization technology.

 

[dEEpEst]

VBA Stomping​

Adversaries may hide malicious Visual Basic Applications (VBA) payloads embedded within MS Office documents by replacing the VBA source code with benign data.

MS Office documents with embedded VBA Content store source code inside of module streams. Each module stream has a PerformanceCache that stores a separate compiled version of the VBA source code known as p-code. The p-code is executed when the MS Office version specified in the _VBA_PROJECT stream (which contains the version-dependent description of the VBA project) matches the version of the host MS Office application.

An adversary may hide malicious VBA code by overwriting the VBA source code location with zero's, benign code, or random bytes while leaving the previously compiled malicious p-code. Tools that scan for malicious VBA source code may be bypassed as the unwanted code is hidden in the compiled p-code. If the VBA source code is removed, some tools might even think that there are no macros present. If there is a version match between the _VBA_PROJECT stream and host MS Office application, the p-code will be executed, otherwise the benign VBA source code will be decompressed and recompiled to p-code, thus removing malicious p-code and potentially bypassing dynamic analysis.

VBA Macros Advanced

Evil Clippy

Evil Clippy a tool released in BlackHat Asia in 2019 it is a a maldoc assistant which help's red teams to bypass popular AV and get an initial foothold, in this category we will focus on the VBA Stomping technique. Discovered years ago by Dr. Vesselin Bontchev (

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

). At a high level explanation of this attack by creating a malicious document we can actually add a non-malicious macro into the source code of the file, as explained by Dr. Bontchev what actually executes is the p-code stored in the document as long as it's compatible with the current VBA version.

Let's work with some samples a Non-malicious Macro is created. A message box is to be displayed when the document is opened.

Now from here we want to modify the VBA source code utilized while leaving the p-code unchanged. To edit this file you will unzip it and edit the vbaProject.bin file using a hex editor, but only withing the VBA source code storage location, not the p-code section.

Now that the VBA source code has been manually edited we will open the document and inspect the VBA Code BEFORE the "Enable Content" button is clicked.

We see here that the source-code still displays XYZ but in fact once the content is enabled we see a message box displaying "ABC"

Well what happened here?. Our source code stated that XYZ was going to be executed but instead ABC was displayed and later on our Code updated to match the execution.

References:

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

 

[dEEpEst]

Run Virtual Instance​

Adversaries may carry out malicious operations using a virtual instance to avoid detection. A wide variety of virtualization technologies exist that allow for the emulation of a computer or computing environment. By running malicious code indie of a virtual instance, adversaries can hide artifacts associated with their behavior from security tools that are unable to monitor activity inside the virtual instance. Additionally, depending on the virtual networking implementation (ex: bridged adapter), network traffic generated by the virtual instance can be difficult to trace back to the compromised host as the IP address and hostname might not match known values.

Adversaries may utilize native support for virtualization (ex: Hyper-V) or drop the necessary files to run a virtual instance (ex: VirtualBox binaries). After running a virtual instance, adversaries may create a shared folder between the guest and host with permissions that enable the virtual instance to interact with the host file system.

I have zero idea how to replicate this here is a reference

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

 

[dEEpEst]

NTFS File Attributes​

Adversaries may use NTFS file attributes to hide their malicious data in order to evade detection. Every New Technology File System (NTFS) formatted partition contains a Master File Table (MFT) that maintains a record for every file/directory on the partition. Within MFT entries are file attributes, such as Extended Attributes (EA) and Data [known as Alternate Data Streams (ADSs) when more than one Data attribute is present], that can be used to store arbitrary data (and even complete files).

Adversaries may store malicious data or binaries in the file attribute metadata instead of directly in files. This may be done to evade some defenses, such as static indicator scanning tools and anti-virus.

Example:

Alternate Data Stream is an Artifact of New Technology File Systems (NTFS) which was introduced by Windows. Attackers introduced a method where they managed to hide payloads, malware, keyloggers and have them execute without the knowledge of the users.

A file can have more than one Alternate Data Stream for the various purpose to hold metadata of the file. When you append an ADS File with a default stream file, there will be no change made to the size or the function of the file.

Here, we are making use of .txt file as our primary stream to demonstrate ADS, you can use any file of your preference.

We create a file and add content.

To display The contents in the folder including Alternate Data Stream we use dir /r

]

In the above image, you can see that there is no hidden file displayed, and on the GUI you see that there is only 1 file.

Here we will proceed with creating a hidden file. A .txt file is created with hidden ADS and to add content in the file we can use the command:

echo Hello World, Again!! > Hello-World.txt:hidden

To display contents I used the previous commands.

But to no luck, here you see that the file is not recognized, therefore, to see hidden content you can use the more command.

And to view the DataStream we check it again with the dir /r command.

You can also open this file with notepad and the contents will be displayed as well. For more information and even with the use of PowerShell here are some references.

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

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

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

 

[dEEpEst]

Hidden Window​

Adversaries may use hidden windows to conceal malicious activity from the plain sight of users. In some cases, windows that would typically be displayed when an application carries out an operation can be hidden. This may be utilized by system administrators to avoid disrupting user work environments when carrying out administrative tasks.

On Windows, there are a variety of features in scripting languages in Windows, such as PowerShell, Jscript, and Visual Basic to make windows hidden. One example of this is powershell.exe -WindowStyle Hidden.

Similarly, on macOS the configurations for how applications run are listed in property list (plist) files. One the tags in these files can be apple.awt.UIElement, which allows for Java applications to prevent the application's icon from appearing in the Dock. A common use for this is when applications run in the system tray, but don't also want to show up in the Dock.

Adversaries may abuse these functionalities to hide otherwise visible windows from users so as not to alert the user to adversary activity on the system.

Example:

Just for this demonstration purposes I will use PowerShell as it is very easy to abuse this features and have it execute a payload with a Hidden Window

Demo:

 

[dEEpEst]

Hidden Files and Directories​

Adversaries may set files and directories to be hidden to evade detection mechanisms. To prevent normal users from accidentally changing special files on a system, most operating systems have the concept of a "hidden" file. These files don't show up when a user browses the file system with a GUI or when using normal commands on the command line. Users must explicitly ask to show the hidden files either via a series of Graphical User Interface (GUI) prompts or with command line switches (dir /a for Windows and ls -a for Linux and macOS).

On Linux and Mac, users can mark specific files as hidden simply by putting a "." as the first character in the file or folder name. Files and folders that start with a period, '.' are by default hidden from being viewed in the Finder application and standard command-line utilities like "ls". Users must specifically change settings to have these files viewable.

Files on macOS can also be marked with the UF_HIDDEN FLAG which prevents them from being seen in Finder.app but still allows them to be seen in Terminal.app. On Windows, users can mark specific files as hidden by using the attrib.exe binary. Many applications create these hidden files and folders to store information so that it doesn't clutter up the user's workspace. For example, SSH utilities create a .ssh folder that's hidden and contains the user's known hosts and keys.

Adversaries can use this to their advantage to hide files and folders anywhere on the system and evading a typical user or system analysis that does not incorporate investigation of hidden files.

Example:

here we will hide some folders to avoid detection, since these folders by default are not commonly viewable in the GUI unless activated, or not even in the command-line or PowerShell unless intended.

I will hide a folder named Payloads in this example which has my payload to connect back to my attacking machine.

Here we can see it is perfectly viewable.

Now let's hide it.

The great thing about this is that as long as you have the correct permissions on a folder then you can hide it, same goes for a file.

If I search it with cmd it won't show as well.

Unless I intend to search it with the "/a" flag

 

[dEEpEst]

File Directory Permissions Modification​

Adversaries may modify file or directory permissions/attributes to evade access control lists (ACLs) and access protected files. File and directory permissions are commonly managed by ACLs configured by the file or directory owner, or users with the appropriate permissions. File and directory ACL implementations vary by platform, but generally explicitly designate which users or groups can perform which actions (read, write, execute, etc.).

Modifications may include changing specific access rights, which may require ownership of a file or directory and/or elevated permissions depending on the file or directory's existing permissions. This may enable malicious activity such as modifying, replacing, or deleting specific files or directories. Specific file and directory modifications may be required a required step for many techniques, such as establishing Persistence via Accessibility Features, Boot or Logon initialization Scripts, .bash_profile and .bashrc, or tainting/hijacking other instrumental binary/configuration files vie Hijack Execution Flow.

 

[dEEpEst]

Windows File and Directory Permissions Modification​

Adversaries may modify file or directory permissions/attributes to evade access control lists (ACLs) and access protected files. File and directory permissions are commonly managed by ACLs configured by the file or directory owner, or users with the appropriate permissions. File and directory ACL implementations vary by platform, but generally explicitly designate which users or groups can perform which actions (read, write, execute, etc.).

Windows implements file and directory ACLs as Discretionary Access Control Lists (DACLs). Similar to a standard ACL, DACLs identifies the accounts that are allowed or denied access to a securable object. When an attempt is made to access a securable object, the system checks the access control entries in the DACL in order. If a matching entry is found, access to the object is granted. Otherwise, access is denied.

Adversaries can interact with the DACLs using built-in Windows commands, such as icacls, cacls, takeown, and attrib, which can grant adversaries higher permissions on specific files and folders. Further, PowerShell provides cmdlets that can be used to retrieve or modify file and directory DACLs. Specific file and directory modifications may be a required step for many techniques, such as establishing Persistence via Accessibility Features, Boot or Logon Initialization Scripts, or tainting/hijacking other instrumental binary/configuration files via Hijack Execution Flow.

Example:

Some great examples on Permissions modifications we encounter in some assessments. Let's check the following example.

We have a "Permissions" folder that our current user dwinchester has no permissions in.

No permissions to view as well.

So here we can use these tools icacls, cacls, takeown and attrib just to not exaggerate on the tools I will demonstrate how an adversary can gain permission once someone has elevated privileges or is the correct user.

I have DENY permission even with a Local Administrator Account so I will take some steps to change the user permissions.

Takeown

Icacls

Then we finally have managed to give ourselves and user the permissions necessary to modify the folder.

A simple demonstration on how we can modify folder permissions as mentioned previously we can use this technique for various other techniques. Persistence, Defense Evasion, hijack Execution Flow and others.

 

[dEEpEst]

Execution Guardrails​

Adversaries may use execution guardrails to constrain execution or actions based on adversary supplied and environment specific conditions that are expected to be present on the target. Guardrails ensure that a payload only executes against and intended target and reduces collateral damage from an adversary campaign. Values an adversary can provide about a target system or environment to use as guardrails may include specific network share names, attached physical devices, files, joined Active Directory (AD) domains, and local/internal IP addresses.

Guardrails can be used to prevent exposure of capabilities in environments that are not intended to be compromised or operated within. This use of guardrails is distinct from typical Virtualization/Sandbox Evasion. While use of Virtualization/Sandbox Evasion may involve checking for known sandbox values and continuing with execution only if there is no match, the use of guardrails will involve checking for an expected target-specific value only continuing with execution if there is such a match.

 

[dEEpEst]

Environmental Keyring​

Adversaries may environmentally key payloads or other features of malware to evade defenses and constraint execution to a specific target environment. Environmental keyring uses cryptography to constrain execution or actions based on adversary supplied environment specific conditions that are expected to be present on the target. Environmental keyring is an implementation of Execution Guardrails that utilizes cryptographic techniques for deriving encryption/decryption keys from specific types of values in a given computing environment.

Values can be derived from target specific elements and used to generate a decryption key for an encrypted payload. Target-specific values can be derived from specific network shares, physical devices, software/software versions, files, joined AD domains, system time, and local/external IP addresses. By generating the decryption keys from target-specific environmental values, environmental keyring can make sandbox detection, anti-virus detection, crowdsourcing of information, reverse engineering difficult. These difficulties can slow down the incident response process and help adversaries hide their tactics, techniques and procedures (TTPs).

Similar to Obfuscated Files or information, adversaries may use environmental keyring to help protect their TTPs evade detection. Environmental keyring may be used to deliver an encrypted payload to the target that will use target-specific values to decrypt the payload before execution. By utilizing target-specific values to decrypt the payload that adversary con avoid packaging the decryption key with the payload or sending it over a potentially monitored network connection. Depending on the technique for gathering target-specific values, reverse engineering of the encrypted payload can be exceptionally difficult. This can be used to prevent exposure of capabilities in environments that are not intended to be compromised or operated within.

Like Execution Guardrails, environmental keyring can be used to prevent exposure of capabilities in environments that are not intended to be compromised or operated within. This activity is distinct from typical Virtualization/Sandbox Evasion. While used of Virtualization/Sandbox Evasion may involve checking for an expected target-specific value that must match for decryption and subsequent execution to be successful.

Example:

This is the most simple and basic example I managed to write since my programming or cryptographic skills barely leave the floor.

First I will create a payload and edit my configuration to use an environmental variable (DESKTOP-ALPHA) which would be the computer name of my target and it's Domain name DC(DominionCyber) to encrypt a payload using these 2 as keys. Once these 2 are found in the system the payload will decrypt and execute.

Will compile the payload and configuration using the Ebowla Tool.

Now I will follow the instructions to compile my payload as this tool contains 3 methods PowerShell, Python and GO.

Now for execution and see what it does for the payload to work. We can see in the output that the payload has a KEY and will find this key strings on our target environment if found it will use these to decrypt and execute with our reverse shell.

Found successfully on our attacking machine a successful shell connected back to us. This was successful since the variables in the target machine match our keys.

And you can see here that the hashes match for a successful decryption as well in here:

Shell

Here is a great resource and understanding on how it would work properly.

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

 

[dEEpEst]

BITS Jobs​

Adversaries may abuse BITS jobs persistently execute or clean up after malicious payloads. Windows Background Intelligent Transfer Service (BITS) is a low-bandwidth, asynchronous file transfer mechanism exposed through Component Object Model (COM). BITS is commonly used by updates, messengers, and other applications preferred to operate in the background (using available idle bandwidth) without interrupting other networked applications. File transfer tasks are implemented as BITS jobs, which contain a queue of one or more file operations.

The interface to create and manage BITS jobs is accessible through PowerShell and the BITSAdmin tool.

Adversaries may abuse BITS to download, execute and even clean up after running malicious code. BITS tasks are self-contained in the BITS job database, without new files or registry modifications, and often permitted by host firewalls. BITS enabled execution may also enable persistence by creating long-standing jobs (the default maximum lifetime is 90 days and extendable) or invoking an arbitrary program when a job completes or errors (including after system reboots).

BITS upload functionalities can also be used to perform Exfiltration Over Alternative Protocol.

In the following example I will create a simple bitsadmin job with user Privileges this will start a calc process to execute.

First we use the /create option to create our job

We will attach a file as well:

A file needs to be created for the job to function properly.

Then we will use the SetNotifyCmdLine Parameter this will set a program to execute for notification, and can optionally take parameters. These options can also be NULL.

Too much of an extra step but we will call cmd to start a calc process on our job

Demo:

References:

LOLBAS