Man-in-the-Middle (MitM) attacks reaching inboxes increase 35% since 2022

Author: Jamie Arndt A man-in-the-middle (MitM) attack is an adversary’s attempt to steal information by inserting themselves between victims and their legitimate, expected destination. Threat actors combining credential phishing with man-in-the-middle attacks have been another evolution in the threat landscape. In this context, rather than setting up one fake login page, the attacker lures victims to their web server which will broker the entire authentication process between the user and the actual destination. If successful, threat actors can use the harvested usernames, passwords, and session cookies to gain access to a victim’s account and even bypass multi-factor authentication.  Man-in-the-middle attacks are meant to be transparent to the victim, but this does not mean they are undetectable. Credential phishing man-in-the-middle attacks are no different. Based on a few tell-tale signs, Cofense Intelligence has identified notable trends, including: 

• a 35% increase in volume reaching inboxes between Q1 2022 and Q1 2023 
• 94% of MitM credential phishing attacks reaching inboxes targeted O365 authentication 
• 89% of campaigns used at least one URL redirect, and 55% used two or more 

The signs we used to track MitM phishing attacks not only allow us to perform statistical analysis, but are also useful for detection and defense. Network defenders will need to be aware of these markers to better protect their organizations. 

MitM Phishing by the Numbers 

Taking the characteristics of credential phishing MiTM URLs (outlined later in this report) and matching them against phishing campaigns found in customer mailboxes, Cofense Intelligence has observed a gradual but persistent increase in the volume of credential harvesting man-in-the-middle attacks since early 2021. Figure 6 shows major spikes in January and September of 2022, followed by significant corrections that still retain an upward long-term trajectory. The spikes and corrections may be due to cycles in which threat actors develop, test, and refine the capabilities of their MiTM phishing kits. There are also numerous open-source tools (such as evilginx2, CipherGinx, and Muraena) that could provide threat actors with MiTM capabilities.

Figure 1: Count of man-in-the-middle phishing campaigns per month over the past two years. 

The significant majority of man-in-the-middle landing pages we have identified attempt to intercept Office 365 credentials (Figure 2), with Outlook and Amazon following as a distant second and third.  

Figure 2: Type of login pages being intercepted by man-in-the-middle servers. 

The majority of campaigns observed have a malicious URL embedded in the body of the email rather than in an attachment. Very few of the embedded URLs address themselves to the man-in-the-middle server itself. Instead, most pass through one or more URL redirects before reaching the final URL that actually conducts the man-in-the-middle attack.  

Figure 3: Most man-in-the-middle phishing campaigns use multiple redirects before the final MiTM URL. 

How It Works 

Man-in-the-middle attacks have been used for a long time, in different contexts. For example, to eavesdrop on network traffic, an attacker could send an update to the other devices saying their machine is the new default gateway and all network traffic should be routed through their computer. An attacker could impersonate a trusted device by setting up their own Wi-Fi hotspot near other available wireless networks allowing them to intercept the traffic from any device which connects to it.  In credential phishing, a man-in-the-middle server will act as a proxy between the user and the actual destination (Figure 4). It will present to the user the destination’s login page and will pass on any received username and password to the destination website. If multi-factor authentication (MFA) is enabled for that account, it will present the MFA request to the user for further input, and forward any responses to the destination. 

Figure 4: The man-in-the-middle server intercepts all steps of authentication.

 Most websites today use web certificates to verify that the site can be trusted and to create a secure connection between themselves and the user. The verification process helps to ensure that the destination is who it claims to be. This secure connection encrypts the back-and-forth traffic with the purpose of making it difficult for attackers to decrypt any traffic they happen to intercept.  The credential harvesting man-in-the-middle server gets around this by setting up two secure connections. One between itself and the destination and the other between itself and the user. To help disguise itself within the authentication process, the man-in-the-middle server will use a valid certificate to authenticate its own identity and allow encrypted traffic between itself and the user.  Since the man-in-the-middle server is between these secure connections, it can decrypt the data from the user and extract the username and password (Figure 5). It then re-encrypts the traffic and sends it on to the destination website. If the authentication is successful, it will continue to broker the connection between the user and the destination, often even passing along MFA requests.

