DICOMHawk: A Cyber Deception Framework for Medical Imaging Infrastructure
Karina Elzer1 , Alberto Mongardini1 , Ricardo Yaben1 , Georgios Theodoridis2 , Alexandra Babanuta1 , Nawras Mouala1 and Emmanouil Vasilomanolakis1 1 Technical University of Denmark, 2 CSIS [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
arXiv:2607.15754v1 [cs.CR] 17 Jul 2026
Abstract Cyber-attacks against exposed healthcare infrastructure threaten sensitive patient data and clinical operations, yet existing defensive tools for DICOM-based medical imaging systems provide limited interaction and are easily fingerprinted. We introduce DICOMHawk, a cyber-deception framework that emulates DICOM and PACS services using realistic interactions, dynamically populated medical records, and embedded honeytokens. In an 86-day comparison and a 347-day deployment across multiple networks, DICOMHawk attracted more valid sessions than Dicompot, avoided honeypot detection, and captured 49 medical-related attacks. The results show that realistic, long-term, multi-location deception improves visibility into threats targeting medical imaging systems. Keywords: deception, honeypot, DICOM, medical
1.
Introduction
Cyber-attacks against exposed critical systems continue to increase, causing severe disruptions and posing direct threats to public safety Coventry and Branley (2018). Healthcare systems are no exception; they are becoming increasingly attractive targets. In Europe, health-sector incidents already exceed 300 Commission (2025), while the US reports more than 710 large data breaches in 2025 alone Alder (2026). Most of the reported incidents in the media stem from vulnerabilities in exposed web applications and poor security hygiene in remote access services Cartwright (2023). However, the attack surface of healthcare institutions is far larger, consisting of interconnected Hospital, Clinical, Laboratory, and Radiology Information Systems (HIS, CIS, LIS, RIS) to
manage Electronic Health Records (EHRs). In this study, we focus on RIS, with particular emphasis on the DICOM (Digital Imaging and Communications in Medicine) protocol and the systems used to archive medical images: DICOM viewers and workstations, Picture Archiving and Communication System (PACS), and modality equipment. Recently, Yazdanmehr (2023) revealed the exposure of nearly 4,000 DICOM-speaking devices accessible over the Internet without security controls and holding over 43.5 million patient records. Our work is motivated by the discrepancy between the sensitivity of the data handled by DICOM, the optional nature of most of its security features “DICOM Security” (2026), and the potential reach of this issue. While significant efforts have been made to harden the security of DICOM and the services relying on it Eichelberg et al. (2020), the work on detecting and studying attack patterns—both ongoing and new—is severely limited. Ihanus and Kokkonen (2020) propose the use of honeypots to enhance the cybersecurity of medical imaging systems, emphasizing their ability to detect cyber threats with a low false-positive rate. The authors recommend deploying honeypots in healthcare networks to provide information about distinct attack phases. The few existing examples covered in the literature rely mainly on threat intelligence from Dicompot (DP)1 , a low-interaction DICOM honeypot. However, DP offers limited interaction and can be detected reliably, defeating the purpose of the honeypot. This paper introduces DICOMHawk (DH), a deception framework to emulate DICOM and PACS services. In DH, attackers can interact with medical images injected with honeytokens using regular DIMSE operations, and upload their own images/malware. 1 https://github.com/nsmfoo/dicompot
After nearly a year of deployment, DH has not been identified as a honeypot by any major Cyber Threat Intelligence (CTI) service. This study presents a unique perspective on ongoing threats to healthcare systems by comparing DH and DP, and by year-long observations of interactions and attacks involving DH across multiple networks. Our contributions are as follows: • We propose DICOMHawk (DH), a deception framework to emulate DICOM and PACS services. DH offers more interaction capabilities than Dicompot (DP), includes publicly available, anonymized medical images, and injects them with honeytokens to trace attackers back. We release our implementation as an open-source repository2 . • We conduct a comparison between our framework and the current state-of-the-art DP during an 86-day period. Overall, DH attracted more sessions and DIMSE-C commands than DP. • Additionally, we conduct a long-term measurement (347 days) of ongoing medical attacks in the wild using DH both in cloud and local networks. Our pseudo-anonymized dataset is openly accessible via Elzer et al. (2026). This paper is organized as follows. Section 2 reviews the literature and motivates our work. Section 3 introduces DH’s architecture, design, and features. Section 4 details our experimental setup, deployment location, and data collection period. Section 5 compares observations across DH and DP deployments. Section 6 analyzes results over the full collection period using DH. Section 7 provides an overview of the main differences between honeypots and deployments, their limitations, and future work. Section 8 concludes this paper.
2.
Related Work
Deception technologies, such as network telescopes and honeypots, are widely used for threat monitoring, as described by Beltrán-López et al. (2026); however, healthcare-specific literature remains scarce. In this space, DP stands out as the primary DICOM honeypot with the richest set of features, mimicking the behavior of an exposed DICOM workstation. However, DP presents several limitations that challenge its main purpose. DP only implements a subset of the available DICOM Message Service Element (DIMSE) operations and is not compliant with the DICOM standard, as it refuses to share implementation details during the 2 https://github.com/honeynet/DICOMHawk/tree/v2.0
association process. Lacking further configuration options to simulate other devices and systems, these two characteristics limit interactions with the honeypot and make it easily identifiable: attackers only need to verify the association messages for missing fields or attempt to store arbitrary binaries in the honeypot to confirm its identity. Saputra et al. (2025) extend DP with a PACS server, full DIMSE support, and a decoy authentication web page. Their evaluation was conducted via simulation and a three-month deployment (May–July 2025), capturing 14,831 logs, but no DIMSE commands. However, this study presents several limitations: i) source code is never shared, ii) there is no deployment comparison with the original honeypot to evaluate the impact of their enhancements, iii) the honeypot remains not compliant with the DICOM standard, iv) the website does not resemble DICOM software, and v) analysis on the web interface is superficial, making it challenging to understand whether attackers were targeting radiology systems in particular, or the correlation between observations is merely an artifact of larger scans. Bhargavi et al. (2019) deployed a decoy database with DICOM honeyrecords for anomaly detection, logging any manipulation. However, the framework was evaluated solely via cloud simulation rather than a real-world deployment. There are also few studies on deception systems related to other healthcare and medical systems. Bythwood et al. (2023) used honeypots—including DP—to monitor 14 protocols, in a university network over one month in 2022, capturing 61 sessions and unquantified C-FIND commands. However, the broad protocol diversity limits their depth of analysis and comparative insights regarding specialized medical threats. Moreover, Wang et al. (2022) created and deployed 462 lightweight Internet of Medical Things (IoMT) honeypots across 22 countries to collect large-scale botnet data, primarily focusing on a novel attack-pattern categorization method. Lastly, Shah et al. (2025) propose a deception network with 30 web applications used in healthcare systems that include communication over HL7 v2. HL7 is a protocol standard for exchange of administrative, logistical, financial health-related data. The authors leverage synthetic datasets and canary tokens to confuse, trap, and study attackers. Overall, the field lacks deception alternatives for healthcare systems. While other honeypots and deception systems exist for HL7 (e.g., Medpot3 ), DP is the only available option for radiology, a low-interaction 3 https://github.com/schmalle/medpot
honeypot, easily identifiable, and lacking basic features. This paper closes the gap by introducing DH, a complete DICOM deception system that combines and exploits known cyber-deception methods.
3.
DICOMHawk Deceptive DICOM Server
DICOMHawk
Radiology infrastructure often includes a mix of DICOM viewers and workstations, PACS servers, modalities, and printers. Most of these devices behave similarly from a client perspective: an accessible DICOM server and/or web interface to interact with stored medical records. The work of Beltrán-López et al. (2026) presents several examples of cyber-deception as active defensive mechanisms for detecting and responding to attacks on these systems (e.g., honeypots and honey-X). This section introduces the architecture and deception features of DH. We build upon previous work using cyber-deception systems to detect attacks on radiology infrastructure and expand related research with new deception features to trap and identify attackers both during and after interaction with DH. DH covers a broader attack surface to study attacker behaviors by implementing the core DIMSE-C services used for verification, query, retrieval, movement, and storage, and PACS interfaces with planted honey credentials in commonly visited paths. In addition, DH includes active deception mechanisms that dynamically collect public DICOM records from The Cancer Imaging Archive (TCIA)4 , populates them with fake persona information, and injects them with PDF canary tokens and honey URLs. Figure 1 shows the main components of the framework (i.e., DICOM service and PACS interface) and their mutual interaction with the stored honeyrecords. Table 1 compares DH, the original DP and DP V2.
3.1.
DICOM Server
Existing DICOM server implementations are not sufficiently flexible to mimic software from other vendors or libraries (e.g., dcm4che, OFFIS DCMTK, Fujifilm, or Neologica), apply deception features (e.g., honeyrecords), or handle/accept arbitrary binaries and commands from attackers. Without these features and behaviors, a honeypot may still resemble a basic DICOM service, but it cannot support realistic attacker interaction or collect high-fidelity threat intelligence. While DP solved some of these limitations, the implementation offers rather limited interaction and is easily identifiable due to incomplete support for DIMSE 4 https://www.cancerimagingarchive.net/
Deceptive PACS
Web Interface
DICOM Core
Dicom File Honeytoken
robots.txt
Honey URL
Honey Credentials
Management
Storage
Data Analysis
SQLite DB for DICOM Files
IP Filtering
Figure 1: DICOMHawk’s architecture, composed of a DICOM server, PACS interface, and database storage. Records are dynamically collected from TCIA and injected with PDF canary tokens and honey URLs.
Table 1: Feature comparison between deception systems covered in the literature to detect and study attacks on radiology infrastructure Feature DICOM Server A-ASSOCIATE C-ECHO C-GET C-FIND C-MOVE C-STORE Legitimate signature PACS Service Authentication panel Web DICOM viewer Decoy paths Active Deception Honeycredentials Honeyrecords HoneyURLs PDF canary tokens 1
Source code not available.
DP
DP V21
DH
✓ ✓ ✓ ✓ – – –
✓ ✓ ✓ ✓ ✓ ✓ –
✓ ✓ ✓ ✓ ✓ ✓ ✓
– – –
✓ – –
✓ ✓ ✓
– – – –
– – – –
✓ ✓ ✓ ✓
operations and semi-honest behavior. DIMSE Operations. DH implements the core DIMSE-C services used for verification, query, retrieval, movement, and storage. Attackers can store records using C-STORE, and retrieve them using C-FIND and C-GET queries. Attackers can also move records within the boundaries of the storage with C-MOVE. DH stores all payloads using a unique identifier and without parsing their content. Legitimate Signature. DH modifies its signature to mimic legimitate DICOM or PACS services (e.g., Fujifilm Synapse5 ), providing legitimate identifiers during the association process with an attacker: the system responds with configurable AETitles and values included in the UserInfo mandatory field, modifying the ImplementationClassUID and ImplementationVersionName to masquerade the underlying library—DP does not modify or provide UserInfo values. Lastly, DH logs but ignores optional fields and values sent during the association, such as UserInfo authentication. DH does not currently support TLS, AETitle validation, or DIMSE restrictions.
3.2.
PACS Service
Saputra et al. (2025) showed that most attackers targeting DICOM services also target web interfaces where PACS systems often host web DICOM viewers and other panels to access clinical data (e.g., for patients and healthcare personnel to access medical records, and system administrators to maintain services, users, and access). However, the authors mention that their web interface is merely a decoy. Authentication Panel. The authentication panel of the web interface intentionally leaks honey-credentials throughout the HTML source, actively encouraging attackers to log in and interact with the system. When honey-credentials are used, attackers are redirected to a replacement page displaying an “Under development” notice, confirming unauthorized access without revealing the deception. In addition, this panel includes validation features, allowing us to accept or reject credential dictionaries. Brute-force attempts using random credentials are a known signature that attackers use to evade deception systems Chaudhry et al. (2026). 5 https://healthcaresolutions-us.fujifilm.com/products/enterpriseimaging/synapse-cloud-services/
Decoy Paths. The web interface includes additional decoy paths leaked through the /robots.txt path, advertising fake sensitive endpoints /admin and /secure to encourage attackers to access restricted resources. Web DICOM Viewer. Authenticated users can interact with a functional DICOM viewer to browse, view, and upload DICOM records. The DICOM server and PACS interfaces share a common database, ensuring a consistent and realistic environment across both interaction points.
3.3.
Active Deception
Desjardins et al. (2020) discussed how attackers can exploit DICOM record tags to embed files with other documents and URL links as attack vectors, opening an opportunity to create honeyrecords and inject them with PDF canary tokens and honeyURLs to alert defenders when attackers access these records. DH leverages these capabilities to serve honeyrecords through its PACS and DICOM services. Honeyrecords. DH collects records from TCIA periodically, preventing the system from being fingerprinted through its file contents. These records are publicly available and freely usable for educational and research purposes under the TCIA usage policy. In addition, DH re-populates anonymized tags with fake persona and clinical metadata (e.g., names and hospital IDs). PDF Canary Tokens. To detect file exfiltration, we leverage the Encapsulated PDF Storage functionality of the DICOM standard, which allows us to wrap PDF documents inside DICOM files—this has numerous real-world applications, such as allowing radiologists to view laboratory results alongside X-rays. We generate PDF canary tokens by embedding invisible tracking pixels directly into DICOM files using the EncapsulatedDocument tag, with the MIMETypeOfEncapsulatedDocument set to application/pdf. DH also overrides the SOPClassUID with EncapsulatedPDFStorage to ensure DICOM viewers can recognize the file as an embedded PDF document and automatically render the payload. The canary is triggered when an attacker extracts the PDF to view its content. Many PDF readers automatically attempt to fetch the invisible image, sending a request to the tracking server to reveal the attacker’s IP address.
HoneyURLs. DH also exploits the RetrieveURL DICOM tag to inject a honeyURL. This tag is normally used to provide a download link for images and remote data. DH injects enticing fake URLs pointing to a non-existent internal PACS server. Attackers scraping metadata via C-FIND will encounter these URLs, and any attempt to visit them will trigger the capture of the attacker’s IP address and browser metadata.
4.
Table 2: Percentage change in daily sessions (∆% = D2 −D1 Positive values |D1 | ) during the 86-day period. indicate an increase in D2 relative to D1 . Comparisons are grouped by Location (Cloud and Local) and Design (DH and DP w/o noise). Factor
D1 → D2
Mean
Location
CloudDH → LocalDH CloudDP → LocalDP
107.46% 87.50% 166.59% 133.33%
Design
DPCloud → DHCloud DPLocal → DHLocal
47.52% 18.35%
Experimental Setup
Our data collection spanned 347 days, from June 26, 2025, to June 7, 2026. We initially deployed DH in two locations for testing and verification: our local institution’s network and a cloud instance hosted in New York (NY). During testing, DH used the underlying library as its signature (i.e., Pynetdicom). DH did not log events between November and December 2025 due to networking issues. Our testing period finalized on January 26, 2026, with the deployment of DH in an additional cloud instance in Frankfurt (FRA) to study differences in attack behaviors between European and US networks. In addition, we deployed DP in Frankfurt cloud and local instances to compare observations between deception systems. Therefore, we select the period between February 9 and May 5, 2026, as our comparison window (86 days) to avoid inconsistencies. Across the entire deployment, all honeypots exposed ports 104 and 11112, with the PACS endpoint hosted on port 3000 (DH only).
5.
Comparison
This section assesses three dimensions: implementation differences (DH vs. DP), deployment locations (cloud vs. local), and interaction dynamics of DICOM and PACS endpoints. Figure 2a illustrates the timeline categorized by honeypot endpoint and location. Geolocation and ISP classification for attacking IP addresses were retrieved via IPinfo6 .
5.1.
False positives
A key validation metric for any protocol-specific honeypot is its ability to filter network noise from meaningful application-level interactions. During this deployment, a structural divergence in logging logic between the two designs became apparent. As shown in Figure 2a, DP deployments (N-DP-Local and N-DP-FRA) initially appeared to log significantly more weekly sessions than DH. However, regular traffic 6 https://ipinfo.io/
Median
40.00% 9.55%
on the local DP instance indicated automated activity, which subsequent investigation traced to a non-DICOM network scanner. Conversely, DH mitigates such false positives by only logging a session after receiving and successfully parsing a valid DICOM request. While this strict validation lowers raw session counts, it ensures high-confidence protocol interactions. To standardize the comparison, we applied a heuristic filter to the DP dataset, removing sessions lacking a client Implementation Version Name. This heuristic serves as an approximation, as we observed this parameter to be absent in the generic TCP noise of the non-DICOM network scanner; it effectively isolates valid traffic for the subsequent analysis.
5.2.
Interaction
Figure 2a demonstrates that DH consistently attracts more genuine DICOM sessions than DP across all vantage points. As detailed in Table 2, DH recorded an average of 47.52% more daily sessions in the cloud and 18.35% more locally than DP (with a daily session count of 1 to 19). This disparity suggests that higher interaction fidelity and increased fingerprinting evasion techniques significantly increase the likelihood of attacker engagement. Furthermore, the persistent performance gap between local and cloud deployments across both platforms indicates that vantage point and network context influence attacker behavior independently of honeypot architecture. For the comparison dataset, DP logged 4 C-ECHO and 4 C-FIND commands, while DH logged 4 C-ECHO and 5 C-FIND commands. As shown in Table 3, DP logged 15 attacks from 3 unique IPs over its one-year deployment, compared to 23 DIMSE-C commands logged by DH. Two of these three IPs were also captured by DH. The third IP targeted the local DP instance only once during the testing period when the local DH experienced logging downtime. Conversely, two other
(a) Sessions per week for DICOM interactions of DICOMHawk (DH) and Dicompot (DP) with (N-DP) and without noise (DP).
(b) Sessions per week for the PACS Web interface for all DH instances.
Figure 2: Timelines showing the number of sessions observed per week over the year-long period by the different DICOM honeypots and locations split by endpoints. Deployment day of the DH Frankfurt (DH-FRA) instance is marked, as well as the 86-day comparison phase (yellow) and the period impacted by the network issue (red). Table 3: Attacker, target (HP+Location), query and count of observed attacks targeting the DICOM endpoint over the year-long period. HP
DH
DP
Attacker
Location
Query
#
University
All
PatientName:*
15
ISP DE
NY
ALL STUDY
1
Hosting TR
All
PatientName:*
4
Comcast
Local
ALL STUDY
2
Comcast
Local
StudyInstanceUID:[...]
1
University
FRA+Local
PatientName:*
12
ISP DE
FRA
-
2
Hosting US
Local
PatientName: *
1
IPs targeted DH but bypassed DP entirely, despite DP being active and in a comparable location. Table 3 highlights a further limitation in DP’s logging fidelity: query parameters for one attack were omitted, though logs indicate that all 50 available results were retrieved. Because the source IP, DICOM viewer, and timestamp align perfectly with an attack captured by DH, we infer this was a wildcard query for all studies. Without DH’s higher-fidelity logs, this context would have been lost.
5.3.
Endpoints and Location.
Table 4 shows an IP address overlap of only 11.51% between DH’s endpoints. Out of 17,563 total sessions, 55.56% targeted the PACS interface and 44.44% targeted the DICOM server. Accounting for data loss that primarily affected the DICOM server, overall engagement across both protocols was roughly equal. Cross-location IP analysis (Table 4) shows minimal IP overlap, under 10% for the PACS endpoint and 20% for DICOM.
Similarly, the IP distribution across deployment locations reveals minimal overlap. The local and New York instances exhibit the highest overlap (16.74%). This lack of intersection across locations demonstrates that multi-vantage point deployments are essential for collecting a comprehensive attack dataset. Attackers seem to rarely interact with multiple locations and endpoints, while generally preferring our local instance, as seen in Table 2.
Table 4: Unique IP address overlap between endpoints, locations, and design of DICOMHawk (DH) and Dicompot (DP) for the 86 days. Overlap DICOM Local+NY DICOM Local+FRA DICOM NY+FRA PACS Local+NY PACS Local+FRA PACS NY+FRA PACS + DICOM DH + DP DH + DP Local DH + DP FRA
Count
Percentage
150 98 100 22 17 18 158 314 156 83
16.74% 10.86% 11.34% 8.46% 8.37% 7.09% 11.51% 24.86% 19.05% 11.66%
Table 5: Observed DICOM sessions and DIMSE commands from DH and unique IP counts (in parentheses) by location. (A-RQ=Association Request, A-AB=Association Abort, A-RL=Association Released) Event A-RQ A-AB A-RL C-ECHO C-FIND C-GET
5.4.
Scanner Evasion and Fingerprinting.
To evaluate DH’s resistance to automated detection, we queried Shodan7 and Censys Durumeric et al. (2025). Shodan tagged DP as a "Honeypot" but classified DH as a legitimate "Medical" device. This confirms that our architectural enhancement DICOM services and an integrated PACS interface successfully evade automated fingerprinting. Notably, DH avoided detection even during testing while using default pynetdicom identifiers. Censys did not flag either system, indicating less aggressive DICOM heuristics than Shodan. These results validate that DH achieves its primary objective: outperforming DP by remaining indistinguishable from a production deployment to both scanners and adversaries.
6.
Long-term Analysis
Given the distinct technical characteristics of the two DH endpoints, we analyze their interactions separately, with a primary focus on medical-specific attacks. We examine interactions with the DICOM server first, followed by the PACS endpoint.
6.1.
DICOM Server
Our DICOM server records sessions and DIMSE commands. As summarized in Table 5, the endpoint processed 7,804 sessions but only 76 DIMSE commands, indicating a heavy presence of automated scanners or reconnaissance activity. This includes 53 C-ECHO requests, which are analogous to a ping command, and we therefore categorize them as 7 https://www.shodan.io/
C-MOVE C-STORE Sessions
Local 3780
NY 3162
FRA 862
Total 7804
(1561 IPs)
(1416 IPs)
(702 IPs)
(2546 IPs)
3553
2971
771
7295
(1392 IPs)
(1257 IPs)
(618 IPs)
(2225 IPs)
213
187
91
491
(169 IPs)
(159 IPs)
(84 IPs)
(321 IPs)
24
25
4
53
(3 IPs)
(3 IPs)
(2 IPs)
(4 IPs)
9
10
3
22
(3 IPs)
(3 IPs)
(2 IPs)
(4 IPs)
1
0
0
1
(1 IPs)
(0 IPs)
(0 IPs)
(1 IPs)
0
0
0
0
(0 IPs)
(0 IPs)
(0 IPs)
(0 IPs)
0
0
0
0
(0 IPs)
(0 IPs)
(0 IPs)
(0 IPs)
3780
3162
862
7804
(1561 IPs)
(1416 IPs)
(702 IPs)
(2546 IPs)
non-malicious reconnaissance. See Figure 2a for daily session distribution details. Except for C-ECHO, all other DIMSE commands can expose sensitive medical data; as such, we classify their execution as an attack. DH primarily observed C-FIND requests, 22 from 4 unique IPs, and a single C-GET request (cf. Table 5). This prevalence is expected, as C-FIND’s wildcard functionality offers the fastest method to map stored patient data, while the C-GET requested one specific study. None of these four attacking IPs intersected with the PACS endpoint. Every adversary utilized C-FIND commands in combination with wildcard queries to request all available data at either the study or patient level (cf. Table 3 for attack details). The majority of C-FIND commands (68.18%) originated from a single IP address registered to an academic institution. Given the high interaction volume, persistence across all three deployment locations, and temporal distribution (September 2025 to March 2026), this traffic likely stems from a long-term, internet-wide research study. Conversely, an attack originating from a residential ISP utilized a commercial medical viewer (RadiAnt-2025.1) rather than automated scripts, strongly indicating a human adversary.
Table 6: Observed web events on the DH’s PACS endpoint and unique IP counts (in parentheses) by location.
Table 7: Categorized login attempt attacks on the PACS endpoint based on password dictionary clustering. Target
Event /robots.txt /admin /secure /admin-config Failed Login Total
6.2.
Local
NY
FRA
Total
750
1650
480
2880
(250 IPs)
(328 IPs)
(138 IPs)
(555 IPs)
401
56
26
483
(11 IPs)
(18 IPs)
(6 IPs)
(32 IPs)
166
4
0
170
(1 IPs)
(2 IPs)
(0 IPs)
(3 IPs)
0
4
0
4
(0 IPs)
(2 IPs)
(0 IPs)
(2 IPs)
7379
18695
315
26389
(29 IPs)
(48 IPs)
(2 IPs)
(58 IPs)
8696
20409
821
29926
(281 IPs)
(383 IPs)
(142 IPs)
(621 IPs)
PACS Service
The PACS endpoint recorded webpage visits and authentication attempts, but no successful login (cf. Figure 2b for this endpoint’s daily interaction). As detailed in Table 6, the majority of unique IP addresses and logged events involved automated robots.txt requests, which are standard scanner behaviors and considered non-malicious. Conversely, visits to /admin and /secure pages occurred less frequently and via fewer IPs, signaling targeted reconnaissance or malicious intent. To isolate medical-specific threats, the subsequent analysis focuses primarily on the observed login attempts.
Login Attempt Patterns. As Table 6 shows, failed authentication attempts were the predominant event. Two primary patterns emerge. First, generic credentials (e.g., admin, root, password) heavily dominate the dataset. Second, many passwords contain explicit contextual indicators regarding the attackers’ intended targets. To categorize these attempts, we applied agglomerative clustering (distance threshold=0.8) using Jaccard similarity on the password dictionary of each IP. As summarized in Table 7, this yielded 14 distinct clusters, which we mapped to broader credential themes. Only 58 unique IP addresses were responsible for 26,389 login attempts, strongly indicating automated brute-force behavior. The majority of false authentication events originated from 44 IPs executing highly uniform dictionary attacks (Table 7). The observed password dictionary contained keywords such as ‘v2ray’ and ‘xui’ indicating attempted exploitation
XUI/V2ray CapRover Medical Other/Unidentified SQL Injection AMS30
Clusters
IPs
#
1 1 7 3 1 1
44 1 8 3 1 1
26147 176 26 22 12 6
of 3x-ui8 , a web interface for the proxy project V2ray9 . The attacks are visible in Figure 2b as the recurring spikes starting at the end of 2025. Using the same methodology, we identified two additional likely targets: CapRover10 and AMS3011 , while three other clusters used generic and non-target specific credential dictionaries, and one cluster included SQL injection attempts. Interestingly, we could identify clusters related to the medical field. Even though only 0.1% of login attempts fall into these clusters due to the intense brute-forcing attempts from the first cluster, 50% of the unique observed brute-force attack patterns were medical-related. This shows our designed PACS endpoint successfully filters a significant amount of generic web traffic, attracting domain-specific attacks. Medical-Related Login Attempts. Out of the 26 medical-related authentication attempts, only one targeted the local instance (Line 10, Table 8) rather than the New York deployment. Notably, all eight attacking IP addresses originated from ISP address space and no commercial hosting providers; four from distinct residential ISPs in India, and another registered to the All India Institute of Medical Sciences (AIIMS). The latter IP utilized an email address containing the institute’s abbreviation but registered under a public Gmail domain. The low volume and distinctive nature of these attempts differentiate them from automated, dictionary-based brute-forcing. However, the underlying credentials remain rudimentary, relying on simple numeric sequences paired with generic medical keywords. This pattern may either reflect a low-effort manual probing attempt or highlight a systemic reliance on weak, default credentials within healthcare environments, representing a broader 8 https://github.com/mhsanaei/3x-ui 9 https://www.v2ray.com/en/ 10 https://caprover.com/ 11 https://www.smcworld.com/newproducts/en-id/22/ams/
Table 8: Credential pairs of observed login attempts in medical clusters and country information of associated IP (IN=India, PK=Pakistan, GB=England, Saudi Arabia=SA, AIIMS=All India Institute of Medical Sciences). Origin
Username
Password
#
ISP PK
Mahmoud
Pacs1234
6
AIIMS AIIMS ISP PK ISP IN ISP IN 2 ISP IN 3
[redacted-email]@gmail.com [redacted-email]@gmail.com Ellithymahmoud nurse Nursing sr pulmmedicine
12345678 lapchole Pacs1234 nurse@20250 Nurse@2020 1234
4 4 3 2 2 2
ISP IN 4 ISP SA ISP GB
ortho 1234 picu 123 32l4CKKtV93nvybbyeHzQ5[...] wrong
1 1 1
sector-specific security risk.
7.
exposed healthcare infrastructure. Furthermore, because these specialized incidents occur far less frequently than generic internet background noise, longitudinal and multi-location measurements are essential to observe them. While the raw volume remains low, any targeted interaction with medical infrastructure carries high severity, given the extreme sensitivity of healthcare data. Continuous monitoring remains vital to identify and decode evolving medical-sector threats. Deployment Limitations. Although university networks often host clinical systems, and modern healthcare has migrated to enterprise cloud services, such as Fujifilm Synapse Cloud, healthcare infrastructure might be more likely targeted by advanced persistent threats (APTs) pursuing highly specific objectives and targets. A deployment in dedicated healthcare environments might lead to deeper insights into the attack landscape and better protection of those critical infrastructures.
Discussion
Our deception framework and deployment show clear advantages over existing solutions and research, and highlight persistent issues in health-related security. DICOMHawk vs Dicompot. DH provides four key improvements compared to DP. First, it refines logging mechanisms to reduce false positives and ensure comprehensiveness. Second, it enhances authenticity by integrating a PACS endpoint and dynamically updating honeyrecords (e.g., patient names and locations), preventing fingerprinting. Third, this increased realism yielded higher interaction volumes and a marginal increase in attacks. Fourth, DH injects deeper deception layers across both endpoints. Notably, embedding honeytokens within DICOM files represents a novel technique adaptable to production databases. While neither the honeytokens were triggered nor the hidden credentials were used, this may be related to the limited interactions and attacks observed in total. State of Attacks on Medical Systems. Nevertheless, our deployment showed active engagement throughout the year, with a focus on reconnaissance and a total of 49 medical-related attacks stemming from 12 different IP addresses. While attacks focus on reconnaissance, we observe attack attempts to map stored data using a single command (C-FIND wildcard). Furthermore, we see interest in using the Web endpoint as an easy entry point through brute-force attacks using generic credentials. This confirms an ongoing adversary interest in publicly
Comprehensive Medical Deception Framework. To further enhance protection, DH iterations should aim to integrate profiles mimicking diverse traditional and cloud-native DICOM/PACS servers. This includes incorporating DICOMWeb, the web-based imaging standard currently unexplored in deception research. With DH, we design a framework focused specifically on the DICOM protocol, analogous to Saputra et al. (2025). Following a similar idea to Shah et al. (2025), future work should further investigate the possibility of a medical deception framework combining different functions, protocols, and systems. For example, PACS platforms bridge DICOM and HL7/FHIR protocols, integrating an advanced HL7/FHIR honeypot is an essential next step. This would replace Medpot, which remains an unmaintained, low-interaction tool restricted to legacy HL7 versions.
8.
Conclusion
This work introduced DICOMHawk (DH), a complete DICOM deception framework that improves on Dicompot (DP), the previous state-of-the-art. The framework implements multiple deception features: a DICOM honeypot, a PACS web interface, honeycredentials, honeyrecords, canary tokens, and honeyURLs. DH collects publicly available, anonymous medical images from TCIA and rotates them to lower identifiability. We deployed DH and DP in multiple locations and compared interactions between the deception systems, achieving up to a 47.52% average
increase in observed daily sessions in the cloud deployment. Our 347-day deployment of DH identified four attackers on the DICOM honeypot, and eight in the PACS service. While low in overall volume, the observed presence of medical-specific attacks presents a notable threat landscape that necessitates continuous, distributed monitoring across diverse environments.
References Alder, S. (2026, May). Healthcare data breach statistics. https : / / www . hipaajournal . com / healthcare data-breach-statistics/ Beltrán-López, P., Gil Pérez, M., & Nespoli, P. (2026). Cyber deception: Taxonomy, state of the art, frameworks, trends, and open challenges. IEEE Communications Surveys & Tutorials, 28, 1520–1556. Bhargavi, U., Gundibail, S., Manjunath, K., & Renuka, A. (2019). Security of medical big data images using decoy technique. 2019 International Conference on Automation, Computational and Technology Management (ICACTM), 310–314. Bythwood, W., Bentley, J., & Vakilinia, I. (2023). Analyses of automated malicious internet traffic using open-source honeypots. SoutheastCon 2023, 68–75. Cartwright, A. J. (2023). The elephant in the room: Cybersecurity in healthcare. Journal of Clinical Monitoring and Computing, 37(5), 1123–1132. Chaudhry, A., Andersen, C., Choudhary, G., & Dragoni, N. (2026). A review of honeypots: Fingerprinting techniques, detection, and evasion mechanisms. Future Internet, 18(4). Commission, E. (2025, January). Cybersecurity in healthcare. https : / / commission . europa . eu / topics / digital - economy - and - society / cybersecurity-healthcare en Coventry, L., & Branley, D. (2018). Cybersecurity in healthcare: A narrative review of trends, threats and ways forward. Maturitas, 113, 48–52. Desjardins, B., Mirsky, Y., Ortiz, M. P., Glozman, Z., Tarbox, L., Horn, R., & Horii, S. C. (2020). Dicom images have been hacked! now what? [PMID: 31770023]. American Journal of Roentgenology, 214(4), 727–735. Dicom security. (2026, January). https : / / www . dicomstandard.org/using/security Durumeric, Z., Clark, H., Cody, J., Cubit, E., Ellison, M., Izhikevich, L., & Mirian, A. (2025). Censys: A map of internet hosts and services.
Proceedings of the ACM SIGCOMM 2025 Conference, 147–163. Eichelberg, M., Kleber, K., & Kämmerer, M. (2020). Cybersecurity in pacs and medical imaging: An overview. Journal of Digital Imaging, 33(6), 1527–1542. Elzer, K., Mongardini, A., Yaben, R., Theodoridis, G., Babanuta, A., Mouala, N., & Vasilomanolakis, E. (2026). Dataset for ”DICOMHawk: A Cyber Deception Framework for Medical Imaging Infrastructure”. https : / / doi . org / 10 . 5281 / zenodo.20698626 Ihanus, J., & Kokkonen, T. (2020). Modelling medical devices with honeypots. Internet of Things, Smart Spaces, and Next Generation Networks and Systems: 20th International Conference, NEW2AN 2020, and 13th Conference, RuSMART 2020, St. Petersburg, Russia, August 26–28, 2020, Proceedings, Part I, 295–306. Saputra, D. R., Lim, C., & Silaen, K. E. (2025). Improving threat intelligence in healthcare through a high interaction dicom honeypot. 2025 IEEE 2nd International Conference on Cryptography, Informatics, and Cybersecurity (ICoCICs), 319–324. Shah, Z. Z., Ikram, M., Asghar, H., & Kaafar, D. (2025). Deception meets diagnostics: Deception-based real-time threat detection in healthcare web systems. 28th International Symposium on Research in Attacks, Intrusions and Defenses RAID 2025, 391–410. Wang, H., He, H., Zhang, W., Liu, W., Liu, P., & Javadpour, A. (2022). Using honeypots to model botnet attacks on the internet of medical things. Computers and Electrical Engineering, 102, 108212. Yazdanmehr, S. (2023). Millions of patient records at risk: The perils of legacy protocols. https : / / blackhat . com / eu - 23 / briefings / schedule / #millions - of - patient - records - at - risk - the perils-of-legacy-protocols-34188