Mit Nmap: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Nmap wird im Purple Teaming oft unterschätzt, weil viele Teams das Werkzeug nur als simplen Portscanner betrachten. In der Praxis ist Nmap jedoch weit mehr als ein Tool zum Auflisten offener Ports. Es ist ein präzises Instrument, um Annahmen über Sichtbarkeit, Erkennung, Segmentierung, Härtung und Reaktionsfähigkeit zu überprüfen. Genau darin liegt der Wert für Purple Teaming: Red- und Blue-Perspektive arbeiten nicht gegeneinander, sondern an derselben Frage, nämlich welche Aktivitäten sichtbar sind, wie sie interpretiert werden und welche Lücken zwischen technischer Realität und Sicherheitsannahmen bestehen.

Ein sauber geplanter Nmap-Einsatz beantwortet nicht nur, welche Systeme erreichbar sind. Er zeigt auch, wie sich unterschiedliche Scanmethoden auf Firewalls, IDS, EDR, NetFlow, SIEM und Analysten-Workflows auswirken. Ein SYN-Scan erzeugt andere Spuren als ein Connect-Scan. Ein aggressives Timing verhält sich anders als ein langsamer, verteilungsähnlicher Scan. Ein DNS-basierter Discovery-Lauf hinterlässt andere Artefakte als ein ARP-Scan im lokalen Segment. Wer Purple Teaming ernsthaft betreibt, betrachtet Nmap deshalb nicht isoliert, sondern als Testgenerator für Detection, Triage und Response.

Im Unterschied zu reinem Pentesting steht nicht primär die Frage im Vordergrund, ob ein Dienst offen ist, sondern ob die Sicherheitsorganisation die Aktivität erkennt, korrekt einordnet und sinnvoll darauf reagiert. Das verbindet Nmap direkt mit Purple Teaming, mit einem strukturierten Workflow und mit belastbarer Und Detection Engineering. Ein Portscan ohne abgestimmte Beobachtung ist nur Technik. Ein Portscan mit Hypothese, Telemetrieabgleich und Nachbesserung ist Purple Teaming.

Typische Ziele eines Nmap-basierten Purple-Team-Szenarios sind die Validierung von Netzwerksegmentierung, die Überprüfung von Alarmregeln für Reconnaissance, die Bewertung von Asset-Inventaren, die Erkennung von Schatten-IT und die Messung, ob Security Monitoring zwischen legitimer Administration und verdächtiger Aufklärung unterscheiden kann. Gerade in größeren Umgebungen zeigt sich schnell, dass CMDB, Schwachstellenscanner, EDR-Inventar und tatsächliche Netzwerkrealität nicht deckungsgleich sind. Nmap macht diese Abweichungen sichtbar.

Ein weiterer Punkt ist die Übersetzbarkeit in operative Maßnahmen. Wenn ein Blue Team feststellt, dass ein bestimmter Scan nicht erkannt wurde, muss daraus mehr entstehen als ein einzelner Alarm. Es geht um Logquellen, Parser, Feldnormalisierung, Schwellenwerte, Segmentkontext, Ausnahmen für Management-Netze und die Frage, ob dieselbe Aktivität in Und Siem und Und Soc überhaupt konsistent sichtbar ist. Nmap eignet sich deshalb hervorragend als kontrollierbarer Stimulus für wiederholbare Übungen.

Wer Nmap im Purple Teaming einsetzt, sollte das Werkzeug nicht als Selbstzweck behandeln. Entscheidend ist die Verbindung aus Zieldefinition, technischer Durchführung, Beobachtung, Auswertung und Iteration. Genau diese Disziplin trennt einen zufälligen Scan von einem verwertbaren Sicherheitsnachweis.

Die meisten Fehler mit Nmap passieren nicht beim Befehl, sondern davor. Ein Purple-Team-Lauf ohne klaren Scope produziert unbrauchbare Ergebnisse, unnötige Störungen und Diskussionen über Zuständigkeiten statt über Sicherheit. Vor dem ersten Paket muss feststehen, welche Netze, Systeme, Zeitfenster und Scanarten erlaubt sind. Ebenso wichtig ist die Definition, welche Telemetriequellen beobachtet werden: Firewall-Logs, IDS/IPS, Zeek, NetFlow, EDR-Netzwerkereignisse, Windows Event Logs, Linux Audit, DNS-Logs, Proxy-Daten und SIEM-Korrelationen.

