IT Setup Guide — stopping the phishing campaigns targeting dental practices

Copy-paste recipes for practice IT providers. Each layer is independent — do as many as apply. Layers 1–3 protect every device including the Outlook desktop app and phones; no browser extension needed. Covers both documented campaigns: the .vu folder-share malware lure and the PRODA/HPOS credential phish impersonating Services Australia.

Coverage map — what protects what

LayerProtectsEffort
1. Mail server rule (M365 / Google Workspace)Every device and mail client, all staff — email is tagged/quarantined before delivery15 min, admin access
2. DNS filtering at the routerEvery device on the practice network, every browser and app — the malicious site simply won't load15 min, router access
3. Account & endpoint hardening (2FA, non-admin, app control)Makes a click survivable and stops mailbox takeoveran afternoon
4. Browser extension (Chrome / Edge / Firefox)Visible red warning inside Gmail / Outlook web2 min per PC
5. Poster + staff trainingEvery human, including desktop-Outlook and phone readers no software reaches15-min team meeting

1a. Microsoft 365 — mail flow rules (covers desktop Outlook)

For practices on Microsoft 365 / Exchange Online — i.e. most practices using the Outlook desktop app. Needs a tenant admin.

Admin center (point-and-click)

  1. Go to admin.exchange.microsoft.com → Mail flow → Rules → Add a rule → Create a new rule.
  2. Rule 1 — quarantine known-bad links: Apply if "The subject or body → subject or body matches these text patterns" → add: \.vu\/ — Do the following: "Redirect the message to → hosted quarantine". Severity: High.
    Use "matches these text patterns", not "includes any of these words". The includes-words predicate matches whole delimiter-separated tokens, so a body containing https://docsecdental.vu/mesh becomes the tokens https, docsecdental, vu, mesh — a rule looking for .vu/ never fires, silently. The pattern form is a regular expression and works.
  3. Rule 2 — warn on share-lure wording from outside: Apply if "The sender → is external/internal → Outside the organization" AND "subject or body includes": shared a file with you, shared a folder with you, shared a file for you — Do the following: "Apply a disclaimer → prepend" with the HTML below. This tags the email with a red warning banner that shows in EVERY client, including desktop Outlook and phones.
<div style="background:#fdecea;border:3px solid #b71c1c;padding:12px;font-family:Arial;font-size:14px">
<b style="color:#b71c1c;font-size:16px">⚠️ CAUTION — "shared file" email from outside the practice</b><br>
A phishing campaign is hitting Australian dental clinics with fake "shared a file" emails sent
from hacked colleagues' real accounts. Before opening any link: PHONE the sender and confirm
they sent it. Never open share links "on your desktop" because the email says to.
</div>

PowerShell (equivalent, for IT providers)

Connect-ExchangeOnline

New-TransportRule -Name "PhishWatch 1 - quarantine .vu links" `
  -SubjectOrBodyMatchesPatterns '\.vu\/' `
  -Quarantine $true -SetAuditSeverity High

New-TransportRule -Name "PhishWatch 2 - external share-lure warning" `
  -FromScope NotInOrganization `
  -SubjectOrBodyContainsWords "shared a file with you","shared a folder with you","shared a file for you" `
  -ApplyHtmlDisclaimerLocation Prepend `
  -ApplyHtmlDisclaimerText '<div style="background:#fdecea;border:3px solid #b71c1c;padding:12px;font-family:Arial;font-size:14px"><b style="color:#b71c1c;font-size:16px">⚠️ CAUTION — "shared file" email from outside the practice</b><br>A phishing campaign is hitting Australian dental clinics with fake "shared a file" emails sent from hacked colleagues' real accounts. Before opening any link: PHONE the sender and confirm they sent it.</div>' `
  -ApplyHtmlDisclaimerFallbackAction Wrap

Rule 3 — government-impersonation (PRODA / HPOS / myGov) credential phishing

The August 2026 campaign impersonates Services Australia and asks staff to "re-link" PRODA. Genuine Services Australia links always terminate at .gov.au, so an external message using PRODA/HPOS account-action wording is always worth tagging. Note the current infrastructure (verifications[.]es) is a plain .es domain, so a TLD blocklist alone will not catch it.

Connect-ExchangeOnline

