Investigation Walkthrough: Targeted Phishing Campaign

This investigation walkthrough follows a security analyst through a targeted phishing campaign against a 6,000-employee hospital network. The case demonstrates how a properly authenticated lookalike domain bypasses SPF, DKIM, and DMARC, why a few self-reported tickets are never the full picture of who clicked, and how the speed of incident response determines the blast radius once credentials are captured.

The Help Desk Ticket That Didn't Add Up

Corinne Yeh worked email security at Bellfield Health, a regional hospital network with 6,000 employees. Most of her days involved routine phishing reports: the usual fake package notifications, bogus password reset links, and Nigerian prince variations. She triaged, reported, and moved on.

Then three help desk tickets arrived within the same hour on a Wednesday morning.

Ticket 1 (8:47 AM): Dr. Nina Kaur, cardiologist. "I can't log into the benefits portal. I used the link in the email from HR and entered my credentials but it just spun and gave me an error. Can you reset my access?"

Ticket 2 (9:12 AM): James Whitfield, billing supervisor. "The HR email about open enrollment sent me to a weird page. I entered my info but now I'm worried. Is that email legit?"

Ticket 3 (9:31 AM): Rosa Vega, nurse practitioner. "I got an email about new benefits options. I clicked the link but nothing happened after I put in my password. Is the system down?"

Three employees. Three different departments. Same morning. All describing the same email and the same experience: click a link, enter credentials, get an error.

Corinne pulled up the email in question. Subject line: "ACTION REQUIRED: Open Enrollment Deadline Extended - Update Your Benefits by Friday." Sender: benefits@bellfield-health.org. Bellfield's actual domain was bellfieldhealth.org. One hyphen. One extra character.

She checked the domain registration. bellfield-health.org had been registered 48 hours earlier through a privacy-protected registrar. The registrant had configured SPF, DKIM, and DMARC for the domain. The phishing email passed every authentication check perfectly.

This wasn't a spray-and-pray phishing blast. Someone had done their homework.

This story is fictional, but the patterns are real.

The Email

Corinne exported the email as an .eml file (preserving full headers) and began her analysis.

What the Employees Saw

The email was well-crafted. Internal-looking formatting. Bellfield's logo. A reasonable pretext (open enrollment is something every employee deals with). The call to action was urgent but not panicked: a Friday deadline to update benefits selections.

The link text displayed bellfieldhealth.org/benefits but the actual URL pointed to bellfield-health.org/enrollment/update. On a phone screen or a quick glance, the difference between bellfieldhealth.org and bellfield-health.org was nearly invisible.

What the Headers Revealed

Corinne read the headers bottom to top, starting from the originating server.

