Archiwa: SIEM - Strona 25 z 46

Zmasowane ataki password spraying na bramy VPN Cisco i Palo Alto (GlobalProtect)

Wprowadzenie do problemu / definicja luki

W połowie grudnia 2025 r. GreyNoise odnotował skoordynowaną kampanię automatycznych prób logowania (password spraying / credential stuffing) wymierzoną w bramy uwierzytelniania VPN dwóch producentów: Palo Alto Networks GlobalProtect oraz Cisco SSL VPN. Wnioski badaczy i doniesienia prasowe potwierdzają, że mamy do czynienia z falą zautomatyzowanych żądań logowania, a nie z wykorzystaniem konkretnej podatności w samym oprogramowaniu VPN.

W skrócie

Skala: ~1,7 mln sesji w ciągu 16 godzin przeciwko portalom GlobalProtect (11 grudnia), z ponad 10 tys. unikalnych adresów IP. Następnego dnia wzrost prób na Cisco SSL VPN do 1 273 unikalnych IP (znacznie powyżej typowej bazowej <200).
Infrastruktura sprawców: niemal cały ruch pochodził z zakresów 3xK GmbH (Niemcy); spójny odcisk TCP i identyczne wzorce ruchu wskazują na jedną kampanię pivotującą między platformami VPN.
Technika: powtarzalne kombinacje login/hasło, jednolity user-agent (Firefox / Windows 10), prawidłowe przepływy uwierzytelniania (w tym CSRF), co potwierdza automatyzację i brak exploitów.
To NIE jest AsyncOS 0-day: GreyNoise nie widzi związku z ujawnioną 17 grudnia kampanią na urządzenia Cisco Secure Email Gateway/SEWM (CVE-2025-20393).

Kontekst / historia / powiązania

Skoki ruchu na GlobalProtect obserwowano już wcześniej — m.in. 14–20 listopada (2,3 mln sesji skanowania) oraz 2 grudnia (7 000+ IP), przy czym w obu przypadkach źródłem była ta sama infrastruktura 3xK GmbH. Obecna fala z 11–12 grudnia wpisuje się w tę sekwencję i wygląda na kontynuację/inwentaryzację na większą skalę.

Analiza techniczna / szczegóły luki

Wejście: Publicznie dostępne portale uwierzytelniania GlobalProtect oraz Cisco SSL VPN.
Łańcuch żądania: żądania HTTP na endpointy logowania, obsługa tokenów CSRF, parametry login/password, silnie powtarzalne nagłówki i treści. Dla Cisco dominujący UA: Mozilla/5.0 (Windows NT 10.0; Win64; x64); dla Palo Alto częsty UA Firefox — oba nietypowe dla zwykłych skanerów tego operatora.
TTPs:
- Password spraying / credential stuffing z użyciem puli standardowych/wyciekłych haseł.
- Jednolita sygnatura TCP/JA4t i ta sama przestrzeń IP → wysoka spójność narzędziowa.
- Pivot: po fali na GlobalProtect szybkie przełączenie na Cisco SSL VPN (w 24 h).
Brak oznak exploitów zero-day/n-day na bramach VPN; żądania imitują legalną ścieżkę logowania.

Praktyczne konsekwencje / ryzyko

Ryzyko przejęcia konta (zwłaszcza kont bez MFA, kont serwisowych, starszych kont SSO, kont z recyklingiem haseł).
Ryzyko DoS logicznego (lockouty i „wybicie” okienka logowania przy masowych próbach).
Ryzyko eskalacji: po jednorazowym wejściu przez VPN możliwe przełamanie segmentacji i lateral movement.
Fałszywe poczucie bezpieczeństwa: brak CVE ≠ brak incydentu — to kampania uwierzytelnieniowa, a nie exploitowa. Doniesienia branżowe i prasowe zgodnie to podkreślają.

Rekomendacje operacyjne / co zrobić teraz

Priorytet — edge & tożsamość:

Wymuś MFA (najlepiej phishing-resistant: FIDO2/Passkeys, WebAuthn) na portalach VPN/SSO; wyłącz fallbacki SMS/TOTP tam, gdzie to możliwe.
Blokuj źródła znane z kampanii (zakresy 3xK GmbH i konkretne IP z list GreyNoise; aktualne bloki/„tags” są publikowane przez GN).
Twarde polityki haseł + sprawdzanie przeciw wyciekom (HIBP/CrackStation, itp.), rotation tylko ryzyko-based, zakaz recyklingu.
Ogranicz powierzchnię:
- dostęp do portali wyłącznie z zaufanych AS/geo/VPN klienta (geo-fencing, allow-list),
- CAPTCHA / rate-limiting / tar-pit na formularzach logowania,
- ukryj portale za IdP z federation only i conditional access.
Monitoring i detekcja:
- reguły UEBA/behavioral na anomalne login bursts i UA fingerprint opisany przez GN,
- alerty na wiele nieudanych logowań z wielu IP do jednego konta,
- korelacja z logami GlobalProtect/Cisco SSL VPN i SIEM.
Higiena kont: wyłącz/stale audytuj konta serwisowe, narzuć MFA i długie hasła; minimalizuj scope i privs.
Playbook IR: gotowe runbooki blokad, wymuszenia resetów po próbach spraying, komunikacja do użytkowników.
Oddzielny wątek: AsyncOS (CVE-2025-20393) — jeśli masz Cisco SEG/SEWM, zastosuj tymczasowe obejścia i zalecenia Cisco, bo to niezależna, aktywnie wykorzystywana 0-day na inny produkt.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

Obecna kampania (VPN): zautomatyzowane loginy bez exploitów; cel — odkryć słabe hasła/konta bez MFA w GlobalProtect/Cisco SSL VPN.
AsyncOS 0-day (CVE-2025-20393): wykorzystywana luka RCE z persystencją (AquaShell/AquaTunnel/Chisel) na Secure Email Gateway/SEWM, wymagająca specyficznej konfiguracji (Spam Quarantine wystawione do Internetu). Inny wektor, inne systemy.

