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

Tag: Admin

Mandiant: ShinyHunters eskalują vishing i „kradzież MFA”, by przejmować SSO i okradać SaaS z danych

Wprowadzenie do problemu / definicja luki

Opisany przez Mandiant przypadek nie dotyczy „magicznej” podatności w chmurze ani błędu w samych platformach SaaS. To klasyczna, ale coraz lepiej „uzbrajana” socjotechnika: vishing (voice phishing) + strony podszywające się pod firmowe portale logowania, które wyciągają od ofiary jednocześnie hasło/SSO i kody MFA lub doprowadzają do zarejestrowania nowego urządzenia MFA kontrolowanego przez atakującego.

Atak działa, bo „człowiek w pętli” potrafi zatwierdzić wszystko, jeśli uwierzy, że rozmawia z IT/Helpdeskiem — a nowa generacja phishing kitów potrafi w czasie rzeczywistym dopasować to, co widzi ofiara w przeglądarce, do scenariusza rozmowy.

W skrócie

  • Google Threat Intelligence Group śledzi aktywność pod kilkoma klastrami: UNC6661, UNC6671 oraz UNC6240 (powiązywany z marką ShinyHunters).
  • Kampanie (wczesny–połowa stycznia 2026) polegają na podszywaniu się pod IT i kierowaniu pracowników na „victim-branded” strony kradnące SSO/MFA.
  • Po wejściu do środowiska atakujący „pivotują” do aplikacji SaaS i masowo wyciągają dane (m.in. dokumenty i komunikację), a następnie przechodzą do wymuszeń/ekstorsji.
  • Kluczowy wniosek obronny: MFA odporne na phishing (FIDO2/passkeys/FastPass) znacząco ogranicza skuteczność tego modelu ataku.

Kontekst / historia / powiązania

Wg Mandiant obserwujemy „rozszerzenie i eskalację” taktyk kojarzonych z wymuszeniami ShinyHunters: rośnie zakres atakowanych platform chmurowych, a presja na ofiarę obejmuje nie tylko e-maile z żądaniem okupu, ale też nękanie personelu i (w niektórych przypadkach) elementy presji operacyjnej.

Ważne jest też rozdzielenie „marki” od wykonawców: GTIG podkreśla, że śledzi aktywność jako kilka klastrów m.in. po to, by uwzględnić różne partnerstwa i możliwość podszywania się pod wcześniej znane TTP.

Równolegle Okta opisuje ewolucję phishing kitów „pod rozmowę telefoniczną” (vishing), które realnie zwiększają skalę tego typu ataków, bo pozwalają atakującemu sterować przebiegiem logowania ofiary niemal jak operatorem „z pulpitu”.

Analiza techniczna / szczegóły luki

1) Łańcuch ataku (high level)

  1. Recon + wybór celu (użytkownicy, aplikacje, numery infolinii/IT).
  2. Vishing: telefon „z IT” z pretekstem aktualizacji ustawień MFA / bezpieczeństwa.
  3. Victim-branded phishing: ofiara trafia na stronę przypominającą firmowy portal i wpisuje dane.
  4. Synchronizacja w czasie rzeczywistym: atakujący na bieżąco wprowadza przechwycone dane do prawdziwego loginu, wywołuje wyzwania MFA i instruuje ofiarę, co ma zatwierdzić/wpisać.
  5. Utrwalenie: rejestracja urządzenia MFA kontrolowanego przez atakującego lub przejęcie sesji/OAuth.
  6. Drenaż SaaS: dostęp do danych zależny od uprawnień skompromitowanej sesji SSO (często oportunistycznie).
  7. Ekstorsja: żądanie okupu, groźby publikacji, dowody kradzieży danych.

2) Klastry i różnice w TTP

  • UNC6661: wczesny–połowa stycznia 2026; domeny phishingowe często w formacie <companyname>sso.com / <companyname>internal.com; rejestracje często u NICENIC; widoczny „post-exploitation” w SaaS oraz przypadki wykorzystania przejętej poczty do dalszego phishingu (np. do podmiotów z branży kryptowalut).
  • UNC6671: podobny model vishing + „victim-branded” strony, ale domeny częściej rejestrowane przez Tucows; dodatkowo Mandiant widział użycie PowerShell do pobierania wrażliwych danych z SharePoint i OneDrive; ekstorsja bywała niebrandowana i z innym Tox ID, a nękanie personelu pojawiało się jako element presji.

3) Co konkretnie jest celem w SaaS?

Mandiant opisuje wykradanie danych i komunikacji z różnych usług SaaS (w przykładach i logach pojawiają się m.in. ekosystem Microsoft 365, Salesforce oraz DocuSign). W części przypadków atakujący wykonywali też wyszukiwania pod kątem „cennych słów kluczowych” (np. „confidential”, „proposal”, „vpn”), co sugeruje selekcję danych pod presję/ekstorsję.

4) Maskowanie śladów i „living off the land”

Ciekawy detal operacyjny: w co najmniej jednym incydencie, po przejęciu konta klienta Okta, atakujący autoryzował dodatek ToogleBox Recall w Google Workspace i usuwał wiadomości mogące ujawnić rejestrację nowego sposobu MFA („Security method enrolled”). To typowy przykład „ciszy po zalogowaniu” zamiast klasycznego malware.

Praktyczne konsekwencje / ryzyko

  • To nie jest „zwykły phishing”: prawdziwym przełomem jest sterowanie sesją ofiary w czasie rzeczywistym, co zwiększa skuteczność nawet przeciwko „lepszemu MFA”, jeśli nie jest ono phishing-resistant.
  • Ryzyko eskalacji przez SSO: pojedyncza udana rozmowa + SSO potrafią dać „szeroki wachlarz” aplikacji do przeszukania i eksportu danych.
  • Ekstorsja bez ransomware: model „data theft + szantaż” omija część klasycznych zabezpieczeń endpointowych, a presja czasu (np. ultimatum 72h w opisywanych przypadkach) wymusza szybkie decyzje kryzysowe.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „tu i teraz” wprost pod ten typ kampanii (priorytetyzacja zgodna z rekomendacjami Mandiant + wnioskami Okta):

1) Natychmiastowe działania (containment)

  • Odwołaj aktywne sesje i tokeny: wymuś wylogowanie, unieważnij tokeny sesyjne i autoryzacje OAuth w IdP oraz kluczowych SaaS.
  • Zablokuj operacje wysokiego ryzyka: ogranicz (czasowo lub politykami) reset haseł, rejestrację nowych urządzeń MFA i zmiany metod MFA — to dokładnie te procesy, które vishing „podrabia”.
  • Przejrzyj rejestracje urządzeń/MFA i uprawnienia adminów w IdP (szczególnie niespodziewane przypisanie ról, anomalie geolokacji, logowania z sieci anonimizujących).

