Playbook: How a Two-Location Dental Practice Should Respond to a Lookalike-Domain Phishing Attempt

This is a playbook for a scenario we structure engagements around regularly across the Inland Empire. The practice described is a composite — no specific client. The mechanics, controls, and remediation steps are the real engagement structure we use.

Picture a two-location dental practice headquartered in Riverside — three dentists, two hygienists per location, three front-desk staff, one practice manager who works across both sites.

The stack: a cloud practice-management platform with a local imaging server at each location for sensor and pano data, M365 for email and file storage, and digital sensors and pano machines that talk to the imaging server over the office LAN. Patient volume is roughly 240 procedures a week across both locations. PHI is everywhere — patient charts, treatment plans, insurance claims, imaging files, payment-on-file records.

The triggering scenario: a Wednesday morning at 8:30 AM. The front-desk lead at Location A receives what looks like an insurance-clearinghouse email asking her to log into a portal to verify a flagged claim. She clicks the link.

The page looks correct — same logo, same color scheme. She enters her practice-management platform username and starts entering her password before stopping mid-type because the URL bar shows a domain that is one character off from the real one. She closes the tab, tells the practice manager, the practice manager calls us.

The payload did not run on her workstation. The credential was not fully entered. But everyone knows the answer that day could have been different.

A post-incident audit in the two days following a near-miss usually paints a familiar mixed picture — the practice has done some things right, and a lot of things by luck.

M365 is often on Business Premium because a previous IT vendor upsold the license at signup years earlier. The license includes Defender for Office 365 and Conditional Access — but most of the configuration is at default.

Safe Links is typically on, which is usually what stops the payload from delivering. Anti-phishing impersonation rules are on but the lookalike-domain list does not include the practice's actual high-risk lookalikes (insurance clearinghouses, dental supply vendors, the practice-management platform vendor).

MFA is on for the practice manager and the dentists, off for the front-desk staff and the hygienists. The reasoning is always that front-desk staff log in and out throughout the day to switch between patients, and MFA "slows them down."

The practice-management platform has its own login system separate from M365. MFA is available on the platform but not enabled. Several staff members share a single common practice-management password "for emergencies" — and a copy of that password is often taped to the inside of a desk drawer at the front desk.

The imaging server at one or both locations is a Windows machine running an out-of-support version of Windows Server. The previous IT vendor told them "don't update, it might break the imaging software." RDP is open from the office LAN to the imaging server with no MFA. The server has not been patched in many months.

Backups of the imaging servers and the file shares run nightly to an external USB drive that the practice manager swaps out weekly. The off-site copy is the previous week's drive sitting in the practice manager's car.

BAAs (Business Associate Agreements) on file: the practice-management platform, yes. M365, yes. The imaging-server vendor, no. The previous IT vendor, no — they refused to sign one. The cloud backup product the practice considered using but never bought, n/a.

An audit at a practice like this will typically surface six findings that matter, plus one good thing worth documenting deliberately:

• The good thing: Safe Links being on is the only reason the payload did not deliver. The front-desk lead's instinct to stop mid-password was the second line of defense. Both of these need to be repeatable — not luck.
• MFA off on the front-desk and hygienist accounts means the practice-management platform is one credential away from full PHI access. A lookalike-domain phishing email has roughly a 40% chance of succeeding against any of those accounts without MFA. The next attempt — and there will be a next attempt — needs to fail at the credential prompt, not at the user's instinct.
• A shared practice-management platform password taped to a drawer is the worst-case scenario for HIPAA (45 CFR § 164.312) access control. The minimum-necessary standard cannot be satisfied when several people use one account, and the access controls cannot be audited because the platform's log shows one user.
• An out-of-support imaging server is an active compliance and operational risk. Out-of-support Windows means no security patches, which means a single SMB or RDP exploit is enough. RDP open on the office LAN with no MFA compounds the risk. "Don't update, it might break" is not a security posture — it is a deferred outage.
• Lookalike-domain detection rules typically do not include the practice's actual high-risk lookalikes. Default anti-phishing impersonation protection covers some big public brands but not industry-specific vendors. A custom lookalike list for dental practices needs to include the insurance clearinghouse, the practice-management platform vendor, the dental supply vendor, and any other vendor that regularly sends emails the front desk will trust on sight.
• The backup story is single-point-of-failure on a USB drive in the practice manager's car. If both the imaging server and the in-car drive are compromised on the same week (theft, ransomware, fire, accident), the data is gone. There is no immutable off-network copy.
• Missing BAAs are HIPAA violations on their own. Any imaging-server vendor and any previous IT vendor with access to PHI need BAAs. Neither having one is common — and is its own finding before any incident.

