Archiwa: Security News - Strona 273 z 274 - Security Bez Tabu

Kategoria: Security News

Grupa wymuszeniowa publikuje miliony rekordów z ataków na klientów Salesforce. Co naprawdę się stało i jak się bronić

Wprowadzenie do problemu / definicja luki

Ekstorcjonistyczna grupa Scattered LAPSUS$ Hunters opublikowała w sieci zestawy danych skradzionych z instancji Salesforce należących do wielu firm. Wyciek nastąpił po nieudanym wymuszeniu okupu – Salesforce publicznie zadeklarował, że nie zapłaci i nie będzie negocjować. Co istotne, sam rdzeń platformy Salesforce nie został naruszony; ataki uderzyły w klientów i ich integracje/aplikacje oraz ludzi (socjotechnika). Na liście ofiar wymieniono m.in. Albertsons, Engie Resources, Fujifilm, GAP, Qantas i Vietnam Airlines. Qantas informował wcześniej o potencjalnie ~5–6 mln dotkniętych klientów, a w przypadku Vietnam Airlines usługę Have I Been Pwned odnotowała ~7,3 mln kont.

W skrócie

  • Kto? Kolektyw Scattered LAPSUS$ Hunters (powiązania z Lapsus$, Scattered Spider, ShinyHunters).
  • Co? Wyciek części danych i groźby ujawnienia kolejnych – łącznie przestępcy chwalili się setkami milionów do ~1 mld rekordów z dziesiątek firm korzystających z Salesforce.
  • Jak? Dwie równoległe ścieżki:
    1. Vishing/Help Desk → skłonienie pracowników do instalacji spreparowanego Salesforce Data Loader / uzyskania dostępu do kont.
    2. Przejęte tokeny OAuth aplikacji Salesloft Drift → masowy eksport danych z obiektów Salesforce.
  • Stanowisko Salesforce: brak dowodów na kompromitację platformy; firma nie zapłaci okupu.
  • Działania organów ścigania: zaburzenie infrastruktury wymuszeniowej grupy przez FBI; mimo to część danych wyciekła.

Kontekst / historia / powiązania

Początek października przyniósł uruchomienie przez grupę własnego serwisu wyciekowego i eskalację gróźb wobec ~39 wskazanych firm-klientów Salesforce. Jednocześnie pojawiły się potwierdzone publikacje danych (m.in. Qantas, Vietnam Airlines). Wcześniejsze ostrzeżenia pochodziły od Google Threat Intelligence/Mandiant oraz FBI, które niezależnie opisały dwie aktywne komórki (UNC6040 i UNC6395) polujące na instancje Salesforce różnymi metodami.

Analiza techniczna / szczegóły luki

Ścieżka A – socjotechnika i Data Loader (UNC6040):

  • Atakujący używali vishingu (podszywanie się pod IT Service Desk), aby nakłonić pracowników do instalacji zmodyfikowanego Salesforce Data Loader lub udostępnienia danych logowania/MFA.
  • Po uzyskaniu dostępu następował eksport masowy rekordów (PII, dane programów lojalnościowych, profile użytkowników).

Ścieżka B – tokeny OAuth i integracje (UNC6395):

  • Kompromitacja tokenów OAuth aplikacji Salesloft Drift; w odpowiedzi 20 sierpnia unieważniono tokeny Drift i wyłączono aplikację w AppExchange.
  • Napastnicy wykonywali SOQL z kont zaufanych aplikacji, zliczając i pobierając obiekty Account, Opportunity, User, Case, oraz wyszukiwali w danych sekrety (np. AKIA, hasła, tokeny Snowflake).
  • GTIG/Mandiant opublikowali IOC (m.in. UA „Salesforce-Multi-Org-Fetcher/1.0”, zakres IP – również węzły Tor) i szczegółowe zapytania SOQL pomocne w detekcji.

Dlaczego ofiary są podatne?

  • Nadmierne uprawnienia Connected Apps („full access”), zbyt liberalne IP Relaxation, brak restrykcji API na profilach, niewłaściwy lifecycle tokenów i zbyt długie sesje.

Praktyczne konsekwencje / ryzyko

  • Ryzyko nadużyć PII: phishing ukierunkowany, oszustwa podróżnicze/lojalnościowe (linie lotnicze), przejęcia kont.
  • Ryzyko wtórne (pivot): wyciek tajnych kluczy/API znalezionych w rekordach Salesforce → dalsze włamania do AWS/Snowflake i systemów SaaS.
  • Chaos informacyjny: część deklaracji grupy jest przesadzona lub niespójna (np. „nie możemy więcej wyciekać”), co utrudnia ocenę pełnej skali, ale potwierdzone wycieki już mogą skutkować incydentami fraudowymi.

Rekomendacje operacyjne / co zrobić teraz

