Technical analysis of the campaign

What we have established from message evidence and a victim-side incident, what we infer, and what we still need. Written for the IT providers and security people who look after dental practices. The plain-language advisory is at the main page; this page assumes technical background. Corrections and additional intelligence are welcome via the form below.

1Attack chain

ACCESSCompromise of a dental practice mailbox (both consumer Gmail and custom-domain business mailboxes observed)

DISTRIBUTIONShare-lure email sent from the genuine account to its correspondents, BCC to undisclosed recipients

DELIVERYFreshly registered .vu domain, short generic path, cloaked against scanners

EXECUTIONWindows payload; fake full-screen "Windows Update" overlay during install

OPERATIONInteractive hands-on-keyboard remote access; repeat visits weeks apart

PROPAGATIONVictim's address book becomes the next distribution list

Simulated fake Windows Update screen: black background, white text reading Working on updates 37% complete, Don't turn off your computer — Fig. T1 — Reconstruction of the fake "Windows Update" overlay reported during payload installation (black screen, white "Working on updates / Don't turn off your computer" text with a spinner). Simulated for awareness; the operator retains interactive control of the desktop behind it. Not a forensic capture.

The propagation model is what makes this campaign effective in a niche sector: every message arrives from a genuine, previously-corresponding address, so SPF, DKIM and DMARC all pass and reputation-based filtering is useless. Targeting requires no attacker knowledge of the industry — the compromised mailbox's own contact graph is the targeting.

2Message evidence

We hold original .eml files from three waves (12, 16 and 22 July 2026) plus a first-wave sample. Key observations from headers and bodies:

Authentication and origin

All observed messages fully pass SPF, DKIM and DMARC for their sending domain. The 22 July sample sent from a compromised consumer Gmail account carries a valid d=gmail.com DKIM signature and a Message-ID of the form <…@mail.gmail.com> — i.e. sent through a genuine authenticated Gmail session, not spoofed and not via third-party SMTP. This is account takeover, not header forgery.
Compromised senders include both consumer Gmail addresses and custom-domain business mailboxes; the business-domain sample also transited Google infrastructure (Workspace-hosted).
Recipients are always concealed: To: undisclosed-recipients:; with the actual recipient in Bcc.
Send times cluster outside AEST business hours; two samples landed 03:41 and 06:32 local. Consistent with a UTC+0…+3-ish operator working their daytime, though not probative.

Lure construction

HTML body imitates a Microsoft OneDrive/SharePoint share card: share icon, "[Practice] shared a file with you" heading, a named ".DOCX" file row, an "Open Document" button, Microsoft logo (embedded inline as base64 cid: images) and a "Privacy Statement" link.
The .docx file-type icon in one sample is hot-linked from Wikimedia Commons — a small but recurring fingerprint.
The instruction "For security reasons, please view this document using your Desktop or Windows Laptop" appears consistently — the payload is Windows-only and the operators are filtering out mobile clicks.
One sample uses two distinct fresh domains in a single message (payload link vs. decoy "privacy statement" link), suggesting templated kit generation rather than hand-built mails.
The compromised account's genuine signature block (address, phone) is retained beneath the lure — the operators send from the real mailbox UI or preserve its formatting deliberately.

3Infrastructure

DOMAIN (defanged)	PATH	FIRST SEEN	SENDER TYPE
avernix[.]vu	/access	early wave	consumer Gmail
uvanv[.]vu	—	early wave	—
xornavo[.]vu	/file	12 Jul 2026	business mailbox (custom domain)
lornica[.]vu	/dental	16 Jul 2026	business mailbox (custom domain)
clientesetupdoc[.]vu	/access	22 Jul 2026	consumer Gmail (decoy link in same mail)
docsecdental[.]vu	/mesh	22 Jul 2026	consumer Gmail (payload link)

TLD choice: all observed domains use .vu (Vanuatu ccTLD). WHOIS/passive-DNS visibility for .vu is poor, which may be part of the appeal alongside cheap registration. Domain names are pronounceable invented words or vaguely thematic compounds ("docsecdental", "clientesetupdoc"); one fresh registration per wave, discarded after.
Cloaking: a urlscan.io submission of one live link returned a Wikipedia article as the rendered page — the kit fingerprints scanners/sandboxes and serves a decoy. Treat any "clean" verdict from automated URL scanning as meaningless for this infrastructure. We do not yet know the fingerprinting method (IP reputation, headless detection, UA, or one-time-token links).
Payload: unrecovered. The one confirmed-infected machine displayed a full-screen fake Windows Update during installation and later showed live cursor control; it was reimaged before forensic capture (lesson learned — see section 5's asks). RAT family, persistence mechanism, and C2 are therefore unknown to us.

4Detection

Because domains rotate per wave, our open-source detector (browser extension, GitHub) scores message content rather than matching indicators alone. Signals, roughly in order of evasion-resistance:

Share-lure phrasing with a link whose registrable domain is not a recognised file-sharing host (works on any TLD);
The desktop/Windows-laptop instruction (operationally necessary to them — dropping it costs them victims);
Brand mismatch: Microsoft/OneDrive branding with non-Microsoft link targets;
High-risk TLD plus short generic path;
Known-domain blocklist (zero-FP repeat detection only).

Server-side, the highest-leverage controls are a transport rule quarantining .vu/ links (we know of no legitimate .vu correspondence in Australian dentistry), an external-sender share-lure disclaimer rule, and resolver-level blocking of the .vu zone at practice routers. Copy-paste configurations for Microsoft 365 and Google Workspace are in the IT configuration guide.

For responders: on any suspected mailbox compromise, audit inbox rules before resetting anything else's passwords — observed BEC tradecraft generally, and hidden forward/move rules specifically, are how operators retain access and conceal replies after a password change fails to evict an authenticated session. Reset password, revoke sessions and app passwords, then check OAuth grants.

5Open questions — what we need from you

Initial access method. Unconfirmed whether mailbox credentials come from the RAT (browser credential theft on infected machines), from a credential-phishing stage on the same links, or elsewhere. If you've responded to one of these and know, we want to hear it.
Payload. No sample, hash, family identification or C2 indicators. If you image an infected machine before wiping, or hold EDR telemetry from one, that is the single most valuable contribution possible.
Cloaking mechanism. Anyone able to capture the real payload flow (residential IP, real browser) alongside the decoy response could characterise the gate.
Scale. Our numbers are only what's reported to us. Mail-flow logs showing outbound bursts from a compromised practice would size a wave properly.
Earlier activity. Whether this crew targeted other Australian healthcare verticals before dentistry.

Original .eml samples (with headers) are available to legitimate researchers and responders on request via the form below. Please also report independently to the ACSC — our evidence is already lodged.

6Contact, ideas and intelligence

Ideas for the tooling, corrections to this analysis, intelligence to share, or anything else — this opens a pre-filled email in your own mail client, so you can attach files (.eml samples, hashes, logs) before sending. Reports of sightings should use the main reporting form instead.