Archiwa: Admin - Strona 17 z 33 - Security Bez Tabu

Tag: Admin

Fortinet: krytyczne obejścia uwierzytelniania już wykorzystywane. Co musisz zrobić teraz

Wprowadzenie do problemu / definicja luki

Atakujący rozpoczęli masowe nadużywanie dwóch krytycznych podatności obejścia uwierzytelniania w produktach Fortinet (FortiOS, FortiWeb, FortiProxy i FortiSwitchManager), które pozwalają ominąć FortiCloud SSO poprzez spreparowaną odpowiedź SAML. Pierwsze oznaki włamań odnotowano zaledwie kilka dni po wydaniu poprawek 9 grudnia 2025 r. (CVE-2025-59718, CVE-2025-59719).

W skrócie

  • Co się dzieje: aktywne logowania SSO do FortiGate’ów z adresów dostawców hostingu, a następnie eksport konfiguracji urządzeń.
  • Dotyczy: FortiOS, FortiWeb, FortiProxy, FortiSwitchManager – tylko gdy włączone jest FortiCloud SSO (domyślnie wyłączone; może zostać włączone podczas rejestracji FortiCare w GUI).
  • Wersje naprawione: m.in. FortiOS 7.6.4 / 7.4.9 / 7.2.12 / 7.0.18, FortiProxy 7.6.4 / 7.4.11 / 7.2.15 / 7.0.22, FortiSwitchManager 7.2.7 / 7.0.6, FortiWeb 8.0.1 / 7.6.5 / 7.4.10.
  • Status KEV: CVE-2025-59718 dodane do katalogu CISA KEV 16 grudnia 2025 r. z terminem remediacji do 23 grudnia (dla agencji FCEB w USA).

Kontekst / historia / powiązania

Fortinet regularnie znajduje się na linii ognia kampanii wymierzonych w interfejsy zarządzania firewallami/VPN. Tym razem czas między publikacją łat (9 grudnia) a wykryciem realnych ataków (12 grudnia) był wyjątkowo krótki — 3 dni, co potwierdza dojrzałość przeciwników w szybkim weaponizowaniu świeżych biuletynów.

Analiza techniczna / szczegóły luki

Obie podatności (CVSS do 9.8) wynikają z niewłaściwej weryfikacji podpisu kryptograficznego w przepływie SAML dla FortiCloud SSO:

  • CVE-2025-59718 (FortiOS / FortiProxy / FortiSwitchManager): atakujący bez uwierzytelnienia mogą odesłać spreparowaną odpowiedź SAML i uzyskać dostęp administracyjny przez SSO.
  • CVE-2025-59719 (FortiWeb): analogiczny błąd w FortiWeb (linie 7.4.x, 7.6.x, 8.0.0).

Warunek: FortiCloud SSO musi być włączone (nie jest domyślnie). Rejestracja urządzenia w FortiCare poprzez GUI może automatycznie aktywować opcję „Allow administrative login using FortiCloud SSO”, jeśli admin jej nie wyłączy.

Artefakty ataku (wg Arctic Wolf):

  • logowania SSO na konto admin z puli znanych dostawców hostingu,
  • po udanym logowaniu – eksport konfiguracji przez GUI (konfiguracje zawierają hashe haseł).

Praktyczne konsekwencje / ryzyko

  • Przejęcie panelu admina bez poświadczeń lokalnych (pełne uprawnienia).
  • Wykradzenie konfiguracji → łamanie hashy offline → wtórne kompromitacje (VPN, konta administratorów).
  • Szybka mobilizacja botnetów/aktorów skanujących internet pod kątem interfejsów zarządzania Fortinet.

