Wprowadzenie do problemu / definicja luki
Australijskie służby (ASD/ACSC) ostrzegają, iż implant webshell BadCandy przez cały czas aktywnie infekuje niezałatane urządzenia Cisco IOS XE wystawione do Internetu. Wg najnowszych danych, od lipca 2025 r. w Australii potencjalnie naruszono ponad 400 urządzeń, a ponad 150 przez cały czas pozostaje zainfekowanych – mimo dostępnych od 2023 r. poprawek eliminujących pierwotny wektor ataku w interfejsie Web UI (CVE-2023-20198).
W skrócie
- Vektor wejścia: historyczna luka w Cisco IOS XE Web UI (m.in. CVE-2023-20198), masowo wykorzystywana od października 2023 r. do wdrażania implantu BadCandy.
- Czym jest BadCandy: lekki webshell w Lua rejestrowany jako niestandardowa ścieżka w wbudowanym serwerze www urządzenia; pozwala na zdalne wykonywanie poleceń na poziomie systemu/IOS.
- Skala w AU (X–XI 2025): >400 potencjalnie naruszonych urządzeń; >150 przez cały czas z implantem.
- Dlaczego wciąż działa: wiele urządzeń pozostaje niezałatanych lub z utrzymaną trwałością (np. dodatkowe konta/hasła, inne formy persystencji) po pierwszym włamaniu.
Kontekst / historia / powiązania
Pierwsze szerokie wykorzystanie luki w IOS XE Web UI odnotowano w październiku 2023 r. – badacze Cisco Talos opisali wtedy kolejne wersje implantu BadCandy rozmieszczanego po uzyskaniu nieautoryzowanego dostępu. Od tego czasu operatorzy zagrożenia iteracyjnie modyfikują webshell, co ułatwia im przetrwanie i unikanie detekcji.
Analiza techniczna / szczegóły luki
Rejestracja webshella. BadCandy jest dostarczany jako plik konfiguracyjny (np. cisco_service.conf), który dodaje nowy endpoint URI w serwerze www urządzenia. Zapytania pod ten endpoint przyjmują parametry umożliwiające wykonywanie dowolnych komend na urządzeniu (system/IOS).
Ewolucja i protokół. Talos opisał co najmniej trzy wersje BadCandy; jedna z nich weryfikuje obecność nagłówka X-Csrf-Token w żądaniach – to mechanizm zaciemniania/zabezpieczenia kanału C2.
Artefakty/detekcja. Publicznie dostępne procedury detekcyjne (Fox-IT) wskazują, iż implant może zdradzać obecność m.in. poprzez nietypowe odpowiedzi HTTP (np. różnice w odpowiedziach 404 przy specyficznym kodowaniu %25 w ścieżce) oraz obecność charakterystycznych wpisów konfiguracyjnych. Repo zawiera skrypty do skanowania i IOC.
Wektor wejścia. Historycznie ataki zaczynały się od nadużycia podatności CVE-2023-20198 (przywileje w Web UI), co pozwalało napastnikowi przejąć kontrolę, wgrać webshell i utrzymać się w systemie. Cisco opublikowało poprawki i szczegóły ograniczające ekspozycję Web UI.
Praktyczne konsekwencje / ryzyko
- Pełne przejęcie urządzenia brzegowego: możliwość modyfikacji konfiguracji routingu/ACL, wstrzykiwania reguł, przechwytywania/zmiany ruchu (MITM), a choćby pivotu w głąb sieci.
- Trwałość po łataniu: choćby po instalacji poprawek implant lub dodatkowa persystencja (np. konta, klucze, hasła, zaplanowane zadania) może utrzymywać dostęp atakującego. ACSC wyraźnie podkreśla konieczność usuwania implantu i twardej rekonfiguracji.
- Ryzyko łańcuchowe: zainfekowane urządzenie na perymetrze to idealny punkt do kradzieży danych uwierzytelniających i ataków na systemy wewnętrzne.
Rekomendacje operacyjne / co zrobić teraz
Priorytet 0: reakcja na incydent
- Sprawdź ekspozycję i kompromitację: użyj procedur ACSC i narzędzi Fox-IT do wykrywania BadCandy; manualnie sprawdź nietypowe endpointy, pliki *.conf rejestrujące usługi www oraz różnice odpowiedzi HTTP opisane przez Fox-IT.
- Jeśli kompromitacja potwierdzona: odłącz z Internetu, usuń implant zgodnie z wytycznymi ACSC, przeprowadź rebuild/reimage urządzenia, a następnie wgraj aktualny, wolny od backdoorów obraz. Obowiązkowo rotuj wszystkie poświadczenia (lokalne, TACACS+/RADIUS), klucze i sekretne wartości.
Priorytet 1: usunięcie wektora wejścia
3. Zainstaluj poprawki dla podatności Web UI (m.in. CVE-2023-20198) na wszystkich instancjach IOS XE; wyłącz lub ogranicz Web UI do zarządzania wyłącznie z zaufanych adresów (MGMNT/VPN), stosuj ACL i AAA.
Priorytet 2: hardening i monitorowanie
4. Minimalizacja powierzchni ataku: wyłącz zbędne usługi HTTP/HTTPS, telemetry, legacy protokoły; wymuś MFA i RBAC dla administratorów.
5. Monitoruj wskaźniki naruszenia (IOC) i anomalie ruchu do/ze zdefiniowanego endpointu webshella; ustaw alerty na niestandardowe ścieżki URI i nagłówki żądań (np. X-Csrf-Token).
6. Logowanie i forensyka: eksportuj logi poza urządzenie (syslog/SIEM); pamiętaj, iż sprawcy często modyfikują/wyłączają logowanie, dlatego artefaktów możesz szukać również w konfiguracji i ruchu.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
Na tle innych kampanii przeciwko infrastrukturze sieciowej BadCandy wyróżnia lekki, „konfiguracyjny” sposób wpięcia webshella w serwer www IOS XE, bez ciężkiego binarnego implantu. W praktyce utrudnia to detekcję (artefakty przypominają „normalną” konfigurację usług), a napastnik może szybko zmieniać endpointy i parametry bez ingerencji w obraz systemu.
Podsumowanie / najważniejsze wnioski
- BadCandy to wciąż realne i aktywne zagrożenie dla niezałatanych urządzeń Cisco IOS XE – również w IV kw. 2025 r. (Australia: >150 aktywnych infekcji pod koniec października).
- Samo łatane po incydencie nie wystarczy – trzeba usunąć implant, rotować poświadczenia i przeprowadzić pełny hardening oraz monitoring pod kątem persystencji.
- Organizacje powinny traktować ekspozycję Web UI jako ryzyko krytyczne i ograniczać ją do minimum, a detekcję oprzeć o artefakty HTTP oraz niestandardowe endpointy.
Źródła / bibliografia
- ACSC: „How your devices could be implanted and what to do about it (BADCANDY)” – wytyczne reagowania i usuwania. (cyber.gov.au)
- ACSC (PDF): „Don’t take BADCANDY from strangers” – skala i procedury (X–XI 2025). (cyber.gov.au)
- Cisco Talos: bieżąca analiza aktywnej eksploatacji IOS XE Web UI i wariantów BadCandy (2023–2024). (Cisco Talos Blog)
- Cisco: Advisory dot. eksploatacji Web UI w IOS XE (CVE-2023-20198) i zalecenia ograniczenia ekspozycji. (sec.cloudapps.cisco.com)
- BleepingComputer: artykuł podsumowujący ostrzeżenie Australii (31 października 2025). (BleepingComputer)
