Wprowadzenie do problemu / definicja luki
W końcówce grudnia 2025 r. WebRAT (backdoor z funkcjami infostealera i spyware) zaczął być dystrybuowany przez GitHub w formie repozytoriów podszywających się pod proof-of-concept (PoC) exploitów na świeżo nagłaśniane podatności. Mechanizm jest prosty: ofiara szuka „działającego exploita”, trafia na repo z atrakcyjnym README i sekcją „Download”, a w praktyce pobiera hasłowany ZIP z ładunkiem malware.
To nie jest „luka” w GitHub jako platformie, tylko klasyczny atak socjotechniczny wykorzystujący zaufanie do publicznych repozytoriów, presję czasu („CVE jest gorące”) i chęć szybkiego uruchomienia PoC bez weryfikacji.
W skrócie
- WebRAT był wcześniej znany głównie z dystrybucji jako cheaty do gier i pirackie/crackowane oprogramowanie, ale od co najmniej września 2025 r. (wg analiz) operatorzy zaczęli masowo „opakowywać” go w fałszywe PoC na GitHub.
- Kaspersky opisał repozytoria z ustandaryzowanymi, bardzo „raportowymi” opisami podatności (podejrzenie treści generowanych przez AI) oraz wspólnym schematem pobrania hasłowanego archiwum.
- W paczce „exploita” pojawia się m.in. plik BAT uruchamiający droppera (np.
rasmanesc.exe), wabik-DLL oraz plik, którego nazwa zawiera hasło do ZIP. Dropper eskaluje uprawnienia, próbuje wyłączyć Defendera i pobiera właściwego WebRAT z twardo zaszytego URL.
Kontekst / historia / powiązania
WebRAT: od „gamingowego” stealer/spyware do polowania na juniorów
Solar 4RAYS opisywał WebRAT już w maju 2025 r. jako złośliwe oprogramowanie kradnące dane z przeglądarek, portfeli kryptowalutowych oraz kont m.in. Steam/Discord/Telegram, a także zdolne do podglądu ekranu i obserwacji przez webcam. Wątek dystrybucji obejmował m.in. cheaty, pirackie strony i nawet linki w komentarzach (np. pod filmami instruktażowymi).
Kaspersky zauważa, że w nowej odsłonie przynęta jest wyraźnie przesunięta w stronę studentów i mniej doświadczonych osób w infosec, które szukają PoC do nauki/testów i uruchamiają je na „normalnej” stacji roboczej zamiast w izolacji.
Dlaczego GitHub działa jako przynęta?
To wpisuje się w szerszy trend: atakujący budują wiarygodność fałszywych repozytoriów (dopieszczone README, tagi, commit-spam, instrukcje w wielu językach), a potem podstawiają komponent kradnący dane lub backdoora. Kaspersky opisał podobny wzorzec w kampanii GitVenom (setki repozytoriów z „projektami-wydmuszkami” i złośliwymi komponentami).
Analiza techniczna / szczegóły „PoC” (łańcuch infekcji)
Przynęta: CVE o wysokim „hype” i wysokich ocenach
W kampanii WebRAT repozytoria podszywały się m.in. pod exploity dla podatności nagłaśnianych w mediach, w tym (przykłady z opisów kampanii):
- CVE-2025-59295 (Windows MSHTML/Internet Explorer – przepełnienie sterty),
- CVE-2025-10294 (OwnID Passwordless Login dla WordPress – obejście uwierzytelnienia),
- CVE-2025-59230 (Windows RasMan – EoP).
Repozytorium wygląda „profesjonalnie” (czasem aż za bardzo)
Kaspersky zwraca uwagę na powtarzalny, „raportowy” układ opisów: przegląd podatności, warunki podatności, instrukcje pobrania i użycia, a nawet zalecenia mitygacji – z drobnymi różnicami w słownictwie, co pasuje do treści generowanych maszynowo.
Payload: hasłowany ZIP + prosta egzekucja
W opisywanym wariancie archiwum zawierało cztery elementy (nazwy mogą się różnić, ale schemat się powtarza):
- plik-wydmuszkę, którego nazwa zawiera hasło do archiwum (np.
pass – 8511), - „zepsuty” wabik
payload.dll(korupcja PE, bez funkcji), - właściwy dropper (np.
rasmanesc.exe) oraz start_exp.bat, który sprowadza się do uruchomienia droppera (zwiększa szansę, że użytkownik kliknie „to co trzeba”).
Zachowanie droppera (wysoki sygnał dla EDR)
Według Kaspersky’ego rasmanesc.exe m.in.:
- podnosi uprawnienia (mapowalne do TTP typu privilege escalation),
- podejmuje próby osłabienia ochrony (np. wyłączenie/obejście Windows Defender),
- pobiera właściwego WebRAT z twardo zaszytego adresu i uruchamia go.
BleepingComputer doprecyzowuje, że WebRAT ma też kilka metod persystencji (m.in. modyfikacje rejestru, harmonogram zadań, „rozsiew” w katalogach systemowych).
IOCs (minimum do polowania)
W Securelist opublikowano m.in. przykładowe IOCs dla tej kampanii: listę złośliwych repozytoriów, domeny C2 oraz hashe (MD5) próbek, w tym MD5 dla rasmanesc.exe wskazywany w analizie.
Uwaga operacyjna: traktuj IOCs jako punkt startu (campaign-specific), a nie „pełną listę” — lepiej budować detekcje po zachowaniu (Defender tampering, BAT→EXE→download→execute, nietypowy ruch HTTP do nowych domen).
Praktyczne konsekwencje / ryzyko
Jeśli użytkownik uruchomi taki „PoC”, ryzyko nie kończy się na jednorazowym incydencie. W opisach WebRAT pojawiają się m.in.:
- kradzież danych logowania i sesji (Steam/Telegram/Discord),
- kradzież danych z portfeli kryptowalutowych,
- funkcje spyware: keylogging, nagrywanie ekranu, użycie kamery/mikrofonu, screenshoty,
- pełniejsza kontrola stacji jako backdoor.
W praktyce oznacza to kompromitację kont prywatnych i służbowych (SSO w przeglądarce, tokeny, menedżery haseł), a przy pracy na laptopie firmowym — realny wektor wejścia do organizacji.
Rekomendacje operacyjne / co zrobić teraz
Dla SOC / IR / blue team
- Hunt po zachowaniu: alertuj na próby wyłączania/ingerencji w Microsoft Defender oraz nietypowe tworzenie zadań w Harmonogramie tuż po uruchomieniu plików z katalogów pobrań/rozpakowanych ZIP.
- Detekcja łańcucha:
start_exp.bat→rasmanesc.exe→ połączenie HTTP(S) do świeżych/egzotycznych domen → zapis/uruchomienie kolejnego binarium. - Blokady prewencyjne:
- blokuj uruchamianie plików BAT/PS1 z
%Downloads%i katalogów tymczasowych (ASR/WDAC/AppLocker zależnie od środowiska), - ogranicz uprawnienia lokalnego admina tam, gdzie nie jest to konieczne,
- egress filtering dla stacji roboczych + DNS logging (łatwiej wyłapać nowe C2).
- blokuj uruchamianie plików BAT/PS1 z
- IOC-based triage: użyj listy repo/C2/hashy z raportu jako szybki screening, ale nie opieraj całej strategii na IOCs.
Dla badaczy i studentów (najczęstsza grupa ryzyka w tej kampanii)
- Nigdy nie uruchamiaj PoC z internetu na „gołym” hoście. VM/sandbox, brak dostępu do prywatnych danych, odłączone urządzenia audio/wideo, brak realnych sesji w przeglądarce. (Kaspersky wprost wskazuje, że dojrzały workflow badawczy zakłada izolację).
- Sygnały ostrzegawcze repo: hasłowany ZIP, „kliknij Download”, plik z hasłem w nazwie, instrukcje jak z poradnika, a w środku EXE/BAT zamiast kodu exploita — traktuj to jako czerwoną flagę.
Różnice / porównania z innymi przypadkami
To, co wyróżnia WebRAT w tej odsłonie, to „opakowanie” ataku: zamiast typowego „cracka” mamy narrację stricte bezpieczeństwową (CVE, CVSS, mitigacje), co zwiększa skuteczność na osobach, które chcą wyglądać profesjonalnie („testuję podatność”), ale nie mają jeszcze twardej higieny operacyjnej.
Trend jest udokumentowany nie tylko w raportach vendorów, ale i w literaturze: analiza PoC na GitHub dla CVE z lat 2017–2021 wykazała, że da się znaleźć setki repozytoriów z oznakami złośliwości; autorzy raportują 899 takich repo na 47 285 badanych (~1,9%).
Podsumowanie / kluczowe wnioski
- Kampania z grudnia 2025 r. pokazuje, że „GitHub jako źródło PoC” bez weryfikacji to ryzyko, zwłaszcza gdy temat dotyczy modnych CVE.
- WebRAT jest groźny nie dlatego, że jest „nowy”, ale dlatego, że jest skutecznie dystrybuowany i nastawiony na kradzież kont + szpiegowanie.
- Najlepsza obrona to połączenie: izolacja analiz (VM/sandbox), kontrola uruchamiania skryptów/binariów z katalogów użytkownika, oraz detekcje behawioralne na tampering i nietypowe łańcuchy procesów.
Źródła / bibliografia
- BleepingComputer — „WebRAT malware spread via fake vulnerability exploits on GitHub” (23.12.2025). (BleepingComputer)
- Kaspersky Securelist — „From cheats to exploits: Webrat spreading via GitHub” (23.12.2025). (Securelist)
- Solar 4RAYS / RT-Solar — komunikat o Webrat (27.05.2025). (RT Solar)
- Kaspersky (blog) — „Malicious code on GitHub: How hackers target programmers” (25.02.2025). (Kaspersky)
- El Yadmani, The, Gadyatskaya — „Beyond the Surface: Investigating Malicious CVE Proof of Concept Exploits on GitHub” (arXiv:2210.08374, v2: 07.06.2023). (arXiv)
