HOLLOWGRAPH: malware ukrywa C2 w kalendarzu Microsoft 365

HOLLOWGRAPH to implant dla Windows, który nie potrzebuje klasycznego serwera C2 do odbierania poleceń i wysyłania plików. Wykorzystuje przejęte konto Microsoft 365, Microsoft Graph API oraz zdarzenia kalendarza jako dwukierunkową skrzynkę kontaktową. Polecenia i wyniki są przenoszone w załącznikach do spotkań ustawionych na 13 maja 2050 roku, a osobny tunel DNS przez rekordy AAAA odświeża poświadczenia Entra ID. Dla zapory ruch wygląda jak legalne połączenie z chmurą Microsoft, dlatego detekcja musi przenieść się z reputacji domeny na tożsamość, zachowanie API, pocztę i DNS.

Group-IB opublikował analizę HOLLOWGRAPH 20 lipca 2026 roku. Zespół zidentyfikował co najmniej 12 zainfekowanych systemów, z których około trzy aktywnie komunikowały się z operatorem w okresie obserwacji. Najwcześniejszy potwierdzony ruch pochodził z 3 czerwca, a najpóźniejszy z 9 lipca. Telemetria wskazuje na ukierunkowanie na podmioty izraelskie, nie masową kampanię oportunistyczną.

Co zostało potwierdzone

HOLLOWGRAPH jest biblioteką DLL skompilowaną jako .NET NativeAOT. Obsługuje tylko dwie funkcje nazwane get i send, ponieważ stanowi komponent większego zestawu narzędzi. Get pobiera załącznik z wcześniej przygotowanego wydarzenia kalendarza, odszyfrowuje polecenie i zwraca je loaderowi. Send szyfruje wskazany plik, dzieli go na załączniki i tworzy wydarzenie, które operator może odebrać.

Group-IB z wysoką pewnością łączy format poleceń i zachowanie komponentu z frameworkiem Cavern. Potencjalny związek z aktorem Lyceum o irańskich powiązaniach został oceniony wyłącznie z niską pewnością. Nie należy więc opisywać HOLLOWGRAPH jako potwierdzonego narzędzia konkretnej grupy. Podobieństwo techniczne jest dowodem na rodzinę frameworka, nie na tożsamość operatora.

Warstwa	Potwierdzone zachowanie
host	DLL .NET NativeAOT i plik konfiguracji logAzure.txt
C2 główne	Microsoft Graph API i kalendarz przejętej skrzynki
pobieranie poleceń	załączniki wydarzeń z 13.05.2050 i tematem Event ID
eksfiltracja	zaszyfrowane załączniki FileN.txt w nowych wydarzeniach
kanał zapasowy	tunel DNS w zapytaniach AAAA
kryptografia	RSA-OAEP oraz AES-256-GCM, osobne klucze na kierunek
skala obserwacji	co najmniej 12 hostów, około 3 aktywne
atrybucja	Cavern: wysoka pewność; Lyceum: niska pewność

Kalendarz jako dead drop

Operator tworzy w przejętej skrzynce wydarzenie na stałą datę w 2050 roku i dołącza plik z poleceniem. Implant pyta endpoint calendarView o wąskie okno czasu i temat zawierający identyfikator zadania, pobiera załącznik oraz odszyfrowuje jego zawartość. Przy wysyłaniu danych tworzy własne spotkanie, dodaje zaszyfrowane fragmenty w plikach FileN.txt, a następnie zmienia temat na wzorzec rozpoznawany przez operatora.

Daleka data zmniejsza szansę, że właściciel skrzynki zobaczy wydarzenie w codziennym widoku. Nie ukrywa go jednak przed API, audytem ani wyszukiwaniem. Dla obrony to cenna cecha o dużej stabilności: spotkania tworzone maszynowo na 13 maja 2050 roku, nietypowe tematy i serie małych załączników są lepszym sygnałem niż adres IP, który może się zmienić.

Kanał działa przez infrastrukturę Microsoft, ale nie jest „bezplikowy”. Po stronie M365 powstają obiekty kalendarza i załączniki, po stronie hosta istnieje implant oraz konfiguracja. Threat hunting powinien łączyć oba widoki. Samo zablokowanie Graph API może uszkodzić legalne aplikacje, a usunięcie wydarzeń nie usuwa malware z hosta.

Szyfrowanie chroni operację napastnika

HOLLOWGRAPH używa hybrydowego szyfrowania. Losowy klucz AES-256-GCM chroni właściwy payload, a RSA-OAEP zabezpiecza klucz symetryczny. Oddzielne pary RSA obsługują polecenia przychodzące i eksfiltrację. Dzięki temu przejęcie jednego kierunku komunikacji nie musi automatycznie ujawnić drugiego.

