How Attackers Lay the Groundwork for Lateral Movement
Lateral Movement is a critical step in the process of carrying out an attack on a network. It is a category broad enough that it has its own kill chain step. Although it is a broad tactic, these posts will survey a specific method that might be carried out by an adversary.
In our last Hunter’s Den post, we covered some of the TTP’s that are associated with searching for lateral movement. Now that we have a rough idea of the progression of this attack lifecycle let’s dig into the stages a bit more.
First I am going to craft the malicious version of a legitimate binary. Here I am using a legitimate copy of putty and injection a malicious reverse_tcp payload.
Creating the Malicious Payload
I have also renamed the file from badguy3.exe to puttyX.exe so that the end user is not aware of the change in the file. Since I am skipping the infection stage in this write up, I will not be going into how I made this binary or how I tricked the user into running it. #PleaseDontSueMe
The first stage that matters is the compromise stage. What you see here is a popular penetration testing suite, called Kali, that is being used to connect to the reverse shell generated by the malware on the target host. You can see that with this shell, I as the attacker, have the ability to run admin-level commands to perform recon of the system and network it is on.
- Communication with the compromised systems and C&C (command and control) servers is established
- Threat actors need to sustain persistent access across the network
- They move laterally within the network and gain higher privileges through the use of different tools
After sending the user the malicious binary I start a metasploit console that is going to wait and listen for a connection request from the user. Below you can see the session being started and initiated by the victim system.
Starting listener for connection from infected system
You can also see that the last line in the image reads “meterpreter”. This means I now have a direct shell on the victim system from my attacker system. From this shell I can either run plugins, scripts, payloads, or start a local shell session against the victim.
First thing I am going to do with my session is see what privileges I have.
Discovering privileges of user who executed the infected binary and compromised the system
Here I can see that the user I have tricked into running my malware is not a local admin and i have very restricted privileges on the system. Good for SecOps but bad for me as an attacker. Luckily, I am not so easily blocked.
I am going to background my meterpreter session so i can load more attacks to use against the host. In this image we can see that the user I am running as is “bjohnson” in the domain “sectechlab” on the host “win7-pc”. I can also see that I am currently running as x86 windows and my victim IP is 192.168.1.100.
Keeping my session live while I load more attacks
Now that I have the session in the background, I am going to load up a generic UAC bypass exploit (this is patched in current windows versions) and run it against the victim system.
Bypassing Windows UAC to escalate privileges
Second Session started with UAC bypass enabled
Well what do you know? This enterprise isn’t keeping up to date with their patches. Thanks to the successful UAC bypass, I know have a second session started on the victim and this session I can start my evil. How can I do this when the sessions look identical? I can do this because I just bypassed windows user access control. To prove i now have more access, I will rerun the getprivs command on the second session to see if I know have admin privs.
Successfully getting system level privileges on second session
Second session has system level privileges
Bam! Money privs.
Now that I have admin privs, i can just simply give myself system level access and then start hiding myself by starting a new x64 process and migrating into that new process. Here I am choosing to use notepad but in reality this will popup and application on the victim system that the user can then quit and I will lose my session. What i really would do is run a process without a Graphical User Interface (gui) but I don’t think I should show that here. #PleaseDontSueMe
Migrating to a new x64 process
Now that I have system level access and have hidden myself in a new process. Let’s start the recon!
Now that we have direct CLI access to the compromised host, we need to enumerate the users on that host, the network that it is on, as well as gather generic system information like running processes and such for possible usage for persistence.
Waste not, want not.
The images that you see are of me using the net user command to find local users on the host as well as domain users who have previously logged in. What I am looking for are admin and power user level users that I can reuse elsewhere in the environment. The first thing I am looking for is the local admin accounts on the system. This account is commonly used as an IT backdoor to get into systems that are having AD issues and is commonly the same username and password on all systems in the environment because it is part of the build process. I beg you not to do this in your environments. There is even a GPO setting that randomizes the local admin password on your systems. There is no excuse for this anymore.
The top three things I want to do once I get access to a system:
- To move laterally within a breached network and maintain persistence, attackers obtain information like network hierarchy, services used in the servers and operating systems
- Check the host naming conventions to easily identify specific assets to target
- Utilize this info to map the network and acquire intelligence about their next move
First I want see who I am and where I am. I will run some basic sysinfo, whoami, and hostname commands. But what I really want to know is who has been on this system and where this system is in the network.
Local and Domain Users
Current Networking Configuration
Current Network Connections
NMAP Network This Host Is On
Next up we have the credential theft stage. What you see here is me running a mimikatz metasploit module. I used this because mimikatz will take credentials out of memory and crack the hashes for me. This allows me to harvest credentials without having to put an executable on the system. These activities are often unnoticed by IT administrators, since they only check failed logins without tracking the successful ones.
Recover the MSV hashes
Recover the Kerberos Hashes
Recover SAM hashes
Recover SAM hashes – if new method above doesn’t work
Finally, we get to the stage where the rubber hits the road. I am going to use the network data I enumerated from the victim as well as the credentials I just took to PsExec into another system on the network. PsExec is a Sysinternals tool that is signed by Microsoft and commonly exists in enterprise environments for legitimate administrative work. This tool gives me full CLI access to a target system so that I can use that remote system while the authorized user is using it without them being the wiser. Once on that system, I will try to reach my goal of stealing information or I will start the attack lifecycle again at the recon stage and repeat it on more systems in the environment until I achieve my goals.
- I can now remotely access desktops
- Accessing desktops in this manner is not unusual for IT support staff
- Remote access will therefore not be readily associated with an ongoing attack
- Attackers may also gather domain credentials to log into systems, servers, and switches
- Because of password reuse by users
- Remote control tools enable attackers to access other desktops in the network and perform actions like executing programs, scheduling tasks, and managing data collection on other systems
- Tools and techniques used for this purpose include remote desktop tools, PsExec, and Windows Management Instrumentation (WMI).
- Note that these tools are not the only mechanisms used by threat actors in lateral movement.
In the example below I am creating a route on the first compromised host that that I can use it as a jumpbox to access another system in the environment.
Now that the route is set, I am just going to repeat my PsExec exploit against the new target and cycle through the captured credentials until one of them works.
Move Laterally – Use PsExec from the attacker, through the compromised system, to the new target host victim
The Hunter’s Den blog series aims to go beyond framework and theory and dig into practical tips and techniques for threat hunting. In our next post, we’ll cover best practices for hunting for lateral movement activity.
And as always, remember my motto, Flag it, Tag it, and Bag it.