Protocol Tunneling und Proxy erkennen: versteckte C2-Kanäle durch die Firewall

Mit Protocol Tunneling und Proxy schließt der Block zu Command and Control ab. Nach dem RMM-Missbrauch, dem Ingress Tool Transfer und dem Web-Service-C2 geht es um den Fall, dass der Angreifer keinen bequemen Kanal vorfindet: Der direkte Ausgang ist gesperrt, interessante Systeme sind nur intern erreichbar. Die Antwort ist ein Tunnel - der Verkehr wird in ein erlaubtes Protokoll verpackt oder über einen Pivot-Host umgeleitet, bis er doch sein Ziel erreicht. Das verschiebt das Problem von der Netzgrenze auf den Endpunkt: Dort ist der Aufbau des Tunnels sichtbar. Der Beitrag nimmt die Erkennung in den Blick und bleibt auf der Verteidigerseite.

Was der Angreifer tut

Tunneling und Proxy laufen auf der Ebene des Prinzips, nicht als Anleitung, in wenigen Varianten ab:

• Verkehr verpacken. Der C2-Verkehr wird in ein erlaubtes Protokoll gehüllt - etwa in SSH, HTTPS oder DNS - und passiert so die Firewall, die nur den Protokoll-Rahmen sieht.
• Von innen nach außen öffnen. Eine entfernte SSH-Weiterleitung oder ein Werkzeug wie ngrok macht einen internen Dienst von außen erreichbar, ohne dass eine eingehende Firewall-Regel nötig wäre.
• Pivot ins Netz. Über einen Proxy auf einem übernommenen Host (etwa per netsh portproxy) leitet der Angreifer Verkehr auf Systeme weiter, die er sonst nicht direkt erreicht.
• Spuren verwischen. Proxy-Ketten über mehrere Stationen und Domain Fronting verschleiern die wahre Gegenstelle, sodass Ziel-IP und SNI nicht mehr zusammenpassen.

Für die Erkennung ist entscheidend: Der Tunnel muss aufgebaut werden, und dieser Aufbau ist ein Prozess mit verräterischer Kommandozeile - das Werkzeug, die Weiterleitungs-Flags und das Ziel.

Welche Logquellen die Technik zeigt

• Prozess-Telemetrie. Event 4688 und Sysmon Event 1 zeigen das Tunnel-Werkzeug samt Kommandozeile - Weiterleitungs-Flags, Zielhost und Ports stehen dort im Klartext. Die wichtigste Quelle.
• Netzverbindung. Die Verbindung (Sysmon Event 3) zeigt lange, dauerhafte Sitzungen zu einem externen Ziel sowie lokale Prozesse, die unerwartet einen Port abhören; Grundlagen unter Sysmon einrichten.
• netsh-Konfiguration. Ein portproxy-Eintrag erscheint in der Kommandozeile und bleibt in der Konfiguration bestehen - ein dauerhafter Hinweis auf einen Pivot.
• Proxy und DNS. Am Perimeter fallen ungewöhnliche Protokollmengen und Ziel-SNI-Abweichungen auf - nützlich gegen Tunnel, die der Endpunkt allein nicht verrät.

Das Muster im Log

Das klarste Signal ist ein Tunnel-Werkzeug in der Prozessliste: ngrok, chisel, frp, gost oder iodine haben auf einem normalen Arbeitsplatz keinen Grund zu laufen. Das zweite Signal ist eine SSH-Kommandozeile mit Weiterleitungs-Flags - ssh oder plink mit -L, -R oder -D, besonders ein entfernter Tunnel (-R), der einen lokalen Dienst nach außen öffnet. Das dritte ist netsh interface portproxy add: eine bordeigene Portweiterleitung, die im Normalbetrieb kaum vorkommt und auf einen Pivot deutet. Legitime Tunnel stammen von Administratoren und Entwicklern mit bekannten Zielen und Hosts. Wie immer trennt der Blick auf Werkzeug, Flags und Ziel den Alltag vom Angriff.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft und decken die drei Wege ab: die SSH-Weiterleitung, das fertige Tunnel-Werkzeug und die netsh-Portweiterleitung. Alle drei setzen am Prozess an.