Rekomendacje operacyjne / co zrobić teraz

  1. Zainstaluj poprawki bezzwłocznie do wersji:
    • FortiOS: 7.6.4 / 7.4.9 / 7.2.12 / 7.0.18 lub nowszych,
    • FortiProxy: 7.6.4 / 7.4.11 / 7.2.15 / 7.0.22 lub nowszych,
    • FortiSwitchManager: 7.2.7 / 7.0.6 lub nowszych,
    • FortiWeb: 8.0.1 / 7.6.5 / 7.4.10 lub nowszych.
  2. Jeśli patchowanie chwilowo niemożliwe – wyłącz FortiCloud SSO:
    • GUI: System → Settings → przełącz Allow administrative login using FortiCloud SSO na Off.CLI:config system global set admin-forticloud-sso-login disable end
    (i analogicznie w FortiWeb/FortiProxy, jeśli dotyczy).
  3. Ogranicz dostęp do interfejsów zarządzania wyłącznie z sieci zaufanych (ACL/VPN/jump host), wyłącz ekspozycję do internetu.
  4. Przeprowadź hunting/IR pod kątem nadużyć SSO:
    • Szukaj w logach zdarzeń udanych logowań SSO na konto admin z nietypowych IP; artefakty w stylu ui="sso(<IP>)" oraz wpisów o pobraniu konfiguracji przez GUI.
    • W przypadku wykrycia anomalii: reset haseł wszystkich kont na urządzeniu (i powiązanych usług), unieważnienie kluczy, przegląd zasad.
  5. Zweryfikuj zgodność z KEV (jeśli podlegasz wymogom): CVE-2025-59718 na liście KEV z deadline 2025-12-23.

Różnice / porównania z innymi przypadkami

  • W odróżnieniu od wielu wcześniejszych kampanii na Fortinet (RCE, path traversal), tutaj nie trzeba exploitować kodu wykonawczego – wystarcza bypass SAML/SSO. To zmienia wektor z „klasycznego RCE” na kradzież i nadużycie tożsamości usługowej w samym punkcie logowania.
  • Czas weaponizacji (3 dni) jest podobny do trendów obserwowanych przy głośnych kampaniach na interfejsy zarządzania (krótka półka życia poradnika → szybkie skanowanie → masowe logowania).

Podsumowanie / kluczowe wnioski

  • Dwie krytyczne luki SAML w FortiCloud SSO są aktywnie wykorzystywane – priorytetem jest aktualizacja i wyłączenie SSO tam, gdzie nie jest niezbędne.
  • Wykryto realne loginy admin i eksporty konfiguracji; traktuj wszelkie wycieki konfigów jak kompromitację poświadczeń.
  • Sprawdź zgodność z CISA KEV i terminy remediacji, nawet jeśli Twoja organizacja nie jest FCEB – to sensowny wskaźnik priorytetu ryzyka.

Źródła / bibliografia

  • SecurityWeek – In-the-Wild Exploitation of Fresh Fortinet Flaws Begins (16 grudnia 2025) – potwierdzenie exploitacji, wersje z poprawkami. (SecurityWeek)
  • SecurityWeek – Fortinet Patches Critical Authentication Bypass Vulnerabilities (10 grudnia 2025) – tło, stan domyślny SSO, wpływ produktów. (SecurityWeek)
  • Arctic Wolf – Observes Malicious SSO Logins… (15 grudnia 2025) – IoC, przykładowe logi, zalecenia, polecenia CLI. (Arctic Wolf)
  • NVD – CVE-2025-59718 – opis techniczny, zakres wersji, adnotacja o dodaniu do CISA KEV i terminie 2025-12-23. (NVD)
  • NVD – CVE-2025-59719 – opis techniczny dla FortiWeb, CVSS. (NVD)

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

  1. AWS Security Blog: Amazon Threat Intelligence identifies Russian cyber threat group targeting Western critical infrastructure (15 grudnia 2025). (Amazon Web Services, Inc.)
  2. SecurityWeek: Amazon: Russian Hackers Now Favor Misconfigurations in Critical Infrastructure Attacks (16 grudnia 2025). (SecurityWeek)
  3. CyberScoop: Amazon warns that Russia’s Sandworm has shifted its tactics (16 grudnia 2025). (CyberScoop)
  4. CSO Online: Russian APT group pivots to network edge device misconfigurations (16 grudnia 2025). (CSO Online)
  5. 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 „AI Kontra Pentesterzy – Lekcje Z Badania Stanford 2025”

SantaStealer: nowy infostealer (MaaS), który kradnie dane z przeglądarek i portfeli krypto

Wprowadzenie do problemu / definicja luki