Podsumowanie / kluczowe wnioski

Ataki na warstwę uwierzytelniania bram VPN znów przyspieszyły — tym razem w formie skoordynowanej kampanii, która w 24 godziny przestawiła się z GlobalProtect na Cisco SSL VPN. Nie potrzebujesz CVE, by zostać zhakowanym: MFA, polityki haseł, geofencing i monitoring to dziś „must-have” na brzegu sieci. Jednocześnie nie mylmy tej fali z incydentami wokół AsyncOS — to dwa różne problemy, oba wymagające działania.

Źródła / bibliografia

GreyNoise: „Coordinated Credential-Based Campaign Targets Cisco and Palo Alto Networks VPN Gateways”, 17 grudnia 2025. (GreyNoise)
BleepingComputer: „New password spraying attacks target Cisco, PAN VPN gateways”, 18 grudnia 2025. (BleepingComputer)
Cisco Security Advisory: „Reports About Cyberattacks Against Cisco Secure Email and Web Manager” (CVE-2025-20393), 17 grudnia 2025. (Cisco)
Cisco Talos: „UAT-9686 actively targets Cisco Secure Email Gateway and Secure Email and Web Manager”, 17 grudnia 2025. (Cisco Talos Blog)
Cybersecurity Dive: „Surge of credential-based hacking targets Palo Alto Networks GlobalProtect portals…”, 18 grudnia 2025. (Cybersecurity Dive)

Amazon ostrzega przed trwającą kampanią cryptominingu wykorzystującą przejęte konta AWS

Wprowadzenie do problemu / definicja luki

Amazon (AWS) poinformował o trwającej kampanii cryptominingu wymierzonej w klientów korzystających z Amazon EC2 i Amazon ECS. Atakujący nie wykorzystują luki w usługach AWS, lecz legalne, skompromitowane poświadczenia IAM (tożsamości i uprawnienia), co pozwala im szybko wdrażać koparki i utrzymywać się w środowisku dzięki nowym technikom utrwalania (persistence). AWS wykrył kampanię 2 listopada 2025 r. i opisał jej przebieg oraz wskaźniki kompromitacji (IoC).

W skrócie

Wejście uzyskiwane jest przez przejęte klucze/hasła IAM o uprawnieniach zbliżonych do admina. Koparki startują w ~10 minut od pierwszego logowania.
Wykorzystywane są EC2 (w tym instancje GPU/ML) oraz ECS/Fargate z agresywnym autoscalingiem (do 999 instancji w grupie).
Nowa technika persistence: masowe ustawianie ModifyInstanceAttribute → disableApiTermination: true utrudnia automatyczną reakcję/terminację.
W kampanii użyto złośliwego obrazu Docker Hub yenik65958/secret (usunięty) z SBRMiner-MULTI i pulami *.rplant.xyz:17155.
Media branżowe potwierdzają szczegóły (m.in. DryRun do sprawdzania uprawnień, publiczne Lambda URL i tworzenie użytkownika z SES Full Access).

Kontekst / historia / powiązania

Cryptojacking w chmurze nie jest nowy – wcześniejsze kampanie uderzały m.in. w AWS Lambda czy klastry kontenerowe, często opierając się na wykradzionych kluczach bądź błędach konfiguracji. Przykładowo w 2022 r. opisano pierwszy znany malware ukierunkowany na AWS Lambda. Dzisiejsza kampania wyróżnia się jednak tempem i dojrzałym łańcuchem działań w wielu usługach jednocześnie.

Analiza techniczna / szczegóły kampanii

Wejście i rozpoznanie

Logowanie z anomalii sieciowej przy użyciu skompromitowanego użytkownika IAM z uprawnieniami admin-like.
Szybkie sondowanie limitów EC2 (GetServiceQuota) oraz walidacja uprawnień przez wielokrotne wywołania RunInstances z flagą DryRun (tani „test” bez tworzenia instancji). To charakterystyczny, wczesny sygnał ostrzegawczy w logach CloudTrail.

ECS / Fargate – wpływ

Tworzenie dziesiątków klastrów ECS (czasem >50 w jednej ofierze).
Rejestracja task definition z obrazem yenik65958/secret:user, uruchamianie usług na Fargate z CPU=16384, RAM=32 GiB, desiredCount=10. Skrypt run.sh uruchamia RandomVIREL z pulami asia|eu|na.rplant.xyz:17155.

EC2 – wpływ

Tworzenie szablonów uruchamiania i 14 grup autoskalujących z parametrami do 999 instancji, celowanie w GPU/ML (g4dn/g5/p3/p4d/inf1) oraz instancje ogólnego przeznaczenia (c6i/m5/r5).

Persistence / utrudnianie IR

Masowe ustawienie disableApiTermination: true dla każdej instancji (via ModifyInstanceAttribute). To przerywa automatyczną remediację i zmusza zespoły do ręcznego cofnięcia ochrony przed terminacją.
Utworzenie publicznego URL w AWS Lambda (CreateFunctionUrlConfig z AuthType: NONE) oraz nadanie AddPermission z principal: "*".
Dodanie użytkownika user-x1x2x3x4 z polityką AmazonSESFullAccess – wskazuje to na potencjalne kampanie phishingowe przez Amazon SES.

IoC / Telemetria

Obraz: yenik65958/secret (Docker Hub – usunięty).
Domeny mining pool: asia|eu|na.rplant.xyz.
UA / narzędzia: ślady Boto3 (AWS SDK for Python).
Wzorce nazewnictwa ASG: SPOT-us-east-1-G*-* oraz OD-us-east-1-G*-*.

Wykrycie

Kampanię skorelowały mechanizmy Amazon GuardDuty Extended Threat Detection (m.in. AttackSequence:EC2/CompromisedInstanceGroup), łącząc TI, anomalie sieciowe i runtime. Niezależne serwisy (BleepingComputer, Dark Reading, THN) potwierdzają opis AWS.

