| Update: June 22, 2026 What We Know about the Canvas Breach On May 11, Instructure said it would release a report explaining the cause of the Canvas breach and what it learned. As of June 22, the report is still not available. The company’s incident update page says it “intends to share additional details about the root cause and lessons learned,” but there is no timeline yet. 1 The U.S. House Committee on Homeland Security asked Instructure CEO Steve Daly for a closed-door briefing by May 21, 2026. There has been no public disclosure as to whether that meeting was held or what was discussed. 2 Instructure confirmed that the exploit was linked to its Free-For-Teacher (FFT) account program. BleepingComputer reported that ShinyHunters injected malicious JavaScript by exploiting cross-site scripting flaws in user-generated content features, which gave attackers access to authenticated admin sessions. Instructure has not confirmed these technical details in a public report, but has since permanently shut down the FFT program. 3 What ShinyHunters Has Done Since ShinyHunters continued their activity after the Canvas breach. From May 27 to June 9, they reportedly exploited CVE-2026-35273, a zero-day vulnerability in Oracle PeopleSoft, across more than 100 organizations and 300 systems. Google and Mandiant say about 68% of those affected are in higher education. Oracle released a security alert on June 10, but it is still unclear if all systems have been patched. 4 On June 10, 2026, the University of Nottingham confirmed a breach. Data from about 454,600 current and former students, including personal and academic records, was stolen and posted on ShinyHunters’ data leak site.5 These incidents all raise the same questions: how far can an attacker move, and would you notice? Without a formal root-cause report, institutions have to make these assessments without all the facts. Each institution is still responsible for understanding its own risks, no matter what Instructure has shared. Proactive assessments can help answer these questions before someone else does. Update: May 15, 2026 Significant developments have emerged since this post was originally published on May 11. We’ve summarized the key updates below. Instructure likely paid the ransom. On May 11, Instructure confirmed it reached an agreement with the threat actor, one day before the attackers’ May 12 deadline. The agreement reportedly included the return of stolen data, digital shred logs confirming its destruction, and a commitment from the attackers not to extort individual institutions. Instructure’s statement advised customers not to engage with the criminals directly. Independent analysts say the agreement likely involved paying a ransom, though Instructure has not publicly confirmed a payment or disclosed an amount. Legal experts are urging institutions to treat these assurances with skepticism because shred logs are unenforceable. There is no way to verify that all copies of the data were eliminated, and cybercriminals regularly retain or resell stolen data regardless of agreements. Paying the ransom also doesn’t eliminate notification obligations under state or federal law. The confirmed scope of compromised data. Instructure has clarified that the data accessed included usernames, email addresses, course names, enrollment information, and messages. Core learning content, submissions, and credentials were not affected. CrowdStrike independently verified that there was no system-level access, malware installation, or additional data extraction during the May 7 defacement attack. Parchment, Instructure’s digital transcript service, operates on distinct servers and was confirmed unaffected. Some messages between students and instructors were compromised. Legal advisers are specifically flagging that those messages may include accommodation requests, harassment complaints, and other sensitive communications, and that institutions should treat Instructure’s scope statements as preliminary until the forensic review is complete. Congressional investigation opened. The U.S. House Committee on Homeland Security sent a letter to Instructure on May 11 requesting a comprehensive briefing on how the breach occurred, what data was accessed, and how the company responded. The letter specifically noted that the same threat actor breached Instructure twice within a week and that the second intrusion defaced login pages across at least eleven states. More than two dozen lawsuits filed. As of mid-May, more than two dozen lawsuits have been filed against Instructure, alleging negligence and unjust enrichment. Plaintiffs argue the breach disrupted exams and that sensitive communications including accommodation requests and harassment complaints may have been exposed. Attorneys advising universities are noting that paying the ransom doesn’t satisfy legal or regulatory notification requirements, and institutions should review insurance coverage and prepare for litigation regardless of Instructure’s agreement with the attackers. Guidance from regulators. The Federal Trade Commission published a consumer alert advising users to avoid clicking suspicious messages, monitor credit reports, and contact IdentityTheft.gov if they suspect their personal information is being misused. Universities including Grand Rapids Community College and the University of Washington have informed their communities that there is no evidence of passwords, dates of birth, government identifiers, or financial data being exposed, but recommend resetting passwords and remaining vigilant against phishing. We’ll continue to update this post as Instructure’s forensic review progresses. The root-cause details the company has committed to sharing are not yet public. When they are, we’ll add them here. |
This past week, a ShinyHunters-linked compromise of the Canvas Platform operated by Instructure disrupted universities including Harvard, Columbia, Princeton, Georgetown, along with hundreds of other educational institutions worldwide, with attackers reportedly altering user-facing Canvas pages as part of an extortion campaign. With more than 100 million users globally, and attacker claims referenced roughly 8,000 to 9,000 institutions, though Instructure’s confirmed scope is narrower, this is a significant event. The incident underscores the systemic risk created by widely adopted third-party platforms across the education sector.
After years of assessing complex, interconnected environments, we’ve noticed that the weakest point is almost always the inherent trust between entities such as a Software as a Service (SaaS) and their customers.
Evaluating SaaS platforms like Instructure’s Canvas and their integration into your network and operational processes is crucial for identifying potential risks within these connections. As a Learning Management System (LMS), Canvas often connects with research platforms, cloud services, and student information systems. These integrations require broad access across environments that institutions inherently trust.
However, over time, convenience overrides verification. Shared accounts Shared accounts proliferate, MFA enforcement weakens across organizational boundaries, and service account credentials remain unchanged for years. When a vendor is compromised, those assumptions create direct attack paths into trusted environments.
The Canvas breach demonstrates how quickly those trusted connections can become operational risk at scale.
This isn’t the first time ShinyHunters breached Instructure. In September 2025, they accessed Instructure’s Salesforce through social engineering. Instructure changed credentials, declared it contained, and moved on. Eight months later, the group returned. On May 1, Instructure reported another incident, called it contained by May 2, but by May 7, Canvas portals tied to schools and universities displayed ransom messages. The real lesson isn’t about ShinyHunters’ skills, it’s about what happens when a breach response only addresses credentials and vulnerabilities, not the root exposure.
ShinyHunters claimed access to hundreds of millions of records including private messages, student IDs, names, and email addresses from nearly 9,000 institutions. Instructure confirmed that names, email addresses, student IDs, and user messages were involved, though the full extent isn’t independently verified. The important point is that attackers didn’t need to breach each university; they only had to breach the one vendor everyone trusted.
There’s another risk to highlight. While institutions deal with the disruption, students are locked out during finals and professors are moving course materials, creating ideal conditions for phishing campaigns impersonating Canvas, Instructure, or university IT, offering to restore access. At least one major university had to warn its community about fake messages within hours. A vendor breach doesn’t end when the platform is restored. It creates confusion that attackers quickly exploit, making your users easy targets. The following is a high-level summary and chronological visualization detailing the key milestones of the recent security breach.
Attackers target Higher Education for good reason. Universities store student records, research, financial, and sometimes patient health data. Their IT environments are decentralized, spanning many departments and partners, with large, changing user groups and vendor networks that grow faster than security teams can manage.
ShinyHunters didn’t just go after Instructure. In late 2025 and early 2026, ShinyHunters-linked activity reportedly impacted institutions including the University of Pennsylvania, Harvard, and Princeton directly. The Canvas incident isn’t a one-off event. It’s part of a sustained campaign by a group that understands exactly how interconnected the higher education ecosystem is and knows how to exploit that at scale.
Campuses also manage complex payment systems for dining, bookstores, tuition, and stadiums. We’ve discussed before how annual PCI DSS penetration tests are often treated as a formality, even though the risks are high. Both vendor trust and payment security issues stem from assuming that controls put in place once will always work. Usually, they don’t, and the only way to know is to test them.
Regardless of existing vendor agreements, institutions should immediately pressure-test these questions, which form the core of our penetration tests targeting third-party risk and supply chain vulnerabilities.
What access does each major vendor really have?
Not just what your records say, but what they have right now at the system level. This includes shared accounts, VPN access, shared apps, and cloud resources. Do you have an up-to-date view of every connected platform, the credentials they use, and what they can reach? Most institutions can answer this for their top vendors, but not for the many smaller platforms.
How do you monitor that access?
Giving a vendor access is one thing, but regularly monitoring their activity is another. Most institutions grant access but don’t keep track of what vendors do. This gap makes third-party breaches hard to detect early.
What happens if a vendor is breached?
If Canvas or another key system is compromised, what could an attacker access in your environment? Can they move between systems or reach sensitive data like PHI or PII shared with partners? Do you know the answer, or are you just assuming?
Who is responsible for notifications?
Instructure reported a cybersecurity incident on May 1 and said it was contained by May 2, but by May 7, Canvas portals tied to universities displayed ransom messages. What does your vendor’s breach notification policy actually require, and is that timeline enough for you to respond?
When was the last time you tested these boundaries?
Has anyone on your team simulated what an attacker could do with vendor access or a compromised account inside a trusted network? If you don’t know, that’s your answer.
September 2025
Salesforce-related compromise reportedly linked to social engineering.
Instructure responds
Instructure rotates credentials and states incident is contained.
April 30, 2026
Unauthorized access activity detected. Investigation begins.
May 1, 2026
Unauthorized intrusion confirmed. Law enforcement engaged.
May 2, 2026
Instructure again states the incident is contained.
May 3, 2026
ShinyHunters posts Instructure on leak site. Attackers claim 275M records from ~8,800 institutions.
May 7, 2026
Canvas portals tied to universities and school systems worldwide display ransom messages. May 12 extortion deadline issued.
Oracle PeopleSoft zero-day reportedly exploited
ShinyHunters reportedly exploits CVE-2026-35273 across 300 vulnerable systems. More than 100 organizations affected; ~68% are colleges and universities.
June 10, 2026
Oracle issues security alert. Patch status across affected systems not yet confirmed.
University of Nottingham confirms breach
~454,600 current and former students affected. Personal and academic records posted on ShinyHunters’ leak site.
We performed this kind of assessment for a major research university and a local partner. Both were well-managed and believed their security was strong. But neither had examined their shared boundary from an attacker’s perspective, since they trusted each other and hadn’t questioned that trust in years.
At that boundary, we found shared credentials without MFA, network shares that allowed attackers to move between institutions, and reused passwords on service accounts both teams thought were secure. A single compromised account could give access to the other institution. The risk was greater and had gone untested for a long time.
The results were clear. We showed what an attack between the two environments would look like and how far it could go. We found a path to sensitive shared information that neither team knew about. We also uncovered detection and response gaps that only appeared when tested. Together, we created a remediation plan to improve both institutions’ security and shared resources.
A meaningful supply chain assessment tests the real security boundary, not just what’s assumed. This includes external testing of internet-facing systems, internal network testing from different breach points, application testing of shared platforms, reviewing authentication and authorization across shared boundaries, and simulating lateral movement to see how far an attacker could go. The findings matter because they reflect reality, not just documentation. The goal isn’t to remove every vendor, but to make sure your controls work as expected.
Immediate action is possible even before Instructure releases its forensic analysis. Considering the observed breach characteristics and common vulnerabilities in higher education, we recommend prioritizing these measures this week.
Rotate all Canvas API keys and integration credentials in your system.
Instructure has reissued application keys with timestamps so admins can spot legitimate keys during re-authorization. Take advantage of this. Any integration still using an old key is a risk you can remove right now.
Check MFA enforcement at every shared network boundary.
Check MFA enforcement at every shared network boundary, not just at your perimeter, but between your institution and every partner, vendor, or affiliated group with network access. If MFA isn’t enforced at these points, one compromised account can put you at risk.
Review all shared service accounts between your institution and partners.
These accounts often go unaudited because they’ve worked for years. Look for password reuse, excessive privileges, and accounts that haven’t been reviewed since setup. This is where we find the most serious risks in partner assessments.
Inform your users about what to watch for now.
Institutions should anticipate phishing campaigns using Canvas-related language following a breach of this scale. Anyone with a school email in the breach is a target. Staff whose Canvas messages included sensitive topics—like safeguarding, accommodations, or finances—should be told their conversations may have been exposed and to treat any unexpected messages about Canvas access with caution.
Check your vendor breach notification requirements.
Review the contract language for Canvas and other major SaaS providers. Find out their notification timelines, what counts as a reportable incident under your laws, and whether there are gaps between what vendors promise and what you need to respond. Don’t wait until the next incident to find out.
The Canvas breach is a good time to test your assumptions, not just about Instructure, but about how your institution manages the risks from all its vendors and partners.
We’ve consistently found that proactive assessments do more than improve security—they provide clear, actionable data that helps secure funding and engage IT leaders. Showing exactly what an attacker could do, where detection gaps are, and what a remediation plan looks like leads to better conversations than compliance reports. Security should be a continuous cycle: assess, improve, and repeat. That cycle starts when you test the real boundaries.
The most damaging breaches in higher education aren’t coming through obvious entry points. They happen through trusted connections that haven’t been fully checked, shared platforms, partner networks, and vendors with old access that no one has reviewed since onboarding. If your team can’t confidently answer the questions here, that’s the gap to close before someone else finds it.
Further Reading
Why Your Campus Payment Systems Need Annual Penetration Testing
Managing OT Supply Chain Security and Insider Threats
Public reporting indicates the incident involved Instructure’s Canvas platform and related systems, not separate confirmed breaches of each university’s own network or identity infrastructure. Because Canvas is widely used across education, the compromise created downstream disruption for multiple institutions at once.
Instructure has reported that exposed data may include names, email addresses, user IDs or student IDs, course-related information, and Canvas messages. Attackers claimed access to a much larger dataset tied to thousands of institutions, but those broader claims have not been independently verified.
Higher education environments often rely on deeply integrated SaaS platforms, APIs, shared authentication, cloud services, and partner systems. When those connections are trusted but not continuously validated, a compromise at one vendor can create operational disruption and potential access risk across many institutions.
Institutions should review connected integrations, rotate exposed or high-risk credentials, validate MFA enforcement, monitor suspicious activity, warn users about phishing attempts, and review vendor notification and incident response requirements.
A strong third-party risk assessment tests what an attacker could actually reach through trusted vendor relationships. This can include reviewing authentication paths, exposed integrations, excessive permissions, lateral movement opportunities, and assumptions that may not have been validated since onboarding.
Sources:
HHS proposed mandatory annual penetration testing for all HIPAA-covered entities. Here’s what the rule requires, when it takes effect, and how to prepare.
| Update — May 26, 2026: OCR projected May 2026 as the finalization date for the proposed HIPAA Security Rule. That date has come and gone without a final rule, but this isn’t unusual. The requirements outlined in this article reflect the proposed rule as written, and the 240-day compliance window will apply once it’s final. We’ll update this post as new developments arise. |
| Update: July 13, 2026: HHS has moved this rulemaking to a “long-term action” on its federal regulatory agenda, pushing the expected final rule date from May 2026 to July 2027. Several independent firms have confirmed this update, citing Reginfo.gov. Keep in mind, this is just a planning estimate and could change again. This update doesn’t change the guidance below. HHS has made it clear that risk analysis, MFA, encryption, and vulnerability management are already required under the current Security Rule, no matter the NPRM’s status. Instead, use this extra time to build a thorough readiness plan rather than putting off action. |
On February 21, 2024, Change Healthcare’s systems went dark. Within hours, pharmacies across the country couldn’t process prescriptions. Hospitals couldn’t verify patient insurance. Prior authorizations stopped moving. For weeks, clinicians worked around paper processes they hadn’t used in years.
The numbers are almost hard to absorb. The breach ultimately affected approximately 100 million Americans, according to reporting by the American Hospital Association and IBM. UnitedHealth Group’s total cost landed near $2.87 billion. A separate survey of roughly 1,000 hospitals found that 94% reported direct financial impact. (AHA, March 2024)
Change Healthcare’s impact was so damaging due to the scale, a cascading effect through interconnected systems. One vendor, one attack, and suddenly half the healthcare payment infrastructure in the United States stopped working. The attackers found a path in, moved laterally, and got to the most sensitive systems before anyone raised an alarm. That’s a penetration testing problem. It’s also an architecture problem, a third-party risk problem, and a monitoring problem.
HHS had been watching these trends accumulate for years before the rule changed. By January 2025, HHS sought to enact real change.
The original HIPAA Security Rule dates to 2003. Healthcare IT in 2003 looked nothing like it does today. The rule’s framework survived two decades largely intact, while the threat environment transformed completely. Large healthcare breaches increased 102% between 2018 and 2023. The Healthcare and Public Health sector has been the most targeted critical infrastructure sector since at least as far back as 2015. (HHS OCR NPRM preamble, Federal Register 2024-30983, January 2025)
This showcases a structural failure of a compliance framework that treated security controls as optional when inconvenient.
The breach picture by the numbers:
OCR enforcement tells the same story from a different angle. In 2024, OCR completed 22 HIPAA enforcement actions, the second-highest total in the agency’s history, collecting $9.9M in penalties. The most frequently cited violation: inadequate risk analysis, appearing in 13 of 22 enforcement matters. (LegalHIE, January 2025)
HHS published the proposed HIPAA Security Rule update in the Federal Register on January 6, 2025 (document 2024-30983). The proposal is the most significant update to the Security Rule since it was enacted. It converts many previously “addressable” standards, meaning organizations could choose alternatives or skip them with documentation, into specific, required controls with defined timelines. (Federal Register 2024-30983)
The proposed rule would require all covered entities to conduct penetration testing at least once every 12 months, codified at 45 CFR 164.312(h)(2)(iii). Testing must be performed by a “qualified person(s)” with knowledge of “generally accepted cybersecurity principles.” The rule does not prescribe a specific certification or methodology, but it sets the floor: annual, qualified, documented.
Before this proposal, penetration testing appeared nowhere in the HIPAA Security Rule as a specific requirement. Organizations could satisfy risk analysis obligations without ever running an actual attack simulation. Many did.
Separate from penetration testing, the proposed rule requires automated vulnerability scanning at a minimum of every six months. These are different activities with different purposes: vulnerability scanning identifies known weaknesses, while penetration testing exploits them to demonstrate real-world impact. Both are now in scope, allowing for organizations to fully understand the risks within their environment.
The proposed rule mandates multi-factor authentication for all access to systems containing electronic protected health information (ePHI). There are limited exceptions for legacy medical devices manufactured before March 2023, where hardware constraints may make MFA technically impossible. Outside that narrow carve-out, the rule removes ambiguity.
Encryption follows the same logic. The proposal eliminates the “addressable” classification for encryption at rest and in transit. Every covered entity will need to demonstrate actual encryption implementation, not just a documented rationale for why they chose something else.
Covered entities must maintain a written technology asset inventory, updated at least annually or whenever infrastructure changes. Alongside the inventory, the rule requires network maps showing how ePHI enters, exits, and moves through the organization’s systems.
These requirements exist because you cannot protect what you can’t see. In our experience, assessment teams frequently discover systems containing ePHI that their own IT teams didn’t know about. The inventory requirement will force that accounting.
The proposed rule introduces specific, measurable timelines that replace vague “reasonable” language. The key deadlines:
The 15-day patch window for critical vulnerabilities deserves particular attention. Many healthcare organizations operate on quarterly or semi-annual patch cycles. That cadence doesn’t survive this rule if it’s finalized.
Healthcare breaches cost 60% more per incident than financial sector breaches, and more than twice the global average, according to the IBM Cost of a Data Breach Report 2024. The $9.77M average reflects the compounding cost of downtime, notification, legal exposure, and regulatory penalties that healthcare uniquely absorbs.
The NPRM was published on January 6, 2025. The comment period closed March 7, 2025, with more than 4,700 public comments submitted. (HIPAA Journal) OCR’s regulatory agenda projects finalization in May 2026. Once the final rule is published, covered entities have 240 days to achieve compliance, placing the hard deadline in early 2027. (Alston & Bird NPRM Analysis)
There is real regulatory uncertainty here. The Trump administration issued a broad regulatory freeze in early 2025, and healthcare industry groups, including CHIME, raised concerns about implementation cost, which HHS estimates at approximately $9.3B in the first year. (HHS NPRM Regulatory Impact Analysis) OCR has maintained its timeline despite that friction.
Waiting for the final publication is the wrong call. 240 days is not a long runway when you factor in what actually happens in that window. You need to identify and engage a qualified penetration testing vendor. You need to schedule the assessment around your operational calendar. You need to remediate findings. You need to document everything. Then you need to be ready to do it again in 12 months.
A penetration test is not a vulnerability scan. A vulnerability scan runs automated tooling against your systems to identify known weaknesses and misconfigurations. It’s valuable, but not sufficient on its own. Penetration testing takes those identified weaknesses and attempts to exploit them, chaining vulnerabilities together the way an actual attacker would, to demonstrate real-world risk. Furthermore, penetration tests often identify vulnerabilities that are not detectable by vulnerability scans — such as misconfigurations without Active Directory.
The proposed rule requires both penetration testing and vulnerability scanning, on separate schedules.
To truly mirror a real-world adversary, an assessment needs to go beyond a simple “point-and-click” scan. It requires simulating the entire attack lifecycle. As shown in the diagram above, this includes testing how an attacker might pivot from a remote entry point through the network boundary, or even how a “local attacker” (such as a malicious actor with physical access or a compromised workstation) might escalate privileges within your Active Directory to reach high-value targets like database servers.
A HIPAA-aligned penetration test should cover the full attack surface relevant to ePHI.
That means:
The deliverable from a qualified penetration test should include an executive summary suitable for board and C-suite consumption; a technical findings report with severity ratings and supporting evidence; remediation guidance prioritized by risk; and attestation documentation suitable for regulatory review.
What We’ve Learned Working Inside HHS
BreakPoint Labs has conducted penetration testing for the Department of Health and Human Services, the same agency proposing this rule, for over six years. That work has taken us through a wide range of Healthcare systems and given us a view into the security challenges that health organizations grapple with directly. The patterns we observe mirror what we see across covered entities in the field.
Third-party connections are the most reliable attack path. Almost every meaningful escalation we’ve achieved in healthcare environments started with a vendor connection, a partner integration, or a legacy API that predated the current security team. These connections are often trusted implicitly. They shouldn’t be.
Encryption policy and encryption reality are different things. Organizations document encryption requirements. They implement encryption on new systems. They miss decommissioned servers, backup repositories, test environments, and older infrastructure that hasn’t been touched in three years. The gap between the policy and the deployment is where ePHI exposure actually lives.
Medical devices are the hardest conversation to have. Clinical teams resist security controls on devices they use for patient care, and they’re not wrong to flag the operational implications. But a networked infusion pump running an unpatched OS is a lateral movement opportunity. We find exploitable medical device vulnerabilities in almost every healthcare environment we test.
Risk analysis is treated as a document, not a process. The most common failure pattern we observe matches what OCR cited in 13 of 22 enforcement actions last year: a risk analysis that was completed once, filed, and not revisited. A risk analysis that doesn’t evolve with the environment isn’t protecting anyone. It’s just paperwork.
Workforce access controls break down at departure. The proposed 1-hour termination window sounds aggressive. In practice, we routinely find active credentials belonging to employees who left months earlier. The manual coordination between HR, IT, and security fails predictably under operational pressure.
You don’t need to wait for the final rule publication to begin.
Five steps you can take right now:
The proposed rule isn’t final yet, but the direction is clear. Annual penetration testing, mandatory MFA and encryption, strict remediation timelines, and documented asset inventories will all be required for every HIPAA-covered entity. The 240-day compliance window after finalization sounds like breathing room. It isn’t, once you account for procurement, scheduling, assessment, remediation, and documentation.
If your organization hasn’t conducted a penetration test recently, or if your last assessment didn’t cover medical devices, cloud environments, and business associate connections, now is the time to close that gap.
BreakPoint Labs works with healthcare organizations navigating exactly this challenge. Our team brings direct experience conducting penetration tests inside federal health environments and understands what regulators look for when they review documentation. If you’d like to talk through your current posture and what a HIPAA-aligned assessment would look like for your organization, contact us.
Yes. HHS originally projected a final rule in May 2026. That date passed without action, and HHS has since reclassified the rulemaking as a “long-term action” on its federal regulatory agenda, with a new anticipated final action date of July 2027. This is reported independently by multiple trackers, including Clark Hill, Davis Wright Tremaine, and HIPAA Journal. It’s worth noting that this new date is a planning estimate, not a binding deadline, and HHS hasn’t publicly explained its reasoning. The delay doesn’t change what’s already expected of covered entities under the current Security Rule, and it isn’t a reason to pause cybersecurity improvements in the meantime.
Yes. The proposed rule applies to all HIPAA-covered entities, regardless of size. Small practices, solo providers, and rural clinics are subject to the same requirements as large health systems. HHS estimates compliance costs at approximately $9.3B industry-wide in the first year, which reflects the breadth of organizations in scope [HHS NPRM Regulatory Impact Analysis] https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/index.html.
The proposed rule requires penetration testing by a “qualified person(s)” with knowledge of “generally accepted cybersecurity principles.” It does not mandate a specific certification. In practice, organizations should look for testers with demonstrated healthcare experience, familiarity with clinical environments, and the ability to produce documentation that satisfies regulatory review. Credentials like OSCP, CEH, or equivalent provide a reasonable baseline signal.
Willful neglect violations carry penalties of up to $73,011 per day per violation, with an annual cap of $2,134,831 for the same violation category [HHS OCR]https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/data/enforcement-highlights/index.html. In 2024, OCR completed 22 enforcement actions, collecting $9.9M in penalties. Inadequate risk analysis, which maps directly to the new testing requirements, was cited in 13 of those 22 matters [LegalHIE, January 2025] https://www.legalhie.com/a-look-back-at-2024-hipaa-enforcement-year-in-review/.
The proposed rule explicitly references NIST frameworks and aligns with the HHS 405(d) Health Industry Cybersecurity Practices (HICP). The 405(d) Cybersecurity Performance Goals already recommend annual penetration testing as a high-priority practice. Organizations that have adopted the HICP framework will find significant overlap with the new requirements. NIST CSF alignment won’t get you all the way there, but it puts you ahead of starting from scratch.
No. A vulnerability scan uses automated tools to identify known weaknesses in systems and software. Penetration testing goes further: a qualified tester actively attempts to exploit those weaknesses, chain vulnerabilities together, and demonstrate real-world impact. The proposed rule requires both. Vulnerability scanning happens every six months. Penetration testing happens annually. They serve different and complementary purposes.
Sources referenced in this article:
Your vulnerability scanners might show clean reports, your patching schedule could be on track, and your compliance audits may look good. Scanners identify outdated components, but they can’t reveal if password reset, MFA recovery, or help desk procedures can be exploited to enable account takeover.
As penetration testers, we don’t just look for missing patches. We focus on logic errors and process gaps that let us walk right in. After over a decade of testing healthcare systems, we’ve noticed a pattern: most breaches don’t come from unpatched systems. Instead, attackers exploit the hospital’s biggest strength—its culture of helpfulness and urgency.
If you’re unsure how your identity recovery, delegated permissions, or external assets would hold up under adversarial testing, that uncertainty itself is the signal.
Hospitals are designed to say “yes” to clinicians so they can save lives. If a surgeon is locked out of their EMR, the priority is to get them back in immediately.
During a recent engagement, a controlled social engineering call to the help desk, using publicly available information to validate our identity and leaning into a ‘broken phone’ excuse, our tester built enough trust for the help desk to send an MFA reset QR code to a personal Gmail account controlled by our team. No technical exploit needed.
The question then becomes: if you need to reset your password or your multi-factor authentication device, what’s the process a user would go through to regain access? If your recovery process relies on human discretion rather than strict technical verification, it’s a high-risk entry point.
Physical security in hospitals is also uniquely challenging because hospitals are open to the public. Anytime you have to let the public in, it’s a huge challenge. Attackers will look to exploit any “trust layer” they can.
To illustrate this, during one assessment, we initially encountered a rock-solid security guard who denied us access to a restricted elevator because we didn’t have a badge. However, we noticed a floor with heavy construction that would give us access to the restricted area. We took advantage of it and, with confidence, walked through the construction space to the other side, then took an unguarded elevator up from there. At the final access point, the guard buzzed us in without looking up from their phone, assuming we must have been cleared by the second layer of security.
This highlights a common vulnerability: Attackers look for temporary gaps in the physical perimeter, whether it’s a construction zone, a service hallway, or a temporary work site. This raises the question: If someone bypassed a checkpoint using one of these non-standard routes, would your controls prevent it, or would they rely on trust and urgency?
Just as we bypass physical checkpoints via temporary routes to test the ‘trust’ of your staff, we bypass digital perimeters to test the ‘trust’ of your internal network logic. While perimeter controls receive a lot of attention, the internal network often becomes a “rat’s nest” of legacy permissions. Over years of use, AD permissions can become layered with inherited rights, creating unintended privilege paths.
In one hospital, we found that the “Everyone” group had been granted “Generic All” permissions across the entire domain. Because every user was in that group, it effectively meant every account in the building was a Domain Admin. This was a huge risk that had been there for 10 years because it doesn’t show up in a vulnerability scanner.
To identify these privilege escalation paths, we perform a structured analysis of AD permissions:
In a medical environment, you can’t just start hacking. It requires a methodical approach, because launching a tool at it could have a negative impact. In healthcare, speed is not the objective. Safety and fidelity are.
We often start by asking a simple question: “If someone performed a DCSync attack inside your network right now, would you detect it?”
In over a decade of testing hospital environments, we’ve only seen one hospital detect this internal attack behavior in real time. Most organizations are so focused on outbound malware beacons that they miss the “loud” behavior of a targeted attacker on the inside. We work together to figure out how you will alert on that, tuning your tools to get high-confidence triggers.
The diagram below shows how we suggest conducting penetration tests. We’re leveraging infrastructure the same way a remote attacker would. This is important because it allows you to fully flesh out your defenses. An attacker’s going to leverage malware and, once they establish internal access, use command-and-control (C2) to communicate with a management server that controls the endpoint.
That’s why we suggest a hybrid approach for hospitals to include penetration testing and purple team integration. In the last few days of the test, we’ll go through and emulate stealthy attacker techniques and map them back to the MITRE ATT&CK framework with timestamps. We then work alongside your team to identify exactly which activities were detected and which went unnoticed.
To reduce exposure before a full engagement, we recommend starting with these areas.
Establish a Verified External Asset Inventory
One of the bigger risks, generally speaking, is that when we conduct a hospital pentest, they don’t know what they have on the internet. We’ve seen printers, medical IoT devices, and a medical app used for messaging doctors and nurses online, just to name a few. Because you’re getting attacked and scanned 24-7, 365 days a year, it’s critical to understand your footprint. That’s the first challenge.
Perform a Structured AD Review
If your Active Directory has never undergone a privilege path analysis, there’s likely accumulated risk embedded in delegated rights and inherited permissions. Conduct a review of “delegated administrative rights” and “privilege escalation chains”. The goal is to determine if a “low-privilege user can directly or indirectly modify, reset, or control higher-privilege accounts”.
Test Identity Recovery and Account Management Processes
Walk through your processes objectively to test whether your help desk relies on a “name and confidence” approach to bypass technical controls. If identity recovery depends heavily on “discretion or urgency,” it deserves a redesign.
Audit Public-Area Network Ports
Hospitals are open environments. That’s the reality. Walk through your waiting rooms, conference areas, and even construction zones. Are there switch ports accessible, and are they locked down? Without locking down those ports in public areas, an attacker can plug into the wall, circumvent all the external controls, and land on the internal network. It doesn’t require a sophisticated exploit. Just access.
A well-executed penetration test isn’t a surprise inspection. It is a controlled validation of how your environment performs under realistic adversarial conditions.
Vulnerability management identifies known weaknesses. Adversary simulation evaluates how identity, logic, and process can be chained together to create access.
Protecting patient data and life-supporting systems requires more than patch discipline. It requires testing how your environment behaves when someone is actively trying to misuse it.
If you’d like to see a technical walkthrough of these scenarios, watch our full session with Health-ISAC here.
If you want a clear view of what your organization exposes externally without disruption, contact us for a complimentary external attack surface snapshot based solely on passive reconnaissance.
In our testing, attackers most frequently exploit identity recovery processes rather than technical vulnerabilities. Help desk procedures that rely on human discretion, such as resetting MFA based on a phone call, create high-risk entry points that don’t require any technical exploit to abuse.
A DCSync attack allows an attacker with sufficient Active Directory privileges to extract password hashes for any account in the domain, including Domain Admins. In over a decade of testing hospital environments, we have seen only one hospital detect this behavior in real time. Most organizations miss it entirely.
Privilege escalation in Active Directory occurs when a low-privilege account can directly or indirectly modify, reset, or control higher-privilege accounts through inherited permissions, delegated rights, or misconfigured group memberships. These paths often go undetected for years because they don’t show up in vulnerability scanners.
Hospitals are open to the public by design, creating layers of trust that attackers exploit. Common entry points include construction zones, service hallways, and temporary work sites that bypass standard checkpoints. In one assessment, our team accessed a restricted area through a construction floor and was buzzed through a final checkpoint without verification.
Start with four areas: establish a verified external asset inventory so you know what is exposed on the internet, perform a structured Active Directory privilege path analysis, test your identity recovery and help desk processes against social engineering scenarios, and audit network ports in public-facing areas like waiting rooms and conference spaces.
In Active Directory (AD) security assessments, data collection is the first step. In large environments, the volume of data in BloodHound can make graphs challenging to analyze.
In Part II of our AD-RECON series, we examine the advanced Pathing and Transitive modules. These features help convert large datasets into actionable output, making it easier to identify critical attack paths without being limited by unusable graphs.
Prerequisites: This guide assumes you have AD-RECON installed and connected to your database. If you are just getting started, please review How to Triage BloodHound Data Faster for installation steps and basic configuration.
With BloodHound running and your data populated, view the help menu by running:
python3 ad-recon.py --helpThis displays available options, including the two focused on here: –pathing and –transitive.
The –pathing switch runs path-specific analysis alongside the usual default modules. This is especially useful for identifying accessible high-value targets.
Command:
python3 ad-recon.py --pathingWhen executed, AD-RECON generates output such as:
The output provides critical context, such as the number of hops required to reach accounts or groups with sensitive privileges.
In the video example, we identify a user (Viserys Targaryen) who does not have the admin count flag enabled, but still has a path to DA. By cross-referencing this user in BloodHound, we see they are a member of the “Domain Users” group, which has Active Directory Certificate Services (ADCS) rights over the domain. This nested permission set effectively grants them Domain Admin privileges, a critical finding that might be missed in a crowded graph.
Transitive queries let you look deeper into outbound rights that propagate through group memberships.
Command:
python3 ad-recon.py --transitiveThis switch helps investigate the following:
The Scale Problem
In small datasets, you can often visually spot these issues in BloodHound. In enterprise environments with thousands of users and systems, the graphs become illegible without targeted searching.
AD-RECON acts as a filter, allowing you to quickly identify specific systems or users that require manual investigation.
Watch the full video below as we walk through command-line execution and analyze the results in BloodHound.
Resources:
Stay tuned for Part III, where we cover extending AD-RECON with custom query development.
The –pathing switch focuses on direct and multi-hop routes to high-value targets like Domain Admin. It tells you who has a path and how many steps it takes to get there. The –transitive switch goes deeper into group membership chains, surfacing rights that a user or computer holds indirectly through nested group memberships.
AD-RECON works with BloodHound Community Edition. It communicates directly with the Neo4j backend using the Python Neo4j driver. As long as your BloodHound instance is running and your data is ingested, AD-RECON will connect to it. The config.toml file lets you point the tool at local, remote, or Docker-based Neo4j instances.
The adminCount attribute is only set on accounts that are currently, or were previously, members of a protected group. A user without that flag is not under SDProp protection, meaning their permissions are less likely to be audited or flagged. When AD-RECON identifies these accounts, it signals a path that defensive tooling and manual reviews often miss.
Start with rights over Certificate Authorities and Domain Controllers. GenericAll or enrollment rights over a CA are high-priority findings because they often lead directly to domain compromise without requiring credential theft. From there, focus on any object where a transitive chain originates from a broad group like Domain Users.
Part III will cover custom query development, extending AD-RECON beyond its built-in modules. Check back on the BreakPoint Labs blog or follow us on LinkedIn for updates.
Luke Hudson is a Senior Offensive Security Engineer at BreakPoint Labs, where he applies deep technical expertise to assess client systems against advanced adversarial threats. He is an expert in adversarial tradecraft, specifically in payload development and bypassing endpoint detection (AV/EDR), leading engagements from initial planning through execution and reporting. Luke holds a variety of advanced certifications, including OSCE, OSEP, OSCP, CRTL, and CISSP.
Effective Active Directory (AD) analysis often requires interpreting large amounts of data to identify real risks. While BloodHound is the industry standard for graphing these relationships, manual analysis can be arduous, especially with large datasets.
BreakPoint Labs developed AD-RECON, a Python utility that quickly triages BloodHound data to address this challenge.
Senior Offensive Security Engineer Luke Hudson provides a technical walkthrough to help security practitioners get started with this capability. The guide shows how to configure the tool and start identifying escalation paths right away.
How does AD-RECON fit into your workflow? AD-RECON bridges the gap between raw data ingestion and actionable findings in Bloodhound. It works by communicating directly with the Neo4j backend, automating impactful queries that usually require manual analysis.
For Red Teams and Penetration Testers, this automation enables quick wins early in analysis, reduces the strain of analyzing complex datasets, and allows operators to focus more on executing the engagement.
For Blue Teams and Defenders, it provides a repeatable way to quickly audit Active Directory health and potentially uncover latent risks before they are exploited.
1. Prerequisites & System Requirements
AD-RECON is lightweight and intended to work with all recent versions of Python 3.
n config.toml file.2. Automating “Quick Wins.”
AD-RECON’s core value is its ability to rapidly parse the Bloodhound database for misconfigurations or interesting targets for further analysis. This is especially impactful for identifying escalation paths, especially when visualizing the data becomes unrealistic.
The tool automates the detection of critical vectors, including:
3. Customization & Extensibility
AD-RECON is designed to be extensible. While it includes our team’s most effective queries, users can add their own Cypher queries. The config.toml file provides flexible configuration, letting you easily connect to local or remote Neo4j databases, which is ideal for teams on shared instances.
For those following along with the video, here are the specific commands required to get up and running:
1. Environment Preparation: Ensure you have Bloodhound installed and running, and that data is successfully ingested. AD-RECON supports any recent version of Neo4j and Bloodhound (local, remote, or Docker installation). The demo video utilizes Bloodhound CE version 8.3.1 from the Kali apt repo.
2. Cloning the Repository Pull down the tool from GitHub and navigate into the directory:
git clone https://github.com/tid35/ad-recon.git
cd ad-recon
3. Setting Up a Virtual Environment. It is highly recommended to use a virtual environment.
python3 -m venv ad-recon-demo
source ad-recon-demo/bin/activate
4. Installing Dependencies: Install the required Neo4j driver and Toml parser at minimum, though some additional dependencies can be helpful for analyzing output:
pip3 install -r requirements.txt
Configuration (config.toml) Open the config.toml file to configure your database connection.
bolt://localhost:7687 (Change this if using a remote instance or non-standard port).6. Running AD-RECON
AD-RECON help:
python3 ad-recon.py -hRun default queries:
python3 ad-recon.pyList all available queries:
python3 ad-recon.py -LExecute a specific query (e.g., List admincount=true users):
python3 ad-recon.py -Q get_adminUsers
AD-RECON enables operators to perform Active Directory analysis quickly and reliably, reducing the overhead required to analyze complex environments.
Resources:
Now that you have the tool configured and your “quick wins” identified, it is time to tackle the complex graphs. In Part II, we cover:
Check out Part II: Analyzing Attack Paths and Transitive Rights
Q: How can AD-RECON be integrated into automated pipelines or CI/CD? AD-RECON can be easily integrated into automated Red Team pipelines or CI/CD workflows. You can simply call the script with the necessary flags (e.g., -Q get_adminUsers or –transitive) and export the output for downstream analysis.
Q: What is the output format? Can findings be exported? AD-RECON outputs finding data to the console and to text-based output. Users can use the –dump flag to print raw queries for reporting or analysis. The upcoming 2.0 update of AD-RECON will support additional reporting formats.
Q: Is it compatible with the latest versions of BloodHound? AD-RECON communicates directly with the Neo4j backend database using Cypher queries. As long as the database structure is intact, it is designed to work with virtually any version of BloodHound (including modern forks) and is regularly tested against recent updates. The Neo4j driver supports Bolt versions 4.4-6.0, though older versions of the driver can be installed to support especially out-of-date instances of Neo4j.
Q: Are there real-world examples of its impact? On most Active Directory networks where we deploy AD-RECON, it uncovers at least one significant misconfiguration that had previously gone unnoticed. We routinely use it to identify obscure Attack Paths, such as legacy object permissions or trust relationships where manual visual analysis fails.
Q: Where can I get support or share custom queries? We encourage community collaboration. The project is hosted on GitHub, where users can submit issues for troubleshooting, contribute new detection logic via Pull Requests, or discuss use cases.
Luke Hudson is a Senior Offensive Security Engineer at BreakPoint Labs, where he applies deep technical expertise to assess client systems against advanced adversarial threats. He is an expert in adversarial tradecraft, specifically in payload development and bypassing endpoint detection (AV/EDR), leading engagements from initial planning through execution and reporting. Luke holds a variety of advanced certifications, including OSCE, OSEP, OSCP, CRTL, and CISSP.
Welcome to the final installment of The Attacker’s Playbook. So far, we’ve covered exploiting the human element (Part 1), finding unlocked doors (Part 2), and using forgotten keys to the kingdom (Part 3) to get inside a network.
But initial access is just the beginning. The real damage is done when we move through the internal network, abusing trust and misconfigurations to turn a minor foothold into a major compromise.
Active Directory (AD) is the heart of most corporate networks, but its permissions can become a tangled “rat’s nest” of complexity. An automated vulnerability scanner can’t understand the intricate web of trust relationships that a human attacker can exploit.
The Flaw: A standard user account may seem harmless, but it could have a hidden, indirect path to administrative power. It’s not uncommon to find that the default “Domain Users” group has overly broad permissions, such as the ability to log into nearly every computer on the network, including servers.
Specifically, we look for the “GenericAll” permission. This allows one group to fully control another object. Even if the target account is disabled, an attacker with GenericAll rights can enable it and abuse those permissions.
The Attack: As we acquire user accounts, we use Bloodhound to map complex relationships and find unexpected privilege escalation paths.
This exact flaw was enumerated on a recent pentest where the “Domain Users” group had GenericAll access to a disabled service account. Seemingly for no reason, this permission existed on an account no one was monitoring.
From there, we enabled the account, reset the password, and masqueraded as that service account on the network. We discovered this service account had interesting permissions, including the ability to modify the password of a Domain Administrator.
After confirming this action was allowed within the Rules of Engagement (ROE), the team abused these permissions to take over the entire AD forest and ultimately the network.
The Result: By manually navigating this maze, we can turn a low-privilege account into a full Domain Administrator, demonstrating a critical risk that no vulnerability scanner would discover.
Mitigation Strategies: Active Directory is a common target because it’s often a “rat’s nest” of complex permissions.
The most damaging breaches rarely rely on a single vulnerability. Instead, they emerge from creative chaining of minor, overlooked issues, a forgotten file, an exposed port, a default password—into a pathway through the maze of internal trust.
Key Takeaways:
Defending against these threats requires adopting the attacker’s perspective. This is where red team expertise provides the greatest value, simulating real-world thinking, not just automated scans.
Your security journey doesn’t end with this playbook. Contact us to learn how our expert-led penetration testing helps organizations secure their networks from the inside out.
That wraps up The Attacker’s Playbook. But your security journey shouldn’t stop here. Check out our deeper dives on Active Directory in “Abusing Active Directory: Down the Rabbit Hole We Go,” and watch this short clip from our recent webinar on Active Directory permission risks — or get in touch to test your defenses before attackers do.
In Part 1, we showed how a single text file could compromise an entire healthcare network. But not every breach starts with a forgotten password file.
Sometimes, the threat is physical. It’s an unlocked workstation in a patient room, an open network jack in a hallway, or a forgotten web portal that everyone—including the IT team—forgot was facing the internet.
Hospitals are unique environments. They host a constant stream of visitors who are granted a level of privacy not found in a typical corporate office. Unfortunately, this physical access can quickly become a digital nightmare.
The Flaw: For a busy hospital IT team, securing every connected workstation is a monumental challenge, yet these workstations remain a frequent entry point for attackers.
The Attack: An attacker can plug a device into a physical port on an unsecured workstation. Even if the organization has disabled USB drives, many common prevention methods are ineffective against Human Interface Device (HID) attacks.
In this scenario, a malicious device masquerades as a keyboard. This allows it to bypass standard USB storage restrictions and rapidly type commands to download and execute malware.
The Result: In just a few minutes, an attacker can turn an unsecured workstation in a patient room into a persistent foothold deep inside the network. The attacker achieves this without needing to defeat a single security appliance.
Mitigation Strategies: Physical and digital security are deeply intertwined.
Sometimes, the greatest risks are the systems you don’t even know are exposed. Poor asset management, a human process, can leave a critical internal system open to the entire internet.
The Flaw: During a pentest for a healthcare customer, our team identified a pager application web portal for medical personnel that was accessible from the internet. The organization didn’t realize this system was publicly exposed. This kind of oversight in asset management is a common challenge we see when conducting security penetration testing for our clients.
The Attack: We discovered we could send a pager message to our Point of Contact without being authenticated to the system. An attacker could exploit this vulnerability to cause significant disruption to staff communications.
In addition, the application publicly listed personnel names and phone numbers, providing a perfect resource for a future phishing or social engineering campaign.
The Result: A critical communication line was left open to potential disruption, and a sensitive employee directory was exposed to the public, all from a system they didn’t know was exposed.
Mitigation Strategies: You can’t protect what you don’t know you have.
Your true attack surface is always larger than the systems you have on paper. A single workstation or forgotten web portal can open doors that attackers are eager to exploit.
Key Takeaways:
Our hospital cybersecurity assessments go beyond basic scans. We evaluate everything from workstations to waiting room jacks to exposed web portals, helping organizations secure both the physical and digital sides of their attack surface.
Once we’re in, we look for the “keys to the kingdom” — and too often, they’re left lying around. In Part 3, we reveal how default credentials, old accounts, and mismanaged data expose entire networks. If you think your old password doesn’t matter, think again.
When you picture a cyberattack, what comes to mind? Is it a shadowy figure in a hoodie, typing code to execute a brilliant, sophisticated exploit against a firewall? While that makes for a great movie scene, the reality is often far less cinematic.
Organizations invest millions in state-of-the-art security technology, but time and again, we find that the most critical breaches don’t start with a zero-day exploit. They start with a simple, predictable, and profoundly human mistake. To show how a small error can have massive consequences, let’s look at a real case from one of our healthcare assessments.
During a large-scale assessment of a healthcare network, our team was inside the environment, sifting through terabytes of data on internal file shares. This is where manual work often yields the most critical findings.
The Flaw: Using a tool called Snaffler, which scans network shares for interesting data, we received a massive output file to analyze. Through careful analysis, a team member spotted something unusual in a temporary folder on a random system: a file named p.kdbx. We immediately recognized this as a KeePass password database. Right next to it was a simple text file: p.txt.
The Attack: We opened p.txt. It contained a single string of text. On a hunch, we used that string as the password to open the KeePass database. It worked.
The Result: The database exposed numerous sensitive accounts. Most notably, it provided us with the credentials for a service account with a direct path to full Domain Administrator privileges. A single, forgotten text file gave us the keys to the entire kingdom.
For a detailed breakdown of the tools and techniques we use to discover exposed files and credentials on network shares, read our in-depth guide: Introduction to Share Analysis.
This is the human element at its purest. It wasn’t a complex software vulnerability or a misconfigured firewall. It was one person’s simple mistake that completely undermined the organization’s security posture.
This is a perfect example of what we look for. However, “human error” is a broad category that attackers systematically target. It can be a process failure, like forgetting to decommission a public-facing web server. It can be a hygiene lapse or a policy gap, such as granting overly permissive access rights to users for convenience.
This is why proactive testing is so critical. It’s not about blame; it’s about building resilience against the predictable patterns of human behavior. You can’t defend against an adversary until you understand what they are looking for first.
The story of a single text file compromising a network isn’t just hypothetical; it’s a prime example of the cybersecurity threats in healthcare that begin with people.
Key Takeaways:
Our security assessments combine technical testing with social engineering to help organizations identify and fix these risks before attackers exploit them. Because mistakes are inevitable, but breaches don’t have to be.
Think a forgotten text file can’t cause real damage? Think again. In Part 2, we’ll show how attackers don’t always need passwords — sometimes all it takes is an unlocked door, both digital and physical. Stay tuned for the Patient Room Hack and other real-world entry points.
In July 2025, the U.S. Department of Health and Human Services’ Office of Inspector General (HHS-OIG) released a cybersecurity audit of a large Northeastern hospital.
The findings revealed a sobering truth: even hospitals with robust defenses, like firewalls, disaster recovery, and security training, remain vulnerable if basic configuration and authentication controls are not consistently enforced.
To provide the technical testing for this audit, OIG engaged BreakPoint Labs (BPL) to conduct penetration testing, web application reviews, and vulnerability scanning under a signed Rules of Engagement. Our work demonstrated how minor weaknesses in internet-facing systems can escalate into significant risks to patient safety and data integrity.
Healthcare providers remain at the center of the cyber threat landscape.
Together, these numbers reinforce the OIG’s audit findings: healthcare is too often playing defense against adversaries who only need to find one overlooked gap.
The OIG audit validated that many of the hospital’s defenses were effective. Employees successfully resisted phishing attempts, and the web application firewall blocked most malicious traffic. However, BPL’s technical assessment identified exploitable weaknesses that highlight where hospitals remain at risk:
OIG issued five recommendations, all accepted by the hospital:
Hospitals and healthcare organizations can use this roadmap to harden their defenses quickly:
Days 0–30: Close Obvious Gaps
Days 31–60: Prove Controls in Practice
Days 61–90: Make Security Durable
As OIG’s trusted technical partner in this hospital audit, BreakPoint Labs brings proven expertise in offensive security testing tailored for healthcare environments. Our services help you proactively identify and fix the same types of vulnerabilities found in this engagement.
Our healthcare cybersecurity services include:
Cybersecurity is patient safety. Don’t wait for an audit to find your blind spots.
Request a consultation with BreakPoint Labs today, and let’s build a perimeter-hardening plan that works.
Note: This post summarizes lessons learned from an OIG audit without naming the hospital or exposing sensitive details. Recommendations are sector-wide best practices suitable for public use.
https://oig.hhs.gov/documents/audit/10493/A-18-22-08019.pdf
Finding the paths to escalate privileges in Active Directory (AD) can be challenging when dealing with a complex web of permissions, as shown in the picture above. This blog explains a method for discovering less obvious escalation paths by focusing on accounts with broad access that are not well protected (AdminCount False).
Often, during offensive engagements, you’ll find yourself with some initial access to the network, and you want to expand your access. On most networks, this can be achieved most efficiently by escalating privileges within Active Directory (AD). There are numerous ways to identify escalation paths, which generally involve identifying AD objects that are not properly protected and can perform a variety of interesting actions.
One interesting way to identify this is by analyzing the AD object attribute “AdminCount”. Microsoft leverages this attribute to apply additional protections to the object. I won’t be going over this in detail here, but you can learn more here: https://learn.microsoft.com/en-us/windows/win32/adschema/a-admincount
This value is set to either “True” or “False” with an AD object. AD objects that can do a lot of actions within the Domain are assigned a value of “True” (Example: Domain Admins, Enterprise Admins, etc.). The way I see networks is that you can divide them into two sections based on inbound permissions: objects with AdminCount: False, which allow more things to reach them, and objects with AdminCount: True, which allow fewer things to reach them.
It’s actually somewhat predictable when looking at an object’s inbound permissions. If AdminCount False, usually the same set of objects can reach it, and if it’s True, the same objects can reach it. Typically, you will not have an object with AdminCount: False that can reach an object that has AdminCount: True. If you do this, you are likely to identify new escalation paths.
When performing engagements, I often find a handful of accounts that numerous AD objects can reach due to AdminCount: False, which have excessive permissions that expose the entire domain to takeover. Generally, it’s just these few accounts that open the door for any attacker who can gain access from a lower-level object (for example, a Tier 1 help desk) and then escalate to these accounts, ultimately taking over the entire domain.
CVE-2017-8613: A good example of this common issue is with the Azure Sync account (MSOL_XXX). These accounts are frequently vulnerable to this permission abuse path because, for a considerable period, Microsoft failed to apply the AdminCount: True setting to these high-access accounts (they can dcsync by design).
https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2017-8613
https://learn.microsoft.com/en-us/security-updates/securityadvisories/2017/4033453
This same vulnerability is introduced to AD environments due to poor permission configuration. I observe this pattern in every engagement, and I wanted to share my analysis techniques to help others identify these escalation paths.
So, what I started doing on engagements is auditing all user accounts with AdminCount: False and their outbound rights. The idea is to identify accounts with lower inbound protections that can achieve a lot.
In Bloodhound, you can see this attribute in the “Node Info” tab:
You can list out all users with their AdminCount value via a simple query:
MATCH (u:User) return u.samaccountname, u.admincount Note: I find it helpful to return the admincount attribute for most of the queries. This is provided as a simple example. It’s just good context to have when analyzing various attack paths.
Now, to automate this further, we need to determine their outbound rights to find who is admincount: false and can do more in the domain, as this will find interesting escalation paths similar to CVE-2017-8613:
def get_admincountFalseUsers_trans():
with GraphDatabase.driver(URI, auth=AUTH) as driver:
result = do_query(driver, "MATCH (m:User {admincount: false}) return m.name, m.objectid, m.admincount")
admincount_outbound_file=open("admincount_false_outbound_trans_rights.txt", "w")
for record in result:
if record["m.name"]:
username = record["m.name"]
objectid = record["m.objectid"]
admincount= record["m.admincount"]
result1 = do_query(driver, "MATCH (n) WHERE NOT n.objectid='"+objectid+"' MATCH p=shortestPath((u:User {objectid: '"+objectid+"'})-[r1:MemberOf|AddSelf|WriteSPN|AddKeyCredentialLink|AddMember|AllExtendedRights|ForceChangePassword|GenericAll|GenericWrite|WriteDacl|WriteOwner|Owns*1..]->(n)) RETURN count(p)")
for record1 in result1:
if record1["count(p)"]:
trans_rights=str(record1["count(p)"])
admincount_outbound_file.write("[-] User: "+username+" Transitive Outbound Rights: "+trans_rights+" Admincount: "+str(admincount)+"\n")
admincount_outbound_file.close()
with open("admincount_false_outbound_trans_rights.txt", "r") as fp:
entries = str(len(fp.readlines()))
print("[+] Generating a List of Users with AdminCount=False Transitive Outbound Rights: admincount_false_user_outbound_trans_rights.txt ("+entries+") lines")The code snippet is pulled from AD-RECON; it will retrieve a list of users with AdminCount: False and then gather the numerical value associated with their transitive outbound rights. Then I will sort the output with bash because I failed to produce the output sorted in Python; maybe I will change that, but for now, just do the following:
```
└─$ cat admincount_false_outbound_trans_rights.txt| sort -k 7,7 -nr | less -S
``` This will sort the output based on the 7th element in the line, which is the numerical count for the transitive outbound rights in reverse numerical order (so highest rights on top):
```
[-] User: MSOL_F367GGD8CDD8@ORGRIMMAR.ORG Transitive Outbound Rights: 43848 Admincount: False
[-] User: acct1@ORGRIMMAR.ORG Transitive Outbound Rights: 43847 Admincount: False
[-] User: passreset@ORGRIMMAR.ORG Transitive Outbound Rights: 43847 Admincount: False
[-] User: domainjoin@ORGRIMMAR.ORG Transitive Outbound Rights: 43847 Admincount: False
[-] User: carol@ORGRIMMAR.ORG Transitive Outbound Rights: 43847 Admincount: False
...
``` The result is output that quickly identifies accounts with lower inbound protections, which can lead to various consequences. Now, all these aren’t always exactly the problem themselves, so you must look at the actual transitive outbound rights for these objects to see how they’re getting their permissions. When you do this, you’ll see there are a handful of accounts ending up in this graph that are allowing these lower-level Admincount: False accounts to do a lot of things.
Example: Since the MSOL account can dcsync and essentially take over the domain, and its Admincount is false, the “passreset” account can change its password and thus has an escalation path to take over the domain. Had the MSOL account been adequately protected with AdminCount set to True, this escalation path might not have existed. On most networks, you will find that the MSOL account is a problem, but it is not the only account that extends permissions up to higher-level AD objects.
Another example we often see is that the account used to add computers to the domain may not be properly configured and may not have permissions over the Domain Controllers (such as WriteAccountRestrictions and Owns), which creates a potential escalation path. See, getting to the domain controllers might be hard, but because the AdminCount: False for the “domainjoin” account, you just need to get any account that can reset a password (example, a Tier 1 help desk), and then take over the domainjoin account, and then the Domain Controllers.
When diving deep into AD, as in this case, you can discover numerous additional escalation paths to enhance security, not just the one initially required to achieve the desired access. Please note that on a Red Team, this might not be the primary goal, but for a penetration test (PenTest), it’s beneficial to include as many escalation paths as you can identify.
Andrew McNicol is the Chief Technology Officer and a co-founder of BreakPoint Labs, where he oversees the company’s technical strategy and manages the Cybersecurity Assessments line of business. He is a recognized expert in adversarial penetration testing, with more than 15 years of experience leading numerous technical teams on red team operations, vulnerability assessments, and penetration testing engagements to achieve each client’s specific objectives. Andrew holds numerous professional certifications and is a frequent speaker at government and industry security forums.
