Domain Fronting – ukrywanie ruchu C2

Dzisiejszy wpis zostanie poświęcony wykorzystaniu serwerów CDN jako pośredników (ang. proxy) w ruchu C2. Pokażę również w praktyce jak możemy wykorzystywać CDN w działaniach Red Teamowych i jak wygląda ukrywanie ruchu C2 poprzez Domain Fronting. Dowiemy się w jaki sposób możemy utrudnić detekcję oraz analizę złośliwego ruchu, a także jak tytułowa technika Red Team pozwala na omijanie niektórych reguł systemów bezpieczeństwa w organizacjach.

Teoria, czyli czym jest Domain Fronting?

Aby zrozumieć ideę Domain Frontingu, musimy najpierw zapoznać się z podstawami działania usługi zwanej CDN. CDN (Content Delivery Network) to usługa, która w założeniu ma pomagać w dostarczaniu rozproszonym po świecie użytkownikom usług o wysokim poziomie QoS (Quality of Service). Omówienie działania CDN nie jest celem tego wpisu, więc chciałbym tylko podkreślić, iż jednym z elementów systemu CDN jest system routingu, który umożliwia dostęp do najbardziej optymalnego węzła dostarczającego dane. W dużym uproszczeniu działa to tak, iż serwer CDN odbierając request od klienta, wysyła kolejne zapytanie do jednego z węzłów CDN, docelową domenę umieszczając w polu „Host” requestu HTTP. Przez wiele lat powyższa technika była wykorzystywana do omijania cenzury w niektórych krajach oraz przez producentów systemu takiego jak Signal czy Telegram.

Idea Domain Frontingu

Domain Fronting w działaniach Red Team

Analizując powyższy akapit, widzimy, iż możemy wysyłać zapytania do domen o wysokiej reputacji (azureedge, cloudflare itp.), a docelowy hostname ukrywać w nagłówku „Host”. W przypadku beaconów Cobalt Strike możemy w wystarczającym stopniu customizować parametry połączenia, tak aby wykorzystać opisaną funkcjonalność. Należy pamiętać, iż dostawca CDN „rozszywając” ruch TLS i odczytując element nagłówka „Host” posiada wiedzę, gdzie na prawdę kierujemy pakiety. Należy więc używać tej techniki w połączeniu z innymi, tworząc wielowarstwowy model omijania zabezpieczeń i utrudniania pracy stronie Blue. Poniższy obrazek stanowi fragment Manuala programu Cobalt Strike, w którym opisano jak ustawiać wartości headerów w ruchu HTTP.

Profile cobalt-strike umożliwają użycie customowego nagłówka „Host”

Powyższa technika opisana jest w matrycy MITRE jako „Domain Fronting”, w taktyce „Proxy”.

https://attack.mitre.org/techniques/T1090/004/

Technika Domain Frontingu została z powodzeniem wykorzystana przez środowiska udostępniające usługi RaaS, m.in. w oprogramowaniu SmokedHam. Została także wykryta przez analityków Cisco Talos^[1] i w opisanym przypadku, frontową domeną o wysokiej reputacji była rządowa strona Mjanmy (Birmy).

Ale jak to zrobić?

Wykorzystanie Domain Frontingu nie należy do najtrudniejszych zadań na etapie tworzenia operacji Red Team. Przede wszystkim potrzebujemy usługi CDN, która będzie wskazywać na naszą domenę C2. Do wybory mamy szereg dostawców, w tym bezpłatnych. W poniższym przykładzie wykorzystano CDN od Microsoftu (Azure CDN).

Konfiguracja CDN Azure

Na powyższym obrazku widzimy konfigurację usługi CDN w chmurze Azure. Pole „Endpoint hostname”, wskazuje na serwer CDN w domenie azureedge.net, który ma dostarczać złośliwy content hostowany na domenie .pl. Przetestujmy sobie to rozwiązanie, hostując plik „test.html”, zawierający krótki tekst.

Hosting pliku test.html w domenie .pl

Zawartość pliku test.html

Aby odczytać zawartość pliku test.html, bez odwołania się do domeny .pl, należy wysłać request do hosta „Endpoint hostname, tj. do domeny azureedge.

