Two-factor Authentication Best Practices: 99 Problems but Two-Factor Ain’t One

Written by: Austin Baker

Two-factor authentication is a best practice for securing remote access, but it is also a Holy Grail for a motivated red team. Hiding under the guise of a legitimate user authenticated through multiple credentials is one of the best ways to remain undetected in an environment. Many companies regard their two-factor solutions as infallible and do not take precautions to protect against attackers’ attempts to bypass or backdoor them.

The techniques covered in this blog range from simple to advanced methods of handling two-factor authentication from the perspective of a red team, and provide insight into potential visibility gaps for security teams to address. I’ll discuss techniques for bypassing two-factor authentication remotely without access to the internal environment, and how to gain access to a two-factor authenticated remote access device with information stolen from the internal environment.

1) K.I.S.S - Keep It Simple, Stupid

Compromising a remote access solution is a red team’s foremost goal because it offers easy access and a low risk of being caught. Red teams using legitimate remote access solutions can conduct their command, control, exploitation, and exfiltration activities under the guise of properly authenticated sessions. In addition, the red team’s system is not subject to the same security restrictions or controls as other corporate systems. This means that the team does not have to deal with antivirus, application whitelisting, and other intrusion detection software interfering with their activities. Two-factor authentication obviously raises the difficulty to compromise these remote access solutions, and challenges red teams to subvert the two-factor protections in place.

In difficult situations like these, it’s best to adopt an Occam’s razor approach and use the most straightforward method to acquire the credentials we need: ask the victim to enter them for us. The perfect trap happens to be the simplest to set.

In Figure 1, we have two different VPN login pages. One is a corporation’s legitimate site, the other is a fake operated by a crafty red team. Can you spot the difference?

No? Neither can your users. Using tools such as the Social-Engineer Toolkit (SET), anyone can effectively replicate an external page by changing the HTML’s local resource locations (“/home/image/logo.png”) to external references (“mycompany.com/home/image/logo.png”). With a compelling phishing scenario, you can guide the victim to your visual clone VPN authentication page and get all the information you need to make your own connection: username, password, and even the token code!

If the red team can move quickly enough, they can take credentials submitted to the fake VPN page and use them to authenticate to the actual VPN. As shown in Figure 2, this can be accomplished by redirecting the login submission to a PHP script that will write the username, password and other metadata (IP address, HTTP User-Agent, time of submission) to a log file that the red team can monitor and wait for a user to provide their two-factor credentials.

Once the red team authenticates to the VPN, they can attempt to escalate privileges and access sensitive data before the security team can detect and respond to the phish. Internal network reconnaissance through scanning, identifying applications and systems that the victim user can access, and even LLMNR/NBT-NS spoofing offer potential avenues to turn a VPN session into full compromise of the environment.

The Mandiant Red Team leverages SpiderLabs’ Responder as our LLMNR/NBT-NS spoofing tool of choice. Responder is a powerful Python utility that sends fake responses to LLMNR/NBT-NS requests to fool systems and services into providing password hashes and, in some cases, plaintext credentials. Running Responder on a VPN subnet for even a few minutes (as exemplified in Figure 3) can provide numerous domain accounts and password hashes. Common passwords and passwords with low complexity requirements can have their hashes cracked in seconds, giving the red team the plaintext credentials they need to continue their lateral movement and privilege escalation.

How to prevent this attack

1. Ensure that your VPN solution enforces a single authenticated session per user. There is limited justification for allowing multiple, concurrent sessions (with different source IP addresses) for a single user account.
2. Conduct regular auditing of VPN authentication logs to identify anomalous login activity, such as flagging login events originating from TOR exit nodes.
3. When responding to phishing incidents, take the potential loss of credentials seriously. If there is reason to suspect credentials were lost, make sure to reset all affected credentials and review access logs for evidence of malicious activity.

2) XSS in Sheep’s Clothing

VPN login pages are valuable targets because their image evokes a sense of familiarity and security with the users. If you authenticate to the VPN every day using a web page such as the one shown in Figure 1, odds are that you’re not inspecting your traffic or the website code to verify your credentials are going where you think they are. The scary truth is that real-world attackers have already started capitalizing on this implicit trust and have been discovered leveraging JavaScript-based credential harvesters on corporate VPN login pages.

Let’s discuss how this attack works. First, the red team exploits a vulnerability to write code to the authentication page (or a page that gets loaded by the authentication page), such as the vulnerability discussed in CVE-2014-3393. The red team then adds code to the authentication page to execute malicious JavaScript from a system they control and waits for unsuspecting users to load the page and authenticate. An example of such code is shown in Figure 4.