Dla zespołu SOC oznacza to, że inspekcja załącznika nie pokaże prostego tekstu polecenia ani dokumentu. Szyfrowana, losowo wyglądająca treść w kalendarzu jest jednak anomalią. Wykrywanie nie musi łamać kryptografii; wystarczy wskazać nietypową kombinację: aplikacyjne logowanie, dostęp do calendarView w dalekiej przyszłości, tworzenie wydarzeń bez typowego klienta, załączniki tekstowe o dużej entropii i powtarzalny schemat tematu.

Nie należy próbować samodzielnie odszyfrowywać dowodów poprzez uruchamianie próbki. Analiza pamięci oraz konfiguracji może ujawnić klucze w kontrolowanym laboratorium, ale w środowisku produkcyjnym priorytetem jest izolacja, zabezpieczenie danych i unieważnienie poświadczeń.

Tunel DNS odświeża poświadczenia Entra ID

Implant musi utrzymać dostęp do Microsoft Graph. Dlatego drugi kanał przesyła tenant ID, client ID, client secret i adres skrzynki przez specjalnie kodowane odpowiedzi IPv6. HOLLOWGRAPH wykonuje zapytania AAAA do rozbrojonej domeny cloudlanecdn[.]com. Odpowiedzi dostarczają długość oraz fragmenty danych, które malware składa i zapisuje w pliku logAzure.txt.

Kanał DNS nie zastępuje głównego C2; służy utrzymaniu konfiguracji i poświadczeń. To przykład, dlaczego kontrola tylko HTTP proxy jest niewystarczająca. Resolver powinien rejestrować nazwy, typy rekordów, klienta, odpowiedź i częstotliwość. Długie lub strukturalne subdomeny, seryjne AAAA i stałe zapytania z hosta, który zwykle nie potrzebuje IPv6, zasługują na analizę.

Techniczne podstawy opisuje nasz przewodnik wykrywanie tunelowania DNS. Dobra reguła uwzględnia entropię, długość etykiet, NXDOMAIN, typ rekordu i zachowanie konkretnego hosta zamiast blokować wszystkie rekordy AAAA.

Tożsamość aplikacyjna jest częścią C2

Konfiguracja zawiera tenant ID, client ID, client secret oraz skrzynkę. To wskazuje na uwierzytelnienie aplikacyjne, nie zwykłe interaktywne logowanie użytkownika. Tradycyjny alert „impossible travel” może niczego nie wykryć, ponieważ aplikacja działa bez człowieka i używa przewidywalnego przepływu OAuth.

Zespół Entra powinien przejrzeć service principals, aplikacje, secrets, przyznane uprawnienia Graph i ostatnie użycie. Szczególnie ważne są aplikacje z dostępem do skrzynek lub kalendarzy, poświadczenia o długim okresie ważności, właściciele spoza aktualnego zespołu i zgody administracyjne bez change ticketu.

Zasada najmniejszych uprawnień musi działać również dla API. Jeżeli aplikacja ma czytać jeden kalendarz, nie powinna otrzymywać globalnego dostępu do wszystkich skrzynek. Wzorzec z artykułu o tożsamościach agentów i NHI ma tu bezpośrednie zastosowanie: inwentarz, właściciel, krótki sekret, ograniczony zakres i telemetryka.

Detekcja w Microsoft 365

Najpierw zabezpiecz Unified Audit Log oraz logi logowania aplikacji i service principals. Następnie szukaj kombinacji sygnałów:

wydarzenia na 13 maja 2050 roku tworzone przez nietypową aplikację;
zapytania calendarView dla wąskiego okna w dalekiej przyszłości;
tematy zawierające Event ID lub wzorzec Boss oraz ID;
załączniki nazwane File0.txt, File1.txt i podobnie;
seryjne create, attachment upload i rename/PATCH;
dostęp aplikacyjny do skrzynki, której właściciel nie zna integracji;
nowy client secret albo zmiana poświadczeń bez zatwierdzenia;
duży wolumen danych w załącznikach kalendarza.

Nie wszystkie te elementy osobno są złośliwe. Testy, automatyzacja kalendarza i archiwizacja mogą tworzyć wydarzenia w przyszłości. Reguła powinna wymagać kilku cech i kontekstu tożsamości. Po wykryciu nie usuwaj od razu wszystkiego: najpierw eksportuj metadane, treść obiektu, identyfikatory i logi, aby zachować timeline.

Przegląd konfiguracji można połączyć z szerszym audytem bezpieczeństwa Microsoft 365, obejmującym zgody aplikacji, reguły pocztowe, MFA i retencję audytu.

Detekcja na hoście i w sieci