1) Reagowanie i łagodzenie skutków (Salesforce/SecOps)

  • Przegląd logów: Event Monitoring (zwł. Connected App OAuth Usage, Login, API, UniqueQuery), anomalia w UA i adresach z IOC (Tor/Cloud).
  • Rotacja sekretów: natychmiast unieważnij i odtwórz tokeny OAuth, API keys, hasła powiązane z integracjami; usuń nadmiarowe refresh tokens.
  • Ogranicz Connected Apps: minimalne scopes, IP restrictions, wyłącz „API Enabled” poza uprzywilejowanymi Permission Sets; ustaw krótsze sesje i wymuś MFA.
  • Wyszukiwanie sekretów w danych: przeszukaj obiekty (Case, Attachment, Task, Chatter) pod kątem AKIA, password, Snowflake, URL-i logowania; zastosuj narzędzia typu TruffleHog.

2) Twardnienie procesów i ludzi

  • Help Desk Playbook: blokada realizacji żądań przez telefon/voice bez out-of-band potwierdzenia i weryfikacji tożsamości; zakaz dyktowania kodów MFA/SSO.
  • Dystrybucja oprogramowania: instalatory Salesforce Data Loader wyłącznie z oficjalnych źródeł, podpisy cyfrowe, listy dozwolonych hashy, EDR.

3) Komunikacja z klientami i monitoring nadużyć

  • Powiadomienie osób, których dotyczy sprawa; brand-monitoring pod kątem phish-kampanii podszywających się pod firmę/lojalności.
  • Dodatkowe kontrole ryzyka transakcji i weryfikacje zmian danych (adresy, telefony) w systemach lojalnościowych.

4) Współpraca z dostawcami i organami

  • Wykonaj zalecenia Salesforce/Salesloft; zgłoś ślady kompromitacji do FBI/CERT (flash TLP:CLEAR nt. UNC6040/UNC6395).

Różnice / porównania z innymi przypadkami

  • Nie jest to „klasyczny” ransomware: brak szyfrowania, czysta ekstorsja danych + presja medialna.
  • Atak na ekosystem SaaS: kruche punkty to integracje i tożsamość, a nie zero-day w samym Salesforce – odmiennie np. od incydentów z lukami w platformach on-prem.

Podsumowanie / kluczowe wnioski

  • Wyciek ujawnia strukturalną słabość: zaufane aplikacje i tokeny OAuth są „złotym kluczem” do danych CRM.
  • Wzmocnienie Connected Apps, monitoring SOQL, rotacja sekretów i dyscyplina operacyjna są dziś ważniejsze niż kiedykolwiek.
  • Organy ścigania potrafią zakłócić infrastrukturę wymuszeniową, ale skutki wycieku (phishing, oszustwa, przejęcia kont) pozostają i wymagają długofalowej obrony.

Źródła / bibliografia

  1. SecurityWeek – przegląd publikacji danych (Albertsons, Engie, Fujifilm, GAP, Qantas, Vietnam Airlines) i kontekst 39 ofiar. (SecurityWeek)
  2. Reuters – potwierdzenia dot. skali („~1 mld rekordów”), technik vishing oraz stanowiska Salesforce. (Reuters)
  3. Google Cloud Threat Intelligence/Mandiant – techniczne szczegóły kampanii UNC6395 (Drift OAuth), SOQL, IOC, zalecenia. (Google Cloud)
  4. Cybersecurity Dive – deklaracja Salesforce o odmowie płatności, rozdzielenie dwóch kampanii (Data Loader vs. Drift). (cybersecuritydive.com)
  5. BankInfoSecurity/GovInfoSecurity – przebieg publikacji po zakłóceniu przez FBI, liczby dla Qantas/Vietnam Airlines. (BankInfoSecurity)

Złośliwy skrypt na stronie Unity (SpeedTree) wykradał dane klientów: co wiemy i jak się zabezpieczyć

Wprowadzenie do problemu / definicja luki

Unity Technologies poinformowało w zgłoszeniach do prokuratora generalnego stanu Maine, że na stronie produktu SpeedTree (moduł do modelowania roślinności 3D) wykryto złośliwy kod na stronie checkout, który wykradał dane wprowadzane podczas zakupów. Według informacji przekazanych władzom, zdarzenie dotyczy co najmniej 428 osób. Poszkodowanym oferowane jest bezpłatne monitorowanie kredytowe i ochrona tożsamości. Zdarzenie zostało opisane przez SecurityWeek i potwierdzone wpisem w rejestrze naruszeń stanu Maine.

W skrócie

  • Okres działania skryptu: od 13 marca 2025 r. do 26 sierpnia 2025 r. (data usunięcia kodu).
  • Zakres danych: imię i nazwisko, adres, e-mail, numer karty płatniczej oraz „access code” (CVV) wpisywane w formularzu płatności.
  • Skala: 428 osób zgłoszonych w notyfikacji do stanu Maine; trwają indywidualne powiadomienia i oferowane jest 12 mies. monitoringu kredytowego.
  • Działania Unity: wyłączenie/odseparowanie strony, usunięcie złośliwego kodu 26 sierpnia 2025 r., rozpoczęcie dochodzenia, notyfikacje.
  • Szerszy kontekst: równolegle branża mierzy się z poważną podatnością w Unity Runtime (CVE-2025-59489), która pozwala na lokalne wstrzyknięcie bibliotek; Microsoft i Valve wdrożyły środki zaradcze. (To odrębny problem, ale istotny kontekst bezpieczeństwa ekosystemu).

