Shifting AiTM Techniques

An increasingly prevalent cyber-attack we detect, and Adversarial Simulation we replicate, leverages Adversary-in-the-Middle (AiTM) to successfully exploit cloud-native identity layers. As a well established credential theft technique, AiTM is now evolving from simple login portal replicas to the abuse of trusted services, making attacks harder to detect and enabling adversaries to bypass traditional security controls.

In this piece, we’ll detail how AiTM techniques are advancing, including:

• Why attackers are increasingly using SVG redirect lures to evade detection.
• How trusted platforms such as Microsoft Visio and Cloudflare Workers are being abused to deliver malicious links.
• Why dynamic, fingerprinting-resistant phishing kits are getting harder to track.
• How proactive measures like ASN blocking and phishing-resistant MFA can help to reduce exposure.
• How poorly implemented kits and infrastructure leaks (e.g. misconfigured domains, static artefacts, exposed hosting providers) create detection opportunities despite growing sophistication.
• Which sectors are being most actively targeted by these campaigns (Finance, Retail, Insurance, Pharmaceuticals, Healthcare/HealthTech) and how these aligns with wider financially motivated attack trends.

To support defenders, we also provide direct evidence from detected attacks and adversarial simulations, including Indicators of Compromise (IcCs) to enable detection.

The attack diagram below shows how adversaries typically deliver lures, evade detection, proxy authentication flows, steal post-MFA tokens, manipulate accounts, and abuse compromised identities across tracked campaigns.

JUMPSEC have previously detailed more of the fundamentals on AiTM campaigns; this piece highlights how the techniques have continued to evolve. The AiTM kits we’ve tracked also bear resemblance to campaigns documented by Sekoia, including Tycoon 2FA and Sneaky 2FA, highlighting a wider trend in the evolution of these techniques.

The key chronological AiTM attacker actions tracked by JUMPSEC.

A common vector we are seeing more and more of, is tricking the victim into downloading a SVG file from a trusted service, once the SVG file downloads and is executed, it requires a password that was provided to the user in the initial phishing lure.

The SVG contained the following:

Which then takes the user to here:

This turned out to be a poorly implemented and easily fingerprintable phishing kit, as the attacker had failed to remove a trailing and requested resources from the impersonated page:

As always, the full list of IoCs can be found here on JUMPSEC’s GitHub.

Another campaign which recently caught our eye was the use of Microsoft Visio to host phishing URLs. This involved a poorly formatted phishing email with a link to a Visio drawing. The Visio drawing had hints of clickfix in it, although it wasn’t the traditional CTRL+R and <please paste this PowerShell in>  the attacker knew that without holding CTRL the link would not be followed.

Instances of this are widespread, a valid account being used to leverage Visio licencing, and making the Visio document publicly accessible.

This ultimately led to the AiTM page that we have been expected from the start. This bares resemblance to the .es domains we were seeing previously.

This method of delivery bares a stark resemblance to one JUMPSEC has seen in other instances of phishing kits, namely https://www.jumpsec.com/guides/uk-industrial-sector-aitm-phishing-campaign/. Where a poorly implemented version of this kit led to the discovery of 250+ domains tied to staging these services. It seems the easily fingerprintable logic has been removed, as it’s now not possible to rely on the static content, as the content now appears dynamic.

Let’s dig into the logic. The first page excepts a human to fill the captcha requests

Once that’s fulfilled it will post the captcha response back to the phishing kit.

This results in heavily obfuscated but simple JavaScript redirection.

The following is a snippet of said JS variables:

Several months ago, we saw an influx of it.com domains being used for phishing, now it seems other rentable and easily obtainable domains such as de.com are being used.

Here’s an example:

This simple DocuSign branded email is a relatively immature effort to trick unsuspecting users.

Once visited, the site you are presented with contains the com.de domain and the Family value is a base64 encoded email parameter, to give the attacker insight around the victim user, it is also used to auto-populate the Microsoft AiTM service.

Notable findings:

• The title and HTML elements are entirely dynamic, meaning the content is dynamically generated upon visiting the service, this is clear from the title in the above instance being “icecreambean” and every time the site is reloaded, this changes to a separate value. This is to prevent static fingerprinting of services.
• The HTML response data also changes, note the “Verifying Secure Online Environment” This value also changes dynamically on every visit again leading to limiting static fingerprinting.
• If the “Family” parameter is not provided, the turnstile captcha will not work and the AITM site will never load, meaning the expected base64 encoded parameter is required on visiting.