Figure 5: Extracted credentials from a secure connection. 

Once all the authentication processes are successful, the final step is for the destination website to craft a session cookie to send back to the user. Session cookies are very valuable. They are used to manage logins, shopping carts, user preferences, and any other information that needs to be saved throughout someone’s interaction with a website. Just like the username and password, the attacker can decrypt and extract the session cookie before sending it along to the user (Figure 6).  

Figure 6: Captured session cookie received from the destination website. 

Once the attacker has the session cookie, they can use it to interact with the website as if they were the user. This session cookie allows them to bypass usernames, passwords, and even the multi-factor authentication steps. Using that session cookie, they will be granted all the access and permissions associated with that account. 

Detecting Man-in-the-Middle Pages 

Figure 4 shows the actual landing page for login.microsoftonline.com and one that is passing through a man-in-the-middle server. At first glance, these two pages look identical. This makes sense, as the man-in-the-middle server has just made a real-time request in order to clone the actual login.microsoftonline.com. However, there are two significant differences. 

Figure 7: Authentication prompts for legitimate (back) and man-in-the-middle server (front).

URL Inspection 

One way to determine if the landing page is legitimate is to inspect the URL. Table 1 shows a few well-known login URLs and samples of malicious ones found in recent campaigns. Notice how similar the URLs are to each other except for the domains. Attackers will still use the tried-and-true method of creating domain names which are similar to the destination they are trying to impersonate (e.g., Microsoft). They may also create a domain which impersonates a customer’s business or include subdomains such as secure or login to help look more legitimate.  

Table 1: Legitimate and malicious URLs found as a part of campaigns which made it to customer inboxes. 

Website Certificates 

The other way to determine if a website is legitimate would be to inspect its website certificate. Legitimate certificates are authorized by a certificate authority. These certificates are used to verify that a website is who it says it is. A padlock icon will appear in your web browser to indicate that the certificate is valid and the connection between you and the destination is secure. If there are any issues with the certificate, modern web browsers will warn you to not proceed any further.  The certificates below (Figure 8) are from the two websites in Figure 7. Both browsers showed the padlock icon which indicates the certificates are trusted. However, looking at the certificates more closely shows the important difference. The common name in the certificate of the legitimate website is microsoftonline.com. The common name in the certificate from the man-in-the-middle server has nothing to do with Microsoft at all.  

Figure 8: Certificates from the legitimate (left) and man-in-the-middle server (right). 

Just like the URLs above, these names in the certificates should be carefully inspected as attackers are likely to create domain names which are similar to microsoftonline.com. Domains such as m1crosoft0nline.com and micsoftonline.com may fool the casual viewer. 

Defending and Detecting 

Throughout the day, there can be a number of online locations where users may be asked to input their business credentials. These could be locations within their own company, multiple online cloud portals, and even shared locations from other businesses. The credential phishing man-in-the-middle campaigns are unique in that the authentication process looks and feels very legitimate, so much that users may not even take a second glance at the URL to question its legitimacy.  With that in mind, here are a few tips for defending against such attacks. 

• Users should be reminded of which online portals are approved for company use.
• Emails containing URLs or attachments that bring users to a website which looks legitimate but does not match the company-approved ones should be considered suspicious and reported for further analysis. 

Detecting these campaigns at the inbox level will be difficult as most of the attacks make use of multiple redirects before landing the victim on the final man-in-the-middle URL. Despite the redirects, patterns in the final malicious URL will be very similar to legitimate ones. Alerts on outbound network traffic which match known URL patterns but do not match the legitimate domains could be beneficial. The basic logic of an alert might look something like this: 

• O365
  • URL contains “.com/common/oauth2/v2.0/authorize?client_id=” AND  
  • URL NOT contains “login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=”
• Outlook
  • URL contains “login.srf?wa=signin” AND 
  • URL NOT contains “login.live.com/login.srf?wa=signin” 

Finally, threat actors may leave tracks once they start interacting with a compromised account. Alerts like the following may help to detect a compromised account. 

• Stolen session cookies 
• Impossible travel 
• Mailbox rule manipulation