Netzwerk-Pentesting: Methodik für interne Infrastruktur

Netzwerk-Pentesting: von der Ausgangsposition zum ersten Foothold

Ein interner Netzwerktest beantwortet eine andere Frage als ein Web- oder API-Test: Was kann jemand erreichen, der schon einen Fuß im internen Netz hat - durch einen kompromittierten Client, ein gekapertes Standardkonto oder einen bewusst gesetzten Startpunkt? Geprüft wird die interne Infrastruktur als Ganzes: erreichbare Netze, Dienste, Vertrauensbeziehungen und die Frage, wie weit sich eine schwache Stelle zu einem echten Zugriff ausbauen lässt.

Die Grenze dieses Artikels ist bewusst gesetzt: Er reicht bis zu einer belastbaren domänenbezogenen Ausgangsposition - dem Punkt, an dem AD-spezifische Enumeration und Angriffslogik beginnen. Ein bereitgestelltes Domänen-Standardkonto kann bereits eine solche Ausgangsposition sein; entscheidend ist nicht der exakte Moment, sondern dass die Betrachtung hier noch infrastrukturbezogen bleibt. Ab dort übernimmt der Deep-Dive zu Active Directory Pentesting mit domänenspezifischer Enumeration, Kerberos, ACLs, Delegation, AD CS, Trusts und domänenspezifischer Privilege Escalation. Hier geht es um das Netz davor: die Infrastruktur, über die der Angreifer die Domäne überhaupt erst erreicht. Die allgemeine Methodik - Scope, Phasen, Risikobewertung, Reporting - steht im Grundlagenartikel.

Ausgangslagen

Ein interner Test beginnt nicht im luftleeren Raum, sondern aus einer definierten Startposition. Welche das ist, entscheidet, was realistisch geprüft werden kann und welche Aussage am Ende überhaupt belastbar ist. Die Startposition gehört deshalb vor dem ersten Paket geklärt und in den Rules of Engagement festgehalten.

Wie dieser Erstzugang in der Realität entsteht - Phishing, ein exponierter Dienst, ein gültiges Konto - ist Thema der Taktik Initial Access. Für den internen Test ist er der vereinbarte Ausgangspunkt: Je klarer die Startposition, desto schärfer die Aussage des Tests.

Host- und Service-Discovery

Der erste Schritt im Netz ist, überhaupt zu wissen, was da ist. Discovery beantwortet drei Fragen in Reihenfolge: Welche Netze sind von der Startposition erreichbar, welche Hosts darin antworten, und welche Dienste laufen auf ihnen. Entscheidend ist, dabei methodisch statt wahllos vorzugehen.

• Erreichbare Netze: Aus Routing-Tabelle, DHCP-Lease und ARP-Cache des Startsystems ergibt sich, welche Segmente direkt erreichbar sind und wohin geroutet wird. Das ist die Landkarte, bevor ein einziger Scan läuft.
• Antwortende Hosts: Ein Host muss nicht auf ICMP reagieren, um erreichbar zu sein. Wer nur pingt, übersieht Systeme, die ICMP blocken, aber auf TCP oder UDP antworten.
• Laufende Dienste: Erst die Dienste machen einen Host interessant. Offene Ports, Versionen und Banner sind der Einstieg in die Enumeration.

Der Unterschied zwischen den Protokollen ist dabei kein Detail: ICMP wird oft gefiltert, TCP-Scans liefern über den Handshake klare Zustände, und UDP ist langsam und mehrdeutig, deckt aber Dienste wie DNS, SNMP oder SMB-Namensdienste auf, die TCP-Scans gar nicht sehen. Passive Discovery - das reine Mithören von Broadcast- und Multicast-Verkehr - verrät Hosts, Namensdienste und Vertrauensbeziehungen, ohne selbst ein Paket aktiv an ein Ziel zu senden, und ist oft der leisere erste Schritt. Sie sieht allerdings nur den Verkehr, der am eigenen Beobachtungspunkt tatsächlich ankommt: Was sichtbar wird, hängt von Segment und Broadcast-Domäne, Switch-Topologie, vorhandenen SPAN- oder Mirror-Möglichkeiten und der Startposition ab - passives Mithören liefert also kein automatisch vollständiges Netzbild.

