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 serwis, który 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ć, że 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, że serwer CDN odbierając request od klienta, wysyła kolejne zapytanie do jednego z węzłów CDN, a docelowy serwer umieszcza 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 oprogramowania takiego jak Signal czy Telegram.

Domain Fronting w działaniach Red Team

Analizując powyższy akapit, widzimy, że możemy wysyłać zapytania do domen o wysokiej reputacji (azureedge, cloudflare itp.), a docelowy hostname ukrywać w nagłówku „Host”. Wygenerowany ruch sieciowy ograniczy się do dwóch etapów:

• wygenerowanie zapytania DNS do domeny o wysokiej reputacji
• nawiązanie połączenia TLS z hostem wysokiej reputacji

Za dalszą część ruchu odpowiada węzeł CDN, który analizuje nagłówki HTTP i przekazuje pakiety do docelowego, złośliwego hosta.

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ć, że dostawca CDN „rozszywając” ruch TLS i odczytując element nagłówka „Host” posiada wiedzę, gdzie docelowo 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.

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

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 serwer C2. Do wybory mamy szereg dostawców, w tym bezpłatnych. W poniższym przykładzie wykorzystano CDN od Microsoftu (Azure CDN).

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.

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

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. Inne serwery CDN Azure również mogą uzyskać dostęp do zasobów hosta azureedge.net poprzez nagłówek „Host”. Zweryfikujmy czy jest to możliwe, z wykorzystaniem jednego z powszechnie znanych hostów „natick.research.microsoft.com”.

Na powyższym obrazku widzimy, że 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 nadal 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ść za pomocą prostego, Pythonowego skryptu:

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

Praktyka z wykorzystaniem Cobalt Strike

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.

Powyższa konfiguracja spowoduje, że 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. To 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 CDN Endpoint azureedge, który z kolei wskazuje na serwer Cobalt Strike w domenie .pl.

Powyższe ustawienia spowodują, że 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.

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