Ein guter Ansatz beginnt mit Hypothesen. Beispiele: Erkennt das SOC horizontale SYN-Scans innerhalb eines VLANs? Werden Service-Version-Scans gegen Server in einer DMZ als Reconnaissance klassifiziert? Löst ein langsamer Scan mit geringer Parallelität überhaupt einen Alarm aus? Werden interne DNS-Lookups im Zusammenhang mit Host Discovery korreliert? Solche Hypothesen machen aus einem technischen Test eine messbare Übung.

Ebenso wichtig ist die Abstimmung mit Betrieb und Netzwerkverantwortlichen. Nmap ist zwar kontrollierbar, kann aber je nach Optionen empfindliche Systeme beeinflussen. Alte Drucker, Embedded-Geräte, OT-Komponenten, Legacy-VoIP-Systeme oder proprietäre Appliances reagieren auf aggressive Service-Erkennung teilweise instabil. In klassischen IT-Netzen ist das meist beherrschbar, in Produktionsumgebungen oder bei kritischen Diensten nicht. Deshalb muss vorab geklärt werden, welche Hosts nur mit Discovery, welche mit Portscan und welche gar nicht getestet werden dürfen. In sensiblen Bereichen ist eine enge Verzahnung mit Im Ot Bereich und Kritis Pflicht.

• Scope schriftlich festlegen: Netze, Hosts, Zeitfenster, erlaubte Scanarten, Ausschlüsse.
• Telemetriequellen benennen: Firewall, IDS, EDR, DNS, NetFlow, SIEM, Ticketing.
• Hypothesen definieren: Was soll erkannt, korreliert, priorisiert oder eskaliert werden?
• Erfolgskriterien festlegen: Alarm vorhanden, richtige Klassifizierung, Reaktionszeit, Qualität der Analyse.

Ein weiterer Vorbereitungsfehler ist fehlende Baseline. Ohne Kenntnis normaler Netzwerkaktivität lässt sich schwer beurteilen, ob ein Scan auffällig war oder im Rauschen unterging. Deshalb lohnt es sich, vor der Übung typische Admin-Scans, Monitoring-Traffic und Schwachstellenscanner zu dokumentieren. Erst dann wird sichtbar, ob Nmap-Verhalten von legitimen Betriebsaktivitäten unterscheidbar ist. Diese Trennung ist ein Kernpunkt von Und Threat Detection.

Schließlich gehört zur Vorbereitung auch die Frage nach Dokumentation und Wiederholbarkeit. Alle Befehle, Parameter, Startzeiten, Quellhosts, Zielbereiche und Beobachtungen müssen sauber erfasst werden. Nur so lässt sich ein Test später reproduzieren, nach einer Regelanpassung erneut fahren und objektiv vergleichen. Ohne diese Disziplin bleibt Purple Teaming ein einmaliges Ereignis statt eines belastbaren Verbesserungsprozesses.

Bevor Ports gescannt werden, muss geklärt werden, welche Systeme überhaupt erreichbar sind. Genau hier entstehen oft die ersten Fehlinterpretationen. Viele Teams verlassen sich auf Standard-Discovery mit ICMP Echo und wundern sich, warum große Teile eines Netzes als down erscheinen. In realen Umgebungen blockieren Firewalls ICMP, Hosts antworten selektiv oder Security Controls filtern bestimmte Pakete. Ein nicht antwortender Host ist deshalb nicht automatisch nicht vorhanden.

Nmap bietet mehrere Discovery-Methoden, die je nach Netzsegment und Zieltyp unterschiedlich sinnvoll sind. Im lokalen Netz ist ARP-Discovery meist am zuverlässigsten, weil Hosts auf Layer 2 sichtbar werden, selbst wenn ICMP blockiert ist. In gerouteten Netzen können TCP-SYN-Pings auf typische Ports, ACK-Pings oder UDP-basierte Discovery sinnvoller sein. DNS-Auflösung kann zusätzliche Hinweise liefern, erzeugt aber eigene Spuren und ist nicht mit tatsächlicher Erreichbarkeit gleichzusetzen.

Ein häufiger Fehler ist das Vermischen von Discovery und Portscan ohne klares Ziel. Wer mit Standardoptionen startet, erhält zwar Ergebnisse, weiß aber oft nicht, warum bestimmte Hosts fehlen. Besser ist ein gestufter Ansatz: zuerst Discovery mit bewusst gewählten Methoden, dann Validierung einzelner Hosts, danach erst Port- und Service-Analyse. So lässt sich sauber unterscheiden, ob ein Host nicht existiert, nicht antwortet oder durch Filterung verborgen wird.

