Investigating an Adversary-in-the-Middle (AiTM) Phishing Email

A client recently asked for some help investigating an adversary-in-the-middle (AiTM) phishing email containing a QR code. They had never encountered this before and needed some incident response guidance. When I responded to this incident, I noticed some interesting details that I felt were worthy of a blog post that breaks down the investigative process and provides guidance to other organizations experiencing similar incidents. If you are unfamiliar with responding to phishing incidents in Microsoft 365, I recommend that you check out my 2023 Source Zero Con talk.



Key Callouts:


  • The phishing link was embedded in the QR code.
  • This standard AiTM phish appeared as a multifactor authentication (MFA) enrollment message.
  • The AiTM server had elementary anti-analysis features.
  • OSINT provided interesting information on the campaign , such as other victims and campaigns on the same infrastructure.



QR Code Analysis

What made this message more interesting than a standard AiTM phish, in my opinion, was that this message used QR codes as a delivery vector and prompted the end user to scan it with a mobile device. There are various ways to compromise accounts and devices with a QR code, such as taking advantage of simplified authentication flows in OAuth and other frameworks, but this particular method just redirected the end user to a standard AiTM phishing server and prompted them to enter credentials. We can infer that this maneuver would bypass many URL filtering and other network protections, especially if the user was on a mobile data connection while scanning the QR code at work.



Figure 1: An AiTM phishing email containing a malicious QR code


I analyzed the URL manually using CyberChef and a dedicated analysis VM. I took a screenshot of the QR code, and then uploaded it to my local CyberChef instance with the "Parse QR Code” recipe. This is what the result looked like:



Figure 2: The malicious QR code decoded in CyberChef


In the output section of CyberChef, we can see two interesting things about the destination that the user is redirected to:


  1. It is hosted on a .ru domain. We knew this wasn’t a legitimate Microsoft email already based on the sender address alone. But if you’re looking for any other evidence, Microsoft will never ask you to scan a QR code that redirects to a randomly generated .ru domain.
  2. The URL contains a Base64 encoded string, which, when decoded, identifies the intended victim. Typically, a well-configured AiTM server will have some kind of protections that block your connection automatically if you do not directly access it via an authorized URL. In this case, the authorized URL required the input of the victim recipient, associated to an ID of the specific campaign it was sent as a part of.


While this does not imply that the phishing email was directly targeted, it does tell us that the adversary was sophisticated enough to attempt to decently configure their AiTM server.



AiTM Server Analysis

Now that we know where the phishing message is redirecting to, we can do some analysis to try and learn more about the campaign. Given that we know there are likely going to be some anti-analysis protections on the AiTM server, our goal is to closely resemble the intended victim. Let’s think out what the user looks like:


  • The phish was sent to a .CA email, so they are likely expecting a Canadian IP address.
  • They are intending for the user to scan from a mobile device, so we need to emulate a mobile device in the browser. We can do this by setting our user agent and screen resolution to appear like a mobile device and using other browser features to appear “like a mobile device.”
  • The AiTM server is expecting a specific parameter identifying the victim of intention.


Knowing all of this, I configured my browser (Microsoft Edge) to emulate an iPhone in Developer Tools in a dedicated malware analysis VM. Ensuring that the browser’s network log was retained, I then navigated to the phishing URL like so:



Figure 3: The phish kit as it would appear to the user


One of the standout observations about this phish kit was that although it appeared exactly like Microsoft 365, the webpage title was a giant garbage string—which should be a visual giveaway to an end user. Taking this a step further, after I capture what I need to see at a network level to hunt for indicators, I like to poke at the server sometimes. 😊 I then do a search for my indicators on various OSINT platforms, such as VirusTotal,, etc.


In this case, VirusTotal had a lot of interesting information.



Figure 4: A search for the phishing domain in VirusTotal Enterprise


Based on the VirusTotal search, we were able to see when they started to resolve that domain and other URLs that correspond to the server. It was evident that the domain had a downloaded file associated with it. As there were a number of URLs submitted, we were able to see some of the other victims of the same campaign. I decided to generate a Base64 string that decodes to an email address that I control, and then I observed how the server handled it. For the initial request, I supplied the Base64 string, omitting the start of the URL, and I was redirected to this page:



Figure 5: A page demonstrating the webserver management panel for the AiTM server


So, although the TA was competent enough to implement some anti-analysis protections on their AiTM server, we can see there was a slight oversight in their infrastructure management processes. A quick web search provided us with some of the information for the default installation of CyberPanel. 😊