2) Utwardzenie (hardening) pod vishing

  • Wymuś phishing-resistant MFA: FIDO2/passkeys lub rozwiązania typu FastPass (tam, gdzie to ma sens). Push/SMS/OTP są podatne na „przegadanie” ofiary przez telefon.
  • Zasady sieciowe i strefy zaufania: tam gdzie możliwe, ogranicz logowania i akcje administracyjne do znanych lokalizacji/stref (allowlist), a ruch z usług anonimizujących traktuj jako sygnał do polowania (hunting), niekoniecznie automatycznego blokowania „w ciemno”.
  • Proces „call-back” dla IT: jeśli pracownik dostaje telefon „z IT”, powinien oddzwonić na numer z firmowej książki/portalu, nie na numer z wyświetlacza. To proste, ale nadal ekstremalnie skuteczne przeciw vishingowi (a często pomijane).

3) Detekcja i monitoring (SOC)

  • Poluj na wzorce: „MFA device enrolled”, nietypowe logowania do konsoli admina IdP, masowe pobrania z SharePoint / OneDrive, użycie PowerShell do pobierania plików, autoryzacje podejrzanych aplikacji OAuth (np. ToogleBox Recall).
  • Kontrola domen podobnych do marki: rejestracje w stylu my<company>sso[.]com, <company>support[.]com, <company>okta[.]com, literówki typu acess.
  • Zweryfikuj, czy Twoje alerty obejmują nietypowe wolumeny pobrań i wyszukiwania po „wrażliwych słowach” w SaaS.

Różnice / porównania z innymi przypadkami

  • „MFA fatigue” vs. „MFA steering”: tu nie chodzi o zalewanie pushami aż ofiara kliknie — chodzi o pełną reżyserię logowania, gdzie kit phishingowy zmienia ekrany w idealnym tempie pod rozmowę. To jakościowo inny poziom „wiarygodności” ataku.
  • Ransomware niepotrzebne: jeżeli organizacja ma dojrzałe backupy i EDR, atakujący nadal może wygrać, kradnąc dane z SaaS i stosując presję reputacyjną/prawną.
  • Brak CVE jako „punktu wejścia”: to kampania oparta o procesy (helpdesk, reset MFA) i zachowania ludzi, dlatego testy podatności aplikacji nie wystarczą — potrzebne są ćwiczenia i polityki IAM.

Podsumowanie / kluczowe wnioski

  1. Kampanie przypisywane klastrom powiązanym z marką ShinyHunters pokazują, że vishing stał się pełnoprawnym wektorem initial access do SSO i SaaS — często skuteczniejszym niż klasyczny e-mailowy phishing.
  2. „Zwykłe MFA” nie wystarcza, jeśli nie jest odporne na phishing: FIDO2/passkeys/FastPass realnie podnoszą poprzeczkę.
  3. Obrona musi koncentrować się na sesjach, tokenach, rejestracji urządzeń MFA, logowaniu i detekcji anomalii w SaaS — a nie na poszukiwaniu „jednej podatności”.

Źródła / bibliografia

  • Mandiant – „Vishing for Access: Tracking the Expansion of ShinyHunters-Branded SaaS Data Theft” (30 stycznia 2026). (Google Cloud)
  • Mandiant – „Proactive Defense Against ShinyHunters-Branded Data Theft Targeting SaaS” (30 stycznia 2026). (Google Cloud)
  • Okta – „Phishing kits adapt to the script of callers” (22 stycznia 2026). (Okta)
  • BleepingComputer – omówienie kampanii i wątków dot. vishing + MFA/SSO (31 stycznia 2026). (BleepingComputer)
  • The Hacker News – streszczenie ustaleń Mandiant (31 stycznia 2026). (The Hacker News)

Microsoft Teams doda „Report a Call”: zgłaszanie podejrzanych połączeń jako nowy sygnał dla SOC

Wprowadzenie do problemu / definicja „luki”

Ataki socjotechniczne coraz częściej omijają klasyczne filtry antyphishingowe, przenosząc ciężar z e-maila do kanałów współpracy: czatów, spotkań i… połączeń VoIP. Rozmowa „rzekomo z IT”, „z banku” czy „z dostawcy” bywa trudniejsza do zweryfikowania niż wiadomość z linkiem – zwłaszcza gdy presja czasu i autorytet rozmówcy robią swoje.

Microsoft odpowiada na ten trend, dodając do Teams mechanizm umożliwiający użytkownikom zgłoszenie podejrzanego połączenia wprost z historii rozmów.

W skrócie

  • Teams dostanie funkcję „Report a Call”, pozwalającą oznaczać połączenia jako podejrzane / niechciane (scam, phishing).
  • Opcja ma być dostępna w historii połączeń dla rozmów 1:1 na Windows, macOS i w wersji web.
  • Raportowanie będzie włączone domyślnie, a administratorzy będą mogli je wyłączyć w Teams Admin Center → Calling settings.
  • Zgłoszenie udostępni ograniczone metadane (m.in. czas, długość, caller ID, identyfikatory uczestników) organizacji oraz Microsoftowi; dane mają być widoczne w Microsoft Defender portal lub w Teams Admin Center.
  • Harmonogram wg opisu wdrożenia: Targeted Release w połowie marca 2026, zakończenie w końcówce marca, GA globalnie do końca kwietnia 2026.

Kontekst / historia / powiązania

Nowa opcja raportowania wpisuje się w szerszy pakiet zabezpieczeń „na warstwie współpracy”. Microsoft równolegle rozwija mechanizmy ostrzegania o podejrzanych połączeniach od nieznanych, zewnętrznych kontaktów (scenariusze podszywania się pod markę / instytucję). Przykładem jest „Brand Impersonation Protection”, które ma wykrywać próby podszycia przy pierwszym kontakcie i ostrzegać użytkownika o ryzyku.

W praktyce to logiczna ewolucja: skoro Teams stał się „nową skrzynką odbiorczą” dla wielu firm, to telemetryka i procesy reagowania muszą objąć nie tylko czat, ale też kanał głosowy.

Analiza techniczna / szczegóły funkcji

Gdzie użytkownik zobaczy opcję?

„Report a Call” ma pojawić się w historii połączeń dla rozmów jeden na jeden. Użytkownik wybierze zgłoszenie z menu More options przy danym połączeniu.

Jakie dane trafiają do organizacji i Microsoftu?

Zgłoszenia mają przekazywać ograniczone metadane, m.in.:

  • znaczniki czasu,
  • czas trwania połączenia,
  • informacje caller ID,
  • identyfikatory Teams uczestników.