Na Windows szukaj DLL NativeAOT uruchamianych przez nietypowy loader, pliku logAzure.txt poza legalnym kontekstem, procesów wykonujących równocześnie DNS i połączenia do Graph oraz zmian w katalogach roboczych. Nazwa pliku nie jest wystarczająca; legalny program może tworzyć identyczny log. Koreluj hash, ścieżkę, proces nadrzędny, podpis i pierwsze uruchomienie.

W sieci monitoruj domenę IOC oraz wzorce tunelu, ale nie ograniczaj się do niej. Operator może zmienić domenę, tenant lub skrzynkę. Stabilniejsze są zapytania AAAA o strukturalnych etykietach, nowa aplikacja komunikująca się z Graph i duży ruch załączników kalendarza z hosta, który nie jest klientem poczty.

EDR, DNS i M365 powinny spotkać się we wspólnej osi czasu. Detection engineering oparty na Sigma pomaga opisać logikę niezależnie od produktu, ale pola Graph i Entra wymagają lokalnego mapowania.

Reakcja krok po kroku

Odizoluj podejrzany host od sieci, zachowując możliwość akwizycji pamięci.
Zabezpiecz DLL, plik konfiguracji, pamięć, logi procesu, DNS i proxy.
Wyeksportuj wydarzenia 2050 oraz logi audytowe skrzynki.
Zablokuj zidentyfikowaną aplikację i unieważnij client secret po zabezpieczeniu dowodów.
Unieważnij tokeny, sprawdź inne sekrety i usuń nieautoryzowane zgody.
Przeszukaj tenant pod kątem tej samej aplikacji, skrzynki, tematów i załączników.
Zbadaj inne hosty korzystające z domeny DNS lub podobnego wzorca.
Ustal, jakie pliki mogły zostać wysłane i czy wymagane jest zawiadomienie.
Odbuduj host z zaufanego obrazu, jeżeli nie można potwierdzić integralności.
Wdróż poprawione reguły i wykonaj tabletop dla podobnego SaaS C2.

Rotacja jednego hasła użytkownika może niczego nie zmienić, jeśli implant używa client secret. Z kolei usunięcie aplikacji bez analizy hosta pozostawia loader i potencjalnie inny kanał. Reagowanie na incydenty musi objąć zespół endpoint, tożsamość, M365, DNS, prawników i właściciela danych.

Jak zapobiegać podobnym kanałom

Używaj workload identity i certyfikatów zamiast długowiecznych client secrets, gdy to możliwe.
Ogranicz dostęp aplikacji do konkretnych skrzynek i funkcji Graph.
Wymagaj właściciela, daty wygaśnięcia i przeglądu każdej aplikacji.
Blokuj bezpośredni DNS z hostów; kieruj ruch do monitorowanego resolvera.
Utrzymuj pełny audit dla działań aplikacyjnych, nie tylko użytkowników.
Alertuj na dane w odległych wydarzeniach i nietypowe załączniki kalendarza.
Segmentuj hosty administracyjne oraz ogranicz ich egress.
Testuj, czy SOC potrafi połączyć alert SaaS, DNS i EDR.

Model Zero Trust jest tu bardziej użyteczny niż blokada jednej domeny: każde żądanie aplikacji ma tożsamość, zakres, urządzenie i kontekst, które powinny być stale weryfikowane.

FAQ

Czy HOLLOWGRAPH wykorzystuje podatność Microsoft 365?

Opublikowana analiza nie opisuje zero-day w Microsoft 365. Malware nadużywa legalnego Graph API i poświadczeń przejętej aplikacji lub konta. Problemem jest kompromitacja tożsamości oraz wykorzystanie prawidłowych funkcji do C2.

Czy blokada cloudlanecdn[.]com rozwiązuje problem?

Jest ważnym IOC, ale niewystarczającym. Główny kanał działa przez Microsoft Graph, a domenę odświeżania można zmienić. Trzeba unieważnić poświadczenia, usunąć implant i przeszukać tenant.

Czy wszystkie wydarzenia w 2050 roku są złośliwe?

Nie. Mogą istnieć legalne testy lub długoterminowe przypomnienia. Wysoki sygnał daje dopiero data połączona z tematem, załącznikami, aplikacyjnym Graph API i aktywnością hosta.

Najważniejszy wniosek

HOLLOWGRAPH omija klasyczne polowanie na złą domenę, ponieważ najważniejszy ruch odbywa się w zaufanej chmurze. Obrona musi widzieć zachowanie usługi, nie tylko cel TLS. Kalendarz, tożsamość aplikacyjna, DNS i endpoint składają się na jeden incydent, choć każdy zespół może widzieć tylko fragment.

Chcesz sprawdzić, czy Microsoft 365 może zostać użyty jako niewidoczny kanał C2? BreachRoad prowadzi testy red team i audyty tożsamości w kontrolowanym zakresie, bez używania danych produkcyjnych. Skontaktuj się z nami, aby zaplanować walidację detekcji.