Botnet Prometei - pięć lat w firmowej sieci i trzy nieudane próby usunięcia

Historia pochodzi z postępowania, które prowadziłem w sierpniu 2026 roku w średniej wielkości organizacji będącej pod moją opieką - na jej prośbę wszystkie szczegóły identyfikujące zostały usunięte, a nazwy stacji zmienione. Cała reszta, łącznie z datami i liczbami, pochodzi wprost z materiału dowodowego. Opisuję tu przebieg zdarzeń i wnioski, które możesz zastosować u siebie - szczegółowa metodyka analizy pozostaje poza zakresem tego tekstu.

Czym jest Prometei i dlaczego nie zauważysz, że go masz

Prometei to wielomodułowy botnet opisany po raz pierwszy przez zespół Cisco Talos w 2020 roku, choć jego ślady sięgają 2016. Główny cel jest prozaiczny: wydobywanie kryptowaluty Monero na cudzym prądzie i cudzym procesorze. Po drodze robi jednak rzeczy znacznie groźniejsze - kradnie poświadczenia zmodyfikowanym Mimikatzem, rozprzestrzenia się po sieci protokołem SMB z użyciem skradzionych haseł, exploitów pokroju EternalBlue oraz narzędzi PsExec i WMI, a łączność z serwerami sterującymi prowadzi między innymi przez sieć Tor.

To połączenie sprawia, że Prometei jest cichy z natury. Koparka kryptowalut nie szyfruje plików i nie wyświetla żądań okupu - jedynym objawem dla użytkownika jest komputer, który „jakoś wolniej chodzi". W badanej sieci nikt przez lata nie powiązał tego objawu z infekcją. Talos szacuje, że sama trzecia wersja botnetu zainfekowała od końca 2022 roku ponad dziesięć tysięcy systemów na świecie - i zdecydowana większość ich właścicieli prawdopodobnie o tym nie wie.

Grudzień 2020 - ciche wejście i pięć lat uśpienia

Najstarszy wiarygodny artefakt w sprawie to pierwszy wpis dziennika klienta Tor na stacji, którą nazwaliśmy pacjentem zero: 2 grudnia 2020 roku, godzina 15:52. Tego samego dnia zainfekowane zostały jeszcze dwie maszyny. Wektor wejścia z tamtego okresu pozostał nieustalony - dzienniki zdarzeń sprzed sześciu lat po prostu nie istnieją i to pierwsza lekcja z tej historii: retencja logów decyduje o tym, ile kiedykolwiek się dowiesz.

Ciekawostka metodyczna: znaczniki czasu samych plików malware'u były o osiem dni wcześniejsze niż katalog kluczy Tora. Nie oznacza to wcześniejszej infekcji - daty plików przyjechały razem z pakietem atakującego. Wiarygodny jest katalog kluczy, bo powstaje dopiero w czasie działania procesu. Przy analizie powłamaniowej trzeba wiedzieć, którym znacznikom wolno ufać.

Botnet przetrwał następnie aktualizację funkcji Windows 10 z wersji 1903 do 22H2 w listopadzie 2023 roku. W rejestrze widać uruchomienie głównego pliku botnetu dzień po aktualizacji. Proces aktualizacji przenosi konfigurację usług razem z całą resztą systemu - złośliwe usługi przejechały na nowy build jak pasażer na gapę.

Dlaczego działający antywirus niczego nie widział

Na większości stacji Windows Defender był włączony i działał. Mimo to przez pięć lat nie podniósł alarmu - i mechanizm tego oślepienia udało się odtworzyć na podstawie kodu znalezionego na jednej z maszyn, nie na podstawie domysłu. Malware dopisywał do konfiguracji Defendera wykluczenia katalogów, w których sam się znajdował. Antywirus był sprawny; po prostu miał zakaz zaglądania tam, gdzie mieszkał intruz.

Co gorsza, wbudowana w Windows ochrona przed manipulacją nie chroni listy wykluczeń, dopóki nie jest ona zarządzana centralnie. A lokalna polityka ukrywająca wykluczenia przed administratorem sprawiała, że wykluczenia dopisane przez malware obowiązywały i jednocześnie były niewidoczne w interfejsie. Administrator, który zajrzałby na maszynę, zobaczyłby czystą listę.