Diese Aufrufe dienen der Veranschaulichung und gehören ausschließlich in ein Netz, für das eine Freigabe vorliegt. Die Intensität - wie breit, wie schnell, wie laut - ist eine bewusste Entscheidung und steht in den Rules of Engagement; welche Werkzeuge sich eignen und welche Spuren sie hinterlassen, ordnet der Tools-Bereich ein. Die systematische Aufklärung des erreichten Umfelds entspricht der Taktik Discovery.

Enumeration

Discovery sagt, dass ein Port offen ist. Enumeration sagt, was dahinter steckt und ob es sich lohnt. Ein offener Port ist noch kein Befund - erst Version, Konfiguration, Authentisierung, erreichbare Ressourcen und Vertrauensbeziehungen machen daraus eine bewertbare Angriffsfläche. Enumeration ist deshalb dienstorientiert, nicht portorientiert.

Das Ergebnis der Enumeration wird nicht im Kopf gehalten, sondern in einer Host- und Service-Matrix festgehalten - sie ist zugleich der Rohstoff für Angriffspfade und Reporting:

Enumeration zahlt sich doppelt aus: Sie liefert konkrete Ansatzpunkte und zugleich das Bild der Vertrauensbeziehungen - welcher Host welchem Konto glaubt und welcher Dienst auf welchen anderen zugreift.

Fehlkonfigurationen und Exposure

Ein großer Teil interner Kompromittierungen braucht keinen Exploit, sondern nur eine Fehlkonfiguration. Diese Klasse von Befunden ist oft der schnellste und zugleich leiseste Weg zum nächsten Schritt - und sie ist gut belegbar, weil sie keine Ausnutzung einer Software-Schwachstelle erfordert.

• Default- und schwache Credentials: Appliances, Management-Interfaces und Datenbanken mit unveränderten Werkszugängen. Hier geht es um den Nachweis, dass ein Default-Zugang aktiv ist - nicht um Passwortlisten oder Credential-Stuffing.
• Anonyme oder Gastzugriffe: SMB-Shares, LDAP-Abfragen oder Datenbanken, die ohne Anmeldung lesen lassen.
• Offene Shares: Breit freigegebene Verzeichnisse mit sensiblen Inhalten - Skripten, Backups, Konfigurationen.
• Veraltete Dienste: Nicht gepatchte oder abgekündigte Software, die bekannte Schwächen mitbringt.
• Unnötig exponierte Management-Interfaces: Admin-Oberflächen, die aus dem Nutzersegment erreichbar sind, statt auf ein Management-Netz begrenzt zu sein.
• Unsichere Protokolle: Klartextdienste und schwache Authentisierungsverfahren, die Mitlesen oder Umleiten erleichtern.
• Fehlende Segmentierung: Flache Netze, in denen jeder Client jeden Server erreicht - die Grundlage für fast jeden internen Angriffspfad.
• Service Accounts und technische Konten: Oft hoch privilegiert, selten rotiert, teils in Skripten und Shares hinterlegt - eine eigene Angriffsfläche.

Der Nachweis bleibt minimal: belegt, dass ein anonymer Zugriff oder ein Default-Zugang möglich ist - nicht das Durchsuchen oder Abziehen der dahinterliegenden Daten.

Credential-Gewinnung im internen Netz

Im internen Netz kommt man oft nicht über einen Exploit weiter, sondern über Zugangsdaten. Ein ganzer Techniken-Komplex zielt darauf, Authentisierung im Netz abzufangen oder umzuleiten. Dieser Abschnitt bleibt bewusst auf der Mechanik- und Entscheidungsebene: Es geht darum, zu verstehen, wann solche Techniken relevant sind und was sie auslösen - nicht um eine scharfe, einsatzfertige Kette.

