‍

Fortian would like to disclose information regarding a recently observed threat campaign leveraging novel techniques to bypass location-based conditional access controls via Adversary in The Middle (AiTM) attacks. This attack presents a significant step-up in sophistication relative to previous AiTM attacks. While traditional adversary in the middle attacks proxy a sign in attempt via a single – or sometimes a handful of – attacker-controlled servers, this AiTM attack dynamically routes traffic via compromised residential IP addresses in the same location as the victim. The result is sign-in requests against the victim organisation’s identity provider which match the expected sign in locations of the target users.

This is a particularly pernicious attack as it bypasses not only password and multifactor authentication requirements, but also subverts location-based conditional access controls. This has numerous security implications for organisations, particularly for security controls that rely on geo-location restrictions. This post will delve into the attack methodology, the attacker-controlled infrastructure, and how the attack can be detected and defended against. The article’s intent is to inform cybersecurity professionals of attacks of this nature and provide guidance on how such attacks can be detected and defended against.

‍

Understanding Adversary in the Middle

To understand how this threat differs from traditional AiTM attacks, let’s first revisit the basics. Adversary in The Middle (AiTM) phishing refers to the use of specialist phishing sites which proxy authentication flows between a user and an identity provider. In this way, threat actors can steal session tokens rather than simply valid credentials in order to bypass multi-factor authentication mechanisms. AiTM phishing sites are visually indistinguishable from legitimate sign-in pages since they render content dynamically based on the response of the real identity provider. This includes customer branding, animations, and multi-factor authentication prompts.

The typical flow of an AiTM phishing attack is:

1. The user is sent an email which contains a malicious link from a previously compromised mailbox. The email will call on the user to act in some way. For example to review a document or receipt, confirm a password reset, or to update their details.
2. Once clicking the malicious link, the user is sent to a first-stage URL before being redirected a number of times. Typically, at least twice before the AiTM site is reached. This first-stage URL is often benign in nature in order to circumvent basic link-scanning by ingress email filters. Common tactics include:
   • Using an online URL link shortener service (such as bit.ly)
   • Abusing legitimate and popular sites with open redirect parameters
   • Sending users to legitimate, but compromised sites
   • Incorporating the victim’s domain as a subdomain of an adversary-controlled domain (E.G victim.com.au.hacked.cloud)
   • Sub-domain hijacking of a legitimate site
3. Before the AiTM site is reached the user is presented with a Cloudflare Managed Challenge. This prevents the AiTM site from being detected by automated URL scanners when passing through the email filters, as well as internet-wide phishing page scanners.
4. After passing the challenge, the user is presented with an Office 365 sign-in portal. The username is typically pre-filled in based on URL parameters so company branding is immediately present.
5. Once the user enters their credentials and passes MFA, they are redirected to the real Office 365 landing page. The token has now been acquired by the adversary.

Importantly, the source IP address of malicious sign-ins may not be the same as the IP address of the AiTM site. It is expected that the authentication flow is proxied through another adversary-controlled server or proxy service, or, the AiTM site is behind a load-balancer or CDN (thereby disguising the real host IP).

‍

Background

On 13/09/2023, Fortian’s security operations centre responded to an incident involving a user interacting with an AiTM website.

The victim received an email from the sender ngewirtz@adleraphasiacenter.org with a subject of Request #12/Sep/2023 and sender display name spoofing that of the target organisation’s name. The email in question was sent from a previously compromised account relating to a not for profit organisation named Adler Aphasia Center.

This email contained the URL hxxp://l.billing01.email-allstate[.]com/rts/go2.aspx?h=813395&tp=i-1NHD-A2-VhS-33P9Mu-2T-4OCJp-1c-KMG2-332gCa-l9CyBV64dS-iEzH7&x=robustpools.co.za/words/as%2F&cf=4298&v=[REDACTED BASE64]#[REDACTED BASE64]== which, when clicked, redirected the user to the website robustpools[.]co.za. Here the user was presented with their organisation’s legitimate sign in page, whereby they authenticated as they ordinarily would. From the end user’s perspective, this was no different to any regular authentication event – the background images, processing times, and MFA prompts all perfectly matched the regular sign in flow. This is to be expected, given that the website is simply proxying the sign in against AAD.

After the user entered their credentials, several sign-in attempts were immediately initiated from the threat actor-controlled IP address. After resetting the accountss password and sign in session, the threat actor continued to replay the stolen sign in session.

This same campaign was observed targeting other users over several days, but with differing first-stage and redirect URLs. In all instances, we observed that regardless of the phishing site, the sign in will be initiated to Office 365. This is likely because it is an application that every AAD account will have access to, regardless of licensing or what the target account is used for.

‍

Uncovering Infrastructure

When loading the AiTM site in a virtual sandbox, it became evident that the IP initiating the proxied sign-in differed from IP initiating the sign to the victim account in the initial incident. Also interesting was that this IP geo-located to the United States of America – the same location as where the virtual machine was hosted. When testing the login via a virtual machine hosted in Australia South-East (Victoria), the IP address geo-located to Victoria.

We suspected that the threat actor may be dynamically routing the proxied sign in requests via IPs with the same geolocation as the victim, so we decided to try several more sign ins to test the hypothesis. Each time we reloaded the AiTM page and attempted a login with fake credentials, we would see a new IP address attempting to sign into the account. Resultingly, we were able to map out a large subset of the adversary’s infrastructure by testing bad passwords against real Azure AD sandbox accounts.

Each sign in attempt would proxy via a new IP address. In every instance, the IP address geo-located to the same region as the virtual machine that loaded the AiTM page. Most notably, all the IP addresses mapped to legitimate telecommunication companies of the respective country.