Praktyczne konsekwencje / ryzyko

Koszty: gwałtowny wzrost wykorzystania zasobów (GPU/ML, Fargate) może przełożyć się na pięcio-/sześciocyfrowe kwoty na fakturze, zanim monitoring zareaguje. (Wprost wynika z opisu skalowania do setek instancji.)
Degradacja usług: wyczerpanie limitów i zasobów wpływa na aplikacje produkcyjne.
Bezpieczeństwo komunikacji: nadużycie SES do phishingu zwiększa ryzyko wtórnych incydentów (brand abuse, BEC).

Rekomendacje operacyjne / co zrobić teraz

1) Natychmiastowa higiena tożsamości

Rotacja wszystkich długoterminowych kluczy IAM; wymuś MFA dla użytkowników i ról, w tym break-glass.
Zasada najmniejszych uprawnień i tymczasowe poświadczenia (IAM Roles, SSO) zamiast długowiecznych access keys.

2) Szybkie kontrole detekcji

Sprawdź w CloudTrail nietypowe wywołania: RunInstances z DryRun, CreateServiceLinkedRole, CreateRole, RegisterTaskDefinition, CreateService, CreateLaunchTemplate, CreateAutoScalingGroup, ModifyInstanceAttribute (disableApiTermination=true), CreateFunctionUrlConfig (AuthType=NONE), AddPermission (principal="*"), tworzenie użytkowników i polityk SES.
W GuardDuty upewnij się, że masz Runtime Monitoring i Extended Threat Detection dla EC2/ECS.

3) Blokady prewencyjne (SCP/Config/CIEM)

Wdróż SCP zakazujące publicznych Lambda URL (FunctionUrlAuthType="NONE").
Wymuś image scanning i deny-listę podejrzanych rejestrów/obrazów dla ECS/Fargate.
Zablokuj możliwość ustawiania disableApiTermination poza procesem IR (np. przez SCP/Config Rules, reguły automatyczne). (Wniosek z analizy AWS).

4) Playbook reakcji (skrót)

Izoluj podejrzane instancje/klastry, cofnij disableApiTermination, terminuj workloady miningowe.
Rotuj wszystkie klucze i unieważnij sesje.
Przejrzyj SES (nadane uprawnienia, wysyłki), usuń publiczne Lambda URL/permissions.
Oceń koszty i wdróż budżety/limity + alerty kosztowe na poziomie kont i OU. (Zalecenia wprost/pośrednio z wpisu AWS).

Różnice / porównania z innymi przypadkami

W porównaniu z wcześniejszymi falami cryptojackingu w AWS, obecna kampania:

łączy wiele usług (ECS/Fargate + EC2) z agresywnym autoscalingiem,
wykorzystuje DryRun do cichej walidacji uprawnień,
utrudnia IR przez hurtowe disableApiTermination,
dobudowuje wektor phishingu (SES) i publiczne Lambda URL dla utrzymania obecności.
Te elementy razem składają się na bardziej dojrzałą metodykę nadużycia skradzionych poświadczeń w chmurze.

Podsumowanie / kluczowe wnioski

To nie jest „bug w AWS” – to nadużycie zaufanych poświadczeń i błędów procesowych.
Sekundy i minuty mają znaczenie: atak osiąga pełną moc kopania w ~10 min; bez automatyki koszt eskaluje wykładniczo.
Detekcja wzorca (DryRun, disableApiTermination, publiczne Lambda URL, SES Full Access, obrazy spoza zaufanych rejestrów) powinna być stałą regułą w SIEM/SOAR.
GuardDuty (ETD + Runtime) + MFA, SCP, least privilege to dziś must-have dla każdego konta/OU.

Źródła / bibliografia

AWS Security Blog – „Cryptomining campaign targeting Amazon EC2 and Amazon ECS” (16 grudnia 2025) – opis techniczny, IoC, rekomendacje. (Amazon Web Services, Inc.)
BleepingComputer – „Amazon: Ongoing cryptomining campaign uses hacked AWS accounts” (17 grudnia 2025) – podsumowanie i kontekst rynkowy. (BleepingComputer)
The Hacker News – „Compromised IAM Credentials Power a Large AWS Crypto Mining Campaign” (16 grudnia 2025) – dodatkowe szczegóły o DryRun, Lambda URL, SES. (The Hacker News)
Dark Reading – „Attackers Use Stolen AWS Credentials in Cryptomining Campaign” (17 grudnia 2025) – potwierdzenie ETD/GuardDuty i IoC. (Dark Reading)
The Record – „Cryptomining malware targeting AWS Lambda” (5 kwietnia 2022) – kontekst historyczny dot. wcześniejszych kampanii na AWS Lambda. (The Record from Recorded Future)

FBI rozbija domniemany serwis do prania pieniędzy dla grup ransomware (E-Note)

Wprowadzenie do problemu / definicja luki

Departament Sprawiedliwości USA poinformował o zakłóceniu działalności i przejęciu infrastruktury E-Note — internetowej usługi wymiany/kantoru kryptowalut, która miała umożliwiać pranie środków dla transnarodowych grup cyberprzestępczych, w tym operatorów ransomware. W sprawie oskarżono 39-letniego obywatela Rosji, Mykhailo (Mykhalio) Petrovicha Chudnovetsa, a amerykańskie i europejskie służby przejęły m.in. domeny i aplikacje mobilne powiązane z serwisem.

W skrócie

Skala: FBI zidentyfikowało ponad 70 mln USD przepływów związanych z atakami ransomware i przejęciami kont, obsłużonych przez E-Note od 2017 r.
Infrastruktura: zajęto serwery, aplikacje oraz domeny e-note.com, e-note.ws i jabb.mn.
Zarzuty: Chudnovets — konspiracja w celu prania pieniędzy (do 20 lat więzienia).
Partnerzy: działania koordynowane z BKA (Niemcy), NBI (Finlandia) i policją stanu Michigan.