Trzecia warstwa kamuflażu: jedna z usług zapewniających przetrwanie botnetu ma nazwę losowaną osobno na każdej maszynie. Narzędzia sprawdzające listę znanych nazw usług przegapiły ją na wszystkich badanych stacjach. Do tego dochodziła nieaktualna lista wskaźników zagrożenia - firmowy monitoring obserwował trzy adresy serwerów sterujących, które napastnik wycofał lata wcześniej. Prawdziwych dziewięć adresów poznaliśmy dopiero z pliku konfiguracyjnego odzyskanego z dysku. Wniosek: lista IOC bez daty ważności to lista życzeń.

Trzy próby usunięcia, które nie mogły się udać

Najbardziej pouczające w całej sprawie jest to, że infekcję w firmie widziano wcześniej co najmniej trzykrotnie - i trzy razy „usunięto" ją w sposób, który gwarantował nawrót.

Próba pierwsza, grudzień 2023: na jednej ze stacji uruchomiono popularne narzędzie czyszczące i katalog malware'u opustoszał tego samego dnia. Zostało jednak siedem reguł zapory otwierających dostęp z zewnątrz oraz wykluczenia Defendera - działały nieprzerwanie do sierpnia 2026 roku.

Próba druga, marzec 2025: ktoś skasował do kosza całą zawartość katalogu malware'u - 65 pozycji - a godzinę później pobrał z GitHuba niezweryfikowane archiwum z obcym plikiem wykonywalnym reklamowanym jako „remover" i uruchomił je na maszynie firmowej. Rejestru nie ruszył. Wpisy usług zostały osierocone i przez siedemnaście miesięcy wskazywały na nieistniejące pliki, czekając, aż mechanizm samoaktualizacji botnetu dostarczy je ponownie.

Próba trzecia, data nieustalona: usunięto pojedynczy plik wykonywalny botnetu, ale usługa wskazująca na ten plik została w rejestrze. Schemat za każdym razem ten sam - usuwano pliki, zostawiano mechanizmy uruchamiania. I za każdym razem nikt niczego nie zgłosił, więc trzy niezależne obserwacje tego samego zagrożenia nigdy nie złożyły się w jeden obraz. To nie jest problem narzędzi, tylko obiegu informacji o incydentach.

Sierpień 2026 - przebudzenie: tysiąc komunikatów na godzinę

20 sierpnia 2026 roku ruszyła nowa fala. System monitorowania zaczął generować około tysiąca komunikatów bezpieczeństwa na godzinę - po pięciu latach ciszy infekcja stała się nagle bardzo głośna. Nieprzypadkowo: miesiąc wcześniej w sieci wdrożono agenta SIEM, a w dniu wykrycia - nowe polityki ochrony. Kampania działała pięć lat i osiem miesięcy niezauważona i stała się widoczna dokładnie w miesiącu, w którym organizacja wzmocniła zabezpieczenia. Botnet nie zmienił zachowania; zmieniło się to, że ktoś wreszcie patrzył.

Skalę tempa ataku najlepiej pokazuje jedna ze stacji: pracownik przyszedł rano, włączył komputer i w niecałe cztery minuty na w pełni aktualnym Windows 11 z działającym antywirusem znalazł się komplet komponentów kampanii, z trzema mechanizmami przetrwania i regułami zapory. To nie relikt z 2020 roku - to sprawna, aktywna droga wejścia, w której skradzione lata wcześniej poświadczenia wciąż otwierały drzwi.

Co faktycznie zadziałało - odcięcie, wyłączenie, czyszczenie z głową

Pierwsza decyzja: odcięcie zainfekowanego segmentu od internetu. Środek gruby, ale w tamtym momencie jedyny dostępny - blokada adresów przestępców wymagałaby ich znajomości, a aktualne adresy poznaliśmy dopiero dwa dni później z dysków. Że odcięcie działało, widać w artefaktach: jedna ze stacji wykonała przez dwa dni 10 996 nieudanych prób połączenia z serwerem sterującym, a kanał Tor na innej ani razu nie osiągnął celu.

