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.
Artificial-intelligence workloads – whether a multimodal LLM chatbot, a computer-vision pipeline, or an autonomous decision engine – behave very differently from classic software. They ingest massive, often shifting data sets, invoke outside services, and keep learning as they run. Those traits open fresh attack surfaces, from prompt manipulation to model exfiltration, that traditional security testing rarely touches. BreakPoint Labs has refined a methodology for AI penetration testing and red teaming that exposes genuinely exploitable weaknesses in AI systems and, crucially, translates them into business-level risk that the customer can act on.
Any effective assessment begins by drawing the boundaries of the digital terrain. Through conversations with asset owners, we define every component to be assessed: model endpoints, plug-ins, vector or RAG stores, fine-tuning pipelines, orchestration agents, and any other AI-related technologies. Scoping this correctly at the outset ensures that components that might expose you to risk won’t slip through the cracks.
Next, we explore adversaries and likely attack paths that match the customer’s risk profile. A rogue insider with privileged MLOps access, a well-funded nation-state, a competing vendor armed only with the public API, or a hobbyist jailbreak enthusiast each brings different tactics and constraints. By making those assumptions explicit, we avoid the common mismatch in which testers probe vulnerabilities that an actual attacker would never reach, or miss the ones that keep CISOs awake at night.
Finally, we set measurable success criteria. A privacy-focused healthcare client may care most about coercing a model to leak protected health information, whereas a university might worry about its public-facing AI services being exploited to gain internal access.
Passive research often uncovers more than clients expect. Public model cards might reveal the date weights were last updated or hint at third-party data sources; GitHub commits can expose access tokens left in a forgotten notebook. Documentation from academic papers sometimes lists hyper-parameters that make gradient-inversion attacks easier.
Collaborative discovery sessions are usually recommended. Sitting down with MLOps and DevSecOps engineers, we trace data lineage from raw collection to fine-tuning to inference, noting where sensitive inputs flow back into training.
Active enumeration rounds out the picture. We explore what is accessible from various vantage points, system and application information that can be gathered unauthenticated, and any other details an attacker could use maliciously. This discovery paints a realistic picture of what a potential attacker sees and what their next steps might be.
Automation gives us breadth. We fire up PyRIT and garak to orchestrate prompt injection and jailbreak attacks, at a scale no human could match. For pure prompt mutation, FuzzLLM stitches together template-based attacks, rapidly testing thousands of structural variations to find novel jailbreaks that slip past naive guardrails. When the target includes vision, audio, or tabular ML components, IBM’s Adversarial Robustness Toolbox (ART) generates perturbations, poison samples, and extraction queries tailored to each modality.
Automated runs are not a scoreboard; they are a sensor network. Initial findings feed the queue for human follow-up and confirmation.
Automation sketches the outlines; skilled operators color them in. A prompt that convinces the model to echo a single internal variable, for instance, can be expanded into a multi-turn jailbreak that exfiltrates the entire system, prompt, API keys, or confidential user data. A minor encoding leak might escalate into full remote code execution if an LLM, equipped with function-calling, can be persuaded to write an arbitrary Bash script that the orchestrator helpfully runs on the host.
Manual work also excels at chained attacks. Suppose reconnaissance shows that user-generated PDFs are fed into a vector store for semantic search. We craft a malicious PDF whose text embeds an indirect prompt injection. Once ingested, the user simply asks a normal question; the retriever surfaces our payload, and the model executes instructions that bypass the front-end filter, sending the conversation history to an external URL. Because this crosses storage, parsing, embedding, retrieval, and inference layers, no single automated tool would exercise it end-to-end.
This targeted manual testing combines with attacker knowledge and customer information to accurately assess and define risk and possible impact. Standards like the OWASP LLM Top 10 can be applied to synthesize current security posture. Mapping exploits back to MITRE ATLAS and the traditional MITRE ATT&CK matrices helps security teams slot each finding into a familiar defensive playbook.
Checking boxes is not enough; customers need to see how an attacker would actually weave techniques into a campaign. We therefore design narrative scenarios specific to the customer and environment.
These scenarios help accurately define risk and assess defense-in-depth capabilities, as well as develop thorough attack surface understanding. Preparation here leads to better detection and response when the bad guys do come around.
The final report begins with an executive narrative, transitions into a high-level analysis of the tested components, and delves into each vulnerability, detailing what we did, what the model did, and why it matters. Most importantly, we include tailored fixes and provide free remediation testing once implemented.
We close with interactive out-briefs, where red-teamers and client engineers review key exploits, discuss mitigations, and assess risk and potential impact. Customers leave not only with a list of vulnerabilities but also with prioritized and practical fixes and improvements.
By the end of this process, organizations understand exactly how an adversary can penetrate, pivot, and profit from their AI stack. They receive fixes that align with their architecture and risk appetite, not generic best-practice slides. Most importantly, they gain the confidence to innovate with AI, knowing their systems have already survived the sort of focused, creative abuse that attackers are perfecting right now.
AI penetration testing is a structured security assessment that identifies exploitable weaknesses in AI systems, including large language models, computer vision pipelines, and autonomous decision engines. Unlike traditional penetration testing, it addresses AI-specific attack surfaces such as prompt injection, model exfiltration, data poisoning, and jailbreaking.
Prompt injection is an attack where malicious instructions are embedded in content that an AI model processes. The model interprets those instructions as legitimate commands and follows them. It is classified as LLM01 in the OWASP Top 10 for Large Language Models and represents one of the most direct attack paths against AI systems that process user-controlled input.
We use PyRIT and garak to orchestrate prompt injection and jailbreak attacks at scale. For prompt mutation, FuzzLLM tests thousands of structural variations to find novel jailbreaks. For vision, audio, and tabular ML components, IBM’s Adversarial Robustness Toolbox generates perturbations, poison samples, and extraction queries tailored to each modality.
Automated testing provides breadth, running thousands of attack variants to identify potential weaknesses quickly. Manual testing provides depth. A skilled operator can take a single finding from automated testing and expand it into a multi-turn attack that exfiltrates system prompts, API keys, or confidential data. Chained attacks that cross multiple layers, such as storage, parsing, retrieval, and inference, require manual testing because no single automated tool exercises them end to end.
RAG stands for Retrieval-Augmented Generation. It is a technique where an AI model retrieves relevant content from a data store to inform its responses. Attackers can target RAG systems through indirect prompt injection, embedding malicious instructions in documents that get ingested into the vector store. When a user asks a normal question, the retriever surfaces the payload and the model executes the attacker’s instructions.
We map findings to the OWASP LLM Top 10, MITRE ATLAS, and the traditional MITRE ATT&CK framework. This allows security teams to slot each finding into a familiar defensive playbook and prioritize remediation based on their existing processes.
Clients receive a report with an executive narrative, a high-level analysis of tested components, and detailed vulnerability write-ups covering what was tested, what the model did, and why it matters. Each finding includes tailored remediation guidance. We also provide free remediation retesting once fixes are implemented and conduct interactive out-briefs with the engineering team.
Ray Blasko is the Technical Director for offensive operations at BreakPoint Labs and a Red Team Operator for a DoD-certified Red Team, responsible for assessing and securing critical ICS/SCADA assets. He is recognized as a subject matter expert in both attacking and defending IT and OT environments, and he excels at resolving the technical and strategic issues that arise in protecting critical infrastructure. Ray holds numerous professional certifications and regularly presents at DoD Red Team conferences, trade conventions, and information security events.
