HollowFrame i fałszywa python39.dll: nowy łańcuch infekcji oparty na DLL sideloading

Wprowadzenie do problemu / definicja

HollowFrame to nowo opisywany loader wykorzystywany w ukierunkowanych kampaniach phishingowych, które nadużywają mechanizmu ładowania bibliotek DLL w systemie Windows. Kluczowym elementem tego łańcucha infekcji jest podszycie się pod legalny komponent środowiska Python, najczęściej pod nazwą python39.dll, aby uruchomić złośliwy kod pod pozorem prawidłowej zależności aplikacyjnej.

Technika ta wpisuje się w schemat DLL sideloading, czyli wymuszenia załadowania spreparowanej biblioteki przez legalny plik wykonywalny. Dzięki temu atakujący korzysta z zaufania do znanych procesów i nazw plików, co utrudnia wykrycie incydentu zarówno użytkownikom, jak i systemom bezpieczeństwa.

W skrócie

Scenariusz ataku zwykle rozpoczyna się od dostarczenia ofierze archiwum lub pakietu zawierającego legalnie wyglądający plik EXE oraz złośliwą bibliotekę DLL nazwaną jak składnik środowiska Python. Po uruchomieniu pliku wykonywalnego system ładuje lokalną bibliotekę python39.dll, co aktywuje loader HollowFrame.

• ofierze dostarczany jest pakiet z legalnie wyglądającym EXE i złośliwą DLL,
• Windows ładuje bibliotekę z lokalnego katalogu zamiast prawidłowej ścieżki,
• loader uruchamia kolejne etapy infekcji,
• malware może wdrażać backdoory, kradzież danych i trwałość w systemie.

Kontekst / historia

DLL sideloading od lat pozostaje jedną z najskuteczniejszych technik omijania zabezpieczeń Windows. Jej skuteczność wynika z faktu, że wiele aplikacji ładuje zależności z bieżącego katalogu roboczego lub innych lokalizacji znajdujących się wysoko w kolejności przeszukiwania bibliotek. Jeśli napastnik dostarczy legalny plik wykonywalny wraz ze złośliwą biblioteką o oczekiwanej nazwie, aplikacja może uruchomić kod atakującego bez konieczności wykorzystywania exploita.

W ostatnich latach biblioteki związane z Pythonem były wielokrotnie używane jako element kamuflażu. Nazwy takie jak python39.dll nie budzą podejrzeń w środowiskach, gdzie obecne są narzędzia automatyzacji, skrypty administracyjne, aplikacje budowane w PyInstallerze lub rozwiązania osadzające interpreter Pythona. To sprawia, że taki plik może wyglądać wiarygodnie zarówno dla użytkownika końcowego, jak i dla mniej precyzyjnych reguł detekcyjnych.

Analiza techniczna

Analizowany łańcuch infekcji najczęściej rozpoczyna się od spear-phishingu albo dostarczenia archiwum zawierającego pozornie nieszkodliwe pliki. W pakiecie ofiara otrzymuje zwykle legalny lub skradziony plik wykonywalny, złośliwą bibliotekę DLL nazwaną jak zależność środowiska Python oraz dodatkowe pliki konfiguracyjne lub zaszyfrowane payloady.

Po uruchomieniu EXE system Windows stosuje standardowy mechanizm rozwiązywania zależności. Jeśli aplikacja odwołuje się do python39.dll, a spreparowany plik znajduje się w katalogu uruchomieniowym, może zostać załadowany przed legalną biblioteką z właściwej instalacji. To klasyczny przypadek side-loadingu.

Sama biblioteka pełni rolę loadera i odpowiada za uruchomienie następnych faz ataku. W praktyce może realizować kilka zadań:

• weryfikację środowiska i podstawowe kontrole antyanalityczne,
• odszyfrowanie lub rozpakowanie kolejnego etapu,
• uruchomienie payloadu bezpośrednio w pamięci,
• ustanowienie mechanizmów trwałości,
• komunikację z infrastrukturą dowodzenia i kontroli.

Nazwa HollowFrame sugeruje powiązanie z technikami hollowingu lub uruchamiania kolejnych etapów w procesach pośrednich. Nawet jeśli początkowym wektorem jest DLL sideloading, dalsze fazy mogą obejmować iniekcję do innych procesów, ukrywanie modułów w pamięci i ograniczanie artefaktów pozostawianych na dysku. Taki model działania zwiększa odporność malware na klasyczne skanowanie oparte na plikach.

Z perspektywy obrońców szczególnie istotne są następujące wskaźniki:

