Pentest Red Team Techniques - Privilege Escalation

[dEEpEst]

Privilege Escalation​

The adversary is trying to gain higher-level permissions.

Privilege Escalation consists of techniques that adversaries use to gain higher-level permissions on a system or network. Adversaries can often enter and explore a network with unprivileged access but require elevated permissions to follow through on their objectives. Common approaches are to take advantage of system weaknesses, misconfigurations, and vulnerabilities. Examples of elevated access include:

· SYSTEM/root level

· Local Administrator

· User Account with admin-like access to specific system or perform specific function.

These techniques often overlap with Persistence Techniques, as OS features that let an adversary persist can execute in an elevated context.

 

[dEEpEst]

Event Triggered Execution​

Adversaries may establish persistence and/or elevate privileges using system mechanisms that trigger execution based on specific events. Various operating systems have means to monitor user activity such as running specific applications/binaries.

Adversaries may abuse these mechanisms as a means of maintaining persistent access to a victim via repeatedly executing malicious code. After gaining access to a victim system, adversaries may create/modify event triggers to point to malicious content that will be executed whenever the event trigger is invoked.

Since the execution can be proxied by an account with higher permissions, such as SYSTEM or service accounts, an adversary may be able to abuse these triggered execution mechanisms to escalate their privileges.

 

[dEEpEst]

PowerShell Profile​

Adversaries may gain persistence and elevate privileges by executing malicious content triggered by PowerShell profiles. A PowerShell profile (profile.ps1) is a script that runs when PowerShell starts and can be used as a logon script to customize user environments.

PowerShell supports several profiles depending on the user or host program. For example, there can be different profiles for PowerShell host programs such as the PowerShell console, PowerShell ISE or Visual Studio Code. An administrator can also configure a profile that applies to all users and host programs on the local computer.

Adversaries may modify these profiles to include arbitrary commands, functions, modules and/or PowerShell drives to gain persistence. Every time a user opens a PowerShell sessions the modified script will be executed unless the -NoProfile flag is used when it is launched.

An adversary may also be able to escalate privileges if a script in a PowerShell profile is loaded and executed by an account with higher privileges, such as a domain administrator.

Example:

PowerShell Profile is a PowerShell script which you can customize to your environment and add session specific elements to every PowerShell session that you Start.

It's a script that runs when PowerShell starts. You can use profiles as a logon script to customize the environment. You can add Commands, Functions, Aliases, Modules, etc.

PowerShell supports several profile files. Also, PowerShell host programs can support their own host-specific profiles.

A few Samples:

The PowerShell profile script is stored in the folder “WindowsPowerShel” which is by default is hidden from the user. If a payload has been dropped into disk the “Start-Process” cmdlet can be used to point to the location of the Executable. The “Test-Path” determines if a profile exists for the current user. If the profile doesn’t exist the Command “New-Item -Path $Profile -Type File -Force” will create a profile for the current users and the “Out-File” will rewrite the profile.

First let’s create a Profile:

Then I will add the command I want to be executed when a New PowerShell Session is initiated.

Now every New PowerShell will run my Executable Command and connect back to my Attacking Machine.

Runs every Second

These are just a few demonstrations that I wanted to share they are simple and very easy to follow, If you would love to go more into Detail please do check out the MITRE Framework as it’s a great guide to understand and check out various techniques used by APT’s.

 

[dEEpEst]

Component Object Model Hijacking​

Adversaries may establish persistence by executing malicious content triggered by hijacked references to Component Object Model (COM) objects. COM is a system within Windows to enable interaction between software components through the operating system. References to various COM objects are stored in the Registry.

Adversaries can use the COM system to insert malicious code that can be executed in place of legitimate software through hijacking the COM references and relationships as a means for persistence. Hijacking a COM object requires a change in the Registry to replace a reference to a legitimate system component which may cause that component to not work when executed. When that system component is executed through normal system operations the adversary's code will be executed instead. An adversary is likely to hijack objects that are used frequently enough to maintain a consistent level of persistence, but are unlikely to break noticeable functionality within the system as to avoid system instability that could lead to detection.

Example:

For this example I will search for instances of applications trying to load objects that don't exist.

Process Monitor is a great tool to search for these objects it's part of the Sysinternals Suite and it shows everything in real time. When running procmon we will apply a filter since it gets bloated with a ton of information that in this case won't be necessary, so what we are looking for here is:

· Result is NAME NOT FOUND

· Operations is RegOpenKey

· Path ends with InprocServer32

In a few minutes I get a ton of results, since this is a Clean VM almost everything is from Explorer and Firefox mainly:

One of the things I noticed is probably the times it is being called, In my testing I went for Explorer since it is being called plenty of times in a matter of seconds but It usually failed, I have no idea why, (Please do explain if you know @dmcxblue).