• LLMNR / NBT-NS / mDNS-Poisoning: LLMNR und NBT-NS sind klassische lokale Namensauflösungs- und Fallback-Mechanismen in Windows-Netzen, mDNS ist ein eigener Multicast-Mechanismus. Gemeinsam ist ihnen nur, dass sich lokale Namensauflösung und ihre Vertrauensannahmen missbrauchen lassen: Wer bei einer fehlschlagenden Auflösung in der lokalen Umgebung antwortet, kann sich als gesuchter Host ausgeben. Die Mechanik beruht auf Fallbacks, die in vielen Netzen aktiv bleiben, obwohl sie nicht gebraucht werden.
• NTLM Relay: NTLM-Authentisierung lässt sich unter bestimmten Bedingungen an ein anderes System weiterleiten, statt sie zu knacken. Ob das gelingt, hängt vom jeweiligen Zielprotokoll und dessen Schutzmechanismen ab: Für SMB-Relay ist insbesondere erzwungenes SMB Signing entscheidend, andere Zielprotokolle bringen eigene Voraussetzungen und Schutzmechanismen mit. Eine konkrete Relay-Kette gehört nicht hierher.
• Responder-Klasse: Werkzeuge, die auf Namensdienst-Anfragen antworten und Authentisierungsversuche einsammeln. Konzeptionell dieselbe Grundidee: die Vertrauensannahme im Namensdienst ausnutzen.

Die Voraussetzungen unterscheiden sich je Technik. Lokales Namensauflösungs-Poisoning setzt typischerweise eine geeignete Position im relevanten lokalen Netz sowie entsprechende Namensauflösungsanfragen voraus. Ob eine abgefangene oder initiierte Authentisierung anschließend weitergeleitet werden kann, hängt dagegen vom Zielprotokoll, dessen Schutzmechanismen und dem jeweiligen Authentisierungskontext ab. Ebenso wichtig ist die Kehrseite: Diese Techniken erzeugen verwertbare Netzwerk- und Authentisierungstelemetrie und können je nach Umgebung auffällig sein. Ungewöhnlicher Namensdienst-Verkehr und Authentisierungsereignisse sind auf der Verteidigungsseite gut sichtbar.

Wo erbeutete Zugangsdaten anschließend verarbeitet werden, berührt die Taktik Credential Access; die konkreten Techniken liegen dort und in der Payload-Sammlung.

Pivoting und Segmentierungsprüfung

Dies ist ein besonders wertvoller Teil eines internen Tests. Die zentrale Frage lautet nicht, ob zwei Systeme Pakete austauschen können, sondern ob die Segmentierung das hält, was das Netzdesign verspricht. Erreichbar und wirklich getrennt sind zwei verschiedene Dinge - und die Lücke dazwischen ist der Weg des Angreifers.

Segmentierung wird deshalb nicht angenommen, sondern geprüft: gezielt, von definierten Quellen zu definierten Zielen, mit einer klaren Erwartung je Verbindung. Das Vorgehen folgt immer demselben Muster: Quelle, Ziel, Port oder Dienst, erwartetes Verhalten, tatsächliches Verhalten. Genau diese Matrix macht aus einem diffusen Gefühl von Erreichbarkeit einen belastbaren Befund.