SantaStealer to nowy information stealer oferowany w modelu Malware-as-a-Service (MaaS), reklamowany na Telegramie i rosyjskojęzycznych forach cyberprzestępczych. Według pierwszych analiz, celem jest kradzież haseł, cookies, historii i kart płatniczych z przeglądarek, danych komunikatorów (Telegram, Discord), kont gamingowych (Steam), portfeli kryptowalut i dokumentów. Operatorzy przedstawiają go jako narzędzie działające w pamięci (fileless) i trudne do wykrycia, choć obecne próbki na to nie wskazują.

W skrócie

  • Model biznesowy: subskrypcja „Basic” $175/mies. i „Premium” $300/mies.; panel afiliacyjny z konfiguracją buildu.
  • Pochodzenie / branding: rebranding z BluelineStealer; kanały dystrybucji i marketingu na Telegramie i forum Lolz.
  • Modułowość: 14 wątków-modułów zbierających różne kategorie danych; zrzut do ZIP-a i wysyłka w kawałkach po 10 MB na C2 po HTTP (port 6767).
  • Obejście App-Bound Encryption (ABE): do odszyfrowania haseł/kart w Chromium wykorzystuje dołączony „ChromeElevator” (post-exploitation), bazujący na publicznym projekcie badawczym.
  • Anty-analiza: w obecnych próbkach prymitywna; twierdzenia o pełnej niewykrywalności przesadzone.
  • Status (16 grudnia 2025, Europa/Warszawa): Rapid7 odnotował komunikat na oficjalnym kanale o wydaniu stealer’a — można spodziewać się kampanii „in the wild”.

Kontekst / historia / powiązania

Rapid7 wskazuje, że SantaStealer to świeżo rebrandowany projekt BluelineStealer, który intensywnie promowano w grudniu 2025 r. w kanałach Telegram i na Lolz. Składnia panelu, domena z TLD .su oraz opcja nieatakowania państw CIS sugerują rosyjską przynależność operatorów (wzorzec typowy dla ekosystemu infostealerów).

Analiza techniczna / szczegóły luki

Architektura i uruchomienie. Zidentyfikowane próbki (EXE/DLL x64) mają bogaty zestaw eksportowanych symboli i niezaszyfrowane ciągi znaków, co ułatwiło inżynierię wsteczną. W konfiguracji wbudowanej w plik znajdują się m.in. parametry anti_cis, exec_delay_seconds i „watermark” z odnośnikiem do Telegrama.

Moduły zbierające dane (14 wątków). Każdy moduł działa w osobnym wątku i zapisuje artefakty w pamięci; po ~45 s zebrane pliki są pakowane do Log.zip w katalogu TEMP. Zbierane kategorie obejmują m.in.:

  • przeglądarki (hasła, cookies, karty, historia),
  • Telegram, Discord, Steam,
  • rozszerzenia przeglądarek i portfele krypto,
  • dokumenty i screenshoty.

Exfiltracja. ZIP dzielony jest na 10-megabajtowe części i wysyłany na sztywno zakodowany adres C2 po HTTP (endpoint /upload, port 6767) z nagłówkami auth (ID buildu) i w (tag kampanii). Brak szyfrowania transmisji.

Obejście ABE w Chromium. Aby ominąć App-Bound Encryption (wprowadzone w 2024 r.), SantaStealer uruchamia dołączony „ChromeElevator” — osobny EXE, który odszyfrowuje i ładuje w pamięci DLL; następnie przeprowadza reflective hollowing i działa w kontekście procesu przeglądarki, co pozwala wyciągać klucze ABE i odszyfrowywać hasła/karty. Rapid7 wskazuje, że komponent ten jest „silnie oparty” na publicznym repozytorium badawczym ChromElevator.

Anty-VM / anty-analiza. Sprawdzenia obejmują m.in. listy procesów, czas pracy systemu, usługę VBoxGuest, ścieżki typu C:\analysis\... i proste kontrole debuggera; w razie wykrycia — zakończenie pracy. Obecne techniki oceniono jako elementarne.

Praktyczne konsekwencje / ryzyko

  • Ryzyko masowych wycieków danych dostępowych i sesyjnych z Chromium (obejście ABE) — szybkie przejęcia kont SSO, SaaS, poczty i bankowości.
  • Kradzież środków z portfeli krypto oraz nadużycia w grach/marketplace’ach (Steam).
  • Szybkie TTV (time-to-value) dla afiliantów dzięki gotowemu panelowi, builderowi i tagowaniu kampanii, co ułatwia skalowanie operacji.
  • Fałszywe poczucie stealth — mimo marketingu „fileless/UD”, obecne próbki są wykrywalne; jednak spodziewana ewolucja może utrudnić detekcję (szyfrowanie configu, obfuskacja).

