External Proxy erkennen: C2 über einen vorgeschalteten Proxy

Command and Control lebt davon, unauffällig zu bleiben. Ein externer Proxy hilft dabei: Statt direkt mit dem Steuerserver zu sprechen, schickt der befallene Rechner seinen Verkehr an einen vorgeschalteten Proxy, der ihn weiterreicht. Für die Verteidigung verschwimmt damit das eigentliche Ziel, und Sperrlisten laufen ins Leere. Doch bevor der Verkehr fließen kann, muss der Rechner den Proxy kennen - er wird in die Konfiguration eingetragen. Diese Umstellung ist der Ansatzpunkt für die Erkennung, denn sie passiert auf dem Endpunkt und hinterlässt klare Spuren. Dieser Beitrag bleibt auf der Erkennungsseite und zeigt, woran sich die Proxy-Umstellung erkennen lässt, nicht, wie man C2 verschleiert.

Was der Angreifer tut

Die Umstellung auf einen externen Proxy folgt - auf der Ebene des Prinzips, nicht als Anleitung - einigen wiederkehrenden Wegen, die alle auf dem Endpunkt Spuren hinterlassen:

• Den Browser-Proxy setzen. In den Internet Settings der Registry wird ein Proxyserver eingetragen; viele Programme folgen dieser systemweiten Einstellung.
• Den WinHTTP-Proxy setzen. Über netsh lässt sich der Proxy für Dienste und Hintergrundprozesse umbiegen, die nicht die Browser-Einstellung lesen.
• Eine Umgebungsvariable nutzen. HTTP_PROXY und HTTPS_PROXY werden von vielen Werkzeugen gelesen; einmal gesetzt, leiten sie deren Verkehr über den Proxy.
• Dann verbinden. Ist der Proxy eingetragen, läuft der C2-Verkehr über ihn - das eigentliche Ziel bleibt verborgen.

Für die Erkennung ist entscheidend: Jeder dieser Wege verändert eine benannte Konfigurationsstelle - einen Registry-Wert, einen netsh-Aufruf oder eine Umgebungsvariable. Nicht der spätere Verkehr ist der erste Ansatzpunkt, sondern die Umstellung, die ihn ermöglicht.

Welche Logquellen die Technik zeigt

• Registry-Telemetrie zuerst. Sysmon Event 13 zeigt, wenn der ProxyServer-Wert in den Internet Settings gesetzt wird - der direkteste Hinweis auf eine Proxy-Umstellung.
• Prozess-Telemetrie. Event 4688 zeigt netsh mit winhttp und proxy sowie das Setzen von HTTP_PROXY oder HTTPS_PROXY samt vollständiger Befehlszeile.
• Wer und wann. Proxy-Einstellungen kommen im Unternehmen meist per Richtlinie; eine Änderung durch ein Benutzer- oder Dienstkonto außerhalb dieses Wegs verdient einen Blick.
• Werkzeug-Kontext. netsh und reg sind mitgelieferte Programme; erst Kontext und Konto machen den Unterschied. Grundlagen zum Missbrauch solcher Bordmittel unter Living off the Land.

Das Muster im Log

Drei Signale tragen. Das erste ist ein gesetzter ProxyServer-Wert unter den Internet Settings der Registry. Das zweite ist netsh mit winhttp und proxy, also die Umstellung des Systemproxys. Das dritte ist das Setzen von HTTP_PROXY oder HTTPS_PROXY in der Befehlszeile. Alle drei stehen auf mittlerer Stufe, weil auch legitime Administration und Entwicklung genau diese Stellen berühren. Entscheidend ist der Kontext: Legitime Treffer stammen aus der Verteilung per Gruppenrichtlinie, von bekannten Admin-Konten oder aus Build-Umgebungen. Auffällig wird es, wenn ein Proxy auf einen unbekannten Host zeigt, von einem untypischen Konto gesetzt wird oder kurz nach einer anderen verdächtigen Aktion auftaucht. Eine einzelne Zeile ist schwach; die Umstellung zusammen mit anschließendem ausgehendem Verkehr zu dem neuen Proxy ist das eigentliche Signal.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft und nehmen die drei Signale: den Registry-Proxy, den netsh-WinHTTP-Proxy und den Umgebungsvariablen-Proxy. Die erste wertet Registry-Telemetrie aus, die beiden anderen die Prozess-Telemetrie.

