Free Tenants, Fake Help Desks

Email bombing followed by a Microsoft Teams message from "IT support" is not new tradecraft. It's been public since ransomware crews started using it in 2024, Microsoft ships native detections for it, and we have written about the phone-call variant of it here before — our Aur0ra ransomware write-up describes an intrusion that started exactly this way, with vishing after an aggressive mail flood.

However, what we want to surface is what the infrastructure did over the course of a single sustained campaign. Across roughly eight weeks in mid-2026, we watched one operator run this technique against an environment we monitor, get their domains identified and blocked repeatedly, and adapt — ending up somewhere meaningfully harder to defend against than where they started.

Below is the anatomy, infrastructure, what it looks like when it succeeds, as well as some of the indicators found. Everything here is attacker-side.

The technique

Email bombing is the cheap half. The attacker walks a target's address through a few hundred legitimate newsletter and subscription signup forms — mailing list platforms, e-commerce welcome flows, SaaS trial confirmations. Within minutes the mailbox is being flooded with thousands of emails every hour.

None of it is malicious. Every message is a real opt-in confirmation from a real sender, correctly authenticated, arriving from infrastructure with a legitimate reputation. There is no payload, no link worth blocking, and no sender worth adding to a deny list. That is the entire point: the bomb is not the attack, it is the pretext.

Ten to thirty minutes into the email bomb, a conveniently timed Teams chat or call arrives from outside the tenant. The display name usually says something like IT Service Desk. The message offers to fix the spam problem. What follows is a request for remote access, or a "verification step" that is actually a paste-and-run command.

The email flood is not a denial of service against the mailbox. It is a denial of service against the person's judgement.

The Teams leg is what makes this hard. Federation delivers it. It never touches the mail gateway, attachment sandbox, URL rewriter, or the phishing banner. The entire stack most organizations have spent a decade tuning sits on a channel the attacker is not using. Because the mail half is composed of genuinely legitimate messages, the parts of the attack that do hit the mail path are, individually, not attacks at all.

Eight weeks of infrastructure

The operator ran three distinct setups across the campaign. Each shift followed their previous infrastructure being identified and blocked.

Phase 1 — Cheap TLDs, reused sender

Registered .top domains — help-desk-tech[.]top, then systems-desk-tech[.]top, all behind plain American-sounding display names. Everything sent from a single Netherlands VPS. Burn one domain and the reused address gives up the next one, which is exactly what happened.

Phase 2 — Lookalike domains, compartmentalized senders

A shift to helpdesk-support-office-3[.]com and helpdesk-support-office-4[.]com, with accounts numbered like inventory: helpdesk.supervisor.0ca, .0gv, .0vd. Sending moved to three separate networks — one per account, all at the same hosting provider. Compartmentalizing senders means burning one account no longer burns the others.

Two more .top domains ran alongside these in the same window — getclient-service[.]top and gethelptechsystem[.]top — this time behind ordinary-name personas rather than help-desk role accounts. The compartmentalization was not yet complete, though: getclient-service[.]top was still sending from the same Netherlands VPS as Phase 1, which is exactly how it got tied back to the earlier activity.

Phase 3 — They stopped buying domains

The operator moved to free Microsoft 365 trial tenants: getsystechopsdesk, getsyscloudcontroldesk, getsyscloudaccessdesk and four more, all on onmicrosoft[.]com. The personas became ordinary full names rather than help-desk role accounts. In a single 24-hour window, three personas across two tenants contacted six employees.

Each of these tenants is free, provisions in minutes, and can be created in unlimited quantity. There is no registration record to age, no WHOIS to correlate, and no domain reputation to accrue, because the namespace belongs to Microsoft. The message arrives over Teams federation from inside the Microsoft cloud, from infrastructure you already trust.

Microsoft ships a control for this. ExternalAccessWithTrialTenants governs federation with trial-only tenants, those carrying no purchased licenses, and its default value is Blocked. On paper, Phase 3 should not have worked at all.

It worked repeatedly. That leaves two possibilities, and we could not close the gap between them from the telemetry we hold: either the setting had been moved to Allowed in this tenant, or the operator attached a purchased license to each tenant so that none of them were trial-only. A native, default-on control existed and did not stop this, and the reason it did not stop this is worth establishing in your own environment before you assume you are covered.

Tenant blocking still works, and it should be your response. Note, though: ExternalAccessWithTrialTenants blocks trial-only tenants as a class before first contact, whereas blocking a named tenant happens one at a time, and only after someone has already been messaged. If the class-level control is not in force, that second mode is all you have left: blocking individually, after contact, against an adversary whose replacement cost is zero and whose supply is unbounded.

In this particular environment the class-level change was recommended and declined: restricting external access to an allowlist was judged too disruptive to the business, and per-domain blocking became the standing process instead, run as each new wave arrived. This is the common outcome. The highest-value control in the hardening list below is also the one most likely to be refused as disruptive, which is why the reactive mode is where most organizations end up.

One detail from Phase 2 is worth noting for hunters: all three helpdesk-support-office accounts sent from the same hosting provider across three different networks. If you catch one address in this pattern, the provider ASN is a better pivot than the address.

What it looks like when it works

The environment above held. Users flagged the calls, the tenants got blocked, and no compromise followed.

We saw the same type of technique succeeding in other environments as well. Times below are relative to the first Teams message. Notably, that message came from a mailbox on a legitimate domain — so there was no suspicious registration to catch, and none of the indicators listed at the end of this post would have matched it.

Sixty-five minutes from first contact to domain reconnaissance.