Rekomendacje operacyjne / co zrobić teraz

Prewencja

  1. Blokada wektorów wejścia: egzekwuj politykę no-install/no-admin, blokuj uruchamianie z %Temp% i katalogów użytkownika; w przeglądarkach wyłącz instalację niezatwierdzonych rozszerzeń.
  2. Hardening przeglądarek: wdrażaj profile MDM/ADMX (Chromium/Edge), wyłącz eksport haseł, wymuś hardware-bound encryption i izolację profili.
  3. Filtry treści i kampanii „ClickFix”: blokuj paste-bin/skracacze, domeny malvertising; szkol użytkowników przeciw „wklej to w PowerShell”.

Detekcja

  1. Sieć: reguły na HTTP do nieszyfrowanych IP:6767 oraz ruch multipart z nagłówkami User-Agent: upload, auth, w; alertuj na dzielenie plików po 10 MB.
  2. Host:
    • monitoruj tworzenie Log.zip w %TEMP% i nietypowe procesy potomne przeglądarek;
    • wykrywaj reflective hollowing/dołączanie DLL do procesów Chrome/Edge/Brave;
    • poluj na artefakt „CIS” oraz wywołania GetKeyboardLayoutList tuż przed zakończeniem procesu (heurystyka anti-CIS).
  3. IoC/IoA: wykorzystaj opublikowane przez Rapid7 skróty SHA-256 (próbki DLL/EXE) i wzorce zachowań do proaktywnych polowań.

Reagowanie

  1. Izolacja i triage: po wykryciu — izoluj host, zrzut pamięci procesu przeglądarki (na potrzeby artefaktów ChromeElevator).
  2. Reset sekretów: reset haseł i unieważnienie cookies/sesji (SaaS, e-mail, komunikatory); rotacja tokenów API.
  3. Higiena przeglądarek: usuń zainfekowane profile, wymuś ponowną rejestrację WebAuthn/2FA, włącz re-challenge po zmianie urządzenia.
  4. Threat intel: subskrybuj feedy (np. z platformy Rapid7) i aktualizuj reguły XDR/EDR pod kątem nowych wariantów.

Różnice / porównania z innymi przypadkami

  • Lumma/Vidar/RedLine: podobny cel (kradzież przeglądarek/portfeli), ale SantaStealer wyróżnia nacisk na obejście ABE w Chromium poprzez wbudowany komponent typu ChromeElevator. Starsze stealer’y często opierały się na DPAPI/cookie-graberach — ABE znacząco utrudniło im życie; SantaStealer nadrabia to techniką in-memory w kontekście przeglądarki.
  • Poziom „stealth”: marketing SantaStealer deklaruje „UD/polymorphic C engine”, ale analiza wskazuje na ubogie anty-analizy w obecnych próbkach — przewaga jest raczej funkcjonalna (moduły + ABE bypass) niż w ukryciu.

Podsumowanie / kluczowe wnioski

SantaStealer to świeży, modułowy infostealer MaaS celujący w przeglądarki i portfele krypto, z dojrzałym pipeline’em kradzieży i obejściem ABE. Na dziś przewaga napastników to funkcjonalność i użyteczność panelu, nie „niewykrywalność”. Ponieważ 16 grudnia 2025 r. pojawił się komunikat o wydaniu narzędzia, należy oczekiwać szybkich kampanii i iteracji technik ukrywania — warto już teraz wdrożyć reguły detekcyjne (C2:6767/HTTP + multipart 10 MB), wzmocnić przeglądarki i egzekwować polityki rozszerzeń.

Źródła / bibliografia

  1. BleepingComputer: „New SantaStealer malware steals data from browsers, crypto wallets” (15 grudnia 2025). (bleepingcomputer.com)
  2. Rapid7: „SantaStealer is Coming to Town: A New, Ambitious Infostealer…” (15–16 grudnia 2025, aktualizacja o wydaniu). (Rapid7)
  3. GitHub (xaitax): „Chrome App-Bound Encryption Decryption” — projekt badawczy, na którym bazuje komponent do obejścia ABE. (GitHub)