1. SSH-Portweiterleitung oder -Tunnel (T1572). ssh oder plink mit -L, -R oder -D. Die Regel steht auf level: medium, weil Admins SSH-Tunnel auch legitim nutzen.

title: SSH-Portweiterleitung oder -Tunnel
id: b697dbeb-87fe-42b9-b32d-de9ded8b4037
status: experimental
description: |
  Erkennt den Aufbau einer SSH-Portweiterleitung ueber ssh.exe oder plink.exe mit den Flags fuer
  lokales (-L), entferntes (-R) oder dynamisches (-D) Forwarding. Angreifer legen damit einen
  getunnelten Kanal an, um Datenverkehr an Firewall-Regeln vorbeizuleiten oder einen Dienst von
  innen nach aussen erreichbar zu machen. Ein entfernter Tunnel (-R) von einem Server ist besonders
  verdaechtig.
references:
  - https://attack.mitre.org/techniques/T1572/
author: blue-team.net
tags:
  - attack.command-and-control
  - attack.t1572
logsource:
  product: windows
  category: process_creation
detection:
  sel_img:
    Image|endswith:
      - '\ssh.exe'
      - '\plink.exe'
  sel_flag:
    CommandLine|contains:
      - ' -L'
      - ' -R'
      - ' -D'
  condition: sel_img and sel_flag
falsepositives:
  - Administratoren und Entwickler, die legitime SSH-Tunnel nutzen - nach Host, Konto und Ziel als Baseline ausnehmen
level: medium

2. Bekanntes Tunneling- oder Proxy-Werkzeug (T1572, T1090). Der Start von ngrok, chisel, frp, gost, iodine und Co. - auf Endpunkten selten legitim. Die Regel steht auf level: high.

title: Bekanntes Tunneling- oder Proxy-Werkzeug
id: 124140e0-64e0-4c73-891a-95397eff247d
status: experimental
description: |
  Erkennt den Start eines bekannten Tunneling- oder Proxy-Werkzeugs (ngrok, chisel, frp, gost,
  iodine, socat, wstunnel und Co.). Solche Werkzeuge bauen einen verschleierten Kanal nach aussen
  oder eine Proxy-Kette auf, um Erkennung und Firewall zu umgehen. Auf normalen Endpunkten haben
  sie selten einen legitimen Grund.
references:
  - https://attack.mitre.org/techniques/T1572/
author: blue-team.net
tags:
  - attack.command-and-control
  - attack.t1572
  - attack.t1090
logsource:
  product: windows
  category: process_creation
detection:
  sel_img:
    Image|endswith:
      - '\ngrok.exe'
      - '\chisel.exe'
      - '\frpc.exe'
      - '\frps.exe'
      - '\gost.exe'
      - '\iodine.exe'
      - '\socat.exe'
      - '\wstunnel.exe'
  condition: sel_img
falsepositives:
  - socat und einzelne Werkzeuge kommen auf Entwickler- und Admin-Hosts legitim vor - diese Hosts gesondert behandeln und als Baseline ausnehmen
level: high

3. Portweiterleitung per netsh portproxy (T1090.001). Das Anlegen eines internen Proxys mit dem bordeigenen netsh - ein klassischer Pivot. Ebenfalls level: high.

title: Portweiterleitung per netsh portproxy
id: b9362354-a72c-447f-b0a9-18ed9133fd7a
status: experimental
description: |
  Erkennt das Anlegen einer Portweiterleitung ueber netsh interface portproxy. Mit dem bordeigenen
  netsh baut ein Angreifer einen internen Proxy, der Verkehr von einem Port auf ein anderes Ziel
  weiterleitet - ein beliebter Weg, um per Pivot tiefer ins Netz zu gelangen, ohne eigene Software
  mitzubringen. Ein portproxy-Eintrag ist im Normalbetrieb sehr selten.
references:
  - https://attack.mitre.org/techniques/T1090/001/