From the AiTM site czetwer[.]com, we were able to uncover 30 IPs across North America, Germany, and Australia (see IoC appendix for details). This indicates an expansive attacker-controlled network. At the time of writing, analysis of the IP addresses yields no connection to known threat actors. Majority of IP addresses were clean in online scanning and were not featured in incident write-ups. No direct link was observed, though we believe with medium confidence that the campaign is leveraging the EvilProxy toolkit. We also suspect that the threat actor is using a residential proxy service (such as SocksEscort) to proxy the sign-in flows from AiTM sites. Of note, the attacker leveraged proxies in North America, Europe, and Australasia, suggesting a potentially global victimology.

‍

Detection efforts

Given that proxied sign ins originate from benign residential IP addresses, the challenge is identifying sign ins that blend in with legitimate sign in events. From the observed samples, we identified several key components that we can leverage for detection strategies:

1. AiTM phishing campaigns are often created and maintained by initial access brokers (IABs). IABs have an incentive to gain access to applications that are most easily abused by extortion groups, and are present in most if not all organisations. In all our observed examples the target application was Office 365.
2. The source IP address of the malicious sign-in activity was performed from a previously unseen IP address for the user. In many instances, the IPs were also from internet service providers previously unassociated with the user.
3. Malicious sign-ins were proceeded by a URL click in an email.
4. The URL redirect chain involved several connections to domains that had not previously been observed in the client environment, and importantly include a Cloudflare challenge to prevent automated scanning.

Many of these indicators are too noisy to reliably alert on in isolation. For example, we cannot alert on all URL clicks from emails. However, we can correlate multiple events to ascertain a malicious pattern of activity.

For this, Fortian recommends the following:

1. Alerting on new sign-in attempts against an account where that IP and associated ISP have not previously been observed. In our testing, this query logic has proven highly effective at detecting AiTM sign ins proxied via residential IPs, while ignoring noise from legitimate user sign ins from dynamic IP addresses. For this, your query will need to perform the following:
   • Baseline previously seen IP addresses (determine a look-back that you feel comfortable with. We went with 14 days because of Sentinel’s look back restriction for alerts. These IP addresses are those which will be ignored from query results
   • Ignore sign ins from on-boarded and compliant devices.
   • Filter out sign-ins where any stage of the sign-in flow was previously satisfied by a claim in the token. This step is important because all the AiTM sign ins initiate a brand-new sign in flow. This will therefore filter noise from users who are re-authenticating from new IP addresses.
   • Filter results where the new IP address for a user originates from the same ISP that is previously associated with the user. For this step, you can rely on the Autonomous System Number associated with the IP address. For example, if a user always logs in from Telco A IP addresses, but now initiates a brand new sign in from Telco B, the alert should trigger.
2. Alerting when users clicking URLs contained inside emails that were sent from unfamiliar senders and included elements of the organisation’s name in the sender display name. This has also proven highly effective at detecting both AiTM attacks and credential harvesting attempts. This alert has not been overly noisy, as there are very few legitimate instances where an unfamiliar sender will include the customer organisation’s name in the email components.

Furthermore given these new tactics employed by threat actors, we highly recommend reconsidering alerting infrastructure that relies upon geo-location for filtering. For example, if you have alerts that filter activity if an IP geo-locates to your organization’s jurisdiction, remain cognisant that this presents the risk of false negatives.

As these sign ins blend in almost exactly with regular user sign-in activity, alerts tend to lack strong indicators. Therefore additional investigation efforts will be required, and for this we recommend the following steps:

1. Identifying user interaction with URLs inside emails that preceded the malicious sign in.
2. Investigating past user sign in activity to determine if they have previously signed in from that IP address or from other IP addresses associated with the ISP.
3. Investigating device information via sign in logs to determine if the device or user agent is associated with past activity for the user.
4. Compare the suspicious sign-in to proximate sign in events. If, for example, the user has signed in from one particular IP address all day, and suddenly signs in from a totally different IP address, this should heighten suspicion.
5. Comparing the suspicious sign-in to proximate sign-ins. A sudden change in IP address amidst sign ins from the user’s standard IP address warrants suspicion.

Prevention

Attacks of this nature underline the importance of device compliance controls to support other identity-based security controls. Fortian recommends organisations require users and devices to meet certain compliance requirements to access company resources. This can be achieved in Intune by defining rules and settings devices must meet to be compliant. Conditional access rules can then be deployed to restrict user access to applications if they do not meet the defined device compliance requirements. This would mean that sign ins which are proxied by an AiTM server will fail conditional access checks due to device compliance, rendering the attack ineffective. You can learn more here: https://learn.microsoft.com/en-us/mem/intune/protect/device-compliance-get-started

From a behavioural perspective, end users can protect themselves by remaining vigilant of the following key indicators leveraged in this attack:

1. Phishing emails related to this attack tend to employ display name spoofing. This is a technique where the threat actor will change their email’s display name to match that of the victim organisation. End users should always ensure that emails which contain the organisation in the display name originate from an email address that is legitimately part of the organisation’s domain. For example, emails that include “Fortian” in the display name will originate from @fortian.com.au email addresses.
2. When users sign into their AAD accounts, they should verify that the login page they are presented with contains a Microsoft-related URL, such as Microsoft.com, Office.com, sharepoint.com, and azure.com.
3. End users should be suspicious when presented with a Cloudflare Managed Challenge before being redirected to the Microsoft login page. This is a technique used to prevent the AiTM site from being detected by automated URL scanners when passing through the email filters, as well as internet-wide phishing page scanners.
4. Emails attempting to elicit a sense of urgency from users. In Fortian’s observation, emails in this campaign try elicit an urgent response from the target. For example, a notification that your account will soon lose access to a resource, an overdue invoice, or an important voicemail.

‍

Indicators of compromise