Dlaczego Darmowa Wiedza Nie Działa (Tak Jak Myślisz)

Gdy dostęp do wiedzy przestaje być wąskim gardłem

Zaobserwowałeś to pewnie sam: dysk pełen darmowych e-booków o cyberbezpieczeństwie, zakładki do tuzinów blogów i playlist YouTube „na później”. Wszystko dostępne od ręki, bez płacenia ani złotówki. Z taką górą darmowej wiedzy już dawno powinieneś być ekspertem, prawda? A jednak – realny progres umiejętności jakoś nie nadchodzi.

Czytaj dalej „Dlaczego Darmowa Wiedza Nie Działa (Tak Jak Myślisz)”

ConsentFix: nowa technika przejęcia kont Microsoft przez nadużycie OAuth w aplikacji Azure CLI

Wprowadzenie do problemu / definicja luki

Badacze z Push Security opisali nową technikę phishingu „ConsentFix”, która łączy wzorce ClickFix z nadużyciem OAuth consent i aplikacji Azure CLI. Atak pozwala przejąć dostęp do kont Microsoft (Entra/Microsoft 365) bez phishingu haseł i z ominięciem MFA, jeśli ofiara jest już zalogowana w przeglądarce. Kluczowy trik to wyłudzenie kodu autoryzacyjnego OAuth i skojarzenie konta ofiary z instancją Azure CLI napastnika.

W skrócie

  • Wektor: złośliwe/zhakowane strony z wysokim rankingiem w Google, fałszywy „Cloudflare Turnstile”, następnie instrukcje w stylu ClickFix.
  • Cel: uzyskać URL do localhost zawierający authorization code dla aplikacji Azure CLI i kazać ofierze wkleić go w stronę atakującego.
  • Efekt: napastnik wymienia kod na token(y) i zyskuje dostęp do danych/operacji w ramach uprawnień Azure CLI – bez hasła i bez dodatkowej weryfikacji MFA.
  • Dlaczego działa: Azure CLI jest aplikacją pierwszej strony Microsoft, zwykle domyślnie ufaną w Entra ID i niepodlegającą typowym ograniczeniom nakładanym na aplikacje zewnętrzne.
  • Mitigacje: zaostrzenie zasad User Consent, workflow Admin Consent, monitoring logowań Azure CLI i szybkie unieważnianie przyznań/zgód.

Kontekst / historia / powiązania

ConsentFix wpisuje się w ewolucję ataków na OAuth consent i ClickFix – zamiast kraść hasła, przestępcy polują na granty i tokeny. Wcześniej obserwowaliśmy m.in. AiTM i nowszy CoPhish, który nadużywał agentów Microsoft Copilot Studio do prezentowania legalnie wyglądających próśb o zgodę. Wspólny mianownik: legitymizacja przez domeny i aplikacje Microsoft oraz socjotechnika wokół przepływów OAuth.

Analiza techniczna / szczegóły luki

  1. Dostarczenie przynęty: ofiara trafia z wyszukiwarki na przejętą stronę; skrypt weryfikuje domenę e-mail (tylko „pożądane” organizacje idą dalej). Widać fałszywy widget Cloudflare Turnstile.
  2. Scena ClickFix: strona instruuje, aby kliknąć „Sign in”, co otwiera prawdziwy adres logowania Microsoft dla przepływu OAuth aplikacji Azure CLI.
  3. Authorization Code: po wybraniu konta (lub zalogowaniu) przeglądarka przekierowuje na http://localhost/... z parametrem code= (authorization code) – to standard w przepływach OAuth (authorization code / device flows).
  4. Exfiltracja: instrukcje nakazują skopiować cały URL i wkleić go w oknie na złośliwej stronie; skrypt po stronie atakującego wymienia code→token w kontekście aplikacji Azure CLI.
  5. Dlaczego bez sekretu? W tym scenariuszu kod wystarcza do pozyskania tokenu (aplikacje klienckie nie przechowują tajemnicy), więc mechanizm MFA/hasła nie chroni – sesja przeglądarki już uwierzytelnia użytkownika.
  6. Utrudnienia analizy: jednorazowość na IP, warunkowe ładowanie skryptów, selekcja celów, co znacznie utrudnia IOC-based detekcję.

