Domain Fronting erkennen: C2 hinter einem CDN

Command and Control lebt davon, unauffällig zu bleiben. Domain Fronting treibt das auf die Spitze: Statt einen eigenen Proxy-Host anzusteuern, nutzt der Angreifer die geteilte Infrastruktur eines großen CDN. Von außen sieht die Verbindung aus wie jeder andere Zugriff auf ein bekanntes, hoch angesehenes Ziel - dieselbe Edge-Adresse, die auch legitime Dienste verwenden. Das Besondere daran ist für die Verteidigung unbequem: Die Technik hinterlässt kein einzelnes, eindeutiges Host-Event. Dieser Beitrag bleibt auf der Erkennungsseite und zeigt, woran sich Domain Fronting als Muster erkennen lässt, wo die Sensorik an ihre Grenzen stößt und warum SNI und DNS allein nicht ausreichen - nicht, wie man C2 verschleiert.

Was der Angreifer tut - und die Abgrenzung zum gewöhnlichen Proxy

Beim gewöhnlichen Proxy stellt der befallene Rechner seinen Verkehr auf einen vorgeschalteten Host um. Dieser Proxy ist ein eigenes, benennbares Ziel - eine Adresse, die man auf eine Sperrliste setzen kann, und eine Umstellung, die am Endpunkt in Registry, netsh oder Umgebungsvariable sichtbar wird. Domain Fronting funktioniert anders und lässt genau diese Angriffsfläche verschwinden.

Das Prinzip - auf der Ebene der Einordnung, nicht als Anleitung - stützt sich auf eine Eigenschaft geteilter CDN-Infrastruktur: Ein CDN beendet die TLS-Verbindung an seinem Rand und entscheidet erst danach, anhand des HTTP-Host-Headers, an welches Backend die Anfrage weitergereicht wird. Der TLS-Verbindungsaufbau nennt über den Server-Name-Indicator (SNI) eine harmlose, hoch angesehene Frontdomäne, die auf demselben CDN liegt. Der Host-Header innerhalb des verschlüsselten Tunnels nennt dagegen das eigentliche Ziel. Das CDN liest den Host-Header und stellt die Verbindung zum C2-Backend her. Nach außen bleibt nur die Frontdomäne sichtbar.

Der entscheidende Unterschied für die Verteidigung: Es gibt keinen eigenen Proxy-Host, den man blockieren könnte, ohne zugleich einen legitimen, breit genutzten Dienst zu treffen. Und es gibt keine Endpunkt-Umstellung, die sich protokollieren ließe - die Weiche liegt im CDN, nicht auf dem Rechner. Was bleibt, ist der Verkehr selbst und der Widerspruch, den er in sich trägt.

Warum SNI und DNS allein nicht reichen

Das ist der Kern der Technik und der wichtigste Punkt dieses Beitrags. Bei klassischem TLS ist der SNI im Klartext sichtbar - aber er nennt die Frontdomäne, nicht das Ziel. Die DNS-Abfrage löst ebenfalls die Frontdomäne auf und zeigt auf eine reguläre CDN-Adresse. Beide Signale sind für sich genommen vollständig unauffällig und von legitimem Verkehr nicht zu unterscheiden. Wer allein auf SNI oder DNS schaut, sieht einen harmlosen Zugriff auf ein bekanntes Ziel.

Das verräterische Signal ist der Host-Header - und der liegt innerhalb des TLS-Tunnels. Ohne TLS-Inspektion ist er nicht sichtbar. Erst wo ein Proxy die Verbindung terminiert und sowohl den TLS-Namen als auch den Host-Header protokolliert, wird der Widerspruch greifbar: SNI zeigt auf die Frontdomäne, der Host-Header auf ein anderes Ziel, beide auf demselben CDN. Mit Encrypted Client Hello (ECH) beziehungsweise verschlüsseltem SNI verschwindet auch der TLS-Name aus der Klartextsicht, sodass noch weniger übrig bleibt. Die Konsequenz für die Erkennung: Domain Fronting ist kein Fall für eine eindeutige Einzelsignatur auf SNI oder DNS, sondern für eine Korrelation mehrerer Beobachtungen - idealerweise dort, wo der Host-Header überhaupt sichtbar gemacht wird.

Welche Logquellen die Technik zeigt