The near-miss is the gift. Every practice gets one. The question is whether the gift comes with a working email gateway behind it — or whether the gift becomes the breach.

The remediation runs as a four-week sprint with the practice manager and the senior dentist signing off on patient-impacting changes.

1. Enable MFA on every account on every platform that touches PHI. Practice-management platform, M365, the cloud backup product onboarded as part of the engagement, the dental insurance clearinghouse portal, the e-prescription system, the patient communication tool. Front-desk training the same day on how the new login flow works. Average added time per login: about four seconds.

2. Kill the shared practice-management platform account and give every staff member an individual login. Pull the platform's audit log retroactively. Make sure each role has only the permissions it needs (front-desk does not need treatment-plan edit rights, hygienists do not need billing rights). Remove any password taped to a drawer.

3. Build a custom lookalike-domain detection list in the M365 anti-phishing policy. Add the insurance clearinghouse domain, the practice-management platform vendor domain, the dental supply vendor domain, the e-prescription vendor domain, and the dental insurance carrier domains the practice works with most. Any inbound email from a one-character-off domain lands in quarantine, not the inbox.

4. Harden the M365 tenant against the broader phishing pattern. Turn on Safe Attachments. Enable external-sender warnings on every email from outside the tenant. Tune the anti-phishing impersonation rules to high. Configure Conditional Access to require MFA on every M365 sign-in, block legacy authentication, and block sign-ins from countries the practice does not work in.

5. Replace the out-of-support imaging server. Migrate the imaging data to a supported Windows Server, joined to the M365 tenant via Entra ID Connect, with BitLocker enforced, EDR running, and RDP locked down to require an authenticated jump host with MFA. The imaging-software vendor is looped in on the migration — and signs a BAA as part of the project.

6. Build a real backup and recovery posture. Cloud-based immutable backup of the imaging servers and the M365 tenant (mailboxes, OneDrive, SharePoint). The USB-drive process is retired. Quarterly restore tests go on the practice manager's calendar — pick a random file from six months ago, restore it, verify the contents.

7. Write and sign BAAs with every vendor that has access to PHI. Imaging-server vendor, IT vendor, cloud backup vendor, patient-communication tool, e-prescription system. The BAA file is organized, dated, and stored in the practice's compliance binder with a renewal calendar.

When this playbook runs cleanly, here is what the practice exits with.

Lookalike-domain emails — and there will be more inbound — land in quarantine. The front-desk lead no longer has to be the last line of defense.

The practice-management platform's audit log can answer the question "who looked at this patient's record on this date." That question gets asked in HIPAA breach investigations. It is also worth being able to answer for legitimate clinical reasons.

The imaging server is on supported Windows, patched, encrypted, and behind a jump host. The vendor signed a BAA. RDP is no longer directly exposed.

Backups are immutable and off-network. A ransomware event that wipes the in-office systems no longer wipes the recovery path. A quarterly restore test typically produces a recovered file in roughly ten minutes.

The BAA file is current. Vendors that refuse to sign a BAA are no longer part of the stack.

The practice will eventually have another near-miss. The difference is what happens that day — whether the email reaches the inbox at all, and whether the credential prompt fails the attacker instead of the front desk.

Three things worth taking from this.

First — the near-miss is the gift. Every practice gets one of these. The question is whether the gift comes with a working email gateway behind it and a hardened tenant, or whether the gift becomes the breach. The practice above had Safe Links on by accident (the previous IT vendor had defaulted it on). That is the only reason they got to call us instead of calling their cyber insurance carrier.

Second — "don't update, it might break" is one of the most expensive sentences in dental IT. Out-of-support Windows in the operatory is a HIPAA violation looking for an audit. The fix is not heroic — it is a planned migration with the imaging-software vendor in the loop. Practices that do this on a normal Tuesday avoid doing it during a ransomware response.

Third — MFA on the front desk is non-negotiable. The argument that it slows things down dissolves the first time a phishing email succeeds at one of those accounts. Four seconds per login is not the cost. The cost is the morning a patient asks why their imaging is offline.

If you are running a dental practice in the Inland Empire and want a structured look at where you sit against HIPAA Security Rule (45 CFR § 164.312) requirements, our dental practice IT page covers the specifics for the vertical, the security baseline assessment walks through the audit, and the free 12-question self-check gives a rough grade in three minutes.