To ważne: mowa o metadanych „pod triage”, a nie o deklaracji, że treść rozmów jest automatycznie przechwytywana. Dla SOC oznacza to dodatkowy sygnał korelacyjny (kto dzwonił, kiedy, jak często, do ilu osób).

Gdzie analitycy to zobaczą?

  • Organizacje z licencjami Defender for Office 365 Plan 1/Plan 2 lub Defender XDR mają otrzymać bardziej szczegółowy wgląd w Defender portal.
  • Bez tych licencji pozostanie podstawowy wgląd w Teams Admin Center (raporty ochrony / Protection Reports).

Praktyczne konsekwencje / ryzyko

Co to realnie poprawia?

  1. Szybszy sygnał od użytkownika – zamiast „napiszcie do IT”, zgłoszenie staje się danymi do korelacji i raportowania trendów.
  2. Widoczność w SOC – nawet jeśli atak „nie zostawił linku”, nadal zostawia metadane i ślad zdarzenia w ekosystemie bezpieczeństwa.

Ryzyka wdrożeniowe

  • Szum operacyjny: jeśli użytkownicy zaczną zgłaszać wszystko, SOC dostanie „spam zgłoszeń”.
  • Fałszywe poczucie bezpieczeństwa: ostrzeżenia i przycisk zgłoszenia nie zastąpią procedur weryfikacji tożsamości rozmówcy.
  • Prywatność i governance: nawet metadane połączeń to dane wrażliwe organizacyjnie – trzeba je objąć polityką retencji, dostępów i audytu.

Rekomendacje operacyjne / co zrobić teraz

  1. Zdefiniuj playbook dla „podejrzanego połączenia”
    • kryteria: podszywanie pod IT/finanse, prośby o MFA, reset hasła, instalację narzędzia zdalnego dostępu, presja czasu;
    • działania: weryfikacja rozmówcy kanałem niezależnym, zgłoszenie incydentu, kontrola konta użytkownika (logowania, anomalie).
  2. Ustal triage i priorytetyzację
    • reguły korelacji: czy numer/konto dzwoniło do wielu osób, czy występuje wzorzec w czasie, czy są równoległe alerty (np. nietypowe logowania).
  3. Przygotuj komunikację dla pracowników
    • krótko: kiedy zgłaszać, kiedy kończyć rozmowę, czego nigdy nie podawać;
    • pokaż przykłady „pretekstów” w voice-phishingu.
  4. Sprawdź ustawienia w Teams Admin Center
    • skoro funkcja ma być domyślnie włączona, decyzja powinna być świadoma (pozostawić i okiełznać procesem, albo wyłączyć z uzasadnieniem).
  5. Jeśli masz Defender – zintegruj to z pracą SOC
    • przypisz odpowiedzialność (kto monitoruje nowe zgłoszenia),
    • zrób dashboard trendów i kampanii (miesiąc do miesiąca).

Różnice / porównania z innymi przypadkami

W Teams od pewnego czasu rozwijane jest też raportowanie podejrzanych wiadomości („Report this message”), które trafia do analizy po stronie bezpieczeństwa i przyspiesza wykrywanie zagrożeń w warstwie konwersacji.

Kluczowa różnica:

  • Wiadomości: często zawierają linki/załączniki → łatwiej o automatyczną analizę treści.
  • Połączenia: treści nie ma w zgłoszeniu, więc wartość leży w metadanych + korelacji + szybkości reakcji. Dlatego tak istotne jest, by playbook SOC nie opierał się wyłącznie na „kliknięciu zgłoś”, ale na szybkiej weryfikacji kontekstu i aktywności konta.

8Podsumowanie / kluczowe wnioski

„Report a Call” w Teams to mała zmiana w UI, ale duża zmiana w praktyce: użytkownik staje się czujnikiem, a SOC dostaje nowy sygnał o kampaniach socjotechnicznych prowadzonych głosem. Najwięcej zyskają organizacje, które:

  • połączą zgłoszenia z korelacją w Defender (jeśli mają licencje),
  • ograniczą szum jasnym szkoleniem i prostym playbookiem,
  • potraktują tę funkcję jako element strategii „secure collaboration”, obok ostrzeżeń o podszywaniu się pod marki.

Źródła / bibliografia

  • BleepingComputer: „New Microsoft Teams feature will let you report suspicious calls” (29 stycznia 2026). (BleepingComputer)
  • Microsoft 365 Roadmap: pozycja „Microsoft Teams: Report a Suspicious Call in Microsoft Teams” (status i daty na roadmapie). (Microsoft)
  • Microsoft Learn: „Microsoft Defender for Office 365 support for Microsoft Teams” (możliwości bezpieczeństwa i raportowania w Teams). (Microsoft Learn)
  • Microsoft Tech Community (Defender for Office 365 Blog): „Safeguarding Microsoft Teams…” (kontekst raportowania zagrożeń w Teams). (TECHCOMMUNITY.MICROSOFT.COM)
  • Windows Central: opis „Brand Impersonation Protection” i ostrzeżeń o podszywaniu się w połączeniach Teams (27 stycznia 2026). (Windows Central)

Ponad 6 tys. serwerów SmarterMail narażonych na automatyczne przejęcia kont admina (CVE-2026-23760)

Wprowadzenie do problemu / definicja luki

SmarterMail (serwer pocztowy i platforma współpracy od SmarterTools) znalazł się na celowniku masowych, zautomatyzowanych ataków po ujawnieniu krytycznej luki CVE-2026-23760. Błąd pozwala bez uwierzytelnienia przejąć konto administratora poprzez nieprawidłowo zaprojektowane API resetu hasła, a następnie – dzięki wbudowanym funkcjom administracyjnym – doprowadzić do zdalnego wykonania poleceń na hoście (RCE).

Równolegle organizacje typu Shadowserver raportowały tysiące instancji wystawionych do internetu, które wyglądały na podatne, a analitycy obserwowali już ataki „in the wild”.

W skrócie

  • CVE-2026-23760: obejście uwierzytelnienia w API resetu hasła; dotyczy wersji przed build 9511.
  • Wektor: POST /api/v1/auth/force-reset-password akceptuje żądania anonimowe i w krytycznej ścieżce dla sysadmina nie weryfikuje starego hasła / tokenu resetu.
  • Skutek: przejęcie konta admina → szybka eskalacja do RCE/SYSTEM przez funkcje administracyjne (np. wykonywanie komend).
  • Eksploatacja była obserwowana masowo i automatycznie (sekwencje żądań API, tworzenie „System Events”, sprzątanie śladów).
  • Skala: raportowano >6 000 publicznie dostępnych serwerów potencjalnie narażonych.