# Tag external mail that talks about PRODA/HPOS/myGov account actions
New-TransportRule -Name "PhishWatch 3 - gov impersonation warning" `
  -FromScope NotInOrganization `
  -SubjectOrBodyMatchesPatterns 'PRODA','HPOS','myGov','Provider Digital Access' `
  -ApplyHtmlDisclaimerLocation Prepend `
  -ApplyHtmlDisclaimerText '<div style="background:#fdecea;border:3px solid #b71c1c;padding:12px;font-family:Arial;font-size:14px"><b style="color:#b71c1c;font-size:16px">⚠️ CAUTION — mentions PRODA / HPOS / myGov</b><br>Scam emails impersonating Services Australia are circulating. NEVER sign in to PRODA via a link in an email — type the address yourself or use your bookmark. A genuine Services Australia link always ends in .gov.au.</div>' `
  -ApplyHtmlDisclaimerFallbackAction Wrap

# Quarantine known PRODA-phish infrastructure
New-TransportRule -Name "PhishWatch 4 - quarantine known phish hosts" `
  -SubjectOrBodyMatchesPatterns 'verifications\.es','ghaspert\.com','machsselbst\.com' `
  -Quarantine $true -SetAuditSeverity High

# Block the attacker sending domains outright
New-TransportRule -Name "PhishWatch 5 - block known phish senders" `
  -SenderDomainIs "ghaspert.com","machsselbst.com" `
  -Quarantine $true -SetAuditSeverity High
Do not blanket-block .es the way you can with .vu — it is a normal European TLD with legitimate business use. Tag on wording, quarantine on the specific known hosts, and rely on the .gov.au rule taught to staff.

Also worth enabling if licensed (Defender for Office 365): Safe Links with "apply real-time URL scanning". Update Rule 1 and Rule 4's word lists as new attack domains appear — the current list is maintained on the advisory indicator table.

1b. Google Workspace — content compliance

For practices whose email runs on Google Workspace (Gmail with your own domain). Needs super-admin.
  1. admin.google.com → Apps → Google Workspace → Gmail → Compliance.
  2. Under Content compliance → Configure. Affect: Inbound.
  3. Add expression: "Advanced content match" → Match type: Regexp match → \.vu\/ (a "Simple content match" on .vu/ is unreliable — punctuation is not matched literally) (add more as new patterns appear). For the PRODA campaign add a second rule matching verifications.es, ghaspert.com and machsselbst.com, and optionally a warning-tag rule on PRODA / HPOS from external senders.
  4. Action: Quarantine message (review quarantines in Admin console) — or "Modify message → Prepend custom subject" with [SUSPECTED PHISHING] if you prefer tagging over holding.
Plain @gmail.com practice accounts can't do server-side rules. For those: the browser extension + poster, plus the DNS layer below, and strongly consider moving practice email onto Workspace or M365 — server-side control is worth it.

2. DNS filtering at the router — protects every device, every browser, every app

Works no matter what email client or browser anyone uses: even if someone clicks, the malicious site fails to load on the practice network. One change on the router.

Option A — Quad9 (free, zero accounts)

Router admin page → DNS settings → set DNS servers to 9.9.9.9 and 149.112.112.112. Quad9 blocks domains on threat-intelligence lists automatically (including reported campaign domains once flagged — another reason to report sightings).

Option B — NextDNS (free tier, more control)

  1. Create a config at nextdns.io; point the router's DNS at the two addresses it gives you.
  2. In Denylist, add the campaign-B hosts individually: verifications.es, ghaspert.com, machsselbst.com. (Do not blanket-block .es — unlike .vu it is a normal European TLD with legitimate business use.)
  3. Also in Denylist, add vu — this blocks the entire .vu domain ending on your network. Legitimate business email from .vu sites is essentially nonexistent in Australian dentistry, so the collateral damage is nil, and every future wave on .vu is dead on arrival regardless of the specific domain.
  4. Add other risky endings as waves appear (icu, top, cyou…), and enable "Threat Intelligence Feeds" + "AI-Driven Threat Detection" in Security settings.

2b. Block the payload's command channel (added 17 Aug 2026)

The campaign-A payload is ScreenConnect (ConnectWise Control) installed as an unattended agent. It is legitimate signed software, so endpoint AV will not stop it — the network is where you catch it.
Do not treat the presence of ScreenConnect as proof of compromise. Verify the relay hostname and the 16-hex thumbprint in the service name against what the practice's legitimate provider uses before removing anything, and prefer network isolation over uninstalling while you confirm — uninstalling destroys the evidence and can strand a provider's legitimate access.

3. Account and endpoint hardening (makes a click survivable)

4. Browser extension (Chrome, Edge, Firefox)

Deployment is not coverage — verify it. From an outside address, send the practice a test message whose body contains a harmless https://example.vu/test URL, and a second one mentioning PRODA. Confirm the first is quarantined and the second arrives with the warning banner. If nothing happens, the predicate is wrong (see the warning under Rule 1). Re-test whenever the rules are edited.

5. Humans (the layer nothing can replace)

Print the DO NOT OPEN poster for the front desk, run the staff booklet as a 15-minute team meeting, and establish the one rule that defeats every future variant: unexpected share link → phone the sender before clicking.