Druga decyzja: wyłączenie wszystkich stacji segmentu. Uzasadniona - skoro maszyna zaraża się w cztery minuty, każda włączona stacja to potencjalne źródło reinfekcji. W praktyce jednak część maszyn pracowała jeszcze wiele dni po wydaniu polecenia, bo pracownicy je włączali. Lekcja organizacyjna: samo polecenie nie wystarczy, potrzebny jest komunikat do użytkowników i kontrola wykonania.

Samo czyszczenie prowadzono na wymontowanych dyskach, na odizolowanym stanowisku: najpierw pełne zabezpieczenie materiału dowodowego z sumami kontrolnymi SHA256, potem usunięcie wszystkich warstw infekcji - plików, wpisów usług w rejestrze, reguł zapory i wykluczeń antywirusa - a na końcu niezależna kontrola, czyli pełna enumeracja rejestru innym narzędziem, nie ponowne uruchomienie tego samego skryptu. Dopiero taki zakres różni usunięcie infekcji od jej przycięcia. Uczciwie trzeba przy tym dodać: „wyczyszczona" znaczy „usunięto znane elementy", a nie „udowodniono brak infekcji" - dlatego stacje po powrocie trafiały najpierw do wydzielonego VLAN-u pod obserwację.

Maszyna z nogą w dwóch sieciach - czemu segmentacja nie pomogła

Falę z sierpnia 2026 roku rozpoczęła stacja, która była podłączona jednocześnie do dwóch sieci - segmentu produkcyjnego i segmentu biurowego - przez drugą kartę sieciową ze skonfigurowanym na stałe adresem. To ustalenie o znaczeniu systemowym: żadna segmentacja nie działa, jeśli pojedyncza maszyna ma nogę po obu stronach. Reguły na zaporze między VLAN-ami można cyzelować tygodniami, a jeden zapomniany komputer z dwiema kartami unieważnia całą tę pracę.

Audyt takich maszyn jest prosty i tani: wystarczy cyklicznie porównywać tablice ARP i listy interfejsów z inwentaryzacją. W tej sprawie odkrycie zajęło sześć lat, bo nikt takiego porównania nie robił.

Czego nauczyło mnie to postępowanie

Zdolność wykrywania rosła z każdą kolejną badaną maszyną. Zaczynaliśmy z sygnaturą rozpoznającą dwanaście wzorców; skończyliśmy z trzydziestoma pięcioma, a ostatni nowy wariant doszedł na dwunastej z trzynastu zbadanych stacji. Botnet ma mechanizm samoaktualizacji, więc każda maszyna mogła dostać inną wersję - i dostawała. Praktyczny wniosek: stacje obsłużone najwcześniej warto po zakończeniu postępowania sprawdzić ponownie, pełną listą wzorców, na zabezpieczonym materiale. To praca na stanowisku analitycznym, bez angażowania użytkowników.

Druga rzecz: dokumentacja trzech równoległych ścieżek reakcji. Praca z dyskami dokumentuje się sama - każdy krok zostawia ślad w protokole. Ale zmiany wdrażane centralnie przez zasady grupy i konfiguracja urządzeń brzegowych nie zostawiają śladu w kopii dysku. Jeśli nie zapiszesz daty, godziny i zakresu odcięcia sieci w momencie jego wykonania, po dwóch tygodniach będziesz miał zmierzony skutek i zero zapisu czynności. Audytor zapyta o to pierwsze.

I trzecia, najważniejsza: ten incydent wykryto nie dlatego, że botnet popełnił błąd, tylko dlatego, że organizacja zaczęła patrzeć. Monitoring wdrożony miesiąc przed wykryciem zrobił więcej niż wszystkie zabezpieczenia z poprzednich pięciu lat razem wzięte.

Częste błędy i pułapki

