Co znajdziesz w tym artykule?
- 1 Wprowadzenie do problemu / definicja „luki”
- 2 W skrócie
- 3 Kontekst / historia / powiązania
- 4 Analiza techniczna / szczegóły działania
- 5 Praktyczne konsekwencje / ryzyko
- 6 Rekomendacje operacyjne / co zrobić teraz
- 7 Różnice / porównania z innymi przypadkami
- 8 Podsumowanie / kluczowe wnioski
- 9 Źródła / bibliografia
Wprowadzenie do problemu / definicja „luki”
SystemBC to rodzina złośliwego oprogramowania określana najczęściej jako proxy malware + backdoor/loader, która zamienia zainfekowane hosty w serwery SOCKS5 (przekaźniki ruchu). W praktyce nie chodzi o „lukę” w sensie CVE, tylko o komponent infrastrukturalny w ekosystemie cyberprzestępczym: umożliwia ukrywanie źródeł ataku (anonymization), utrzymanie dostępu i – w zależności od wariantu – dostarczanie kolejnych payloadów, w tym tych wykorzystywanych w kampaniach ransomware.
W lutym 2026 r. temat wrócił z dużą siłą, bo analitycy z Silent Push raportują ponad 10 000 unikalnych zainfekowanych adresów IP generujących charakterystyczny dla SystemBC ruch – mimo wcześniejszych działań organów ścigania wymierzonych w ten ekosystem.
W skrócie
- Skala: ponad 10 000 IP powiązanych z aktywnością SystemBC; największe skupiska w USA, ale także m.in. w Niemczech, Francji, Singapurze i Indiach.
- Funkcja: konwersja hostów do SOCKS5 proxy + komponent backdoor; bywa wykorzystywany do „tunelowania” kolejnych działań i dostarczania malware/ransomware.
- Odporność operacyjna: po działaniach wymierzonych w droppers/loadery w ramach Operation Endgame (maj 2024) aktywność nie zniknęła; raporty wskazują na ciągły rozwój i aktualizacje na forach podziemnych.
- Nowość techniczna: Silent Push opisuje wcześniej nieudokumentowany wariant w Perlu (Linux), co potwierdza ewolucję i multi-platformowość.
Kontekst / historia / powiązania
SystemBC jest znany co najmniej od 2019 r. i funkcjonuje pod aliasami Coroxy oraz DroxiDat. Z perspektywy obrony kluczowe jest to, że ten malware pojawia się wcześnie w łańcuchu infekcji: jako warstwa pośrednicząca (proxy) i utrzymująca dostęp, zanim dojdzie do właściwej „monetyzacji” (kradzież, oszustwa, ransomware).
W maju 2024 r. SystemBC był wśród rodzin malware objętych szeroką akcją Operation Endgame, ukierunkowaną na infrastrukturę botnetów i loaderów/droppers wykorzystywanych do dystrybucji kolejnych zagrożeń. Proofpoint podaje, że w ramach skoordynowanych działań mowa była m.in. o aresztowaniach, przejęciach domen i wyłączeniu serwerów.
Dlaczego więc temat wraca? Bo „takedown” uderza w elementy infrastruktury, ale operatorzy i klienci takich usług potrafią szybko migrować (bulletproof hosting, nowe C2, rotacja węzłów), a sam model działania proxy-malware sprzyja odporności: sieć złożona z wielu hostów i przekaźników trudniej „wyzerować” jednym ruchem.
Analiza techniczna / szczegóły działania
1) Proxy SOCKS5 jako produkt „infrastrukturalny”
SystemBC projektowany jest tak, aby host ofiary stał się węzłem proxy. Dla atakującego to ogromna wartość:
- maskowanie prawdziwego źródła ruchu,
- możliwość prowadzenia ataków „z IP ofiar” (utrudnia atrybucję),
- budowa płatnej usługi proxy lub wewnętrznej warstwy anonimizacji dla grup przestępczych.
Silent Push opisuje dwie główne role: proxy oraz backdoor utrzymujący dostęp; część wariantów (w tym obserwowane na Windows) bywa łączona z dostarczaniem dodatkowych payloadów, czasem „obok” ransomware.
2) Architektura rotacyjna i C2
SecurityWeek (za Silent Push) zwraca uwagę na rotacyjną architekturę: klienci łączą się z wystawionymi do internetu serwerami C2, które następnie proxy’ują ruch przez zainfekowane hosty.
Taki model:
- rozprasza „punkt ciężkości” infrastruktury,
- upraszcza wymianę węzłów i migrację,
- pozwala na szybkie odtwarzanie sieci po zakłóceniach.
3) Multi-platformowość i wariant Perl (Linux)
Istotny sygnał z raportu Silent Push to nowy wariant napisany w Perlu, co dodatkowo wzmacnia tezę, że ekosystem nie tylko przetrwał, ale nadal się rozwija.
W praktyce dla zespołów SOC oznacza to konieczność myślenia o detekcji nie tylko na endpointach Windows, ale też w środowiskach Linux/VPS, gdzie często działają usługi internetowe (hosting, reverse proxy, panele administracyjne).
4) Preferencja celów: hosting/VPS zamiast „domowych PC”
Według SecurityWeek botnet „głównie celuje w hosting providers”.
Lumen (Black Lotus Labs) historycznie pokazywał, że SystemBC często „lubi” środowiska serwerowe/VPS: wysoka przepustowość, stała dostępność i mniejsza szansa, że użytkownik zauważy anomalię. W ich analizie pojawia się też wątek dużej liczby niezałatanych podatności na hostach ofiar (średnio dziesiątki CVE na system).
5) Powiązania z kolejnymi etapami ataku
Wniosek wspólny dla źródeł: SystemBC bywa „wczesnym markerem” aktywności, która może eskalować do ransomware. Silent Push wprost wskazuje, że aktywność SystemBC jest często prekursorem późniejszego nadużycia (follow-on).
Praktyczne konsekwencje / ryzyko
- Ucieczka spod kontroli egress
Jeśli host staje się SOCKS5 proxy, atakujący mogą prowadzić ruch „jakby z twojej infrastruktury”, omijając część kontroli reputacyjnych i utrudniając analizę incydentu. - Ryzyko wtórnych infekcji i ransomware
Nawet jeśli sam komponent proxy wygląda „niegroźnie”, to może być etap przygotowawczy: utrzymanie kanału, rozpoznanie, pivoting, dostarczenie kolejnych modułów. - Zagrożenie dla usług publicznych i instytucji
Silent Push wspomina o infekcjach w „wrażliwych” środowiskach (m.in. hostujących oficjalne domeny). To nie musi oznaczać pełnego przejęcia instytucji, ale nawet sam fakt działania węzła proxy na takim IP ma konsekwencje reputacyjne i operacyjne. - Odporność na „takedown”
Historia po Operation Endgame pokazuje, że ekosystemy loaderów/proxy potrafią się odrodzić: deweloperzy aktualizują kod, operatorzy zmieniają hosting/C2, a klienci nadal kupują dostęp.
Rekomendacje operacyjne / co zrobić teraz
Dla SOC / IR
- Poluj na nietypowy ruch SOCKS5 (porty, wzorce handshake, nietypowe długotrwałe sesje wychodzące). W środowiskach serwerowych traktuj to jako sygnał wysokiego priorytetu.
- Wykrywanie C2 i fingerprinting: jeśli korzystasz z TI, sprawdzaj, czy dostawcy mają sygnatury/fingerprinty specyficzne dla SystemBC (Silent Push raportuje opracowanie takiego fingerprintu).
- Segmentacja i egress filtering: ogranicz możliwość zestawiania dowolnych połączeń wychodzących z serwerów, które nie powinny „proxy’ować świata”.
- Higiena VPS/hostingu: szybkie łatanie, redukcja powierzchni usług, twarde zasady MFA dla paneli, monitoring integralności i procesów.
Dla administratorów WWW/DevOps
- Skan podatności + priorytetyzacja CVE: Lumen zwracał uwagę na liczne niezałatane podatności na hostach ofiar; potraktuj to jako wskaźnik, że „drobne zaległości” kumulują się w realne ryzyko przejęcia VPS.
- Weryfikuj nowe/nieznane procesy i połączenia na serwerach produkcyjnych (szczególnie jeśli serwer nagle generuje duży outbound).
- Zbieraj artefakty: netflow/pcap, listy procesów, crontab/systemd timers, historię powłoki – w wielu kampaniach loader/proxy zostawia ślady w automatyzacji uruchamiania.
Dla zarządzania ryzykiem
- Traktuj proxy-malware jako „wczesny etap ransomware” w playbookach i komunikacji do biznesu. To ułatwia uzasadnienie szybkiej izolacji systemów i działań naprawczych.
Różnice / porównania z innymi przypadkami
- Proxy-malware vs klasyczny botnet DDoS: SystemBC może być wykorzystywany do różnych nadużyć, ale jego „rdzeń” to warstwa pośrednicząca ruch (SOCKS5) i utrzymywanie dostępu – bardziej infrastrukturalna rola niż jednorazowe „strzelanie” pakietami.
- Takedown infrastruktury vs takedown ekosystemu: Operation Endgame uderzało w droppers/loadery; jednak modele usługowe (MaaS/RaaS) i migracje do odpornych dostawców hostingu sprawiają, że efekt bywa czasowy, jeśli nie towarzyszy mu presja na operatorów i klientów rynku.
- Windows-only vs multi-platform: raporty wskazują na komponenty/aktywność również w Linux (w tym Perl), co zwiększa trudność obrony w środowiskach mieszanych.
Podsumowanie / kluczowe wnioski
SystemBC to nie „kolejny trojan”, tylko element infrastruktury cyberprzestępczej, który pomaga ukrywać ataki, utrzymywać dostęp i torować drogę do kolejnych etapów – włącznie z ransomware. Najnowsze obserwacje (luty 2026) wskazują na ponad 10 000 infekcji i ciągły rozwój (nowe warianty, ewolucja), mimo wcześniejszych działań organów ścigania.
Jeśli zarządzasz serwerami/VPS, kluczowe są: kontrola egress, szybkie łatanie, monitoring anomalii sieciowych oraz traktowanie wykrycia proxy/backdoora jako potencjalnego początku „większej historii”, a nie incydentu o niskim priorytecie.
Źródła / bibliografia
- SecurityWeek – „SystemBC Infects 10,000 Devices After Defying Law Enforcement Takedown” (05.02.2026). (SecurityWeek)
- Silent Push – „Silent Push Identifies More Than 10,000 Infected IPs as Part of SystemBC Botnet Malware Family” (02–04.02.2026). (Silent Push)
- Lumen / Black Lotus Labs – „Inside SystemBC’s Criminal Proxy Empire” (18.09.2025). (Lumen Blog)
- Ireland NCSC – „SystemBC Historical Bot Infections Special Report” (materiał powiązany z Operation Endgame, 2024). (National Cyber Security Centre)
- Proofpoint – „Major Botnets Disrupted via Global Law Enforcement Takedown” (30.05.2024). (Proofpoint)