Praxisnah ist auch die Gegenprobe aus Blue-Team-Sicht. Wenn ARP-Discovery in einem internen Segment durchgeführt wird, sollte geprüft werden, ob Switch-Telemetrie, NAC, EDR oder Netzwerkmonitoring diese Aktivität erfassen. Bei TCP-basierten Discovery-Methoden ist relevant, ob Firewalls Verbindungsversuche protokollieren und ob SIEM-Regeln horizontale Muster erkennen. Gerade langsame Discovery-Läufe zeigen oft, dass vorhandene Regeln nur auf hohe Frequenz reagieren und verteilte Reconnaissance übersehen.

Ein typischer Ablauf könnte so aussehen:

nmap -sn 10.10.20.0/24
nmap -sn -PR 10.10.20.0/24
nmap -sn -PS22,80,443,3389 10.10.30.0/24
nmap -sn -PA80,443 10.10.40.0/24
nmap -Pn 10.10.50.15

Der letzte Befehl ist besonders wichtig zu verstehen. -Pn bedeutet nicht, dass ein Host sicher online ist, sondern dass Nmap die Host-Discovery überspringt und direkt scannt. Das ist nützlich, wenn Discovery blockiert wird, erhöht aber Scanzeit und kann zu mehr Rauschen führen. In Purple-Team-Szenarien ist -Pn oft sinnvoll, um zu prüfen, ob Security Controls Hosts zwar vor Discovery verbergen, aber nicht vor gezielter Portanalyse schützen.

Die eigentliche Erkenntnis aus Discovery-Phasen liegt selten nur in der Hostliste. Wertvoll ist der Vergleich zwischen erwarteten Assets, tatsächlich erreichbaren Systemen und den Spuren in Monitoring-Systemen. Genau daraus entstehen belastbare Maßnahmen für Inventarisierung, Segmentierung und Erkennung.

Der Portscan ist der sichtbarste Teil von Nmap, aber auch der Bereich mit den meisten Missverständnissen. Ein SYN-Scan mit -sS ist schnell und effizient, weil keine vollständige TCP-Verbindung aufgebaut wird. Ein Connect-Scan mit -sT nutzt dagegen den Betriebssystem-Stack und ist dort relevant, wo Raw-Socket-Zugriff fehlt. Für Detection und Forensik ist der Unterschied erheblich: Je nach Sensorik erscheinen SYN-Scans eher als halboffene Verbindungsversuche, während Connect-Scans deutlicher in Host-Logs und Applikationsspuren auftauchen können.

Timing ist kein kosmetischer Parameter, sondern beeinflusst sowohl Scanqualität als auch Erkennbarkeit. Viele Teams verwenden reflexartig -T4 oder -T5, weil Ergebnisse schneller vorliegen. In Purple-Team-Übungen ist das oft kontraproduktiv. Ein aggressiver Scan testet primär, ob grobe Schwellenwerte anschlagen. Ein langsamer, kontrollierter Scan zeigt dagegen, ob Detection auch bei realistischerem Verhalten funktioniert. Angreifer scannen nicht immer laut. Gerade interne Reconnaissance erfolgt häufig gedrosselt, segmentweise und mit Pausen.

Wichtige Stellschrauben sind Parallelität, Retries, Hostgruppen und Rate-Limits. Wer diese Parameter versteht, kann sehr gezielt testen, welche Erkennungsmuster robust sind und welche nur auf offensichtliche Last reagieren. Ein Beispiel:

nmap -sS -p 1-1024 --max-retries 2 --min-rate 50 --max-rate 100 10.10.20.15
nmap -sS -p 22,80,443,445,3389 -T2 --scan-delay 500ms 10.10.20.0/24
nmap -sT -p 445,3389 --max-hostgroup 8 --min-parallelism 1 10.10.30.0/24

Der erste Scan ist kontrolliert schnell, der zweite bewusst langsam und horizontal, der dritte reduziert Parallelität und Hostgruppen, um ein unauffälligeres Muster zu erzeugen. Für das Blue Team ist genau dieser Vergleich wertvoll. Wenn nur der erste Scan erkannt wird, ist die Detection zu stark auf Lautstärke statt auf Verhalten ausgerichtet.

Auch UDP-Scans verdienen Aufmerksamkeit. Viele Umgebungen fokussieren sich auf TCP und übersehen DNS, SNMP, NTP, TFTP oder proprietäre UDP-Dienste. UDP-Scanning mit -sU ist langsamer und fehleranfälliger, weil fehlende Antworten schwer zu interpretieren sind. Trotzdem ist es für Purple Teaming wichtig, weil es Monitoring-Lücken offenlegt. Ein offener SNMP-Dienst oder ein exponierter DNS-Resolver ist oft sicherheitsrelevanter als ein zusätzlicher Webport.