Jede Abweichung zwischen erwartetem und tatsächlichem Verhalten ist zunächst ein Prüfpunkt. Zum Befund wird sie, wenn die Verbindung dem vorgesehenen Sicherheits- oder Segmentierungsmodell widerspricht; es kann auch legitime, nur schlecht dokumentierte Ausnahmen geben. Der Rest ist Mechanik: Jump Hosts und Bastion Hosts als vorgesehene, kontrollierte Übergänge prüfen, VLAN- und Firewall-Grenzen entlang der Matrix abklopfen und interne Trust-Zonen sichtbar machen. Pivoting - ein erreichtes System als Brücke in ein sonst nicht erreichbares Segment zu nutzen - bleibt hier konzeptionell: Der Nachweis, dass eine Grenze überwindbar ist, genügt; das Ausrollen von Tunnelketten ist für den Befund nicht nötig. Die Bewegung zu weiteren Systemen entspricht der Taktik Lateral Movement.

Service Exploitation

Service Exploitation ist im internen Test ein Werkzeug, kein Selbstzweck. Bevor ein Dienst aktiv ausgenutzt wird, steht die Frage, ob das überhaupt nötig und verantwortbar ist - oft führt eine Fehlkonfiguration schneller und leiser zum Ziel. Wird exploitiert, dann kontrolliert und mit minimalem Nachweis.

Die wichtigste Unterscheidung ist die zwischen einer echten Software-Schwachstelle und einer Fehlkonfiguration, denn sie führt zu unterschiedlichen Empfehlungen:

Daraus folgt eine klare Stopp-Regel: Ist die Ausnutzbarkeit belegt und der Impact eingeordnet, ist der Befund fertig. Weiter zu gehen bringt keinen zusätzlichen Erkenntniswert, erhöht aber das Risiko für den Betrieb. Konkrete Techniken und ihre Einordnung entlang MITRE ATT&CK liegen in der Payload-Sammlung; dieser Artikel sammelt bewusst keine Exploits.

Interne Angriffspfade

Der Wert eines internen Tests liegt nicht in der Liste der Einzelbefunde, sondern in ihrer Verkettung. Jeder Schritt für sich mag harmlos wirken - zusammen ergeben sie den Weg von der Ausgangsposition bis an die Tür der Domäne. Das folgende Szenario ist vereinfacht, aber typisch:

Jede Schwachstelle für sich wäre vielleicht als mittel bewertet worden: ein offenes Share, ein Zugang in einem Skript, eine fehlende Firewall-Regel. Erst die Kette macht daraus einen Weg vom gewöhnlichen Arbeitsplatz bis zum Fuß der Domäne. Genau hier endet dieser Artikel bewusst: Was danach im Active Directory passiert - Enumeration der Domäne, Kerberos-Angriffe, Rechteausweitung bis Domain Admin - ist Gegenstand des eigenen Deep-Dives zu Active Directory Pentesting.

Operator-Entscheidungen

Ein interner Test ist eine Kette von Entscheidungen, nicht das Abarbeiten einer Werkzeugliste. Dieselbe Situation kann je nach Ziel, Umgebung und RoE zwei verschiedene richtige Antworten haben. Die folgende Matrix macht die wiederkehrenden Abwägungen explizit:

Die durchgehende Leitlinie: so viel Nachweis wie nötig, so wenig Eingriff wie möglich. Ein belegter Befund ist wertvoller als ein tiefer, aber riskanter Durchstich, der den Betrieb gefährdet oder den Scope verlässt.

Typische Fehler

• Nur Portscan: Ein Scan ist Discovery, kein Test. Ohne Enumeration bleibt offen, was hinter den Ports wirklich steckt.
• Nur die Versionsnummer bewerten: Eine gemeldete Version allein trägt keine belastbare Risikobewertung - entscheidend sind konkrete Betroffenheit, Exposition und Voraussetzungen, nicht die Versionsnummer für sich.
• Segmentierung nicht wirklich testen: Anzunehmen, dass VLANs trennen, statt es Quelle für Ziel zu prüfen, übersieht genau die wichtigsten Befunde.
• Zu früh exploitieren: Ein scharfer Exploit, wo eine Fehlkonfiguration denselben Nachweis liefert, bringt nur zusätzliches Risiko.
• Scope-Grenzen ignorieren: Fremde Netze, VLANs oder angebundene Dienstleister mitzutesten, die nicht freigegeben sind, ist ein harter Scope-Bruch.
• Interne Weboberflächen übersehen: Admin-Panels und Appliances im internen Netz sind oft der einfachste Weg und werden trotzdem übergangen.
• Testaktionen nicht protokollieren: Ohne festgehaltene Zeit, Quelle und Aktion lässt sich ein Befund später nicht belegen und ein echter Vorfall nicht vom Test trennen.
• AD-Themen unstrukturiert vermischen: Domänenangriffe mitten in den Netzwerktest zu ziehen, verwischt die Grenze und das Reporting - der AD-Teil gehört sauber getrennt.

