Everything You Need to Know About Evil Proxy Attacks and MFA Bypass
Attackers use a malicious proxy server to intercept, monitor, and manipulate communication between a client and a legitimate server, often to steal credentials, session tokens, or other sensitive information.
Some services provide “Phishing-as-a-Service” (PhaaS), offering attackers ready-made tools and infrastructure to conduct phishing campaigns. These services simplify the process of deceiving individuals into providing sensitive information, such as usernames, passwords, or financial details, by automating key aspects of the attack.
An Evil Proxy can be particularly dangerous as it uses Reverse Proxy and Cookie Injection methods to bypass two-factor authentication (2FA or MFA) from major vendors such as GitHub, Apple, Okta, Microsoft, and Google.
How it works
Evil Proxies operate on the Reverse Proxy principle, where the attacker leads the victim to click a malicious link that appears to look like a legitimate login page.
When the victim attempts to log in, the Evil Proxy forwards the authentication request to the actual service, simultaneously capturing the two-factor authentication (2FA) credentials through Cookie Injection. Cookie injection is a technique where attackers manipulate or insert session cookies to impersonate a user and bypass authentication mechanisms.
To increase their chances of success, attackers impersonate trusted services and apps like Concur Solutions, DocuSign, and Adobe by leveraging legitimate registration processes available to the public.
The phishing URL including DocuSign is undetected by Virus Total
Here’s another example of how a phishing URL created by the attacker and sent by a legitimate DocuSign sender bypasses the Email Gateway security tool by using the “DocuSign” application as the email sender.
Email Security Gateway determined the phishing URL as clean
EvilProxy in Action
To show how easy and effective EvilProxy attacks are, we demonstrate an attack flow using the evilginx2 phishing framework. This attack shows how users are tricked into sharing their credentials, even when two-factor authentication is enabled. The attack phases are as follows –
- Create a Fake Login Page: Set up a duplicate of the legitimate login page.
- Configure Proxy Server: Use Evilginx2 to set up a proxy to intercept traffic. This can be achieved with or without a Man-in-the-Middle (MitM) attack.
- Send Phishing Link from a Legitimate App: Disguise a malicious link as a trusted URL (e.g., docuSign.com) by leveraging legitimate registration processes that are available to the public, and were sent to the victim by the trusted application email (e.g., dse_na2@docusign.net).
- Redirect to Fake Page: The victim clicks the link and is sent to the fake login page.
- User Enters Credentials: Victim enters their login information, believing it’s real.
- Capture Credentials: EvilProxy logs the entered credentials.
- Forward MFA Request: If MFA is enabled, EvilProxy forwards the MFA prompt to the attacker.
- Attacker Retrieves MFA: The attacker can intercept (ex. with a MitM attack) or socially engineer the victim to share the MFA code.
- Submit MFA Code: The attacker submits the MFA code to complete the login process.
- Relay Login to Real Site: Forward the credentials and MFA code to the legitimate site to complete the login.
- Exfiltrate Data: The attacker uses the credentials and MFA to access the victim’s account and steal data.
- Get Cookies from EvilProxy: Capture session cookies from the fake login process.
- Insert Cookies into Real Site: The attacker inserts the captured cookies into their real session to maintain access without needing to log in again.
The entire attack can be easily visualized by the flowchart below:
How to Detect & Block an EvilProxy Attack
Okta Identity Threat Hunting
Use your identity management logs to identify and detect phishing attempts. Here are some explanations of Okta messages that help detect and identify potential threats:
- Okta – AiTM phishing attempt blocked by FastPass
This message means that the Okta phishing detection with FastPass origin check has been raised. Okta provides platform-wide detection for when users enrolled in FastPass fail to authenticate via a real-time adversary in the middle (AiTM) phishing proxy.
Event Properties:
Cloud Platform: Okta
okta.outcome.reason: “FastPass declined phishing attempt”
- Okta – Abnormal session using the same dtHash/2FA token
This rule identifies a session Hijacking attack where the attacker is able to access the browser cookies of an authenticated Okta user by searching for a dtHash that has been used by other users.
Event Properties:
Cloud Platform: Okta
Event Name: (“policy.evaluate_sign_on” OR “user.session.start”)
Error Outcome: “Success”
Threshold: Results aggregated by okta.debug_context.debugData.dtHash >= 2
- Okta – User reached the rate limit on failed MFA attempts
This message means an Okta user account has reached the rate limit on multiple failed (MFA) authentication attempts. A cumulative limit of 5 unsuccessful authentication attempts is enforced over a rolling 5-minute period.
Event Properties:
Cloud Platform: Okta
Event Name: system.operation.rate_limit.violation
Error Message: Too many OTP verification attempts for Enter a code factor
Okta is usually successful in detecting and blocking phishing attempts
Web Traffic Logs It is also important to monitor your organization’s network traffic logs to identify and analyze authentication requests. Detect where the domain of the request differs from the domain specified in the iss (issuer) parameter to identify potential security issues.
Example of two consecutive requests:
First Request:
okta.loginmt.com/app/userhome?iss=https://okta.loginmt.com&session_hint=AUTHENTICATED
This request seems to be legitimate, as the domain of the request and the domain specified in the iss are the same.
Second Request:
malicious-okta.com/app/userhome?iss=https://okta.com&session_hint=AUTHENTICATED
In the second request, malicious-okta.com – is not equal to okta.com because they are entirely different domains. Despite the former containing “okta” in its name, it could be used for malicious purposes.
Here is a simple Python script to validate that the domain in the request is the same as the domain specified in the iss (issuer) parameter:
import re
# Example URLs to test
urls = [
"https://okta.loginmt.com/app/userhome?iss=https://okta.loginmt.com&session_hint=AUTHENTICATED", # Legitimate
"https://malicious-okta.com/app/userhome?iss=https://okta.com&session_hint=AUTHENTICATED", # Potential Malicious
"https://secure-okta.io/app/userhome?iss=https://secure-okta.io&session_hint=AUTHENTICATED", # Legitimate
"https://fake-okta.net/app/userhome?iss=https://okta.com&session_hint=AUTHENTICATED" # Potential Malicious
]
# Improved regex to extract host and iss domains
pattern = r"^(?:https?:\/\/)?([a-zA-Z0-9.-]+)(?:\/|$).*?[&?]iss=https?:\/\/([a-zA-Z0-9.-]+)"
print("Malicious URLs:")
for url in urls:
match = re.search(pattern, url)
if match:
host_domain = match.group(1)
iss_domain = match.group(2)
# Flag malicious if host and iss domains don't match
if host_domain != iss_domain:
print(f"- {url} (Host: {host_domain}, Iss: {iss_domain})")
Threat Intelligence and OSINT
Another method in mitigating potential threats is to utilize Threat Intelligence sources in identifying malicious actors and assess risks associated with suspicious domains. It also investigates known domains linked to harmful activities and searches for domains that are similar to your organization URL.
Integrating Indicators of Compromise (IOCs) into various systems, such as SIEM, SOAR, Email gateway, EDR, within an organization’s security infrastructure is crucial for enhancing threat detection and enabling fast response capabilities.
- Indicators of Compromise (IoCs) – EvilProxy
The Indicators of Compromise (IoCs) for EvilProxy are continually updated as new threats are detected, for the latest information, refer to this direct link to the IoCs.
Flow of how attacks that initially appear clean are later identified as malicious
The Email Gateway and Web Traffic monitoring systems initially flagged the attack domain as “clean,” meaning they did not detect it as a threat. The Identity Management system, however, identified suspicious activity related to this domain and partially blocked it based on the detected anomaly.
Using this information, the SOAR system can dynamically classify the domain as “malicious” and take action to block it fully, enhancing the security response.
Microsoft 365
There are a number of steps that can be taken to protect against potential attacks through proper configuration of Microsoft Office:
- Organizations should implement conditional access through their Microsoft Office License, limiting access to specific devices, locations, or other resources.
- Deny access to suspicious devices by configuring Microsoft Intune to deny access to untrusted devices.
Enhance Employee Awareness
Educating employees about security risks, including phishing and smishing tactics can go a long way towards the prevention of successful attacks. Regular training sessions, gamified events, and simulated attacks can all significantly reduce the risk of compromising your organization.
Additionally, employees should be aware of recognizing warnings, such as certificate mismatch warnings in the browser, which can indicate man-in-the-middle attacks.
Least Privilege Principle
The concept here is that users, processes, and systems should only be granted the minimum levels of access necessary to perform their tasks. Benefits of this approach include:
- Grants users access only to the resources necessary for their specific organizational roles.
- Minimizes potential damage if an account is compromised.
- Enhances overall security by reducing the risk of unauthorized access to sensitive information.
- Decreases the attack surface, making it more difficult for malicious actors to exploit vulnerabilities.
- Requires regular reviews and updating of access permissions as user roles and responsibilities evolve.
By limiting permissions, this principle helps minimize the potential damage that can occur if a system is compromised.
Conclusion
Threat actors are continually looking for new methods to steal legitimate user credentials and gain entry to user accounts, aiming to access sensitive information. New methods and techniques are constantly being adapted to counter the latest security techniques and methodologies, such as multi-factor authentication.
As we have seen, there is no protective scheme, not even MFA that acts as a silver bullet against all possible threats. That’s why it’s probably a good idea to take a tour or schedule a demo to see how JFrog’s Advanced Security solutions can protect your organization from potential attacks today and in the future.