The anchor point (the Received header added by Bellfield's own mail server) showed the email arrived from an IP address that resolved to a hosting provider in Amsterdam. The phishing domain's mail server.

Authentication results from Bellfield's mail gateway:

• SPF: pass (the sending IP was authorized for bellfield-health.org)
• DKIM: pass (the email was signed with a valid DKIM key for bellfield-health.org)
• DMARC: pass (at least one of SPF or DKIM aligned with the From domain)

All three checks passed. Because the attacker owned the lookalike domain and had configured its email authentication correctly, the email was technically legitimate mail from bellfield-health.org. The authentication system confirmed the domain was real. It couldn't tell Corinne that the domain was malicious.

The Landing Page

Corinne opened the phishing URL in a sandboxed browser. The page was a convincing replica of Bellfield's actual single sign-on (SSO) portal. Same color scheme. Same logo. The URL bar showed bellfield-health.org, which looked close enough to legitimate unless you knew to check for the hyphen.

The page had a login form. Username, password, and a "Remember this device" checkbox. After entering credentials, the page displayed a brief loading animation, then showed an "Error: System maintenance in progress. Please try again later" message.

That error message was the cover story. The credentials had already been captured and sent to the attacker. The "try again later" message explained away the failure so victims wouldn't immediately suspect phishing. They'd just think the system was down and move on with their day.

Scoping the Attack

How Many People Received the Email?

Corinne queried Bellfield's email gateway logs for all inbound messages from the bellfield-health.org domain in the past 72 hours. The results:

847 employees had been targeted. The email was sent in a single batch, but the recipient list wasn't random. Every target was a current Bellfield employee. The attacker had a staff directory.

How Many People Clicked?

Bellfield's email security tool tracked URL clicks. Corinne pulled the click-through data:

194 employees had clicked the phishing link. How many had actually entered their credentials was unknown. The phishing page was hosted on the attacker's infrastructure, so Bellfield had no server logs from it.

Corinne had to assume the worst: anyone who clicked might have entered credentials.

How Did They Get the Staff Directory?

This question gnawed at Corinne. The attacker had sent emails to 847 current employees, not former employees, not generic addresses, not guessed formats. Someone had a recent employee list. The same kind of reconnaissance is documented in the criminal infrastructure ecosystem that produces target lists, lookalike domains, and hosting on demand.

She investigated three possibilities:

LinkedIn scraping. Bellfield had an active LinkedIn presence. Many employees listed their employer publicly. A scraper could compile names and generate email addresses using the standard format (firstname.lastname@bellfieldhealth.org).

Website staff directories. Bellfield's website listed physician names and bios. The "Find a Doctor" tool included email addresses for patient communication.

Previous breach data. A search of breach databases showed that Bellfield employee email addresses appeared in a third-party vendor breach from the previous year. That vendor had Bellfield's HR contact list for benefits administration.

The most likely source was a combination: LinkedIn for breadth, the vendor breach for accuracy.

Incident Response

The First 24 Hours

Corinne's response followed Bellfield's incident response playbook:

Hour 1: Block the domain.

• Added bellfield-health.org to the email gateway's block list
• Added the domain to the web proxy's block list (preventing any employee from reaching the phishing page)
• Submitted the domain to Google Safe Browsing and Microsoft SmartScreen for wider blocking

Hour 2: Identify at-risk accounts.

• Exported the list of 194 employees who clicked the link
• Cross-referenced with Active Directory to identify their roles and access levels
• Flagged any employees with privileged access (IT admins, financial system access, executive assistants)

Hour 3: Force credential resets.

• All 194 clicker accounts had passwords reset and active sessions terminated
• All 194 received a direct phone call (not email) explaining the situation and walking them through creating a new password

Hour 4: Check for compromise.

• Reviewed authentication logs for all 194 accounts for any logins from unusual IPs or devices after the phishing email was sent
• Checked for email forwarding rules added to any of the 194 accounts
• Reviewed access to sensitive systems (EHR, financial, HR) for anomalies

The compromise check found something.

The Attacker Had Already Moved

Two of the 194 accounts showed suspicious activity. Both belonged to employees who had clicked the phishing link within the first hour of the campaign.

Account 1: James Whitfield (billing supervisor)

• Phishing email clicked at 8:34 AM
• Unauthorized login from a VPN exit node at 9:15 AM (41 minutes after click)
• Email forwarding rule added, copying all inbound email to an external address
• No further action taken (James submitted his help desk ticket at 9:12 AM, and Corinne's response interrupted the attacker)

Account 2: Dr. Linda Moran (chief medical officer)

• Phishing email clicked at 8:51 AM
• Unauthorized login from the same VPN provider at 10:07 AM
• Attacker accessed the CMO's email, read three threads about an upcoming hospital acquisition, and forwarded them to an external address
• Attacker attempted to access the hospital's financial planning SharePoint but was blocked by an MFA prompt for the second factor

The attacker had harvested credentials and immediately used them. The 41-minute gap between James's click and the unauthorized login suggested the operation was partially automated: credentials were captured, validated, and accessed programmatically.

Dr. Moran's account was the real target. The attacker had gone straight for the acquisition-related emails. This wasn't random credential harvesting. It was targeted intelligence gathering with a specific objective.

The Bigger Picture

Corinne stepped back and mapped the attack as a timeline:

The gap between the first employee click (8:02 AM) and Corinne's investigation start (10:30 AM) was nearly two and a half hours. During that window, the attacker had accessed at least two accounts and exfiltrated sensitive information about a hospital acquisition.

Decision Points Where Things Could Have Gone Wrong

If Corinne Had Ignored the Pattern

Three tickets in an hour about the same email. If Corinne had treated them as routine password reset requests, the phishing campaign would have continued unchecked. The attacker would have had more time to exploit compromised accounts.

The lesson: volume matters. One report of a suspicious email is routine. Three reports of the same email in an hour is an incident.

If Bellfield Had Only Reset the Three Reporters

Only three of the 194 clickers self-reported. If Corinne had only reset those three accounts, 191 potentially compromised accounts (including Dr. Moran's) would have remained accessible to the attacker.

The lesson: the people who report are the tip of the iceberg. Most phishing victims don't know they've been phished. The same gap shapes how account-takeover detection is built. Defenders cannot wait for self-reports.

If MFA Hadn't Been Enabled on SharePoint

The attacker accessed Dr. Moran's email (single-factor: just a password) but was blocked from accessing the financial SharePoint (which required a second factor). Without MFA on that sensitive system, the attacker would have had direct access to acquisition documents, financial projections, and board communications.

The lesson: MFA on sensitive systems is the last line of defense when credentials are compromised. It can't prevent the initial compromise, but it limits the blast radius.

Key Takeaways

• Lookalike domains bypass email authentication. SPF, DKIM, and DMARC verify that an email came from the domain it claims. They can't tell you that bellfield-health.org is not the same as bellfieldhealth.org. Domain monitoring and employee awareness are the defenses here.
• Phishing campaigns have short exploitation windows. The attacker used stolen credentials within 41 minutes. Incident response speed directly determines how much damage occurs. Every hour of delay is an hour the attacker has inside your network.
• Most victims don't self-report. Three out of 194 clickers raised an alarm. The other 191 either didn't realize they'd been phished or were too embarrassed to report it. Build processes that detect compromised accounts without relying on user reports.
• Targeted phishing has a specific objective. This wasn't random credential harvesting. The attacker went straight for the CMO's acquisition emails. Understanding the attacker's goal helps you prioritize which accounts to investigate first.
• MFA limits blast radius. When credentials are compromised (and they will be), MFA on sensitive systems prevents the attacker from escalating a stolen password into a full network compromise.

What's next: Review Email Authentication for a deeper understanding of how SPF, DKIM, and DMARC work and why they can't catch lookalike domain attacks. For a parallel walkthrough that traces the post-login phase of an account takeover from a different starting point, see The Breach That Kept Giving, and for the pretext mechanics that made the open-enrollment lure work, see Social Engineering Basics.

Key Terms