Lateral Movement in AD

Lateral Movement

Lateral Movement is a tactic that aims at gaining further access within a target network. Lateral Movement techniques may use the current valid account or reuse authentication material such as password hashes, Kerberos itckets, and application access tokens obtained from previous attack stages.

WMI For Lateral Movement

The Windows Management Intrumentation (WMI) is an object-oriented feature that facilitates task automation.

WMI is capable of creating processes via the Create method from the Win32_Process class. It communicates through Remote Procedure Calls (RPC) over port 135 for remote access and uses a higher-range port (19152-65535) for session data.

Creating a WMI Process

To create a process on a remote target via WMI, it requires the credentials of a member of the Administrators local group, which could also be a domain user.

Using wmic

C:\Users\jeff>wmic /node:192.168.50.73 /user:jen /password:Nexus123! process call create "calc"
Executing (Win32_Process)->Create()
Method execution successful.
Out Parameters:
instance of __PARAMETERS
{
        ProcessId = 752;
        ReturnValue = 0;
};

The WMI job will return the PIC of the newly created process and return a value of "0" meaning that the process has been created successfully.

Using PowerShell

In order to start a WMI Process with PowerShell, we first will need to create a PSCredential object that will store session username and password. In the example below, our PSCredential will be stored in the variable $secureString

Once we have a PSCredential object, we will create a Common Information Model (CIM) using the New-CimSession cmdlet.

Now we can use the Invoke-CimMethod cmdlet to create the process.

Obtaining a Reverse Shell With WMI

Python script to base64 encode a PowerShell reverse shell

Next, set up a listener on the attack machine and run the PowerShell WMI script on the target machine.

WinRM For Lateral Movement

WinRM is the Microsoft version of the WS-Management protocol and it exchanges XML messages over HTTP and HTTPS. It uses TCP port 5986 for encrypted HTTPS traffic and port 5985 for plain HTTP.

In addition to its PowerShell implementation, WimRM is implemented in several built-in utilities such as winrs (Windows Remote Shell).

For WinRS to work, the domain user needs to be a member of the Administrators or Remote Management Users group on the target host.

WinRS

The winrs utility can be invoked by specifying the target host through the -r: argument and the username with -u: and password with -p. We can then specify the commands to be executed on the remote host.

WinRS Reverse Shell

WinRS can be used to execute a Base64 encoded reverse-shell payload

PowerShell Remoting

PowerShell also has WinRM built-in capabilities called PowerShell remoting, which can be invoked via the New-PSSession cmdlet by providing the IP of the target host along with the credentials in a credential object format.

To interact with the session ID that was created, the Enter-PSSession cmdlet can be used:

PsExec for Lateral Movement

PsExec is part of the SysInternals suite intended to replace telnet-like applications and provide remote exectuion of processes on other systems through an interactive console.

PsExec can be used for lateral movment under the following conditions:

  • The user that authenticates to the target machine needs to be part of the Administrators local group

  • The ADMIN$ share must be available

  • File and Printer Sharing has to be turned on

The seconds and third requirements are met by default on modern Windows Server systems, but may have been explicitly disabled.

To execute the commond remotely, PsExec performs the following:

  • Writes psexesvc.exe into the C:\Windows directory

  • Creates and spawns a service on the remote host

  • Runs the requested program/command as a child process of psexesvc.exe

PsExec is not installed by default on Windows, and will likely need to be transferred from our attacking machine to a compromised target machine.

Pass the Hash Attack

Pass the Hash (PtH) attacks allow an attacker to authenticate to a remote system or service using a user's NTLM hash instead of a plaintext password. This only works for servers or services using NTLM authentication, not for services or servers using Kerberos authentication.

Tools that use PtH:

The following are required for a successful PtH attack:

  • Requires an SMB connection through any firewall (typically port 445)

  • The Windows File and Printer Sharing feature must be enabled

  • An admin share called ADMIN$ needs to be available.

To establish a connection to the ADMIN$ share, the attacker must present valid credentials for a user with local administrative permissions. This type of attack often requires local administrative rights. PtH attacks use the NTLM hash legitimately. However, the vulnerability lies in the fact that we gained unauthorized access to the password hash of a local administrator.

wmiexec to Perform PtH

Overpass the Hash for Lateral Movement

Overpass the hash can "over" abuse an NTLM user hash to gain a full Kerberos Ticket Granting Ticket (TGT). This TGT can then be used to obtain a Ticket Granting Service (TGS).