From here create a Simple DLL Project from Visual Studio and have it open a MessageBox, I wrote "Hello hacker", it will need 3 arguments so just use NULL on the other 2 and your last being Hello hacker message.

Once we have our DLL built we will transfer it to the host machine and register it to the proper CLSID but we are assuming here that we have a terminal and not a GUI Desktop so for this simple demo we will.

We will locate the CLSID that we are currently aiming to Hijack and we will change the location of the DLL that it is currently trying to load:

Once we find ti and replace this, we will wait for a while (10 min in my occasion) and we will get greeted with a message (we are trying to gain persistence as an Administrator, but in this Demo I reached for a user level persistence)

Tip: We can also use Powershell

New-Item -Path "HKU:\S-1-5-21-214746808-1661000321-346206657-1108_Classes\Wow6432Node\CLSID\" -Name "{F1C46D71-B791-4110-8D5C-7108F22C1010}"

New-Item -Path "HKU:\S-1-5-21-214746808-1661000321-346206657-1108_Classes\Wow6432Node\CLSID\{F1C46D71-B791-4110-8D5C-7108F22C1010}" -Name "InprocServer32" -Value "C:\Temp\HelloHacker.dll"

New-ItemProperty -Path "HKU:\S-1-5-21-214746808-1661000321-346206657-1108_Classes\Wow6432Node\CLSID\{F1C46D71-B791-4110-8D5C-7108F22C1010}\InprocServer32" -Name "ThreadingModel" -Value "Both"

References:

 

[dEEpEst]

Application Shimming​

Adversaries may establish persistence and/or elevate privileges by executing malicious content triggered by application shims. The Microsoft Windows Application Compatibility Infrastructure/Framework (Application Shim) was created to allow for backward compatibility of software as the operating system codebase changes over time. For example, the application shimming features allows developers to apply fixes to applications (without rewriting code) that were created for Windows XP so that it will work with Windows 10.

Within the framework, shims are created to act as a buffer between the program ( or more specifically, the Import Address Table) and the Windows OS. When a program is executed, the shim cache is referenced to determine if the program requires the use of the shim database (.sdb). If so, the shim database uses hooking to redirect the code as necessary in order to communicate with the OS.

A list of all shims currently installed by the default Windows Installer (sdbinst.exe) is kept in:

· %WINDIR%\AppPatch\sysmain.sdb and

· hklm\software\microsoft\windows nt\currentversion\appcompatflags\installedsdb

Custom databases are stored in:

· %WINDIR%\AppPatch\custom & %WINDIR%\AppPatch\AppPatch64\Custom and

· hklm\software\microsoft\windows nt\currentversion\appcompatflags\custom

To keep shims secure, Windows designed them to run in user mode so they cannot modify the kernel and you must have administrator privileges to install a shim. However, certain shims can be used to bypass User Account Control (UAC and RedirectEXE), injects DLLs into processes (InjectDLL), disable Data Execution Prevention (DisableNX) and Structure Exception Handling (DisableSEH), and intercept memory addresses (GetProcAddress).

Utilizing these shims may allow an adversary to perform several malicious acts such as elevate privileges, install backdoors, disable defenses like Windows Defender, etc. Shims can also be abused to establish persistence by continuously being invoked by affected programs.

 

[dEEpEst]

Accessibility Features​

Adversaries may establish persistence and/or elevate privileges by executing malicious content triggered by accessibility features. Windows contains accessibility features that may be launched with a key combination before a user has logged in (ex: when the user is on the Windows logon screen). An adversary can modify the way these programs are launched to get a command prompt or backdoor without logging in to the system.

Two common accessibility programs are C:\Windows\System32\sethc.exe, launched when the shift key is pressed five times and C:\Windows\System32\utilman.exe, launched when the Windows + U key combination is pressed.

The sethc.exe program is often referred to as "sticky keys", and has been used by adversaries for unauthenticated access through a remote desktop login screen.

Depending on the version of Windows, an adversary may take advantage of these features in different ways. Common methods used by adversaries include replacing accessibility feature binaries or pointers/references to these binaries in the Registry. In newer versions of Windows, the replaced binary needs to be digitally signed for x64 systems, the binary must reside in %systemdir%\, and it must be protected by Windows File or Resource Protection (WFP/WRP). The Image File Execution Option Injection debugger method was likely discovered as a potential workaround because it does not require the corresponding accessibility feature binary to be replaced.

For simple binary replacement on Windows XP and later as well as Windows Server 2003/R2 and later, for example, the program (e.g:C:\Windows\System32\utilman.exe) may be replaced with "cmd.exe" (or another program that provides backdoor access). Subsequently, pressing the appropriate key combination at the login screen while sitting at the keyboard or when connected over Remote Desktop Protocol will cause the replaced file to be executed with SYSTEM privileges.

