Analysis and detection of MITM phishing attacks bypassing 2FA: O365 use case
This SEKOIA.IO Threat & Detection Lab tackles a Man-in-the-middle (MITM) phishing attack.
This type of attack is frequently leveraged by attackers to harvest victims’ credentials, sometimes without even the victims noticing they have been phished [1], [2]. The aim of this lab is to play the attack, to search for traces left by the attackers by analysing the logs and to see how this type of attack can be detected and mitigated. As an example, we will focus on an O365 phishing scenario, from the mail click to the endpoint detection.
First, what is a Man-in-the-middle phishing attack?
In traditional phishing, to lure the victims and make them fill in their credentials, attackers used to develop HTML templates looking like sign-in pages of the service they wanted to impersonate. With some of them being convincing enough to make the victim fall into the trap. However, this technique became less efficient with the adoption by the targeted companies and services of the two-factor authentication (2FA) scheme which requires exactly two proofs for successful authentication. Even though the attacker captures a single 2FA answer, this would not be of a great help since the second proof has a short lifetime and would be required at each login attempt.
Soon after this security barrier had become largely implemented, new techniques bypassing the 2FA emerged, with some of them leveraging a man-in-the-middle attack.
In this scenario, three players are involved: the victim, the service and the attacker. The victim communicates with the service (e.g. google mailbox, O365 account), without knowing that a third party — in a man-in-the-middle position, is intercepting the communication between the two of them.
Ok, but how is it allowing to bypass 2FA?
Once a user is authenticated, a session cookie containing a session token is created. This one maintains the session state between the client and the server, so that the user remains signed-in and is not prompted to provide the credentials each time a new page is reloaded.
That being said, the key element of a successful attack relies on the interception of this browser’s session token by playing a MITM attack. This technique is commonly called Pass-the-Cookie.
Now, let’s dive into the whole use case scenario
To acquire more intel about the attack, there is nothing better than playing it and seeing what truly unfolds in the background. The phishing campaign will target a victim of an organization using O365 to harvest credentials and access confidential data.
Since it no longer surprises us to see that attackers are fond of offensive security tools (for more information, please refer to this article), we chose to work with one of them.
Some more or less efficient MITM frameworks are already available on GitHub such as Modlishka or Evilginx2. We found Evilginx2 way more powerful than Modlishka. This tool, fully written in GO implements its own HTTP and DNS server and allows you to set up a phishing page by working as a reverse proxy. It takes the request from the victim and sends it to the original website service, then takes the response form the website service and sends it back to the victim. Hence, Evilginx2 captures the data transmitted between the victim and the service including the authentication tokens of the session cookies. The captured session cookies can then be imported in a browser, giving full access to the victim’s account from wherever the attacker is located.
How does it work?
Since we are focusing on an Evilginx2 attack, let’s see its main technical features that may help us detect it. Note that this lab blogpost is not a tutorial for Evilginx2, since many of them are available on the internet. We will only focus on information that could be relevant to the detection.
Evilginx2 first requires a domain name, this domain will be displayed on the url browser when the victim clicks on the link. Consequently, attackers use copycat domain names to efficiently lure the victim. Evilginx2 also requires an external server where the installation will be hosted and the proxying will occur. For this purpose, the server must be listening on ports TCP 80 and TCP 443.
What makes Evilginx2 a highly-efficient tool is its configuration files named “phishlets” that are plain-text ruleset written in YAML format. These files designate which subdomains are needed to proxy a specific site, which credentials and cookies to capture, to which page you want to redirect the victim, etc. Each user of Evilginx2 can implement their own custom phishlets, but there is already a large panel of phishlets available on Evilginx2’s GitHub allowing to efficiently lure the victims into logging on Gmail, LinkedIn, O365, GitHub, Amazon, Outlook, Protonmail, Twitter, etc., and capture credentials.
Enough theory, let’s phish and check the logs
We set up the phishlet for O365 following the original tutorial, this step generated two URLs as follows:
‘login.O365.mydomainname.com’
‘www.O365.mydomainname.com’
So we had to update the external DNS records to point all traffic on these URLs to our phishing server regardless of the subdomain. We had to configure the domain with relevant A records and nameservers. Then, we got an SSL certificate for the phishing domain and its subdomains since Evilginx2 can create signed certificates using the client of Let’s Encrypt.
Eventually, we generated the lure URL to be sent in the phishing email, which let the victim connect to what looks like the real O365 sign-in page through the reverse proxy framework.
On the victims’ side, we can expect that a persuasive email leading the victims to click on the lure URL would lead them to trust the website and fill in their credentials since everything is set up to convince them it is legitimate: with an SSL certificate and the fact that the victim is landing on a page with the real content of the O365 login page as shown in the figure below. In this step, the only way for the victim to know that something is wrong is to notice that the domain name displayed in the browser is not the real O365 domain name.
As you can notice, with this level of lure, even experienced users could fall into the trap. After credentials and the second factor are filled in, we can redirect the victims to the real O365 website so nothing triggers their suspicion.
Now from the attacker’s perspective, the victim’s password and email were displayed on the server.
Then we looked for the session cookies. We were able to copy the token and paste it in the browser so we were successfully logged in the victim’s account.
Wow, ok, now show me the attack footprint!
For advanced threat protection, it is recommended to integrate O365 and Azure AD activity logs in a SIEM solution. Depending on the services that your organization uses, you can choose to export different types of logs such as Audit.SharePoint, Audit.AzureActiveDirectory, Audit.Exchange, etc. The full list is documented on Microsoft’s website.
You can find below an example of event logs and fields we chose to display on our SIEM SEKOIA.IO to study this specific case.
In this lab, we chose not to be exhaustive, but rather outline two types of detection that can be implemented specifically for this scenario.
First, let’s hunt
The first approach that can be used to detect this threat is to detect the tool itself: Evilginx2.
First, let us tell you a few words about this: we have developed trackers for all the tools frequently used by attackers from cybercriminals to APT threat actors, such as Cobalt Strike, Metasploit and Empire. This approach enables us to identify malicious Command and Control (C2) servers based on the observation of specific characteristics related to these tools.
Once we know what patterns/characteristics we are looking for, we scan the Internet to collect server IP addresses or domain names matching the searched patterns/parts. Since we studied Evilginx2 in the above paragraphs, we noticed that when following the official tutorial for Evilginx2 phishlets configuration, we had Evilginx2 generate these two URL structures: ‘login.O365.mydomainname.com’ and ‘www.O365.mydomainname.com’. A hunting approach would consist in searching these specific domain name structures associated with Let’s Encrypt certificates using Certificate Transparency.
Searching for this URL structure allowed us to retrieve more than 50 domain names likely registered for O365 phishing campaigns, including our own phishing server.
Here we focus on O365, but this strategy can be applied to all the phishlets provided by default in Evilginx2. These results then feed the Cyber Threat Intelligence database of SEKOIA.IO so that any login attempt carried out from these servers will trigger an alert as shown below.
Then, let’s correlate some events
The second approach would consist in analyzing the O365 logs, comparing the legit behaviour with the non-legit one.
In this scenario, the victims received an email with the phishing link. This means that the victims were already connected to their email account, then clicked on the link. From there, because of the proxy framework, they are invited to fill in their credentials despite being already connected. And all of these steps occur within a short time frame. This behaviour can be detected with a correlation rule to track events as follows:
([action.name= “MailItemsAccessed”] FOLLOWEDBY [action.name= “UserLoggedIn”] WITHIN 300 SECONDS)
A more global approach to detect this type of threat is based on the detection of “impossible travel”. An alert is triggered when a user is, within a short time window connected from two different countries or cities, as we can see in the screenshot above, where our attack server is tagged as “US” while the legit user has an IP tagged as “FR”.
Multiple other ways to detect this threat are possible based on the IP (e.g. IP attributed to an anonymous service VPN/Tor), UserAgent value, SSL certificate validity. All these types of logs can be correlated to ensure the best detection possible and minimize the false positive rate. Note that we are dealing with a phishing attack. In this type of attack, many users can be targeted at the same time. Depending on the size of your company it can be relevant to refine these rules with a parameter indicating that the searched behaviour can be seen in more than n user (e.g. >5 users).
Hence, conducting a real-time detection based on proactive threat hunting combined with the correlation of event logs enable us to detect this type of attack to limit the damage and respond quickly.
Now that we saw that, what can we do to prevent it?
Phishing is a technique frequently leveraged by multiple threat actors such as APT28, APT32, FIN8, Kimsuky, Turla and many others since it has proven to be an efficient way of harvesting credentials or downloading malware. For Evilginx2 based attacks as well as other types of phishing attacks, training your users is the best way to avoid damages. Users can be trained to recognize social engineering and be vigilant regarding the link they click on.
But since users can be easily lured with tools and methods as powerful as Evilginx2, the best option is to rely on an efficient real-time monitoring and detection solution that knows how to leverage Cyber Threat Intelligence.
Narimane LAVAY
Threat & Detection Research Team | SEKOIA.IO
