Pomagamy Zrozumieć i Wdrażać Bezpieczeństwo
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”
Szef Biura Budżetowego Kongresu USA (CBO), Phillip Swagel, zeznał 18 listopada 2025 r. przed Komisją Budżetową Izby Reprezentantów, że po wykrytym dwa tygodnie wcześniej incydencie napastnicy zostali usunięci z systemów pocztowych CBO, a agencja „działa normalnie” i nie obserwuje dalszych oznak nieautoryzowanego dostępu do e-maili. Trwa jednak dochodzenie przy udziale partnerów federalnych oraz prywatnych specjalistów ds. bezpieczeństwa.
Incydent w CBO wpisuje się w ciąg ataków na instytucje legislacyjne i administrację publiczną, gdzie e-mail pozostaje newralgicznym kanałem wymiany informacji i celem działań szpiegowskich. Po wstępnym potwierdzeniu naruszenia w dniach 6–7 listopada 2025 r. agencja informowała o działaniach zaradczych i ciągłości prac analitycznych na rzecz Kongresu. W międzyczasie biura kongresowe ograniczały kontakty e-mail z CBO do czasu potwierdzenia remediacji.
Szczegóły wektorów ataku nie zostały upublicznione. Z dotychczasowych oświadczeń i przekazu medialnego można jednak zrekonstruować kilka kluczowych faktów:
Uwaga: brak jawnych danych o wykorzystanych podatnościach (np. 0-day w kliencie poczty, nadużycie tokenów OAuth, BEC z przejęciem konta, itp.). Na tym etapie należy traktować scenariusze techniczne jako hipotezy, a nie potwierdzone fakty.
Dla instytucji publicznych i organizacji współpracujących z administracją:
(Rekomendacje uzupełniają publiczne komunikaty CBO o wdrożeniu dodatkowych kontroli i monitoringu po incydencie).
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.
Logitech ujawnił incydent cyberbezpieczeństwa obejmujący kradzież danych z wewnętrznego systemu IT. Według zgłoszenia do amerykańskiej SEC, sprawcy wykorzystali zero-day w oprogramowaniu podmiotu trzeciego, po czym skopiowali część danych. Logitech podkreśla, że zdarzenie nie wpłynęło na produkty, produkcję ani operacje biznesowe i nie powinno mieć istotnego wpływu finansowego. Firma oczekuje pokrycia kosztów z polisy cyber.
The Record wskazuje, że zgłoszenie 8-K z 14 listopada 2025 r. (piątek) nastąpiło tydzień po tym, jak Cl0p przypisał sobie włamanie i zasugerował wykorzystanie podatności w Oracle EBS. Logitech odmówił potwierdzenia związku z Oracle lub Cl0p.
Relacje BleepingComputer i SecurityWeek opisują szerszą falę wymuszeń danych: ofiary (m.in. Harvard, Envoy Air, The Washington Post) informowały o kradzieży po dodaniu do witryny wycieków Cl0p. Oracle miało opublikować pilną łatę dla zero-daya związanego z EBS; w prasie branżowej pojawiają się numery CVE (np. CVE-2025-61882), lecz Logitech nie wskazał konkretów.
Dla użytkowników i pracowników:
Dla firm (szczególnie korzystających z ERP/Oracle EBS):
Cl0p od lat prowadzi kampanie „data-theft-only” przez luki dnia zerowego w narzędziach integracyjnych i transferowych. W przypadku MOVEit (2023) skala była bezprecedensowa; obecna fala na Oracle EBS jest podobna pod względem TTP (eksfiltracja + wymuszenie bez szyfrowania), ale dotyka systemów ERP o centralnym znaczeniu dla danych biznesowych. Logitech – jak wielu innych – raportuje brak wpływu na operacje, ale ujawnia eksfiltrację i zastosowanie polisy cyber do pokrycia kosztów.
DoorDash potwierdził naruszenie bezpieczeństwa, w którym „nieupoważniony podmiot” uzyskał dostęp do wewnętrznych systemów po tym, jak pracownik padł ofiarą ataku socjotechnicznego. Wyciek obejmuje dane osobowe (PII) użytkowników, dostawców (Dashers) i sprzedawców: imiona i nazwiska, adresy e-mail, numery telefonów oraz adresy fizyczne. Incydent wykryto 25 października 2025 r., a powiadomienia do poszkodowanych rozpoczęto w połowie listopada.
To nie pierwszy incydent DoorDash. Wcześniej firma raportowała naruszenia związane z dostawcami trzecimi i phishingiem, co pokazuje utrzymujące się ryzyko socjotechniczne w łańcuchu dostaw. Obecne zdarzenie wpisuje się w szerszy trend ataków na konta pracowników, które stają się „kluczem” do systemów produkcyjnych.
Poprzednie incydenty DoorDash wiązały się m.in. z kompromitacją dostawcy zewnętrznego (phishing na vendorze). Obecny przypadek to bezpośrednia socjotechnika na pracowniku DoorDash, bez udziału osoby trzeciej jako wektora startowego – ale efekt końcowy (ekfiltracja PII kontaktowej) jest podobny i prowadzi do tych samych nadużyć (phishing/SMiShing).
10 listopada 2025 r. Princeton University potwierdził incydent bezpieczeństwa dotyczący bazy „Advancement” (obszar fundraisingu i relacji z absolwentami). Atakujący uzyskali krótkotrwały dostęp (mniej niż 24 godziny) po skutecznym „phone phishingu” wymierzonym w pracownika z uprawnieniami do tej bazy. Uczelnia podkreśla, że systemy poza tą bazą nie zostały naruszone.
Incydent na Princeton następuje po głośnym włamaniu do University of Pennsylvania (UPenn) z końca października, gdzie atakujący wykorzystali przejęte konto SSO pracownika (PennKey) i uzyskali dostęp do Salesforce, SAP BI, SharePoint, Qlik; sprawcy twierdzili, że wynieśli dane ~1,2 mln osób (donorzy, absolwenci, studenci). Choć przypadki są podobne (ataki socjotechniczne na konta z szerokimi uprawnieniami), Princeton zaznacza, że nie ma dowodów na powiązania obu spraw.
Wektor dostępu: „phone phishing” – rozmowa telefoniczna, której celem było skłonienie pracownika do ujawnienia/wykonania akcji dającej dostęp do bazy Advancement. Tego typu ataki często łączą elementy vishingu (telefon), smishingu (SMS) i oszustw helpdeskowych, a ich skuteczność wynika z presji czasu i podszywania się pod osoby „zaufane” (np. IT, przełożeni). W tym przypadku uczelnia potwierdza, że hasła do innych systemów i rekordy objęte przepisami prywatności nie znajdowały się w naruszonej bazie, co ogranicza bezpośrednie skutki techniczne, ale nie eliminuje ryzyka wtórnych ataków (phishing ukierunkowany, SIM-swap, pretexting).
Zakres danych w bazie Advancement: dane identyfikacyjne i kontaktowe oraz metadane dot. darowizn i zaangażowania. Brak SSN, haseł, numerów kart/bankowych. Nie są to „recordy studenckie” chronione amerykańskimi przepisami FERPA.
Segmentacja i lateral movement: Princeton informuje, że nie ma oznak przejścia na inne systemy przed odcięciem napastników, co sugeruje skuteczną segmentację lub szybkie wykrycie nadużycia sesji/połączenia. (Deklaracja uczelni; pełne dochodzenie potrwa tygodnie).
Dla osób potencjalnie dotkniętych (alumni, darczyńcy, rodzice, studenci, kadra):
Dla zespołów IT w uczelniach i organizacjach non-profit: