Here is a case study from a financial institution that implemented “two-factor authentication” for remote access. Our setting is the type of old-school, on-premise, Windows shop that is nearing extinction: fixed workstations managed through Active Directory, which would have felt right at home in the 1990s along with the Macarena. In a rare concession to the novel idea of employees having to access their work PC while they are not physically in the office (credit COVID for this modern epiphany) the IT department has rolled out a VPN and enabled remote-desktop access. In order to access their assigned workstations, employees jump through two layers of access control:

1. First, they connect to the corporate VPN, authenticating with their AD domain credentials (username + password) augmented by TOTP two-factor authentication
2. Once on the VPN, they can use one of the standard remote-desktop clients to connect to their specific workstation, again authenticating with domain credentials.

When this enterprise is going through their ritualistic yearly review of IT controls, an auditor is very likely to ask:

“Does remote access to internal systems require multi-factor authentication?”

Based on the above description, one expects this IT department to confidently respond in the affirmative and the auditors to quickly rubber-stamp that answer after cursory validation.  The subtle flaw in this model— common to legacy systems where second factor authentication has been bolted-on to satisfy some compliance requirement without much consideration for the relevant threat model— is likely to escape notice.

Mix-and-match authentication

The core issue is a disconnect between the two different authentication steps performed in series. There is no consistency check verifying whether the user connected to the VPN is the same one connecting to a specific workstation. In other words, one can connect to the VPN as Alice using Alice’s domain password & OTP credentials, then login to Bob’s workstation using Bob’s domain password. While that may look like an edge case, it points to an intrinsic weakness: once an attacker can fully impersonate any account (second factor included) every other account is only protected by a password alone.

From the threat actor perspective: if the objective is getting access to the documents on the CEO’s workstation, it is not necessary to compromise the CEO’s second-factor authentication. Instead this “mix-and-match” combination is sufficient:

• Password + 2FA for any random employee
• Password for the CEO

Does this qualify as two-factor authentication? Under a charitable interpretation, the answer is yes: the attacker still has to satisfy 2FA for some employee. Under a more strict interpretation, it falls short of the intended security guarantee: they did not have to defeat the 2FA associated with the CEO account. Viewed in terms of probabilities, the situation looks much better for the attacker: in a company with thousands of employees, there is a good chance some employee will get phished for both factors or have their device compromised by malware. (At which point, even phishing-resistant authentication is useless; the threat actor can ride the active session once the legitimate user completes authentication using as many convoluted steps as necessary– tapping the hardware security dongle, connecting their smart-card or performing an interpretive dance.)

Mitigations

As with most security challenges, correctly enforcing multi-factor authentication is more challenging than bolting on the half-baked version. There are a few options here, ranging from window-dressing to fully robust:

• Alerting after the fact: correlate VPN events against remote desktop access events. This will not prevent mix-and-match authentication but it can detect unauthorized access after the fact. Depending on the latency of aggregating logs, detecting anomalies and the maturity level of incident response for the enterprise, there is a fighting chance the breach can be contained before significant damage is done.
• Enforce two-factor authentication on endpoints. Third-party offerings such as Duo Authentication for Windows Logon allow enforcing MFA as part of the remote-desktop logon, where the presence of the second factor counts the most. (Depending on what is accessible once on the VPN, one could even argue the original design had it completely backwards: if the only thing employees can do is access their own workstation over RDP, they would have been better off with a single-factor VPN while saving the proper MFA enforcement at the endpoint.)
• Implement proper two-factor authentication at Active Directory layer. This is the most comprehensive solution, based on a little-known fact: AD has supported phishing-resistant two-factor authentication with cryptographic hardware for 20+ years— long before consumer-grade/watered-down FIDO & its ilk existed. Based on the standardized PKINIT extension to Kerberos and smart-cards, this is widely used in high-security environments including the US government CAC & PIV programs. Realistically, the complexity of operating a PKI and issuing smart-cards places this far outside the meager capabilities of most IT departments likely to exist within the confines of a traditional financial institution.

CP