Where things become a lot harder to fingerprint is in the trusted service space. Attackers are leveraging trusted services such as Adobe or other presentation sharing services to target users through trusted domains. Commonly we observe Cloudflare being abused to facilitate hosting and staging of the front-end infrastructure. With the novel technology being created by Cloudflare, essentially, like any other serverless technology can perform the AiTM flow inside of the serverless backend. Meaning attackers can leverage the reputation of the services, whilst also using them to perform malicious actions.

From an adversary’s perspective:

• workers.dev or pages.dev are the domain names used

The attacker controls part of the subdomain:

• <workername>.<controlledbyattacker>.workers.dev
• dev & Pages.dev has a high level of reputation and is being widely abused
• The attacker can set up a Custom Domain – DNS records auto configured by the worker

Newer versions of this kit have been leveraged to bypass conditional access policies, for example polices have gaps pertaining to Entra Joined devices. If a number of actors have been seen to be using User-Agents that tricks Entra into thinking they are coming from an IOS or Mac device, as they are known to be harder to enroll into Entra and due to the wider adoption of BYOD

Also, a worthy mention related to MFA downgrade attacks are possible when the conditional access policy is not configured to enforce phishing resistant MFA and rather is configured to enforce MFA with no requirement on the authentication strength level.

Another anti-fingerprinting blunder by attackers here, as a specific JavaScript library is being used to detect if the victim user is using a private browser window (Incognito mode)

This results in 400 worker domains being actively used for the past 7 months up until hours before the release of this blogpost. As with all attacker infrastructure detailed in this article, the IoCs can be found on our Github, here – https://github.com/tdejmp/AITM-Tracking/blob/main/cloudflareworkers.txt
The backend infrastructure, as discussed, is harder to fingerprint, but anything’s possible. Here’s an example of an active campaign:

• apexcabels[.]co[.]uk
• 104[.]194[.]149[.]222

Through numerous hunting efforts and qualifications, we identified over 200 organisations targeted by this kit. These broadly correlate with the most targeted industries for ransomware extortion, most prominently:

• Financial Services
• Retail
• Insurance
• Pharmaceuticals
• IT Services
• HealthTech and healthcare

A notable exception from the list is Manufacturing, which was most highly targeted in JUMPSEC’s earlier campaign published in April (similar to Tycoon 2FA). Generally, one would expect Manufacturing to be one of the most targeting sectors for ransomware extortion.

The industries most targeted by this AiTM kit tracked by JUMPSEC.

The countries most targeted by this AiTM kit. This reflects the rate of known ransomware extortion instances, with the UK consistently at 5% and the US at 50-55% for several years. Interestingly, Germany’s recent increase in known ransomware attacks over the past 6-12 months is also reflected, now surpassing the UK for the first time.

Social Engineering and Helpdesk Abuse

As seen with previous high-profile breaches, attackers are commonly abusing helpdesk password and MFA reset processes in attempt to gain access to victim user accounts. This usually takes the form of vishing or attempting to contact the service desk and attempting to coerce the helpdesk staff into resetting a victim’s account password or MFA method, depending on what the attacker has already obtained. These are usually well equipped and highly motivated attackers that have a wealth of information that they have obtained public sources to successfully pose or impersonate a user.

A mature stance to take with social engineering is to assume at some point it will be possible, and an attacker will be able to perform the actions they desire. Therefore, it’s imperative that subsequent actions are detected and closed down prior to any damage being done. Let’s consider the following:

• The attacker coerces the helpdesk staff into resetting the password and MFA of a user
• The attacker then logs into the account from their own device, in most cases this will force the MFA registration process and will require the attacker to register their own MFA method as part of the required conditional access

Post AITM

After successfully leveraging AiTM, attackers TTPs usually involve attackers adding their own authentication methods, such as their own MFA to the compromised account. JUMPSEC’s DART team have seen successful intrusion methods through blended social engineering and AiTM that result in the following immediate attacker actions:

• Adversary adds their own modern MFA method (Authenticator device)
• Adversary adds their own SMS MFA method
• Adversary adds an email forwarding rule as part of a business email compromise campaign
• Adversary does nothing in terms of persistence and immediately starts abusing the account, and organization reputation to send another campaign out

Preventing Social Engineering and Helpdesk Abuse & AiTM

Conditional Access, especially in Microsoft centric AITM abuse, play a key part in the protection of identities. Several key controls can help to limit identity theft:

• Enforce MFA (modern authentication methods and not just email or SMS)
• Enforcing hybrid joined or compliant devices
• Enforcing phishing resistant MFA (using authentication strength controls, and mandating a certain authentication strength for users)
• Enforcing re-MFA on risky sign ins.
• Block countries/regions from which you never expect a sign-in
• Reduce exceptions on conditional access policies where possible
• CAE and Token Binding

Another proactive consideration is the blocking of known abused services, whilst this isn’t a conclusive list, JUMPSEC advises considering blocking the following hosting providers at identity provider level – to be clear, blocking these at the identity layer wont prevent users from visiting sites hosted on these providers, more so authentication attempts originating from them.

There is a degree of operational risk, as legitimate services could be affected. We therefore recommend hunting first to confirm whether these networks are used in your environment before enforcing a block. That said, in most cases users should not be authenticating from these addresses, making them high-value candidates for restriction.

• Digital Ocean – https://github.com/platformbuilds/Digitalocean-ASN-and-IPs-List/blob/master/digitalocean_ip_cidr_blocks.lst
• Tor Exit Nodes – https://github.com/platformbuilds/Tor-IP-Addresses/blob/master/tor-exit-nodes.lst
• Hostinger ASN
  • 147.93.16.0/20
  • 147.93.96.0/20
  • 148.230.80.0/20
  • 151.106.112.0/20
  • 151.106.96.0/20
  • 156.67.208.0/20
  • 156.67.64.0/20
  • 217.21.80.0/20
  • 31.220.48.0/20
  • 31.97.128.0/20
• Linode:
  • 178.79.128.0/18
  • 45.79.128.0/18
  • 139.144.192.0/19
  • 139.162.0.0/19
  • 139.162.128.0/19
  • 139.162.160.0/19
  • 139.162.192.0/19
  • 139.162.224.0/19
  • 139.162.32.0/19
  • 139.162.64.0/19
• Vultr – https://geofeed.constant.com/?text

Reviewing and testing the helpdesk credential reset process is also an important step in securing the identity security information.

• Never reset based only on username or employee ID.
• Require at least two independent verification factors (e.g., employee badge number + callback to a pre-registered phone + MFA code).
• Compare against HR system data that can’t be easily guessed or found online (e.g., manager name, last training completion date, internal extension).
• If the request comes by phone/email/chat, only call back using the official contact number stored in the corporate directory — not the one provided by the requester.
• Limit which accounts helpdesk can reset (e.g., no domain admin or executive resets without supervisor approval).
• Require supervisor approval (or two IT staff members) to reset credentials for high-risk roles (executives, IT admins, finance staff).
• Train helpdesk staff to recognize urgency pressure (“CEO needs this now”), intimidation, or oversharing attempts.

Detecting Social Engineering and Helpdesk Abuse & AiTM

Common mistakes with see with the proactive detection of AiTM unfractured is the reliance on detected front end infrastructure. It would be impossible to automatically include all of the domains that are staged immediately in a blocklist. The focus should be on the backend infrastructure, however with that being said, there are some quick wins that can be had, involving proactive blocking of commonly abused hosting providers (as provided above).

Custom detection logic that captures the following:

• Unfamiliar sign in properties – this is a great indicator that an account has been signed into with various properties that don’t match their standard operating practices.
• Impossible travel – Another great Microsoft standard detection will
• A new MFA method added (this can be enriched with a new IP address also being used)
• Email forwarding rule creation – this is a generic detection Microsoft offers that is in most cases overlooked but is a key indicator. This again can be enriched logins from new IP addresses.

AiTM continues to evolve in uneven ways. Some campaigns demonstrate increasingly advanced techniques, such as abuse of trusted platforms and dynamic, fingerprint-resistant kits. Others remain clumsy and poorly implemented, yet still succeed against organisations with gaps in their defences. This mix of sophistication and simplicity underscores why AiTM remains one of the most effective attack methods. Defenders must prepare for both ends of the spectrum.

• JUMPSEC Github: https://github.com/tdejmp/AITM-Tracking/tree/main
• Previous JUMPSEC AiTM Article: https://www.jumpsec.com/guides/uk-industrial-sector-aitm-phishing-campaign/
• Sekoia Research: https://blog.sekoia.io/global-analysis-of-adversary-in-the-middle-phishing-threats/
• Push Research: https://pushsecurity.com/blog/mfa-downgrade-attacks/