Other accessibility features exist that may also be leveraged in a similar fashion:

· On-Screen Keyboard: C:\Windows\System32\osk.exe

· Magnifier: C:\Windows\System32\Magnify.exe

· Narrator: C:\Windows\System32\Narrator.exe

· Display Switcher: C:\Windows\System32\DisplaySwitch.exe

· App Switcher: C:\Windows\System32\AtBroker.exe

Example:

Note: Now in the newer Windows 10 some come with a Trusted Installer Group from the start, mostly on Enterprise Version it's a security feature not even SYSTEM has access the only approach I found was the takeover utility

We find the Accessibility Feature we are trying to abuse for our persistence in this sample OSK(On-Screen Keyboard)

We demonstrated where this Accessibility Feature is located we can also use more easier ones such as Utilman.exe this executable has a shortcut of Windows + U

What happens when we replace the binary with a cmd.exe binary and use the Shortcut?

Windows + U

 

[dEEpEst]

Screensaver​

Adversaries may establish persistence by executing malicious content triggered by user inactivity. Screensavers are programs that execute after a configurable time of user inactivity and consist of Portable Executable (PE) files with a .scr extension. The Windows screensaver application scrnsave.scr is located in C:\Windows\System32\, and C:\Windows\sysWOW64\ on 64-bit Windows systems, along with screensavers included with base Windows installations.

The following screensaver settings are stored in the Registry (HKCU\Control Panel\Desktop\) and could be manipulated to achieve persistence:

· SCRNSAVE.exe - set to malicious PE path

· ScreenSaveActive - set to '1' to enable the screensaver

· ScreenSaverIsSecure - set to '0' to not require a password to unlock

· ScreenSaveTimeout - sets user inactivity timeout before screensaver is executed

Adversaries can use screensaver settings to maintain persistence by setting the screensaver to run malware after a certain timeframe of user inactivity.

In this example we will establish persistence with the use of our Screen Saver the current path for the current Screen Saver that is loaded depending on the idle time (1 minute here) will be loaded when the user is inactive during that certain amount of time.

We can see the current value of the Key to what screensaver it is pointing to, if you notice it is using the .scr extension no worries this is just another form of executable so changing the extension name of your payload will work fine as well.

We can vie other key values as well:

Screensaver is Active

Screensavers Timeout (usually this is in seconds)

SCRNSAVE.EXE - The binary it is loading when the idle time has been reached

All that we wish to accomplish in this situation is have the screensaver point to our payload. We do not need Administrator privileges in this matter as any user can setup their own screensaver as they would like.

We wait for the 60 seconds (1 min) to pass an we should receive a shell back to our attacking machine.

Demo:

 

[dEEpEst]

Default File Association​

Adversaries may establish persistence by executing malicious content triggered by a file type association. When a file is opened, the default program used to open the file (also called the file association or handler) is checked. File association selections are stored in the Windows Registry and can be edited by users, administrators, or programs that have Registry access or by administrators using built-in assoc utility. Applications can modify the file association for a given file extension to call an arbitrary program when a file with the given extension is opened.

System file associations are listed under HKEY_CLASSES_ROOT.[extension], for example HKEY_CLASSES_ROOT.txt. The entries point to a handler for that extension located at HKEY_CLASSES_ROOT[handler]. The various commands are then listed as subkeys underneath the shell key at HKEY_CLASSES_ROOT[handler]\shell[action]\command. For example: HKEY_CLASSES_ROOT\txtfile\shell\open\command HKEY_CLASSES_ROOT\txtfile\shell\print\command* HKEY_CLASSES_ROOT\txtfile\shell\printto\command

The values of the keys listed are commands that are executed when the handler opens the file extension. Adversaries can modify these values to continually execute arbitrary commands.

Example:

On Windows, extensions that are known by the operating system are defined in the registry. For example we have a txt file.

Below we see the one responsible for opening a text file.

Each of these extensions may be connected to some handler, that is also defined in the registry in this case we know .txt are handled by notepad.

In this section the important one we want to know about is the command option:

We can see that notepad runs with parameters one of them being (%1) is the name of the file that was clicked. Thanks to this notepad opens the clicked file.

We can replace the value to point it to our payload and gain a shell. But we also don't want to mess with the proper functionality of the execution so we will create a small batch script which calls our payload and the proper program to open the extension. This should be the final settings for the hijack.

Then we open regular txt file and check our shell connection.

We have to be lucky and the file note have a (" ") space on the name or this will be taking as 2 different files to be opened

Demo:

 

[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]

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 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]

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]

Create or Modify System Process​

Adversaries may create or modify system-level processes to repeatedly execute malicious payloads as part of persistence. When operating systems boot up, they can start processes that perform background system functions. On Windows and Linux, these system processes are referred to as services. On macOS, launchd processes known as Launch Daemon and Launch Agent are run to finish system initialization and load user specific parameters.

