HL735TER: An Open Source Burp Suite Extension for HL7 Penetration Testing

HL735TER: An Open Source Burp Suite Extension for HL7 Penetration Testing

In the world of web application security, we’d be lost without tools like Burp Suite. The ability to intercept, analyze, and manipulate HTTP traffic is fundamental to our work. But the moment an engagement drifts into healthcare, the comfortable terrain gives way to HL7 v2 – the pipe-and-caret messaging standard that HL7 International itself calls the workhorse of clinical electronic data exchange, used by roughly 95% of US healthcare organizations and in more than 35 countries.

The trouble is that HL7 v2 is nearly unreadable raw. A real message looks like this:

MSH|^~\&|TestLIS|TestFacility|XXXXX|XXXXX|20250917133407||OML^O21^OML_O21|…

Counting pipes to find the field you want to tamper with is exactly the kind of manual, error-prone grind we thought we’d left behind. Pentesters working in healthcare face a familiar frustration: a patchwork of scripts, limited-feature tools, and a lot of manual effort to achieve the visibility and control we take for granted with HTTP. We’ve been there. That’s why we built HL735TER.

Today, we’re excited to announce that we are open-sourcing it for the security community.

HL735TER is a Burp Suite extension, written in Python/Jython, designed by pentesters, for pentesters. It teaches Burp to read, edit, and fuzz HL7 v2.x messages natively – turning an opaque blob into a clean, labelled, attackable structure.




What Is HL735TER?

HL735TER is an open source Burp Suite extension for penetration testers assessing applications and APIs that process HL7 v2 messages. It detects raw or JSON-embedded HL7 traffic, converts the message into readable and editable JSON, and reconstructs the HL7 message after changes are made.

The extension also integrates with Burp Intruder by identifying HL7 fields, components, sub-components, repetitions, and empty insertion points as potential payload positions. Its custom payload generators help security testers evaluate patient identity controls, message routing, order processing, healthcare codes, field boundaries, separators, and other HL7-specific attack surfaces.

HL735TER at a Glance

CapabilityWhat It Provides
HL7 detectionIdentifies raw and JSON-embedded HL7 v2 messages
Structured viewingConverts HL7 segments and fields into labelled JSON
Message editingAllows testers to change HL7 values by field name
Message reconstructionConverts edited JSON back into valid HL7
Burp Repeater supportEnables targeted manual testing of HL7 requests
Burp Intruder supportAutomatically identifies meaningful fuzzing positions
Custom payload generatorsProvides ten HL7-specific payload sets
JSON-safe payload handlingEscapes payloads so the surrounding JSON remains valid



How HL735TER Builds on HL7Magic