Kontekst / historia / powiązania

SpeedTree to znany komponent używany przez studia gier i twórców 3D. Incydent dotyczył strony checkout SpeedTree, a nie samego silnika Unity czy gier opartych na Unity. Raport SecurityWeek wskazuje, że atak jest typowym przypadkiem web skimmingu (często określanego jako Magecart), gdzie złośliwy skrypt zbiera dane z pól formularza podczas płatności.

W tym samym okresie media branżowe opisywały podatność CVE-2025-59489 w Unity Runtime — nie ma dowodów, by była ona bezpośrednio powiązana z atakiem na SpeedTree, ale oba tematy podbiły uwagę na bezpieczeństwo w ekosystemie Unity.

Analiza techniczna / szczegóły luki

Na bazie udostępnionych notyfikacji i publikacji można zrekonstruować charakterystykę ataku:

  • Wektor: modyfikacja strony checkout (warstwa klienta). Skrypt był aktywny od 13.03.2025 do 26.08.2025.
  • Mechanizm: klasyczny skimmer JS: przechwytywanie wartości wpisywanych przez użytkownika (imiona, adresy, e-mail, numery kart i CVV) i wysyłanie ich do infrastruktury atakującego. To wzorzec zgodny z rodziną ataków Magecart obserwowanych w e-commerce.
  • Skala i identyfikacja ofiar: 428 osób ujętych w zgłoszeniu do Maine AG (łączna liczba, nie tylko rezydenci Maine).

Choć Unity nie ujawniło dokładnej techniki wstrzyknięcia, podobne kampanie często wykorzystują kompromitację łańcucha dostaw skryptów (np. zależności zewnętrzne, naruszenie CMS, tag managera) albo bezpośrednią zmianę plików JS na serwerze. (Wniosek na podstawie znanej taktyki Magecart w literaturze branżowej).

Praktyczne konsekwencje / ryzyko

Dla klientów SpeedTree:

  • Ryzyko nadużyć kartowych i kradzieży tożsamości wskutek przejęcia danych płatniczych i kontaktowych. Atrybucja czasu ryzyka obejmuje zakupy wykonane między 13.03 a 26.08.2025.

Dla firm (merchants / SaaS):

  • Pokazuje to, że kontrola po stronie serwera (WAF, skanery SAST/DAST) nie wystarczy wobec ataków w warstwie klienta – konieczne są dedykowane mechanizmy Client-Side Protection/Monitoring oraz rygorystyczne zarządzanie skryptami trzecich stron. (Wniosek zgodny z analizami branżowymi dot. Magecart).

Rekomendacje operacyjne / co zrobić teraz

Użytkownicy, którzy kupowali na SpeedTree w tym okresie:

  1. Skorzystaj z oferowanego monitoringu kredytowego (12 mies.) i alertów anty-fraud.
  2. Rozważ zastrzeżenie/ wymianę karty użytej do transakcji w danym oknie czasowym; monitoruj wyciągi i ustaw powiadomienia o transakcjach.
  3. Włącz 2FA w serwisach, gdzie używasz tego samego e-maila; uważaj na spear-phishing oparty o pozyskane dane.

Zespoły bezpieczeństwa / e-commerce (lekcje na przyszłość):

  • Wprowadź CSP (Content Security Policy) z script-src i connect-src whitelistingiem + raportowaniem (report-to).
  • Używaj SRI (Subresource Integrity) i wersjonowania/lockfile dla skryptów zewnętrznych.
  • Zaimplementuj Client-Side Monitoring (RUM/DOM integrity, detekcja skimmerów, monitorowanie form) i kontrolę tag managera (uprawnienia/4-eyes review). (Praktyki rekomendowane przy obronie przed Magecart).
  • Regularnie pen-testuj warstwę klienta (checkout), prowadzaj lustrzane środowiska do porównań integralności, wdrażaj CI/CD z kontrolą zmian w zasobach statycznych.
  • Dla środowisk Unity: śledź i wdrażaj poprawki związane z CVE-2025-59489 (chociaż to inny wektor), by minimalizować ogólny profil ryzyka.

Różnice / porównania z innymi przypadkami

Incydent SpeedTree wpisuje się w schemat Magecart/web skimming, gdzie kluczowe są:

  • Warstwa klienta jako punkt ataku (JS na stronie płatności).
  • Ciche działanie przez miesiące (tu ~5,5 miesiąca), zanim zostanie wykryte i zgłoszone.

W poprzednich latach widzieliśmy podobne nadużycia m.in. z wykorzystaniem Google Tag Manager do dostarczania skimmerów na sklepach Magento — mechanicznie zbliżone, choć detale różniły się sposobem wstrzyknięcia.