Uwaga: Microsoftowa dokumentacja potwierdza, że device/authorization flows mogą kończyć się tokenem po poprawnym zalogowaniu i konsencie – to cecha protokołu, nie błąd implementacji. Problemem jest socjotechnika i nadużycie zaufanej aplikacji.

Praktyczne konsekwencje / ryzyko

  • ATO bez hasła i bez MFA: wystarczy aktywna sesja w przeglądarce i kilka kliknięć/kopiuj-wklej.
  • Zaufana aplikacja: Azure CLI jako first-party bywa wyłączony z restrykcji wobec app consent, co zwiększa powierzchnię nadużyć.
  • Dostęp szerokiego zakresu: w zależności od przyznanych/wykorzystanych uprawnień – potencjał na odczyt maili, plików, automatyzację operacji i pivot w M365/Azure. (Kierunek zgodny z wcześniejszymi kampaniami na tokeny OAuth).
  • Detekcja logowań wymaga patrzenia na zdarzenia sign-in specyficzne dla Azure CLI i nietypowe zakresy/stare Graph scopes.

Rekomendacje operacyjne / co zrobić teraz

1) Zaostrz politykę User Consent i włącz Admin Consent workflow

  • Ogranicz lub wyłącz zgody użytkowników; dopuszczaj wyłącznie zweryfikowanych wydawców i/lub niskiego ryzyka. Włącz Admin Consent workflow do obsługi próśb.

2) Monitoruj i reaguj

  • Ustal detektory na logowania Azure CLI z nowych lokalizacji/agentów oraz na przyznania zgody/zakresy nietypowe dla Twojej organizacji. Rekomendacje Push: poluj na sygnały związane z Azure CLI i „legacy Graph scopes”.
  • W razie incydentu: cofnij zgody/połączenia (Enterprise Apps), unieważnij refresh tokeny i wymuś ponowną autoryzację. (Patrz sekcja przeglądu i cofania zgód w Entra).

3) Twarde zasady wokół aplikacji i portali

  • Minimalizuj powierzchnię ataku: klastryzacja uprawnień, ograniczenia dostępu do portali, minimalizacja ról z prawem do przyznawania zgód. (Wytyczne dot. consent policies).

4) Edukacja użytkowników (anty-ClickFix)

  • Szkolenia ukierunkowane na „kopiuj-wklej z instrukcji wideo/strony” i fałszywe widgety weryfikacyjne. Podkreślaj: nigdy nie wklejać URL-i z kodami w obce formularze. (Wzorce opisane przez Push).

5) Testy kontroli i purple teaming

  • Przećwicz scenariusz: wyszukiwarka → „weryfikacja Cloudflare” → „Sign in” → localhost z code= → exfil. Sprawdź, które alerty zadziałały i gdzie brakuje telemetrii.

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

  • AiTM: kradnie sesje przez proxy logowania; ConsentFix poluje na granty OAuth i działa w kontekście przeglądarki bez pośredniczącej bramki.
  • CoPhish (Copilot Studio): także nadużywa zaufania do domen Microsoft i flow OAuth, ale przynętą są agenci Copilot z wbudowanymi przyciskami zgody. ConsentFix zamiast tego wyłudza kod z przepływu Azure CLI.

Podsumowanie / kluczowe wnioski

ConsentFix pokazuje, że obronność oparta wyłącznie na MFA i filtracji e-maili nie wystarczy wobec browser-native nadużyć OAuth i aplikacji pierwszej strony. Trzonem obrony musi być governance zgód, dojrzały threat hunting w logach Entra/Defender oraz ukierunkowana edukacja anty-ClickFix.

Źródła / bibliografia

  • Push Security: „ConsentFix – browser-native ClickFix hijacks OAuth grants” (11.12.2025). (Push Security)
  • BleepingComputer: „New ConsentFix attack hijacks Microsoft accounts via Azure CLI” (11.12.2025). (BleepingComputer)
  • Microsoft Learn: „Configure how users consent to applications” (aktualizacja 24.06.2025). (Microsoft Learn)
  • Microsoft Learn: „OAuth 2.0 device authorization grant flow” (aktualizacja 04.01.2025) – tło protokołu. (Microsoft Learn)
  • TechRadar: „CoPhish… steals OAuth tokens via Copilot Studio” (10.2025) – kontekst trendu. (TechRadar)

