Lesson 1.1: Greater Pittsburgh Orthopaedic Associates disclosed a 2025 breach, but was there also one in 2024?

Compliance Framework Mapping

Introduction

Welcome to Lesson 1.1: Greater Pittsburgh Orthopaedic Associates disclosed a 2025 breach, but was there also one in 2024? Over the next 45 minutes, we will explore how a single public disclosure can mask a longer, more damaging history of compromise, and what that means for your threat intelligence.

But first, let me tell you about Dr. Anya Sharma.

It's 3:15 PM on a Tuesday in October 2025. Dr. Anya Sharma, a senior orthopaedic surgeon at Greater Pittsburgh Orthopaedic Associates, is reviewing a patient's X-rays in her office. The smell of antiseptic lingers in the air, and the low hum of the clinic's air conditioning is the only sound. She clicks to pull up the patient's full medical history from the electronic health record system.

The screen flickers for a moment longer than usual. When the record loads, she notices something odd. The patient's listed allergies are wrong—completely different from the notes she made during their consultation last week. She assumes it's a data entry error by a junior staff member and makes a mental note to correct it later. She doesn't think much of the system's sluggishness; it's been a bit slow for weeks.

Two days later, the clinic's administrator calls an emergency meeting. A notification letter is being prepared for patients. The practice has discovered unauthorised access to its systems, and patient data was exposed. The breach, they say, was discovered in early 2025. As Dr. Sharma listens, a cold realisation settles in her stomach. The strange data anomalies, the system performance issues... they started over a year ago, in the autumn of 2024.

This is the story of a Data Breach. By the end of this lesson, you'll understand exactly why Dr. Sharma and her colleagues never stood a chance against a threat they didn't know existed, and more importantly, what could have saved them.

Content Section 1: The Story in the Silence: Analysing Breach Disclosures

A public breach disclosure is like an iceberg. The official statement is the visible tip—the date discovered, the number of records. But the real mass, the timeline of initial access and lateral movement, often remains hidden beneath the surface. Understanding this hidden timeline is the core of effective threat intelligence.

The Public Narrative vs. The Hidden Timeline

When Greater Pittsburgh Orthopaedic Associates publicly disclosed a breach in 2025, they provided a snapshot: unauthorised access, patient data involved, discovery in 2025. This is the legally required disclosure. But threat intelligence isn't about accepting the public story; it's about investigating the gaps.

The critical question isn't 'what happened in 2025?' It's 'what activity made the 2025 breach possible?' Attackers rarely achieve major data theft in a single session. They establish a foothold, explore the network, escalate privileges, and then exfiltrate. This dwell time—the period between initial compromise and detection—can be months or years.

For a medical practice, the implications are severe. A breach starting in 2024 means over a year of potential data exposure. It means every patient record accessed, every prescription reviewed, every diagnosis noted in that period could have been compromised. The 2025 disclosure date is merely the day the practice finally looked under the hood.

Why Organisations Disclose Late (or Partially)

There are reasons a 2024 breach might only be disclosed in 2025. Forensic investigations are complex. Determining the initial point of entry requires sifting through terabytes of log data, which may not have been retained. Legal counsel often advises disclosing only what you can definitively prove.

There's also the human factor. Early, subtle signs—like Dr. Sharma's slow system or data anomalies—are often explained away as IT glitches. Without a culture of security awareness, these weak signals are missed. The breach only becomes 'real' when the evidence is undeniable, like a ransom note or a database suddenly disappearing.

DORA Article 5 DORA Article 5 requires financial entities to have a strong ICT risk management framework. This includes continuous monitoring and detection capabilities to identify incidents early, directly challenging the long dwell time seen in this case.

ISO A.5.24 ISO 27001 A.5.24 mandates planning and preparation for incident management. A key part of preparation is ensuring log collection and retention is sufficient to investigate an incident's root cause and full timeline, not just its final stage.

Content Section 2: Connecting the Dots: The Anatomy of a Long-Running Breach

Understanding how breaches persist unseen reveals why they're so effective. Let me show you exactly how an attacker could have operated at Greater Pittsburgh Orthopaedic Associates from 2024 to 2025 without raising a major alarm.

The Attack Flow: A Slow Burn

Step 1: Initial Access (2024). This likely started with a phishing email to a clinic staff member. A single click on a malicious link or attachment gives the attacker a toehold on one workstation.

Step 2: Establishing Persistence. The attacker installs a lightweight backdoor or uses legitimate admin tools already on the system. They work slowly, often during business hours, to blend in with normal network traffic. They might only be active for minutes a day.

Step 3: Lateral Movement and Discovery. Over weeks, they map the network. They look for file servers, database servers (like the one holding patient records), and administrative systems. They steal credentials from the compromised workstation's memory or from cached sessions.

Living Off the Land

With valid login credentials, the attacker can use the practice's own IT tools. They might use Remote Desktop Protocol (RDP) to move between systems, or PowerShell scripts to search for data. These are normal tools for IT administrators, so their use doesn't trigger classic malware alerts.

The data exfiltration is also slow. Instead of downloading a massive database file in one go—which would spike network usage—they might compress and encrypt small batches of records and send them out periodically, disguised as outbound web traffic or hidden in DNS requests.

Why Traditional Defences Failed at GP Ortho

Notice what all of these methods have in common. They look for known bad things or dramatic anomalies. A slow, patient attacker using valid credentials behaves like a 'known good' thing, slipping straight through.

The clinic likely had security measures in place. Here’s why they weren't enough:

NIST DE.CM-8 NIST CSF DE.CM-8 requires monitoring for unauthorised personnel, connections, devices, and software. This control would have been defeated because the attacker used authorised credentials and legitimate software, highlighting the need for behavioural analytics, not just signature-based detection.

