Context
Here at Eye Security, we have observed a disturbing increase in security breaches where multi-factor authentication (MFA) has shown itself to be inadequate in preventing unauthorised access. Despite the presence of well-known attack patterns engineered to bypass MFA, certain techniques are becoming more prevalent as a larger number of companies adopt MFA as a security measure. This underscores the urgent problem of phishing, which has grown significantly more important, as disclosed by a recent study conducted by APWG (Anti-Phishing Working Group), an organisation committed to studying phishing risks since 2003.
2022 was a record for phishing, with the APWG recording more than 4.7 million attacks. From the start of 2019, the number of phishing attacks has increased by over 150% annually. Among these MFA phishing tools is one known as EvilProxy. In this article, we explain our approach to developing a solution for this issue.
In quantifying the impact of phishing attacks on companies, the damage caused by Business Email Compromise (BEC) is often accounted for. In these attacks, threat actors gain unauthorised access to an employee's email account and undertake various actions to divert funds to their own accounts. Between 2013 and 2016, BEC attacks resulted in an estimated total loss of $5.3 billion averaging €200,000 per attack.
EvilProxy
There are many different types of EvilProxy. Various Github projects can be found, such as Evilginx 2.4, or even Phishing as a Service (PaaS) providers that offer this service for a few hundred euros per month, complete with a dashboard to coordinate these attacks. This provides less technically adept attackers with the opportunity to use this method. Resecurity has written a thorough blog post about how these PaaS providers operate.
Source: EvilProxy Phishing-as-a-Service with MFA bypass emerged in dark web
However, for the operation of EvilProxy, this study has used Evilginx 2.4. Later, we will discuss Evilginx 3.2 more - the most recent version. In version 2.4, basic templates for platforms such as M365, Citrix or Okta are no longer provided. Yet, these can be easily created using the examples that are provided here.
In essence, an EvilProxy operates as follows:
-
The victim receives a phishing email with a link.
-
This link usually directs to major SaaS providers such as Microsoft, Google, Citrix, or Okta.
-
The link leads to a website where the victim must enter their login information.
-
These details are then input into the legitimate service to subsequently send back the MFA response to the user.
-
When the user resolves this, the attacker then intercepts the session token.
-
With this token, the attacker can log into the SaaS application without using MFA.
If you want to learn more about how Evilginx 2.4 works, Aon has written this a blog post about it.
Source: Bypassing MFA a forensic look at Evilginx2 Phishing Kit
Office logging
To initiate an investigation, the focus was placed on identifying potential methods for detecting an EvilProxy. Within a Microsoft environment, there are various points where logging occurs. As regular users engage in their daily tasks, they interact with multiple logging points. However, there are also user and system accounts that are solely used for authentication. As a result, Azure Active Directory sign-in audit logs emerge as the most suitable location to investigate.
These logs can be retrieved through various means. They can be accessed via the GUI by navigating to Azure AD → Users → Sigin-logs, or they can be obtained using Microsoft's Graph API. When retrieving this logging information, the following JSON structure is provided:
{
"id": "66ea54eb-6301-4ee5-be62-ff5a759b0100",
"createdDateTime": "2020-03-13T19:15:41.6195833Z",
"userDisplayName": "Test Contoso",
"userPrincipalName": "testaccount1@contoso.com",
"userId": "26be570a-ae82-4189-b4e2-a37c6808512d",
"appId": "de8bc8b5-d9f9-48b1-a8ad-b748da725064",
"appDisplayName": "Graph explorer",
"ipAddress": "131.107.159.37",
"clientAppUsed": "Browser",
"correlationId": "d79f5bee-5860-4832-928f-3133e22ae912",
"conditionalAccessStatus": "notApplied",
"isInteractive": true,
"riskDetail": "none",
"riskLevelAggregated": "none",
"riskLevelDuringSignIn": "none",
"riskState": "none",
"riskEventTypes": [],
"resourceDisplayName": "Microsoft Graph",
"resourceId": "00000003-0000-0000-c000-000000000000",
"status": {
"errorCode": 0,
"failureReason": null,
"additionalDetails": null
},
"deviceDetail": {
"deviceId": "",
"displayName": null,
"operatingSystem": "Windows 10",
"browser": "Edge 80.0.361",
"isCompliant": null,
"isManaged": null,
"trustType": null
},
"location": {
"city": "Redmond",
"state": "Washington",
"countryOrRegion": "US",
"geoCoordinates": {
"altitude": null,
"latitude": 47.68050003051758,
"longitude": -122.12094116210938
}
},
"appliedConditionalAccessPolicies": [
{
"id": "de7e60eb-ed89-4d73-8205-2227def6b7c9",
"displayName": "SharePoint limited access for guest workers",
"enforcedGrantControls": [],
"enforcedSessionControls": [],
"result": "notEnabled"
},
{
"id": "6701123a-b4c6-48af-8565-565c8bf7cabc",
"displayName": "Medium signin risk block",
"enforcedGrantControls": [],
"enforcedSessionControls": [],
"result": "notEnabled"
}
]
}The beginnings
One of the initial findings revealed that Useragents are not a reliable method for detecting EvilProxy login attempts. Approximately half of the EvilProxy login attempts were able to replicate the Useragents of the original users.
Due to the proxy on a VPS, login attempts originating from an EvilProxy are always associated with IP addresses that the users have never used before. This contrasts with legitimate login attempts, which often originate from familiar IP addresses, such as a users' office or home network. By using external information from services like http://vpnapi.io or http://ipinfo.io , we can assess the risk posed by these IPs.
Microsoft can distinguish between a login attempt originating from a browser and a one originating from a Microsoft application. Since a malicious proxy can only get access through the browser, we can filter based on this criterion. If an application is used instead of a browser, the following field inside the sign-in log will be present:
"clientAppUsed": "Mobile Apps and Desktop clients",Another noteworthy observation is that most EvilProxies use domain office.com as a method to prompt users to login. This can be traced back from one of the login fields as “OfficeHome”. Some other examples of this include: "Microsoft Forms", "Azure Portal," and the most common one: "Office365 Shell WCSS-Client."
First version
If we were to create an initial version of this analysis, it would look something like this:
if get_vpn_info(sign_in['ipAddress'], "vpn") == True:
if "OfficeHome" == sign_in['appDisplayName']:
if sign_in['clientAppUsed'] != "Mobile Apps and Desktop clients":
return TrueThe results of this simple rule-based detection are 42% precision and a recall of 62%. These numbers indicate a high number of false positives, making it less useful for our SOC specialists. To address this issue, we need to develop a 'whitelisted' list of already checked and known IP addresses.
Fortunately, there is another field that can help us. If the company uses Microsoft Intune, and has enrolled certain devices, valuable information can be found in the sign-in logs under the 'deviceDetail' section. This section provides details both from the User Agent and from Intune. Specifically, if a device is registered in Intune and marked as 'compliant,' the 'isCompliant' field will be set to True. In such cases, we can add the device to the whitelist.
"deviceDetail": {
"deviceId": "",
"displayName": null,
"operatingSystem": "Windows 10",
"browser": "Edge 80.0.361",
"isCompliant": null,
"isManaged": null,
"trustType": null
},If we incorporate that into our early version, we achieve a precision score of 85% and a recall of 62%. This shows significant progress in our detection capabilities. However, it's important to note that even with this improvement, we will still experience some missed EvilProxy attacks, indicating the need for further enhancements.
if sign_in['ipAddress'] in whitelist_ip:
return False
else:
if get_vpn_info(sign_in['ipAddress'], "vpn") == True:
if "OfficeHome" == sign_in['appDisplayName']:
if sign_in['clientAppUsed'] != "Mobile Apps and Desktop clients":
return TrueSecond version
EvilProxy attacks vary in the number of login attempts, typically ranging from two to five. This is because EvilProxies are often unaware of whether the targeted user has Multi-Factor Authentication (MFA) enabled, which impacts the login process. When a user enters their email and password, the EvilProxy initiates the login attempt. However, since MFA is enabled, the login flow on the Microsoft platform cannot be completed successfully. As a result, a second attempt is made, triggering an MFA challenge issued by Microsoft, which the user then resolves. This pattern repeats for all EvilProxies, as they are unable to achieve a successful login in a single attempt. The correlation of these multiple login attempts can be identified by the unique Correlation ID associated with each attempt.
For instance:
"correlationId": "d79f5bee-5860-4832-928f-3133e22ae912",To tackle this issue, we have devised a solution by appending the previous three login attempts to each individual attempt. By applying the same steps as in the initial version, we have refined our detection logic. As a result, we have achieved a precision rate of 72% and a recall rate of 85%.
These improved metrics demonstrate the effectiveness of our approach in identifying and mitigating malicious login attempts. With a higher precision rate, we can reduce false positives and ensure that legitimate login attempts are not mistakenly flagged as malicious. Additionally, the increased recall rate indicates that our detection system successfully captures a higher proportion of actual malicious login attempts.
if sign_in['deviceDetail']['isCompliant'] == True:
whitelist_ip.append(sign_in['ipAddress'])
if sign_in['ipAddress'] in whitelist_ip:
return False
else:
if get_vpn_info(sign_in['ipAddress'], "vpn") == True:
if "OfficeHome" == sign_in['appDisplayName']:
if sign_in['clientAppUsed'] != "Mobile Apps and Desktop clients":
return True
if sign_in['previous_logs'] != "":
for log in sign_in['previous_logs']:
if log['ipAddress'] == sign_in['ipAddress']:
if log['status']['errorCode'] != 0:
if log['status']['errorCode'] == 50072:
pass
else:
if log['clientAppUsed'] != "Mobile Apps and Desktop clients":
if "Office" in sign_in['appDisplayName']:
correletion_id.append(sign_in['correlationId'])
return TrueAs off today
Evilginx has undergone several updates since version 2.4. At the time of this writing, version 3.2 is available, introducing a variety of new features.
Gone are the ready-to-use templates
The creator of Evilginx has expressed the intention to provide a phishing framework designed for use by red teamers. Therefore, maintaining these phishing templates is time-consuming and not in line with that goal, leading to their removal from the tool.
Feature to circumvent automated phishing scanners
When a URL lands in a user’s mailbox, many email providers investigate the URL. A server opens and scans the HTML-content of the URL, subsequently quarantining suspicious emails.
The simplest method to bypass this is to temporarily hide the page. This must be done long enough to deceive the scammers into believing it is not a phishing URL, yet brief enough to ensure users see the phishing page.
A standard header to identify Evilginx
In the latest version of Evilginx, the HTTP headers now reveal the use of Evilginx through:
X-EvilginxThis addition aims to make it easier to track attackers using the tool's basic configuration. However, it's important to note that advanced users could remove this identifier, given the tool's open-source nature, potentially decreasing its effectiveness as a tracking method.
Prevention and mitigation
Fido2 authentication
Hardware-based authentication mechanisms that use FIDO2 protocols currently present as the most effective approach for mitigating the risk of bypassing MFA in all its forms. FIDO2 authentication leverages cryptographic keys that are pre-registered with domains, enabling users to authenticate themselves securely. The challenge posed by the service to the FIDO2 device includes specific details regarding the request's origin, such as the site's URL. As a result, any attempts to authenticate to fraudulent phishing sites using this mechanism should fail. Notable examples of FIDO2 authentication include hardware tokens like YubiKeys.
For implementing this there is also an option for Windows to make use of Windows Hello for Business.
IP-whitelisting and VPN services
An additional defence measure against EvilProxy attacks is to restrict connectivity by implementing IP whitelisting for trusted IP ranges and geographic locations. This approach involves creating a whitelist of approved IP addresses associated with the office network and hosting a VPN server at the office. With this setup, all users are required to establish a connection with the office network in order to sign in to SaaS or other applications.
Another option to consider is implementing geo-blocking by whitelisting a specific list of countries and denying access from all other countries. This method allows companies to limit connections to only trusted regions where their business operates. However, it's important to note that geo-blocking IPs can be bypassed by threat actors using VPN services, enabling them to appear as if they are connecting from a whitelisted country. Therefore, while geo-blocking can be a useful measure, it may not provide complete protection.
Phishing awareness
Regular phishing awareness campaigns are vital for companies to enhance their employees' ability to identify and mitigate phishing threats. These campaigns aim to educate employees to recognise and report malicious links or emails to the security team, thereby reducing the risk of successful EvilProxy attacks.
While it is important to acknowledge that awareness campaigns may not guarantee a 100% success rate, they still play a crucial role in strengthening a company's frontline defences. Phishing emails can closely mimic legitimate communications, making it challenging for even the most alert of employees to identify them. However, by instilling a strong culture of awareness and providing comprehensive training, companies help their employees to be proactive in detecting and responding to potential threats.
Microsoft Authenticator
As well as using Microsoft Authenticator, enabling Number Matching as also an option. This feature requires the user to enter a number displayed on the Authenticator app, reducing the risk of approving incorrect logins and adding an extra layer of security.
Furthermore, there is an option to display the geolocation of the MFA request. This allows the user to see the approximate location from where the request is being made. It's important to note that geolocation accuracy may vary due to the imprecise or unreliable nature of IP address locations. However, it can still provide some distinction between requests originating from different countries, such as France or the Netherlands. This geographical information can help companies mitigate potential risks without necessarily implementing geoblocking measures.
For detailed instructions on setting up these features, you can refer to this article.
Mobile application management
Another effective measure, instead of relying solely on IP whitelisting, is to enroll every device within Microsoft Intune. By doing so, companies can restrict access to their Office 365 environment only to devices that are compliant with their security policies. This ensures that only devices meeting necessary security requirements can establish a connection, mitigating the risk of EvilProxy attacks.
In some cases, companies allow employees to use work-related applications on their personal mobile devices. To address the privacy concerns associated with this, Microsoft offers Mobile Application Management (MAM) through Intune. MAM provides users with the option to create a work profile that is segregated from the rest of their device, which enhances both security and user privacy.
For more information about MAM.
Closing thoughts
In light of the rising security breaches, it is clear that technologies such as Multi-Factor Authentication (MFA), while useful, are not sufficient to entirely prevent unauthorised access. As we have seen in this analysis, there are various attacks that can bypass MFA. Furthermore, when Single Sign-On (SSO) is used and connected with other applications, an attacker can gain access not only to email environments but also to those applications. This expands the risks far beyond email traffic. It could lead to a total environment breach.
These attacks can cause substantial financial damage and, due to the availability of subscriptions to Phishing-as-a-Service solutions for a few hundred euros per month, attackers require little to no technical knowledge.
While we at Eye Security strive to detect and respond to these attacks, our shared focus should not only be on improving technical security measures, but also on enhancing organisational and procedural security practices. That's why we advise our customers to deploy more advanced authentication methods such as FIDO2 and hardware tokens like YubiKeys, to implement IP-whitelisting and VPN services and to create phishing awareness amongst employees. This combination of technical and human factors are a more comprehensive security approach.
The path to improved cybersecurity is not one-dimensional and requires a continuous effort to keep pace with the ever-changing threat landscape. Therefore, even on top of these measures, we must keep learning, experimenting, and refining our strategies to stay ahead of malicious actors.