Ein weiterer häufiger Fehler ist das Scannen aller 65535 Ports ohne Begründung. Das erzeugt viel Last, verlängert die Übung und liefert oft wenig zusätzlichen Erkenntnisgewinn. Besser ist eine zielgerichtete Portauswahl nach Use Case: Administrationsports, typische Serverdienste, Datenbankports, Remote-Management, Legacy-Protokolle. Vollscans sind sinnvoll, wenn Asset-Typ und Exposition unbekannt sind oder wenn bewusst die Reaktion auf breite Reconnaissance getestet werden soll. In allen anderen Fällen ist Präzision meist wertvoller als Vollständigkeit.

Im Purple-Team-Kontext sollte jeder Portscan mit einer Beobachtungsfrage verknüpft sein: Welche Sensoren sehen den Scan? Welche Felder landen im SIEM? Gibt es Korrelation über mehrere Ziele? Wird zwischen internem Admin-Host und verdächtigem Quellsystem unterschieden? Diese Fragen verbinden Nmap direkt mit Und Log Analyse und Und Alerting.

Mit offenen Ports allein ist selten viel gewonnen. Erst Service-Erkennung und Versioning machen Ergebnisse operativ verwertbar. Nmap nutzt dafür Banner, Protokoll-Interaktionen und Signaturen, um Dienste auch dann zu identifizieren, wenn sie auf untypischen Ports laufen. Genau das ist im Purple Teaming relevant, weil Sicherheitsannahmen oft an Portnummern hängen. Ein interner Dienst auf Port 8443 wird vielleicht überwacht, ein proprietärer Webservice auf 9443 dagegen nicht. Version Detection mit -sV deckt solche Abweichungen auf.

Allerdings steigt mit tieferer Interaktion auch das Risiko von Seiteneffekten. Manche Dienste reagieren empfindlich auf ungewöhnliche Probes, insbesondere ältere Middleware, industrielle Gateways, Embedded-Webserver oder schlecht implementierte Protokollstacks. Deshalb sollte Service-Erkennung nicht blind auf ganze Netze losgelassen werden. Besser ist ein gestufter Ablauf: Discovery, Portscan, Auswahl relevanter Hosts, dann gezielte Version Detection. In kritischen Umgebungen wird zusätzlich mit Betrieb und Asset-Verantwortlichen abgestimmt, welche Systeme ausgeschlossen bleiben.

Besonders mächtig ist die Nmap Scripting Engine. NSE kann Informationen sammeln, Konfigurationen prüfen, Standardzugänge testen, TLS-Parameter auslesen, SMB-Freigaben enumerieren oder Schwachstellenindikatoren erkennen. Genau hier liegt aber auch die Grenze zwischen kontrollierter Übung und unnötiger Belastung. Nicht jedes Script ist rein passiv. Einige führen tiefe Protokollinteraktionen aus, manche können Accounts locken, Logs fluten oder fragile Systeme destabilisieren.

• -sV gezielt auf bestätigte Hosts anwenden, nicht reflexartig auf ganze Adressräume.
• NSE-Kategorien prüfen: safe und default sind nicht automatisch risikofrei in jeder Umgebung.
• Vor produktionsnahen Tests Script-Dokumentation lesen und Seiteneffekte bewerten.
• Ergebnisse immer gegen echte Telemetrie und Asset-Kontext validieren.

Praxisbeispiele:

nmap -sV -p 80,443,8080,8443 10.10.20.15
nmap --script banner,http-title -p 80,443,8080 10.10.20.0/24
nmap --script ssl-cert,ssl-enum-ciphers -p 443,8443 10.10.30.15
nmap --script smb-os-discovery,smb-enum-shares -p 445 10.10.40.25

Diese Befehle sind technisch einfach, aber analytisch wertvoll. Ein TLS-Scan zeigt nicht nur Cipher Suites, sondern auch, ob entsprechende Verbindungen in Proxy-, Firewall- oder IDS-Daten sichtbar sind. SMB-Enumeration zeigt nicht nur Freigaben, sondern auch, ob Host-basierte Sensoren die Aktivität als verdächtig markieren. HTTP-Banner und Titel helfen, Schatten-Services zu identifizieren, die in Inventaren fehlen.

Ein häufiger Fehler ist die Gleichsetzung von NSE mit Schwachstellenscanning. Nmap kann Hinweise liefern, ersetzt aber kein vollständiges Vulnerability Management. Im Purple Teaming geht es hier primär um Sichtbarkeit und Reaktion: Welche Enumeration wird erkannt, welche nicht, und wie gut kann das Blue Team die Aktivität kontextualisieren? Für weitergehende Angriffssimulationen kann die Verzahnung mit Mit Metasploit sinnvoll sein, wenn aus Reconnaissance kontrolliert in Exploitation-nahe Tests übergegangen werden soll.

