Cryptojacking on a PACS Imaging Server: Incident Response Checklist

How to identify cryptojacking indicators on a PACS server

Cryptojacking is unauthorized use of a system’s computing resources to mine cryptocurrency. On a PACS imaging server, investigate unexplained sustained CPU or GPU use, increased power or cooling demand, degraded image retrieval or processing, unfamiliar processes, unexpected scheduled tasks or services, and outbound connections to infrastructure with no approved clinical or business purpose. These symptoms are clues, not proof: legitimate PACS workloads, backups, and maintenance can also consume significant resources.

Check for Stratum protocol traffic and other connections that may indicate communication with cryptocurrency mining pools. Look for unusual outbound sessions, DNS requests, repeated connections to unfamiliar hosts, or traffic from a PACS server that conflicts with its documented role. Stratum use or a particular port is not conclusive by itself; compare findings with approved software, network baselines, and vendor documentation. MITRE ATT&CK’s Lucifer profile documents one malware example that used Stratum to communicate with a mining server, while MITRE ATT&CK’s compute-hijacking technique describes cryptocurrency mining as one way attackers misuse computing resources.

• Compare CPU, memory, disk, and network use with normal PACS activity and recent workload changes.
• Identify processes, accounts, services, scripts, startup entries, and remote connections that are unexpected or unauthorized.
• Review endpoint detection alerts, firewall and DNS telemetry, authentication events, and changes to system or security configuration.
• Check whether neighboring servers or connected systems show similar symptoms; a mining process may be one part of a wider intrusion.

Escalate suspected compromise to the organization’s incident-response and clinical operations leads. Avoid treating high utilization alone as a confirmed infection or relying on a single indicator to decide whether to disconnect a system.

How to contain an affected PACS imaging server without disrupting care

Coordinate containment with the PACS owner, radiology leadership, clinical engineering, IT operations, and the incident-response lead. First determine which services are affected and what patient-care functions depend on them. Follow the organization’s diagnostic imaging downtime procedures and emergency-mode plans before changing network access or shutting services down.

When practical, use the narrowest effective containment: for example, block confirmed malicious destinations or restrict the affected server’s outbound communications while preserving only the connections needed for approved clinical operations. If compromise is spreading or the server presents an immediate risk, stronger isolation may be necessary. Do not assume that unplugging the server, powering it off, or applying a broad network block is safe; those steps can interrupt imaging workflows and may destroy volatile evidence.

• Record the clinical impact, decision-maker, containment actions, time, and systems affected.
• Confirm availability of alternate viewers, redundant archives, failover systems, or a safe manual process before disabling a service.
• Limit access to compromised accounts and remote administration paths as appropriate, while preserving a controlled path for authorized response and recovery.
• Keep staff informed about where to send urgent imaging requests and how to report delays or missing studies.

HHS describes emergency-mode operations and contingency planning for systems containing electronic protected health information (ePHI). Its October 2026 cybersecurity newsletter recommends planning how essential functions can continue when critical systems are unavailable, including through paper-based processes where appropriate.

What PACS clinical workflows and diagnostic services should be assessed

Assess clinical impact alongside technical scope. Determine whether staff can locate, retrieve, view, interpret, and distribute current and prior studies, and whether new images are being acquired and routed successfully. Ask radiology and modality teams which studies are time-sensitive and whether interruptions are delaying diagnosis or treatment.

• Image acquisition and routing: Check whether modalities can send studies and whether interfaces, gateways, and worklists are functioning as expected.
• Viewing and interpretation: Verify access for radiologists and clinicians, including remote or on-call workflows if used.
• Archive and prior studies: Assess whether images and reports remain available, intact, and associated with the correct patient and encounter.
• Interfaces and dependencies: Review connections with the radiology information system, electronic health record, identity services, storage, backups, and vendor-managed systems.
• Operational workarounds: Identify approved alternate sites, manual processes, escalation contacts, and procedures for reconciling work completed during downtime.

Clinical and technical leads should agree on prioritization, acceptable temporary limitations, and criteria for returning services to normal. Record delayed, repeated, or manually handled studies so they can be reconciled and checked for completeness after recovery.

How to investigate the entry point and determine incident scope

Establish a timeline: when unusual resource use or traffic began, when it was detected, what changed beforehand, and which accounts or systems were involved. Review recent patches, software installations, configuration changes, remote access, vendor maintenance, and alerts. Investigate potential entry paths such as exposed services, stolen credentials, vulnerable software, or a compromised connected workstation without assuming any one path in advance.

Determine whether activity is confined to one server or extends to other PACS components, storage, administrative systems, modality networks, identity infrastructure, or third-party connections. Search for shared indicators, unauthorized access, persistence mechanisms, new accounts, lateral movement, and attempted access to ePHI. Network and endpoint evidence should be correlated with PACS application records rather than assessed in isolation.

Preserve a clear incident timeline and document what is known, what remains uncertain, and which systems have been checked. If the investigation indicates that ePHI may have been accessed, acquired, used, or disclosed, involve privacy, legal, and compliance teams promptly to assess obligations. HHS OCR’s cyber-attack quick-response checklist discusses incident mitigation and breach-reporting considerations; the organization should assess its specific facts and applicable requirements rather than assume every cryptomining incident has the same reporting outcome.

