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:

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.

Image

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:

Image

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:

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:

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:

Image

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, Greynoise.io, etc.

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

Image

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:

Image

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:

EmailEvents
| where NetworkMessageId contains "NETWORK_MESSAGE_ID"

EmailEvents
| 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:

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

Red Team

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.