Adversaries may install new services, daemons, or agents that can be configured to execute at startup or a repeatable interval in order to establish persistence. Similarly, adversaries may modify existing services, daemons, or agents to achieve the same effect.

Services, daemons, or agents may be created with administrator privileges but executed under root/SYSTEM privileges. Adversaries may leverage this functionality to create or modify system processes in order to escalate privileges.

 

[dEEpEst]

Windows Services​

Adversaries may create or modify Windows services to repeatedly execute malicious payloads as part of persistence. When Windows boots up, it start programs or applications called services that perform background system functions. Windows service configuration information, including the file path to the service's executable or recovery programs/commands, is stored in Windows Registry. Service configurations can be modified using utilities such as sc.exe and Reg.

Adversaries may install a new service or modify an existing service by using system utilities to interact with services, by directly modifying the Registry, or by using custom tools to interact with the Windows API. Adversaries may configure services to execute at startup in order to persist on a system.

An adversary may also incorporate Masquerading by using a service name from a related operating system or benign software, or by modifying existing services to make detection analysis more challenging. Modifying existing services may interrupt their functionality or may enable services that are disabled or otherwise not commonly used.

Services may be created with administrator privileges but are executed under SYSTEM privileges, so an adversary may also use a service to escalate privileges from administrator to SYSTEM. Adversaries may also directly start services through Service Execution.

Example::

In this situation I will create a New Service to achieve persistence we can only continue here with Administrator Privileges as mentioned previously we will create a Service with Administrator but these services get executed as SYSTEM.

Here is a sample on what happens when working with user permissions:

Now let's create it with Administrator Privileges the parameters are easy to follow:

Let us check our Service

Currently stopped now we will start our service and check our shell back with SYSTEM privileges

Shell:

 

[dEEpEst]

Boot or Logon AutoStart Execution​

Adversaries may configure system settings to automatically execute a program during system boot or logon to maintain persistence or gain a higher-level privileges on compromised systems. Operating systems may have a mechanism for automatically running a program on system boot or account logon. These mechanisms may include automatically executing programs that are place in specially designated directories or are referenced by repositories that store configuration information, such as the Windows Registry. And adversary may achieve the same goal by modifying or extending features of the kernel.

Since some boot or logon AutoStart programs run with higher privileges, an adversary may leverage these elevated privileges.

 

[dEEpEst]

Winlogon Helper DLL​

Adversaries may abuse features of Winlogon to execute DLLs and/or executables when a user logs in. Winlogon.exe is a Windows component responsible for actions at logon/logoff as well as the secure attention sequence (SAS) triggered by Ctrl-Alt-Delete. Registry entries in HKLM\Software{\Wow6432Node\}Microsoft\Windows NT\CurrentVersion\Winlogon and HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon are used to manage additional helper programs and functionalities that support Winlogon.

Malicious modifications to these Registry keys may cause Winlogon to load and execute malicious DLLs and/or executables. Specifically, the following subkeys have been known to be possibly vulnerable to abuse:

· Winlogon\Notify - points to notification package DLLs that handle Winlogon events

· Winlogon\Userinit - points to userinit.exe, the user initialization program executed when a user logs on

· Winlogon\Shell - points to explorer.exe, the system shell executed when a user logs on

Adversaries may take advantage of these features to repeatedly execute malicious code and establish persistence.

Example:

As mentioned this component handles what is going on during logon and logoff times so this payload needs to be dropped onto the System23 folder, in this way we can load the legitimate binary and our payload and the same time.

The registry key that we will focus in this situation is the UserInit. We will need Administrator privileges for this technique to work properly.


Machine generated alternative text:Administrator: Command Prompt Microsoft windows [Version 18.8.19842.638] (c) 2828 microsoft Corporation. All rights reserved . C: \Windows\system32>reg add NT\CurrentVersion\Win10gon" 'v Userinit 'd "Userinit .exe, payloadx64.exe" If
We can also apply the same technique to the Shell Registry and we can also reach the same goal when a user logs in we will receive a shell.

From here we can simply lock the screen of the target workstation and wait for the user to log back onto the machine.

Logoff:

Sign-in:

Shel:

We have 2 registry keys that we can modify and reach our goal of persistence but we also have a 3rd one Notify Key:

The “Notify” registry key is typically found in older operating systems (prior to Windows 7) and it points to a notification package DLL file which handles Winlogon events. Replacing DLL entries under this registry key with an arbitrary DLL will cause Windows to execute it during logon.

As we can see both of our methods will work correctly and will execute on logon we just have to remember that these binary's need to be dropped on the System32 folder so that both the legitimate and the payload gets executed.

References:

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