author: blue-team.net
tags:
  - attack.command-and-control
  - attack.t1090
  - attack.t1090.001
logsource:
  product: windows
  category: process_creation
detection:
  sel_img:
    Image|endswith: '\netsh.exe'
  sel_cmd:
    CommandLine|contains: 'portproxy'
  condition: sel_img and sel_cmd
falsepositives:
  - Sehr selten; einzelne Administrations-Faelle (z. B. Dienst-Weiterleitung) - bekannte Faelle nach Host und Konto als Baseline ausnehmen
level: high

Härtung: der Angriff, der ins Leere läuft

• Ausgang strikt filtern. Ausgehende Verbindungen nur über einen Proxy und nur auf benötigte Ziele und Ports zulassen. Ein Tunnel braucht einen offenen Ausgang - fehlt er, läuft er ins Leere.
• Tunnel-Werkzeuge blockieren. ngrok, chisel und verwandte Programme per Anwendungssteuerung (WDAC oder AppLocker) sperren; auf normalen Endpunkten werden sie nicht gebraucht.
• netsh portproxy überwachen. Das Anlegen einer Portweiterleitung alarmieren und bestehende Einträge regelmäßig prüfen - sie sind selten und meist verdächtig.
• Abhörende Ports im Blick behalten. Prozesse, die unerwartet einen Port öffnen, und lange Verbindungen zu externen Zielen gezielt auswerten.

Der Test

Die Erkennung lässt sich im Lab gefahrlos prüfen, auf isolierten Systemen mit aktivem Sysmon:

• Für Regel 1 mit ssh oder plink testweise eine lokale Weiterleitung (-L) zu einem internen Dienst aufbauen. In Event 4688 muss die Kommandozeile mit dem Forwarding-Flag erscheinen.
• Für Regel 2 ein harmloses Tunnel-Werkzeug (etwa chisel im Lab) starten und den Eintrag in der Prozess-Telemetrie prüfen; danach wieder entfernen.
• Für Regel 3 mit netsh interface portproxy add testweise eine Weiterleitung anlegen. Die Kommandozeile muss in Event 4688 auftauchen; den Eintrag anschließend mit delete entfernen.
• Breiter wird der Test mit den Fällen zu T1572 und T1090 aus Atomic Red Team.

Fehlalarme und Tuning

• Administratoren und Entwickler. SSH-Tunnel und einzelne Werkzeuge wie socat gehören auf manchen Hosts zum Alltag. Diese Hosts und Konten gesondert behandeln und als Baseline ausnehmen.
• Legitime Portweiterleitung. Sehr selten richtet die Administration eine netsh-Weiterleitung ein. Die wenigen bekannten Fälle dokumentieren und ausnehmen - der Rest bleibt hochprior.
• Ziel und Dauer bewerten. Ein Tunnel zu einem internen, bekannten Host wiegt leichter als einer zu einem frisch registrierten externen Ziel. Die Anreicherung um Ziel-Reputation schärft die Bewertung.
• Kette statt Einzelaufruf. Nachgeladenes Werkzeug, Tunnel-Aufbau und lange Verbindung zusammen betrachtet trennen Angriff und Alltag zuverlässiger als jede Einzelregel.

Fazit

Protocol Tunneling und Proxy sind die Antwort des Angreifers auf eine gute Netzgrenze: Was nicht direkt hinausdarf, wird verpackt oder umgeleitet. Doch der Tunnel muss auf dem Endpunkt aufgebaut werden, und genau das ist sichtbar - am Tunnel-Werkzeug, an den SSH-Weiterleitungs-Flags und am netsh-portproxy-Eintrag. Die wirksamste Härtung filtert den Ausgang strikt, sperrt die Tunnel-Werkzeuge und überwacht Portweiterleitungen. Damit ist der C2-Block komplett: vom RMM-Missbrauch über Ingress Tool Transfer und Web-Service-C2 bis zum Tunnel. Verwandt ist das Living off the Land, und in die Gegenrichtung führt der Datenabfluss. Alle Techniken dieser Taktik sammelt das Lexikon nach Taktik unter Command and Control.