Wprowadzenie do problemu / definicja luki
Infy (znany też jako „Prince of Persia”) to przypisywany Iranowi aktor APT, kojarzony z długotrwałymi kampaniami szpiegowskimi, w których wykorzystywał własne rodziny malware oraz infrastrukturę C2 (command-and-control). Po okresie względnej ciszy badacze ponownie obserwują aktywność grupy – tym razem z odświeżonym toolsetem i technikami utrudniającymi wykrywanie oraz „zrywanie” łączności z serwerami sterującymi.
W praktyce nie jest to pojedyncza „luka” w rozumieniu CVE, tylko powrót kampanii malware: infekcje inicjowane socjotechniką (phishing) i plikami biurowymi, a następnie etapowe wdrażanie komponentów Foudre/Tonnerre do rozpoznania ofiary i eksfiltracji danych.
W skrócie
- Infy/„Prince of Persia” wraca po latach z nowszymi wersjami Foudre i Tonnerre; najnowsze warianty Tonnerre były obserwowane we wrześniu 2025 r.
- Zmienia się wektor wejścia: obok klasycznych dokumentów z makrami pojawiają się pliki Excel z osadzonym wykonywalnym payloadem (co potrafi ominąć część polityk „macro hygiene”).
- Istotnym elementem odporności jest DGA (Domain Generation Algorithm) oraz dodatkowa walidacja „prawdziwości” domeny C2 z użyciem podpisu RSA.
- SafeBreach opisuje też scenariusz, w którym część C2/operacji jest przekierowywana do Telegrama (bot/grupa) jako kanału kontroli/transferu.
Kontekst / historia / powiązania
Infy to nazwa używana w branży do opisu aktora i kampanii obserwowanych co najmniej od wczesnych lat 2010., wiązanych m.in. z celowaniem w aktywistów i organizacje wrażliwe politycznie. Malpedia opisuje Infy jako grupę podejrzewaną o irańskie pochodzenie, obserwowaną w kontekście ukierunkowanych działań i własnych rodzin złośliwego oprogramowania.
Starsze analizy Unit 42 (Palo Alto Networks) dokumentowały „Prince of Persia/Infy” jako kampanię opartą o spear-phishing z dokumentami Office i etapowe dostarczanie malware. To ważne tło, bo pokazuje, że dzisiejszy „powrót” to raczej ciągłość rozwoju i ewolucja TTP, a nie całkowicie nowy byt.
Analiza techniczna / szczegóły luki
1) Łańcuch infekcji: Office jako nośnik, ale z twistem
Według SafeBreach i relacji The Hacker News, aktor odchodzi (przynajmniej częściowo) od klasyki w postaci makr w Excelu na rzecz dokumentów Excel z osadzonym plikiem wykonywalnym, który instaluje Foudre. Równolegle wciąż mogą występować warianty oparte o makra.
Z perspektywy MITRE ATT&CK taki model często „opiera się” o zachowanie użytkownika (otwarcie pliku, włączenie zawartości/uruchomienie elementu), czyli wzorce z obszaru User Execution: Malicious File.
2) Role malware: Foudre jako etap 1, Tonnerre jako etap 2
SafeBreach opisuje Foudre jako pierwszy etap (profilowanie/rozpoznanie i selekcja), a Tonnerre jako komponent uruchamiany, gdy ofiara jest „warta” dalszej inwestycji (np. eksfiltracja, rozszerzone komendy). W kampanii wykryto m.in. Foudre v34 oraz Tonnerre w wersjach 12–18 i 50.
3) Odporność C2: DGA + walidacja podpisem
Najbardziej charakterystyczny element obecnej odsłony to:
- DGA – generowanie domen C2 w czasie, co utrudnia blokowanie listą statycznych domen,
- walidacja C2 – pobranie pliku podpisu RSA i porównanie z lokalnym „wzorcem”, aby upewnić się, że malware łączy się z właściwą infrastrukturą (a nie np. sinkhole/pułapką analityków).
4) Telegram jako element ekosystemu sterowania
Nowością opisywaną przez SafeBreach jest sytuacja, w której infrastruktura C2 kieruje komunikację do zasobów Telegrama (bot/grupa) jako alternatywnego kanału – co może poprawiać „przeżywalność” kampanii i utrudniać klasyczne blokady po IP/domenie.
Uwaga praktyczna: nawet jeśli badacze publikują szczegóły, w środowisku obronnym lepiej traktować je jako punkt startowy do detekcji (telemetria endpoint + proxy/DNS), a nie „jedyne IOC”, bo aktor może szybko rotować elementy infrastruktury.
5) Zasięg geograficzny i profil celów
W podsumowaniach wskazuje się ofiary w wielu krajach (m.in. Iran, Irak, Turcja, Indie, Kanada oraz część Europy). To sugeruje, że kampania ma charakter szerszy niż lokalny i może obejmować diasporę, podmioty powiązane tematycznie lub łańcuchy relacji biznesowych.
Praktyczne konsekwencje / ryzyko
- Ryzyko wycieku danych: Tonnerre jest opisywany jako etap, w którym pojawia się realna eksfiltracja/operacje na plikach, a infrastruktura ma katalogowanie i logowanie komunikacji.
- Trudniejsze blokowanie C2: DGA + walidacja „autentyczności” C2 zmniejszają skuteczność prostych blokad domen/IP i mogą ograniczać skuteczność sinkholingu.
- Wyzwania dla polityk Office: organizacje skupione wyłącznie na blokadzie makr mogą mieć lukę kontrolną, jeśli wektor przechodzi na osadzone executables / nietypowe SFX/loader-y.
Rekomendacje operacyjne / co zrobić teraz
- Wzmocnij kontrolę uruchomień z Office
- Blokuj/ograniczaj tworzenie procesów potomnych przez aplikacje Office (np. reguły ASR w Microsoft Defender, polityki EDR).
- Monitoruj nietypowe zachowania: Excel → tworzenie plików wykonywalnych, uruchamianie SFX/loaderów, wykonywanie DLL z katalogów tymczasowych. (Zgodne z ryzykiem User Execution: Malicious File).
- DNS i egress: przygotuj się na DGA
- Wykrywaj anomalie DNS (dużo nieudanych zapytań, domeny o nietypowej entropii/alfabecie, krótkie „losowe” hosty).
- Stosuj egress filtering i proxy z inspekcją; DGA bez wyjścia na Internet traci sens.
- Detekcje na endpoint
- Poluj na wzorce: dokumenty Office jako initial access, a potem binaria w nietypowych lokalizacjach + ruch HTTP(S) do świeżo generowanych domen.
- Procedury IR i threat hunting
- Jeśli podejrzewasz infekcję: izolacja hosta, pełna triage (autoruny, harmonogram zadań, persistence), korelacja DNS/Proxy/EDR.
- Ustal, czy w organizacji występowały kontakty z infrastrukturą opisywaną przez badaczy i czy doszło do nietypowych transferów danych.
Różnice / porównania z innymi przypadkami
- Klasyczne APT vs „odporne C2”: DGA to technika znana od lat, ale połączenie jej z walidacją C2 (podpis RSA) i potencjalnym „fallbackiem” do popularnej platformy komunikacyjnej (Telegram) tworzy bardziej elastyczny, trudniejszy do przejęcia łańcuch sterowania.
- Makra to nie jedyny problem: przesunięcie w stronę osadzonych wykonywalnych elementów w dokumentach pokazuje, że polityki „disable macros” są konieczne, ale niewystarczające, jeśli nie ma twardej kontroli uruchomień i zachowań procesów.
Podsumowanie / kluczowe wnioski
Powrót Infy/„Prince of Persia” to sygnał ostrzegawczy: grupa rozwija toolset (Foudre/Tonnerre), zmienia elementy dostarczania (Excel z osadzonym payloadem), a przede wszystkim zwiększa odporność infrastruktury (DGA + walidacja RSA, a według SafeBreach także elementy oparte o Telegram). Dla obrony kluczowe jest odejście od myślenia „zablokuj domenę i po sprawie” na rzecz podejścia warstwowego: kontrola uruchomień z Office, analiza anomalii DNS, telemetria EDR oraz dobrze przećwiczone IR.
Źródła / bibliografia
- The Hacker News – opis ponownej aktywności Infy, zmiany w łańcuchu ataku i elementy DGA/walidacji C2. (The Hacker News)
- SafeBreach – raport techniczny o Foudre/Tonnerre, wariantach, C2 i obserwacjach dotyczących Telegrama. (SafeBreach)
- Unit 42 (Palo Alto Networks) – historyczny kontekst kampanii „Prince of Persia/Infy” i model działania. (Unit 42)
- Malpedia – profil aktora Infy (kontekst, nazewnictwo, ogólny opis). (Malpedia)
- MITRE ATT&CK – User Execution: Malicious File jako punkt odniesienia dla wektora „użytkownik otwiera złośliwy plik”. (attack.mitre.org)