Podsumowanie / kluczowe wnioski

  • Atak na checkout SpeedTree to klasyczny skimming JS, który dotknął co najmniej 428 osób i obejmował dane kartowe wraz z CVV. Okno ekspozycji: 13.03–26.08.2025.
  • Unity usunęło kod i prowadzi notyfikacje oraz oferuje monitoring. Niezależnie od tego, organizacje powinny traktować warstwę klienta jako krytyczny element łańcucha bezpieczeństwa.
  • W tle branża patchuje CVE-2025-59489 w Unity Runtime — to osobny problem, ale przypomina, że higiena aktualizacji i kontrola zależności są kluczowe.

Źródła / bibliografia

  1. SecurityWeek — „Malicious Code on Unity Website Skims Information From Hundreds of Customers” (13 października 2025). (SecurityWeek)
  2. Rejestr naruszeń danych — Maine Attorney General: Unity Technologies SF (wpis dot. 428 osób). (Maine)
  3. Security Affairs — omówienie notyfikacji Unity do Maine AG (okno 13.03–26.08.2025, monitoring kredytowy). (Security Affairs)
  4. SecurityWeek — „Microsoft and Steam Take Action as Unity Vulnerability Puts Games at Risk” (CVE-2025-59489; kontekst ekosystemowy). (SecurityWeek)
  5. Kaspersky — „Vulnerability in Unity game engine (CVE-2025-59489)” (analiza techniczna podatności; kontekst). (Kaspersky)

SimonMed Imaging: wyciek danych po ataku Medusa – 1,28 mln rekordów pacjentów

Wprowadzenie do problemu / definicja luki

SimonMed Imaging – jedna z największych sieci diagnostyki obrazowej w USA (170+ placówek, 10 stanów) – potwierdziła naruszenie ochrony danych wynikające z ataku ransomware Medusa. W ujawnieniu przekazano, że nieuprawniony dostęp do systemów trwał od 21 stycznia do 5 lutego 2025 r., a wyciek dotyczy ponad 1,2 mln osób. Incydent został publicznie powiązany z grupą Medusa, która wcześniej chwaliła się kradzieżą ~200 GB danych i żądała ok. 1 mln USD okupu.

W skrócie

  • Skala: 1 275 669 osób (dane PHI/PII). Powiadomienia wysyłane od 10 października 2025 r.
  • Wejście napastników: między 21.01–05.02.2025; wykrycie własne 28.01 po alercie od dostawcy 27.01.
  • Sprawcy: Medusa (RaaS), deklaracja kradzieży ~200 GB, żądanie 1 mln USD.
  • Zakres danych: m.in. imię i nazwisko, adres, data urodzenia, nr ubezpieczenia, dane prawa jazdy/ID, SSN, dane kont finansowych, poświadczenia dostępu, informacje medyczne (diagnoza, leczenie, MRN).

Kontekst / historia / powiązania

Pierwsze sygnały o kampanii Medusa wobec SimonMed pojawiły się w lutym 2025 r., gdy grupa opublikowała „proof files” i termin zapłaty, deklarując setki gigabajtów skradzionych danych. W bazach urzędowych (AG Maine, OCR/HHS) przypadek figuruje jako naruszenie PHI >500 osób, zaktualizowane obecnie do ponad 1,27 mln. Jednocześnie CISA klasyfikuje Medusę jako aktywny ekosystem RaaS operujący od 2021 r., wielokrotnie uderzający w sektor ochrony zdrowia.

Analiza techniczna / szczegóły luki

Z publicznego Notice of Data Incident wynika, że po alercie dostawcy (27.01) SimonMed wykrył „podejrzaną aktywność” 28.01 i podjął działania zaradcze: reset haseł, wzmocnienie MFA, wdrożenie EDR, odcięcie bezpośrednich dostępów vendorów, whitelistowanie ruchu, zgłoszenie do organów ścigania i angaż ekspertów ds. prywatności/bezpieczeństwa. To wskazuje na wektor powiązany z łańcuchem dostaw lub nadużyciem dostępu pośrednika. Dokładna technika wejścia nie została podana, ale charakter danych („poświadczenia uwierzytelniające” wśród skradzionych) sugeruje, że częścią incydentu mogła być kradzież haseł/tokenów i lateral movement.

Kategorie danych objętych incydentem (wybór):

  • PII: imię i nazwisko, adres, data urodzenia, nr prawa jazdy/ID, SSN;
  • Dane finansowe: numery kont;
  • Dane medyczne/PHI: data usługi, nazwa świadczeniodawcy, MRN/patient number, diagnoza, leczenie, leki, informacje o ubezpieczeniu;
  • Poświadczenia dostępu (credentials).

Praktyczne konsekwencje / ryzyko

  • Ryzyko kradzieży tożsamości i nadużyć ubezpieczeniowych: zestawienie PII+PHI+SSN to pełny profil do fraudów finansowych i medycznych (np. wyłudzeń świadczeń).
  • Dalsza monetyzacja danych: taktyka Medusy obejmuje publikację/sprzedaż dumpów, co zwiększa dług ogonowy ryzyka (months–years).
  • Ryzyko wtórne dla organizacji: potencjalne pozwy zbiorowe, koszty notyfikacji i wsparcia, sankcje OCR/HHS za naruszenie HIPAA (w przypadku stwierdzenia niezgodności).

Rekomendacje operacyjne / co zrobić teraz

Dla pacjentów SimonMed

  1. Zamrożenie kredytu (security freeze) i alerty fraudowe w biurach kredytowych; monitorowanie raportów (annualcreditreport.com) – wskazówki w oficjalnym zawiadomieniu.
  2. Zmiana haseł i włączenie MFA w serwisach powiązanych (poczta, portale pacjenta, ubezpieczyciele).
  3. Obserwacja EOB/rachunków pod kątem nieznanych usług medycznych; szybka reklamacja u ubezpieczyciela.
  4. Ostrożność wobec phishingu podszywającego się pod SimonMed/ubezpieczyciela.

Dla organizacji ochrony zdrowia (lekcje z incydentu)

  • Higiena dostawców: Zero Trust dla łańcucha dostaw: brak stałych tuneli, JIT/JEA, segmentacja, MFA z FIDO2 dla kont vendorów, pełny loging i polityka zapytań serwisowych.
  • EDR + telemetry fusion: korelacja EDR, dzienników IdP, VPN, proxy; detekcje „impossible travel”, MFA fatigue i anomalii poświadczeń.
  • Ochrona poświadczeń: wdrożenie phishing-resistant MFA, rotacja kluczy/API, seedy TOTP poza stacjami roboczymi, Secret Scanning w repozytoriach.
  • Backupy odporne na modyfikację: immutability (WORM), air-gap, testy przywracania tabletop co 90 dni.
  • DLP/klass. danych: oznaczanie PHI/PII, minimalizacja retencji; szyfrowanie w spoczynku i w tranzycie, monitoring exfiltracji (TLS SNI/DNS egress).
  • Ćwiczenia IR: playbook „ransomware+exfil” z osobnymi ścieżkami dla danych medycznych i powiadomień stanowych (AG/OCR).

Różnice / porównania z innymi przypadkami Medusa

  • Wektor i taktyki: zgodne z profilem Medusy opisanym przez CISA (RaaS, kradzież danych przed wymuszeniem, groźby publikacji).
  • Zakres danych: rzadziej spotykane jest jednoczesne wystąpienie poświadczeń i pełnych PHI/SSN – podnosi to próg ryzyka względem wielu „typowych” incydentów medycznych.
  • Skala: 1,28 mln czyni ten przypadek jednym z największych ujawnionych w sektorze ochrony zdrowia w 2025 r. (wg branżowych zestawień).

Podsumowanie / kluczowe wnioski

Atak Medusa na SimonMed to klasyczna, dane-najpierw kampania wymuszeniowa z silnym komponentem łańcucha dostaw. Skala (1,28 mln rekordów), szeroka mieszanka PHI/PII/SSN/credentials oraz długi czas ekspozycji (15 dni) oznaczają istotne ryzyko dla pacjentów. Organizacje medyczne powinny traktować dostawców jak potencjalne pivots, wymuszając phishing-resistant MFA, segmentację i obserwowalność na poziomie tożsamości – zanim dojdzie do exfiltracji.

Źródła / bibliografia

  • SecurityWeek: „SimonMed Imaging Data Breach Impacts 1.2 Million” (13 października 2025). SecurityWeek
  • SimonMed – Notice of Data Incident (aktualna strona). SimonMed Website
  • HIPAA Journal: „SimonMed Imaging confirms January 2025 cyberattack; 1,275,669 affected; letters mailed Oct 10, 2025”. The HIPAA Journal
  • Maine Attorney General – rejestr zgłoszeń (pozycja SimonMed). maine.gov
  • CISA: „#StopRansomware: Medusa Ransomware” (12 marca 2025) – charakterystyka grupy. CISA

SonicWall: masowe przejęcia kont SSL VPN po incydencie z kopią zapasową konfiguracji — co wiemy i co robić

Wprowadzenie do problemu / definicja luki

10 października 2025 r. firma Huntress ostrzegła przed szeroko zakrojoną kampanią przejęć kont SonicWall SSL VPN, w której napastnicy logowali się „lawinowo” na wiele kont, najpewniej używając prawidłowych poświadczeń, a nie siłowego łamania haseł. Do 10 października skompromitowano ponad 100 kont w 16 środowiskach, a znaczna część aktywności zaczęła się 4 października. SecurityWeek potwierdził skalę zjawiska, powołując się na dane Huntress.

W skrócie

  • Co się stało: trwają ataki polegające na poprawnym logowaniu do kont SSL VPN w urządzeniach SonicWall (bez brute force). Jedno ze źródeł logowań wskazuje na adres 202.155.8[.]73.
  • Kontekst: kilka dni wcześniej SonicWall ujawnił, że nieuprawniony dostęp do usługi MySonicWall Cloud Backup objął wszystkich klientów przechowujących kopie konfiguracji firewalli (pierwotnie szacowano <5%).
  • Czy sprawy są powiązane? Huntress nie ma dowodów na bezpośrednie powiązanie, ale go nie wyklucza.
  • Ryzyko: wyciek zaszyfrowanych poświadczeń i danych konfiguracyjnych może ułatwić ataki ukierunkowane; obserwowane są także skanowania sieci i próby dostępu do kont w domenie.