DroidLock: nowe oprogramowanie wymuszające dla Androida blokuje urządzenia i żąda okupu

Wprowadzenie do problemu / definicja luki

10–11 grudnia 2025 r. badacze Zimperium opisali nową kampanię złośliwego oprogramowania na Androida o nazwie DroidLock. Malware blokuje ekran, wymusza kontakt e-mailowy i grozi zniszczeniem danych w 24 godziny, a dodatkowo umożliwia atakującemu niemal pełne przejęcie urządzenia (zdalne sterowanie, zmiana PIN/biometrii, wipe). Celem są głównie użytkownicy hiszpańskojęzyczni, a dystrybucja odbywa się przez fałszywe strony i aplikacje podszywające się m.in. pod operatorów telekomunikacyjnych.

W skrócie

  • Typ zagrożenia: ransomware-locker (bez szyfrowania plików, z blokadą dostępu + groźbą zniszczenia danych).
  • Wejście: phishing stron/apek, dropper → drugi etap z właściwym payloadem.
  • Uprawnienia: nadużycie Accessibility Services i Device Administrator do przejęcia kontroli (lock/wipe/zmiana PIN).
  • Zdalne sterowanie: kanały HTTP/WebSocket, VNC (sharing/stream ekranu).
  • Celowana kampania: użytkownicy hiszpańskojęzyczni (Hiszpania).
  • Wykrywanie: Zimperium zgłasza próbki w ramach App Defense Alliance; Play Protect ma blokować znane warianty.

Kontekst / historia / powiązania

„Lockery” na Androida pojawiają się od lat (np. Android/Locker, DoubleLocker). Klasyczne taktyki to pełnoekranowe nakładki, wymuszenia quasi-policyjne oraz nadużycia Device Admin/Accessibility – dokładnie te elementy widzimy w DroidLock. Historyczne analizy ESET opisują, jak twórcy mobilnego ransomware’u od lat korzystają z tych mechanizmów i jak w 2017–2018 r. zaczęli masowo nadużywać Accessibility do automatycznego nadawania sobie uprawnień.

Analiza techniczna / szczegóły luki

Łańcuch infekcji. Użytkownik trafia na phishingową stronę i pobiera dropper, który dosyła właściwy moduł (drugi etap). Po instalacji malware żąda Accessibility i Device Admin, a gdy ofiara je nada, samo „klika” kolejne zgody, aby uzyskać dostęp do SMS-ów, kontaktów, logów połączeń, audio itp.

Komunikacja i C2. DroidLock ustanawia połączenia HTTP (telemetria) i WebSocket (komendy w czasie rzeczywistym). Obsługuje 15 komend, m.in.: RANSOMWARE (nakładka żądania okupu), BLACK_SCREEN / UPDATE_OVERLAY (fałszywy ekran aktualizacji blokujący interakcje), BLOCK_BIOMETRIC (blokada urządzenia), WIPE (factory reset), MUTE, CAMERA, VNC (zdalne sterowanie), INJECT_APP (nakładki credential harvesting), APP_BLOCK_LOCK_PATTERN (kradzież wzoru blokady), UNINSTALL_APP.

Nakładki i kradzież wzoru blokady. Malware wstrzykuje WebView/HTML nad wybranymi aplikacjami albo wyświetla szybki „lock-pattern overlay” z zasobów APK, by przejąć wzór odblokowania i ułatwić późniejsze sterowanie VNC.

Ransom-overlay i wymuszenie. Po komendzie z C2 wyświetla się pełnoekranowy ekran z instrukcją kontaktu (adres Proton) i ultimatum 24 h. DroidLock nie szyfruje plików, ale łączy blokadę urządzenia z groźbą skasowania danych – co skutecznie wymusza okup.

MITRE ATT&CK (Mobile) – przykłady mapowania:

  • T1660 Phishing (dystrybucja przez strony/apki)
  • T1626.001 Abuse Elevation Control (Device Admin)
  • T1629.002 Device Lockout
  • T1516/T1417 Input Injection/Keylogging (sterowanie/zbieranie danych)
  • T1517 Access Notifications (przechwyt OTP)
  • T1414 Clipboard Data (wyciek schowka)
    Zimperium wskazuje te techniki wprost w raporcie.

