vegefox.com - stock.adobe.com
Sicherheitstests mit Ncrack, Hydra und Nmap durchführen
Mit Nmap, Ncrack und Hydra lassen sich Webdienste und Workloads im Netzwerk auf Schwachstellen prüfen. Der Beitrag zeigt, wie das geht und wie Administratoren dabei vorgehen.
Dieser Artikel erklärt praxisorientiert Installation, Konfiguration und den operativen Einsatz von Ncrack und Hydra für autorisierte Sicherheitstests. Er zeigt, wie Nmap offene Authentifizierungsdienste erkennt, wie Ncrack großflächig und parallelisierte Prüfungen auf schwache Zugangsdaten durchführt und wie Hydra gezielte Angriffe auf Webformulare und Protokolle mit spezieller Authentifizierungslogik übernimmt.
Administratoren erhalten Anleitungen zur Installation unter Kali Linux und Debian, praxisnahe Befehle für Discovery und Massentests, Empfehlungen zu Timing und Parallelität, Hinweise zum sicheren Umgang mit Benutzer und Passwortlisten sowie Methoden zur Auswertung und Priorisierung von Befunden. Wir gehen außerdem darauf ein, wie sich Ncrack und Hydra zu einem automatisierten Prüfpfad verknüpfen lassen und welche Maßnahmen nötig sind, um Prüfungen störungsarm und nachvollziehbar im Produktivumfeld durchzuführen.
Nmap liefert die erkannten Dienste und ihre Version. Ncrack übernimmt die schnelle, parallele Authentifizierungsprüfung über viele Hosts. Hydra ergänzt das Set bei Webformularen und bei Diensten mit nicht-standardisierter Authentifizierungslogik. In der Praxis ergibt sich ein dreistufiger Prüfpfad: Entdecken Prüfen Vertiefen.
In der Praxis gliedert sich der Prüfablauf in drei Phasen. Entdecken steht für die systematische Erfassung offener Dienste und ihrer Versionen mit Nmap, um die tatsächlichen Angriffsflächen zu identifizieren. Prüfen bezeichnet breit angelegte, parallelisierte Passwortaudits mit Ncrack, die viele Hosts gleichzeitig durchlaufen und schnelle Trefferlisten liefern. Vertiefen meint gezielte, kontextsensitive Tests mit Hydra auf Webformulare und Protokolle mit spezieller Authentifizierungslogik, um einzelne Befunde zu verifizieren und reproduzierbare Angriffswege aufzudecken. Zusammengenommen ergibt sich ein effizienter Prüfpfad, der Angriffsflächen aufdeckt, Schwachstellen priorisiert und konkrete Nachbesserungen ermöglicht.
Installation und erste Einrichtung auf Kali
Kali Linux liefert beide Werkzeuge in den offiziellen Paketen. Auf Debian oder Ubuntu reicht ein einzelner Befehl um Ncrack und Hydra zu installieren. Beispiel für einer Testumgebung:
sudo apt update && sudo apt install ncrack hydra
Der Administrator legt ein Arbeitsverzeichnis an und schützt es mit restriktiven Rechten. Benutzerlisten und Passwortlisten liegen getrennt in diesem Verzeichnis, so lassen sich Prüfungen nachvollziehen und sensible Wortlisten vor unberechtigtem Zugriff schützen:
mkdir -p /root/credlists && chmod 700 /root/credlists
printf "root\nadmin\n" > /root/credlists/users.txt
printf "password\n123456\nP@ssw0rd\n" > /root/credlists/passwords.txt
chmod 600 /root/credlists/*
Die erste Anweisung erstellt rekursiv das Verzeichnis /root/credlists wenn es nicht existiert. Das Optionflag -p sorgt dafür, dass alle erforderlichen Elternverzeichnisse angelegt werden und kein Fehler entsteht, wenn das Verzeichnis bereits vorhanden ist. Der nachfolgende Befehl chmod 700 setzt die Dateirechte, so dass nur der Eigentümer Vollzugriff hat. Der numerische Wert 700 bedeutet Lese-, Schreib- und Ausführungsrecht für den Eigentümer und keinerlei Rechte für Gruppe und Andere.
Die beiden printf-Befehle erzeugen die Textdateien users.txt und passwords.txt im Arbeitsverzeichnis. Jeder Eintrag steht in einer neuen Zeile das wird durch die Escape-Sequenz \n erzeugt. Die Umleitung > schreibt den Inhalt in die jeweilige Datei und überschreibt vorhandene Dateien. Falls die Listen ergänzt werden sollen kann >> verwendet werden um an das Ende anzuhängen. Der Befehl chmod 600 setzt für alle Dateien im Verzeichnis Leserecht und Schreibrecht nur für den Eigentümer. Der numerische Modus 600 verhindert Lesezugriff durch Gruppe und Andere. Damit bleiben sensible Passwortlisten vor unbefugtem Zugriff geschützt.
Alle Dateien sollen dem Prüf-Account gehören zum Beispiel dem Benutzer root oder einem dedizierten Prüfbenutzer. Eigentümer und Gruppenzugehörigkeit lassen sich mit chown anpassen. Beim Einsatz in Kubernetes oder beim Weiterreichen an Scanner wie Ncrack empfiehlt sich ein zusätzliches Backup der Listen und eine sichere Löschung nach Abschluss der Tests. In Automatisierungsumgebungen ist darauf zu achten, dass Secrets korrekt als Kubernetes Secret angelegt werden und dass am Ende der Datei eine leere neue Zeile steht um Parsing-Schäden zu vermeiden.
Für Ncrack empfiehlt sich zusätzlich OpenSSL auf Unix-Systemen. Logs und XML-Ausgaben speichern Metadaten für die Nachbearbeitung.
Serviceerkennung und selektive Übergabe an Ncrack
Zuerst erfolgt die Erkennung offener Dienste und der zugehörigen Versionen:
sudo nmap -sS -sV -oX scan.xml 10.0.4.0/24
Die XML-Ausgabe von Nmap dient als präzise Basis für Ncrack. Der direkte Import vermeidet unnötigen Verkehr. Der Befehl nutzt Nmap mit folgenden Parametern:
-sS führt einen TCP-SYN-Scan durch. Dabei sendet Nmap ein TCP-SYN an einen Port und wertet die erste Antwort aus. Er ist schnell und verursacht kein vollständiges Dreiwege-Handshake, deshalb belastet er das Ziel weniger, kann aber IDS/Firewall-Alarme auslösen.
-sV aktiviert die Versionserkennung. Nmap schickt zusätzlich gezielte Probes an offene Dienste, um Diensttyp und Versionsinformationen zu ermitteln. Das erzeugt mehr Netzwerkverkehr als ein einfacher Portscan, liefert dafür aber entscheidende Details für die weitere Analyse.
-oX scan.xml schreibt die Scan-Ergebnisse im XML-Format in die Datei scan.xml. Die XML-Struktur enthält Hosts, offene Ports, gefundene Dienste, Banner-Texte und die ermittelten Versionsangaben in maschinenlesbarer Form.
10.0.4.0/24 ist das Zielnetz im CIDR-Format. Nmap prüft alle 256 Adressen in diesem Subnetz.
Warum die XML-Ausgabe eine präzise Basis für Ncrack ist
Die XML-Datei enthält genau die Hosts und Ports, die tatsächlich offen sind, sowie die erkannten Diensttypen und Portnummern. Ncrack kann diese Datei direkt einlesen (-iX scan.xml) und anschließend nur die wirklich relevanten Dienste prüfen. Das spart unnötigen Verkehr gegenüber einem vollständigen erneuten Scan und reduziert die Last im Zielnetz. Außerdem übernimmt Ncrack die Port- und Dienstinformationen, so dass es das passende Modul wählt und keine Zeit mit Tests gegen nicht vorhandene Dienste verliert.
Kurzes Beispiel für den Anschluss an Ncrack
ncrack -v -iX scan.xml -U users.txt -P passwords.txt
So verwendet Ncrack die Nmap-XML-Ausgabe als Input und führt nur Authentifizierungsprüfungen gegen die in scan.xml bestätigten, offenen Dienste durch.
ncrack -v -iX scan.xml -U /root/credlists/users.txt -P /root/credlists/passwords.txt
Auf diese Weise prüft Ncrack nur tatsächlich offene Authentifizierungsdienste und passt Module automatisch an nicht standardisierte Ports an.
Ncrack Praxisbeispiele und Tuning
Ncrack skaliert durch Timing Vorlagen und feingranulare Optionen. Ein Beispiel für ein Netzsegment:
ncrack -v 10.0.4.0/24 -p ssh,ftp:3500 -g CL=3,to=1h
In diesem Aufruf begrenzt CL die maximal parallel offenen Verbindungen. Die Option to setzt eine Gesamtzeitbegrenzung pro Service. Für diskretes Vorgehen eignet sich ein vorsichtiges Template:
ncrack -v -T1 -iL hosts.txt -U users.txt -P passwords.txt -p ssh,rdp -g cd=500ms,at=1
Die Option at begrenzt die Anzahl an Authentifizierungsversuchen pro Verbindung. Das reduziert Alarmierungswahrscheinlichkeit in Intrusion-Detection-Systemen.
Ein konkreter Einzelscan gegen SSH mit gezielter Hostliste:
ncrack -v -iL hosts.txt -U /root/credlists/users.txt -P /root/credlists/passwords.txt -p ssh -g CL=2,at=2
Ncrack unterstützt eine Vielzahl von Protokollen, darunter SSH, RDP, FTP, VNC, SMB und mehrere NoSQL-Datenbanken. Jedes Modul bildet die jeweiligen Authentifizierungsschritte des Protokolls exakt nach und ermöglicht dadurch präzise und reproduzierbare Prüfungen.
Über spezifische Moduloptionen lässt sich das Verhalten von Ncrack im Detail anpassen. Die Option path legt bei Webmodulen den zu testenden Pfad fest, zum Beispiel /admin/login.php. Die Option db definiert bei Datenbankmodulen den Namen der Zieldatenbank, etwa db=admin. Mit domain kann bei Windows-basierten Diensten wie WinRM eine Domäne angegeben werden, beispielsweise domain=CORP. Einige typische Aufrufe verdeutlichen die Anwendung dieser Parameter:
ncrack http://10.0.1.230,path=/admin/login.php
ncrack mongodb://10.0.1.230,db=admin
ncrack winrm://10.0.1.230,domain=CORP
ncrack ssh://10.0.1.230:22,cl=5,at=2
Die Kombination dieser Optionen ermöglicht sehr gezielte Tests. Administratoren können damit bestimmen, welche Dienste mit welchen Parametern geprüft werden, unnötigen Netzwerkverkehr vermeiden und gleichzeitig die Aussagekraft der Ergebnisse erhöhen.
Jedes Modul implementiert die für das Protokoll nötigen Authentifizierungsschritte und erlaubt so zuverlässige Prüfungen statt willkürlicher Anfragen. Moduloptionen erlauben eine feingranulare Steuerung der Prüfparameter damit Tests zielgenau und effektiver ausfallen.
Beispiele für konkrete Moduloptionen und ihre Wirkung:
HTTP-Login an einem speziellen Pfad prüfen:
ncrack http://10.0.1.230,path=/admin/login.php
MongoDB gegen die Datenbank admin prüfen:
ncrack mongodb://10.0.1.230,db=admin
WinRM mit definierter Domäne prüfen:
ncrack winrm://10.0.1.230,domain=CORP
Per-host Timing und Authentifizierungsversuche setzen:
ncrack ssh://10.0.1.230:22,cl=5,at=2
Optionen kurz erklärt:
path legt bei Webmodulen den zu testenden URL Pfad fest, so dass nur der relevante Login Endpunkt geprüft wird.
db bestimmt bei Datenbankmodulen den Zieldatenbanknamen, so dass Ncrack die korrekte Authentifizierungsroutine nutzt.
domain übergibt bei Windows bezogenen Diensten die Anmeldedomäne, so dass Authentifizierungsversuche in den richtigen Kontext erfolgen.
Zusätzliche Steuerungsmöglichkeiten
Per Moduloption -m lassen sich Einstellungen auf alle Instanzen eines Modultyps anwenden zum Beispiel -m http:path=/admin/login.php.
Mit -g lassen sich globale Parameter definieren, die für alle Dienste gelten zum Beispiel -g CL=20.
Per-Host-Optionen haben die höchste Priorität und überschreiben modulweite und globale Einstellungen.
Diese Feinsteuerung erhöht die Trefferquote, reduziert Fehlversuche und minimiert unnötigen Traffic im Zielnetz.
Hydra Praxisbeispiele und Formularangriffe
Hydra bietet flexible Formulardefinitionen und Platzhalter für Benutzer und Passwort. Ein typischer SSH-Einzeiler:
hydra -l root -P /root/credlists/passwords.txt 10.0.4.50 ssh -t 8 -V
Der Aufruf startet einen gezielten Passwort-Brute-Force-Angriff gegen den SSH-Dienst auf dem Host 10.0.4.50. Hydra versucht nacheinander Passwörter aus der Datei /root/credlists/passwords.txt für den Benutzernamen root.
-l root gibt einen einzelnen Benutzernamen vor. Hydra testet ausschließlich Kombinationen mit diesem Login.
-P /root/credlists/passwords.txt übergibt den Pfad zur Passwortliste. Jede Zeile der Datei wird als Kandidat verwendet.
10.0.4.50 ist die Zieladresse.
ssh teilt Hydra das zu testende Protokoll mit, hier SSH auf dem Standardport 22.
-t 8 legt die Anzahl paralleler Tasks fest. Hydra öffnet bis zu acht gleichzeitige Verbindungen, beziehungsweise führt acht gleichzeitige Prüfungen durch.
-V aktiviert die ausführliche Ausgabe. Hydra zeigt jede getestete Benutzer/Passwort-Kombination und zusätzliche Statusmeldungen an.
Durch -t 8 erhöht sich die Geschwindigkeit gegenüber dem sequenziellen Test deutlich. Gleichzeitig steigen die Last auf Zielsystem und Netzwerk sowie die Chance, von Abwehrmechanismen erkannt oder von der SSH-Diensteinstellung (zum Beispiel Ratenbegrenzung, Account Lockout) blockiert zu werden. Bei sehr hoher Parallelität droht außerdem eine Beeinträchtigung des Zielsystems bis hin zu kurzzeitigem Dienstausfall.
Die Option -V erzeugt viel Ausgabe. Sie ist nützlich zur Diagnose und zur Überwachung des aktuellen Prüffortschritts, kann aber in großen Tests die Konsole fluten oder Logdateien schnell sehr groß werden lassen.
Solche Tests dürfen natürlich nur mit ausdrücklicher Genehmigung durchgeführt werden. Auf Produktivsystemen empfiehlt sich eine abgesprochene Testzeit und reduziertes Timing. Beachten Sie, dass Intrusion-Detection-Systeme und Schutzdienste wie fail2ban oder CrowdSec aktive Brute-Force-Versuche melden und die Herkunftsadresse sperren können. Ebenfalls üblich sind SSH-Diensteinstellungen, die nach einer definierten Zahl fehlgeschlagener Anmeldeversuche den Account sperren oder Verbindungen trennen.
Tipps für den praktischen Einsatz
Wenn SSH auf einem Nicht-Standardport läuft, ergänzen Admins -s <port>. Beispiel: -s 2222
Für mehrere Benutzer kann -L users.txt anstelle von -l verwendet werden. Wenn nur das erste gefundene Credential relevant ist, kommt -f zum Einsatz, damit Hydra die Arbeit für diesen Host beendet, sobald ein Treffer vorliegt. Zur Reduktion der Erkennungswahrscheinlichkeit wird -t verringert oder auf -w/-W wenn verfügbar gesetzt. Auch das Nutzen von längeren Verbindungsverzögerungen auf der Nmap/Ncrack-Seite ist sinnvoll. Auf dem Zielsystem sollten parallel noch die Logs genutzt werden, zum Beispiel mit journalctl -u ssh -f, um Effekte und erfolgreiche Anmeldungen live zu sehen.
Beispielausgabe und Interpretation
Bei Erfolg zeigt Hydra typischerweise eine Zeile mit dem gefundenen Credential, zum Beispiel
[80][ssh] host: 10.0.4.50 login: root password: P@ssw0rd
Diese Zeile bedeutet, dass das getestete Passwort für den Benutzer root auf dem Host funktioniert.
Kurzempfehlung:
Vor Tests prüfen, ob das Ziel in Scope und genehmigt ist. Mit -t so konservativ wie nötig arbeiten. -V nur zur Fehlersuche oder bei kleinen Tests verwenden. Nach dem Test Bereinigung und sichere Aufbewahrung der Ergebnisdateien sicherstellen.
Für HTTP-Formulare ist die Syntax platzhalterbasiert. Beispiel für ein POST-Login:
hydra 10.7.7.5 http-form-post "/owaspbricks/login-3/index.php:username=^USER^&passwd=^PASS^&submit=Submit:Wrong user name or password." -L users.txt -P passwords.txt -t 16
Die korrekte Fehlernachricht nach dem Punkt ist ausschlaggebend für die Treffererkennung. Vor einem breit angelegten Versuch empfiehlt sich ein Validierungsschritt mit einem bekannten Zugang.
Beispiel für VNC mit Passwortfokussierter Iteration:
hydra -P vnc_passwords.txt --passwords-first 10.0.4.20 vnc -t 4 -V
Der Befehl startet einen gezielten Passwortangriff gegen den VNC-Dienst auf dem Host 10.0.4.20. Die Option -P vnc_passwords.txt übergibt die Passwortliste, jede Zeile der Datei gilt als ein Kandidat. Mit --passwords-first ändert Hydra die Iterationsreihenfolge so, dass für ein Benutzerkonto alle Passwörter nacheinander getestet werden, bevor zum nächsten Benutzer gewechselt wird.
Bei VNC ist dieses Verhalten sinnvoll, weil viele Implementierungen nur ein Passwort verwenden und Benutzernamen keine Rolle spielen. Der Parameter vnc weist Hydra an, das VNC-Modul zu nutzen und damit die protokollspezifische Authentifizierungsabfolge zu fahren. Mit -t 4 setzt Hydra vier parallele Tasks, wodurch die Prüfgeschwindigkeit steigt, und die Gesamtzeit sinkt. Gleichzeitig steigen damit die Belastung von Zielsystem und Netzwerk und die Erkennungswahrscheinlichkeit durch Abwehrsysteme. Die Option -V aktiviert die ausführliche Ausgabe, so dass jede getestete Kombination und Statusmeldungen protokolliert erscheinen. In produktiven Umgebungen empfiehlt sich vorsichtiges Timing, Überwachung der Zielprotokolle und Absprache mit dem Betreiber, da hoher Parallelismus Account-Sperren, Anomaliealarme oder Dienstbeeinträchtigungen auslösen kann.
Kombination von Ncrack und Hydra in Workflows
Kombinierte Workflows verbinden die jeweiligen Stärken der Werkzeuge und folgen einem klaren Prüfpfad von Breite zu Tiefe. Zuerst erfolgt die Netzerkundung mit dem SYN Scan und der Versionserkennung durch
sudo nmap -sS -sV -oX scan.xml 10.0.4.0/24
wobei sudo rohe Sockets erlaubt, -sS schnelle SYN Probes sendet, -sV Diensttypen sowie Versionen ermittelt und -oX die Ergebnisse im maschinenlesbaren XML-Format ablegt.
Die so erzeugte XM- Datei dient Ncrack als präzise Zielbasis und vermeidet unnötige Redundanz im Netzwerkverkehr. Anschließend startet die breit angelegte Authentifizierungsprüfung mit
ncrack -v -iX scan.xml -U users.txt -P passwords.txt -g CL=4,to=2h
wobei -v die Ausgabe erhöht, -iX die Nmap-XML-Datei importiert, -U und -P Benutzer sowie Passwortlisten liefern und -g CL=4,to=2h globale Moduleinstellungen setzen, die die maximale Parallelität begrenzen und die maximale Prüfzeit auf zwei Stunden festlegen. Für die Fokussierung auf Webdienste wandelt ein XSLT-Transformationsschritt mit xsltproc nmap2hosts.xsl scan.xml > webhosts.txt die Nmap-XML-Ausgabe in eine Zieltabelle um, die nur Webserver enthält.
Auf dieser gefilterten Zielmenge setzt Hydra an, um Formular-Logins tiefgehend zu testen mit
hydra -M webhosts.txt http-form-post "/login.php:username=^USER^&password=^PASS^:Login failed" -L webusers.txt -P webpasses.txt -t 24 -V
wobei -M eine Zielliste einliest, das Modul http-form-post den POST-Loginpfad und das Muster für fehlgeschlagene Logins angibt, -L und -P Nutzer und Passwörter bereitstellen, -t 24 die Parallelität regelt und -V ausführliche Statusmeldungen erzeugt. Dieses Muster nutzt Ncrack für die schnelle Breitenwirkung und Hydra für kontextsensitive Vertiefung. Ncrack findet zügig schwache Standardanmeldepunkte in vielen Diensten, Hydra erlaubt dann detaillierte Manipulationen bei Formularen, zum Beispiel das Einfügen dynamischer Felder oder das Handling von Session Tokens und Captchas.
Skalierung Automatisierung und Kubernetes Integration
Die kombinierte Prüfung lässt sich in automationsfähige Abläufe überführen und in Kubernetes betreiben, so dass regelmäßige Audits in CI-Jobs (Continuous Integration) oder als CronJobs laufen. Passwortlisten werden als Kubernetes Secret abgelegt und nur dem Scan-Job zugänglich gemacht. So bleiben die sensiblen Dateien in einem Cluster-internen Schutzraum mit eingeschränkten Rechten. Ein kurzes Installationsbeispiel zeigt die benötigten Schritte in Klartext und als Helm-Parameter:
kubectl create secret generic --from-file=users.txt --from-file=passwords.txt ncrack-lists
helm upgrade --install ncrack oci://ghcr.io/securecodebox/helm/ncrack --set scanner.extraVolumes[0].secret.secretName=ncrack-lists
SecureCodeBox orchestriert den Scan als Container-Job und liefert Mechanismen zur Verschlüsselung und standardisierten Nachverarbeitung der Ergebnisse. Bei SecureCodeBox handelt es sich um ein Open-Source-Projekt der OWASP-Community, das Sicherheitsprüfungen in automatisierten Infrastrukturen orchestriert.
Die Plattform integriert gängige Scanner wie Nmap, Ncrack, Hydra, Nikto oder Trivy in standardisierte Workflows und führt sie innerhalb von Kubernetes-Umgebungen als Container-Jobs aus. Jeder Scanner läuft isoliert in einem Pod und gibt seine Ergebnisse an Parser-Jobs weiter, die Rohdaten in strukturierte Findings überführen. Diese Findings werden anschließend verschlüsselt gespeichert oder an externe Systeme wie Defect-Tracker oder SIEM-Plattformen weitergereicht. Im Unterschied zu klassischen Einzelaufrufen erlaubt SecureCodeBox die kontinuierliche Wiederholung von Scans und damit ein laufendes Monitoring sicherheitsrelevanter Dienste. Prüfungen können über Helm-Charts definiert, zeitgesteuert oder in CI/CD-Pipelines eingebunden werden. Durch den modularen Aufbau lassen sich Ncrack und Hydra als eigenständige Scanner oder als Teil größerer Prüfkaskaden einsetzen.
Das Bereitstellen der Eingabedaten erfolgt über Kubernetes Secrets, die nur während des jeweiligen Scanlaufs eingebunden werden. Passwörter und Benutzerlisten bleiben damit im Cluster geschützt. Die Option encryptPasswords.existingSecret erlaubt die Verwendung eines öffentlichen Schlüssels, um gefundene Zugangsdaten direkt bei der Ausgabe zu verschlüsseln. Parserjobs übernehmen anschließend die Auswertung, bewerten die Ergebnisse nach Schweregrad und bereiten sie für automatisierte Reports auf.
Damit wird SecureCodeBox zu einer Plattform, die Sicherheitsscans reproduzierbar, skalierbar und revisionssicher in bestehende IT-Abläufe integriert. Für regelmäßige Audits und Compliance-Prüfungen in komplexen Netzumgebungen bietet sie eine zentrale, konsistente Grundlage, um Werkzeuge wie Ncrack und Hydra kontrolliert, nachvollziehbar und sicher zu betreiben.
Gefundene Passwörter lassen sich mit einer öffentlichen Age-Schlüsseldatei verschlüsseln, so dass nur Inhaber des privaten Schlüssels die Klartexte entschlüsseln können. Die Verschlüsselung aktiviert man über den Helm-Wert encryptPasswords.existingSecret und erzeugt das zugehörige Kubernetes Secret mit dem öffentlichen Schlüssel. SecureCodeBox führt außerdem vordefinierte Parser-Jobs aus, die die Rohausgaben von Ncrack und Hydra in strukturierte Findings überführen, Metadaten ergänzen und sensible Felder markieren. Dadurch entstehen auditfähige Reports, die in Ticketing oder SIEM Systeme eingespeist werden können.