Before we go further, credit where it is richly due. The idea of bringing HL7 inside Burp and editing it as JSON was pioneered by [HL7Magic](https://github.com/WithSecureLabs/hl7magic), a Burp Suite extension by Katie Inns (@J3lly____), presented at DEF CON 31 (2023). HL7Magic proved the approach: built on the hl7apy library, it parses an HL7 message, converts it to human-readable JSON, lets the tester edit it, and converts it cleanly back to HL7. It is open source under Apache-2.0, and it remains the reference for intercepting raw MLLP traffic – the native, non-HTTP transport HL7 v2 has used for decades. Because MLLP is a plain TCP protocol, HL7Magic is designed to run alongside mitm_relay, with Burp configured for Jython, so the TCP stream gets pulled into Burp’s orbit.

HL735TER extends that work and steps in a different, increasingly common direction. Modern healthcare integrations are dragging HL7 onto the web: clinical messages now routinely ride over HTTP(S), embedded as a JSON string field on a REST API – “hl7_message”:”MSH|^~\&|…”. That is squarely native Burp territory – no mitm_relay, no TCP relay, no Jython gymnastics to capture the traffic. But Burp still shows that embedded HL7 as a meaningless string. HL735TER fills that gap, and then pushes the idea further into a full, systematic testing workflow.




Why We Built HL735TER for Healthcare API Testing

The story of HL735TER begins, as many security tools do, during a client engagement. We were assessing a healthcare integration platform – a REST API quietly ingesting laboratory orders and ADT (admit/discharge/transfer) feeds from upstream systems. The HL7 wasn’t on a classic MLLP port at all. It arrived as a JSON-embedded string in the body of an ordinary POST, and the API happily answered 201 Created.

A POST to a staging healthcare API; the body is JSON with an embedded raw HL7 string, response 201

On paper this was a dream: the traffic was already flowing straight through Burp Proxy. In practice, every request body was a wall of pipes and carets buried inside a JSON envelope. We wanted to flip a single patient identifier, retarget a sending facility, change an order control code – and we were squinting at the screen counting delimiters to find the byte we needed.

HL7Magic was the obvious reach, but it is built for the MLLP/mitm_relay path; here there was no raw TCP stream to relay, just HTTP that Burp already owned. So we went back to the drawing board and built the tool we wished we’d had: one that lives entirely inside Burp, reads HL7 wherever it hides, and makes the whole message a first-class testing target.




Convert Raw HL7 Messages into Readable JSON

The first job is simply seeing the message. HL735TER registers a message editor tab factory, so an “HL7 JSON” tab appears in any Burp editor – Proxy, HTTP history, Repeater, Intruder – the instant it detects HL7. Detection works on raw messages (MSH|^~\&) and on JSON-embedded ones, recognizing the common carrier fields hl7_message, hl7Message, and message.




Select that tab, and the wall of delimiters becomes readable, indented JSON.

The same Proxy request rendered in the HL7 JSON tab: labelled fields like Field Separator, Sending Application, Patient Name

You get a top-level info block – message version, message type, and a plain-English description like “Laboratory Order Message” – followed by each segment with its own description (“Message Header”, “Patient Identification”, “Specimen”). Every field carries its HL7 id, a human-readable label (“Sending Application”, “Patient Name”, “Patient Identifier List”), the data itself, and its parsed repetitions and components. HL735TER understands the common HL7 v2.x message families – ADT, OML, ORU, ORM, ACK, and friends – so the labels are meaningful, not generic.




Edit HL7 Fields Directly in Burp Repeater

Reading is half the battle; the real work is tampering. The “HL7 JSON” tab isn’t just a viewer – it’s editable. Drop the request into Repeater and you can modify the structured, clearly-labelled JSON instead of hunting through a raw line. Change a patient identifier, an assigning authority, or an order control code by editing the field that literally says so.

Repeater holding the HL7 request with a 201 response
The editable HL7 JSON tab in Repeater, showing segments and labelled fields ready to modify

On send, HL735TER does the unglamorous-but-essential plumbing: it converts your edited JSON back into a valid HL7 message, preserves the original escaping convention (literal \r versus an actual carriage return), re-embeds the message into the JSON body exactly where it found it, and fixes the `Content-Length` automatically so the server never even blinks. Targeted tampering that used to mean fragile, hand-counted hex edits becomes: change a labelled value, hit Send.




Send HL7 Messages to Burp Intruder Automatically

This is where HL735TER stops being a convenience and becomes a fuzzing platform. Right-click any request with HL7 in it and you get two options under Extensions → HL735TER: “Test HL7 Detection” (which prints the detected message to the extension output for a quick sanity check) and “Send to Intruder (HL7 configured)”.

The right-click context menu showing Send to Intruder (HL7 configured) and Test HL7 Detection

That second option does not just dump the request into Intruder and leave you to mark positions by hand. It parses the HL7 structure and pre-marks every meaningful injection point for you, calling Burp’s sendToIntruder with computed payloadPositionOffsets so the positions arrive already configured.

Crucially, the marking is hierarchical. For a field like PID.3, HL735TER doesn’t just mark the whole field – it marks the components (^), sub-components (&), and repetitions (~) within it, plus automatic insertion points for empty fields (||), empty components (^^), and empty sub-components (&&):

PID.3 = 12345^^^HOSPITAL&1.2.3.4.5&ISO^MR

  Field level:         [ 12345^^^HOSPITAL&1.2.3.4.5&ISO^MR ]
  Component level:     [12345] [^^] [HOSPITAL&1.2.3.4.5&ISO] [MR]
  Sub-component level: [HOSPITAL] [1.2.3.4.5] [ISO]
  Empty insertion:     [||]  [^^]  [&&]

The philosophy is deliberately penetration-test-maximal. Only MSH.1 (the field separator) and MSH.2 (the encoding characters) are protected, because tampering with those breaks parsing outright. Everything else – across MSH, PID, PV1, OBX, ORC, OBR, SPM, EVN, NTE, AL1, DG1, MSA, RXE, RXR, TXA – is fair game. A typical message yields 100+ ready-to-fuzz positions. Offsets are validated and de-overlapped first (Burp rejects overlapping positions), and if anything goes sideways, the extension falls back gracefully to simple field-level marking. And because it computes those offsets inside the JSON string when the HL7 is embedded, it works just as well on your web-API target as on a raw message.




Ten HL7-Specific Intruder Payload Generators

Marked positions are only as good as what you fire at them. HL735TER registers ten custom Intruder payload generators, selectable straight from Intruder’s payload generator dropdown:

Intruder Payloads tab with HL7 positions marked and the HL7 payload-generator dropdown open
  • HL7 Buffer Overflow – length-based attacks against field size limits
  • HL7 SQL Injection (Safe) – non-destructive, information-gathering only
  • HL7 XSS Attacks – for the web interfaces that render these records
  • HL7 Format Strings – memory-corruption probes
  • HL7 Separator Elements – abuse of the ^ ~ \ & | structure itself
  • HL7 Unicode Attacks – encoding and normalization bypasses
  • HL7 Healthcare Context – medical terminology, codes, providers, timestamp test values
  • HL7 Special Characters – reserved strings and edge cases
  • HL7 Authority Spoofing – impersonating sending/receiving systems, OID and assigning-authority manipulation
  • HL7 Component Attacks – component/sub-component injection, empty-component exploitation, integer-boundary cases

Collectively, that’s a couple hundred payloads. The single most important detail: every payload is automatically “JSON-safed.” Backslashes, double-quotes, CR, LF, and tabs are all escaped on the way out, so a payload survives intact even when the HL7 it’s attacking lives inside a JSON string. You can fuzz JSON-embedded HL7 without ever breaking the surrounding envelope – the exact problem that sent us down this road in the first place. (There’s also an HL7 Context Processor registered as an Intruder payload processor; today it’s a pass-through hook, there for the workflows to come.)




HL7 Security Tests Supported by HL735TER

Map those positions and payloads onto the HL7 field structure and the attack classes fall out naturally:

  • Patient-identity attacks – PID.3 assigning-authority spoofing, identifier-type confusion, cross-patient access
  • Message-routing attacks – MSH.3-6 sender/receiver spoofing and redirection
  • Message-type confusion – MSH.9
  • Processing-control bypass – MSH.11
  • Order-control manipulation – ORC.1-3
  • Medical-code injection – ICD-10, CPT, LOINC

This isn’t theoretical. HL7 v2 was built for a trusted hospital LAN: it travels in cleartext, has no built-in authentication, and offers no tamper detection (an ACK confirms receipt, not integrity). Researchers have been ringing this bell for years – Black Hat USA 2018’s “[Pestilential Protocol](https://i.blackhat.com/us-18/Thu-August-9/us-18-Dameff-Pestilential-Protocol-How-Unsecure-HL7-Messages-Threaten-Patient-Lives-wp.pdf)” demonstrated faking a diabetic-ketoacidosis lab result and altering a medication order into a 10x overdose live over HL7, and Katie Inns’s DEF CON 31 work brought the same lessons into Burp. As more of this traffic moves onto HTTP and REST, the blast radius only grows – and so does the need to test it the way we test any other web target.

Every payload HL735TER ships is deliberately non-destructive – no DROP, no DELETE, no filesystem damage – so the bundled set is suitable for safe testing against live-ish healthcare environments where a clumsy payload is genuinely not an option.




HL735TER Requirements and Compatibility

Before installing HL735TER, confirm that your testing environment includes:

  • Burp Suite Professional for the custom Intruder payload generators
  • Python and Jython support enabled in Burp Suite
  • HTTP or HTTPS traffic containing raw or JSON-embedded HL7 v2 messages
  • Authorization to test the healthcare application, integration, or environment

HL735TER is designed primarily for HL7 messages already traveling through HTTP-based application traffic. Testing traditional raw MLLP traffic may require a relay-based workflow such as the one supported by HL7Magic.




Download HL735TER on GitHub

We believe HL735TER fills a real and growing gap: the case where HL7 has left the MLLP wire and ridden into your Burp Proxy inside a JSON body, with no native way to read, edit, or fuzz it. It was born from a real engagement and refined into a full Burp-native testing workflow – automatic detection and readable rendering across Proxy, Repeater, and Intruder; structured JSON editing that round-trips back to valid HL7; HL7-aware Send-to-Intruder marking that hands you 100+ positions; and ten HL7-specific, JSON-safe payload generators.

HL735TER needs Burp Suite Professional for the custom Intruder payload generators, and Python/Jython support enabled in Burp.

You can find the project, with full documentation and examples, on our [GitHub](https://github.com/VerSprite/HL735TER/). We welcome your feedback, feature requests, and contributions!.




Frequently Asked Questions About HL735TER

What is HL735TER?

HL735TER is an open source Burp Suite extension developed for penetration testing applications and APIs that process HL7 v2 messages. It converts raw or JSON-embedded HL7 into readable, editable JSON and supports structured testing through Burp Repeater and Intruder.

What problem does HL735TER solve?

Raw HL7 v2 messages are difficult to read and manipulate because their fields, components, repetitions, and sub-components are separated by characters such as pipes, carets, tildes, and ampersands. HL735TER labels that structure so testers can work with named fields rather than manually counting delimiters.

Can HL735TER test HL7 embedded inside JSON?

Yes. HL735TER detects HL7 carried inside common JSON fields, including hl7_message, hl7Message, and message. It can extract the HL7 content, display it as structured JSON, and reinsert the modified message into the original request.

Does HL735TER work with Burp Repeater?

Yes. Testers can edit the structured HL7 representation in Burp Repeater. When the request is sent, HL735TER converts the edited content back into HL7, preserves the original escaping convention, and updates the HTTP content length.

Does HL735TER integrate with Burp Intruder?

Yes. HL735TER can send a detected HL7 request to Intruder with meaningful payload positions already identified. Depending on the message structure, these positions may include complete fields, components, sub-components, repetitions, and empty insertion points.

What types of HL7 security testing does HL735TER support?

HL735TER can support testing for patient identifier manipulation, assigning-authority spoofing, sender and receiver manipulation, message-type confusion, processing-control bypass, order-control manipulation, medical-code injection, separator handling, Unicode edge cases, and field-length problems.

Are the included HL735TER payloads destructive?

The included payload generators are designed to be non-destructive. They avoid destructive database and filesystem operations, but testers must still use the extension only within an authorized scope and follow the safety requirements of the environment being assessed.

Is HL735TER a replacement for HL7Magic?

No. The tools address related but different testing workflows. HL7Magic remains relevant for raw MLLP traffic routed into Burp through a relay. HL735TER focuses on raw or JSON-embedded HL7 that is already traveling through HTTP or HTTPS traffic handled by Burp.

Does HL735TER require Burp Suite Professional?

Burp Suite Professional is required to use HL735TER’s custom Intruder payload generators. Python and Jython support must also be enabled in Burp Suite.

Where can I download HL735TER?

HL735TER is available from VerSprite’s GitHub repository with its documentation and examples.