Pomagamy Zrozumieć i Wdrażać Bezpieczeństwo
W świecie cyberbezpieczeństwa Linux odgrywa szczególną rolę – to fundament wielu narzędzi i środowisk do testów bezpieczeństwa, analizy incydentów czy ochrony prywatności. Zwykła dystrybucja Ubuntu czy Fedora oczywiście może zostać wyposażona w potrzebne programy, ale istnieją gotowe systemy tworzone z myślą o konkretnych zadaniach.
Czytaj dalej „Specjalistyczne Dystrybucje Linuksa W Cyberbezpieczeństwie”
Test penetracyjny (ang. penetration test, potocznie pentest) to kontrolowany, celowy atak symulowany na system informatyczny, aplikację lub sieć, przeprowadzany w celu oceny bezpieczeństwa tego systemu. Innymi słowy, jest to zaplanowane “hakowanie” własnej infrastruktury – etyczny atak wykonywany za zgodą właściciela systemu.
Czytaj dalej „Pentest (Test Penetracyjny) — Co To Jest? Kompletny Przewodnik”
W świecie cyberbezpieczeństwa Blue Team często korzysta z matrycy MITRE ATT&CK do mapowania taktyk i technik ataków przeciwnika. A co z naszą własną defensywą? Czy potrafimy równie przejrzyście zobrazować, jak broni się nasza organizacja? W tym artykule zobaczymy, jak framework MITRE D3FEND pomaga zbudować wizualną mapę obrony – swoisty dashboard defensywny zespołu SOC. Zamiast domyślać się, gdzie mamy luki, zwizualizujemy techniki obrony tak, by od razu wskazać mocne punkty i obszary wymagające uwagi.
Czytaj dalej „Jak Zamienić MITRE D3FEND W Wizualne Mapy Obrony”
Nowa fala ataków botnetu RondoDox celuje w serwery XWiki, wykorzystując krytyczną podatność CVE-2025-24893 (CVSS 9.8), która umożliwia zdalne wykonanie kodu bez uwierzytelnienia. Zaatakowane instancje są włączane do sieci botnetu i wykorzystywane w kolejnych kampaniach. Informację o nowej taktyce RondoDox potwierdził m.in. serwis BleepingComputer.
Badacze VulnCheck zwrócili uwagę, że po pierwszych oznakach użycia CVE-2025-24893 do exploitu, w krótkim czasie dołączyły kolejne grupy: botnety, górnicy kryptowalut i oportunistyczni skanerzy. To klasyczny wzorzec „efektu kuli śnieżnej” po publikacji technicznych szczegółów luki.
Równolegle media branżowe raportują o „wzmożonej eksploatacji” XWiki w ostatnich dniach, a BleepingComputer precyzuje, że jednym z beneficjentów tej luki jest właśnie botnet RondoDox.
CVE-2025-24893 dotyczy sposobu, w jaki XWiki przetwarza treści szablonów/makro w zapytaniach (m.in. kanał RSS wyszukiwarki Solr). Atakujący mogą wstrzyknąć i wykonać Groovy w kontekście serwera — bez logowania. NVD podaje nawet prosty test na podatność, który wykrywa wykonanie kodu w tytule zwracanego feedu RSS.
Skutkiem jest pełne zdalne wykonanie kodu (RCE). Broadcom/Symantec opisuje to jako możliwość wstrzyknięcia i wykonania dowolnego kodu Groovy przez spreparowane żądania.
W praktyce przejęty serwer XWiki może zostać:
{{groovy}}). (Wniosek na podstawie szczegółów NVD i opisów w Broadcom.) /xwiki/bin/get/...SolrSearch?media=rss..., nowo utworzone konta, modyfikacje skryptów/makr, zadania cron, nieznane procesy powłoki. (Na bazie wektora z NVD.) W odróżnieniu od wielu wcześniejszych błędów XWiki (np. dotyczących właściwości klas czy nadużyć edytora), CVE-2025-24893 zapewnia RCE dla gościa poprzez przetwarzanie treści w publicznych endpointach (np. RSS Solr), co radykalnie zwiększa ryzyko skanów/automatyzacji przez botnety takie jak RondoDox. W efekcie czas od publikacji szczegółów do masowych nadużyć był wyjątkowo krótki.
W ekosystemie Node.js wykryto siedem złośliwych paczek, które nadużywają chmurowej usługi Adspect (mechanizmy „cloaking”) do rozróżniania badaczy od potencjalnych ofiar i przekierowywania tych drugich na strony oszustw krypto. Paczki publikował autor „dino_reborn” (e-mail geneboo@proton[.]me) między wrześniem a listopadem 2025 r. — sześć z nich zawierało złośliwy kod, jedna służyła do budowy „białej” strony przynęty.
Nazwy zgłoszonych pakietów: signals-embed, dsidospsodlks, applicationooks21, application-phskck, integrator-filescrypt2025, integrator-2829, integrator-2830. Według badaczy Socket, po zgłoszeniach trafiły do „security holding” w npm.
appprotector[.]online, protectorapp[.]online, association-google[.]xyz) ukrywa strukturę Adspect i zbiera prawdziwe IP ofiary; parametry identyfikacyjne kampanii ADSPECT_STREAM_ID różnią się między pakietami. Kampania wpisuje się w szerszą falę ataków na łańcuch dostaw npm w 2025 r., obejmującą m.in. przejęcia kont maintainerów oraz masowe publikacje złośliwych bibliotek (np. incydent z kompromitacją chalk/debug i kilkunastu innych projektów o miliardowych tygodniowych pobraniach). W ostatnich miesiącach raportowano również kampanie z fałszywymi CAPTCHA i wielowarstwową obfuskacją.
Łańcuch wykonania w przeglądarce. Złośliwy kod (ok. 39 kB) uruchamia się automatycznie dzięki IIFE po załadowaniu do aplikacji webowej ofiary (np. przez import skompromitowanej paczki). Skrypt zbiera charakterystyki środowiska (user-agent, host, referrer, URI, query string, protokół, język, kodowanie, akceptowane typy treści, port, timestamp) i wysyła je do proxy aktora (np. …/adspect-proxy.php). Proxy ustala realne IP odwiedzającego i pośredniczy w wywołaniach do Adspect API, które klasyfikuje wizytę (white/black).
Cloaking i anty-analiza. Jeśli Adspect oceni wizytę jako badawczą, serwowana jest „biała” witryna (np. fikcyjna strona Offlido) w celu zatarcia śladów; w przeciwnym razie ofiara widzi fałszywą CAPTCHA brandowaną (np. standx[.]com, Uniswap, Jupiter), której interakcja inicjuje przekierowanie do docelowego URL zdefiniowanego po stronie Adspect. Dodatkowo kod:
TARGET_CONTAINER, np. signals-embed-root), łącząc poszczególne pakiety kampanii. Konfiguracja kampanii. Każdy pakiet ma swój ADSPECT_STREAM_ID oraz zestaw domen-proxy (appprotector[.]online, protectorapp[.]online, association-google[.]xyz) i plików pomocniczych (adspect-file.php, adspect-proxy.php). Różnice konfiguracyjne pozwalają śledzić warianty i skuteczność strumieni w Adspect.
1) Natychmiastowa higiena zależności
signals-embed, dsidospsodlks, applicationooks21, application-phskck, integrator-filescrypt2025, integrator-2829, integrator-2830.--ignore-scripts w CI tam, gdzie to możliwe, oraz mirror/allow-list dla rejestru. (Praktyka szeroko rekomendowana po wrześniowych incydentach). 2) Detekcja artefaktów kampanii (IoC i zachowania)
appprotector[.]online, protectorapp[.]online, association-google[.]xyz, ścieżki adspect-proxy.php, adspect-file.php.ADSPECT_STREAM_ID, TARGET_CONTAINER, IIFE z funkcjami blokującymi DevTools, wywołania do rpc.adspect[.]net/v2/ przez proxy. 3) Twardnienie frontendu i obserwowalność
default-src 'self' i restrykcyjnym connect-src, SRI dla skryptów, blokada window.open bez interakcji użytkownika; monitorowanie Content Security Policy violation reports. (Skuteczne przeciw nieautoryzowanym przekierowaniom.) — w kontekście tej kampanii ogranicza ładowanie skryptów i wywołań proxy.4) Procesy i governance
Atak pokazuje, że łańcuch dostaw JavaScript nie dotyczy już tylko masowych infostealerów u devów — frontend użytkownika końcowego staje się celem poprzez import „pozornie niewinnych” paczek. Wykorzystanie Adspect (cloaking-as-a-service) znacząco utrudnia analizę i wydłuża czas wykrycia. Organizacje powinny zacieśnić politykę zależności, wdrożyć CSP/SRI, śledzić IoC Adspect oraz szybko izolować projekty, w których wykryto wskazane nazwy paczek.
Policja w Niderlandach (Politie) poinformowała, że 12 listopada 2025 r. przejęła infrastrukturę złożoną z ok. 250 fizycznych serwerów należących do dostawcy tzw. bulletproof hostingu. Usługodawca reklamował pełną anonimowość i brak współpracy z organami ścigania; jego zasoby były wykorzystywane wyłącznie do działalności przestępczej (ransomware, botnety, phishing, a nawet dystrybucja materiałów CSAM). Serwery stały w Hadze i Zoetermeer, a ich zajęcie wyłączyło tysiące serwerów wirtualnych obsługiwanych na tej infrastrukturze.
„Bulletproof hosting” to segment usług, w którym operatorzy celowo ignorują abuse i wnioski o usunięcie treści, nie egzekwują KYC, dopuszczają płatności krypto i promują anonimowość klientów. Tego typu platformy są ekosystemowym „multiplikatorem” dla kampanii ransomware, phishingu, C2 botnetów i baz wykradzionych danych. Opisywany hoster działał co najmniej od 2022 r., a jego zasoby pojawiały się w wielu dochodzeniach zarówno w NL, jak i za granicą.
W tym samym tygodniu Europol ogłaszał kolejny etap Operation Endgame (ponad 1 025 serwerów zaburzeń/zdjętych globalnie, 20 domen, 11 przeszukań, w tym 9 w NL), jednak niderlandzka Policja – za pośrednictwem BleepingComputer – wskazała, że te dwa wątki nie są ze sobą połączone.
W lutym 2025 r. holenderska Policja wyłączyła 127 serwerów należących do innego bulletproof hostera (ZServers), co odbywało się pod parasolem sankcji–dochodzeń międzynarodowych. Obecna akcja jest większa na poziomie skutku (tysiące VM) i dotyczy innego podmiotu; dodatkowo – w odróżnieniu od wątków Endgame – Policja podkreśla brak powiązania między obiema historiami.
Google ogłosiło, że wprowadzi do Sklepu Play ostrzeżenia dla aplikacji, które nadmiernie drenują baterię poprzez długotrwałe utrzymywanie partial wake locks (blokad uniemożliwiających uśpienie CPU przy wyłączonym ekranie). Nowa polityka opiera się na metryce “excessive partial wake locks” w Android Vitals i będzie wpływała zarówno na widoczność aplikacji, jak i komunikaty ostrzegawcze widoczne dla użytkowników na kartach aplikacji. Zmiany zaczną obowiązywać od 1 marca 2026 r..
Android od lat walczy z aplikacjami, które „przytrzymują” urządzenie w stanie aktywnym bez korzyści dla użytkownika. Wcześniej Google promowało praktyki ograniczania pracy w tle (JobScheduler/WorkManager) oraz monitorowania energii (Batterystats/Battery Historian). Nowa metryka włącza te zasady do twardego progu jakości technicznej Android Vitals — obok crash rate czy ANR rate — i wiąże je z algorytmiczną widocznością w Play. To zmienia rekomendacje w wymogi: zignorowanie problemu będzie miało realny wpływ na wzrost/instale.
Czym jest partial wake lock?
To mechanizm utrzymujący CPU w stanie aktywnym przy zgaszonym ekranie, aby aplikacja mogła wykonywać pracę w tle (np. synchronizację). Nadużywany — potrafi wyssać baterię w nocy.
Definicje Google dla metryki:
Jak Google wykrywa problem?
Zespół połączył dane platformy z „real-world insights” od Samsunga i feedbackiem deweloperów z bety (od kwietnia), kalibrując algorytm pod rzeczywiste wzorce drenażu.
Dla deweloperów:
Dla użytkowników:
Dla bezpieczeństwa (defensywnie):
class SyncWorker(ctx: Context, params: WorkerParameters) : CoroutineWorker(ctx, params) { override suspend fun doWork(): Result { // ...realna praca sieciowa... return Result.success() } } val constraints = Constraints.Builder() .setRequiredNetworkType(NetworkType.UNMETERED) .setRequiresCharging(true) .build() val req = OneTimeWorkRequestBuilder<SyncWorker>() .setConstraints(constraints) .build() WorkManager.getInstance(context).enqueue(req)val pm = context.getSystemService(Context.POWER_SERVICE) as PowerManager val wl = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "app:shortTask") try { wl.acquire(30_000L) // maks. 30s – twardy limit! doShortTask() } finally { if (wl.isHeld) wl.release() }
finally.# reset licznika adb shell dumpsys batterystats --reset # uruchom scenariusz testowy ... # zrzut do pliku adb shell dumpsys batterystats > /sdcard/bstats.txt adb pull /sdcard/bstats.txt .
adb bugreport bug.zip # otwórz w Battery Historian i sprawdź wakelocki/alarms/sync