Example of Overpass the Hash

Assume you have a compromised workstation or server that a user has authenticated to. We can also assume that the machine is now caching their credentials (and therefore their NTLM hash).

To simulate these cached credentials, we can log in to the machine as a compromised user and run a process as the target user, which will prompt for authentication.

The most simple way of running a process as another user is if we have access to the GUI desktop via RDP and right click a program icon then shift left click "show more options" on the popup an select Run as different user.

From here, we sign in with our target user's credentials which will launch the program in the context of the target user. After the authentication is successful, the target user's credentials will be cached on the machine.

To validate the cached credentials, we can open an Administrative shell and use mimikatz to dump the logonpasswords.

The goal of the overpass the hash lateral movement technique is to turn the NTLM hash into a Kerberos ticket and avoid the use of any NTLM authentication.

Mimikatz for Overpass the Hash

We can use the mimikatz sekurlsa::pth command to perform an overpass the hash attack. The command creates a new PowerShell process in the context of our target user. This new PowerShell prompt allows us to obtain Kerberos tickets without performing NTLM authentication over the network.

At this point, we have a PowerShell session that allows us to execute commands as the target user. We can then list cached Kerberos tickets with klist.

If no Kerberos tickets are cached, it is because no interactive login has been performed. We can generate a TGT by authenticating to a network share on a target server using net use.

listing the cached Kerberos tickets now reveals the following:

We now have the TGT and a TGS, in this case for the Common Internet File System (CIFS) service.

You can distinguish a ticket being a TGT because the server is krbtgt.

We can now use tools that rely on Kerberos authentication as opposed to NTLM.

Using PsExec with stolen TGT

Now that we have a Kerberos TGT, we can use PsExec with the TGT. PsExec can run a command remately but does not accept password hashes.

Pass the Ticket Attack

How the Attack Works

The Overpass the Hash attack uses a captured NTLM hash to acquire a Kerberos TGT allowing authentication using Kerberos. We can only use the TGT on the machine that it was created for, but a TGS would be more flaxible.

The Pass the Ticket attack takes advantage of the TGS, which can be exported and re-injected elsewhere on the network and then used to authenticate to a specific service. In addition, if the service tickets belong to the current user, then no administrative privileges are required.

Performing the Attack

In this example scenario, we have an existing session for the user dave. The dave user has privileged access to the backup folder located on WEB04 whereas our logged-in user jen does not. We are going to extract all the current TGT/TGS in memory and inject dave's WEB04 TGS into our session. This will allow us to access the restricted folder.

From jen's computer, we will open an administrator shell and use Mimikatz to export the current TGT/TGS from memory

We can now see we have exported all of the TGT/TGS saved in a kirbi mimikatz format:

we can now pick any TGS ticket in the .kirbi format and inject it through mimikatz

We can now see that the ticket is listed when running klist

We can now access the share that dave has exclusive access to:

Distributed Component Object Model (DCOM)

This is a fairly recent lateral movement technique that exploit the Distributed Component Object Model (DCOM). The Microsoft Component Object Model (COM) is a system for creating software components that interact with each other. While COM was created for either same-process or cross-process interaction, it was extended to Distributed Component Object Model (DCOM) fori nteraction between multiple computers over a network.

Both Interaction with DCOM is performed over RPC on TCP port 135 and local administrator access is required to call the DCOM service Control Manager, which is essentially an API.

The DCOM lateral movement technique is based on the Microsoft Management Console (MMC) COM application that is employed for scripted automation of Windows systems.

The MMC Application Class allows the creation of Application Objects, which expose the ExecuteShellCommand method under the Document.ActiveView property. As its name suggests, this method allows the execution of any shell command as long as the authenticated user is authorized, which is the default for local administrators.

Performing the Attack

From a PowerShell prompt, we can instantiate a remote MMC 2.0 application by specifying the target IP as the second argument of the GetTypeFromProgID method.

Once the application object is saved into the $dcom variable, we can pass the required argument to the application via the ExecuteShellCommand method. The method accepts four parameters: Command, Directory, Parameters, and WindowState.

Once these two PowerShell lines are executed, we should have spawned an instance.

Reverse Shell with DCOM

We can use an encoded PowerShell reverse shell payload:

PreviousActive Directory PersistenceNextWinRM for Lateral Movement

Last updated