Praktyczne konsekwencje / ryzyko

  • Utrata dostępu do telefonu (zmiana PIN/biometrii, lockout) i ryzyko utraty danych (wipe).
  • Kompromitacja kont: przejęcie OTP z powiadomień, keylogging/overlay nad bankowością i komunikatorami.
  • Ryzyko dla firm: urządzenie staje się „wrogim punktem końcowym” wewnątrz sieci (VNC, screen recording, sterowanie UI).

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników (BYOD/indywidualni):

  1. Nie instaluj APK spoza Google Play; jeżeli musisz – tylko od sprawdzonych wydawców. Włącz i nie wyłączaj Google Play Protect.
  2. Zachowaj nieufność wobec żądań Accessibility/Device Admin – szczególnie gdy pojawiają się od razu po instalacji.
  3. Jeśli już jesteś zainfekowany/a:
    • Spróbuj uruchomić telefon w Trybie awaryjnym (Safe Mode) i odinstalować podejrzaną apkę; Safe Mode blokuje aplikacje firm trzecich, co często „zdejmuje” nakładkę.
    • Jeśli nie możesz cofnąć uprawnień Device Admin lub usunąć aplikacji – rozważ przywrócenie ustawień fabrycznych z kopii zapasowej (ostatnia deska ratunku). (Wipe jest też wykorzystywany przez sam malware).
  4. Kopie zapasowe (foto/dokumenty) w chmurze/szyfrowane lokalnie – minimalizują presję okupu. (Wnioski ogólne z badań ESET).

Dla organizacji:

  • MTD/EDR na mobile + runtime behavioral detection (np. wykrywanie nadużyć Accessibility/Admin, overlay, VNC/screen-recording).
  • Polityki MDM/UEM: blokuj sideloading, wymagaj sklepów zarządzanych, ogranicz uprawnienia Accessibility, wymuś regularne aktualizacje i skanowanie urządzeń. (Dobre praktyki zgodne z rekomendacjami branżowymi).
  • Szkolenia phishingowe dla mobile i monitoring anomalii (np. nagłe wyciszenie urządzeń, nagłe żądania admin perms).

Różnice / porównania z innymi przypadkami

  • Bez szyfrowania plików, ale z pełnym przejęciem – DroidLock eskaluje w stronę totalnego sterowania (VNC, screen streaming), co rzadziej występowało w starszych lockerach, które skupiały się na nakładkach/pseudo-policyjnych żądaniach.
  • Nowoczesne nadużycia Accessibility + automatyzacja zgód – trend obserwowany od DoubleLocker, lecz tu rozszerzony o bogaty zestaw komend C2.

Podsumowanie / kluczowe wnioski

DroidLock to świeża kampania locker-ransomware na Androida, która nie szyfruje danych, ale łączy blokadę urządzenia, groźbę kasowania i zdalne sterowanie do skutecznego wymuszenia. Najskuteczniejszą ochroną jest niewłączanie sideloadingu, odmowa podejrzanych uprawnień, aktywne Play Protect oraz MTD/MDM w firmach. W razie infekcji – Safe Mode i deinstalacja często wystarczą; gdy to niemożliwe, przywrócenie fabryczne z kopii zapasowej.

Źródła / bibliografia

  1. Zimperium (raport techniczny, 10 grudnia 2025): „Total Takeover: DroidLock Hijacks Your Device”. (zimperium.com)
  2. BleepingComputer (news, 10 grudnia 2025): „New DroidLock malware locks Android devices and demands a ransom”. (BleepingComputer)
  3. SiliconANGLE (news/omówienie, 10 grudnia 2025): „New DroidLock threat gives attackers near-total control of Android phones”. (SiliconANGLE)
  4. Trend Micro (poradnik, 27 października 2025): „Removing lock-screen type ransomware using Safe Mode on Android device”. (Trend Micro Success)
  5. ESET (whitepaper): „Android Ransomware: From Android Defender to DoubleLocker” – kontekst historyczny i taktyki (Device Admin, Accessibility).