Saubere Teams trennen deshalb klar zwischen Informationsgewinnung, Konfigurationsprüfung und exploitnahen Schritten. Diese Trennung verhindert Missverständnisse, reduziert Risiko und macht Ergebnisse belastbar.

Der eigentliche Mehrwert von Nmap im Purple Teaming entsteht erst bei der Auswertung der Sichtbarkeit. Ein Scan ist kein Ergebnis, sondern ein Stimulus. Entscheidend ist, welche Sensoren anschlagen, welche Felder erfasst werden und ob daraus eine verwertbare Erkennung entsteht. In vielen Umgebungen existieren zwar Logs, aber keine belastbare Korrelation. Firewall-Daten zeigen Verbindungsversuche, IDS erkennt Portscan-Muster, EDR sieht Netzwerkaktivität auf dem Quellhost, doch im SIEM entsteht daraus kein priorisierter Fall. Genau diese Brüche müssen sichtbar gemacht werden.

Ein guter Detection-Abgleich beginnt mit einer Matrix: Scanart, Quelle, Zielsegment, erwartete Telemetrie, tatsächliche Telemetrie, Alarmstatus, Analystenbewertung. So lässt sich präzise feststellen, ob ein SYN-Scan gegen Server erkannt wurde, ein langsamer Connect-Scan gegen Clients aber nicht. Ebenso wird sichtbar, ob DNS-Lookups, Reverse-Lookups oder SMB-Enumeration isoliert betrachtet werden, obwohl sie zusammen ein klares Reconnaissance-Bild ergeben.

Besonders wertvoll ist die Unterscheidung zwischen Netzwerk- und Hostsicht. Ein interner Scan kann auf Netzwerkebene klar sichtbar sein, während der Quellhost im EDR kaum auffällt, etwa weil Nmap portabel ausgeführt oder in Admin-Kontexten toleriert wird. Umgekehrt kann ein Hostsensor Prozessstarts und Socket-Aktivität erkennen, während Netzwerkmonitoring durch Segmentgrenzen oder fehlende Sensorplatzierung blind bleibt. Purple Teaming muss beide Perspektiven zusammenführen.

Für die Auswertung sollten mindestens folgende Fragen beantwortet werden: Wurde die Aktivität erkannt? Wurde sie korrekt als Reconnaissance klassifiziert? Wurde die Quelle richtig zugeordnet? Gab es Kontext zum Asset-Wert des Ziels? Wurde ein Ticket erzeugt? Wurde eskaliert? Wie lange dauerte es bis zur Sichtung? Ohne diese Fragen bleibt Detection Engineering abstrakt.

In SIEM-nahen Umgebungen lohnt sich die direkte Verknüpfung mit Mit Splunk oder Mit Elk Stack. Dort zeigt sich schnell, ob Parser Felder wie Quell-IP, Ziel-IP, Port, Aktion, Richtung und Sensorname sauber normalisieren. Schon kleine Parsing-Fehler verhindern Korrelationen über mehrere Datenquellen. Ein Portscan wird dann zwar in Rohlogs sichtbar, aber nie als zusammenhängendes Ereignis erkannt.

Ein weiterer Praxispunkt ist die Unterscheidung zwischen legitimer und verdächtiger Nutzung. In vielen Unternehmen scannen Schwachstellenscanner, Monitoring-Systeme oder Administratoren regelmäßig Netze. Wenn Nmap-ähnliche Aktivität pauschal als normal gilt, entsteht Blindheit. Detection muss deshalb Kontext einbeziehen: bekannte Scanner-IPs, Wartungsfenster, Service-Accounts, Management-Netze, Asset-Klassen und ungewöhnliche Quell-Ziel-Kombinationen. Ein Scan von einem Jump Host in ein Servernetz ist anders zu bewerten als derselbe Scan von einem Office-Client.

Die beste Purple-Team-Frage lautet hier nicht: Gibt es einen Alarm? Sondern: Kann ein Analyst innerhalb weniger Minuten erkennen, was passiert, warum es relevant ist und welche nächsten Schritte sinnvoll sind? Wenn die Antwort nein ist, liegt das Problem nicht nur in der Erkennung, sondern im gesamten Analysepfad.