Kontekst / historia / powiązania

Uderzenie w E-Note wpisuje się w szerszą kampanię przeciwko no-KYC/no-AML kryptousługom, które od lat służą do „cashoutu” zysków z cyberprzestępczości. Przypomnijmy: w 2024 r. BKA zamknęła 47 rosyjskojęzycznych serwisów wymiany bez KYC, a analizy pokazały ich centralną rolę w ekosystemie prania środków. Również FBI ostrzegało wcześniej przed korzystaniem z nierejestrowanych w USA „money services businesses” (MSB).

Analiza techniczna / szczegóły luki

Model działania: E-Note miało łączyć procesor płatności z siecią „money mules” (słupów) oraz konwersją krypto-fiat, oferując szybkie transfery transgraniczne i wypłaty gotówkowe — krytyczny krok do „wybielenia” okupów.
Artefakty infrastrukturalne: przejęto serwery, bazy klientów i rejestry transakcyjne, co może umożliwić wsteczne śledzenie przepływów i identyfikację klientów/pośredników.
Powiązania z ransomware: wg FBI przez usługę przepływały środki z ataków na ochronę zdrowia i infrastrukturę krytyczną (wskazuje to na użycie przez aktorów „big-game hunting”).
Brak KYC/AML: operacyjny charakter usługi wskazuje na obchodzenie reżimów KYC/AML, co czyniło ją atrakcyjną dla operatorów APT-crime i brokerów dostępu. FBI od 2024 r. podkreśla, że usługi MSB bez rejestracji/AML są sygnałem alarmowym.

Praktyczne konsekwencje / ryzyko

Ryzyko wtórne (exposure): firmy, które nieświadomie opłaciły odzysk lub współpracowały z zewnętrznymi „cashout” brokerami, mogą pojawić się w przejętych rejestrach klienta/operacji. To może skutkować pytaniami organów nadzoru i wymogiem audytu AML.
Retorsje cyberprzestępców: krótkoterminowo możliwa jest relokacja do innych no-KYC oraz wzrost opłat „cashout”. W przeszłości podobne takedowny prowadziły do migracji na mniejsze, bardziej rozproszone platformy.
Okazja śledcza: pełne bazy transakcyjne to szansa na atrybucję i recoup (odzysk środków) przy współpracy organów i podmiotów prywatnych analityki on-chain.

Rekomendacje operacyjne / co zrobić teraz

Blokady i detekcje
- Dodaj do blokad DNS/URL i EDR: e-note.com, e-note.ws, jabb.mn; przejrzyj proxy/DNS pod kątem historycznych wywołań.
- Uzupełnij reguły UEBA/SIEM o wykrywanie wzorców „cashout”: nietypowe przelewy na giełdy P2P/no-KYC, nagłe mikropłatności, rozbijanie kwot (structuring).
AML/KYC i zgodność
- Zweryfikuj dostawców „OTC/wykup okupu” pod kątem rejestracji MSB i programu AML — to wymóg regulacyjny w USA i dobry standard globalnie.
- Odśwież procedury zgodności z no-KYC exchange exposure; wykorzystaj listy ryzyka (np. zewnętrzne feedy analityki łańcuchów).
IR/Threat Intel
- Jeśli Twoja organizacja miała incydent z płatnością w krypto, przeprowadź retrospekcję transakcyjną (on-chain tracing) i kontakt z organami — FBI udostępniło dedykowany kanał dla potencjalnych ofiar E-Note.
- Zmapuj zależności z kampaniami ransomware celującymi w ochronę zdrowia i ICS; zaktualizuj playbooki DDoS-i-negocjacje na scenariusz „brak kanału cashout”.
Polityka płatności okupu
- Weryfikuj ryzyko sankcyjne/AML przed jakimikolwiek transferami — nierejestrowane MSB to czerwone światło i potencjalne naruszenie prawa.

Różnice / porównania z innymi przypadkami

W porównaniu z szerokimi operacjami (np. niemieckie zamknięcie 47 serwisów no-KYC w 2024 r.), sprawa E-Note to precyzyjny takedown pojedynczego węzła cashout, ale z wartością śledczą (pełne bazy klientów i transakcji).
Wspólny mianownik: brak KYC, szybkie swapy i „mosty” krypto-fiat — dokładnie te cechy, które analitycy uznają za „kręgosłup” prania środków z cyberprzestępczości.

Podsumowanie / kluczowe wnioski

Takedown E-Note to kolejny cios w ekosystem wyprowadzania okupów. Najważniejsze dla obrony: blokady znanych artefaktów, przegląd ekspozycji AML/KYC, oraz współpraca z organami w zakresie ewentualnych przepływów przez E-Note. Na poziomie rynku można oczekiwać dyspersji na mniejsze, bardziej ukryte usługi — warto więc budować detekcje behawioralne, a nie tylko listy domen.

Źródła / bibliografia

U.S. DOJ (Eastern District of Michigan): „FBI disrupts virtual money laundering service used to facilitate criminal activity” — komunikat, 17 grudnia 2025. (Department of Justice)
The Record / Recorded Future News: „FBI takes down alleged money laundering service for ransomware groups”, 17 grudnia 2025. (The Record from Recorded Future)
FBI IC3 PSA: „Alert on Cryptocurrency Money Services Businesses (MSB)”, 25 kwietnia 2024 — ostrzeżenia dot. nierejestrowanych usług. (ic3.gov)
Chainalysis: „German authorities seize Russian-centric no-KYC exchanges”, 25 września 2024 — tło nt. roli no-KYC w cyberpraniu. (Chainalysis)
The Record: „Germany shuts down 47 cryptocurrency exchange services used by cybercriminals”, 20 września 2024 — kontekst operacji BKA. (The Record from Recorded Future)

JumpCloud Remote Assist: luka CVE-2025-34352 umożliwia przejęcie systemu (Windows). Co muszą zrobić zespoły IT?

Wprowadzenie do problemu / definicja luki