Kontekst / historia / powiązania

8 października 2025 r. SonicWall zaktualizował poradnik incydentowy, kończąc dochodzenie (z Mandiant) i potwierdzając, że wszystkie kopie konfiguracji przechowywane w chmurze były dostępne dla atakującego. CISA z kolei opublikowała ostrzeżenie i wskazówki dla klientów SonicWall w związku z tym zdarzeniem.

W lipcu–wrześniu obserwowano równolegle aktywność związaną z ransomware Akira i urządzeniami SonicWall/SMA/SSL VPN; mimo że to inna oś narracji, podkreśla ona rosnącą atrakcyjność ekosystemu SonicWall dla grup przestępczych.

Analiza techniczna / szczegóły luki

  • Wektor dostępu w bieżącej kampanii: logowania z prawidłowymi poświadczeniami do SSL VPN (szybkie serie logowań; brak oznak bruteforce). Część sesji kończy się natychmiastowym rozłączeniem, w innych przypadkach stwierdzono działania potexploitacyjne (skanowanie, próby dostępu do lokalnych kont Windows).
  • Incydent chmurowy MySonicWall: napastnik uzyskał dostęp do plików kopii konfiguracji (zawierających m.in. zaszyfrowane hasła/sekrety, reguły, ustawienia VPN, integracje LDAP/RADIUS/TACACS+, SNMP, itp.). SonicWall udostępnił klientom listy dotkniętych urządzeń i klasyfikację priorytetów (Active High/Low/Inactive).
  • Status powiązania zdarzeń: Huntress podkreśla brak dowodu, że masowe logowania są bezpośrednim skutkiem incydentu kopii zapasowej — ale taka możliwość istnieje (np. odtworzenie haseł/sekretów, korelacja konfiguracji).

Praktyczne konsekwencje / ryzyko

  • Ryzyko nadużyć poświadczeń: nawet jeśli dane w kopiach były zaszyfrowane, metadane i konfiguracje mogą obniżyć koszt rekonesansu i ułatwić obejście zabezpieczeń perymetrowych.
  • Ryzyko lateral movement: potwierdzone skanowanie sieci i próby kompromitacji kont AD wskazują na możliwość szybkiej eskalacji uprawnień po wejściu przez SSL VPN.
  • Ryzyko „cichego” dostępu: część aktorów kończy sesję bez dalszych działań — możliwe przygotowanie do późniejszych kampanii lub testy ważności poświadczeń. (Wniosek na podstawie obserwacji Huntress).

Rekomendacje operacyjne / co zrobić teraz

Poniższe kroki zbierają zalecenia SonicWall, Huntress i CISA — w kolejności „od teraz do stabilizacji”:

  1. Natychmiast ogranicz zdalne zarządzanie i dostęp WAN (HTTP/HTTPS/SSH/SSL VPN), aż do pełnej rotacji sekretów; jeśli to możliwe, odetnij zarządzanie z Internetu.
  2. Wymuś pełną rotację wszystkich sekretów powiązanych z firewallami/SSL VPN: hasła lokalnych adminów, pre-shared keys VPN, klucze/hasła do LDAP/RADIUS/TACACS+, PSK Wi-Fi, SNMP, API (DDNS, SMTP/FTP, automatyzacje).
  3. Zmień hasła w MySonicWall i wszystkich zewnętrznych integracjach; usuń stare kopie w chmurze, wykonaj nowe lokalne (po rotacji). Sprawdź portal MySonicWall → Product Management → Issue List i priorytety urządzeń.
  4. Włącz/Mandatuj MFA dla wszystkich kont administracyjnych i zdalnych; zrewiduj role i zasady najmniejszych uprawnień.
  5. Zwiększ logowanie i retencję: przeanalizuj nietypowe logowania, zmiany konfiguracji, zestawienia tuneli; zachowaj logi do analizy powłamaniowej.
  6. Stopniowo przywracaj usługi po rotacji haseł, monitorując, czy nie powracają nieautoryzowane logowania.
  7. Zastosuj wskazówki CISA/SonicWall z aktualnych poradników dot. incydentu chmurowego i twardnienia konfiguracji.

Różnice / porównania z innymi przypadkami

  • Nie jest to klasyczna luka „do załatania” w firmware (jak CVE-2024-40766 w przeszłości), lecz konsekwencje kompromitacji usługi kopii zapasowej i/lub wtórnego nadużycia poświadczeń — dlatego kluczowe są rotacja sekretów i hardening, a nie patch.
  • Kampania logowań (październik 2025) różni się od wcześniejszych fal, gdzie wykorzystywano podatności SMA/SSL VPN lub 0-daye; tutaj dominują poprawne logowania i „masowe” użycie jednego adresu źródłowego.