• TLS-inspizierender Proxy zuerst. Nur hier werden TLS-Name und HTTP-Host-Header gemeinsam sichtbar. Ein Proxy, der beide Felder protokolliert, kann den Widerspruch zwischen Frontdomäne (SNI) und Zieldomäne (Host) erkennen - das direkteste Signal, aber nur verfügbar, wo TLS aufgebrochen wird.
• DNS-Telemetrie als Kontext, nicht als Beweis. DNS zeigt die Auflösung der Frontdomäne auf das CDN. Für sich genommen unauffällig; nützlich nur in der Zusammenschau, etwa wenn eine selten genutzte Frontdomäne unmittelbar vor auffälligem CDN-Verkehr aufgelöst wird.
• TLS-Sicht soweit möglich. SNI, Zertifikat und JA3/JA4-Fingerabdruck des Clients. Der Fingerabdruck verrät nicht das Ziel, kann aber eine bekannte C2-Implementierung kennzeichnen, deren Verkehr scheinbar nur zu einem CDN geht. Bei ECH ist der SNI nicht mehr lesbar - dann trägt vor allem das Verbindungsmuster.
• Host-Ziel-Beziehung soweit die Sensorik sie hergibt. Wo der Host-Header sichtbar ist (inspizierender Proxy, entschlüsselter Zeek-Verkehr), ist die Beziehung zwischen beanspruchtem Host und tatsächlicher CDN-Adresse auswertbar. Ohne Inspektion bleibt nur die Verbindungs-Metadatenebene.
• Firewall und Egress. Die Firewall sieht ausgehende Verbindungen zu CDN-Adressbereichen. Allein harmlos - wertvoll wird sie, wenn direkter 443-Ausgang am inspizierenden Proxy vorbei möglich ist und so die einzige Stelle umgeht, an der der Host-Header sichtbar würde.
• NDR und Zeek. Zeek liefert in ssl.log den Servernamen und den JA3/JA4-Fingerabdruck, in conn.log Dauer, Byte-Verhältnis und Verbindungszahl. Ist der Verkehr entschlüsselt, zeigt http.log zusätzlich den Host-Header. Daraus baut sich das Verbindungsmuster, aus dem die Korrelation entsteht.

Das Muster im Log

Weil es kein Einzelereignis gibt, das Domain Fronting beweist, tragen mehrere schwächere Signale gemeinsam. Das stärkste ist der Widerspruch zwischen TLS-Name und Host-Header auf demselben CDN - sichtbar nur bei TLS-Inspektion. Daneben steht das Verbindungsmuster: regelmäßige, taktgenaue Verbindungen zu einem CDN-Endpunkt (Beaconing), ungewöhnlich viele verschiedene Host-Namen hinter derselben CDN-Adresse von einem einzelnen Client, oder lange, datenarme Verbindungen mit auffälligem Byte-Verhältnis. Ein weiteres schwaches Signal ist ein Host-Header, der direkt auf einen rohen CDN-Edge-Namen zeigt, statt auf eine eigene, per CNAME dahintergelegte Unternehmensdomäne. Keines dieser Signale ist für sich beweiskräftig. Erst die Verkettung - ein C2-typischer Client-Fingerabdruck, der taktgenau zu einer CDN-Frontdomäne spricht, deren Host-Header nicht zur Frontdomäne passt - ergibt ein belastbares Bild.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft und setzen bewusst auf der Proxy-Logquelle auf, weil dort der Host-Header verfügbar ist. Sie liefern Korrelate, keine Beweise - jede für sich braucht die Einordnung in den Kontext. Alle drei setzen einen Proxy voraus, der den Host-Header (cs-host) protokolliert; das ist bei TLS-Verkehr nur mit Inspektion der Fall.

1. Host-Header zeigt auf einen rohen CDN-Edge-Namen (T1090.004). Ein schwaches Signal auf level: low, weil auch legitime Dienste rohe Edge-Namen ansprechen. Erst in der Zusammenschau mit dem Verbindungsmuster wird es aussagekräftig.

title: HTTP-Host-Header zeigt auf rohen CDN-Edge-Namen
id: c1fbc1a7-21fe-4c39-9539-2f9ddacf5810
status: experimental
description: |
  Erkennt HTTP-Anfragen, deren Host-Header direkt auf einen rohen Edge- oder
  Default-Namen eines grossen CDN zeigt (zum Beispiel ein CloudFront- oder
  Azure-Edge-Name) statt auf eine eigene, per CNAME dahintergelegte Unternehmensdomaene.
  Bei Domain Fronting setzt die Schadsoftware im Host-Header das eigentliche Ziel
  hinter dem Front. Dieses Signal ist nur auf einem TLS-inspizierenden Proxy sichtbar,
  der den Host-Header sieht, und es ist bewusst niedrig eingestuft, weil auch legitime
  Dienste rohe Edge-Namen ansprechen koennen.