W module JumpCloud Remote Assist dla Windows wykryto podatność CVE-2025-34352 (CVSS v4.0: 8.5 – High), która pozwala lokalnemu użytkownikowi o niskich uprawnieniach na eskalację uprawnień do SYSTEM oraz potencjalne przejęcie hosta podczas deinstalacji lub aktualizacji agenta. Błąd wynika z wykonywania uprzywilejowanych operacji na przewidywalnych plikach w katalogu %TEMP% bez odpowiedniej walidacji/ustawienia ACL. Problem dotyczy wersji Remote Assist < 0.317.0.

W skrócie

CVE-2025-34352 to lokalna eskalacja uprawnień (LPE) w JumpCloud Remote Assist (Windows), aktywowana przy uninstall/update agenta.
Atakujący może wymusić arbitrary file write/delete poprzez symbole dowiązań / punkty montowania, prowadząc do SYSTEM shell lub BSOD (np. zapis w System32\cng.sys).
Luka została załatana w Remote Assist 0.317.0; JumpCloud informuje, że klientów automatycznie podniesiono do 0.319.0 pod koniec października. Admini powinni zweryfikować wersję i polityki EDR/SIEM.

Kontekst / historia / powiązania

15 grudnia 2025: XM Cyber publikuje szczegóły techniczne i PoC-owe prymitywy ataku.
2 grudnia 2025: NVD publikuje rekord CVE; CNA: VulnCheck, z metryką CVSS 8.5.
16–17 grudnia 2025: SecurityWeek opisuje wpływ i otrzymuje komentarz JumpCloud (o masowej aktualizacji do 0.319.0 wykonanej „pod koniec października”).

Analiza techniczna / szczegóły luki

Źródło problemu. Podczas odinstalowania/aktualizacji JumpCloud Agent (działającego jako NT AUTHORITY\SYSTEM) wywoływany jest deinstalator Remote Assist, który wykonuje tworzenie, zapis, kasowanie i uruchamianie plików o przewidywalnych nazwach w podkatalogu %TEMP% (np. ~nsuA.tmp\Un_A.exe, ~nsu.tmpA\Un_*.exe) bez resetu ACL i bez walidacji zaufania ścieżki. To klasyczne błędy CWE-59 (link following) i CWE-378 (insecure temp).

Prymitywy eksploatacji.

Arbitrary file write: montowanie/namespace Object Manager + linki symboliczne → przekierowanie zapisu SYSTEM do plików chronionych (np. sterownik cng.sys) → BSOD/DoS.
Arbitrary delete → LPE: wyścig TOCTOU na DeleteFileW() do usunięcia/ podmiany zawartości Config.Msi, a następnie znane techniki Windows Installer LPE do uzyskania SYSTEM shell.

Zakres wersji i komponent. Podatność dotyczy Remote Assist < 0.317.0 w środowiskach, w których komponent jest instalowany i zarządzany w cyklu życia Agenta.

Praktyczne konsekwencje / ryzyko

Przejęcie endpointu: lokalny user (lub malware już obecne na stacji) może podnieść uprawnienia do SYSTEM i utrwalić się.
Zakłócenie usług: możliwe BSOD poprzez nadpisanie krytycznych plików systemowych.
Wpływ łańcuchowy: komponent jest powszechny w środowiskach JumpCloud; atak na jedno stanowisko ułatwia ruch boczny i eskalację domenową.
Okno ataku przy maintenance: trigger następuje w trakcie uninstall/update, więc okna serwisowe lub masowe aktualizacje to momenty szczególnie wrażliwe.

Rekomendacje operacyjne / co zrobić teraz

Zweryfikuj wersję Remote Assist na wszystkich Windowsach:
- Wymagane: ≥ 0.317.0 (XM Cyber/NVD) — JumpCloud podaje, że klientów zaktualizowano do 0.319.0 pod koniec października 2025; sprawdź, czy to faktycznie nastąpiło w Twojej flocie.
Wymuś aktualizację agenta/komponentów JumpCloud w MDM/patch management i raportuj niezgodności (compliance).
Twarde zasady dla ścieżek tymczasowych:
- Monitoruj tworzenie/wykonywanie plików w %TEMP%\~nsuA.tmp i %TEMP%\~nsu.tmpA.
- W EDR utwórz reguły dla podejrzanych sekwencji CreateFile/WriteFile/CreateProcess przez procesy powiązane z deinstalatorem Remote Assist. (IOC/behavioural).
Kontrola czasu aktualizacji: ogranicz uprawnienia lokalnych użytkowników i zablokuj interaktywne logowanie w oknach maintenance, aby utrudnić wyścigi/TOCTOU.
Higiena uprawnień: egzekwuj least privilege, audytuj członkostwa lokalnych grup, włącz WDAC/Credential Guard gdzie to możliwe.
Myśl o klasie błędu: w ocenie dostawców wymagaj, by uprzywilejowane procesy nie operowały na katalogach użytkownika (np. %TEMP%) bez jawnego ustawienia ACL oraz walidacji ścieżek.

Różnice / porównania z innymi przypadkami

Ta luka jest kolejnym przykładem LPE przez niebezpieczne operacje w katalogu tymczasowym z udziałem deinstalatorów/aktualizatorów. W odróżnieniu od niektórych wcześniejszych przypadków (np. typowe DLL hijacking), tutaj kluczowe są linki symboliczne/mount pointy i wyścig DeleteFileW(), co umożliwia zarówno DoS przez arbitralny zapis, jak i LPE przez arbitralne kasowanie + MSI. To zwiększa prawdopodobieństwo sukcesu w realnych warunkach utrzymaniowych.

Podsumowanie / kluczowe wnioski