Die häufigsten Fehler sind nicht technisch komplex, aber folgenreich. Der erste Fehler ist fehlende Zielklarheit. Ein Team startet einen Scan, sammelt Ergebnisse und versucht erst danach zu entscheiden, was eigentlich getestet wurde. Das führt fast immer zu Diskussionen über Tool-Ausgabe statt über Sicherheitswirkung. Jede Nmap-Aktivität braucht vorab eine Hypothese und ein Erfolgskriterium.

Der zweite Fehler ist falsche Interpretation von Zuständen. filtered, closed, open|filtered oder fehlende Antworten werden oft vorschnell als Sicherheitsnachweis gelesen. Tatsächlich sagen diese Zustände nur etwas über beobachtetes Verhalten unter bestimmten Bedingungen. Ein Port kann heute gefiltert erscheinen und morgen offen sein, weil ein anderes Quellsystem, ein anderes Segment oder ein anderer Pakettyp verwendet wird. Purple Teaming muss solche Mehrdeutigkeiten bewusst einplanen.

Der dritte Fehler ist übermäßige Aggressivität. Vollscans mit -A, hoher Geschwindigkeit und NSE auf ganze Netze liefern zwar viele Daten, aber oft wenig verwertbare Erkenntnis. Gleichzeitig steigt das Risiko von Störungen, Alarmmüdigkeit und unklaren Korrelationen. Wenn alles gleichzeitig passiert, lässt sich kaum noch sauber zuordnen, welcher Teil der Aktivität welchen Alarm ausgelöst hat.

Der vierte Fehler ist fehlende Zeitkorrelation. Scanstart, Scanende und einzelne Phasen werden nicht exakt dokumentiert. Dadurch kann das Blue Team Alarme nicht sauber zuordnen, und spätere Regelanpassungen lassen sich nicht verifizieren. Gerade bei langsamen oder mehrstufigen Scans ist präzises Timing entscheidend.

Der fünfte Fehler ist die Vernachlässigung von Gegenproben. Wenn ein Host nicht entdeckt wird, wird das Ergebnis oft akzeptiert. Besser ist eine Validierung mit alternativen Methoden, etwa gezieltem -Pn, TCP-basiertem Discovery oder manueller Verbindung. Nur so lässt sich unterscheiden, ob ein Host wirklich unsichtbar ist oder nur die gewählte Methode ungeeignet war. Viele der hier beschriebenen Probleme tauchen auch in Typische Fehler Beim Purple Teaming auf, werden mit Nmap aber besonders deutlich sichtbar.

• Keine Hypothese vor dem Scan: Ergebnislisten ohne Aussagekraft.
• Zu aggressive Optionen: unnötige Last, unklare Korrelation, vermeidbare Störungen.
• Fehlende Zeitstempel und Dokumentation: keine reproduzierbaren Erkenntnisse.
• Blindes Vertrauen in Standard-Discovery: Hosts werden fälschlich als nicht vorhanden bewertet.
• Keine Trennung zwischen Reconnaissance, Enumeration und exploitnahen Schritten.

Ein weiterer Fehler liegt auf Blue-Team-Seite: Alarme werden nur auf Frequenzschwellen gebaut. Das erkennt laute Scans, aber keine langsamen, verteilten oder zielgerichteten Muster. Ebenso problematisch sind Regeln, die nur bekannte Scanner-Ports oder Standard-Signaturen betrachten. Nmap ist flexibel genug, um viele dieser Annahmen zu umgehen, ohne dass dafür besondere Tarntechniken nötig wären.

Schließlich scheitern viele Übungen an schlechter Kommunikation. Wenn Red und Blue nicht dieselben Begriffe verwenden, werden Ergebnisse missverstanden. Ein Blue Team spricht von Netzwerk-Scan, das Red Team von Host Discovery, das Management von Angriffssimulation. Ohne gemeinsame Sprache entstehen falsche Erwartungen. Deshalb gehören klare Begriffe, saubere Dokumentation und abgestimmte Auswertung fest zum Prozess. Das ist kein Formalismus, sondern Voraussetzung für belastbare Verbesserungen.

Ein belastbarer Nmap-Workflow im Purple Teaming ist immer iterativ. Ziel ist nicht, in einem Lauf alles zu testen, sondern in klaren Schritten Erkenntnisse zu erzeugen, Maßnahmen abzuleiten und dieselben Tests nach Anpassungen erneut auszuführen. Genau dadurch wird aus einem Scan ein Sicherheitsprozess. Die Struktur ähnelt einem technischen Labor: Hypothese, Stimulus, Beobachtung, Analyse, Anpassung, Retest.

