Attackers are hijacking subdomains by creating Azure DNS Zones for domains that were previously delegated to Azure & not properly decommissioned. This is made possible by Azure not having an authorization check on creating Public DNS Zones. Abuse requires a misconfiguration & has been ongoing since ~2018 at least.
Actions
Establish proper DNS lifecycle management. Ensure you remove unneeded NS records. Check for domain resolution to uncommon AS. Some IPs from a specific case below.
Notes
This is me using some IoCs to excuse me posting “TIL” about something that bit us (and a couple other companies by the looks of it). Chances are the old-heads already know this.
Situation: Previously a subdomain of ours was delegate to Azure. This domain was (partially) decommissioned in 2025, with the Azure DNS Zone being removed but the NS record pointing to Azure DNS servers remaining active. April 2026 new A records were set up pointing to AS 212238 IPs, hosting what appears to be a Thai language gambling ad. We strongly believe this was made possible by the attacker… just creating a new Public DNS Zone in Azure in their own Tenant (Tutorial: Host your domain in Azure DNS | Microsoft Learn). The one tricky part is obtaining a zone with matching nameservers as these are chosen somewhat randomly by Azure, we don’t know how this was achieved in this case.
Checking our TI providers IP lookup we are (by far) not the only “customer” on the IPs below, unfortunately I can’t properly export the list for sharing, maybe one of the DNS wizards here has the ability to do so - we are talking a couple hundred domains dating back to sometimes 2018.
While we didn’t do a full analysis on potential malicious behaviour by the hosted site (e.g. cookie extraction for parent domains, clickfix, …) I included the other domains it contacted in our sandboxes in the IoCs. I’ll also include an example or two for other domains where this is still live.
Credit for detecting the original issue that sparked the investigation & reporting it to our VDP to Teun van der Ploeg.
IoCs:
A records post compromise:
86.38.247[.]29
209.92.170[.]22
Other domains used by the loaded page:
cdn.stillsunday[.]pl
www.bigc.co[.]th
appbox.z28akc6bv4[.]com
st.bigc-cs[.]com
Sample "live" cases:
welcome-to-mikalai-world3.labs.vocovo[.]com
new.fly.myvegas[.]com
It’s a sort of subdomain hijacking, but using leftover NS records instead of CNAME/A/AAAA records? It’s a little more powerful as it allows the attacker to actually make changes in the zone but in the ends it’s the same issue.
Obvious disclaimer: We can’t prove this is exactly what happened as we do not have visibility on the Azure tenant of the attacker, but we had multiple folx here come to the same conclusion & it matches the documentation.
@neurovagrant was kind enough to help me out with some historical DNS data so we now have an at least partial list of organisations impacted. I’ll include the list of identified likely-hijacked zones below - the full list of domains is too large to share here, even as an attachment (lol, 600k+ domains), but you can find it over on my server: https://files.nyanbinary.de/misc/rdns.json
Most of these are still up (as in: DNS is still hijacked) though we have a few sites that don’t show the same Thai gambling template. Additionally, while crawling the identified sites I ran across another few domains on other IPs that are linked & host similar content (I’m only including new domains that are still up here - a lot of the new ones are already down or were never live):
Which in return can yield us a long list of domains and …
I’ll stop the rabbit hole here for now & would explicitly ask y’all if anyone has a good idea what to do here: Taking down these instances (either on Azure level or on IP level) is something MS & the hoster can do, but unfortunately, unlike normal Subdomain Hijacking, this doesn’t resolve the issue, this can only be done by MS actually implementing proof-of-ownership for DNS Zone creation or the owning org cleaning up their dangling NS records. I’m reaching out to a few orgs (.de & Beyondtrust) but I don’t have high hopes that even they’ll all respond…