At this point, I decided to give some attention to the TLS certificates used on the AiTM server to try to fingerprint the AiTM servers’ ‘true IP’. A good deployment of an AiTM server will be totally firewalled behind a content delivery network, like Cloudflare, to further obfuscate the true origin of the server. In this case, they did put the server behind Cloudflare, but they did not limit which URLs were being publicly served. Thus, the server management panel was accessible when it should not have been. A Censys search showed multiple certificates issued for that domain—all with various subdomains from different certificate authorities. Some of those certificates were very recently issued, indicating that the TA is still using that infrastructure to some extent.



Incident Response

I was able to work through that analysis of the phish quickly enough to get my key network indicators and start helping our client respond to the incident. This client was licensed for Microsoft Defender 365, which I used to mitigate the threat.


Taking some details out of the message headers, I pivoted to look for other recipients of the phishing email with these queries:



| where NetworkMessageId contains "NETWORK_MESSAGE_ID"



| where Subject contains "PHISHING_EMAIL_SUBJECT"
| project Timestamp, Subject, SenderFromAddress



After I identified the other victims, I worked with their IT teams to take the following actions:


  • Disabled sign-in
  • Revoked active sessions
  • Revoked registered MFA devices
  • Initiated a password reset


At this point, we had successfully analyzed the phishing email to understand the nature of the attack. We were able to contain the incident and investigate further to identify the adversary’s activity. I feel that the use of QR codes to deliver malicious content is an interesting development in the ever-evolving phishing landscape, as there are not many email security solutions that are capable of outright blocking QR codes or auditing them in real time. Additionally, not all QR code readers will properly display a full URL, which is one of the many key anti-phishing training measures organizations industry-wide. I feel that this will likely become more popular, and email security vendors will need to adapt to implement protections against QR-code-based threats. Defenders will need to adapt to this change as well.


In another blog post, I will share tips and tricks for auditing the Microsoft 365 unified audit log, as well as discuss methods for auditing TA activity in Microsoft 365.



Final Recommendations for Red and Blue Teamers

To conclude this post, here are some of the lessons learned when investigating AiTM phishing attacks. Based on my research and client work, I would like to share advice for both adversaries and defenders:


Blue Team


  • Ensure that your Microsoft 365 environment is correctly hardened to defend against AITM attacks.
    • Deploy conditional access policies.
    • Consider using phishing-resistant MFA methods.
    • Monitor “risky sign-in" events and Azure identity protection alerts.
    • Control security info registration with conditional access.
    • Activate safe links and the full feature set of Microsoft Defender for Office365.
  • If you are licensed for it, extend your Microsoft Defender (or other capable EDR) deployment to corporate-owned mobile devices. This will allow you to defend network traffic that originates from a mobile device. You will then have visibility if a user ever scans a QR code like this from a mobile device.
  • Once you have appropriate IOCs, you can use Threat Explorer to manually remediate the threat.


Red Team


  • Do not expose your cPanel to the internet. It should only be accessible from your VPN IP.
  • Ensure that you are properly configuring your AiTM server to block requestors who try to access unauthorized URLs. You might consider serving benign content to unauthorized users instead of a 404 or other error. If there is a valid HTTP 200 response logged for a victim in a security platform, and the analyst receives an HTTP 404, that will indicate that there are likely some anti-analysis detections in place.
  • If you are going to run multiple campaigns, use multiple domain names. You will get burned pretty quickly once you start sending phishing emails.
  • Use redirectors to obscure your evil domains in the QR code.
  • The title of the Microsoft 365 landing page is "Sign in to your account,” not “”.
  • Check out your domain on Virus Total on a recurring basis, and consider existing guidance on configuring AITM servers.


If your organization is experiencing an incident and you would like immediate assistance, please call 1-877-310-0557 to engage the Optiv Enterprise Incident Management Team.

Justin Safa
Digital Forensics and Incident Response Consultant | Optiv
Justin Safa is a Digital Forensics and Incident Response Consultant at Optiv on our Enterprise Incident Management Team. Justin is a Subject Matter Expert in Microsoft 365, Cisco Security, Carbon Black, Sentinel One and a variety of other technologies. Justin has led many Incident Response Engagements involving Ransomware, Targeted Attacks, Zero-Days and other Sophisticated Threats. Justin has worked for a diverse range of Clients in various industries including various levels of government and the Fortune 500.

Optiv Security: Secure greatness.®

Optiv is the cyber advisory and solutions leader, delivering strategic and technical expertise to nearly 6,000 companies across every major industry. We partner with organizations to advise, deploy and operate complete cybersecurity programs from strategy and managed security services to risk, integration and technology solutions. With clients at the center of our unmatched ecosystem of people, products, partners and programs, we accelerate business progress like no other company can. At Optiv, we manage cyber risk so you can secure your full potential. For more information, visit