references:
  - https://attack.mitre.org/techniques/T1090/004/
author: blue-team.net
date: 2026-10-06
tags:
  - attack.command-and-control
  - attack.t1090.004
logsource:
  category: proxy
detection:
  sel_edge:
    cs-host|endswith:
      - '.cloudfront.net'
      - '.azureedge.net'
      - '.azurefd.net'
      - '.trafficmanager.net'
      - '.web.core.windows.net'
      - '.fastly.net'
      - '.fastlylb.net'
      - '.workers.dev'
      - '.b-cdn.net'
  condition: sel_edge
falsepositives:
  - Legitime Anwendungen und SDKs, die einen CDN direkt ueber seinen Edge-Namen ansprechen - bekannte Dienste, Clients und Ziele als Baseline ausnehmen
level: low

2. Beaconing-Kadenz zu einem CDN-Endpunkt (T1090.004). Eine Korrelation auf level: medium: auffällig viele Verbindungen eines einzelnen Clients zu demselben CDN-Host in kurzer Zeit. Die Schwelle ist ein Startwert und muss an die Umgebung angepasst werden.

title: CDN-Verbindung als Basisereignis
id: a7c32506-6be4-4887-941b-9a61f1c8d2af
name: proxy_cdn_connection_base
status: experimental
description: |
  Basisereignis fuer ausgehende Verbindungen ueber den Proxy zu einem grossen CDN.
  Dient als Grundlage fuer die Korrelation auf Beaconing-Kadenz.
references:
  - https://attack.mitre.org/techniques/T1090/004/
author: blue-team.net
logsource:
  category: proxy
detection:
  sel_cdn:
    cs-host|endswith:
      - '.cloudfront.net'
      - '.azureedge.net'
      - '.azurefd.net'
      - '.trafficmanager.net'
      - '.fastly.net'
      - '.workers.dev'
      - '.akamaiedge.net'
      - '.edgekey.net'
  condition: sel_cdn
---
title: Beaconing-Kadenz zu einem CDN-Endpunkt
id: fe1b9bb9-d50f-4150-a583-ba952c2de773
status: experimental
description: |
  Erkennt, wenn ein einzelner Client in kurzer Zeit auffaellig viele Verbindungen zu
  demselben CDN-Host aufbaut. Das ist ein moegliches Zeichen fuer automatisiertes
  Beaconing hinter einem Front (Domain Fronting), bei dem der TLS-Name auf eine
  harmlose Frontdomaene zeigt, der Verkehr aber an einen C2-Endpunkt geht. Das Signal
  ist ein Korrelat, kein Beweis, und die Schwelle ist an die Umgebung anzupassen.
references:
  - https://attack.mitre.org/techniques/T1090/004/
author: blue-team.net
date: 2026-10-06
tags:
  - attack.command-and-control
  - attack.t1090.004
correlation:
  type: event_count
  rules:
    - proxy_cdn_connection_base
  group-by:
    - src_ip
    - cs-host
  timespan: 1h
  condition:
    gte: 120
falsepositives:
  - Software-Updates, Telemetrie und Streaming erzeugen ebenfalls viele CDN-Verbindungen - bekannte Dienste und Ziele als Baseline ausnehmen und die Schwelle anpassen
level: medium

3. Viele verschiedene Host-Namen hinter einer CDN-Adresse (T1090.004). Eine zweite Korrelation auf level: medium: ein einzelner Client spricht auffällig viele verschiedene Host-Namen hinter derselben CDN-Ziel-IP an. Das kann auftreten, wenn dieselbe Frontdomäne für wechselnde Backend-Ziele genutzt wird.

title: CDN-Verbindung mit Zieladresse als Basisereignis
id: c39bba55-0fb8-414f-931a-a38d3b7da653
name: proxy_cdn_connection_dst_base
status: experimental
description: |
  Basisereignis fuer ausgehende Proxy-Verbindungen zu einem grossen CDN mit erfasster
  Ziel-IP. Dient als Grundlage fuer die Korrelation auf viele verschiedene Host-Namen
  hinter derselben CDN-Adresse.