Kontekst / historia / powiązania

CVE-2026-23760 wypłynęło krótko po innej krytycznej luce w SmarterMail (CVE-2025-52691), co podbiło zainteresowanie atakujących (i presję na zespoły IT). BleepingComputer opisał sytuację jako serię zdarzeń: zgłoszenie, szybka poprawka, a następnie szybka adaptacja eksploitu i skanowanie internetu w poszukiwaniu podatnych serwerów.

Istotny kontekst operacyjny: w przypadku serwerów pocztowych ekspozycja na internet jest często „z definicji” (webmail, panel admina, API), więc okno czasowe między patchem a masową eksploatacją bywa wyjątkowo krótkie. SecurityWeek cytował watchTowr, że poprawka została szybko przeanalizowana (reverse engineering) i zaczęła być wykorzystywana na szeroką skalę.

Analiza techniczna / szczegóły luki

1) Root cause: reset hasła admina bez dowodu tożsamości

watchTowr opisał problem jako błąd w logice resetu hasła: endpoint force-reset-password jest dostępny anonimowo (co samo w sobie bywa normalne dla resetów), ale ścieżka dla kont sysadmin pozwala podać Username i NewPassword bez weryfikacji OldPassword lub tokenu resetu.

W praktyce: jeśli atakujący zna (lub zgadnie) nazwę konta administratora (często „admin”), może zresetować hasło i zalogować się jako administrator.

2) Od przejęcia konta do RCE – dwie obserwowane ścieżki

  • Ścieżka A (watchTowr): po przejęciu sysadmina możliwe jest doprowadzenie do wykonania poleceń systemowych przez wbudowane funkcje administracyjne (watchTowr opisał drogę przez ustawienia i mechanizm, który finalnie uruchamia komendę na hoście).
  • Ścieżka B (Huntress): w atakach „in the wild” widziano użycie funkcji System Events – napastnik po zdobyciu tokena dostępu tworzył złośliwy event-hook, wyzwalał go (np. dodaniem domeny), a potem wykonywał działania porządkowe (kasowanie domeny i hooka).

3) Sygnały masowej automatyzacji

Huntress pokazał typową sekwencję żądań API obserwowaną u wielu ofiar w krótkich odstępach czasu (co wygląda na automatyczne skrypty), zaczynając od wymuszenia resetu hasła, potem autoryzacji i konfiguracji mechanizmów do wykonania komend.

Praktyczne konsekwencje / ryzyko

Przejęty serwer SmarterMail to zwykle „klucz do królestwa” poczty:

  • dostęp do skrzynek, korespondencji i danych wrażliwych,
  • możliwość podszywania się (phishing/BEC), reguły przekierowań, utrwalanie dostępu,
  • infrastruktura do dalszych ataków (malware, pivot w sieci, kradzież poświadczeń),
  • ryzyko incydentu zgodności (RODO), reputacji i ciągłości działania.

NVD wprost wskazuje, że uprawnienia sysadmina w SmarterMail mogą przekładać się na administracyjne uprawnienia na hoście (SYSTEM/root) dzięki wbudowanym funkcjom zarządzania – co z perspektywy IR oznacza traktowanie takiego zdarzenia jak pełne przejęcie serwera.

Rekomendacje operacyjne / co zrobić teraz

1) Patch i weryfikacja wersji

  • Zaktualizuj do build 9511 lub nowszego (wszystko „przed 9511” jest wprost wskazywane jako podatne).

