SystemBC wraca po „takedownie”: botnet z 10 000 infekcji i rola w łańcuchach ransomware

Wprowadzenie do problemu / definicja „luki”

SystemBC to rodzina złośliwego systemu 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 najważniejsze jest to, iż ten malware pojawia się wcześnie w łańcuchu infekcji: jako warstwa pośrednicząca (proxy) i utrzymująca dostęp, zanim dojdzie do adekwatnej „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, iż 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ą gwałtownie 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ę, iż ekosystem nie tylko przetrwał, ale przez cały czas 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ł, iż SystemBC często „lubi” środowiska serwerowe/VPS: wysoka przepustowość, stała dostępność i mniejsza szansa, iż 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, iż aktywność SystemBC jest często prekursorem późniejszego nadużycia (follow-on).

Praktyczne konsekwencje / ryzyko

1. 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.
2. Ryzyko wtórnych infekcji i ransomware
   Nawet jeżeli sam komponent proxy wygląda „niegroźnie”, to może być etap przygotowawczy: utrzymanie kanału, rozpoznanie, pivoting, dostarczenie kolejnych modułów.
3. 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 choćby sam fakt działania węzła proxy na takim IP ma konsekwencje reputacyjne i operacyjne.
4. Odporność na „takedown”
   Historia po Operation Endgame pokazuje, iż ekosystemy loaderów/proxy potrafią się odrodzić: deweloperzy aktualizują kod, operatorzy zmieniają hosting/C2, a klienci przez cały czas 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żeli 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, iż „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żeli 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ą, iż efekt bywa czasowy, jeżeli 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 / najważniejsze 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, najważniejsze 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

1. SecurityWeek – „SystemBC Infects 10,000 Devices After Defying Law Enforcement Takedown” (05.02.2026). (SecurityWeek)
2. Silent Push – „Silent Push Identifies More Than 10,000 Infected IPs as Part of SystemBC Botnet Malware Family” (02–04.02.2026). (Silent Push)
3. Lumen / Black Lotus Labs – „Inside SystemBC’s Criminal Proxy Empire” (18.09.2025). (Lumen Blog)
4. Ireland NCSC – „SystemBC Historical Bot Infections Special Report” (materiał powiązany z Operation Endgame, 2024). (National Cyber Security Centre)
5. Proofpoint – „Major Botnets Disrupted via Global Law Enforcement Takedown” (30.05.2024). (Proofpoint)