Penetration Testing Explained, Part IV: Making the Lateral Move

You can think about the post-exploitation part of penetration testing as an army or rebel force living off the land. You’re scrounging around the victim’s website using what’s available — shells, networking utilities, berries, poorly protected password files, etc.

Kidding about the berries, but the idea is to import as little malware as possible and leverage what you find for more exploration and new attacks.

This whole topic goes under the name of “malware-less” hacking, which is much harder to detect than old-school techniques. Ed Skoudis noted in our interview last month that attackers are even starting to use PowerShell for their post-exploit work.

This next post in the series will focus on moving off the original hacked site — lateral movement in pen testing speak. I’ll be giving you some ideas about doing that with as little help from imported tools as possible.

Acme Company Domain

If you can find the goodies on the original target’s site, then you make a quick getaway. However, most hackers are not that lucky unless they land on the CEO’s laptop.

To make my penetration testing a little more realistic, I decided to set up a small domain, courtesy of Amazon Web Services. After a little hair-pulling (and reading this AWS document carefully), I installed a domain controller (with Active Directory and DNS) and then created two Windows servers.

I added two mythical employees — Jane and Bob — to a mythical company called Acme with a mythical domain name of acme.local. I then associated each employee with one of the servers. I enabled basic user networking capabilities on the domain controller through the User Rights Assignment group policy. But I prevented Jane and Bob from networking to each other’s computer to make the thing more interesting

I now will disclose that I made the server firewall less restrictive than was called for in the Amazon specs.

This is obviously a very rudimentary infrastructure, but who knows, it could describe a small system in a larger company or perhaps that of a third-party supplier, like an HVAC vendor.

Hacker Things to Know

As before I used a RAT to get a foothold on internal computer, in this case Jane’s Windows 2008 server. I uploaded two tools for my pen testing into Jane’s Documents directory: ncat, which I wrote about last time, and a utility known as psexec — check out this Technet article for parameter usage.

Both are in the gray area — they’re useful for IT admins as well as hackers — so if they’re spotted they’re not necessarily incriminating. I probably should have hid them in less obvious folder than Documents, but never mind.

I launched a shell on Jane’s server through ncat, and then started the process of gathering information. My goal in testing is to think like a hacker: pull together bits of information and make a few inferences.

First, I entered the Windows hostname command to learn the name of the machine I’ve landed on (see above). The command returns “miller”.

Is that miller as in beer? Could it be the naming scheme is based on beer names?

The systeminfo command provides even more detailed technical nuggets: besides hostname, it displays IP address, OS name and version, and the domain name. All useful.

Let’s assume I’ve done a search for PII and haven’t found anything interesting. I’d like to find another server to hop onto. I could have uploaded nmap to scan for IP addresses, but I’m doing lean pen testing.

I instead ran the native arp –a to see what else is on the subnet. I’m in luck: the arp cache shows another machine in the neighborhood.

How do I hop onto it?

The Local Admin Loophole

That’s where psexec can, in theory, be of help. It’s a favorite of Ed’s and just about anyone who’s ever proudly called themselves an IT admin.

The command lets you remotely connect to another machine in the domain, letting you launch a shell or another Windows command. There’s also Windows netsh, which is less flexible, but also has remote capabilities.

The first problem for pen tester is that psexec requires the name of the remote computer (see syntax).  At this point, I only have the IP address.

You need to scavenge.

Over in the \Windows\system32 folder you’ll find nlsookup, the classic utility to query a DNS server for converting URLs to IP addresses and vice-versa. The Windows version lets you directly feed nslookup an IP address and it returns the DNS name.

I found that this remote machine is called amstel. So the IT admin is fond of beer names. I’ll file that away.

I tried this next:

psexec \\amstel.acme.local -u jane@acme.local cmd.exe

And unfortunately Windows rejects Jane’s account. There are two problems. In my role as an Acme admin, I didn’t allow Jane to log on to another machine. Second, Jane herself needs admin level privileges to run psexec, which she doesn’t have.

This is not that unusual in the real-world — you want to restrict average users from getting around the network.

But hackers and pen testers know a secret. Often there are local accounts with elevated permission on the machine they’ve landed on.

In the Windows-verse, there has been a long history of admin-level local accounts remaining on laptops and servers long after they’ve server their purpose, usually with the incredibly obvious user names of admin or administrator and guessable passwords — Admin1234 or some other simple pattern.

So hackers try to exploit this security hole by guessing the local admin’s password.

To be fair, the Microsoft folks have been aware of this problem, and they’ve disabled admin privileges on local accounts by default starting a few OS versions ago. And they also have discouraged the addition of local user accounts.

The Amazing Lateral Move

Though I had a limited tool set and could claim only slightly above average IT skills, I was hoping to say it was easy for me to OWN Bob’s server. That was not the case. I’ll go into the details about this in another post.

I can say the reverse shell technique using netcat is not entirely transparent. There were issues with entering text from my hacker machine into remote commands that issued prompts— most notably runas.

So to make this a more interesting pen testing post, I put my Acme IT admin hat back on and gave Jane elevated permissions. Jane’s domain account was still locked out from Bob’s server.

Now as a pen tester, I can run psexec commands. Psexec has the desirable feature of allowing a password argument. In my current set up, I can now do a brute force attack on the local admin password on Bob’s server. I finally nailed it (see above).

I was also hoping to get psexec to pop a shell on Bob’s amstel server in my reverse-shell scenario. The best I could do was run a single shell command — no scripts — from the command line, and even that took some doing. Although I couldn’t come up with an easy approach to searching for PII and other strings in the remote directory, psexec was still useful.

The larger point is that with psexec, hackers and pen testers can search for admin accounts on domain machines. Yes, they can try to guess domain level passwords, but local admin is usually far more productive.

When all Else Fails, There’s ssh

I couldn’t help but come away from my first pen testing exercise with the sense that Windows makes it difficult to run commands remotely. Not impossible, but difficult.

I’m not the only one. IT admins have felt the pain as well. And that’s why they often install open-source ssh in their Windows infrastructures.

So it’s not unreasonable for an ssh server to be running. In my Acme IT role, I had previously set up freeSSHd’s version on Bob’s server.

Now with ssh in the picture, the doors begin to open up. Using my RAT, I uploaded and launched an ssh client app on Jane’s computer. And quicker than you can say Target, I was ssh-ed into Bob’s server using the local admin account I had worked out earlier. To pull this off, I had to take advantage of ssh’s port forwarding, which is another one of those sneaky features that pen testers enjoy using. I’ll explain this in another post.

My little adventure was meant as a learning experience for me and inspiration for your own in-house testing efforts. Professional pen-testers (and hackers) would likely be using more advanced tools, but as some of my former teachers liked to say while waving their hands: the concepts I’m describing are the same!

In my next post, we’ll looking at better techniques for grabbing credentials instead of trying to guess them.