Home / The Long Con

The Long Con

A complete attack narrative. Every tool. Every decision. Every consequence.

Educational Fiction

This is a fictional narrative demonstrating how real attacks unfold. The target company, individuals, and events are entirely fictional. The techniques, however, are real and documented in security research. This exists to teach defenders how attackers think. Understanding the adversary is the first step to stopping them.

Prologue: The Contract

22:47 UTC - Encrypted Channel

The message arrives through three layers of proxies. A Tor hidden service to a dead drop, relayed through a compromised VPS in Moldova, finally landing in my encrypted inbox.

Another job. Another company that thought firewalls were enough. They never learn.

The brief is clean: Meridian Health Systems. A mid-sized healthcare provider operating twelve hospitals across the American Midwest. 15,000 employees. 2.3 million patient records. The client wants everything—patient data, financial records, research data from their clinical trials. They're paying 400 Bitcoin. Half now, half on delivery.

The money doesn't interest me. Not really. It's the puzzle. The architecture of trust that companies build and the hairline fractures that let people like me slip through.

Operator's Note: Healthcare targets are high-value for multiple reasons: regulatory pressure (HIPAA) makes them likely to pay ransoms, patient data has long shelf-life for fraud, and research data can be sold to competitors or nation-states. The threat actor ecosystem includes both financially-motivated criminals and state-sponsored groups.

I accept the contract. The clock starts now.

Phase I: Reconnaissance

Weeks 1-3 | Chapter: Initial Access

1

Passive Intelligence Gathering

The patient hunter studies prey before striking

I don't touch their network. Not yet. For the first week, I'm a ghost watching from a distance, piecing together the puzzle from publicly available information.

Most operators rush this phase. They want the thrill of the shell, the dopamine hit of that first beacon checking in. Amateurs. The reconnaissance phase isn't foreplay—it's the entire game. Every hour spent here saves ten hours of fumbling in the dark later.

LinkedIn Harvesting

I create three fake LinkedIn profiles over three days. Sarah Chen, IT recruiter from Austin. Michael Torres, healthcare IT consultant. Jennifer Walsh, medical device sales rep. Each profile is aged for months with connections from purchased accounts and legitimate-looking activity.

Through them, I map Meridian's IT department:

  • David Park - Senior Network Administrator. Posts about Cisco certifications. His profile mentions "managing 340+ network devices across 12 locations."
  • Amanda Foster - Security Analyst. Recent posts complaining about "alert fatigue." Uses Splunk based on her endorsements.
  • Robert "Bobby" Chen - Help Desk Manager. Active in local gaming Discord. His posts reveal they use ServiceNow for tickets and Microsoft 365 for email.
  • Lisa Yamamoto - CISO. 8 months in role. Previous company had a breach. She's under pressure.
OSINT Technique: LinkedIn is a goldmine for organizational reconnaissance. Job postings reveal technology stacks. Employee posts reveal security posture and pain points. CrossLinked and linkedin2username automate employee enumeration. See Initial Access: Reconnaissance.

Technical Reconnaissance

DNS enumeration reveals their infrastructure:

# Subdomain enumeration - no direct contact with target
subfinder -d meridianhealth.com -silent | httpx -silent > subdomains.txt

# Results:
# mail.meridianhealth.com - Exchange Online (MX records confirm M365)
# vpn.meridianhealth.com - Cisco AnyConnect
# ehr.meridianhealth.com - Epic Systems (patient records)
# citrix.meridianhealth.com - Citrix Gateway
# servicedesk.meridianhealth.com - ServiceNow instance

Certificate transparency logs tell me even more. Using crt.sh, I find certificates issued for internal hostnames that leaked into CT logs:

# Certificate transparency reconnaissance
curl -s "https://crt.sh/?q=%25.meridianhealth.com&output=json" | jq -r '.[].name_value' | sort -u

# Interesting finds:
# dev-ehr.meridianhealth.com - Development EHR environment
# test-ad.meridianhealth.com - Test Active Directory
# jenkins.internal.meridianhealth.com - CI/CD leaked to CT logs
There it is. A development environment. Test Active Directory. Jenkins with an internal hostname in a public certificate. Someone in IT made a mistake months ago, and now I have a map of their internal network structure without sending a single packet to their infrastructure.

Social Engineering Research

Bobby Chen's gaming Discord is public. Three hours of scrolling reveals:

  • He complains about "password resets every 90 days" - they enforce rotation
  • Mentions "that one doctor who keeps clicking phishing tests" - they run simulations
  • Posts a screenshot of his home office - his work laptop visible, sticky note on monitor

