Penetration Testing 101: Lateral Movement

In the last article we talked about surveying a network that a penetration tester may land in during a penetration test. Finding and scanning hosts in that network is integral to lateral movement. How can a penetration tester hop to a new target if they don’t scan and survey the target network first?

This series of articles will cover how to access different hosts within the target network.

There are countless ways to access different hosts on a local network. However, since we already covered technical exploitation in an earlier article, this article will cover items usually turned on in local networks which aid in administering those computers and devices. After all, in most penetration testing scenarios, it can be more prudent to use the built-in tools and blend in with administrator activity.

The first article in this series will cover a few different ways to laterally move through a network. In this proposed scenario, we assume the other remote hosts on the network are discovered and the operating system is known. In addition, we will cover how to remote into a device and, later, how to use that remote device to extend farther into the network. Each of these parts will have a scenario described to illustrate the point. Please note, these articles assume privilege escalation has happened. Privilege escalation is a large topic and is not in the scope of this article or series as there are hundreds of ways to escalate privileges on various operating systems.

Scenario 1: Windows Domain
Consider this scenario: You’re penetration testing a largely Microsoft Windows based network. You’ve landed on a typical user workstation via a phishing email. You have normal user privileges but have escalated to the SYSTEM user on the local host. However, since this is a Windows domain, there are other workstations configured identically to the compromised machine as well as a Windows Server acting as a domain controller.

The following examples and screenshots take place on a local network to mimic a Windows based network. There are two Windows 10 user workstations, “win10-dev1” with an IP address of 192.158.175.23 and “win10-prod27” with an IP address of 192.168.175.92. The domain controller is Windows Server 2022 called “CORP-DC” with an IP address of 192.168.175.1. Finally, the domain is simply called “corp.local”.

As a penetration tester with SYSTEM level permissions on the compromised system, you can now use tools like “mimikatz” to dump the usernames and hashes from the system. All users who have logged in to the computer since reboot will have their Windows passwords hashed in memory. Windows does not store passwords in clear text in memory and only stores the password hashes. These password hashes have the potential to be cracked depending on the hashing algorithm. However, they do not need to be cracked to be of use to a penetration tester.

One of the easiest ways to move laterally through a network is by a technique called “Pass the Hash”. When a user logs into a Windows system on a domain, the local Windows system will take the username and the password. The Local Security Authority Subsystem Service, or LSASS, will hash the password according to the set algorithm then send the username and corresponding hash to the domain controller. At no point is the actual password sent to the domain controller - only the hash of the password. Because of this design, the password does not have to be known, only the hash of it.

Moving through the network with ‘Pass the Hash’ doesn’t stand out to those watching the network unless it’s abused. Because it is built into Windows, it looks normal and cannot be patched out. This technique works on fully patched Windows systems and servers.

As you can see from the above screenshot, we got a callback from a workstation on the network. The user in question is “gevans” and authenticated to the logon server called “CORP-DC”. You’ll notice the NTLM hash is present but not the password. From here, we can use the hash to do many different things, both from the compromised host and from the Kali attack machine.

The first and easiest example is using a tool called “PsExec” from Linux. We can get a simple command shell on workstations allowing the “gevans” user to log in by using the password hash of the “gevans” user. Below is a screenshot of using PsExec from Linux to log into the “win10-prod27” workstation.

A more complicated method, but one that works in the same manner, is to use the Windows version of PsExec. This method is tricky, as the Windows Sysinternals tool will not allow us to pass the hash. In the screenshot below you’ll see a callback from the compromised workstation, “win10-dev1”. From there, another backdoor is downloaded called “4445.exe”. That backdoor is then uploaded to “win10-prod27” and then run using the Windows version of PsExec. You’ll notice when using the Windows version of PsExec, a user wasn’t specified. PsExec will use the current user to log into the remote system, if allowed, and run the commands specified.

You’ll see that the user who called back was “tjohnson”. That was the user who was previously compromised on “win10-dev1”. He also has rights to log into “win10-prod27” and run commands. We can extend this even more with a concept called “PS Remoting”. You can think of PS Remoting being similar to SSH but used through Microsoft PowerShell.

Another way to move laterally through a network is to create scheduled tasks on another system. Often, users are allowed to log into other network systems and run commands remotely. When this happens, we can upload a backdoor to the currently compromised system and create a task on a remote system to run an executable hosted on the current system.

Extending Access

Extending this scenario, let’s say there’s a computer in the network that cannot access the outside world. We can make it “callback” to a computer which might have internet access and thus get back to our Kali attack machine. To make this happen, a few things must occur. First, we must craft a payload to callback to a computer that can reach out to Kali. Second, we must create a firewall rule on the originally compromised host that will listen for the callback and then forward the traffic to our Kali box. Finally, we have to set up our listener on our Kali box.

In this scenario, we’re assuming the 192.168.175.23 computer can callback to our Kali attack box. We’re creating a Windows payload that will callback to 192.168.175.23 on port 3390.

From here, we will upload it to 192.168.175.23 and create a scheduled task on 192.168.175.92, using the last example as a guide, to run every minute to call back to the 192.168.175.23 computer.

Now, we should receive a callback from 192.168.175.92 but going through 192.168.175.23.

Check out part two of this blog series here.

About Hisomeru

Hisomeru is a contributing player in the infosec community. In Hisomeru’s more than 15 years of experience, Hisormeru has managed IT security teams, developed custom tools and performed penetration tests. Cyber security is Hisomeru’s passion and Hisomeru has taught many individuals cutting edge penetration testing techniques. Hisomeru’s twitter is: https://twitter.com/Hisomeru