NIS2 Article 21 NIS2 Article 21 mandates incident handling. A key part of handling is early detection. The long dwell time indicates a failure in detection capabilities, which this article aims to address through stronger security requirements.

Content Section 3: Finding the Needle: Detection for the Patient Attacker

Dr. Sharma's computer knew something was wrong. The sluggish performance was a clue. The system just couldn't tell her. Detection in these cases isn't about blocking a virus; it's about spotting subtle behavioural contradictions.

Network-Level Indicators of Compromise (IoCs)

Look for connections that don't make sense. A workstation in the billing department making repeated connections to the database server holding patient X-rays is suspicious. Even with valid credentials, this is a potential 'needle'.

Monitor for data flows to unexpected external locations. Small, regular outbound transfers to a cloud storage provider not used by the business, or communications with internet addresses in countries where the organisation has no operations, are red flags.

The key is establishing a baseline of 'normal' network traffic for each system and user. Deviations from this baseline, even if the tools and credentials used are valid, become the primary detection signal.

Endpoint-Level Indicators

On individual computers, watch for the use of powerful system tools at unusual times. A receptionist's computer running PowerShell scripts at 2 AM is a major alert, even if the user account is legitimate.

Look for evidence of credential dumping. Tools like Mimikatz leave traces in system memory and event logs. Multiple failed login attempts followed by a success from a new location can indicate credential theft and reuse.

Identity and Access Management Signals

This is often the most telling layer. Monitor for impossible travel. A login from a user's desktop in Pittsburgh followed by a login from an overseas IP address 30 minutes later is physically impossible and a clear sign of compromised credentials.

Alert on privilege escalation. A user from the marketing team suddenly being added to the 'Domain Admins' or 'Server Administrators' group is a critical event that must be investigated immediately, regardless of who performed the action.

SOC2 CC7.1 SOC 2 CC7.1 requires detection and monitoring procedures to identify changes that introduce vulnerabilities. The behavioural monitoring for unusual tool use and privilege escalation described here is a direct implementation of this control to detect active intrusions, not just configuration changes.

GDPR Article 33 GDPR Article 33 requires breach notification within 72 hours of awareness. To be 'aware', you need detection. The indicators covered in this section are precisely the signals that should trigger an investigation, starting the clock for a compliant notification, potentially long before full data exfiltration is confirmed.

Content Section 4: From Intelligence to Evidence: Building Your Compliance Narrative

Compliance isn't about having a checkbox for 'firewall installed.' It's about proving you have a thoughtful process to manage risk. This lesson provides the raw material to build that proof.

Evidence Generation

This lesson provides documentation for multiple compliance frameworks:

For DORA Article 5 auditors... For DORA auditors, you can now demonstrate that your staff training includes analysis of breach dwell times and attacker methodologies, a key part of a mature ICT risk management framework.

For ISO A.5.24 auditors... For ISO 27001 assessors, you can evidence that your incident response planning considers extended timelines of compromise, ensuring your log retention and forensic analysis capabilities are aligned with real-world threat models.

For NIST RS.RP-1 auditors... For NIST CSF reviewers, you can show that your response plan execution is informed by an understanding of slow-burn attacks, meaning your first response actions include hunting for evidence of earlier compromise, not just containing the immediate discovery.

Audit Trail

Document your completion of this lesson:

• Lesson title and date completed
• Time invested: approximately 45 minutes
• Key learnings in your own words
• Activity submission reference
• Follow-up actions identified (e.g., 'Review our own breach disclosure procedures for timeline analysis gaps')

Conclusion

Let me tell you how Dr. Sharma's story ended.

The investigation confirmed the attacker had been in the systems for at least 14 months. Over 100,000 patient records were potentially exposed. The practice faced multiple regulatory investigations, class-action lawsuits from patients, and a severe loss of trust. Repairing their reputation took years.

The organisation eventually invested in a 24/7 security operations centre, implemented user behaviour analytics, and mandated comprehensive security training for all staff, clinical and administrative. They learned that the cost of advanced detection was a fraction of the cost of a long-undetected breach.

But it doesn't have to be your story. That's why we're here.

You should now understand that a breach disclosure date is often just the end of a long story. You understand how attackers use legitimate tools and credentials to hide in plain sight for months. You know that detection must focus on behavioural anomalies, not just known threats. And you understand how to turn this intelligence into both stronger defences and solid compliance evidence.

Next, we'll explore Next, we'll explore Lesson 1.2: The Contractor's Laptop. We'll examine how third-party access, a common feature in healthcare, can become the weakest link in your security chain.

See you there.

Resources

The course materials folder contains downloadable resources for this lesson:

• Lesson 1.1 Quick Reference Card - Summarise the key behavioural detection indicators for long-dwell breaches and immediate investigation steps for a suspected pre-disclosure compromise on a single page.
• Compliance Mapping Worksheet - Map your organisation's incident detection and response controls to the DORA, NIST CSF, and GDPR requirements relevant to identifying and investigating extended breach timelines.
• Risk Assessment Template - Assess your organisation's specific exposure to patient, low-and-slow attack methods based on the credential use and lateral movement techniques covered in this lesson.
• Further reading - Links to the MITRE ATT&CK framework (for techniques like Credential Dumping, Lateral Movement), and guidance from the NCSC on investigating intrusions.

Greater Pittsburgh Orthopaedic Associates disclosed a 2025 breach, but was there also one in 2024? Defence Masterclass | Threat Intelligence | Lesson 1.1
© LimitedView Limited | 2026