The Exploit We Chose Not to Run

By the second day of a recent internal penetration test, we had a working path to a host we could have taken over with a single unauthenticated exploit, and a route to the jump servers that guard a medical-device manufacturer’s plant floor. We ran neither all the way.

That was not caution for its own sake, and it was not a limit on our skill. It was the job done correctly. The most useful thing we can say about that engagement is not how far we got. It is where we chose to stop, and why stopping proved the point better than pressing would have.

A vulnerability you do not need to detonate to prove

One of the hosts on the network was an old Windows server, years past the end of its support, still running a legacy file-sharing protocol. It tested vulnerable to MS17-010, better known as EternalBlue: a flaw that lets an attacker take full control of a machine with no credentials and no user interaction. It is the same flaw that powered the WannaCry and NotPetya outbreaks of 2017, which together did billions of dollars of damage and shut down hospitals mid-shift. (Microsoft’s bulletin MS17-010 and the public advisories on those outbreaks, including CISA’s on WannaCry, document it in detail.)

We did not fire the exploit. We did not need to, and firing it would have been reckless.

We did not need to because the vulnerability check is reliable on its own. Confirming that a host is exposed to EternalBlue does not require setting off EternalBlue. The check tells us, and it tells the client, everything the report needs to say: this machine is exploitable, here is the proof, fix it.

Firing it would have been reckless because EternalBlue is not a gentle exploit. It manipulates memory in the operating system’s core, and when it misses it does not fail quietly. It crashes the machine. This was likely production hardware inside a medical-device manufacturing environment. A blue-screened server there is not an inconvenience. It can be a stopped production line, a batch record broken in the middle, a safety and regulatory problem that lands on people who had nothing to do with the test. The risk was entirely ours to avoid, so we avoided it.

The line at the plant-floor door

The same judgment call came up in a larger form at the boundary of the operational-technology (OT) zone, the segmented network that runs the physical manufacturing systems.

The full story of how we reached it is in the flagship writeup of this engagement. The short version: we had gained Domain Admin-equivalent control of the corporate Active Directory forest, and the OT systems shared that same forest, so our rights already counted as OT administrator rights by design. On top of that, the OT jump hosts, the controlled gateways into the plant floor, answered network requests from the corporate side.

Neither half of that took an exploit. The foothold came from credentials sitting in a readable git repository, and the escalation came from privileged access nobody had counted. Two ordinary misconfigurations, and we were standing at the door of a manufacturing plant with valid credentials. That is precisely why the stop conditions matter: the further in you get without breaking anything, the more it costs to be careless at the end.

We proved two things and then stopped. We proved the OT bastions were reachable from the ordinary IT network, which they should not have been. And we proved our credentials were valid against them. That is the entire exposure: the systems that run manufacturing were reachable from a compromised corporate network, and they fell within access we already held.

We did not log in to a plant-floor system. We did not interact with a single manufacturing control. That step was withheld for a separate, explicit authorization and a coordinated window with the client’s OT team, because the stakes on the other side of that door are patient safety and regulatory compliance, not data. Interactive access to a live control system is something you arrange carefully, with the people who run it in the room, or you do not do at all. The exposure was fully demonstrated without it.

Why restraint is the feature, not the limitation

There is a version of penetration testing that treats maximum damage as maximum proof. Pop the box, crash the service, screenshot the wreckage. It makes for a dramatic report and a bad partnership.

The purpose of a test is to show you your risk without becoming the incident. A finding that says “this host is exploitable, here is the confirmation, here is the fix” protects you. A finding that says “this host was exploitable, and we know because we knocked it over during business hours” has handed you an outage and called it a service. The first is the work. The second is a tester enjoying themselves at your expense.

Knowing where that line sits comes from having been responsible for the systems on the other side of it. Deciding not to fire EternalBlue at production medical hardware, and not to touch a live manufacturing control without the OT team’s explicit sign-off, is not a gap in the assessment. It is the assessment being run by people who understand what these systems do when the test is over and the plant is still making product.

What proof without impact looks like

“Prove it without breaking it” sounds like a slogan until you see what the evidence actually is. Strong findings do not depend on causing the damage. They depend on documenting the conditions that make the damage possible.

For the vulnerable server, the proof is the version, the exposed protocol, and the vulnerability check that confirms the flaw, captured and dated. That is enough for the client to act and enough for an auditor to accept. Firing the exploit would add a crashed production machine and no new information.

For the path to the plant floor, the proof is the network route and the credential validity: the OT gateways answered from the corporate network when they should not have, and the access we already held was valid against them. Documenting reachability and held privilege demonstrates the exposure in full. Logging in to a live control system would add real operational risk and, again, tell the client nothing they did not already know from the two facts we captured.

This standard matters most in environments that are regulated and change-controlled, where an unplanned reboot or a modified system can break a validated process and create a compliance problem on top of the operational one. In those settings, a tester who defaults to demonstrating exposure rather than exploiting it is not being timid. They are working under the same constraints the client’s own engineers do every day, which is exactly why the client can trust the result.

What to ask of anyone testing near production

If your environment includes systems that cannot simply be rebooted, manufacturing lines, medical devices, OT and industrial control systems, clinical infrastructure, then how a tester handles restraint is not a soft question. It is a core competency. Before you hand anyone a foothold, get clear answers on a few things.

• Rules of engagement in writing. What is in scope, what is explicitly out, and what the stop conditions are. It should be agreed before anyone starts, not negotiated after something breaks.
• A non-destructive standard of proof. For safety-critical systems, the default should be to demonstrate exposure (reachability, valid credentials, confirmed vulnerability) without exploiting it. Ask how they prove a finding without causing the impact.
• OT handled as its own boundary. Interactive testing of control systems should require separate authorization and a coordinated window with the people who operate them. A tester who treats the plant floor like just another subnet is telling you something.
• Awareness of the blast radius. The right question before any action is not only “can I do this?” but “what happens to the business if this goes wrong, and is that risk mine to take?”
• Evidence your own team can check. A good finding is reproducible. The tester should hand you proof you can verify and retest after you fix it, not a story you have to take on faith.

We got a long way into this environment. We reached the corporate directory, the second domain, systems in another country, and the doorstep of the plant floor. The client was genuinely surprised by how far a single foothold traveled. And the part they valued most, the part that made them trust the finding, was that we drew the exposure in full and did not break anything to do it.

That trust is not a soft benefit. It is what lets a client hand a tester real access to real systems, which is the only way a test reflects real risk. A team that has to wall off its most important systems from the testers to feel safe ends up testing everything except what matters most.

That is the standard. Prove the risk, protect the business, and know exactly where to stop. If that is the kind of penetration testing you want near your production and OT systems, whether you run a manufacturing plant or healthcare infrastructure, we should talk.