What Is an Adversary-in-the-Middle Attack?

An Adversary-in-the-Middle (AitM) attack is a variant of the well-known Man-in-the-Middle (MitM) attack. It is a form of data eavesdropping and theft where an attacker intercepts data from a sender to the recipient, and then from the recipient back to the sender. It’s called a “adversary in the middle” because the attacker’s device sits between the sender and recipient and relays messages silently without making either party aware of the eavesdropping. The attacker is typically situated on the same network as the targeted user, but eavesdropping can be done on a remote network if data crosses the path where an attacker is located. Using an AiTM, an attacker can obtain passwords, personally identifiable information (PII), intellectual property, private messages, and trade secrets. In advanced attacks, the attacker can potentially install malware on a targeted user’s device.

Any method that allows an attacker to read third-party communication between two people is considered an AiTM. It’s imperative that the attacker stays undetected, so attackers will often breach a network or personal account to read information as two parties communicate and do nothing that would alert them of the attacker’s activity. A good AitM gives an attacker months to read information before detection.

The most common method is Address Resolution Protocol (ARP) poisoning usually on a public Wi-Fi network. While on the network, the attacker sends a message to a targeted user’s device that tells it to use the attacker’s device as the default gateway. The attacker then sends an ARP poisoning message to the default gateway (usually the Wi-Fi router) that the targeted user’s IP address should be associated with the attacker’s device rather than the targeted user’s device. This puts the attacker’s device in the “middle” of communication between the targeted user and the default gateway, which allows the attacker to intercept data. In other words, the attacker’s device acts as a proxy similar to a proxy server.

If the data is in cleartext (no HTTPS connection), the attacker has access to any data passed between the two parties. For instance, if a user authenticates into an application using HTTP, the username and password would be intercepted and visible to the attacker.

Even HTTPS connections are not completely safe from an AiTM attack. If the server accepts deprecated cryptographic connections using libraries such as TLS 1.0, the encrypted data intercepted could be vulnerable to brute-force attacks where an attacker can transform it to cleartext. With this method, the attacker sends ARP poisoning messages to the sender and recipient server, but downgrades the HTTPS connection to an insecure library and tricks the user’s device into downgrading the encryption algorithm. The downgrade is invisible to the user, so the user is unaware that the HTTPS connection is not secure. As data is passed using HTTPS, the attacker is still able to decrypt it and read communications.

Although ARP poisoning is commonly known as an AiTM attack, other forms of data interception also give attackers the ability to read private communications between two parties.

The five main categories of an AiTM attacks include:

• Email hijacking: Email messages sent in cleartext are open to eavesdropping, but an attacker can also read messages should they obtain a targeted user’s username and password to the email account. The attacker may wait silently reading messages until sensitive information is transferred such as a financial transaction, and then use the targeted user’s email address to send a message that will reroute money transfers to the attacker’s bank account.
• Wi-Fi eavesdropping: A poorly secured Wi-Fi connection could be subject to an AiTM using a method called ARP poisoning. The attacker’s device is used as the default gateway between the sender and the Wi-Fi router where data can be intercepted and read. Attackers also use malicious hotspots of their own to trick users into connecting and routing communication through the attacker-controlled hotspot.
• Session hijacking: When users connect to a server, a unique session is created that identifies the user on the server. Attackers with access to this session token can impersonate the user and read data on a web application.
• IP spoofing: Using a fraudulent IP address, an attacker can reroute traffic from an official site to an attacker-controlled server.
• DNS spoofing: Similar to IP spoofing, DNS spoofing alters a website’s address record to divert traffic to an attacker-controlled server. Any information sent to this server is intercepted by the attacker unbeknownst to the tricked users.

With more users accessing the internet with a mobile device, AiTM attacks often target iOS or Android. Attackers can inject code into an application, use malicious apps to intercept data, or install their own proxy to read data between the device and a remote API. For instance, malicious proxies could be used to read messages on Tinder or Twitter. Certificate pinning was then used to stop this issue, but attackers still work with malicious apps to read data before a remote connection is made and before data is encrypted.

The Retefe banking trojan was created to intercept data between a sender and financial servers. The malware affected major browsers such as Chrome, Firefox, and Internet Explorer which most users use on desktop computers. It installs a fake certificate and routes traffic to an attacker-controlled server used as the default proxy in the browser’s settings. User data is collected at the attacker’s server and decrypted. The Retefe malware was used as an attack vector for banking transactions at most major financial institutions, but its main targets were banks in Japan, Switzerland, UK, and Sweden.

Because AiTM attacks are invisible and silent to the targeted user, it’s essential that users take the necessary precautions to prevent them. It’s also the responsibility of the application developer to ensure that their software is not vulnerable to AiTM attacks. In some cases, users would be unable to prevent an adversary-in-the-middle attack due to the way an application is coded.

Some methods to prevent becoming a victim of an AiTM attack:

• Use two-factor authentication on email accounts. Should an attacker obtain email credentials for your account, successful authentication would not be possible as the attacker would not have access to the 2FA PIN.
• Use traffic analytical tools on the network. These tools help administrators identify suspicious traffic and provide analytics into ports and protocol usage across users and devices.
• Use certificate pinning on mobile apps. Certificate pinning whitelists approved certifications, which blocks any attacker-controlled certificates from being used with the application. Certificate pinning is the responsibility of the application developer.
• Use VPN on public Wi-Fi networks. With VPN, an attacker may intercept data but would be unable to read data or downgrade to a weaker encryption protocol as the VPN uses its own encryption algorithm to package data and transfer it across the internet.
• Educate employees about the dangers of phishing. Some AiTM and malware attacks start with phishing attacks. Educate employees to identify phishing attacks so that they do not install malware or send credentials to attackers.
• Integrate email security. Email filters will detect a majority of phishing emails or messages with malicious attachments and send them to a safe quarantine storage where they can be reviewed by an administrator.
• Never connect to an unknown Wi-Fi hotspot. Attackers use malicious hotspots with names similar to an official source. Users should never connect to a public Wi-Fi without first verifying that it is indeed owned by the official provider.