What is an adversary-in-the-middle attack, and how is it used in phishing?
The increasing use of both multi-factor authentication (MFA) and cloud services in organizations has forced cybercriminals to update their tools and tactics. On the one hand, they no longer need to penetrate a company’s internal network or use malware to steal information and conduct fraudulent schemes. It’s enough to gain access to cloud services — such as Microsoft 365 email or MOVEit file storage — through legitimate accounts. On the other hand, stolen or brute-forced credentials are no longer sufficient — MFA must be somehow bypassed. A recent large-scale series of cyberattacks on major organizations, which affected over 40,000 victims, shows that attackers have adapted to the new reality. They’re using targeted phishing techniques and adversary-in-the-middle tools on a broad scale to target companies.
What is adversary-in-the-middle
An adversary-in-the-middle (AitM) attack is a variation of the well-known man-in-the-middle attack: the attacker gets access to the communications between legitimate parties (client and server), intercepts client requests, forwards them to the server, and then intercepts the server responses and forwards those to the client. What makes an AitM special is that the attacker doesn’t just eavesdrop on communications, but actively interferes with them — modifying the messages to their advantage.
Advanced AitM attacks may involve compromising the organization’s ISP or Wi-Fi network. Attackers then manipulate network protocols (ARP poisoning, DNS spoofing) and display fake web pages or files when the user accesses legitimate resources. But in the case of spearphishing, such tricks are unnecessary. It’s enough to lure the user to a malicious web server, which will simultaneously communicate with both the victim and the legitimate cloud-service servers using a reverse proxy. The attack generally goes like this:
The user receives a phishing message and clicks the link.
Through a chain of masking redirects, the user’s browser opens a page of a malicious site that looks like the cloud service’s login portal. To display this page, the attackers’ reverse-proxy contacts the legitimate server and transfers the entire login-page content to the user’s browser, making any changes necessary for the attackers.
The user sees the familiar interface and enters their username and password.
The malicious server relays the username and password to the legitimate server, imitating the user’s login. The username and password are also stored in the attackers’ database.
The legitimate server verifies the password and, if correct, requests a one-time code, which is sent to the user or generated in their app, as per the usual MFA procedure.
The malicious server displays a page prompting the user to enter the one-time code.
The user enters the one-time code from the authenticator app or text message.
The malicious server sends the code to the legitimate server, which verifies it and, if correct, lets the user into the system.
The legitimate server sends session cookies needed for normal system operation to the “browser” (which is actually the malicious server).
The malicious server forwards the cookies to the attackers, who can then use them to imitate the browser of a user already logged into the system. The attackers don’t need to enter passwords or MFA codes anymore — it’s all been done already!
The malicious server redirects the user to another site or to the regular login page of the legitimate service.
Additional features of modern AitM attacks
Attackers have streamlined the basic attack scenario described above. There are ready-made phishing kits available — usually including reverse proxies like Evilginx or Muraena, which enable “out-of-the-box” attacks with templates for modifying login pages of popular cloud services and well-oiled MFA-code theft scripts.
However, to successfully compromise large organizations, “off-the-shelf” attacks need to be tailored. Well-resourced attackers can target many organizations at once. In the attack mentioned above, about 500 large companies — all law firms — were targeted within three months. Each received a custom domain within the attackers’ infrastructure, so the victims (executives of these organizations) were directed to domains with familiar and correct names in the initial part of the URL.
The arms race continues. For example, many companies and cloud services are transitioning to phishing-resistant MFA methods such as hardware USB tokens and passwordless logins (passkeys). These authentication methods are generally resistant to AitM attacks, but most cloud systems allow a backup-plan login using older verification methods such as “paper envelope” one-time codes or one-time codes delivered in text messages. This is intended for cases where the user loses or breaks the second factor physical device. Attackers can exploit this feature: the malicious server shows the victim modified authentication pages of the legitimate server, erasing the more reliable authentication methods. This type of attack has been named Passkey Redaction.
How to protect against AitM attacks
Protection against spearphishing attacks aimed at gaining access to cloud accounts requires coordinated measures from corporate security services, cloud providers, and the users themselves:
Use phishing-resistant MFA tools such as hardware USB tokens. Ideally, these should be used by all employees, but at the very least by management and those responsible for critical business operations and IT.
Work with SSO solution providers and cloud services to disable backup-plan authentication methods and take technical measures to make it difficult to steal authentication-token cookies.
Educate employees to pay attention to changes in login pages and avoid entering credentials if “authentication disappears” unexpectedly, or the site name seems unfamiliar. Regularly conduct cybersecurity training tailored to employees’ responsibilities and experience.
Explore and properly configure the cloud provider’s security tools. Ensure that employee activity logging is sufficiently detailed and that the security team receives these logs promptly. Ideally, they should go directly to the SIEM system.
Ensure that all computers and smartphones used to access corporate accounts have an EDR agent
Install a reliable protective solution with antiphishing capabilities on the corporate email server.
Kaspersky official blog – Read More