Nachweis und Reporting

Ein interner Test lebt von nachvollziehbaren, kompakten Belegen statt von Massendaten. Die zentralen Artefakte entstehen ohnehin während der Arbeit und werden nur sauber aufbereitet:

• Host- und Service-Matrix: welche Hosts, welche Rollen, welche erreichbaren Dienste und Auffälligkeiten.
• Segmentierungs-Matrix: Quelle, Ziel, Dienst, erwartet gegen tatsächlich - der direkte Beleg jedes Segmentierungsbefunds.
• Minimaler Credential- und Access-Nachweis: dass ein Zugang möglich war, belegt an einem einzelnen Beispiel - keine abgezogenen Datenmengen.
• Angriffspfad-Diagramm: die Verkettung der Einzelbefunde bis zum ersten Domain- oder AD-Foothold.
• Reproduzierbare Sequenz: die genaue Abfolge der Schritte, damit das Team den Fund selbst bestätigen kann.

Die Berichtsstruktur vertieft der Deep-Dive zu Pentest Reporting; die Risikobewertung der Deep-Dive zu Risikobewertung und CVSS. Welche Spuren die hier gezeigten Schritte - Scans, Enumeration, Poisoning, Ost-West-Verkehr und interne Remote-Ausführung - auf der Verteidigungsseite hinterlassen, behandelt das Schwesterportal blue-team.net.

Häufige Fragen

Was unterscheidet einen Netzwerk-Pentest von einem Schwachstellenscan?

Der Scan findet bekannte Muster und offene Ports in der Breite. Der Netzwerk-Pentest prüft in der Tiefe, enumeriert Dienste im Kontext, verifiziert Ausnutzbarkeit und findet vor allem das, wofür ein Scanner keinen Kontext hat: fehlende Segmentierung, Vertrauensbeziehungen und verkettbare Fehlkonfigurationen.

Brauche ich Domänen-Zugangsdaten für den Test?

Nicht zwingend. Ein Test kann ohne Konto aus reiner Außensicht im Netz starten, läuft aber realistischer und tiefer aus einer Assumed-Breach-Position mit einem Standardkonto oder einem kompromittierten Client. Welche Ausgangslage sinnvoll ist, richtet sich nach der Frage, die der Test beantworten soll.

Wo hört der Netzwerk-Pentest auf und wo beginnt Active Directory?

Dieser Artikel reicht bis zu einer belastbaren domänenbezogenen Ausgangsposition - dem Punkt, an dem AD-spezifische Enumeration und Angriffslogik beginnen. Alles Domänenspezifische danach - Domänen-Enumeration, Kerberos, ACLs, Delegation, AD CS, Trusts und domänenspezifische Privilege Escalation - gehört in den eigenen Active-Directory-Deep-Dive.

Ist LLMNR- oder Relay-Poisoning immer Teil des Tests?

Nein. Diese Techniken greifen aktiv in den Netzverkehr ein, erzeugen verwertbare Netzwerk- und Authentisierungstelemetrie, können je nach Umgebung auffällig sein und können Dritte betreffen. Sie gehören nur dann in den Test, wenn sie ausdrücklich in den Rules of Engagement freigegeben sind und die Voraussetzungen im Netz überhaupt gegeben sind.