• ładowanie python39.dll przez aplikacje, które zwykle nie korzystają z osadzonego interpretera Pythona,
• obecność bibliotek Pythona poza standardowymi ścieżkami instalacyjnymi,
• uruchamianie legalnych EXE z katalogów tymczasowych, pobrań lub rozpakowanych archiwów,
• nietypowe zestawy plików, w których obok dokumentów znajdują się biblioteki runtime,
• połączenia sieciowe inicjowane krótko po załadowaniu biblioteki.

Konsekwencje / ryzyko

Ryzyko związane z HollowFrame jest wysokie, ponieważ technika nie wymaga wykorzystania luki w zabezpieczeniach, a jedynie błędnego zaufania do legalnego procesu i nazwy biblioteki. To obniża próg wejścia dla napastnika i zwiększa skuteczność kampanii ukierunkowanych.

Dla organizacji konsekwencje mogą być poważne i obejmować zarówno naruszenie pojedynczej stacji roboczej, jak i eskalację do incydentu domenowego.

• zdalne wykonanie kodu na urządzeniu ofiary,
• instalację backdoora i trwały dostęp do środowiska,
• kradzież danych uwierzytelniających i dokumentów,
• ruch lateralny wewnątrz organizacji,
• pełne naruszenie bezpieczeństwa po dalszej eskalacji.

Szczególnie narażone są organizacje, które często wymieniają pliki archiwalne, korzystają z narzędzi deweloperskich lub dopuszczają uruchamianie aplikacji spoza zarządzanych repozytoriów. Problem pogłębia możliwość błędnej klasyfikacji pliku jako legalnej biblioteki Python, zwłaszcza gdy analiza opiera się wyłącznie na nazwie lub podstawowych metadanych.

Rekomendacje

Aby ograniczyć ryzyko ataków wykorzystujących fałszywe biblioteki python39.dll i podobne warianty, zespoły bezpieczeństwa powinny połączyć monitoring behawioralny, kontrolę aplikacji i edukację użytkowników.

• Monitorować zdarzenia ładowania DLL, szczególnie nazw związanych z Pythonem z lokalizacji niestandardowych.
• Wdrożyć reguły EDR i SIEM wykrywające przypadki DLL sideloading.
• Ograniczyć uruchamianie niezatwierdzonych plików wykonywalnych z użyciem AppLocker, WDAC lub podobnych mechanizmów.
• Analizować nietypowe zestawy plików zawierające pojedynczy EXE i biblioteki runtime w tym samym katalogu.
• Weryfikować podpisy cyfrowe oraz reputację całego łańcucha dostarczonych artefaktów.
• Izolować próbki, w których python39.dll uruchamiana jest przez nietypowe procesy biznesowe lub narzędzia systemowe.
• Szkolić użytkowników w zakresie zagrożeń wynikających z otwierania archiwów z wiadomości e-mail, komunikatorów i kanałów B2B.
• Korelować telemetrię procesów, modułów i ruchu sieciowego, aby wychwytywać krótki łańcuch zdarzeń prowadzący do infekcji.

W działaniach reagowania incydentowego warto zabezpieczać próbki, listy załadowanych modułów, drzewo procesów, wpisy autostartu oraz artefakty pamięci. W wielu przypadkach to właśnie analiza pamięci ujawnia rzeczywisty payload, który nie występuje jawnie na dysku.

Podsumowanie

HollowFrame pokazuje, że dobrze znane techniki, takie jak DLL sideloading, nadal pozostają wyjątkowo skuteczne, jeśli zostaną połączone z wiarygodnym kamuflażem. Podszycie się pod python39.dll pozwala napastnikom wykorzystać zaufanie do legalnych komponentów i ukryć złośliwy kod w pozornie zwyczajnym zestawie plików.

Dla obrońców kluczowe znaczenie ma nie tylko wykrywanie samego malware, ale również analiza kontekstu ładowania bibliotek, ścieżek plików i zależności uruchamianych procesów. To właśnie warstwa behawioralna daje największą szansę na wczesne wykrycie podobnych kampanii.

Źródła

1. Infosecurity Magazine – HollowFrame fake Python DLL story: https://www.infosecurity-magazine.com/news/hollowframe-fake-python-dll/
2. HijackLibs – python39.dll: https://hijacklibs.net/entries/3rd_party/python/python39.html
3. SANS Internet Storm Center – Python Bot Delivered Through DLL Side-Loading: https://isc.sans.edu/diary/31778
4. ManageEngine Log360 – Potential Python DLL SideLoading: https://www.manageengine.com/log-management/detection-rules/potential-python-dll-sideloading.html
5. ThreatInfo – python39.dll Malware Detection Report: https://threatinfo.net/files/python39.dll-c905bc81ca2e732abb2f152f2bce1471