Clik here to view.
As we step through a busy season of ransomware, financial scams involving deepfake, and sophisticated phishing campaigns, we continue to witness campaigns targeting enterprise users with Adversary-in-the-Middle (AiTM) attacks. As discussed in our previous blog post[1], AiTM leverages proxy-based toolkits such as Evilginx and EvilProxy. This technique has proven extremely effective, even in our red team assignments, in capturing credentials, and authenticated sessions.
In this article, we explore a use case in Microsoft 365, in which a feature has allowed opportunities to build a canary-based detection mechanism in an unconventional way. Inspired by the effectiveness of bug bounty programs in identifying vulnerabilities, this strategy aims to locate and mitigate the risks associated with AiTM attacks.
Understanding Adversary-in-the-Middle Attacks
Traditionally, in combating phishing and scams, our approach to protecting accounts in Microsoft 365 has revolved around the use of strong credentials and multi-factor authentication (MFA). These proved mostly effective against password brute-force and credential harvesting with fake phishing sites. Coupling this with new solutions such as Microsoft’s Intune or Mobile Device Management (MDM) applications, threat actors need to explore new ways of gaining access to their victims’ Microsoft 365.
AiTM attacks have proven to be extremely effective choice of technique leveraged by cybercriminals. We have previously covered use cases observed in phishing campaigns targeting our clients in Hong Kong, Macau, and in the region. This is because, unlike traditional phishing techniques, AiTM captures both the victims’ passwords, as well as valid login sessions cookie – another form of valid credentials. Threat actors have also explored new ways of using the compromised identities, not just to access confidential data from the victim’s mailbox, but also the data files on OneDrive and SharePoint.
From a defender’s perspective, it is difficult to identify individuals who has fallen victim to this kind of technique as, unlike traditional phishing, the victim is engaged in an interactive flow, supplying both credentials and any multi-factor authentication. The phishing site acts as an intermediatory internet reverse proxy, completing the authentication on the victim’s behalf and, capturing the materials in between. The diagram below illustrates a complete flow of how a threat actor can compromise the victim’s account.
Clik here to view.
In general, detection of a compromised user account would require heuristics approaches (e.g. Microsoft’s Risky IP Address, or Impossible Travel) or detection of specific threat-actor activities (e.g. New-InboxRule). These are very effective in identifying anomalies in interactions with the mailbox, prompting additional investigations and mitigations with the downside being, in our experience, a late detection where the threat actor might have taken actions or information with the victim’s account.
The Canary-Based Approach to Detection
For those experienced in cyber defense, canaries are a familiar tool used to provide detection opportunities against specific behaviors. They act like tripwires or indicators which are designed to stand out in attack scenarios. A prime example is “honey accounts” in Active Directory environment, where a failed attempt to log in to this decoy account should warrant immediate attention to identify the source for potential behavior in the environment.
How can we do the same in our use case in M365? Going back to our drawing board, the authentication process in both normal and AiTM attack scenario involves interaction with the official Azure login page. Earlier this year, security researchers at IronPeak identified a feature in Azure called “Company Branding” which can enable such a detection mechanism.
The reader can follow the original blog post here.[2]
Company Branding is a feature that allows Azure administrators to apply branding to their login page by setting company logos, brand colors, and more through customising a cascading style sheets (CSS) file. A user browsing the login page will load the corresponding components referencing the style sheets. It is then possible, by introducing a single-pixel web-beacon as a CSS component, to capture referred request to the beacon, and identify if a user is falling victim to a phishing site.
Clik here to view.
Setting up canary-URL for detecting AiTM
The section below outlines sample steps to configure a canary-based detection for AiTM attack on Microsoft 365 platform. This is based on the research conducted by IronPeak team.
To begin, download a copy of the template CSS file available from Microsoft.[3] Add the custom reference canary URL to the CSS file template and upload to the sign-in page.
Clik here to view.
Access the “Company Branding” section of Microsoft Entra admin center. Click “Edit” for the default sign-in, or corresponding sign-in pages.
Clik here to view.
Select the “Layout” tab and upload the customised CSS file under the “Custom CSS” section.
Clik here to view.
The configuration will take effect during new login against M365 at the login page (e.g. https://login.microsoftonline.com).
Clik here to view.
As a website is created in the detection site, a web server can be configured to capture the full request, including header values such as “Referrer”. Note that the existence of the requested file does not matter as we just needed the web service to capture the request. A sample set of logs is shown below.
47.39.x.x - - [03/Apr/2024:03:43:56 +0000] "GET /beacon.png HTTP/1.1" 404 197 "https://login.microsoftonline.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "3.03"
174.102.x.x - - [03/Apr/2024:03:47:30 +0000] "GET /beacon.png HTTP/1.1" 404 197 "https://totally-not-phishing.site/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "3.03"
185.240.x.x - - [03/Apr/2024:03:47:30 +0000] "GET /beacon.png HTTP/1.1" 404 197 "https://login.microsoftonline.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36" "3.03"
The key point here is that the canary-URL is triggered when the user key in the email address i.e. the log is not indicative of an access session or credentials compromise. However, we can take steps to determine if an AiTM attack has taken place:
- Determine if the URL specified in the “Referrer” field above exhibits behavior of an AiTM phishing portal
- Review the Microsoft 365 logs to identify the actual user behind the IP address
- If a successful authentication has matched the logs, we can determine that the user account has been compromised : perform the necessary mitigations e.g. revoke sessions, credentials reset, inbox rule cleanup, etc.
Faring against advance phishing kits
While this canary URL is effective against open-source, proxy-based phishing framework (e.g. Evilginx), there are other phishing toolkits which take a different approach in displaying contents to the victim. One example is the more advanced Phishing-as-a-Service (PhaaS) platforms, such as “Caffeine” or “Tycoon 2FA”.
In our research, these phishing kits are well-designed to hide from public scanners behind Cloudflare or other anti-DDoS pages. During interaction, they also behave differently by displaying pre-loaded components and styles from the official Microsoft 365 login pages to the user, while leveraging embedded JavaScript as the API engine with Microsoft 365 in authentication. In other words, the victim is not interacting directly with the official Microsoft 365 login page and thus, the custom CSS files as well as the canary-URL will not be triggered.
An example of such a page is shown below.
Clik here to view.
This seems like a bypass of the canary-URL detection, but not all hope is lost.
Since we are using canary-URL to collect data for every access to the official Microsoft 365, the resulting data set can be compared against the Azure sign-in log. The analysis of data will still allow isolation of IP addresses in login records that security analysts should further conduct review.
Clik here to view.
Conclusion
In an era of increasingly sophisticated cyber threats, the detection of AiTM attacks is of paramount importance. The canary-based approach presents a proactive strategy to identifying victims in AiTM attacks. By combining dynamic canary URL and behavioral analysis, organisations can enhance their security posture and protect sensitive data from falling into the wrong hands.
Canary-based approach uses triggers to create new opportunities in attack detection. The Canary URL above targets anomalies as early as the authentication process, reduces the time-to-detect duration in AiTM attack, and allows for prompt response and mitigation.
This technique has proven effective in combating phishing toolkits such as Evilginx. As cybercriminals up their game with additional Phishing-as-a-Service frameworks, we shall continuously evaluate the limitations in our detection tricks and explore additional techniques or data-centric approaches to identify anomalies.
Feel free to contact us at [darklab dot cti at hk dot pwc dot com] for any further information.