Ein praxistauglicher Ablauf beginnt mit einem eng abgegrenzten Szenario. Beispiel: Ein interner Office-Client scannt ein Serversegment auf typische Administrationsports. Danach wird geprüft, welche Sensoren anschlagen, wie die Aktivität klassifiziert wird und ob Analysten den Quellhost als ungewöhnlich erkennen. Anschließend werden Regeln oder Kontextdaten verbessert und derselbe Test wiederholt. Erst wenn dieses Szenario sauber funktioniert, wird auf weitere Segmente, langsamere Timings oder zusätzliche Enumeration erweitert.

Wichtig ist die Trennung der Phasen. Discovery, Portscan, Service-Erkennung und NSE sollten nicht wahllos vermischt werden. Jede Phase erzeugt andere Artefakte und sollte separat beobachtet werden. Nur so lässt sich später sagen, ob ein Alarm durch horizontales Scannen, durch Banner-Grabbing oder durch SMB-Enumeration ausgelöst wurde. Diese Trennung ist auch für Reporting und Nachsteuerung entscheidend.

Ein einfacher, aber robuster Workflow kann so aussehen:

1. Hypothese definieren
2. Zielnetz und Quellhost festlegen
3. Discovery mit dokumentierten Parametern durchführen
4. Ergebnisse validieren und Zielhosts auswählen
5. Portscan mit kontrolliertem Timing ausführen
6. Telemetrie und Alarme sammeln
7. Service-Erkennung oder NSE gezielt ergänzen
8. Detection-Lücken analysieren
9. Regeln, Parser oder Prozesse anpassen
10. Test identisch wiederholen

Dieser Ablauf passt gut zu einer strukturierten Methodik, einem klaren Prozess und geplanter Iteration. Entscheidend ist, dass jede Wiederholung möglichst identisch erfolgt. Schon kleine Änderungen an Timing, Quellhost oder Zielauswahl können Ergebnisse verfälschen und Vergleiche unbrauchbar machen.

Zur Workflow-Qualität gehört auch die Wahl der Ausgabeformate. Nmap kann normale, grepbare und XML-Ausgaben erzeugen. Für Purple Teaming ist XML oft sinnvoll, weil Ergebnisse maschinenlesbar weiterverarbeitet und mit anderen Datenquellen korreliert werden können. Gleichzeitig sollte eine menschenlesbare Zusammenfassung erstellt werden, die nicht nur Ports auflistet, sondern Beobachtungen und Abweichungen erklärt.

Ein weiterer Best Practice ist die Trennung von Test- und Produktionsnähe. Neue Scanprofile werden zuerst in Lab- oder Staging-Umgebungen validiert, bevor sie produktionsnah eingesetzt werden. Das reduziert Risiko und verbessert die Vorhersagbarkeit. Gerade bei NSE oder ungewöhnlichen Protokollen ist dieser Schritt Pflicht. Wer Nmap sauber in Purple Teaming integriert, arbeitet nicht mit Ad-hoc-Kommandos, sondern mit versionierten Profilen, dokumentierten Parametern und nachvollziehbaren Freigaben.

Der größte Nutzen entsteht, wenn Nmap in realistische Szenarien eingebettet wird. Ein klassisches Beispiel ist interne Reconnaissance nach initialem Zugriff. Ein kompromittierter Client versucht, erreichbare Server, Management-Dienste und Dateifreigaben zu identifizieren. Hier ist Nmap ideal, um zu testen, ob Segmentierung tatsächlich greift und ob das Blue Team ungewöhnliche Ost-West-Kommunikation erkennt. Ein Scan auf 445, 3389, 5985, 22 und 443 liefert oft schon genug Signal, um Schwächen in Netzwerkdesign und Detection sichtbar zu machen.

Ein zweites Szenario betrifft DMZ- und Expositionsprüfungen. Ein definierter Quellhost außerhalb eines Serversegments scannt nur die Ports, die laut Architektur erreichbar sein sollten. Jede zusätzliche Antwort ist dann nicht nur ein technischer Fund, sondern ein Architekturbruch. Solche Tests sind besonders wertvoll, wenn Firewalls über Jahre gewachsen sind und Regelwerke nicht mehr sauber dokumentiert sind.

Ein drittes Szenario ist die Kombination aus Nmap und Web-Prüfung. Nmap identifiziert Webdienste, TLS-Parameter, alternative Ports und Banner. Anschließend werden ausgewählte Ziele tiefer mit Mit Burp Suite untersucht. Diese Kombination ist praxisnah, weil viele reale Angriffe mit breiter Aufklärung beginnen und erst danach in applikationsnahe Tests übergehen. Purple Teaming profitiert hier besonders, weil Netzwerk- und Applikationstelemetrie gemeinsam betrachtet werden können.

