Secure MFA from Phishing Proxies with F5 BIG-IP APM and Distributed Cloud Bot Defense

A real-time phishing proxy attack begins with a phishing message delivered via text, email, or a web page. The phishing message contains a link taking the user to a domain controlled by the attacker that is designed to proxy all requests through to the target application. From the perspective of the user, everything looks legitimate, except the domain name, which is usually chosen to closely resemble the real one. 

Fooled by the phishing proxy, the user enters their credentials. In the case of single factor authentication, this entry of credentials is sufficient for the attacker to gain access to the account. In the case of 2FA, the real-time phishing proxy sends the credentials to the legitimate application, triggering the 2FA request. Unfortunately, the user, still believing that they are engaging with the legitimate application, will likely go along with the 2FA, agreeing to whatever request is made. 

Reverse phishing proxies can compromise nearly all forms of 2FA:

• 2FA based on short message service (SMS). In an SMS 2FA, the authentication system triggers a text message to the user with a one-time passcode (OTP), which the user types into the app. During a phishing proxy attack, the user types the passcode directly into the malicious app, which then proxies it to the legitimate app, thereby granting the criminal access. The same logic applies to 2FA when the OTP is sent via email. If the mechanism involves the user typing the OTP into an app, a real-time phishing proxy attack can gain access to that OTP.
• Hardware token 2FA. Hardware tokens, which are physical devices that generate keys at fixed-time intervals following a cryptographic algorithm, serve the same purpose as the OTPs in SMS-based 2FA. Looking at the device, the user types the key into the application. When fooled by a real-time phishing proxy to type that key into a malicious application, the attacker gains access to the account. In a sense, delivering the token via SMS, email, or hardware makes no difference to the real-time phishing proxy. (In contrast, FIDO2/U2F hardware keys are not phishable because the browser collaborates with the hardware key in origin binding.)
• App-based 2FA. Mobile authenticator apps such as Google Authenticator and Duo Mobile generate tokens much in the same way as hardware devices. Again, users are expected to type the token into the app. If the user is fooled into typing the token into a malicious app, the attacker gains access to the real application.
• Push-based 2FA. Certainly, any 2FA mechanism that involves the user typing an OTP into an application can be broken by fooling the user into typing the OTP into a malicious application. But what about push-based 2FA, which does not require the user to type an OTP into an application? Rather, in a push-based system, the application, upon receiving a login request, triggers a request to a push notification system that results in the user receiving a notification on their mobile device. The user just has to click once to accept the request. Once that occurs, the push notification system makes an API call back to the application indicating that the push authentication has been successful, and the application completes the authentication process, granting access to the user. In this scenario, the phishing proxy never receives the token because it is passed directly to the application. Nonetheless, the criminal still gains access to the account because the application will eventually deliver the authenticated session token to the application through the proxy, which enables the attacker to capture it and use it to access the application using the victim’s identity.

We should expect real-time phishing proxy attacks to rise because phishing proxies as a service (PhaaS)—such as EvilGinx, Muraena, and Modlishka—make it remarkably easy for criminals by providing everything they need to launch these attacks:

• Phishing email templates that fool users into visiting malicious sites
• Hosted web servers that mimic target apps
• Databases to store stolen credentials
• Real-time monitoring
• Defensive mechanisms to thwart security researchers
• Documentation and customer service

Traffic that passes through a phishing proxy has distinctive characteristics: The domain name will not match that of the real site, the HTML and JavaScript may be altered to accommodate the domain name change, and the timing and TLS signatures may be altered. Using many of the same client-side and network signals used to distinguish bots from humans, Distributed Cloud Bot Defense can detect the anomalies that distinguish real-time phishing proxies and thereby resolve one of the most common threats against MFA.

BIG-IP APM is a flexible, high-performance access management solution for apps and APIs. It provides authentication services to applications by connecting enterprise identity services, such as Active Directory, LDAP providers, and RADIUS, to modern authentication protocols, such as SSO, access federation, OAuth 2.0, SAML, and OIDC. 

BIG-IP APM includes support for step-up authentication, providing SMS-based OTP 2FA out of the box. Moreover, BIG-IP APM integrates with most leading MFA solutions, including those from Cisco Duo, Okta, Azure AD, and others. 

Because of the central role that BIG-IP APM plays in the authentication process of many enterprises, it is an ideal location to implement Distributed Cloud Bot Defense to protect users from real-time phishing proxy attacks that use automation to bypass MFA protections.