Zaktualizuj Remote Assist do ≥ 0.317.0 (docelowo 0.319.0, jeśli dostępne w Twojej flocie) i potwierdź zgodność na wszystkich hostach.
Dodaj detekcje EDR dla sekwencji tworzenia/wykonywania plików w %TEMP%\~nsu* przez procesy instalatorów/deinstalatorów JumpCloud.
Zabezpiecz okna serwisowe i minimalizuj powierzchnię ataku lokalnego użytkownika.
Traktuj tę podatność jako sygnał kontrolny dla wszystkich narzędzi z uprawnieniami SYSTEM — żadnych uprzywilejowanych operacji w katalogach użytkownika.

Źródła / bibliografia

SecurityWeek — „JumpCloud Remote Assist Vulnerability Can Expose Systems to Takeover” (16–17 grudnia 2025, z oświadczeniem JumpCloud o auto-aktualizacji do 0.319.0). (SecurityWeek)
NVD — wpis CVE-2025-34352 (opis, CVSS 8.5, zakres wersji < 0.317.0, CWE-59/378). (NVD)
XM Cyber — „JUMPSHOT: … LPE (CVE-2025-34352) in JumpCloud Agent” (analiza techniczna, prymitywy, ścieżki %TEMP%). (XM Cyber)
VulnCheck Advisory — „JumpCloud Remote Assist < 0.317.0 Arbitrary File Write/Delete…” (daty, CVSS 8.5, zakres wersji). (VulnCheck)
JumpCloud — strona produktu Remote Assist (kontekst funkcjonalny). (JumpCloud)

Uwaga redakcyjna: w źródłach pojawiają się dwie wartości „naprawczych” wersji: 0.317.0 (NVD, XM Cyber, VulnCheck) oraz informacja JumpCloud o automatycznej aktualizacji do 0.319.0 (oświadczenie dla SecurityWeek). W materiałach operacyjnych zalecamy minimalny próg zgodności: 0.317.0, z preferencją 0.319.0, jeśli jest dostępna w Twojej flocie.

Amazon: rosyjscy hakerzy coraz częściej wykorzystują błędne konfiguracje urządzeń brzegowych w atakach na infrastrukturę krytyczną

Wprowadzenie do problemu / definicja luki

Amazon Threat Intelligence (ATI) opisał kampanię GRU (klaster powiązany z Sandworm/APT44), która w latach 2021–2025 ewoluowała od intensywnej eksploatacji 0-day/n-day do nadużywania błędnie skonfigurowanych urządzeń brzegowych (edge) — zwłaszcza takich z ujawnionymi interfejsami zarządzania. Z przejętych urządzeń atakujący przechwytywali ruch (pcap), pozyskiwali poświadczenia i odtwarzali je (credential replay) w usługach online ofiar w celu ruchu bocznego i utrzymania dostępu. Amazon podkreśla, że obserwowane przypadki dotyczyły urządzeń klientów hostowanych na AWS i wynikały z błędnych konfiguracji klientów, a nie słabości AWS.

W skrócie

Taktyczna zmiana: mniej exploitów, więcej polowania na „low-hanging fruit” — źle skonfigurowane routery, koncentratory VPN, bramki zdalnego dostępu, platformy kolaboracyjne i systemy zarządzania projektami.
Metoda: kompromitacja urządzenia → pasywny packet capture → kradzież poświadczeń → próby logowania (replay) do usług organizacji → lateral movement.
Sektory: nacisk na energetykę i infrastrukturę krytyczną w Ameryce Płn. i Europie; ofiary z infrastrukturą sieciową w chmurze.
Atrybucja: wysoka pewność powiązania z Sandworm/APT44 (znany klaster GRU).

Kontekst / historia / powiązania

Do 2024 r. ten sam aktor chętnie wykorzystywał znane luki m.in. w WatchGuard (CVE-2022-26318), Atlassian Confluence (CVE-2021-26084, CVE-2023-22518) czy Veeam (CVE-2023-27532). W 2025 r. Amazon odnotował spadek wykorzystania podatności na rzecz systematycznego atakowania błędnych konfiguracji urządzeń brzegowych. Równolegle zidentyfikowano nakładanie się infrastruktury z grupą określaną przez Bitdefender jako „Curly COMrades” — znaną z post-eksploatacji i ukrywania się w maszynach wirtualnych Hyper-V (CurlyShell, CurlCat).

Niezależne redakcje (CyberScoop, CSO Online) potwierdzają wątki: przejęcie urządzenia brzegowego, przechwytywanie ruchu w celu kradzieży poświadczeń i credential replay do usług ofiary.

Analiza techniczna / szczegóły luki

Punkt startowy (Initial Access)

Urządzenia brzegowe klientów z odsłoniętymi interfejsami zarządzania (HTTP/HTTPS, SSH, Telnet, SNMP) lub z domyślnymi/ponownie użytymi hasłami.
Często dotyczy instancji w chmurze (np. obrazy/appliance’y na EC2), gdzie konfiguracja sieciowa lub reguły SG/NACL dopuszczają dostęp z Internetu.

Zbieranie poświadczeń (Collection)

Wskazania czasowe i wzorzec użycia haseł sugerują pasywną inspekcję ruchu (packet capture) na skompromitowanych urządzeniach; atakujący pozyskują poświadczenia domenowe ofiary, nie tylko konta urządzeń.

Użycie poświadczeń (Credential Replay) i ruch boczny

Próby uwierzytelnienia do usług SaaS/IDP, repozytoriów kodu, platform kolaboracyjnych, portali administracyjnych, często z nietypowych geolokalizacji i z opóźnieniem (charakterystycznym dla zbioru pcap).

Przykładowe CVE z wcześniejszych faz kampanii

WatchGuard CVE-2022-26318; Confluence CVE-2021-26084 i CVE-2023-22518; Veeam CVE-2023-27532.

IOCs i telemetry

Amazon udostępnił przykładowe adresy IP (kompromitowane legalne serwery wykorzystywane jako proxy/staging). Zaleca analizę kontekstową zamiast ślepego blokowania.

Praktyczne konsekwencje / ryzyko