The more useful number is the gap between step one and step two. Two and a half minutes is less time than it takes to walk to a colleague's desk and ask whether the help desk really just messaged them. Any control that depends on a human noticing and escalating mid-conversation has to work at that speed or it does not work at all.

The control that performed best was the users

Users reported external calls. Microsoft 365 exposes a native user-reported signal for exactly this, and it fired repeatedly through the peak of the campaign. In the final wave, two of the six targeted employees flagged the contact as suspicious while the campaign was still in progress — before anything else happened.

That is security awareness training doing what it is meant to do, and out-performing the technical stack on this specific attack. We often hear that users are the weakest link, and it has become a comfortable thing for security teams to believe. It did not hold true here. The mail gateway did not catch this. The users did.

Detection and response must happen quickly. A user-reported Teams call is a high-fidelity signal from someone who was actually there, and given the two-and-a-half-minute figure above, its value decays quickly.

Hardening and detection

Restrict Teams external access to an allowlist. Default Teams federation permits contact from any tenant on earth. Moving to allowlisted partner domains ends this technique at the door and is the single highest-value change available. Expect resistance — it was declined as too disruptive in the environment described above, which is how that organization ended up blocking tenants one at a time for two months. If a full allowlist is not politically achievable, confirm Get-CsTenantFederationConfiguration still shows ExternalAccessWithTrialTenants: Blocked — the default since 2024. Teams external access has no wildcard domain block, so this setting, not a namespace pattern, is the control that covers free tenants as a class. If a partner genuinely runs a trial-only tenant, safelist it with AllowedTrialTenantDomains rather than flipping the whole setting to Allowed.

Treat a mail flood as an incident precursor, not a spam problem. The instinct is to silence mail-bombing alerts because nothing in the flood is malicious. Resist it. The flood is a countdown. When one fires, the immediate question is who has contacted that user out-of-band in the last hour — Teams, phone, SMS.

Correlate the two halves. Mail bombing alone is ambiguous. An external Teams contact alone is ambiguous. The same user hit by both inside a short window is close to conclusive, and Microsoft ships a native alert title for that exact pairing. If you build one correlation rule out of this post, build that one.

Alert on remote-access tooling arriving out of process. The payoff step is a remote-access client or a pasted command. Maintain a list of RMM tools sanctioned in your environment and alert on everything else. Pay particular attention to services installing from user-writable paths, which is how these tools land when someone is talked into running the installer.

Watch for ClickFix patterns on the endpoint. The Run dialog, mshta, and clipboard-sourced PowerShell are the recurring shapes. Given the two-and-a-half-minute window, endpoint detection is realistically the last line here rather than the first.

Tell users the help desk will never message them unprompted. Cheap, fast, and demonstrably effective — it is what held in the environment that did not get compromised. Pair it with a named internal channel for verifying that a contact is genuine, so a suspicious user has somewhere to go in under two minutes.

Indicators

All attacker-controlled. Worth noting that every sending address below was clean or near-clean across VirusTotal's engines at the time of the activity — reputation lookups were not going to catch this.

Sending addresses:

187.126.45[.]63     Clouvider Limited (AS62240)   helpdesk.supervisor.0gv@helpdesk-support-office-4[.]com
185.215.181[.]16    Clouvider Limited (AS62240)   helpdesk.supervisor.0vd@helpdesk-support-office-3[.]com
62.106.78[.]129     Clouvider Limited (AS62240)   helpdesk.supervisor.0ca@helpdesk-support-office-4[.]com
89.187.25[.]197     Ultahost (AS214036)           personas on getclient-service[.]top
2.58.14[.]230       Gwy It Pty Ltd (AS199959)     gethelptechsystem[.]top

The column is the ASN registrant, not geolocation, and the two differ here: 89.187.25[.]197 is the Netherlands-hosted VPS reused from Phase 1, which is how getclient-service[.]top was tied back to the earlier activity.

Registered domains:

help-desk-tech[.]top
systems-desk-tech[.]top
getclient-service[.]top
gethelptechsystem[.]top
helpdesk-support-office-3[.]com
helpdesk-support-office-4[.]com

Free Microsoft 365 tenants:

getsystechopsdesk[.]onmicrosoft[.]com
getsystechhelpdesk[.]onmicrosoft[.]com
getsyscloudcontroldesk[.]onmicrosoft[.]com
getsyscloudaccessdesk[.]onmicrosoft[.]com
getsyscloudnetworkhubdesk[.]onmicrosoft[.]com
getsyscloudservicehubdesk[.]onmicrosoft[.]com
getsyscloudportalcore[.]onmicrosoft[.]com

Sender accounts and display names:

helpdesk.supervisor.0ca      helpdesk.supervisor.0gv      helpdesk.supervisor.0vd
FrankSanders                 JustinSimmons                JeffreyCollins
OscarSullivan                DylanHamilton                MichaelTurner
ConnorFoster                 JordanColeman                RileyMurray
OwenCook                     RyanBell                     SarahMorgan

Microsoft alert titles covering this chain:

Mail bombing activity detected
Potentially malicious IT support Teams impersonation post mail bombing
Microsoft Teams chat initiated by a suspicious external user
Teams call reported by user as security risk
Possible SPN enumeration via LDAP

ATT&CK techniques observed: T1566 Phishing, T1656 Impersonation, T1078 Valid Accounts, T1219 Remote Access Tools, T1087.002 Domain Account Discovery, T1558.003 Kerberoasting, and T1059.001 PowerShell. T1566.004 Spearphishing Voice also applies to this campaign, but to the call variant specifically — the chain detailed above opened with a Teams chat message rather than a call.