Vulnerability scans only provide minimal information. When actually attacking the machine, you want to perform some deep level probes to check for helpful information leaks. From the scans, we can see that both a Windows Domain Controller and a Windows File Server run Windows 2008 Server. Both have SMB/NetBIOS services running. A good first attack vector in a case like this is to exploit the SMB/NetBIOS services, which are known to have exploitable weaknesses. So, let's look closer at these services.
Before we go any further into footprinting the target machines, here is our note about notes. Especially when getting into manual probes, remember to keep notes on your outputs and your findings. Copy/paste is your best friend. Vulnerability scans almost always produce nice reports with the data all compiled in one place. Manually probing doesn't, so it's up to you. We strongly suggest using KeepNote, which we first visited in Chapter 1, Sharpening the Saw because you will be collecting an awful lot of data that you may need later. Don't trust your memory for this. Like a detective on a case, chronicle everything.
The following is our normal layout for testing. The best thing about KeepNote is that the framework is very open and can be set up and used as you like. This setup uses:
- A folder for the client company in which is found:
- A page for general project notes
- A folder for targets
- Individual pages for each system being tested
KeepNote even comes with a nice Export to HTML tool where you can export your notes so they can be read by others without them having KeepNote.
- First, we use
nbtscanto get a quick look at the domain name or workgroup name and any other basic NetBIOS data we'll need. So, let's open a new terminal window and run this command:nbtscan -v -s : 192.168.202.0/24The
-vflag is for verbose mode and will print out all gathered information. The-s: flag will separate the data with a colon.
We can see that the domain name is
LAB1and all machines are members of that domain; we will need this information later. - Back in the
msfconsole window, run the command:msf> search smbWe get a listing of all the modules related to the SMB service. This is a listing of scanning, probes, exploits, and post exploits modules. First, we are going to check whether there are exposed shares and then check whether the Guest account has any rights on the machine. We pick
auxiliary/scanner/smb/smb_enumshares. You can select the text and copy it by hitting Ctrl + Shift + C; you can paste using Ctrl + Shift + V.
- To use the module, run the command:
use auxiliary/scanner/smb/smb_enumsharesThis will put you into the module. The following way in which we have used this module is the normal way of using all the modules. The configurations for the different modules may be different, however the operation of getting into a module and configuring are the same.
The
usecommand is the way to access any module. If you want to back out of the module, you type thebackcommand with no option or target information. - By running the command,
info auxiliary/scanner/smb/smb_enumsharesWe can see information and help information about the module without actually entering the module.
- After entering the module type,
show optionsIt will show you the usable parameters for the module. With this module, we will need to set the hosts to probe the domain name and the user account. By running this module with the SMBUser account as blank, you can check to see if the
Everyonegroup has any permissions. Setting it toGuestwill check whether the Guest account is enabled; however, it will also check the Everyone group.Notice that we have a parameter, RHOSTS; this is the parameter to set the host you are going to probe. This is a scanner module, so the parameter is plural and will accept a network range or a single host.
- We set the configuration by typing
set RHOSTS 192.168.202.3 set SMBDomain LAB1 set SMBUser Guest show options
The
show optionscommand will pull up the configuration again so you can check it before running the scan.
Below, we see the results of the scanner run by typing
exploit
We see that the scan failed but it did give us valuable information. First, by the scan failing, we now know that there are no shares open to the Everyone group. By the response, we can tell that the service is active but is refusing to allow a connection. Second, we can see that, in fact, the Guest account is disabled. One could say that this has led nowhere, but from this we have determined that the service is active and accepting connections from our IP address, which is important information for our next move.
The SMB service uses RPC pipes to transfer information and the RPC service is known for leaking system information sometimes; so, let's look at what we've got. To do this, we will use DCERPC Pipe Auditor module.
use auxiliary/scanner/smb/pipe_dcerpc_auditor show options
We can see the module configuration in the following screenshot. We can use the arrow keys to arrow up to the configurations from the earlier module and set the SMBDomain and RHOSTS settings.
set SMBDomain LAB1 set RHOSTS 192.168.202.3 show options exploit
It seems our SMB service is well locked down. We'll see about that in a minute.
Looking over the earlier scans completed, we can tell that the machine hasn't been patched in a while. Also, from our network footprinting, we know that this is a Windows 2008 server, so this rules out using exploits earlier than 2008. We can also tell from our probes that weak links in the configuration of the server are present. We need an exploit that will work around these roadblocks.
Picking the right exploit is a matter of experience and trial and error. Not all work and some take more than one try to exploit a system. Don't give up if at first you don't succeed. The average Windows installation has several exploitable vulnerabilities.
We have picked the exploit/windows/smb/ms09_050_smb2_negotiate_func_index. This exploit attacks the SMB request validation function with an out of bounds call and establishes a Meterpreter session. The Meterpreter is a Metasploit shell that works with remote connections and has a lot of tools to use to gain elevated privilege, gather hashes, and system information. Once at the prompt, type help to see these commands:
Congratulations! You have opened a session on the target machine. Now things get interesting. Since you have a session open on the target machine, you can find out the details that can only be found from inside the machine:
- First we need to elevate our access by typing
getsystem.We see that we got a positive result, so we now have SYSTEM access to this server. To get further information, typesysinfoto find out about the specific build of Windows Server OS and the general architecture of the hardware. In this case, the OS is a 32-bit version, which is becoming more and more unusual. The x86 designation tells you that. Now, just for fun, type inipconfigto find out how many network cards are present on the machine and to which subnets they are defined.
- Next, we type
hashdump, and now we have the hashes of all the local accounts. Note the 500 after the name Administrator; this is the User Identifier (UID). The Administrator UID is always 500 on a Windows machine. If the Administrator's account name has been changed, you can still see which account the local administrator is by this number. If we copy and paste these accounts and hashes into a text file and then import it into the Johnny Cracking Tool, we will soon have the passwords.
- Next, let's upload a file. Now this could be a virus, a trojan, or any sort of file at all. You can now upload anything, including more tools for exploitation. Since you now own it, you can upload and install anything you like. Here, as part of the testing procedure, we're going to upload a text file called
youvebeenpwned.txtinto theC:WindowsSystem32directory. In testing, we used this sort of benign file as evidence that we have been there and had the ability to upload files to an area to which only users with administrative privileges can write files.
Tip
Hacker Tip
The first time we tried to upload the file it failed. In the destination, we typed it as c:windowssystem32; we used backslashes, and as you can see in the output, the slashes were omitted and all the text was run together. The Meterpreter is a Linux command line, so you must use the forward slash /. The second attempt used forward slashes, so the file was successfully uploaded to the system.
On the Windows machine, we can now see the file in the Systems32 directory. This will work for evidence that the server is vulnerable to attack.
Wasn't that easy?
Moving along, we need to look and see if we have anyone logged in at the moment. It would be counter-productive to just make a lot of noise or call out, "Is there anybody in?" In a real hack, the attacker will wait until there isn't anyone in. We can see below that we have one user logged in with an active desktop.
Some exploits in Metasploit will open a desktop during the exploit; if this is the case, you will see the exploits session number under the Session table. All zeros also tells us that the active desktop is actually a user on the machine.
So far, during this session, we have escalated our privileges, uploaded a file, and checked to see if anyone is watching. What we need now is a shell to run the file we uploaded (if it had been something nasty and we were a real attacker).
To create a command shell on the owned Windows machine, type shell. You now have a shell on the remote machine. Note: in the example below, the Linux ls command to list the current directory contents doesn't work because you are now in Windows.
