TL;DR - A piece of research posted on r/netsec this week counted 181,874 meeting invites that were accepted, joined or forwarded inside the dataset without anyone checking who sent them. That is the security state of the calendar for most tenants: meetings land, meetings are joined, the organiser is never questioned. Fake Teams meetings are the new phishing emails, and the vishing call that follows is the new credential prompt. What you need to do: run the four-step M365 external-invite lockdown below this week, set anonymous join to off at the tenant default, route the lobby through "people in my org only" by default, and switch on Defender for Office 365 Safe Links for Teams before quarter-end.
If you look after an M365 tenant, this is the week to audit the calendar. A 60-page PDF is a lot to send your CEO, but the family version of the same instinct is what my Personal Security Quick-Start Guide is built around. Same idea, smaller blast radius.
Get my Personal Security Quick-Start Guide - the practical handbook for the controls that actually change your day. 193 pages, no jargon.
Plus: Join 158+ Australians getting one 5-minute security briefing every Friday.
The shape of a fake Teams meeting
The dataset behind the r/netsec post this week is the version with the numbers attached: 181,874 meeting invites accepted, joined or forwarded without anyone checking who sent them. The post was tagged TLDV, for "too lazy, didn't validate", the long-running joke about meeting-invite acceptance behaviour. The number itself is from a piece of published research into meeting-invite acceptance, and the headline finding is that the average user accepts, joins or forwards a meeting without any sender validation step the overwhelming majority of the time.
The shape I keep seeing in ANZ tenants matches the dataset. A meeting invite lands, the title is plausible, the timing is tight enough to discourage scrutiny, and the organiser is a name that looks like it belongs to the business. The calendar entry is now a real slot in the diary with a join link sitting in it. When the meeting time arrives, the link works, the Teams room opens, and the people in the room are the attackers.
The reason this matters is that the calendar is not an inbox, and the training has not caught up. Most phishing awareness training still focuses on email. Most email training still focuses on the link, the attachment, the sender address. None of those are the failure mode for a Teams meeting invite. The failure mode is a calendar entry that looks routine and a join URL that works.
A meeting invite is the only phishing payload that creates its own scheduled slot in the victim's calendar, complete with a working join link, before the victim has thought about it.
Teams Meeting Invites By The Numbers
| Thing | Figure |
|---|---|
| Invites accepted, joined or forwarded without sender validation (per the r/netsec-cited dataset) | 181,874 |
| Default Teams state for anonymous join in a fresh tenant | On |
| Default Teams state for "people in my org" lobby bypass | Anyone in the meeting's organisation |
| Default Teams state for external organisers sending invites to your users | Allowed |
| Where the join URL lives once accepted | In the user's calendar, with one click to join |
| Default Defender for Office 365 coverage for Teams messages and URLs | Off, requires Safe Links plan |
The defaults in the bottom half of that table are why the top half of the table is the number it is. None of the defaults is a single malicious setting. Every one of them is a sensible default for collaboration that nobody has gone back to harden.
What an attacker actually does with a fake Teams meeting
The attack is a sequence, and each step has a working artifact that survives the next. The attacker registers a look-alike domain, sets up a free Microsoft 365 trial or a burner tenant, and sends a Teams meeting invite to a curated list of people inside the target. The title matches the target's actual work, the time is short enough to discourage scrutiny, and the organiser is a plausible name lifted from LinkedIn.
Most users accept without reading the organiser line. The meeting is on the calendar, the join URL is one click away, and the meeting reminder will fire and reinforce the impression the meeting is real. When the meeting time arrives, both the user and the attacker enter. The attacker is on camera or off, depending on the pretext, and the pretext usually starts with audio trouble. The small talk buys time for the pivot.
The pivot is a vishing attempt. The attacker asks the user to "share the deck", "open the share-screen so we can look at the same file", or "click this link to confirm the file is the right version". The link resolves to a credential-harvesting site, to a file that drops a remote access tool, or to a request for the user to read out a one-time code that has just arrived in their SMS. Each pivot option ends in the attacker holding a working identity in the target's environment, and the meeting ends with the user assuming it was a bad call. From there, the playbook is the playbook for any compromised account: business email compromise, lateral movement, mailbox rule creation, session token theft, the long tail. The Teams meeting is the entry point. The damage is everything that comes after.
The four-step M365 external-invite lockdown
The fix is a configuration pass, not a project. Run it on a quiet afternoon, and the whole job fits inside two hours for a small tenant or two days for a 500-seat estate. The four steps are below, in the order I would run them.
Step 1: Block anonymous join at the tenant default
In the Microsoft Teams admin centre, go to Meetings, then Meeting policies, and edit the global default. The relevant setting is "Anonymous users can join a meeting" and the default is on. Turn it off. Anonymous join is the path that lets an attacker join a meeting without an account in any tenant, and turning it off does not break your staff's ability to meet with people from outside your org, because external people from a federated or guest tenant still get in via the guest path. What it breaks is the path where the attacker joins a meeting without any identity at all.
Set "Who can present in meetings" to "Only organizers and co-organizers" for the same global default if you do not already restrict it. The default is "Everyone", which is the vishing pivot the attacker relies on: an open mic and a shared screen are the weapons, and both are off the table if the user is the only one who can present.
Step 2: Restrict who can schedule meetings with external people
In the Teams admin centre, the per-user meeting policy has a setting called "Allow scheduling private meetings". The default is on, which means any user in the tenant can schedule a meeting and invite any external address. That is the lever the attacker pulls when they send the look-alike invite: a user is the recipient, and the user did not have a say in whether the meeting could be scheduled.
The fix is two-part. First, set the "Allow scheduling private meetings" toggle to off for any user who does not have a business need to schedule external meetings, and document the exception list. Second, set the org-level external access configuration to allow only the specific external domains your business actually meets with. Everything else is a candidate for block-by-default.
To configure external access by domain, go to Users, then External access, and click "Add a domain". Add the domains you actually meet with. The "Allow all external domains" toggle should be off for any tenant where the meeting roster is a known set. The same screen is where you set the org-level preference for "People in my organisation can communicate with people in these external organisations" and the "People in my organisation can communicate with people in Teams and Skype for Business organisations" toggles. Both should be on only for the specific domains you trust.
Step 3: Set the lobby to "people in my org only" by default
In the meeting policy, the "Who can bypass the lobby" setting is the one that determines whether an external user waits in the lobby or walks straight into the meeting. The default is "People in my org, trusted organizations, and guests", which means that any guest or federated user from an allowed domain bypasses the lobby. The attackers are not from an allowed domain, so this default does not stop them. What stops them is the lobby.
Set "Who can bypass the lobby" to "People in my org only" at the global default. Set "People dialing in can bypass the lobby" to off. Set "Always let callers bypass the lobby" to off. The shape of the meeting experience changes slightly: every external user waits in the lobby, and a meeting organiser has to actively let them in. That is the point. The vishing attacker cannot pivot to a working session if the user has to actively admit them, and the active admission is the moment the user is most likely to realise the meeting is not what it claims to be.
If a sub-set of your staff genuinely needs "people in trusted orgs" to bypass the lobby (a sales team that meets with partner orgs all day, for example), create a sub-policy for that group, scope it to a security group, and document the exception. The default should be the safer option.
Step 4: Turn on Defender for Office 365 Safe Links for Teams
Safe Links is the URL-rewriting and time-of-click scanning service in Defender for Office 365. It is on by default for email in tenants that have the licence, and it is off by default for Teams. The same URL scanning that protects an inbox protects a Teams chat, and the same time-of-click detonation that protects against a malicious link in email protects against the link the vishing attacker asks the user to open in step four.
In the Microsoft 365 Defender portal, go to Policies, then Safe Links, and create a Safe Links policy that has the "Teams" workload turned on. Apply the policy at the global level. The setting is one checkbox, and it is the difference between a malicious link in a Teams chat being scanned and not being scanned.
If you do not have the Defender for Office 365 plan that includes Safe Links, this is the moment to have the licensing conversation. The cost of the licence is one of the smaller IT line items in an M365 budget, and the cost of a single vishing-driven account compromise is several orders of magnitude higher.
The audit you can run this week
The four steps above are the lockdown. The audit is a separate five-minute pass that confirms the lockdown is still in place, because defaults drift back to permissive whenever a new feature ships or a policy is recreated.
In the Teams admin centre, run the meeting policy report and the external access report. For every meeting policy in the tenant, confirm anonymous join is off, the lobby bypass is set to "people in my org only", and "who can present" is restricted. For the external access configuration, confirm the allowed-domains list is the list of domains your business actually meets with, and that the "allow all" toggle is off. The reports that ship in the admin centre cover both, and a 30-minute pass is enough to confirm the tenant is where you left it.
The audit you can run in PowerShell is more thorough. The Microsoft Teams PowerShell module exposes the meeting policy and external access cmdlets directly, and a single script can dump the current state of every setting across every policy in the tenant. If the audit is going to be recurring, the script is the version you keep.
What to do on Monday
The 181,874 figure is a snapshot, and snapshots go stale. The shape of the attack does not. The calendar is the new email attachment, the meeting join link is the new credential prompt, and the lobby is the only control that fits between the two.
If you inherit a tenant that has never had this audit run, expect the defaults to be the defaults: anonymous join on, lobby bypass permissive, external access "allow all". The four-step lockdown will change all four, and a small number of "we cannot do that, we meet with [external party] all day" objections will surface. The answer to each is the same: scope the exception, do not relax the default. The defaults drift back, so make the audit recurring.
Pick one meeting policy in your tenant today. Open it. See who can bypass the lobby. If the answer is "anyone in any allowed organisation," that is your Monday job.
Forward this to whoever runs your tenant. A two-hour configuration pass is cheaper than a compromised account in the next quarter's incident review.
Mathew Clark Founder, SecureInSeconds Currently: working through the external access allowed-domains list with a Cremorne agency and finding three domains on it that should not be.
Frequently asked
How do I tell if a meeting invite is from a real external party?
Look at the organiser line in the invite details, not the calendar entry title. The organiser is an email address, and the domain is the thing to check. If the domain is one you do not recognise, verify with the named person out of band before accepting. The look-alike domain is the trick, and the verification step is the only thing that catches it.
Does this only apply to Teams, or to Outlook calendar meetings too?
Both. The Outlook calendar is the front door for a Teams meeting invite, and the controls above cover the meeting itself. The Outlook-side controls (external calendar sharing, automatic calendar processing, auto-decline policies) are separate, and the lockdown is incomplete if only one side is configured.
What about "Allow forwarding" on a meeting invite?
Forwarding is how a single compromised user becomes a way to reach the rest of the org, and the 181,874 figure includes invites that were forwarded. In the meeting policy, the "Allow meeting chat" and "Allow transcription" toggles are the levers to check. Both should be off for external meetings by default.
Is this only an ANZ SMB problem?
No. The defaults are the defaults in any M365 tenant that has not been hardened, and the failure mode is the same in a 20-seat tenant and a 20,000-seat tenant. The 181,874 figure is not from an ANZ-specific dataset, and the configuration playbook is the same in either case. The ANZ-specific consideration is the Notifiable Data Breaches scheme: if a vishing-driven compromise leads to personal information being accessed without authorisation, the assessment clock starts under that scheme.
What is the single highest-value change I can make today?
Set "Who can bypass the lobby" to "People in my org only" at the global default. It is one toggle, one minute, and it changes the failure mode of every external meeting in the tenant from "the attacker walks straight in" to "the attacker has to ask, and the user has to actively admit them." The active admission is the moment the attack usually falls apart.
How often should this audit run?
Quarterly for a small tenant, monthly for a mid-size, and as a continuous process in larger estates where the meeting policy count is in the dozens. The first run is the longest because you are also building the runbook. Each subsequent run gets faster.
Further reading
- TLDV: Too Lazy, Didn't Validate - 181,874 meetings left unvalidated (r/netsec) - the r/netsec post this post is built around
- tl;dv - the meeting-recording tool behind the TLDV dataset - the platform whose dataset the r/netsec post cites
- Microsoft: Manage external access in Microsoft Teams - the platform's own guide to the org-level external access toggles
- Microsoft: Meeting policies in Teams - the platform's own reference for the meeting policy settings
- Microsoft: Safe Links in Microsoft Defender for Office 365 - the time-of-click URL scanning service for Teams messages
- ACSC: Essential Eight maturity model - the Australian framework the meeting controls map into
- CIS Controls v8.1: 09 Email and Web Browser Protections - the international framework the calendar-spam and phishing controls map into
- SecureInSeconds: Swiss government lost 200 accounts in a SharePoint breach - the same week, the same M365-defaults shape on a different surface
- SecureInSeconds: Metabase SQLi zero-day: the five-minute check for self-hosted BI - the same week, the same default-on-IT-feature pattern on a different vendor
The defaults are the defaults, and the defaults are permissive. The fix is configuration, not budget. Forward this to whoever runs your tenant before the next 181,874 starts accumulating.