Kasowanie plików malware'u bez czyszczenia rejestru. To błąd, który w tej sprawie popełniono trzykrotnie. Usunięcie plików nie usuwa usług, zadań harmonogramu, reguł zapory ani wykluczeń antywirusa. Botnet z mechanizmem samoaktualizacji odtworzy pliki, gdy tylko mechanizm uruchamiania znów będzie miał co uruchomić. Usuwaj infekcję warstwami: pliki, rejestr, zapora, wykluczenia - i kontroluj wynik niezależnym narzędziem.

Uruchamianie „removerów" z internetu na maszynach firmowych. Pobranie z GitHuba niepodpisanego pliku wykonywalnego nieznanego autora i uruchomienie go na zainfekowanej stacji to wpuszczenie drugiego nieznajomego, żeby wyprowadził pierwszego. Nie wiesz, co ten plik robi, a przy okazji niszczysz materiał dowodowy. Jeśli nie masz zaufanego narzędzia - odłącz maszynę i eskaluj.

Ciche „naprawianie" bez zgłoszenia. Trzy niezależne obserwacje tej samej infekcji na przestrzeni trzech lat nigdy nie trafiły do jednego rejestru, więc nikt nie zobaczył wzorca. Pojedyncze zgłoszenie z 2023 roku skróciłoby życie tej kampanii o trzy lata. Kultura zgłaszania incydentów jest tańsza niż każde narzędzie bezpieczeństwa.

Poleganie na liście IOC sprzed lat. Napastnicy wymieniają infrastrukturę. Lista adresów serwerów sterujących z raportu sprzed kilku lat daje złudzenie monitoringu - obserwujesz adresy, których nikt już nie używa. Wskaźniki zagrożenia traktuj jak mleko, nie jak wino: sprawdzaj datę przydatności.

Wykluczenia antywirusa niezarządzane centralnie. Jeśli lokalny administrator - a więc i malware działający z jego uprawnieniami - może dopisywać wykluczenia, antywirus jest tak skuteczny, jak chce tego intruz. Wymuś scalanie list wyłącznie z polityki centralnej i cyklicznie audytuj, co faktycznie widnieje na stacjach.

Wdrażanie polityk blokujących bez okresu audytu. W trakcie tej samej reakcji komplet reguł ograniczania powierzchni ataku wdrożono na flotę od razu w trybie blokowania - i środowisko z systemem księgowym zintegrowanym z pakietem Office stanęło. Zgłoszenia „nic nie działa" w środku incydentu bezpieczeństwa to ostatnia rzecz, jakiej potrzebujesz. Reguły ASR najpierw w trybie audytu, potem etapami w blokowanie.

Polecenie „wyłączcie komputery" bez kontroli wykonania. Część stacji pracowała wiele dni po wydaniu polecenia, bo użytkownicy włączali je z przyzwyczajenia. Środek zaradczy istnieje tylko wtedy, gdy zweryfikujesz jego wykonanie - komunikat do ludzi, potem kontrola techniczna, które maszyny odpowiadają w sieci.

Ufanie znacznikom czasu plików malware'u. Daty utworzenia plików przyjeżdżają razem z pakietem atakującego i potrafią wskazywać moment sprzed faktycznej infekcji. Chronologię buduj na artefaktach powstających w czasie działania: dziennikach usług, katalogach kluczy, rejestrze wykonań.

FAQ - najczęściej zadawane pytania

Czym jest botnet Prometei?

Prometei to wielomodułowy botnet aktywny co najmniej od 2016 roku, opisany publicznie przez Cisco Talos w 2020. Jego głównym celem jest wydobywanie kryptowaluty Monero na zainfekowanych maszynach, ale po drodze kradnie poświadczenia i rozprzestrzenia się po sieci protokołami SMB i RDP. Występuje w wersjach dla Windows i Linuksa.

Jak rozpoznać, że komputer jest częścią botnetu?

Najczęstsze objawy to niewyjaśnione obciążenie procesora, wolniejsza praca maszyny i ruch sieciowy do nieznanych adresów, często przez Tor. Pewne rozpoznanie wymaga jednak analizy: przeglądu usług i zadań harmonogramu, reguł zapory, wykluczeń antywirusa oraz dzienników połączeń. Sam skan antywirusowy może nie wystarczyć, jeśli malware dopisał własne wykluczenia.