1. System-Proxy über die Registry gesetzt (T1090.002). Ein ProxyServer-Wert unter den Internet Settings. Wegen der legitimen Nutzung auf level: medium.

title: System-Proxy ueber die Registry gesetzt
id: 4e8a2c71-3d96-4b52-a7f1-6c9b5d8e2a43
status: experimental
description: |
  Erkennt das Setzen eines Proxyservers in den Internet Settings der Registry. Angreifer biegen damit den
  ausgehenden Datenverkehr auf einen von ihnen kontrollierten externen Proxy um, um ihre C2-Verbindung zu
  verschleiern (External Proxy). Legitime Proxy-Konfigurationen kommen vor, der Zeitpunkt und das setzende
  Konto machen den Unterschied.
references:
  - https://attack.mitre.org/techniques/T1090/002/
author: blue-team.net
tags:
  - attack.command-and-control
  - attack.t1090.002
logsource:
  product: windows
  category: registry_set
detection:
  sel:
    TargetObject|contains: '\Internet Settings\'
    TargetObject|endswith: '\ProxyServer'
  condition: sel
falsepositives:
  - Unternehmens-Proxy per Richtlinie oder Benutzer stellt einen Proxy ein - bekannte Proxys, Konten und Verteilwege als Baseline ausnehmen
level: medium

2. WinHTTP-Proxy über netsh gesetzt (T1090.002). netsh mit winhttp und proxy. Ebenfalls level: medium.

title: WinHTTP-Proxy ueber netsh gesetzt
id: 7c1e4a93-2d85-4b61-9f52-5a3b8c7d6e24
status: experimental
description: |
  Erkennt netsh beim Setzen eines WinHTTP-Proxys. Darueber laesst sich der Systemproxy fuer Dienste und
  Hintergrundprozesse auf einen externen Proxy umbiegen, oft um C2-Verkehr zu verschleiern (External Proxy).
references:
  - https://attack.mitre.org/techniques/T1090/002/
author: blue-team.net
tags:
  - attack.command-and-control
  - attack.t1090.002
logsource:
  product: windows
  category: process_creation
detection:
  sel_img:
    Image|endswith: '\netsh.exe'
  sel_cmd:
    CommandLine|contains: 'winhttp'
  sel_proxy:
    CommandLine|contains: 'proxy'
  condition: sel_img and sel_cmd and sel_proxy
falsepositives:
  - Legitime Proxy-Einrichtung durch Administratoren - bekannte Konten, Hosts und Zeitfenster als Baseline ausnehmen
level: medium

3. Proxy über eine Umgebungsvariable gesetzt (T1090.002). HTTP_PROXY oder HTTPS_PROXY in der Befehlszeile. Wegen der Nutzung in Build-Umgebungen auf level: medium.

title: Proxy ueber eine Umgebungsvariable gesetzt
id: 9a2d6c48-5e71-4b93-a6f2-3c7b4d8e2f15
status: experimental
description: |
  Erkennt das Setzen der Umgebungsvariablen HTTP_PROXY oder HTTPS_PROXY in der Befehlszeile. Viele
  Werkzeuge und Schadprogramme lesen diese Variablen und leiten ihren Verkehr dann ueber einen externen
  Proxy, um die C2-Verbindung zu verschleiern (External Proxy).
references:
  - https://attack.mitre.org/techniques/T1090/002/
author: blue-team.net
tags:
  - attack.command-and-control
  - attack.t1090.002
logsource:
  product: windows
  category: process_creation
