{"id":"493ca54d-d12a-44b5-94eb-baab2fd537e0","arxiv_id":"2607.15754","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"DICOMHawk, an open-source high-interaction DICOM/PACS honeypot with dynamic fake patient records and canary tokens, attracted more valid sessions than Dicompot over 86 days and logged 49 medical-related attacks over 347 days.","lead":"This paper presents DICOMHawk, a fake DICOM/PACS server that mimics a hospital imaging system to attract and observe attackers. Deployed for nearly a year, it logged more genuine sessions than the existing Dicompot honeypot and captured a small set of medical-themed attacks, giving defenders a new open-source tool and dataset for studying threats to medical imaging.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Headline session-superiority claim may rest on an asymmetric session metric: DP sessions lacking an optional Implementation Version Name are discarded while DH sessions are defined by its own parser.","rationale":"The paper is a genuine empirical contribution with open code/data and a long, multi-location deployment. My concern is not with external consensus but with internal measurement validity: what must be true for the central claim is that 'valid sessions' means the same thing for DH and DP after filtering. Section 5.1 shows it does not, exactly as the reader's weakest assumption states. The proposed re-analysis would settle the issue. If the advantage persists under a common criterion, the central claim holds; if not, the paper's headline should be softened to a qualitative observation. Because the reader already issued a conditional verdict that identifies this concern, I recommend keeping the verdict unchanged rather than moving to accept or reject.","tokens_in":10568,"tokens_out":4113,"duration_ms":35900,"concrete_test":"Recompute Table 2 from the released raw datasets using a single parser-independent session criterion applied identically to both honeypots: count a session only when a complete DICOM A-ASSOCIATE-RQ is observed and at least one valid DIMSE message follows (or, if packet-level logs are unavailable, apply the Implementation-Version-Name filter to DH's own logged sessions and to DP's logs). If the +47.52% cloud and +18.35% local deltas do not persist under a common definition, the superiority claim is not supported by the current evidence.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central quantitative claim—that DH attracts more valid sessions than DP (47.52% more daily sessions in cloud, 18.35% locally, Table 2)—is inferred from two different session definitions. Section 5.1 says DP's raw logs were reduced by removing 'sessions lacking a client Implementation Version Name,' while DH counts a session only 'after receiving and successfully parsing a valid DICOM request.' This filter is applied only to DP. If legitimate DICOM associations omit the Implementation Version Name field, or if the non-DICOM scanner includes some value for it, the filter either undercounts DP or fails to remove noise. The asymmetry is material: in the same comparison window DP logged only 4 C-ECHO and 4 C-FIND commands, so the large session deltas in Table 2 rest almost entirely on the filtered denominator. The paper's own limitations—no canary token triggered, no hidden credentials used, one attacker likely a research scanner—also temper the '49 medical-related attacks' claim, but the session comparison is load-bearing because it directly supports the headline superiority of DH over DP.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents DICOMHawk (DH), an open-source deception framework that emulates a DICOM server and a PACS web interface, with dynamic honeyrecords, honeycredentials, canary tokens, and honeyURLs. The authors deployed DH and Dicompot (DP) on local and cloud networks for 347 days, including an 86-day side-by-side comparison, and report that DH attracted more valid sessions than DP (47.52% more daily sessions in cloud, 18.35% locally), avoided automated fingerprinting by Shodan/Censys, and captured 49 medical-related attacks. The paper also describes attacker behavior: C-FIND wildcard queries, medical-themed PACS login attempts, and low overlap between endpoints and locations.","tokens_in":10789,"tokens_out":5176,"duration_ms":43726,"significance":"If the measurement claims survive scrutiny, the paper is a useful contribution: it provides a long-term, multi-location dataset for medical-imaging honeypots, an open-source implementation, and a comparison against the previous state of the art. The observation that both automated and human adversaries interact with DICOM/PACS services is of interest to the healthcare security community. The authors are honest about several limitations, and the release of code and data is a clear strength that supports reproducibility. However, the central quantitative claims rely on small counts and an asymmetric session-definition filter, so the magnitude of the reported advantage is not yet established.","major_comments":[{"comment":"The headline comparison of valid sessions relies on an asymmetric session definition. DP logs are filtered to remove sessions lacking a client Implementation Version Name, whereas DH counts a session only after \"receiving and successfully parsing a valid DICOM request.\" The Implementation Version Name is an optional User Information item in DICOM A-ASSOCIATE; legitimate clients may omit it, and the paper gives no evidence about its presence/absence across real DICOM implementations. Because the 47.52% and 18.35% deltas in Table 2 are the main quantitative evidence for DH superiority, this filter must be justified or applied symmetrically (e.g., run the same DICOM parser on raw DP logs, or report DH raw session counts before parser validation). With daily session counts of 1–19 and no confidence intervals, the percentage changes may not be statistically distinguishable.","section":"§5.1, Table 2"},{"comment":"The abstract/conclusion claim of \"49 medical-related attacks\" is computed from 23 DIMSE-C commands (Table 5) plus 26 medical-related failed login attempts (Table 8). This conflates low-level events with attacks: a single brute-force campaign can produce many attempts, and repeated identical credential pairs are each counted as a separate attack. The paper needs an explicit attack definition, deduplication per IP/campaign, and separation of automated reconnaissance, brute-force attempts, and any successful compromise. Without this, the headline number overstates the observed adversarial activity.","section":"§6, Tables 5 and 8"},{"comment":"All cross-design and cross-location comparisons are reported without uncertainty or statistical testing. The session counts are tiny (1–19 daily sessions), DP logged only 4 C-ECHO and 4 C-FIND in the comparison window, and IP-overlap percentages in Table 4 are raw unique-IP overlaps with no consideration of scanning background. Statements such as \"this disparity suggests that higher interaction fidelity ... significantly increase the likelihood of attacker engagement\" are not yet supported. The authors should provide confidence intervals or a bootstrap/permutation-based test, and temper causal language.","section":"§5.2–5.3, Tables 2–4"},{"comment":"The paper's own limitations section concedes that neither the honeytokens were triggered nor the hidden credentials were used. As a result, the active-deception features (PDF canary tokens, honeyURLs, honeycredentials) are not validated by field observation; their detection value is currently speculative rather than demonstrated. The design is interesting, but the paper should not imply these features contributed to the measured outcomes.","section":"§7, Deployment Limitations"}],"minor_comments":[{"comment":"Typographical and formatting issues: \"legimitate\" should be \"legitimate\"; \"UserInfomandatory\" is missing a space; the sentence about \"values included in the UserInfo mandatory field\" is unclear and should be rewritten.","section":"§3.1"},{"comment":"The deployment timeline would benefit from a clearer statement of which instances were active at which times, especially the November–December 2025 logging gap and the exact relation between the 347-day total and the 86-day comparison window. Figure 2's shading is helpful but the text should make the intervals explicit.","section":"§4"},{"comment":"The term \"attack\" is used inconsistently across DIMSE commands, login attempts, and scanner traffic. The table also labels attacker/count fields with informal names (e.g., \"University\", \"ISP DE\") that should be defined or replaced with neutral identifiers in the main text.","section":"§5.2, Table 3"},{"comment":"Several references appear incomplete or nonstandard (e.g., the Censys citation, the European Commission web citation, and the DICOM security web citation lack full bibliographic detail). The authors should align the reference list with the venue's citation guidelines.","section":"References"}],"recommendation":"major_revision","confidential_remarks":"The paper is within scope for a security-measurements venue and the open-source release is a genuine strength. The main risk is the asymmetric session-definition filter in §5.1: if the authors can show it does not remove legitimate DICOM associations (e.g., by validating against several real DICOM client libraries or by applying the same parser to both systems), the core comparison would be substantially stronger. The \"49 attacks\" counting issue is also fixable with a clearer attack taxonomy. I would ask for a major revision rather than rejection, because the underlying measurement effort is valuable and the flaws are addressable within the manuscript's scope."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"DICOMHawk is a real piece of work with an honest skeleton: a higher-interaction DICOM/PACS honeypot, open-source implementation, and 347 days of field data. The parts that make it worth reading are the engineering choices — rotating records from TCIA, embedding PDF canaries, honeyURLs, a PACS facade, and a legitimate DICOM signature — and the fact that they actually deployed it in three places and compared against Dicompot. That is more than most honeypot papers do.\n\nThe central claim — that DH draws more valid sessions than DP — is plausible but not proven by the numbers. The stress-test concern is real: DP's logs are filtered by removing sessions that lack a client Implementation Version Name, while DH only counts sessions after it parses a valid DICOM request. That asymmetric filter is applied only to DP, and it is exactly the load-bearing piece for the 47% and 18% differences. If a meaningful share of DP's raw sessions were legitimate DICOM associations that happened to omit that optional field, the gap shrinks or disappears. The authors call it a heuristic, but they don't show how sensitive the comparison is to the filter. That is the main thing a referee should push on.\n\nAlso in proportion: the sample sizes are small (daily sessions 1–19; 4 C-ECHO and 4 C-FIND for DP in the comparison window), so the percentage differences have wide error bars even if the filtering is fair. No confidence intervals or tests. And the \"49 medical-related attacks\" is a mix of wildcard C-FINDs and 26 login attempts, with the authors themselves admitting one major contributor is likely an internet-wide research study. That tempers the threat narrative, though it doesn't erase the few genuinely interesting incidents, like the RadiAnt user from a residential ISP.\n\nWhat the paper does well is transparency: they admit no canary fired, no honeycredentials were used, and the limitation section is honest. The Shodan finding is a nice concrete data point. The dataset and code are released, which makes this independently checkable — and that raises the paper above most in this niche.\n\nBottom line: this is a competent empirical systems paper, not a breakthrough, and not a fraud. A serious referee should take it, with specific requests: re-analyze DP's raw logs under a symmetric session definition, add sensitivity analysis for the filter, and report counts with intervals. I'd send it to peer review and be willing to cite the system and dataset in my own work.","headline":"A credible, open-source DICOM honeypot with a year of field data, but the headline session-superiority claim is weakened by an asymmetric filter and tiny counts.","tokens_in":11332,"tokens_out":2433,"would_cite":true,"duration_ms":19522,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A DICOM honeypot that mimics legitimate PACS software attracts more genuine attacker sessions than earlier low-interaction tools and surfaced 49 medical-specific attacks over a year.","keywords":["DICOM","honeypot","cyber deception","PACS","medical imaging security","honeytoken","threat intelligence","healthcare infrastructure"],"falsifier":"Run the 86-day comparison a second time while recording Dicompot sessions using the same valid-DICOM-request criterion DICOMHawk uses, and see whether the 47.52% (cloud) and 18.35% (local) session advantages persist; separately, deliberately open a canary-embedded PDF and visit a honeyURL to confirm the tracking pixel and landing server fire.","tokens_in":10415,"feed_emoji":"🩻","tokens_out":6962,"duration_ms":57959,"temperature":0.7,"pith_summary":"DICOMHawk is a cyber-deception framework that poses as a hospital imaging (DICOM/PACS) server while actually observing attackers. The paper argues that realistic interaction—filling in a legitimate-looking DICOM signature, serving real but re-personalized medical images, and adding a PACS web interface with leaked credentials—makes the deception credible enough to attract more genuine DICOM sessions than the earlier Dicompot honeypot. Across an 86-day side-by-side comparison and a 347-day deployment in multiple locations, the authors report 47.52% more daily sessions in the cloud, 18.35% more locally, no honeypot fingerprinting by Shodan, and 49 medical-related attacks from 12 IPs. If right, this gives defenders a reproducible way to see how attackers probe medical imaging systems and shifts the field from low-interaction, easily detected honeypots to long-term, multi-vantage-point deception.","feed_headline":"Fake PACS server lures 49 medical attacks in a year","feed_subtitle":"DICOMHawk mimics real imaging software, logs more valid sessions than Dicompot, and escapes Shodan's honeypot flag.","key_machinery":"The load-bearing object is the legitimate DICOM signature combined with a shared database between the DICOM server and the PACS web viewer. The signature fills the UserInfo fields—ImplementationClassUID and ImplementationVersionName—that Dicompot omits, letting the service pass association-time checks and evade automated fingerprinting. The shared database means an attacker querying via DIMSE and an attacker logging into the web UI see the same patient records, reinforcing the illusion. On top of this sit three active-deception mechanisms: dynamically rotated honeyrecords (real publicly available medical images with fake personas), PDF canary tokens embedded through Encapsulated PDF Storage","core_discovery":"The paper's central claim is that a deception system for DICOM can be built to be essentially indistinguishable from production imaging infrastructure while remaining instrumented enough to log high-fidelity attacker behavior. DICOMHawk does this by answering DICOM associations with a legitimate signature (real ImplementationClassUID and ImplementationVersionName, masquerading as a Fujifilm Synapse service), implementing the core DIMSE-C services so attackers can C-ECHO, C-FIND, C-GET, C-MOVE, and C-STORE, serving a PACS web interface seeded with honeycredentials and decoy paths, and populating storage with real-looking medical images re-tagged with fake personas and embedded PDF canary toke","pith_inferences":["A normalized re-analysis is the first thing I would try: apply Dicompot's original per-connection logging rule to both honeypots and DICOMHawk's parse-based rule to both, to bracket how much of the 47.52%/18.35% advantage is measurement and how much is attacker preference.","The two endpoints catch essentially disjoint attacker sets (roughly 11.5% IP overlap), which hints that DIMSE-wire attackers and web-UI attackers are different populations; planting the same honeyrecord in both surfaces would test whether any single adversary works both.","Since the deployment saw no canary triggers, an obvious next experiment is a controlled red-team session that extracts an embedded PDF and follows a honeyURL, measuring trigger latency and false-alarm rate before relying on these tokens in production.","The credential clustering shows the vast majority of PACS login attempts were generic proxy/panel brute-forcing; filtering those clusters first in a future version would let defenders focus on the small set of medical-specific attempts, which is where the signal lives."],"forward_implications":["Deploying this open-source framework gives a healthcare defender a DICOM/PACS service that looks like production software—legitimate association signature, shared database, realistic images—without needing custom fake data, so deception can become a routine monitoring layer.","The year-long logs show the observed DICOM attack pattern is dominated by reconnaissance: 53 C-ECHO pings, 22 wildcard C-FIND queries across four IPs, and one targeted C-GET; no C-STORE or C-MOVE attempts were recorded during the deployment.","Multi-location deployment is not optional for coverage: unique-IP overlap was under roughly 17% between any two locations and about 12% between the DICOM and PACS endpoints, so a single vantage point sees only a small slice of the adversary population.","Medical-context credential pairs appear in real traffic (for example nurse/nurse@2020 and ortho/1234), and half of the distinct password clusters were medical-flavored, so this kind of deception separates healthcare-specific threats from generic internet noise.","Because the canary tokens and honeyURLs were never triggered during the deployment, their exfiltration-alerting value is demonstrated as a design capability rather than as an observed event.","A defender can now build a DICOM/PACS deception layer that looks like production software—legitimate association signature, shared database, realistic images—without custom fake data, making deception a routine monitoring option."],"fun_headline_variants":["DICOMHawk fakes PACS, logs 49 attacks","Fake PACS server lures 49 medical attacks","Deceptive DICOM server escapes honeypot, nets 49","Fake imaging server traps 49 medical attacks in a year","347-day fake PACS captures 49 medical attacks"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The session-count comparison rests on discarding Dicompot sessions that lack a client Implementation Version Name while counting DICOMHawk sessions that pass its own DICOM parser; if meaningful pre-DICOM reconnaissance or real queries can omit that optional field, the reported advantage partly reflects the counting rule rather than attacker preference.","fun_headline_variants_meta":{"raw":{"variants":["DICOMHawk fakes PACS, logs 49 attacks","Fake PACS server lures 49 medical attacks","Deceptive DICOM server escapes honeypot, nets 49","Fake imaging server traps 49 medical attacks in a year","347-day fake PACS captures 49 medical attacks"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00053,"raw_usage":{"total_tokens":2558,"prompt_tokens":705,"completion_tokens":1853,"prompt_tokens_details":{"cached_tokens":640},"prompt_cache_hit_tokens":640,"prompt_cache_miss_tokens":65,"completion_tokens_details":{"reasoning_tokens":1776}},"tokens_in":65,"tokens_out":1853,"duration_ms":15594,"temperature":1.0,"reasoning_tokens":1776,"cache_read_input_tokens":640,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-01T22:24:53.836489+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the 86-day comparison a second time while recording Dicompot sessions using the same valid-DICOM-request criterion DICOMHawk uses, and see whether the 47.52% (cloud) and 18.35% (local) session advantages persist; separately, deliberately open a canary-embedded PDF and visit a honeyURL to confirm the tracking pixel and landing server fire.","supporting_citations":[],"review_version":1}