Dlaczego antywirus nie wykrywa botnetu Prometei?

Prometei dopisuje katalogi, w których się znajduje, do listy wykluczeń Windows Defendera - antywirus działa, ale ma zakaz zaglądania we właściwe miejsca. Ochrona przed manipulacją nie obejmuje listy wykluczeń, dopóki nie jest ona zarządzana centralnie. Dodatkowo nazwy części usług botnetu są losowane osobno na każdej maszynie.

Czy format lub reinstalacja systemu usuwa botnet?

Czysta reinstalacja z wymazaniem dysku usuwa infekcję z tej konkretnej maszyny - ale nie z sieci. Jeśli inne stacje są zakażone, a skradzione poświadczenia nadal działają, maszyna po powrocie do sieci może zostać zainfekowana ponownie w kilka minut. Usuwanie botnetu to operacja na całym segmencie, nie na pojedynczym komputerze, i musi objąć zmianę haseł.

Czy aktualizacja Windows usuwa złośliwe oprogramowanie?

Nie. W opisanej sprawie botnet przetrwał aktualizację funkcji Windows 10 z wersji 1903 do 22H2 - proces aktualizacji przeniósł złośliwe usługi razem z całą konfiguracją systemu. Aktualizacje łatają podatności i utrudniają nowe infekcje, ale nie czyszczą już istniejących.

Jak długo botnet może pozostać niewykryty w firmie?

W opisanym przypadku pięć lat i osiem miesięcy - od grudnia 2020 do sierpnia 2026 roku. Kluczowe czynniki to brak monitoringu (SIEM wdrożono dopiero miesiąc przed wykryciem), oślepiony antywirus i nieaktualna lista obserwowanych adresów. Botnet wydobywający kryptowaluty nie ma interesu w tym, żeby być głośnym.

Co zrobić w pierwszej kolejności po wykryciu botnetu w sieci?

Odciąć zainfekowany segment od internetu - to zatrzymuje wyciek danych i łączność z serwerami sterującymi nawet wtedy, gdy nie znasz jeszcze ich adresów. Następnie zabezpieczyć materiał dowodowy przed jakimkolwiek czyszczeniem, zaplanować wymianę haseł kont, które były używane na zakażonych maszynach, i dopiero wtedy usuwać infekcję warstwami. Jeśli organizacja podlega ustawie o KSC lub NIS2, równolegle biegną terminy zgłoszenia incydentu.

Czy warto zgłaszać incydent, skoro „już posprzątaliśmy"?

Tak - i ta sprawa jest tego najlepszym dowodem. Trzy ciche, niezgłoszone próby czyszczenia sprawiły, że nikt nie złożył obserwacji w całość i infekcja żyła latami. Zgłoszenie tworzy zapis, który pozwala zobaczyć wzorzec, a w podmiotach objętych regulacjami jest po prostu obowiązkiem prawnym.

Co dalej - sprawdź, czy ta historia nie dzieje się u Ciebie

Ten incydent został wykryty nie dlatego, że ktoś miał szczęście - został wykryty, bo miesiąc wcześniej w sieci pojawił się monitoring. Dokładnie tym zajmuję się zawodowo: wdrażam systemy monitorowania sieci, dzielę płaskie sieci na segmenty, porządkuję i standaryzuję środowiska Windows oraz utwardzam je tak, żeby opisane w tym artykule mechanizmy ukrywania po prostu nie miały gdzie zadziałać. Jeśli po lekturze naszła Cię myśl „u nas też komputery jakoś wolniej chodzą" albo nie potrafisz dziś odpowiedzieć, co właściwie widzi Twój antywirus - potraktuj to poważnie i napisz do mnie. Rozmowa i wstępna ocena sytuacji nic nie kosztują, a ta historia pokazuje, ile kosztuje pięć lat niewiedzy.

Piszę też regularnie o bezpieczeństwie i praktycznej administracji sieciami na kanale Praktycznie o informatyce - jeśli takie materiały są dla Ciebie przydatne, zasubskrybuj kanał, a kolejnych historii z pierwszej linii nie przegapisz.