Auch Segmenttests zwischen Admin-, User- und Servernetzen sind sehr ergiebig. Wenn ein User-Netz plötzlich WinRM, RDP oder Datenbankports in ein Servernetz erreicht, ist das nicht nur ein Härtungsproblem, sondern ein laterales Bewegungsrisiko. Nmap macht diese Pfade schnell sichtbar. Das Blue Team kann parallel prüfen, ob solche Verbindungsversuche als policy-widrig erkannt werden oder im normalen Traffic untergehen.

Für fortgeschrittene Teams lohnt sich die Einbettung in größere Übungsserien, etwa zusammen mit Purple Teaming Beispiele oder konkreten Szenarien. Nmap bildet dabei häufig die Reconnaissance-Phase, auf die weitere Schritte wie Authentifizierungsversuche, Web-Enumeration oder kontrollierte Post-Exploitation folgen. Der Vorteil: Detection kann entlang einer realistischen Angriffskette bewertet werden, statt nur einzelne Signaturen zu testen.

Wichtig bleibt dabei die Dosierung. Nicht jedes Szenario braucht Vollscans, OS-Erkennung und NSE. Oft reichen wenige, gezielt gewählte Befehle, um genau die Frage zu beantworten, die für Sicherheit und Betrieb relevant ist. Gute Purple Teams testen nicht maximal viel, sondern maximal aussagekräftig.

Nach dem technischen Teil entscheidet die Auswertung darüber, ob aus der Übung echte Verbesserung entsteht. Eine gute Dokumentation enthält nicht nur Befehle und Ergebnisse, sondern den vollständigen Kontext: Ziel der Übung, Hypothesen, Scope, Quellhost, Zeitfenster, verwendete Optionen, beobachtete Telemetrie, ausgelöste Alarme, Analystenreaktionen, Abweichungen und empfohlene Maßnahmen. Ohne diesen Kontext bleiben selbst präzise Scanergebnisse operativ schwach.

Für Metriken eignen sich vor allem Kennzahlen, die Detection und Reaktion messbar machen. Dazu gehören Zeit bis zur ersten Sichtbarkeit, Zeit bis zur Alarmierung, Zeit bis zur Analystensichtung, Korrektheit der Klassifizierung, Anteil erkannter Hosts oder Scanphasen und Qualität der Kontextanreicherung. Auch False Positives und unnötige Eskalationen sollten erfasst werden. Ein Alarm, der zwar auslöst, aber regelmäßig ignoriert wird, ist kein echter Erfolg.

Ebenso wichtig ist die technische Nachvollziehbarkeit. Nmap-Ausgaben sollten versioniert abgelegt werden, idealerweise zusammen mit Rohlogs oder Referenzen auf SIEM-Suchen. Wenn Parser, Regeln oder Dashboards angepasst werden, muss klar erkennbar sein, welche Änderung welchen Effekt hatte. Nur so lässt sich belegen, dass eine Verbesserung tatsächlich auf die Maßnahme zurückgeht und nicht auf Zufall oder geänderte Rahmenbedingungen.

In der Praxis bewährt sich eine Auswertung entlang von vier Ebenen: technische Beobachtung, Detection-Wirkung, Prozesswirkung und Restrisiko. Technische Beobachtung beschreibt, was Nmap gesehen hat. Detection-Wirkung beschreibt, was Sicherheitskontrollen gesehen haben. Prozesswirkung beschreibt, wie Menschen und Abläufe reagiert haben. Restrisiko beschreibt, was trotz Anpassungen weiterhin möglich bleibt. Diese Struktur verhindert, dass sich Berichte in Portlisten verlieren.

Wer Purple Teaming professionell betreibt, verknüpft Nmap-Ergebnisse außerdem mit übergreifenden Artefakten wie Reporting, Dokumentation und Metriken. So wird aus einer Einzelübung ein Baustein für Trendanalysen: Werden langsame Scans heute besser erkannt als vor drei Monaten? Hat sich die Sichtbarkeit in Cloud-Segmenten verbessert? Reagiert das SOC konsistenter auf interne Reconnaissance?

Am Ende sollte jede Übung in konkrete Maßnahmen münden. Beispiele sind neue Korrelationsregeln, bessere Asset-Kontexte, Ausnahmen für bekannte Scanner, härtere Segmentierung, zusätzliche Sensorplatzierung oder angepasste Analysten-Playbooks. Wenn ein Nmap-Lauf nur mit dem Satz endet, dass mehrere Ports offen waren, wurde das Potenzial des Werkzeugs im Purple Teaming nicht genutzt.