Scenario 2: Mixed Domain

In part 2 of our Lateral Movement article series, we’re going to cover a second penetration test scenario which focuses on mixed domains.

On a penetration test, you can find yourself in a network that isn’t entirely made up of Microsoft Windows based systems. Networks like this are often found in development, banking, and scientific organizations. These systems don’t use an active directory to maintain network access but usually have their user account management managed on the local machine instead of a network server.

Taking what we learned in the Windows scenario discussed in Part 1, because we have the password hashes of some users, it’s possible to crack their passwords. In this scenario, we will assume we have their passwords and, because humans are creatures of habit, password reuse among systems is in play.

After having done a further scan of the network, there are three new Linux/Unix based systems on it. One is a CentOS8 server with the IP address of 192.168.175.103, a development system based on Debian Linux with an IP address of 192.168.175.107 and a FreeBSD system with an IP address of 192.168.175.11

With password reuse, we can try to SSH into one of these systems. Let’s try SSH’ing to the Debian development system using the ‘gevans’ credentials.

Success! From here, we can look around to see if we have any additional privileges on this system.

When penetration testing older networks and Linux/Unix systems, you may encounter older network services that were created before network security was taken seriously. One such set of services includes the ‘r’ based services of ‘rlogin’ and ‘rsh’ introduced by the BSD community in the 1980’s. These services allowed for easy, but very insecure, remote administration. ‘rlogin’ and ‘rsh’ were the precursor to our modern SSH. Where ‘rlogin’ allows an interactive shell, ‘rsh’ allows a user to just run one remote command on a foreign system.

Given the output of the commands above, you’ll notice we weren’t prompted for a password for either running a command or logging in. We can also make it run code we create as well. For example, during a penetration test, the security team notices us running commands using ‘rsh’ or ‘rlogin’. If this happens, we can use ‘rsh’ to download and run a backdoor for us.

Extending Access

Now that we have access to two different Linux systems, we can target the FreeBSD system. Through nmap we notice it’s running a web server. However, as with the Windows example, we may not be able to go directly to the server from our attack machine. We can, however, access it in several different ways using various tunneling techniques. In the following paragraphs we will explain how to make SSH tunnels, firewall tunnels and use ‘socat’ as a tunneling agent.

The following command tells SSH to listen on local (our Kali attack computer) port 8000 and send the traffic it receives through the Debian system to the FreeBSD target (192.168.175.11) on port 80. You can see the full SSH command, the open port on our Kali machine and Firefox browsing to the “localhost” but it is actually sent through the tunnel to the FreeBSD target via Debian.

Another way to accomplish this is to use a tunnel with IPtables. IPtables is the most common Linux firewall. Changing firewall rules on a Linux host requires the use of the super user. The following commands in the screenshots below allow the Linux system to route packets. The first IPtables rule sets up port 8000 to accept traffic and forward that to the FreeBSD target. The last IPtables command says, when leaving the Debian machine, keep track of the connection and use the Debian IP address to talk to the FreeBSD target.

The last type of tunnel we will cover is tunneling using socat. Socat is the Swiss army knife of connection and port forwarding. It can translate between protocols such as TCP and UDP and between IPv4 and IPv6, making it extremely versatile. You’ll notice in the socat command the syntax isn’t like most commands run on Windows or Linux. Using the socat command below, it opens port 1111 on the IPv4 interface. Any traffic it receives on port 1111 it will send to port 22 to the IPv6 address of “2020:db8:aa:bb:cc:dd:2”. Lastly, it forks the process so more than one connection can be piped through socat. The SSH command used in the bottom screenshot is a demonstration of how to log into an SSH server with a certificate and no password, provided that the SSH server is set up that way.

Additional Tools
These are just a few of the tools at your disposal during a penetration test. These tools are very rudimentary but still accomplish a lot. Other tools such as tcpdump, ettercap, covenant, tgcd, and responder.py are also great to use in a penetration test. They can make network sniffing, traffic redirection, callbacks, and tunneling far easier than having to do it manually. The only downside is they usually require the penetration tester to upload them to the target or compromised host. Many of the tools demoed in this article are already built into the respective operating systems. You can learn more about these tools in the resources section below.

Conclusion
Penetration testing has a multitude of tools at our disposal. It’s worth knowing the tools that are native to the environment you will operate in. Having custom built tools, or more fleshed out tools such as responder.py or covenant, is great but can often be limiting. There will be instances when you need to get down and dirty with an operating system or native binary to accomplish your goal. There is also something to be said about using one computer to hop through to keep network traffic to a minimum. It helps keep external traffic to your Kali attack machine to a minimum and hopefully under the radar of the security team.

In the next article we will discuss gaining persistence, maintaining persistence, and what to look for in choosing a particular persistence host.

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: @Hisomeru