Insights

Recent investigations by the Chorus Cyber CSOC have uncovered a surge in Adversary-in-the-Middle (AiTM) phishing attacks leveraging domains ending in [.]sa[.]com, an unusual second-level domain associated with Saudi Arabia. These attacks are strongly linked to the Tycoon 2FA Phishing-as-a-Service (PhaaS) kit and have been observed across multiple organisations, indicating a shared infrastructure or threat actor. This article outlines the attack patterns, detection strategies, and actionable recommendations to help organisations strengthen their defences against AiTM attacks exploiting [.]sa[.]com domains.

What has the Chorus CSOC observed with AiTM attacks exploiting [.]sa[.]com domains?

While Adversary-in-the-Middle (AiTM) attacks have been common in the past few years, some specific trends and observations behind them can change over time.

In the past couple of months, the Chorus Cyber CSOC has noticed many AiTM attacks involving network connections to domains ending in [.]sa[.]com. This is a country code second-level domain associated with Saudi Arabia and is very uncommon amongst the network data seen across our customers.

Threat intelligence suggests that most of the attacks involving this domain are *likely * to be part of the Tycoon 2FA PhaaS (Phishing-as-a-service) phish kit.

Creating new detection and containment rules as a result

Our CSOC has investigated various successful and unsuccessful AiTM attacks where this indicator was identified. Because of this, a new detection was created to look for network events to *[.]sa[.]com domains followed by a list of possible Microsoft domains associated with login behaviour from the same initiating process within a close timeframe, including msftauth.net and msauth.net. This can help catch likely clicks where the user’s browser (e.g edge.exe) makes a connection to the 2 domain patterns in 60 seconds.

After further threat hunting and research into normal traffic for all customers, a decision was made to add a threat indicator to Defender for Endpoint to block all *[.]sa[.]com connections, where any edge cases can be excluded as needed.

In many cases, the same domains were also seen across multiple organisations, suggesting that the same threat actor or same back-end used was part of the phishing service in multiple attacks. This highlights the importance of using threat intelligence indicators from alerts to strengthen detection and blocking across all customers; insights from one customer’s incident can help prevent attacks on others.

Most of the time, these AiTM phishing attacks originate from a known sender to the victim, as part of a business email compromised chain (BEC). When a user is compromised, attackers often use that victim’s account to forward the phish to their contact list. This is because victims are more likely to trust the email coming from a known sender and click on the link. These phishing attacks are often sent via email, sometimes via Teams and more recently being sent as calendar invites.

Example phish page scan by urlquery.net: https://urlquery.net/report/426b9884-f7e0-41d8-b201-aa48c0a531aa (This is public info, involving a domain we saw in the screenshot above)

Example of blocked activity and click detected. Here the high alert is the custom click detection, while the informational alert from Defender for Endpoint relates to a network connection blocked due to the sa[.]com indicator:

Example of activity prior to blocking being in place, resulting in near-compromise (conditional access blocked the sign-in attempts):

What are the recommendations for protecting against AiTM attacks using [.]sa[.]com domains?

Our recommendations are:

• Blocking unknown/spoofed platforms: This is often a quick and easy win for most organisations. Deployment of a Conditional Access policy to block login attempts that occur from sources which do not appear as Linux, Windows, macOS, iOS, Android or Windows Phone is advised. This will block things such the axios user agent, which is quite common for AiTM attacks, including this one. Other unexpected platforms should be blocked too, such as Linux, macOS or Windows Phone if you confirm users are not expected to use these platforms. This is because attackers often spoof their sign-in requests to appear as those platforms.
• Web content filtering: Block recently registered domains (via your own proxy or via Microsoft Defender for Endpoint web filtering) Web content filtering – Microsoft Defender for Endpoint | Microsoft Learn
• Geo-blocking: Block and monitor usage of [.]sa[.]com domains. Consider improvements to geo-blocking where possible, by either blocking all countries and only allowing those expected for work or creating policies for each country and groups of users.
• Device compliance: Block sign-ins from unknown platforms in Conditional Access – this is a general recommendation for AiTM attacks. Requiring users to operate only from compliant or Microsoft Entra hybrid joined devices helps reduce the risk of compromise, as attackers will not be able to sign in from an unknown device. Any operating systems/platforms not bound by Device Compliance should be blocked or restricted by other policies, such as device registration and usage of office MS applications (MAM). Block unsupported platforms with Conditional Access – Microsoft Entra ID | Microsoft Learn
• Risk-based Conditional Access (Entra P2): Risk-based Conditional Access can be used to block access or force users to reset their password and re-authenticate following a risky sign-in. Note that MFA and reauthentication requirement on risk is not enough to prevent AiTM, and access should be blocked or require a password reset which will invalidate the sign-in sessions too. This does mean it should ideally be used in high confidence to reduce potential operational impact, this usually means choosing High severity only or both High and Medium depending on sign-in risk history.
• Phish-resistant credentials: Use phish-resistant credentials such as FIDO2 where possible and/or enforce Device join or compliance requirement for sign-ins in Conditional Access.

Conclusion

Cybercriminals are constantly innovating, seeking new techniques to bypass security controls and exploit human trust. At Chorus Cyber, our CSOC remains vigilant by continuously monitoring emerging trends, refining detection capabilities, and deploying rapid response measures to protect our customers. By combining proactive threat intelligence with decisive action and true response, we ensure that insights from one incident strengthen defences across all environments, keeping organisations resilient against evolving threats.