Podsumowanie / kluczowe wnioski

  • 8–10 października 2025 r.: SonicWall finalizuje dochodzenie (z Mandiant) i potwierdza pełny zakres incydentu kopii konfiguracyjnych w chmurze; niemal równolegle Huntress sygnalizuje masowe przejęcia kont SSL VPN z użyciem prawidłowych poświadczeń.
  • Brak twardego dowodu na związek, ale ryzyko wtórnych nadużyć jest wysokie.
  • Priorytetem jest szybka rotacja wszystkich sekretów, ograniczenie ekspozycji usług i wzmożony monitoring.

Źródła / bibliografia

  1. SecurityWeek — SonicWall SSL VPN Accounts in Attacker Crosshairs, 13 paź 2025. SecurityWeek
  2. Huntress — Threat Advisory: Widespread SonicWall SSLVPN Compromise, 10 paź 2025. Huntress
  3. SonicWall — MySonicWall Cloud Backup File Incident (aktualizacja 8 paź 2025). SonicWall
  4. CISA — SonicWall releases advisory… (22 wrz 2025). CISA
  5. SecurityWeek — All SonicWall Cloud Backup Users Had Firewall Configurations Stolen, 9 paź 2025. SecurityWeek

Microsoft uszczelnia IE Mode w Edge po atakach z wykorzystaniem 0-day w Chakra

Wprowadzenie do problemu / definicja luki

Microsoft przebudował sposób uruchamiania Internet Explorer (IE) mode w przeglądarce Edge po „wiarygodnych doniesieniach” o realnych atakach z sierpnia 2025 r., w których napastnicy przekształcali tę funkcję kompatybilności w furtkę do przejęcia systemu. W odpowiedzi usunięto szybkie „wejścia” do IE mode (przycisk na pasku, opcje w menu kontekstowym i hamburger menu), pozostawiając włączanie trybu wyłącznie przez ustawienia i listy witryn.

W skrócie

  • Ataki wykorzystywały 0-day w silniku JavaScript IE (Chakra) oraz drugi exploit do eskalacji uprawnień poza przeglądarkę.
  • Microsoft nie ujawnił CVE ani atrybucji, ale usztywnił IE mode: zniknęły szybkie przełączniki; uruchamianie wymaga dodania domeny do listy w ustawieniach/Politykach.
  • IE jest oficjalnie wycofany od 15 czerwca 2022 r., a IE mode w Edge istnieje dla zachowania zgodności z dziedzictwem — i to on bywa dziś „duchem IE” w środowiskach korporacyjnych.

Kontekst / historia / powiązania

IE 11 został formalnie wycofany, lecz IE mode pozwala na renderowanie starszych aplikacji (ActiveX, BHO itd.) w Edge przy użyciu silnika Trident/MSHTML właśnie po to, by przedsiębiorstwa nie musiały utrzymywać dwóch przeglądarek. Ta funkcja była i jest zależna od obecności komponentów IE w systemie i — zgodnie z dokumentacją — jest wspierana w środowiskach organizacji poprzez Enterprise Site List.

Analiza techniczna / szczegóły luki

Z opisu zespołu Microsoft Browser Vulnerability Research wynika, że łańcuch ataku wyglądał następująco:

  1. ofiara trafia na pozornie legalną stronę; 2) interfejs strony (np. flyout) nakłania do „przeładowania w IE mode”; 3) po przełączeniu, atakujący odpala 0-day w Chakra i uzyskuje RCE; 4) następnie wykorzystuje drugi exploit do EoP, przejmując pełną kontrolę nad urządzeniem. Krytycznym elementem jest opuszczenie piaskownicy Chromium poprzez wymuszenie starszego środowiska wykonawczego IE.

Zmiany w Edge obejmują usunięcie:

  • dedykowanego przycisku paska narzędzi „Otwórz w IE mode”,
  • pozycji w menu kontekstowym i w menu głównym,
    co zmniejsza powierzchnię nadużyć przez proste socjotechniczne „kliknij tutaj, by działało”. W praktyce IE mode uruchomisz teraz tylko przez Ustawienia → Default Browser oraz dopisanie danej domeny do IE mode pages list / firmowego Enterprise Site List.