Ataki bez głośnych exploitów: trudniejsze do detekcji, bo wyglądają jak „normalna” administracja urządzeniem lub legalny ruch.
Przenikalność IT–OT: poświadczenia wykradzione na brzegu mogą otwierać drogę do systemów OT/ICS (np. przez skojarzone konta domenowe lub jump-hosty). Analizy ENISA i innych ośrodków pokazują, że kradzież poświadczeń pozostaje kluczowym elementem łańcucha ataku.
Skala sektorowa: energetyka, telekomunikacja, dostawcy usług chmurowych i MSP obsługujące podmioty infrastruktury krytycznej — ryzyko efektu łańcuchowego.

Rekomendacje operacyjne / co zrobić teraz

1) Higiena urządzeń brzegowych (priorytet wysoki)

Audyt ekspozycji: zinwentaryzuj wszystkie interfejsy zarządzania; przenieś je do prywatnych podsieci i zabezpiecz dostępem przez bastion/VPN z MFA. Zablokuj Telnet/HTTP/niezaszyfrowane SNMP.
Twarde uwierzytelnianie: rotacja haseł, unikalne konta admin, MFA wszędzie tam, gdzie to możliwe.
Konfiguracja sieci: reguły SG/NACL o najmniejszej potrzebnej przepustowości, VPC Flow Logs do analizy anomalii.

2) Detekcja credential replay

Koreluj logi uwierzytelniania pod kątem ponownego użycia poświadczeń między panelami zarządzania urządzeń a usługami SaaS/IDP; alertuj na logowania z nietypowych geolokalizacji oraz na próby po opóźnieniu po incydencie na urządzeniu.

3) Telemetria i EDR/SIEM

Szukaj śladów packet capture na urządzeniach (pliki pcap, uruchomione narzędzia tcpdump/pcapd).
W środowiskach Windows monitoruj Hyper-V enable/VM import/start — to TTP łączone z „Curly COMrades” (ukryty VM z implantami).

4) Twardnienie w AWS

IAM przez federację + role, GuardDuty, CloudTrail, Amazon Inspector do wykrywania niezamierzonej ekspozycji i luk, segmentacja zarządzania w VPC.

5) Reagowanie na IOCs

Weryfikuj adresy IP z listy ATI kontekstowo; mogą to być przejęte legalne hosty. Zastosuj TLS-only dla paneli, wyłącz legacy-crypto, loguj całość administracji.

Różnice / porównania z innymi przypadkami

W odróżnieniu od fali kampanii 2021–2024 opartej o szybkie „n-day smash-and-grab”, obecne operacje preferują trwałość i niski profil: infiltracja przez misconfig, pasywny zbiór poświadczeń, a następnie replay do usług chmurowych/SaaS. To bardziej „kontrolowane” i mniej hałaśliwe niż masowe skanowanie pod CVE. Relacje AWS i niezależnych redakcji spójnie wskazują na taki pivot taktyczny.

Podsumowanie / kluczowe wnioski

Dla operatorów OT/ICS i dostawców usług to alarm na konfigurację edge: interfejsy zarządzania muszą zniknąć z Internetu.
Detekcja credential replay powinna być stałym use case’em w SIEM i systemach tożsamości.
Segmentacja, MFA, monitoring i twardnienie w chmurze minimalizują okno nadużyć nawet przy błędach konfiguracyjnych.
Zmiana taktyk Sandworm/APT44 nie zmniejsza ryzyka — przeciwnie, utrudnia wykrycie i skraca czas do celu.

Źródła / bibliografia

AWS Security Blog: Amazon Threat Intelligence identifies Russian cyber threat group targeting Western critical infrastructure (15 grudnia 2025). (Amazon Web Services, Inc.)
SecurityWeek: Amazon: Russian Hackers Now Favor Misconfigurations in Critical Infrastructure Attacks (16 grudnia 2025). (SecurityWeek)
CyberScoop: Amazon warns that Russia’s Sandworm has shifted its tactics (16 grudnia 2025). (CyberScoop)
CSO Online: Russian APT group pivots to network edge device misconfigurations (16 grudnia 2025). (CSO Online)
Bitdefender Labs: Curly COMrades: Evasion & Persistence via Hidden Hyper-V Virtual Machines (4 listopada 2025). (Bitdefender)

AI Kontra Pentesterzy – Lekcje Z Badania Stanford 2025

Dlaczego to ma znaczenie

Rosnące zdolności sztucznej inteligencji (AI) wywołują pytania o jej wpływ na bezpieczeństwo – zarówno pozytywny, jak i negatywny. Najnowsze raporty wskazują, że zaawansowane grupy atakujące (od cyberprzestępców po aktorów państwowych) już zaczynają wykorzystywać AI w operacjach ofensywnych. W odpowiedzi liderzy branży (np. OpenAI, Anthropic) uwzględniają ryzyko cyber w swoich zasadach bezpieczeństwa AI. Skoro napastnicy testują AI jako broń, obrońcy muszą zrozumieć, na co stać takie systemy – jak wypadają one na tle żywych pentesterów?

Czytaj dalej

JLR potwierdza kradzież danych pracowników po cyberataku: co wiemy i co robić teraz

Wprowadzenie do problemu / definicja luki

Jaguar Land Rover (JLR) potwierdził, że w wyniku cyberataku z końca sierpnia 2025 r. doszło do kompromitacji danych aktualnych i byłych pracowników oraz kontraktorów. Firma informuje, że kontaktuje się z osobami objętymi naruszeniem i udostępnia im pomoc oraz monitoring tożsamości. To pierwsze tak jednoznaczne potwierdzenie kradzieży danych po wielotygodniowej przerwie produkcyjnej jesienią 2025 r.

W skrócie