detection:
  sel:
    CommandLine|contains:
      - 'HTTP_PROXY'
      - 'HTTPS_PROXY'
  condition: sel
falsepositives:
  - Entwickler und Build-Umgebungen setzen diese Variablen legitim - bekannte Hosts, Konten und Skripte als Baseline ausnehmen
level: medium

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

• Proxy zentral verwalten. Proxy-Einstellungen über Gruppenrichtlinie verteilen und sperren; eine lokale Abweichung ist dann sofort ein Signal statt Normalfall.
• Ausgehenden Verkehr lenken. Direkten Internetzugang der Endpunkte unterbinden und nur über den bekannten Unternehmens-Proxy zulassen - ein fremder Proxy läuft dann ins Leere.
• Befehlszeile und Registry protokollieren. Prozessstart mit Befehlszeile (Event 4688 oder Sysmon) und Registry-Wertänderungen (Sysmon Event 13) zuverlässig erfassen.
• Neue Proxy-Ziele prüfen. Taucht ein unbekannter Proxy-Host auf, diesen gegen bekannte, genehmigte Proxys abgleichen und unbekannte Ziele untersuchen.

Der Test

Die Erkennung lässt sich im Lab gefahrlos prüfen, auf einem Testrechner mit aktivem Sysmon und Command-Line-Auditing:

• Für Regel 1 einen Test-Proxywert unter den Internet Settings setzen und prüfen, dass Sysmon Event 13 ihn zeigt und die Regel greift.
• Für Regel 2 mit netsh einen WinHTTP-Testproxy setzen (und wieder zurücksetzen) und kontrollieren, dass die Regel anspringt.
• Für Regel 3 HTTP_PROXY in einer Testsitzung setzen und prüfen, dass Event 4688 die Befehlszeile zeigt.
• Breiter wird der Test mit den Fällen zu T1090 aus Atomic Red Team.

Fehlalarme und Tuning

• Zentrale Proxy-Verteilung. Viele Umgebungen setzen den Proxy per Richtlinie. Den bekannten Verteilweg, die Konten und die genehmigten Proxy-Hosts als Baseline aufnehmen, bevor alarmiert wird.
• Build- und Entwicklungsumgebungen. HTTP_PROXY und HTTPS_PROXY sind dort Alltag; Regel 3 nach Host und Konto priorisieren statt pauschal zu alarmieren.
• Auf das Ziel schauen. Entscheidend ist der Proxy-Host: Ein bekannter Unternehmens-Proxy ist harmlos, ein unbekanntes externes Ziel nicht - das Ziel in die Bewertung aufnehmen.
• Kette schlägt Einzelzeile. Eine Proxy-Umstellung, gefolgt von ausgehendem Verkehr zu genau diesem neuen Host, ist weit aussagekräftiger als ein Treffer allein - die Korrelation schärft die Bewertung.

Fazit

Der externe Proxy ist ein einfaches, aber wirksames Mittel, um C2-Verkehr zu verschleiern: Der befallene Rechner spricht nicht mehr direkt mit dem Steuerserver, sondern über ein vorgeschaltetes Ziel. Damit das gelingt, muss der Rechner erst umgestellt werden - und genau das ist am Endpunkt sichtbar, in der Registry, über netsh oder über eine Umgebungsvariable. Die verlässlichen Signale sind der gesetzte ProxyServer-Wert, der netsh-WinHTTP-Proxy und das Setzen von HTTP_PROXY oder HTTPS_PROXY. Weil legitime Verwaltung dieselben Stellen nutzt, liegt die Stärke in der Abgrenzung: das Proxy-Ziel, das Konto, der Verteilweg und die Verkettung entscheiden. Die wirksamste Härtung ist, den Proxy zentral zu verwalten und den direkten Internetzugang der Endpunkte zu unterbinden. Weitere Techniken dieser Taktik führt das Lexikon nach Taktik unter Command and Control.