Stealing the Bank Vault Codes via Insecure Microsoft Default Settings

Fun with forced authentication inside a financial services network.

Sometimes in infosec, it’s the little things that matter. This truth was underscored once again during a recent penetration test of a financial services client. A combination of somewhat minor issues— rather than a major vulnerability—yielded a high-impact result.

The client had given us free rein to test anything on the network. We were allowed to work internally and externally and perform social engineering— nothing was off-limits. Typical of a financial services organization, the network was locked down and very secure.

After various unsuccessful attempts at gaining deeper access through the earlier phases of the engagement on the internal network, we decided to piece together what we knew about a few insecure Microsoft default settings:

• Microsoft Exchange server accepts emails from any address by default if the email sends to a domain the server is configured to handle. This makes it trivial to spoof a sender’s address, even from the organization’s own domain.
• Outlook automatically downloads images within emails from the same domain by default. This means an HTML image tag pointed to our “malicious” SMB server would be loaded and the Outlook client would authenticate with the credentials of the logged-in user.
• SMB signing, by default, is not required on Microsoft Windows systems (except for domain controllers).

The attack

We built a script that automated sending a simple email to a list of several hundred of the client’s employees, spoofing the sender as the company’s IT department. The email itself simply informed the user that their password had expired. It contained no links or attachments. We included an image tag in the HTML with the ‘src’ value pointing to a nonexistent GIF on our SMB server.

When the user opened the email, the link in the image tag forced an NTLM authentication to our SMB server, sending the user’s password hash straight to us, generally in Net-NTLMv2 format.

Without the need for any user interaction beyond opening the email, the setup worked like a charm. Within five minutes, we gathered 35 password hashes, which we took offline for cracking. Thanks to our trusty GPU server, we cracked 24 in short order.

The customer’s domain was strictly configured. Outside of the domain and enterprise administrator groups, only a few users had local administrator privileges anywhere in the network, and these privileges overlapped to a single computer. The odds were in our favor that day because out of 24 passwords, one belonged to one of those users.

Using this admin privilege to remote desktop in, we poked around for a while.

Hitting paydirt

After following some breadcrumbs, things took an interesting turn when we found ourselves staring at the network share folders of what appeared to be a computer controlling an ATM. Then things got really interesting because one file, in particular, stood out to us: An Excel sheet named Vault Combo Chart.

Could it be? No, surely not. But we wouldn’t be doing our job if we didn’t open it to find out.

Hacking in the movies is portrayed as fast-paced and exciting, when most of the time, it’s a tedious process of trial and error and waiting around. There are times, though, when it does provide an adrenaline rush. This was one of those times. Because once opened, the document was exactly what it sounded like: A list of vault combinations for every one of the bank’s locations. The penultimate keys to the kingdom.

Forced authentication: From external to internal

Forced authentication attacks have been around for decades, traditionally as an external concern. But after organizations and even ISPs began widely blocking the ports these attacks use, attackers lost interest over time. After a long enough lag in forced authentication attempts, however, it seems companies and even some ISPs have gotten lax about blocking these attacks, or in some cases, an organization may have explicitly requested the unblocking of a port. Whatever the reason, in recent years, these attacks have begun to see a resurgence externally. This engagement was confirmation that forced authentication attacks work not only externally, but even better internally.

What makes internal forced authentication effective? And what can organizations running internal Microsoft Exchange servers do to prevent these attacks? Let’s run through the issues that make this attack possible, and how to rectify them.

Problem 1: Microsoft trusts internal traffic by default

Microsoft Exchange allows anything that can reach it on TCP port 25 to relay to any accepted internal domain without authentication by default. This makes sense from a historical standpoint because, until the invention of SPF, DKIM, and DMARC, there was no way to authenticate the source of an email on the internet. On top of that, for the sake of internal device setup, there is no authentication for internal mail relay over TCP/25 by default. This makes it easier to set up printers and other devices that need to send mail from the internal domain, but there are security tradeoffs.

The mail server is also indiscriminating when it comes to the sender’s email address and will accept any sender by default. From the internal network of the organization, one can pose as anyone from any domain. This allowed us to pose as “[email protected],” a simple spoof that would have been impossible with an external phish, as spam filters usually protect these systems.

These defaults can be dangerous when the Exchange server is exposed externally because the same lack of spoofing protection applies—you can still send through whatever you want as long as it goes to an accepted domain. (This is why customers buy spam filters to put in front of their Exchange servers.)

Outlook also loads images from internal senders by default, without the control layer of asking whether the user wants to load the images.

Solution: Configure Exchange transport rules to block traffic that claims to be your domain without being authenticated.

Problem 2: NTLM security issues

NTLM is an outdated protocol replaced since Windows 2000 by Kerberos as the default authentication protocol, but it’s still widely used in Windows systems to maintain compatibility with older systems. Borrowing from CrowdStrike, NTLM’s challenge-response protocol is as follows:

1. The user shares their username, password and domain name with the client.
2. The client develops a scrambled version of the password — or hash — and deletes the full password.
3. The client passes a plain text version of the username to the relevant server.
4. The server replies to the client with a challenge, which is a 16-byte random number.
5. In response, the client sends the challenge encrypted by the hash of the user’s password.
6. The server then sends the challenge, response and username to the domain controller (DC).
7. The DC retrieves the user’s password from the database and uses it to encrypt the challenge.
8. The DC then compares the encrypted challenge and client response. If these two pieces match, the user is authenticated and granted access.

Step 5 is what spit the user passwords back to us, hashed, in a non-replayable format that pen testers generally refer to as Net-NTLMv2.

Solution: Disable NTLM authentication completely (with appropriate internal testing with conversion to Kerberos). Consider setting IE trust settings to only allow specific internal web servers that your employees are meant to go to that are known to require NTLM for SSO authentication.

Problem 3: Lack of SMB signing

SMB allows for file sharing in Windows, transferring files between systems, and various other Windows tasks. If signing is not required during that exchange, an attacker can intercept the traffic between client and server and compromise the integrity of messages between them.

At this point in the attack, the lack of default SMB signing on Microsoft systems (for anything other than a domain controller) introduces the additional possibility of internal cross-protocol relay attacks—whether just stealing the user’s password hash and attempting to crack it or trying to relay it to other systems.

Fortunately, the client’s environment was secure from the highly prevalent attacker tactic of NTLM relaying. Had it not been, we could have had even more access. And had this been discovered by a malicious actor, the potential for widespread damage would have been greater.

Solution: Require SMB signing on both servers and clients for all systems within the domain (with appropriate testing).

The bottom line

The success of this engagement underscores the risks associated with default configurations that administrators should carefully consider. While none of these issues are critical in and of themselves, linked together they can allow attackers the leverage needed to access information that is critical to an organization.