Die Radiologie zählt zu den digitalsten Disziplinen der Medizin. Bilddaten entstehen, werden übertragen, analysiert, archiviert und geteilt, überwiegend in einem Format namens Digital Imaging and Communications in Medicine, kurz: DICOM. Während vielen Anwendern die Gefahr beim Einleseprozess von DICOM-Dateien aus fremden Medien wie etwa CDs bekannt ist, werden Risiken, die aus dem Inhalt der DICOM-Datei selbst entstehen, oft unterschätzt.
Seit dem 1. Oktober 2025 gelten neue Richtlinien der Kassenärztlichen Bundesvereinigung zur IT-Sicherheit. Praxen sind seitdem ausdrücklich dazu verpflichtet, ihr Personal im sicheren Umgang mit der Praxis-IT zu unterweisen, ausdrücklich auch im Hinblick auf das Einbringen externer Daten in das eigene Haus1. Bereits 2007 warnte das Ärzteblatt in einem Artikel zweier Experten2 davor, CDs mit DICOM-Daten nur mit deaktiviertem Autostart einzulesen und auf keinen Fall die Viewer-Software zu verwenden, die auf der CD mitgeliefert wird, sondern stattdessen eine vertrauenswürdige Viewer-Software zu nutzen, die bereits auf dem Computer installiert ist. Ob CD, DVD, USB-Stick, E-Mail oder Webfreigabe-Link: Diese Handlungsempfehlung sollte unabhängig vom Übertragungsmedium befolgt werden. Andernfalls lässt sich nicht ausschließen, dass der mitgelieferte Viewer mit Schadsoftware infiziert wurde. Für radiologische Praxen und Abteilungen bedeutet das, aus dem Übertragungsmedium ausschließlich die eigentliche DICOMDatei (Endung ".dcm") zu übernehmen, in den PACS-Serverzu importieren und anschließend mit dem lokal installierten PACS-Viewer zu betrachten.
Das Innenleben einer DICOM-Datei
Stark vereinfacht betrachtet kann man sich eine DICOM-Datei wie einen Ordner voller Dateien vorstellen. Diese Dateien müssen eine vordefinierte Struktur haben, abhängig von der Art der gespeicherten Daten und damit vom jeweiligen Dateityp. In der Realität sind DICOM-Dateien deutlich umfangreicher und die Strukturen deutlich komplexer, die Spezifikation umfasst nicht ohne Grund mehrere tausend Seiten. Zur Einordnung der folgenden Sicherheitsrisiken ist diese stark vereinfachte Beschreibung jedoch ausreichend.
Der Dateityp PDF-Dokument
Wie im obigen Beispiel gezeigt, unterstützen DICOM-Dateien das Speichern von PDF-Dokumenten über den Dateityp "PDFDokument" 3. Diese Funktion wird in der Praxis häufig genutzt, etwa für Befunde, Vorbefunde oder eingescannte Überweisungsscheine. Eine nähere Betrachtung der Datenstruktur zeigt das Feld "MIME-Type". MIME steht für Multipurpose Internet Media Type und beschreibt – ähnlich einer Dateiendung – die Art der Datei. PDF-Dokumente haben ausnahmslos den MIME-Type "application/pdf ". Die DICOM-Spezifikation erlaubt daher auch nur diesen Wert für dieses Feld4. Trotzdem ist es ein zwingender Bestandteil der strukturierten Daten, und genau hier entstehen Angriffsvektoren.
Angriffsszenario 1: MIME-Type
Wenn Anwender ein vermeintliches PDF-Dokument aus einer DICOM-Datei öffnen, entscheidet der Viewer, mit welcher Anwendung die Datei geöffnet wird. Da der DICOM-Standard an dieser Stelle ausschließlich PDF-Dateien erlaubt, darf der Viewer weder das MIME-Type-Feld als Kriterium verwenden noch anhand der Binärdaten den Dateityp erraten, sondern muss die Datei grundsätzlich mit einem PDF-Viewer öffnen. Hält er sich nicht daran, können manipulierte DICOM-Dateien den Viewer dazu bringen, andere Dateiformate oder sogar ausführbare Dateien zu starten.
Ist dies nicht korrekt implementiert, kann Magic Byte Spoofing eine Angriffsfläche bieten: Dabei wird etwa eine Windows-EXE-Datei so manipuliert, dass sie typische Merkmale einer PDF-Datei enthält und dadurch fälschlich als valide PDF-Datei interpretiert wird. Auch polyglotte Dateien sind denkbar, also Dateien, die sowohl in einem PDF-Viewer als auch in Microsoft Word geöffnet werden können. Wird eine solche Datei in Word geöffnet, kann ein schädliches Makro ausgeführt werden.
Angriffsszenario 2: Missbrauch von PDF-Funktionalitäten
Eine weitere Angriffsmöglichkeit entsteht durch das PDF-Format selbst. Viele Funktionen, die Interaktivität in PDF-Dokumenten ermöglichen, können für Angriffe missbraucht werden. Besonders kritisch sind sogenannte "/Launch"-Aktionen. Sie erlauben das Ausführen von Befehlen in der Kommandozeile des Betriebssystems, entweder unmittelbar beim Öffnen des Dokuments oder ausgelöst durch das Anklicken eines Buttons. In vielen PDF-Viewern lassen sich diese Funktionen deaktivieren, sind jedoch standardmäßig aktiviert. Ein Beispiel ist der Browser Firefox, der in der Standardkonfiguration die Ausführung von JavaScript in PDF-Dokumenten erlaubt.
Angriffsszenario 3: Der Mensch
Neben technischen Schwachstellen bleibt Social Engineering der kritischste Angriffsvektor. Ein PDF-Dokument mit einem gut sichtbaren Link "Befund öffnen" wirkt auf den ersten Blick harmlos. Beim Anklicken könnte sich jedoch der Browser öffnen und eine Datei namens "Befund.exe" aus dem Internet herunterladen. Besonders in stressigen Situationen wie im Notfallbetrieb oder bei hoher Arbeitslast werden Warnhinweise des Browsers oder Betriebssystems häufig ignoriert und die Datei trotzdem geöffnet.
Virenscanner erkennen viele Angriffe nicht
Ein verbreiteter Irrglaube ist, dass Virenscanner zuverlässig vor schädlichen PDF-Dateien schützen. Um dies zu überprüfen, wurden acht schädliche PDF-Dokumente mit 64 unterschiedlichen Virenscannern getestet, zunächst im direkten Dateienscan und anschließend im Scan, bei dem das schädliche PDF-Dokument in eine DICOM-Datei eingebettet war.
Die Ergebnisse sind ernüchternd. Beim direkten Scan der PDF-Dateien haben nur 20 Prozent der getesteten Virenscanner Alarm geschlagen. Ist die schädliche PDF-Datei zusätzlich in eine DICOM-Datei eingebettet, verschlechtert sich das Ergebnis weiter: Lediglich 6 Prozent der Scanner haben die Datei als gefährlich markiert.
Natürlich sollten Virenscanner trotz der schlechten Ergebnisse weiter genutzt werden; sie dürfen jedoch nicht der einzige Abwehrmechanismus sein.
Dateien in Sandbox öffnen
Radiology Advanced empfängt als Teleradiologie-Anbieter täglich Daten aus unterschiedlichsten Quellen und Formaten. Für unsere IT-Security spielt es dabei keine Rolle, ob der Absender die Daten vom Patienten eingelesen hat, sie direkt von einer anderen radiologischen Einrichtung erhält oder die Dateien vor Ort selbst erstellt. Wir behandeln zugesendete Dateien grundsätzlich wie E-Mail-Anhänge: mit großer Vorsicht und als mögliches Sicherheitsrisiko.
Dateien, die uns zugesendet werden, öffnen wir in einer sogenannten Sandbox. Eine Sandbox ist eine abgeschottete virtuelle Umgebung, in der Dateien und Programme ausgeführt werden können, ohne direkten Zugriff auf den gesamten Computer oder das Netzwerk zu haben. Selbst wenn sich in einer Datei Schadsoftware befindet, bleibt diese innerhalb der Sandbox isoliert und kann sich nicht verbreiten. Nach dem Schließen der Datei wird die Umgebung zurückgesetzt, sodass mögliche Manipulationen vollständig rückgängig gemacht werden. Auf diese Weise lässt sich das Risiko eines erfolgreichen Angriffs auf
die Praxis-IT erheblich reduzieren.
Ergänzend dazu bleibt die routinemäßige Sensibilisierung der Mitarbeitenden von großer Bedeutung. Technische Schutzmaßnahmen helfen nur bis zu einem gewissen Grad. Letztlich entscheidet insbesondere das Verhalten der Anwender im Alltag darüber, ob ein Cyberangriff Erfolg hat oder nicht. Regelmäßige praxisnahe Schulungen sowie klar definierte, gut erreichbare und zugewandte Ansprechpartner bei Verdachtsfällen sind ein zentraler Faktor für wirksame IT-Sicherheit.
Autor:
Martin Ramm, CTPO
RA Radiology Advanced GmbH
E-Mail: office@radiology-advanced.com
Quelle: Krankenhaus-IT Journal, Ausgabe 06/2025 / Stand: Dezember 2025
Quellen
1 https://hub.kbv.de/pages/viewpage.
action?pageId=63537333
2 https://www.aerzteblatt.de/archiv/dicom-cd-sicherheitsprobleme-
beachten-47605735-83d6-459f-baa2-028d578afe6c
3 https://dicom.nema.org/medical/dicom/current/output/
chtml/part03/sect_A.45.html#sect_A.45.1
4 https://dicom.nema.org/medical/dicom/current/output/
chtml/part03/sect_A.45.html#sect_A.45.1.4.1
5 https://searchfox.org/firefox-esr140/source/toolkit/components/
pdfjs/Pdf JsDefaultPrefs.js#41