The victim user does not notice anything different. This tiny bit of code loads file “stealcreds.js” from “https://www.evil.com” and executes its code into your legitimate user’s web session (i.e. the JavaScript code runs in the context of the user’s browser). By using an external resource, we minimize code introduction on the front page and allow ourselves the ability to dynamically update our payload each time a user’s browser requests the resource. Figure 5 shows a snippet of code we use to compromise user credentials.

Using an internal frame insertion and a POST-back setup to “https://www.evil.com/pwnd.php”, the red team rigs the normal VPN login page to POST user credentials every time they are entered in a session where the “stealcreds.js” resource is loaded. By attacking the VPN solution itself, the red team can disguise themselves as legitimate users remotely connecting to the environment through the authorized remote access solution.

How to prevent this attack

Monitor access to your two-factor solutions and conduct regular examinations of any code served to users to ensure that no tampering has occurred. Two ways to accomplish this are to use a file integrity monitoring solution to monitor files served by networking devices and by conducting periodic scans or assessments of public infrastructure to identify changes.

3) 1.5-Factor Authentication

Another popular VPN configuration is a “host check” process as a requirement to connect to the corporate VPN. Typically, this process verifies the host’s domain and some basic configuration stats, such as whether or not antivirus signatures have been updated. Some companies view this “host check” process as a pseudo-second factor (hence the 1.5 factor title). The unfortunate issue with host inspections is that they rely on the host being trustworthy.\

We performed a red team assessment on a client that used a VPN device that required only a single-factor password authentication in addition to the “host check” process. Every piece of information examined by the “host check” process was provided in a web request and minimally obfuscated with Base64 encoding – fair game to anyone using a proxy. An example of the kind of data expected, complete with registry paths checked and the “correct answers,” is shown in Figure 6.

Not only does the “host check” process rely on trustworthy answers from potentially untrustworthy sources, it even provides what it’s inspecting within the request! At a minimum, a red team can attempt to modify the features examined during the check. Even worse, the response to the “host check” was a simple POST containing whether each inspected element was “correct” or not – another easy target for red teams using web proxies such as Fiddler or Burp.

We used a combination of Fiddler and Python to modify POST requests to generate a valid policy inspection report and fool the “host check” into approving us, as shown in Figure 7.

Another common form of 1.5-factor authentication is leveraging usernames and passwords in combination with a computer certificate. Some companies choose to authenticate both the user and their device before allowing remote access. While this is a good approach, requiring single-factor credential authentication in combination with a locally installed certificate is not. It is trivial for an attacker to gain access to an end user system, export the locally installed computer certificate, and install the certificate on their own virtual system.

How to prevent this attack

Do not use single factor or 1.5-factor authentication for any remote access. Only strong multi-factor authentication (something you know, something physical you have, or something you are) should be implemented. If you want to leverage computer certificate in conjunction with credential-based authentication, make sure you use multi-factor credential-based authentication in conjunction with a client-side certificate.

4) Email is the Enemy

Digital tokens often require a synchronization code that is unique to each user’s token in order to function properly. The synchronization code and algorithm is what ensures the token that is displayed to the user matches the token the authentication server expects. Many companies use a simple IT-friendly process of sending users a notice via email when their request for VPN access is approved. These emails often contain the “seed” key and instructions for installation. Unfortunately for the security team, users often read this email and forget to delete it, leaving the literal keys in the users inbox, ripe for an attacker to steal.

One of the steps in the Mandiant Red Team methodology is to search email inboxes (including.PST and .OST files on disk), for these types of sensitive and useful files. In most cases, we use a simple PowerShell script to search the user’s mailbox and related files for evidence of RSA soft-token .sdtid files.

The .sdtid file is essentially a password-protected certificate of authenticity you can use to set up a digital (“soft”) token on your local host. With the combination of both the .sdtid file and password (often located in the same email sent by your IT Help Desk, stored in a local text file, or stored in a local password manager), the red team can replicate a user’s soft-token and use a simple keylogger to identify the user’s PIN. After that, the red team gains two-factor authenticated access to the network at any time, day or night, masquerading as a legitimate user.

How to prevent this attack

Innocuous things such as a soft certificate in an email can help an attacker gain access to a company. “Soft” tokens are often easier targets for compromise than physical devices, so keep that in mind when you decide what and how you are securing with two-factor. Train your users to securely delete sensitive information once they’re done with it. Train your IT staff to not include passwords in the same emails as the .sdtid file or not to include the .sdtid in an email. For instance, require your users to authenticate to a website to download the .sdtid file.