The sticky note is too blurry to read, but I note the model: Dell Latitude 5520. Standard healthcare IT equipment. I'll know exactly what endpoint protection to expect.

2

Active Reconnaissance

First contact, carefully measured

Week two. Time to make contact—but surgically, from infrastructure that can never trace back to me.

Building Attack Infrastructure

I spin up infrastructure across three cloud providers, paid with tumbled cryptocurrency:

# Infrastructure setup - all categorized as legitimate business domains
# Redirector 1: DigitalOcean (NYC) - healthtechus.com (aged domain, 2 years)
# Redirector 2: Vultr (Chicago) - medaboratory.net (aged domain, 18 months)
# C2 Server: OVH (Montreal) - behind Cloudflare

# Domain fronting through legitimate CDN for C2 traffic
# Beacon traffic appears as requests to cdn.microsoft.com
Infrastructure Design: Professional operators separate infrastructure by function. Phishing domains → Redirectors → C2 servers. Each layer provides attribution protection and allows burning compromised components without losing the operation. See Chapter: Infrastructure.

My Command & Control setup uses Sliver with HTTPS beacons configured to blend with Microsoft 365 traffic patterns. The malleable profile mimics OneDrive sync traffic—something their security team sees thousands of times per day.

External Scanning

From a residential proxy network (real IPs from real homes), I conduct light scanning:

# Slow, distributed scanning through residential proxies
# Rate: 1 request per 30 seconds per target
# Source: 50 different residential IPs

# VPN endpoint analysis
nmap -sV -p 443 vpn.meridianhealth.com --script ssl-enum-ciphers

# Results:
# Cisco AnyConnect version 4.10.x
# TLS 1.2 with strong ciphers
# Certificate valid until 2025

# Citrix Gateway
nmap -sV -p 443 citrix.meridianhealth.com --script http-headers

# Results:
# Citrix Gateway 13.1
# No MFA detected on initial probe (concerning for them)
Citrix without visible MFA. Could be configured internally, but that's a potential entry point. I file it away. The VPN is locked down tight—not worth the risk of triggering alerts with brute force attempts. Patience.

Email Infrastructure Analysis

Microsoft 365 means I need to understand their email security:

# Check for DMARC policy
dig txt _dmarc.meridianhealth.com

# Result: v=DMARC1; p=quarantine; rua=mailto:dmarc@meridianhealth.com

# Quarantine policy, not reject. Spoofed emails might land in spam,
# but they won't be blocked outright.

# Check for email security gateway
# Send test email from burner address, analyze headers
# Result: Proofpoint Email Protection detected
Email Security Assessment: Understanding the email security stack is critical for phishing success. Proofpoint will sandbox attachments and analyze URLs. DMARC in quarantine mode means spoofed emails may still reach users (just flagged). Plan accordingly.
3

Target Selection

Choosing the door, not just any door

Three weeks of reconnaissance. I have maps of their network, lists of their employees, understanding of their security tools. Now I choose my entry point.

Attack Vector Analysis

Vector Likelihood Risk Notes
Phishing - IT Staff Medium Medium Aware, but human error exists
Phishing - Clinical Staff High Low Less security-aware, urgent workflows
Citrix Exploitation Medium High Noisy, might trigger IR
Supply Chain High Medium Trusted vendors = trusted access

The decision crystallizes: supply chain compromise through a trusted vendor.

Direct phishing will work eventually, but I want something cleaner. If I compromise a vendor they already trust, I inherit that trust. Emails from a known sender. Files from a known source. The human brain is wired to accept information from trusted sources without scrutiny.

Vendor Reconnaissance

Press releases and job postings reveal Meridian's vendors:

  • MedEquip Solutions - Medical device maintenance (on-site technicians)
  • HealthTech Consulting - Epic EHR implementation partner
  • SecureIT Partners - Managed security services (ironic target)
  • Clarity Labs Integration - Lab systems integration, 15-person company

Clarity Labs Integration. Small company, probably limited security budget, direct system access for lab integrations. Perfect.

Two days of OSINT on Clarity Labs reveals their IT administrator: Marcus Webb. LinkedIn shows he's the only IT person. He manages everything—network, email, endpoints. Single point of failure.

Phase II: Initial Access

Week 4 | Chapter: Initial Access | Chapter: Payloads

4

Compromising the Vendor

The first domino falls

Marcus Webb has a personal email visible on his GitHub profile: mwebb.dev@gmail.com. His GitHub shows contributions to a lab integration project. The commit messages mention "Meridian deployment."

I craft a spearphish tailored to Marcus:

The Long Con continues in the full narrative...