How to eradicate cryptojacking malware and recover PACS services

Do not rely on terminating a mining process as the only remediation. Confirm how it started, identify persistence and unauthorized changes, and investigate whether the attacker obtained credentials or access to other systems. Where feasible, preserve forensic evidence before making changes that could erase it.

If compromise is confirmed, rebuilding the affected server from a known-good system image is often a safer recovery option than trusting an in-place cleanup, especially when the integrity of the operating system or administrative tools is uncertain. Validate the image’s provenance and patch level, restore only necessary and verified data and configurations, rotate credentials that may have been exposed, and close or mitigate the entry point before reconnecting the host.

• Verify the repaired or rebuilt system with security tools and checks for known incident indicators before production use.
• Confirm PACS application, interface, archive, and access-control behavior with technical and clinical owners.
• Test image integrity, patient and study associations, retrieval, routing, and any backlog reconciliation process.
• Reconnect in a controlled manner, monitor for renewed suspicious activity, and retain a documented rollback or downtime plan.

HHS identifies backup, restoration, and continuation of critical business processes as elements of contingency planning for ePHI. Its guidance on system disruptions and recovery also emphasizes checking backup integrity and periodically testing restorations.

Which logs and volatile data should responders preserve

Preserve records from the affected server and relevant supporting systems, following organizational evidence-handling procedures. Prioritize data likely to be overwritten by retention limits or affected by containment and recovery actions.

• PACS audit logs: User and administrator logins, study access and changes, exports, configuration changes, service activity, and relevant application or interface events.
• Host and security records: Operating-system events, process and service information, endpoint detection alerts, authentication logs, scheduled tasks, and software or configuration changes.
• Network evidence: Firewall, DNS, proxy, IDS, and flow records that show outbound destinations, timing, and relationships between affected systems.
• Incident documentation: Screenshots or notes of observed symptoms, system and account identifiers, time zone and clock differences, actions taken, and chain-of-custody details.
• Volatile evidence: When authorized and safe, consider volatile memory acquisition and collection of live process, connection, and session data before a shutdown or reboot.

Volatile data can be lost when a system loses power. NIST’s Guide to Integrating Forensic Techniques into Incident Response explains that collection from a live system can preserve information unavailable after shutdown, but also changes system state and carries risks. Have qualified responders weigh evidence value against clinical and operational risk; document collection steps, preserve originals where possible, and protect copies from alteration.

How to strengthen PACS network security after an incident

Use incident findings to reduce the chance of recurrence without breaking required imaging workflows. Maintain an accurate asset and connection inventory for PACS servers, modalities, workstations, storage, interfaces, and vendor access. Document which communications are necessary, who owns each connection, and how exceptions are approved.

• Apply network segmentation controls that restrict unnecessary communication between PACS, user, modality, server, and external networks; test changes with clinical and technical owners.
• Limit outbound access to documented business needs, and monitor for unexpected destinations, mining-pool indicators, and abnormal resource consumption.
• Remove or restrict unused services and remote access, enforce least privilege, and strengthen authentication for administrative access.
• Maintain supported software and a risk-based patch process that accounts for vendor dependencies and clinical validation requirements.
• Centralize relevant security and PACS audit logs, protect them from unauthorized changes, and confirm retention supports investigations.
• Test backups, recovery, and diagnostic imaging downtime procedures with the teams that will use them during an actual outage.

CISA’s Healthcare and Public Health Sector Mitigation Guide describes segmentation measures such as maintaining network architecture, controlling cross-segment traffic with firewalls and access-control lists, and analyzing traffic logs. Apply these measures in a way that respects the PACS design and validated clinical dependencies.

In summary: Detect suspicious mining activity, contain it in coordination with clinical operations, preserve useful evidence, investigate the full scope, and restore service only after verifying system integrity and clinical workflows. Use the incident to improve segmentation, monitoring, access controls, backups, and downtime readiness.

FAQs

What signs indicate cryptojacking on a PACS imaging server?

Possible signs include unexplained sustained CPU or GPU use, performance problems, unfamiliar processes or persistence mechanisms, unexpected outbound connections, and traffic that may involve Stratum or cryptocurrency mining pools. These are indicators to investigate, not confirmation by themselves; compare them with normal workloads and approved PACS activity.

How can responders isolate a compromised PACS server while maintaining clinical operations?

Coordinate with incident response, radiology, clinical engineering, and PACS owners. Follow diagnostic imaging downtime procedures, identify alternate workflows, and use the narrowest effective network restrictions that contain the threat while preserving essential services when safe. Escalate to stronger isolation if risk requires it, and document the clinical impact and decisions.

Which PACS logs and volatile data should be preserved?

Preserve PACS audit logs, operating-system and security records, authentication events, firewall and DNS data, relevant network telemetry, and a timeline of response actions. If qualified responders judge it safe and useful, collect volatile memory and live system information before shutdown or reboot, documenting the process and protecting evidence integrity.

Should an affected PACS server be rebuilt from a known-good image?

Consider rebuilding when compromise is confirmed or system integrity cannot be trusted. Preserve evidence first when feasible, verify the image is genuinely known-good and appropriately patched, address the entry point, rotate potentially exposed credentials, and validate security and clinical functions before returning the server to production.