references:
  - https://attack.mitre.org/techniques/T1090/004/
author: blue-team.net
logsource:
  category: proxy
detection:
  sel_cdn:
    cs-host|endswith:
      - '.cloudfront.net'
      - '.azureedge.net'
      - '.azurefd.net'
      - '.fastly.net'
      - '.workers.dev'
      - '.akamaiedge.net'
  condition: sel_cdn
---
title: Viele verschiedene Host-Namen hinter einer CDN-Adresse
id: 20ee8908-a682-47bf-8460-ba86e2f889fb
status: experimental
description: |
  Erkennt, wenn ein einzelner Client ueber kurze Zeit auffaellig viele verschiedene
  Host-Namen hinter derselben CDN-Ziel-IP anspricht. Das kann auftreten, wenn ein
  Werkzeug dieselbe Frontdomaene fuer wechselnde Backend-Ziele nutzt (Domain Fronting).
  Das Signal ist ein Korrelat und braucht eine an die Umgebung angepasste Schwelle,
  da ein TLS-inspizierender Proxy noetig ist, der den Host-Header je Verbindung sieht.
references:
  - https://attack.mitre.org/techniques/T1090/004/
author: blue-team.net
date: 2026-10-06
tags:
  - attack.command-and-control
  - attack.t1090.004
correlation:
  type: value_count
  rules:
    - proxy_cdn_connection_dst_base
  group-by:
    - src_ip
    - dst_ip
  timespan: 1h
  condition:
    gte: 30
    field: cs-host
falsepositives:
  - CDNs bedienen legitim sehr viele Host-Namen ueber dieselbe Adresse - die Korrelation auf einzelne Clients beziehen und bekannte Dienste als Baseline ausnehmen
level: medium

Grenzen der Erkennung

• Ohne TLS-Inspektion kein Host-Header. Wo TLS nicht aufgebrochen wird, bleibt der Host-Header verborgen - dann tragen nur noch Verbindungs-Metadaten und der Client-Fingerabdruck. Die Regeln 1 bis 3 setzen einen Proxy voraus, der cs-host protokolliert.
• ECH und verschlüsselter SNI. Mit Encrypted Client Hello verschwindet auch der TLS-Name aus der Klartextsicht. Die Erkennung verlagert sich dann vollständig auf Verbindungsmuster und Fingerabdrücke.
• Große CDNs haben Fronting eingeschränkt. Mehrere große Anbieter haben klassisches Domain Fronting seit 2018 technisch erschwert oder unterbunden. Die Technik ist dadurch seltener, aber nicht verschwunden - sie lebt auf anderen Diensten und in Varianten weiter.
• Kollateralrisiko bei der Sperre. Die Frontdomäne pauschal zu blockieren trifft legitime Dienste auf demselben CDN. Deshalb ist Erkennung plus gezielte Untersuchung meist sinnvoller als eine breite Sperre.

Härtung und Egress Controls

• Ausgehenden Verkehr über einen inspizierenden Proxy zwingen. Direkten 443-Ausgang der Endpunkte unterbinden und TLS am Proxy inspizieren - nur so wird der Host-Header überhaupt sichtbar, an dem Domain Fronting erkennbar ist.
• Kein Vorbei am Proxy. Jeden direkten Internetpfad der Clients schließen; sonst umgeht der Verkehr genau die Stelle, die den Widerspruch zeigen könnte.
• Proxy so konfigurieren, dass er SNI und Host protokolliert. Beide Felder gemeinsam sind die Voraussetzung für die Mismatch-Erkennung. Fehlt eines, bleibt nur das Verbindungsmuster.
• Client-Fingerabdrücke und CDN-Baselines pflegen. Bekannte, legitime CDN-Nutzung (Updates, Telemetrie, Streaming) als Baseline erfassen, damit die Korrelationsregeln auf das Ungewöhnliche zeigen statt auf den Alltag.
• Egress nach Zielkategorie steuern. Wo möglich, ausgehenden Verkehr auf benötigte Kategorien begrenzen und neue oder selten genutzte CDN-Ziele gesondert prüfen.

Der Test im Lab

Die Erkennung lässt sich gefahrlos im eigenen Lab prüfen, ohne echten Missbrauch fremder CDN-Infrastruktur:

• Einen eigenen Reverse Proxy aufsetzen, der anhand des Host-Headers auf unterschiedliche Backends verteilt. So lässt sich der Mismatch zwischen TLS-Name und Host-Header im eigenen Netz nachstellen und die Proxy-Protokollierung prüfen, ohne eine fremde Frontdomäne zu verwenden.
• Für Regel 1 im Lab eine Anfrage erzeugen, deren Host-Header auf einen rohen Edge-Namen zeigt, und kontrollieren, dass die Proxy-Protokollierung ihn in cs-host zeigt und die Regel greift.
• Für die Regeln 2 und 3 ein Skript taktgenaue Verbindungen beziehungsweise wechselnde Host-Namen zum Lab-Proxy erzeugen lassen und prüfen, dass die Korrelation bei der gewählten Schwelle anspringt.
• Breiter wird der Test mit den Fällen zu T1090.004 aus Atomic Red Team; die Schwellen danach an die eigene Baseline anpassen.

Fehlalarme und Tuning

• Legitime CDN-Nutzung ist allgegenwärtig. Updates, Telemetrie und Streaming erzeugen genau die Verbindungsmuster, auf die die Korrelationen zielen. Ohne Baseline werden die Regeln 2 und 3 laut - bekannte Dienste und Ziele zuerst ausnehmen.
• Rohe Edge-Namen kommen auch legitim vor. Regel 1 steht deshalb auf level: low und ist als Anreicherung gedacht, nicht als eigenständiger Alarm.
• Schwellen sind Startwerte. Die Werte in den Korrelationen (120 Verbindungen, 30 Host-Namen pro Stunde) passen zur Umgebung, nicht umgekehrt - vor dem Alarmieren an die eigene Baseline anpassen.
• Kette schlägt Einzelsignal. Ein auffälliger Client-Fingerabdruck plus taktgenaue CDN-Verbindung plus ein nicht zur Frontdomäne passender Host-Header ist weit aussagekräftiger als jedes Signal allein - die Korrelation entscheidet.

Analysten-Checkliste

1. Liegt der Treffer auf einem TLS-inspizierenden Proxy, der TLS-Name und Host-Header gemeinsam protokolliert? Wenn nein, steht nur das Verbindungsmuster zur Verfügung - das bei der Bewertung berücksichtigen.
2. Passt der Host-Header zur Frontdomäne aus dem TLS-Namen, oder zeigen beide auf unterschiedliche Ziele auf demselben CDN? Der Widerspruch ist das stärkste Signal.
3. Welcher Client ist betroffen, und passt die CDN-Nutzung zu seiner Rolle? Ein Server, der plötzlich taktgenau zu einem CDN spricht, ist auffälliger als ein Arbeitsplatz mit Streaming.
4. Gibt es einen auffälligen JA3/JA4-Fingerabdruck, der zu einer bekannten C2-Implementierung passt?
5. Ist das Verbindungsmuster beaconing-typisch - regelmäßiger Takt, datenarme Verbindungen, langes Bestehen?
6. Gibt es einen direkten 443-Pfad am inspizierenden Proxy vorbei, über den der Verkehr die Host-Header-Sicht umgangen haben könnte?
7. Reiht sich der Treffer in andere Beobachtungen am selben Host ein (verdächtiger Prozess, frische Persistenz, ungewöhnliche Eltern-Kind-Beziehung)? Die Verkettung entscheidet über die Bewertung.

Fazit

Domain Fronting ist der unbequeme Fall in der Proxy-Familie: Es gibt keinen eigenen Proxy-Host und keine Endpunkt-Umstellung, und der einzige eindeutige Hinweis - der Widerspruch zwischen TLS-Name und Host-Header - liegt verschlüsselt im Tunnel. SNI und DNS zeigen beide nur die harmlose Frontdomäne; aus ihnen allein lässt sich Domain Fronting nicht erkennen. Wer es sichtbar machen will, braucht einen TLS-inspizierenden Proxy, der SNI und Host gemeinsam protokolliert, und eine Korrelation aus Verbindungsmuster, Client-Fingerabdruck und Host-Ziel-Beziehung statt einer einzelnen Signatur. Die drei geprüften Regeln liefern genau solche Korrelate - als Bausteine, die erst im Kontext tragen. Die wirksamste Härtung ist, allen Ausgang über einen inspizierenden Proxy zu zwingen und jeden direkten Pfad daran vorbei zu schließen. Weitere Techniken dieser Taktik führt das Lexikon nach Taktik unter Command and Control; verwandte Wege zeigen Cobalt Strike erkennen und DNS-Tunneling erkennen.