Zakres danych: informacje kadrowo-płacowe używane do obsługi payrollu, świadczeń i programów pracowniczych; media wskazują m.in. na dane adresowe, wynagrodzenia i numery ubezpieczenia (National Insurance).
Linia czasu: atak rozpoczął się 31 sierpnia 2025 r., a produkcja była wstrzymywana/ograniczana przez wiele tygodni we wrześniu i październiku.
Wpływ biznesowy: straty i koszty przestoju skłoniły rząd UK do gwarancji pożyczki ~£1,5 mld w celu ochrony łańcucha dostaw.
Status śledztwa: JLR nie potwierdził publicznie typu ataku (ransomware nie zostało oficjalnie wskazane), trwa dochodzenie i współpraca z regulatorami.

Kontekst / historia / powiązania

We wrześniu 2025 r. JLR wstrzymywał produkcję w zakładach m.in. Halewood, Solihull i Wolverhampton, a pracownikom nakazano pozostanie w domach. Skala przestoju uderzyła w tysiące firm w łańcuchu dostaw motoryzacji. Rząd podjął interwencję finansową, a według „Financial Times” decyzję o gwarancji kredytowej podjęto mimo zastrzeżeń urzędników ze względu na ryzyko systemowe dla branży.

Analiza techniczna / szczegóły luki

JLR nie ujawnił szczegółów technicznych. Na podstawie dotychczasowych komunikatów i relacji mediów można odtworzyć możliwy profil incydentu:

Domena uderzenia: systemy back-office (HR/payroll) oraz systemy produkcyjne (OT/IT) były co najmniej pośrednio dotknięte – wskazuje na to jednoczesny wyciek danych pracowniczych i długotrwały przestój.
Potencjalny wektor: brak oficjalnego potwierdzenia. W doniesieniach prasowych przewijały się hipotezy o gangu z anglojęzycznej sceny cyberprzestępczej i możliwym komponencie ransomware, jednak JLR tego nie potwierdził – ostrożność interpretacyjna jest wskazana.
Ekspozycja danych: z korespondencji do pracowników wynika, że naruszone były rekordy potrzebne do obsługi płac i świadczeń. Tego typu systemy zwykle przechowują: identyfikatory, adresy, dane zatrudnienia, numery NI, bankowe referencje płacowe, dane o osobach pozostających na utrzymaniu – zakres może się różnić w zależności od modułu i integracji. (Na tę chwilę brak pełnej, publicznej listy pól od JLR).

Praktyczne konsekwencje / ryzyko

Dla osób, których dane wyciekły:

Podwyższona ekspozycja na phishing i socjotechnikę (np. fałszywe „aktualizacje payroll”, „weryfikacje benefitów” czy kradzież zwrotów podatkowych).
Ryzyko kradzieży tożsamości i nadużyć kredytowych (wyciek danych PII + danych finansowych zwiększa ryzyko skutecznego wniosku kredytowego).

Dla firm w łańcuchu dostaw:

Zakłócenia płatności i planowania produkcji (efekt domina); część dostawców wymagała wsparcia pomostowego.
Możliwe wtórne kampanie phishingowe podszywające się pod JLR/partnerów (np. aktualizacje kont bankowych, „pilne” zmiany zleceń).

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów JLR i dostawców (CISO/CIO/BCM/OT):

Segmentacja i EDR/XDR na styku IT/OT; weryfikacja dostępu serwisowego do linii produkcyjnych; pełny review reguł w SIEM pod kątem TTP wykorzystywanych w atakach na automotive (żywe z ziemi, kradzież sesji, kradzież M365/OAuth).
Zamrożenie i rotacja sekretów (klucze API, tokeny integracyjne HR/payroll, SFTP do banków, integracje z benefitami).
DLP + klasyfikacja dla repozytoriów HR (chmurowych i on-prem); wymuś fine-grained access (JIT/JEA) i monitoruj masowe eksporty.
Tabletop + runbooki: scenariusze „payroll breach”, „supplier payment diversion”, „production OT restart” (z checklistami komunikacji do regulatorów i pracowników).

Dla osób, których dane mogły wyciec:

Załóż monitoring kredytowy/ID i alerty w biurach kredytowych (JLR deklaruje wsparcie).
Włącz MFA we wszystkich usługach powiązanych z pocztą prywatną i bankowością; uważaj na SMS/voice phishing.
Zgłaszaj podejrzane próby „aktualizacji konta płacowego” do działu HR – nie klikaj w linki z wiadomości.

Dla partnerów biznesowych:

Potwierdzaj zmiany kont bankowych kanałem out-of-band.
Korzystaj z listy dozwolonych domen i DKIM/DMARC w komunikacji z JLR.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

Na tle innych incydentów w motoryzacji ten przypadek wyróżnia:

Długotrwały wpływ na produkcję (kilka tygodni), rzadko spotykany w UK w tej skali.
Bezprecedensową interwencję finansową rządu dla stabilizacji łańcucha dostaw (gwarancja £1,5 mld).

Podsumowanie / kluczowe wnioski

JLR potwierdził kradzież danych pracowników/kontraktorów z systemów HR/payroll po cyberataku z sierpnia 2025 r. – to przesuwa akcent z „samego przestoju” na długofalowe ryzyko PII/ID.
Skala operacyjna incydentu wymusiła interwencję państwa; podobne łańcuchy dostaw muszą planować resilience nie tylko na wypadek awarii OT, ale też wycieku danych back-office.
Organizacje powinny wdrożyć kontrole wokół payroll/HR (DLP, rotacja sekretów, hardening integracji z bankami/benefitami) i programy anty-phishingowe ukierunkowane na pracowników oraz działy kadr.

Źródła / bibliografia

The Record (Recorded Future News): potwierdzenie kradzieży danych pracowniczych (15 grudnia 2025). (The Record from Recorded Future)
The Register: doniesienia o zakresie „payroll data” (15 grudnia 2025). (The Register)
The Guardian: przestój produkcji i interwencja rządu (wrzesień 2025). (The Guardian)
AP News: decyzje o kontynuacji wstrzymania produkcji, wpływ branżowy (wrzesień/październik 2025). (AP News)
Financial Times: szczegóły gwarancji pożyczki i kontekst rządowy (październik 2025). (Financial Times)