5) Leaving the Vault Key under the Doormat

“Password vault” is a phrase that will inspire groans from even the most hardened red team veterans. A properly configured password vault is a powerful tool to restrict and monitor the usage of credentials in an environment. It reduces exposure of passwords to traditional tools such as Mimikatz and Windows Credentials Editor (WCE). After all, dumping passwords becomes a tired game when all administrative credentials change every time they are checked in and out of the vault.

Add a multi-factor-enabled RADIUS authentication server with physical tokens in front of that password vault and you’ve created a real challenge for a red team. In order for a red team to get a temporarily valid password, they now need to reproduce a user password, PIN and physical token code – all at once! Even with local access via a backdoor and a keylogger, the red team likely still won’t be able to enter that token code in time before the RADIUS server shuts down access because the token has already been used.

However, rather than give up at bypassing the highest level of password security that can be realistically implemented, a red team can return to the fundamental rule of security: your security chain is only as strong as its weakest link, and that weakest link is almost always the people involved in the processes. This is where we start to explore the unsecured Windows file share.

Unsecured Windows file shares have served our Red Team well over the years. We almost always get at least some of the data necessary for privilege escalation and sensitive data theft by combing through unsecured file shares. Unfortunately for security teams, Windows makes it incredibly easy to share files and folders in a domain and for a user or red team to discover those shares and scrape through them for valuable information. PowerView’s “Invoke-ShareFinder” PowerShell script is a great utility that offers a fair amount of scalability in the hunt for shares of interest. This tool can help you discover valuable information, including interesting shares such as one we recently found named “Security”. As expected, this share was readable to any user with valid domain credentials.

In some cases, you may find yourself looking at a document such as the one shown in Figure 8.

Passwords discovered in these types of documents give red team’s direct access to the authentication server, which means they can control how the authentication process works. With the password to the account used to administer the two-factor authentication solution, the red team can grant themselves – at least temporarily – access to any existing account’s password vault. As the next section shows, with this level of access comes new techniques to further entrench the red team’s control of critical infrastructure in an environment to maintain access and evade detection.

How to prevent this attack

Restrict users’ abilities to create arbitrary open Windows shares by restricting local administrator permissions. There is almost no reason for real information to be stored in a location where it is accessible to “Everyone” (i.e. any domain user). Use Active Directory Groups to your advantage to define tight access controls where sensitive information may be. Consider implementing a Data Loss Prevention (DLP) solution that maintains encryption of sensitive files and audits their access and modification. You can even take the “Invoke-ShareFinder” script and do a quick self-assessment in a day or two - keep an eye out for shares on web servers or corporate data shares.

6) A Two-Factor Emergency

Many two-factor authentication products offer what are called “Emergency Access” codes, an authentication mechanism designed to allow VPN access after a user has lost their token and remote access is critical. An example screenshot depicting emergency access token code management is shown in Figure 9.

As the screenshot above shows, the system offers a fixed “second factor” of authentication – perfect for the red team that wants stealthy remote access to the environment. These emergency access codes are particularly dangerous because they can be configured with no expiration date, allowing for a quiet return into the environment at a later date.

A word of caution for eager red teams: while creating your own profile/token using this access is tempting, there is typically more alerting and auditing around the creation of profiles than the modification of existing profiles.

As every vendor solution is different, we’ll leave it as an exercise to the reader to determine the proper method of implementing “Emergency Access” in their target environment. Keep in mind that if you’re using an existing user’s account, emergency access may not always be enough – the PIN is required in addition to the emergency access code. Fortunately, most vendors offer the option to quickly clear the PIN and set a new one, as depicted in Figure 10.

How to prevent this attack

Implement regular two-factor application auditing. Log the user that logs in, the date of the login, where the login originated, and the changes that were made, especially if the changes involved the creation of new user profiles. Enforce policies that disallow emergency token access except in the direst of needs, and even then only allow this access for a short period. We highly recommend you perform a quick audit of all your two-factor authenticated accounts right now – you might be surprised what you find.

Conclusion

There are many attack paths and vectors that veteran red teams can use to bypass “secure” security controls. At Mandiant, our Red Team takes advantage of our front line intelligence, as well as the latest tools, tactics, and procedures we see our adversaries leverage in their own breaches.

Unfortunately, many companies place too much trust in security solutions such as two-factor authentication without taking the necessary steps to secure the underlying technologies. This oversight could allow attackers and red teams alike to subvert two-factor authentication implementations even when they’re implemented properly.

Special thanks to Andrew Burkhardt, Evan Peña, and Justin Prosco for their help with the content of this blog.