Praktyczne konsekwencje / ryzyko

  • Ryzyko przejęcia stacji roboczej po wymuszeniu IE mode (RCE+EoP) — zwłaszcza tam, gdzie stacje użytkowników mogą same „przełączać” tryb dla dowolnych stron.
  • Obejście nowoczesnych mechanizmów Edge/Chromium (site isolation, nowocześniejsze mitigacje) przez cofnięcie się do modelu bezpieczeństwa IE.
  • Wpływ na user experience: zniknięcie przycisków/skrótów może chwilowo utrudnić pracę zespołom korzystającym ze starych aplikacji, dopóki admini nie skonfigurują list witryn.

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów IT / SecOps

  1. Audyt użycia IE mode — sprawdź, które aplikacje naprawdę go wymagają; zinwentaryzuj domeny i dopisz tylko te niezbędne do Enterprise Site List (Intune/GPO).
  2. Wyłącz „Allow sites to be reloaded in Internet Explorer mode” dla użytkowników, jeśli nie ma krytycznej potrzeby; zezwolenia nadawaj wyłącznie przez polityki oraz centralną listę.
  3. Twarde filtrowanie: proxy/NGFW/DNS — blokuj nieautoryzowane domeny próbujące wymuszać IE mode; monitoruj wzorce „przełączenia” (np. nietypowe żądania MSHTML/Trident).
  4. Detekcja: alertuj na łańcuch zdarzeń Edge → IE mode → procesy potomne/LOLBins → eskalacja/EoP; koreluj z telemetrią EDR (uruchomienie iexplore.exe nie powinno występować, ale komponenty MSHTML/Chakra mogą być ładowane).
  5. Segmentacja i zasada najmniejszych uprawnień na stacjach z zależnościami legacy; rozważ VDA/VDI lub izolację aplikacji (App-V, Windows Sandbox, IE-dependent app w kontenerze) jako pomost migracyjny.
  6. Plan migracji: wyznacz deadliny na usunięcie zależności od ActiveX/BHO; przypominamy — IE 11 jest EoL od 15 czerwca 2022.

Dla użytkowników końcowych

  • Nie „klikaj w flyouty” sugerujące przeładowanie w IE mode, chyba że to zatwierdzona aplikacja firmowa z listy.
  • Zgłaszaj wszelkie prośby o relaunch w IE mode spoza znanych serwisów (może to być socjotechnika).
  • Aktualizuj Edge do najnowszej wersji i stosuj polityki firmowe.

Różnice / porównania z innymi przypadkami

W przeciwieństwie do dawnych kampanii wykorzystujących MSHTML (np. ataki na kontrolki ActiveX lub luki w renderowaniu dokumentów), obecny wektor nadużywał samego przejścia do IE mode w Edge, a następnie 0-day w Chakra. Microsoft zareagował zmianą UX/punktów wejścia (hardening funkcji), a nie publikacją konkretnego CVE, co jasno pokazuje, że czynnik użytkownika (łatwość przełączenia) był krytyczną częścią łańcucha.

Podsumowanie / kluczowe wnioski

  • IE mode to konieczne zło dla części organizacji — i dlatego musi być ściśle kontrolowany listami witryn i politykami.
  • Microsoft usunął szybkie przełączniki do IE mode; teraz wejście w tryb jest działaniem intencjonalnym i audytowalnym.
  • Priorytetem powinno być wyeliminowanie zależności legacy oraz zabezpieczenie ścieżek migracji; do tego czasu — maksymalnie ograniczaj miejsca, gdzie IE mode może się w ogóle uruchomić.

Źródła / bibliografia

  1. Microsoft Browser Vulnerability Research — Securing the Future: Changes to Internet Explorer Mode in Microsoft Edge (08.10.2025). (microsoftedge.github.io)
  2. Microsoft Learn — What is Internet Explorer (IE) mode? (ostatnia aktualizacja: 18.07.2024). (Microsoft Learn)
  3. The Hacker News — Microsoft Locks Down IE Mode After Hackers Turned Legacy Feature Into Backdoor (13.10.2025). (The Hacker News)
  4. Microsoft Lifecycle — Internet Explorer 11 desktop application ended support… (15.06.2022). (Microsoft Learn)
  5. Microsoft Support — Internet Explorer mode in Microsoft Edge (instrukcje użytkowe). (Microsoft Support)

Hiszpania rozbija syndykat „GXC Team”. Zatrzymano 25-letniego lidera „GoogleXcoder”

Wprowadzenie do problemu

Hiszpańska Guardia Civil rozbiła działający na Telegramie i rosyjskojęzycznych forach syndykat cyberprzestępczy „GXC Team”, aresztując jego domniemanego lidera — 25-letniego Brazylijczyka znanego jako „GoogleXcoder”. Grupa sprzedawała w modelu Crime-as-a-Service (CaaS) zestawy phishingowe z funkcjami AI, złośliwe aplikacje na Androida do przechwytywania SMS/OTP oraz narzędzia do scamów głosowych. Celem były m.in. banki, firmy transportowe i e-commerce w Hiszpanii oraz innych krajach.

Czytaj dalej „Hiszpania rozbija syndykat „GXC Team”. Zatrzymano 25-letniego lidera „GoogleXcoder””

CVE-2025-11371: aktywnie wykorzystywana luka (0-day) w Gladinet CentreStack i Triofox — od LFI do RCE

Wprowadzenie do problemu / definicja luki

W produktach Gladinet CentreStack i Triofox wykryto podatność CVE-2025-11371, którą napastnicy aktywnie wykorzystują. Błąd to nieautoryzowany Local File Inclusion (LFI) w domyślnej instalacji i konfiguracji, umożliwiający zdalne odczytywanie plików systemowych bez logowania.

Czytaj dalej „CVE-2025-11371: aktywnie wykorzystywana luka (0-day) w Gladinet CentreStack i Triofox — od LFI do RCE”