2) Jeśli nie możesz zaktualizować natychmiast (awaryjnie)

  • ogranicz dostęp do panelu/web API (VPN/allowlista IP, przynajmniej dla interfejsu administracyjnego),
  • rozważ tymczasowe reguły reverse proxy/WAF ograniczające dostęp do ścieżek API resetu hasła (uwaga: to obejście, nie „fix”),
  • włącz monitoring anomalii na endpointach /api/v1/auth/* i akcjach administracyjnych.

3) „Assume breach” – szybkie polowanie i IR

Szukaj w logach (proxy / aplikacyjnych) nietypowych żądań:

  • POST /api/v1/auth/force-reset-password oraz dalszych sekwencji API,
  • tworzenia/edycji System Events / event-hooków i operacji dodania/usunięcia domen (pattern z Huntress).

IOCs/sygnały (wg Huntress):

  • powtarzające się, szybkie sekwencje żądań API,
  • user-agent python-requests/2.32.4 widziany w atakach,
  • artefakt plikowy wskazywany w analizie Huntress (plik z wynikami rozpoznania).

4) Higiena po incydencie

  • reset haseł kont uprzywilejowanych (i rotacja kluczy/sekretów, jeśli serwer miał dostęp do innych systemów),
  • przegląd reguł przekazywania poczty, integracji i webhooków,
  • sprawdzenie trwałości (scheduled tasks, usługi, web-shelle, nieznane binaria),
  • segmentacja i minimalizacja ekspozycji usług zarządzających.

Różnice / porównania z innymi przypadkami

Warto odróżnić dwie głośne luki SmarterMail z przełomu stycznia:

  • CVE-2026-23760 – „czyste” przejęcie admina przez reset hasła bez weryfikacji (API), a potem RCE jako konsekwencja uprawnień admina i funkcji administracyjnych.
  • CVE-2025-52691 – wcześniejsza, krytyczna podatność pre-auth (opisywana jako droga do RCE na niezałatanych serwerach), wspominana w kontekście tej fali ataków.

Operacyjnie: w CVE-2026-23760 kluczowe jest, że atakujący może „wejść drzwiami frontowymi” jako admin (zmieniając hasło), co utrudnia detekcję, jeśli organizacja monitoruje wyłącznie klasyczne wskaźniki exploitów RCE.

Podsumowanie / kluczowe wnioski

  • CVE-2026-23760 to krytyczny błąd projektowy w API resetu hasła, który umożliwia przejęcie konta sysadmina i w praktyce prowadzi do pełnego kompromisu serwera.
  • Skala ekspozycji jest duża (tysiące instancji wystawionych do internetu), a eksploatacja była obserwowana jako zautomatyzowana.
  • Najważniejsze działania: aktualizacja do build 9511+, ograniczenie ekspozycji panelu/API oraz szybkie threat hunting pod kątem sekwencji API i nadużyć System Events.

Źródła / bibliografia

  • BleepingComputer – o skali ekspozycji i trwających atakach (BleepingComputer)
  • NVD (NIST) – opis CVE-2026-23760, wersje podatne, charakter wpływu (NVD)
  • watchTowr Labs – analiza techniczna root cause i PoC dla force-reset-password (watchTowr Labs)
  • Huntress – obserwacje ataków „in the wild”, sekwencje API i IOCs (Huntress)
  • SecurityWeek – kontekst masowej eksploatacji i mechaniki nadużyć (SecurityWeek)

FG-IR-26-060 / CVE-2026-24858: krytyczne obejście uwierzytelniania FortiCloud SSO w FortiOS, FortiManager i FortiAnalyzer

Wprowadzenie do problemu / definicja luki

Fortinet opublikował advisory PSIRT o numerze FG-IR-26-060 (data publikacji: 27 stycznia 2026) dotyczący krytycznej podatności w mechanizmie FortiCloud Single Sign-On (SSO), umożliwiającej obejście uwierzytelniania administracyjnego w produktach FortiOS, FortiManager oraz FortiAnalyzer.

Podatność ma identyfikator CVE-2026-24858 i jest klasyfikowana jako Authentication Bypass Using an Alternate Path or Channel (CWE-288) — czyli sytuacja, w której produkt „wymaga logowania”, ale istnieje alternatywna ścieżka prowadząca do skutecznego uwierzytelnienia bez prawidłowej weryfikacji.

W skrócie

  • CVE: CVE-2026-24858 (krytyczna; Fortinet/CNA: CVSS 9.8)
  • Dotknięte produkty: FortiOS / FortiManager / FortiAnalyzer (w określonych zakresach wersji) (
  • Warunek ataku: włączone FortiCloud SSO (logowanie admina przez FortiCloud); atakujący musi posiadać konto FortiCloud i zarejestrowane urządzenie
  • Status: obserwowano aktywne wykorzystanie w środowiskach produkcyjnych; Fortinet czasowo ograniczał działanie FortiCloud SSO, a następnie przywrócił je z blokadą logowań z podatnych wersji firmware

Kontekst / historia / powiązania

W grudniu 2025 Fortinet opisywał wcześniejsze problemy związane z omijaniem FortiCloud SSO (m.in. CVE-2025-59718 i CVE-2025-59719). Nowy incydent był początkowo postrzegany jako „powrót” tamtego wektora, jednak Fortinet wskazał przypadki naruszeń na urządzeniach, które były już zaktualizowane zgodnie z wcześniejszym advisory — co zasugerowało istnienie nowej ścieżki ataku (alternate path).

Z perspektywy IR ważna jest też oś czasu działań dostawcy: Fortinet wskazał m.in. blokowanie nadużywanych kont i czasowe wyłączenie FortiCloud SSO po stronie chmury, a następnie przywrócenie usługi z ograniczeniem dla podatnych wersji.

Analiza techniczna / szczegóły luki

Na czym polega problem

Opis CVE sprowadza się do ryzyka naruszenia izolacji między tenantami/klientami w przepływie FortiCloud SSO: atakujący z kontem FortiCloud i zarejestrowanym urządzeniem może w pewnych warunkach zalogować się administracyjnie do urządzeń zarejestrowanych na inne konta, jeśli na tych urządzeniach włączono FortiCloud SSO dla admina.

Co widać w telemetrii

Fortinet opublikował przykładowe wskaźniki i logi, które pomagają odróżnić „normalne” SSO od nadużycia:

  • obserwowane konta użyte do logowań SSO: cloud-noc@mail.io, cloud-init@mail.io
  • przykładowe adresy IP (część ukrywana za Cloudflare): m.in. 104[.]28.244.115, 104[.]28.212.114 oraz dodatkowe IP raportowane przez strony trzecie
  • typowy ciąg zdarzeń po udanym logowaniu: utworzenie lokalnego konta admin (np. audit, backup, itadmin, secadmin, support i inne) jako mechanizm persystencji

Fortinet pokazał również przykład wpisu logu „Admin login successful” z method="sso" oraz kolejny log wskazujący dodanie obiektu w system.admin (tworzenie nowego admina).

Zakres wersji narażonych

W opisie NVD wskazano zakresy wersji, dla których ryzyko dotyczy m.in.:

  • FortiOS: 7.0.0–7.0.18, 7.2.0–7.2.12, 7.4.0–7.4.10, 7.6.0–7.6.5
  • analogicznie dla FortiManager i FortiAnalyzer w odpowiadających gałęziach 7.0/7.2/7.4/7.6

(Uwaga operacyjna: „zakres dotknięty” ≠ „zakres wdrożony w Twojej organizacji”. Jeśli masz mieszane wersje i centralne zarządzanie, traktuj temat jako kampanię obejmującą całą flotę.)

Praktyczne konsekwencje / ryzyko

Skuteczne obejście uwierzytelnienia administracyjnego na urządzeniu brzegowym/zarządzającym oznacza w praktyce „pełne przejęcie”:

  • modyfikacja polityk firewall/VPN, tworzenie tuneli i kont zdalnego dostępu
  • eksfiltracja konfiguracji (często zawierającej informacje o topologii, adresacji, integracjach, kontach i certyfikatach)
  • przygotowanie persystencji (lokalne konta admin) i pivot do sieci wewnętrznej

Dodatkowy wątek: Fortinet podkreślił, że choć obserwowana eksploatacja dotyczyła FortiCloud SSO, to problem klasy „SAML SSO alternate path” może mieć szerszy kontekst w organizacjach, które wdrażają SSO także z innymi dostawcami.

Rekomendacje operacyjne / co zrobić teraz

1) Ogranicz powierzchnię ataku na interfejs zarządzania (natychmiast)

Fortinet rekomenduje twarde ograniczenie dostępu administracyjnego (najlepiej out-of-band; alternatywnie allowlista IP przez local-in policy).

2) Rozważ czasowe wyłączenie FortiCloud SSO dla logowań admina

Jeśli Twoje procesy na to pozwalają, wyłącz „Allow administrative login using FortiCloud SSO” i przejdź na kontrolowane metody dostępu. Fortinet podaje też komendę CLI:
set admin-forticloud-sso-login disable

(W części środowisk Fortinet wdrożył dodatkowo blokowanie logowań SSO z podatnych wersji po stronie chmury — ale to nie zwalnia z higieny zarządzania i kontroli dostępu.)

3) Threat hunting / detekcja

Sprawdź:

  • logowania admin method="sso" i nietypowe ui="sso(...)"
  • wystąpienia kont cloud-init@mail.io / cloud-noc@mail.io (oraz inne nieoczekiwane tożsamości SSO)
  • nowe konta admin o podejrzanych nazwach (lista w sekcji IOC)

4) Jeżeli widzisz IOC — traktuj system jako skompromitowany

Fortinet zaleca m.in.: przywrócenie konfiguracji z „known good”, audyt zmian, rotację haseł/sekretów (w tym integracji LDAP/AD) i pełny przegląd kont administracyjnych.

5) Patch management

Kieruj się zasadą: zaktualizuj do najnowszego dostępnego wydania w danej gałęzi (lub wykonaj upgrade międzygałęziowy zgodny z polityką Twojej organizacji) i monitoruj komunikaty PSIRT/CVE. Zakresy wersji dotkniętych masz w NVD, a status/zmiany mitigacji Fortinet aktualizował w komunikacji PSIRT/blogu.

Różnice / porównania z innymi przypadkami

  • Podobieństwo do CVE-2025-59718/59719 (grudzień 2025): ten sam „obszar funkcjonalny” (FortiCloud SSO) i podobne symptomy (logowanie SSO, tworzenie lokalnych adminów).
  • Różnica kluczowa: według Fortinet/BleepingComputer ataki występowały również tam, gdzie wcześniejsze poprawki były już wdrożone — co wskazuje na inną ścieżkę obejścia (alternate path), a nie prosty „patch bypass” jednego CVE.

Podsumowanie / kluczowe wnioski

  1. CVE-2026-24858 (FG-IR-26-060) to krytyczne obejście uwierzytelniania w przepływie FortiCloud SSO z realnymi przypadkami nadużyć.
  2. Największe ryzyko dotyczy środowisk z włączonym logowaniem administracyjnym przez FortiCloud SSO oraz wystawionym/nieograniczonym dostępem do panelu zarządzania.
  3. Priorytet „tu i teraz”: ograniczenie dostępu admin, monitoring IOC, oraz gotowość do pełnych działań IR (rotacje, rollback konfiguracji) w razie wykrycia śladów ataku.

Źródła / bibliografia

  • Fortinet PSIRT Blog: Analysis of Single Sign-On Abuse on FortiOS (22 stycznia 2026) (fortinet.com)
  • NIST NVD: CVE-2026-24858 (NVD)
  • BleepingComputer: Fortinet blocks exploited FortiCloud SSO zero day until patch is ready (27 stycznia 2026) (BleepingComputer)
  • FortiGuard PSIRT (metadane advisory w wynikach wyszukiwania): FG-IR-26-060 Administrative FortiCloud SSO authentication bypass (fortiguard.fortinet.com)

Microsoft łata aktywnie wykorzystywany 0-day w Office (CVE-2026-21509) – obejście zabezpieczeń OLE/COM i pilne działania dla adminów

Wprowadzenie do problemu / definicja luki

Pod koniec stycznia 2026 Microsoft wydał awaryjne, pozacykliczne poprawki (out-of-band) dla podatności 0-day w Microsoft Office, która – co najważniejsze – była już aktywnie wykorzystywana w atakach. Luka otrzymała identyfikator CVE-2026-21509 i jest klasyfikowana jako Security Feature Bypass: nie chodzi więc o „klasyczne RCE”, ale o ominięcie mechanizmów ochronnych w Office związanych z kontrolkami COM/OLE.

W skrócie

  • CVE: CVE-2026-21509
  • Typ: obejście zabezpieczeń (Security Feature Bypass), powiązane z decyzjami bezpieczeństwa opartymi o niezaufane dane (CWE-807)
  • Wektor CVSS (CNA/Microsoft): 7.8 HIGH, AV:L / UI:R (wymagane działania użytkownika)
  • Warunek ataku: dostarczenie spreparowanego pliku Office i nakłonienie ofiary do otwarcia; Preview Pane nie jest wektorem ataku
  • Zakres: wiele wersji Office (m.in. 2016/2019/LTSC/365); dla części wydań ochrona ma być realizowana „po stronie usługi” i wymaga restartu aplikacji
  • KEV: podatność trafiła do kontekstu Known Exploited Vulnerabilities (KEV); w danych NVD widać m.in. Date Added: 2026-01-26 oraz Due Date: 2026-02-16

Kontekst / historia / powiązania

Ataki na łańcuch „dokument → elementy OLE/COM → uruchomienie niebezpiecznej logiki” to stały motyw kampanii phishingowych i malware’owych. W tym przypadku Microsoft jasno wskazuje, że aktualizacja dotyczy obejścia „OLE mitigations”, czyli mechanizmów ograniczających ryzyko podatnych kontrolek COM/OLE. To ważna wskazówka: nawet jeśli sam błąd nie jest „pełnym RCE”, to może otwierać drogę do kolejnych etapów ataku (np. uruchomienia komponentów, które powinny zostać zablokowane przez polityki/mitigacje).

Analiza techniczna / szczegóły luki

Co wiemy na pewno (z advisory i opisów technicznych)

  • Opis z NVD (na podstawie danych od CNA/Microsoft): „Reliance on untrusted inputs in a security decision in Microsoft Office…” – czyli mechanizm decyzyjny bezpieczeństwa może zostać oszukany przez niezaufane wejście.
  • Microsoft i media branżowe łączą problem bezpośrednio z OLE/COM i mechanizmami ochrony („OLE mitigations”).

Warunki exploitacji

  • Atak lokalny (AV:L) i wymagana interakcja użytkownika (UI:R): typowy scenariusz to phishing / spearphishing z załącznikiem Office lub plikiem pobieranym z internetu, który użytkownik otwiera.
  • Microsoft podkreśla, że Preview Pane nie jest wektorem, ale otwarcie pliku przez użytkownika już tak.

Mitigacja „kill bit” (COM Compatibility)

W materiałach opisano obejście zmniejszające ryzyko (szczególnie gdy łatka nie jest jeszcze dostępna dla danej edycji): w rejestrze Windows, w gałęzi COM Compatibility, tworzy się klucz dla konkretnego CLSID i ustawia wartość Compatibility Flags = 0x400. To podejście przypomina klasyczne „kill bity” blokujące problematyczne komponenty COM/ActiveX.

Praktyczne konsekwencje / ryzyko

  1. Realne ryzyko operacyjne: aktywne wykorzystanie „in-the-wild” oznacza, że kampanie już trwają, a PoC nie jest konieczny, by zobaczyć skutki w organizacji.
  2. Bypass zabezpieczeń to często początek łańcucha: ominięcie mitigacji OLE/COM może zwiększyć skuteczność ataków dokumentowych i obniżyć próg wejścia dla kolejnych technik (np. uruchomienia komponentu, który miał być zablokowany).
  3. Presja czasowa dla organizacji: NVD wskazuje, że CVE jest powiązane z KEV i ma datę „due date” 16 lutego 2026 (co praktycznie wymusza szybkie domknięcie tematu w patch management).

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „od najpilniejszych” – tak, żeby dało się je wdrożyć nawet w dużym środowisku:

1) Zweryfikuj, które edycje Office są w użyciu

  • Zidentyfikuj: Office 2016, Office 2019, LTSC 2021/2024, Microsoft 365 Apps – podatność dotyczy wielu linii produktowych.

2) Wymuś aktualizacje / restart aplikacji Office

  • Dla części wersji (Office 2021 i nowsze / M365) Microsoft wskazuje ochronę przez service-side change, ale z warunkiem: użytkownicy muszą zrestartować aplikacje Office, aby mechanizm zaczął działać. W praktyce: komunikat do użytkowników + wymuszenie restartu (np. po logoffie, przez narzędzia EDR/ITSM).

3) Jeśli łatka nie jest dostępna dla Twojej edycji – zastosuj mitigację rejestrową

  • Jeżeli masz środowiska, gdzie update jeszcze nie dotarł (w materiałach wskazywano opóźnienia dla 2016/2019), rozważ tymczasową mitigację w rejestrze w gałęziach COM Compatibility z ustawieniem Compatibility Flags = 0x400 dla wskazanego CLSID. Najbezpieczniej wdrożyć to jako kontrolowany GPO/Intune remediation (z backupem i rollbackiem).

4) Utwardź warstwę „dokumenty z internetu”

  • Utrzymuj / egzekwuj Protected View oraz polityki ograniczające uruchamianie zawartości aktywnej z plików pobranych z internetu (MOTW). Microsoft wprost wskazuje, że ustawienia ochronne typu Protected View dają dodatkową warstwę obrony.

5) Hunting i detekcja

  • Potraktuj incydent jak „kampanię dokumentową”: poluj na nietypowe załączniki Office, wzrost otwarć plików z maili zewnętrznych, anomalie procesów potomnych Office (WinWord/Excel/PowerPoint) i zdarzenia związane z COM/OLE.
  • Microsoft wspomina o dostępnych detekcjach w Defenderze (warto upewnić się, że sygnatury/telemetria są aktualne).

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

  • 0-day „bypass” vs „RCE”: CVE-2026-21509 nie jest opisywany jako klasyczne zdalne wykonanie kodu bez udziału użytkownika – tu kluczowe są interakcja użytkownika i ominięcie mechanizmu ochrony. To często mniej „medialne”, ale w praktyce równie groźne, bo zwiększa skuteczność dobrze znanych technik (phishing + dokument).
  • Mitigacja typu kill bit: użycie COM Compatibility i flag kompatybilności mocno przypomina historyczne podejście do blokowania podatnych komponentów ActiveX/COM – to sygnał, że problem może dotyczyć „konkretnego obiektu/klasy” w ekosystemie OLE/COM.

Podsumowanie / kluczowe wnioski

  • CVE-2026-21509 to aktywnie wykorzystywany 0-day w Microsoft Office, sklasyfikowany jako obejście zabezpieczeń OLE/COM.
  • Priorytetem jest szybka redukcja ekspozycji: aktualizacje, wymuszenie restartu Office tam, gdzie ochrona jest „service-side”, oraz mitigacje rejestrowe w środowiskach, które czekają na patch.
  • Traktuj temat jak incydent „high urgency”: NVD wskazuje powiązanie z KEV i termin działań do 16 lutego 2026.

Źródła / bibliografia

  1. BleepingComputer – opis OOB patch, zakres wersji, mitigacje rejestrowe, komentarz Microsoft (BleepingComputer)
  2. NVD (NIST) – CVSS 3.1 (CNA), opis, CWE-807, informacja o KEV (date added / due date) (nvd.nist.gov)
  3. The Hacker News – podsumowanie techniczne, restart aplikacji, wersje/aktualizacje, kroki mitigacji (The Hacker News)
  4. SecurityWeek – kontekst „in-the-wild”, brak szczegółów o kampanii, ogólna ocena ryzyka (SecurityWeek)
  5. The Register – dodatkowe tło i ujęcie operacyjne dla OOB patch (The Register)

Nowe ataki ClickFix nadużywają skryptów Windows App-V, by dostarczać malware (Amatera Stealer)

Wprowadzenie do problemu / definicja luki

ClickFix to nie „luka” w sensie CVE, tylko powtarzalny wzorzec socjotechniczny: ofiara jest przekonywana, by sama uruchomiła polecenie w Windows (najczęściej przez Win+R) pod pretekstem „weryfikacji” albo „naprawy problemu”. W najnowszej odsłonie atakujący dołożyli sprytny twist: zamiast odpalać PowerShell bezpośrednio, proxy’ują wykonanie przez legalny, podpisany komponent Microsoftu związany z App-V.

W skrócie

  • Kampania startuje od fałszywego CAPTCHA i instrukcji: wklej/uruchom komendę w oknie „Uruchamianie” (Win+R).
  • Komenda nadużywa SyncAppvPublishingServer.vbs (App-V) odpalonego przez wscript.exe, aby „przykryć” uruchomienie PowerShell i zmienić typowy łańcuch procesów.
  • Łańcuch ma bramki anty-sandbox: sprawdzanie zachowania użytkownika, kolejności uruchomienia i stanu schowka; w środowiskach analitycznych potrafi „wisieć” w nieskończoność.
  • Konfiguracja jest pobierana z publicznego Google Calendar (.ics) (dead-drop), a jeden z etapów ukrywa payload w PNG (steganografia) i ładuje go w pamięci.
  • Finalnie celem jest Amatera Stealer (rodzina infostealer sprzedawana jako MaaS, rozwijana i „utwardzana” pod kątem evasion).

Kontekst / historia / powiązania

Microsoft wskazuje, że ClickFix rośnie od 2024 r. i bywa łączony z phishingiem, malvertisingiem oraz kompromitacją stron — a kluczową przewagą napastnika jest wymuszenie interakcji człowieka, która potrafi ominąć część automatycznych detekcji.

W tej kampanii istotne jest „życie z ziemi” (LotL/LOLBins): MITRE opisuje nadużycie SyncAppvPublishingServer.vbs jako sub-technikę System Script Proxy Execution, gdzie legalny skrypt może proxy’ować wykonanie poleceń PowerShell zamiast bezpośredniego powershell.exe.

Analiza techniczna / szczegóły luki

Poniżej najważniejsze elementy łańcucha (z perspektywy IR/DFIR i detekcji):

1) Wejście: fake CAPTCHA → Win+R
Użytkownik widzi stronę „human verification” i dostaje instrukcję uruchomienia komendy. To klasyczny ClickFix, ale dalej robi się nietypowo.

2) Proxy wykonania: wscript.exe + SyncAppvPublishingServer.vbs
Zamiast explorer.exe → powershell.exe, pojawia się uruchomienie przez wscript.exe i skrypt App-V (SyncAppvPublishingServer.vbs). To zmienia „process ancestry” i może obniżać skuteczność reguł nastawionych na typowe wzorce PowerShell.

3) „Execution gates” i anty-analiza
Blackpoint opisuje bramkowanie oparte m.in. o:

  • walidację kolejności kroków i zachowania użytkownika,
  • kontrolę schowka (marker potwierdzający manualne wklejenie),
  • ciche „zawieszenie” (np. nieskończone oczekiwanie), by marnować zasoby sandboxów.

4) LotL infrastruktury: konfiguracja w Google Calendar (.ics)
Zamiast twardo kodować parametry C2/loadera, kampania pobiera je z publicznego pliku kalendarza (ICS) — prostej tekstówki, którą łatwo aktualizować bez ruszania pierwszych etapów.

5) Fileless/stage’in memory + steganografia w PNG
W kolejnych etapach payload jest odszyfrowywany/rozpakowywany w pamięci, a jedna z metod dostarczania to ukrycie zaszyfrowanego ładunku w obrazie PNG (steganografia).

6) Payload: Amatera Stealer
Amatera jest opisywana przez Proofpoint jako rebranding ACR Stealera, oferowany w modelu MaaS i rozwijany pod kątem unikania detekcji; w praktyce to „warstwa monetyzacji” wielu web-inject / ClickFix-like łańcuchów.

Praktyczne konsekwencje / ryzyko

  • Celowanie w środowiska firmowe: App-V częściej występuje w środowiskach Enterprise/Education; tam też „naturalnie” działa SyncAppvPublishingServer.vbs, więc aktywność łatwiej ukryć w szumie.
  • Kradzież danych uwierzytelniających i sesji: infostealery typowo polują na przeglądarki, hasła, tokeny, portfele krypto i dane aplikacji — co szybko przekłada się na przejęcia kont i dalszą propagację. (Charakterystyka Amatera jako aktywnie rozwijanego stealera/MaaS.)
  • Niższa skuteczność „klasycznych” reguł PowerShell: jeżeli polityki/detekcje są budowane głównie wokół powershell.exe, proxy przez wscript.exe + podpisany skrypt może wyślizgiwać się spod części alertów.

Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (24–72h):

  1. Edukacja i komunikat do użytkowników: „Nigdy nie wklejaj poleceń do Win+R/Terminala z przypadkowych stron (CAPTCHA, ‘fix’, ‘verify’)”. Microsoft wprost wskazuje ten element jako rdzeń ClickFix i punkt, w którym szkolenie realnie obniża ryzyko.
  2. Detekcja: wscript.exe → SyncAppvPublishingServer.vbs z osadzonym PowerShell
    • MITRE sugeruje monitorowanie uruchomień tego skryptu przez wscript.exe i anomalii w linii poleceń, gdzie skrypt służy jako proxy dla PowerShell.
  3. Ograniczenie powierzchni: blokada skryptu, jeśli App-V nie jest wymagany
    • MITRE w mitigacjach mówi wprost: jeśli podpisane skrypty proxy-execution nie są potrzebne, warto je blokować polityką kontroli aplikacji. (WDAC/AppLocker / allow-listing).

Wzmocnienia średnioterminowe (1–4 tyg.):

  • Hardening stacji: ograniczenie możliwości uruchamiania narzędzi i interpreterów skryptowych tam, gdzie nie są niezbędne (w tym kontrola VBScript/WSH w środowisku).
  • Telemetria PowerShell: gdzie to możliwe, włącz/utrzymaj logowanie (Script Block Logging/AMSI) i koreluj z nietypowym proces ancestry (PowerShell bez powershell.exe na wierzchu).
  • Polityki uprawnień: minimalizacja lokalnych adminów oraz kontrola makr/skryptów i stref (szczególnie gdy wektor wejścia to web).
  • Polowanie po IoC/TTP: nietypowe pobieranie .ics z publicznych usług, sekwencje loaderów „in-memory”, pobieranie PNG w kontekście skryptów i późniejsze deszyfrowanie/uruchomienie.

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

Klasyczny ClickFix często sprowadza się do „wklej i uruchom PowerShell”. Microsoft opisuje, że wariantów jest wiele, ale rdzeń pozostaje ten sam: użytkownik wykonuje polecenie, bo wygląda na element weryfikacji/naprawy.

To, co wyróżnia opisywaną kampanię, to proxy execution przez App-V (LOLBin) oraz wieloetapowa, konsekwentna optymalizacja pod anty-analizę: bramkowanie schowkiem i kolejnością, dead-drop w Google Calendar i steganografia w PNG, wszystko z naciskiem na „ciche” wykonanie w pamięci.

Podsumowanie / kluczowe wnioski

  • ClickFix dalej działa, bo wykorzystuje nawyk „szybkiego naprawiania” problemu — a ta kampania pokazuje, że napastnicy potrafią go połączyć z podpisanymi komponentami Windows i przemyślanym łańcuchem evasion.
  • SyncAppvPublishingServer.vbs nie jest egzotyką w ATT&CK — to rozpisana technika proxy-execution; jeśli masz App-V, musisz liczyć się z nadużyciem tego elementu.
  • Największy „ROI” na start: uświadomienie użytkowników + detekcje na wscript/App-V + kontrola aplikacji (blokuj, jeśli niepotrzebne).

Źródła / bibliografia

  1. BleepingComputer – „New ClickFix attacks abuse Windows App-V scripts to push malware” (26 stycznia 2026) (BleepingComputer)
  2. Blackpoint Cyber – „Novel Fake CAPTCHA Chain Delivering Amatera Stealer” (Blackpoint)
  3. MITRE ATT&CK – T1216.002 System Script Proxy Execution: SyncAppvPublishingServer (attack.mitre.org)
  4. Microsoft Security Blog – „Think before you Click(Fix): Analyzing the ClickFix social engineering technique” (21 sierpnia 2025) (Microsoft)
  5. Proofpoint – „Amatera Stealer: Rebranded ACR Stealer With Improved Evasion, Sophistication” (16 czerwca 2025) (Proofpoint)

7 Typowych Pułapek W Procesie Zarządzania Incydentami I Jak Ich Unikać

Dlaczego to ma znaczenie

Gdy dochodzi do cyberincydentu, czas działa na niekorzyść obrony. To, jak zespół zareaguje w pierwszych godzinach, decyduje o tym, czy incydent będzie tylko drobnym potknięciem, czy pełnowymiarową katastrofą. Dobre przygotowanie potrafi zamienić potencjalny paraliż firmy w kontrolowane zdarzenie o minimalnym wpływie. Z kolei brak planu i chaotyczne działania “na gorąco” często tylko pogarszają sytuację.

Czytaj dalej „7 Typowych Pułapek W Procesie Zarządzania Incydentami I Jak Ich Unikać”