Spawning Process Remotely
Different techniques explained for spawning process remotely on machine in an AD environment
In this blog post, we will take a look at techniques threat actors or adversaries utilizes to spawn a process remotely, that enables them to run malicious commands on machines in the Active Directory domain with valid credentials. These techniques are best if the threat actors or adversaries have already gained an initial foothold on the machine that is domain joined and need to move laterally inside the network
For the practical demonstration, we will take an example from a tryhackme room called "Later Movement and Pivoting".
PsExec
PsExec is a lightweight telnet replacement that lets you execute processes on other systems, complete with full interactivity for console applications, without having to manually install client software. PsExec's most powerful uses include launching interactive command prompts on remote systems and remote-enabling tools like IpConfig that otherwise do not have the ability to show information about remote systems.
PsExec operates on port - 445 and requires the Administrators group's permission
Psexec has been the go-to method when needing to execute processes remotely for years. It allows an administrator user to run commands remotely on any PC which he has access. Psexec is one of many Sysinternals Tools
The working flow of PsExec -
Connect to Admin$ share and upload a service binary. Psexec uses psexesvc.exe as the name.
Connect to the service control manager to create and run a service named PSEXESVC and associate the service binary with
C:\Windows\psexesvc.exe
.Create some named pipes to handle stdin/stdout/stderr.
The command to run psexec on the remote host with valid credentials is as follows
If needed to run from attacker machine, we can use impacket-psexec
Remote Process Creating Using WinRM
Windows Remote Management or WinRm, is a Windows native built-in remote management protocol and web-based protocol that uses Simple Object Access Protocol or SOAP to interface with remote computers and servers, can also be used to send Powershell commands to remote windows hosts too. Most Windows Servers installations have WinRM enabled by default, making it an important attack vector for threat actors.
WinRM operates on Port - 5985/TCP (WinRM HTTP) or 5986/TCP (WinRM HTTPS) with required group memberships of "Remote Management Users".
To connect to a remote Powershell session from the cmd -
We can also achieve the same result in Powershell, we need to create a PSCredential Object
Once we have our PSCredential object, we can create an interactive session using the Enter-PSSession cmdlet.
Powershell also includes the Invoke-Command cmdlet, which runs ScriptBlocks remotely via WinRM. Credentials must be passed through a PSCredential object as well.
Remote Process Creation Using SC
Ports:
135/TCP, 49152-65535/TCP (DCE/RPC)
445/TCP (RPC over SMB Named Pipes)
139/TCP (RPC over SMB Named Pipes)
Required Group Memberships: Administrators
Windows services can also be leveraged to run arbitrary commands since they execute a command when started. While a service executable is technically different from a regular application, if we configure a Windows service to run any application, it will still execute it and fail afterwards.
We can create a service on a remote host with sc.exe, a standard tool available in Windows. When using sc, it will try to connect to the Service Control Manager (SVCCTL) remote service program through RPC in several ways:
A connection attempt will be made using DCE/RPC. The client will first connect to the Endpoint Mapper (EPM) at port 135, which serves as a catalogue of available RPC endpoints and request information on the SVCCTL service program. The EPM will then respond with the IP and port to connect to SVCCTL, which is usually a dynamic port in the range of 49152-65535.
If the latter connection fails, sc will try to reach SVCCTL through SMB named pipes, either on port 445 (SMB) or 139 (SMB over NetBIOS).
We can create and start a service named "THMservice" using the following commands:
The "net user" command will be executed when the service is started, creating a new local user on the system. Since the operating system is in charge of starting the service, you won't be able to look at the command output.
To stop and delete the service, we can then execute the following commands:
Creating Scheduled Tasks Remotely
Adversaries and threat actors usually prefer creating a scheduled task on remote machines or on the compromised machine. The benefits of this are usually used for persistence if the defenders kick out the attackers, the scheduled task will enable them to gain the foothold again. The MITRE ATT&CK have it labelled as T1053
To create a task named THMtask1, we can use the following commands
We set the schedule type (/sc) to ONCE, which means the task is intended to be run only once at the specified time and date. Since we will be running the task manually, the starting date (/sd) and starting time (/st) won't matter much anyway.
Since the system will run the scheduled task, the command's output won't be available to us, making this a blind attack.
Finally, to delete the scheduled task, we can use the following command and clean up after ourselves to avoid detection
Practical Example
Now we will take a look at a practical example for creating a scheduled task remotely to gain access to the remote machine. As mentioned above, we will take an example from the tryhackme room.
Note - The network is shared
Here is the domain map -
Although the domain environment has other machines for this example, we will focus on the highlighted one -
Initial foothold machine -> 10.200.51.249 - THMJMP2
Target -> 10.200.64.201 - THMIIS
We will act as an adversary that has already gained an initial foothold on the machine THMJMP2 with a valid set of credentials. Next, we will create a scheduled task that will download the exe file and give us a reverse shell back to our attacker or our Kali Linux machine.
First SSH into THMJMP2 using the credentials we already have
Next, create a malicious binary using msfvenom. However, if we try to run a reverse shell using this method, we will notice that the reverse shell disconnects immediately after execution. The reason for this is that service executables are different to standard .exe files, and therefore non-service executables will end up being killed by the service manager almost immediately. Luckily for us, msfvenom supports the exe-service format, which will encapsulate any payload we like inside a fully functional service executable, preventing it from getting killed.
Transfer the exe to the THMJMP2 machine. For this, we will be using smbclient
Once our executable is uploaded, we will set up a listener on the attacker's machine to receive the reverse shell from msfconsole
Since sc.exe doesn't allow us to specify credentials as part of the command, we need to use runas to spawn a new shell with t1_leonard.summer's access token.
Still, we only have SSH access to the machine, so if we tried something like runas /netonly /user:ZA\t1_leonard.summers cmd.exe , the new command prompt would spawn on the user's session, but we would have no access to it. To overcome this problem, we can use runas to spawn a second reverse shell with t1_leonard.summers access token
Checking back the listener
And finally, proceed to create a new service remotely by using sc, associating it with our uploaded binary. Be sure to change the name of your service to avoid clashing with other students.
The above two commands will create a task name - THMservice-1234 and will run our exe. Checking back our listener
We successfully got a shell back as THMIIS. Get the flag
Thank you for reading!
Closing note
I will be updating this blog if I came across a new and unique techniques to spawn a process on a remote machine
Last updated