W powyższym przykładzie nie wykorzystaliśmy do tej pory nagłówka „Host” w requeście, ponieważ do tej pory odnosiliśmy się to tzw. Endpointa CDN, czyli końcowego serwera, który cachuje i dostarcza zasoby z oryginalnego URLa. Rozproszony system CDN musi się ze sobą komunikować w celu sprawnego dostarczania treści, więc inne serwery CDN Microsoftu również mogą uzyskać dostęp do zasobów hosta azureedge.net poprzez nagłówek „Host”. Zweryfikujmy czy jest to możliwe, z wykorzystaniem jednej z powszechnie znanych domen, które routują ruch w ramch CDNu Azure.

Dostęp do pliku „test.html” poprzez domenę natick.research.microsoft.com

Na powyższym obrazku widzimy, iż udało się uzyskać dostęp do pliku test.html z wykorzystaniem domeny „https://natick.research.microsoft.com” i nagłówka „Host”, w którym wskazaliśmy nasz CDN Endpoint. Ruch odbywa się wykorzystaniem protokołu TLS, więc bez rozszywania ruchu, analizatory i firewalle nie są w stanie zweryfikować zawartości żądania HTTP.

Jakie domeny można wykorzystać?

Ilość domen, które mogą być wykorzystywane w celu przekazywania ruchu jest ograniczona i prawdopodobnie stale się kurczy. Wynika to z rosnącej świadomości administratorów tych usług. Są jednak w sieci listy hostów, które przez cały czas mogą być traktowane jako frontowa domena w poszczególnych CDN. Takie domeny, podobnie jak „natick.research.microsoft.com” mogą być wykorzystywane do proxowania ruchu. W celu identyfikacji takich domen skorzystałem z jednej z takich list i zweryfikowałem jej zawartość dzięki prostego, Pythonowego skryptu:

Skrypt weryfikujący frontowalne domeny

Efekt działania skryptu

Po krótkim researchu udało się zidentyfikować kilkadziesiąt domen, które umożliwiają przekazywanie ruchu w ramach CDNu Microsoftu.

Czas na weryfikację

Proces weryfikacji techniki Domain Frontingu należy rozpocząć od stworzenia odpowiedniego listenera. Elementy, które ujmujemy w polu „HTTPS Hosts”, to hosty, do których łączy uruchomiony Beacon. Musimy więc wpisać tu domeny, które odkryliśmy w poprzednim kroku.

Konfiguracja listenera serwera Cobalt Strike

Powyższa konfiguracja spowoduje, iż Beacon Cobalt Strike będzie komunikował się z serwerami api.[…].org oraz cdn.[….]rs.com. Serwery te, co udowodniliśmy sobie w poprzednim akapicie, mogą przekazywać dalej nasz ruch. Musimy więc w jakimś miejscu wskazać co ma być wpisane w nagłówku „Host” podczas komunikacji z C2. Powyższe ustawienia możemy zdefiniować w tzw. malleable profile naszego serwera. Poniżej znajduje się fragment tych ustawień ze zdefiniowanym nagłówkiem „Host”, wskazującym na naszą złośliwą domenę:

Definicja headera „Host” w profilu serwera Cobalt Strike

Powyższe ustawienia spowodują, iż Beacon zacznie łączyć się z domenami o wysokiej reputacji, ale ruch C2 będzie forwardowany do złośliwego hosta.

Po uruchomieniu Beacona na stacji ofiary, udało się zaobserwować zapytania DNS o frontowalne domeny wysokiej reputacji. Następnie nawiązano połączenie TLS z tymi domenami. Nagłówek „Host” został prawidłowo zinterpretowany i nawiązano ruch C2 pomiędzy ofiarą, a serwerem Cobalt Strike.

Uzyskane połączenie z Beacona Cobalt Strike

Podsumowanie

Na powyższym przykładzie widać jak w łatwy sposób ukrywać docelowe hosty w komunikacji C2. W połączeniu z pozostałymi metodami Proxy/OPSEC takimi jak redirectory czy sieć TOR, analiza ruchu sieciowego złośliwego komunikacji staje się utrudniona. Najpopularniejszą metodą detekcji i obrony przed opisaną techniką jest wykorzystywanie firewalli i bramek proxy w organizacji. Systemy te powinny rozszywać wychodzący ruch TLS i analizować nagłówki wiadomosci HTTP. Najprostszym rozwiązaniem jest blokowanie ruchu, który zawiera nagłówki „Host” niezgodne z domeną wskazaną w polu SNI (Server Name Indication) pakietu TLS.

[1] https://blog.talosintelligence.com/2021/11/attackers-use-domain-fronting-technique.html