Archiwa: Phishing - Strona 199 z 207 - Security Bez Tabu

Cyberprzestępcy handlują 183 mln skradzionych poświadczeń na Telegramie i podziemnych forach — co naprawdę się stało (i co z tym zrobić)

Wprowadzenie do problemu / definicja luki

Na przełomie października 2025 r. firma Synthient przekazała do Have I Been Pwned (HIBP) ogromny zbiór danych z ekosystemu infostealerów i podziemnych kanałów wymiany (m.in. Telegram, fora, social media). Po normalizacji i deduplikacji w HIBP pozostało 183 mln unikatowych adresów e-mail z odpowiadającymi im hasłami oraz domenami serwisów, w których były użyte. Co istotne, 16,4 mln adresów nie pojawiało się wcześniej w publicznych naruszeniach monitorowanych przez HIBP.

W skrócie

  • Skąd dane? Głównie logi infostealerów oraz listy do credential stuffing zbierane z Telegrama i forów.
  • Skala: 3,5 TB surowych plików, 23 mld wierszy; po deduplikacji 183 mln unikatowych adresów.
  • Nowość danych: ok. 9% (16,4 mln) adresów wcześniej nie widziano w HIBP.
  • Nie był to „wyciek Gmaila”: Google zdementowało doniesienia o rzekomym włamaniu do Gmaila; to agregat danych z wielu źródeł, głównie z infekcji malware.

Kontekst / historia / powiązania

Publikacje branżowe i wpisy twórcy HIBP, Troya Hunta, podkreślają, że ekosystem wycieków na Telegramie jest mocno recyklingowany: te same logi i combolisty są wielokrotnie przepakowywane i udostępniane. Dlatego każdy taki zbiór wymaga oczyszczenia i weryfikacji. Właśnie ten proces przeprowadził HIBP przed dodaniem rekordu „Synthient Stealer Log Threat Data”. Równolegle w mediach przetoczyła się fala błędnych nagłówków o „wielkim włamaniu do Gmaila”, czemu Google publicznie zaprzeczyło.

Analiza techniczna / szczegóły luki

Źródła danych. Zgodnie z opisem Synthient, ich system przez wiele miesięcy monitorował ~20 kontami Telegrama kanały powiązane z handlem logami, wykrywał linki-zaproszenia, pobierał archiwa, parsował różne, niespójne formaty i deduplikował z użyciem hashy plików oraz struktur w ClickHouse. Główne role w ekosystemie: primary sellers (sprzedawcy pierwotni), aggregators (wtórni kolekcjonerzy) i traffers (dystrybutorzy malware).

Weryfikacja i statystyki.

  • HIBP raportuje rekord „Synthient Stealer Log Threat Data” z opisem pól: adres e-mail, witryna (np. gmail.com, facebook.com) i użyte hasło. Po odrzuceniu duplikatów: 183 mln unikatowych adresów.
  • Hunt opisuje, że próbka pokazała ~91–92% adresów już znanych HIBP (recykling), a ~8–9% było nowych; po pełnym załadowaniu to 16,4 mln wcześniej nieobecnych w HIBP. Dodatkowo część zbioru stanowią listy do credential stuffing, nie tylko czyste logi infostealerów.

„To nie wyciek Gmaila”.
Google wyjaśniło, że mówimy o zebranej mieszance z wielu incydentów i infekcji, nie o świeżym ataku na jedną platformę. To nie podważa ryzyka dla użytkowników, ale zmienia interpretację: nie ma jednego „źródła włamania”, lecz wieloletni dryft poświadczeń po kanałach przestępczych.

Praktyczne konsekwencje / ryzyko

  • Przejęcia kont (ATO) przez credential stuffing i logowanie z przejętych sesji.
  • Spear-phishing i oszustwa oparte na znajomości serwisów, w których ofiara ma konta (domena z logu).
  • Lateral movement do środowisk firmowych, jeśli e-mail prywatny i służbowy współdzielą hasła.
  • Ujawnienie wzorców haseł, ułatwiające łamanie kolejnych skrótów.
  • Ryzyko reputacyjne i prawne (RODO) w razie wtórnego naruszenia w organizacji.

Warto założyć, że część haseł wciąż działa, zwłaszcza tam, gdzie MFA nie jest egzekwowane i użytkownicy recyklingują hasła.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i pracowników:

  1. Sprawdź adresy e-mail w HIBP (adres + „pwned sites” / „pastes”). W razie trafienia — natychmiastowa zmiana haseł i włączenie MFA (lub passkeys jako preferowany mechanizm).
  2. Unikalne hasło per serwis + menedżer haseł.
  3. Higiena urządzeń: aktualizacje, EDR/anty-malware, ostrożność wobec załączników i cracków — to infostealery są pierwotnym źródłem wycieku.

Dla zespołów bezpieczeństwa:

  1. Masowy reset haseł i/lub wymuszenie rotacji tam, gdzie brak MFA lub wykryto recykling.
  2. Egzekwuj MFA / passkeys dla poczty, VPN, SaaS i krytycznych aplikacji. Google i branża wskazują to jako najlepszą obronę przed kradzieżą poświadczeń.
  3. Blokada recyklingu haseł (zasady złożoności + sprawdzanie przeciw słownikom wycieków przy zmianie hasła).
  4. Detekcja ATO: reguły SIEM/UEBA na nietypowe logowania (nowe ASN, niestandardowe UA, nietypowa pora/geo), korelacja z listami adresów z HIBP.
  5. Unieważnij sesje po zmianie haseł; włącz powiadomienia o nowych logowaniach.
  6. Hunting na infostealery: IOC/IOA popularnych rodzin (Raccoon, RedLine, Vidar, Lumma itd.), kontrola egzekucji przeglądarek i kradzieży browser creds.
  7. Hardening przeglądarek (wyłączenie zapamiętywania haseł, izolacja profili), konteneryzacja przeglądania dla ról wysokiego ryzyka.
  8. Zarządzanie tożsamością: wdrożenie risk-based auth, FIDO2, ograniczenie dostępu uprzywilejowanego, just-in-time.

Różnice / porównania z innymi przypadkami

  • Combolisty vs. logi infostealerów: combolisty są zlepkiem starych wycieków (często bez kontekstu), podczas gdy logi infostealerów zawierają pary e-mail-hasło + domena, co podnosi skuteczność ATO. Zbiór Synthient zawiera obie kategorie, stąd duża objętość i konieczność deduplikacji.
  • „Jedno wielkie naruszenie” vs. „agregat wielu źródeł”: tutaj mamy agregat; brak pojedynczego punktu kompromitacji (np. „Gmail breach”).

Podsumowanie / kluczowe wnioski

  • Zbiór 183 mln unikatowych adresów z hasłami to realne ryzyko ATO na masową skalę, nawet jeśli większość wpisów to dane recyklingowane. 16,4 mln „nowych” adresów czyni ten przypadek wyjątkowo istotnym operacyjnie.
  • To nie jest wyciek jednego dostawcy poczty. To skutek lat infekcji infostealerami i wtórnego obiegu danych na Telegramie. Źródłem problemu są zainfekowane urządzenia i recykling haseł.
  • Priorytetem powinno być pełne egzekwowanie MFA/passkeys, polityka unikalnych haseł, monitoring ATO i hunting na infostealery w środowisku.

Źródła / bibliografia

  1. SecurityWeek — „Cybercriminals Trade 183 Million Stolen Credentials on Telegram, Dark Forums” (28 paź 2025). (SecurityWeek)
  2. Troy Hunt — „Inside the Synthient Threat Data” (22 paź 2025). (Troy Hunt)
  3. Have I Been Pwned — wpis „Synthient Stealer Log Threat Data”. (Have I Been Pwned)
  4. Synthient — „The Stealer Log Ecosystem: Processing Millions of Credentials a Day” (21 paź 2025). (Synthient)
  5. BleepingComputer — „Google disputes false claims of massive Gmail data breach” (27–28 paź 2025). (BleepingComputer)

Sweden’s power grid operator confirms data breach claimed by ransomware gang — co wiemy o incydencie w Svenska kraftnät (Everest)

Wprowadzenie do problemu / definicja luki

Svenska kraftnät — państwowy operator szwedzkiego systemu przesyłowego — potwierdził incydent bezpieczeństwa danych po stronie zewnętrznego, wydzielonego rozwiązania do transferu plików. Spółka podkreśliła, że dostawy energii nie zostały zakłócone, a zespół współpracuje z policją i organami cyberbezpieczeństwa nad oceną skali wycieku.

W skrócie

  • Atakujący: gang ransomware Everest twierdzący, że wykradziono ok. 280 GB danych i grożący publikacją.
  • Wektor/zakres: naruszenie dotyczy ograniczonego, zewnętrznego systemu wymiany plików; systemy krytyczne i zasilanie nie zostały naruszone według aktualnych ocen.
  • Status: trwające dochodzenie, zaangażowane służby państwowe; brak publicznej atrybucji.

Kontekst / historia / powiązania

O zdarzeniu poinformowano publicznie w niedzielę 26 października 2025 r. (wykrycie miało miejsce w sobotni wieczór, 25 października). W tym samym czasie Everest umieścił żądania i deklaracje na swoim serwisie wyciekowym. Sprawę opisały również media publiczne w Szwecji.

Analiza techniczna / szczegóły luki

Na tym etapie nie ujawniono technicznych szczegółów łańcucha ataku. Wiadomo jednak, że:

  • kompromitacja dotyczyła „avgränsad, extern filöverföringslösning” (wydzielonego, zewnętrznego narzędzia do transferu plików), co sugeruje potencjalny vektor przez aplikację MFT/SFTP/HTTP(S) z ekspozycją internetową i dostępem do buforów wymiany danych, a nie do rdzeniowych systemów sterowania (OT). Jest to wnioskowanie na podstawie opisu, nie potwierdzona informacja od operatora.
  • grupa Everest przypisała sobie atak i grozi publikacją ~280 GB danych; skala nie została niezależnie zweryfikowana.
  • operator deklaruje, że systemy krytyczne i zasilanie nie wykazują oznak naruszenia.

Co mogło się znaleźć w zasięgu?
Typowo w takich węzłach MFT przechowuje się eksporty danych organizacyjnych (umowy, projekty, raporty, dokumentację techniczną, plany prac, pliki dzienników), a także pakiety dla partnerów (np. dostawców). Jeżeli MFT pełnił rolę „skrzynki” dla wielu jednostek, to ryzyko wtórnych nadużyć (phishing ukierunkowany, podszywanie, eskalacja na partnerów) rośnie.

Praktyczne konsekwencje / ryzyko

  • Ryzyko wycieków operacyjnych: dokumentacja infrastruktury, harmonogramy prac, dane dostawców mogą umożliwić precyzyjniejsze ataki (np. spear-phishing na wykonawców podpiętych do sieci energetycznej).
  • Ryzyko reputacyjne i prawne: możliwy obowiązek notyfikacji, jeśli w plikach były dane osobowe/niejawne.
  • Brak wpływu na ciągłość zasilania (na ten moment) nie oznacza braku zagrożeń długoterminowych — wycieki informacji o topologii/zasadach operacyjnych bywają wykorzystywane w kampaniach pre-positioning.

Rekomendacje operacyjne / co zrobić teraz

Dla operatorów infrastruktury krytycznej oraz dostawców w łańcuchu SVK:

  1. Izolacja i triage MFT: pełny „containment” węzła wymiany plików, rotacja kluczy/poświadczeń, weryfikacja listy partnerów i zakresów uprawnień.
  2. Threat hunting i telemetria: przeszukanie pod kątem ewentualnych TTP grupy Everest i powiązanych narzędzi exfiltracji (np. archiwizacja, tunelowanie, nietypowe wolumeny egress). (Na dziś brak oficjalnych IoC SVK; posiłkuj się listami zaufanych CERT-ów/ISAC).
  3. Kontrole poczty i tożsamości: ujednolicone DMARC/DKIM/SPF, ostrzeżenia o podszyciach, reset haseł, MFA odporne na phishing.
  4. Hardening stref wymiany: zasada one-way (diody danych) gdzie możliwe; segregacja od AD/ERP/OT, szyfrowanie at rest, krótkie TTL dla plików, WAF + mTLS i inventory integracji.
  5. DLP i monitoring wycieków: reguły na wzorce dokumentacji technicznej, skanowanie darkweb/clearweb pod kątem artefaktów SVK.
  6. Ćwiczenia IR: scenariusze „data leak + extortion bez szyfrowania”, polityka no-pay vs. wyjątki, gotowe komunikaty do interesariuszy.

(Powyższe to dobre praktyki branżowe; SVK nie opublikowało jeszcze własnych wskazówek operacyjnych poza komunikatem o braku wpływu na zasilanie.)

Różnice / porównania z innymi przypadkami

  • Miljödata (IX–X 2025): atak łańcucha dostaw dotknął setek gmin i organizacji — przypadek o innym profilu (dostawca IT vs. operator przesyłowy), ale podobne ryzyka wtórnych nadużyć po publikacji danych.
  • Everest i sektor transport/lotnictwo (2025): grupa wcześniej przypisywała sobie ataki na podmioty z branży lotniczej — wzorzec ukierunkowania na organizacje o wysokiej wrażliwości operacyjnej. (Deklaracje grup przestępczych nie zawsze są weryfikowalne).

Podsumowanie / kluczowe wnioski

  • Potwierdzono nieuprawniony dostęp do danych w zewnętrznym systemie transferu plików w SVK; dostawy energii nie zostały zakłócone.
  • Gang Everest rości sobie prawo do ataku i grozi publikacją ~280 GB danych; trwa dochodzenie i brak jest publicznej atrybucji państwowej.
  • Największe bieżące ryzyko dotyczy wykorzystania wykradzionych dokumentów do dalszych ataków socjotechnicznych i infiltracji łańcucha dostaw.

Źródła / bibliografia

  • Komunikaty SVK o incydencie i wpływie na zasilanie. (SVK)
  • The Record (Recorded Future News): potwierdzenie incydentu i roszczeń gangu Everest (280 GB). (The Record from Recorded Future)
  • SVT Nyheter: relacja o ataku i groźbie publikacji. (SVT Nyheter)
  • Omni: przegląd ustaleń i komentarze ekspertów dot. potencjalnej wagi danych. (Omni)

Jak Mierzyć Bezpieczeństwo w NIS2 – Metryki, Audyty I Ciągłe Doskonalenie

Znaczenie metryk i audytów w zgodności z NIS2

Dyrektywa NIS2 to największa od lat zmiana w podejściu do cyberbezpieczeństwa w Europie. Jej celem nie jest biurokracja, lecz wprowadzenie realnych, mierzalnych standardów bezpieczeństwa – organizacje muszą nie tylko wdrożyć środki ochrony, ale także wykazać ich skuteczność. Oznacza to konieczność stałego monitorowania systemów, regularnego mierzenia efektywności zabezpieczeń i przeprowadzania audytów, aby udowodnić przed regulatorami i interesariuszami, że cyberbezpieczeństwo jest utrzymywane na wysokim poziomie i podlega ciągłemu doskonaleniu.

Czytaj dalej „Jak Mierzyć Bezpieczeństwo w NIS2 – Metryki, Audyty I Ciągłe Doskonalenie”

Mem3nt0 mori: jak Kaspersky powiązał APT ForumTroll ze szpiegowskim Dante od Memento Labs (ex-Hacking Team)

Wprowadzenie do problemu / definicja luki

Kaspersky opisał dziś kulisy kampanii Operation ForumTroll (marzec 2025), w której kliknięcie spersonalizowanego linku phishingowego prowadziło do cichej infekcji przez przeglądarkę Chrome. Badacze wykryli i zgłosili nową podatność CVE-2025-2783 (sandbox escape w komponencie Mojo), którą Google załatał w stabilnym wydaniu 134.0.6998.177/.178 z 25 marca 2025 r.

W toku dalszej analizy Kaspersky powiązał tę kampanię i pokrewny arsenał z komercyjnym spyware “Dante” rozwijanym przez Memento Labs — firmę, którą świat znał wcześniej jako Hacking Team.


W skrócie

  • Wejście: e-mail phishingowy ze spersonalizowanym, krótkotrwałym URL-em; sama wizyta w witrynie uruchamiała exploit 0-day na Chrome (Windows).
  • Eksploit: CVE-2025-2783 — eskalacja z sandboksa (Mojo/IPC), potwierdzona przez Google i NVD; poprawka 25.03.2025.
  • Łańcuch: validator → exploit → persistent loader → etap LeetAgent → właściwe moduły szpiegowskie (Dante).
  • Atrybucja: zbieżności kodu, TTP, ścieżek FS, mechanizmów trwałości oraz jawne ciągi “Dante” w binariach; kontynuacja linii RCS (Da Vinci/Galileo) po rebrandingu Hacking Team → Memento Labs.

Kontekst / historia / powiązania

Hacking Team to jedna z najbardziej rozpoznawalnych marek rynku spyware (RCS: Da Vinci/Galileo). Po wycieku ~400 GB danych w 2015 r. firma została w 2019 r. przejęta przez InTheCyber i przemianowana na Memento Labs. W 2023 r. na konferencji ISS World MEA firma ujawniła nazwę nowego produktu: DANTE. Według Kaspersky’ego kod RCS ewoluował do 2022 r., gdy został zastąpiony przez Dante.

Szersze mapowanie rynku komercyjnego spyware (NSO/Intellexa/Candiru/Paragon/Quadream/RCS Labs/Memento Labs itd.) potwierdza ciągłość działalności dostawców po rebrandingu.


Analiza techniczna / szczegóły luki

Łańcuch ataku (high-level)

  1. Phishing URL (krótko żyjący, spersonalizowany) → 2. Validator (sprawdza środowisko) → 3. Exploit CVE-2025-2783 (ucieczka z sandboksa Chrome/Windows) → 4. Persistent loader (utrwalenie) → 5. LeetAgent (staging/koordynacja) → 6. Dante (moduły szpiegowskie).

CVE-2025-2783 (Chrome Mojo)

  • Błąd klasy incorrect handle w Mojo IPC na Windows umożliwiający sandbox escape przy udziale złośliwego pliku/strony.
  • Status: wykryty in-the-wild, załatany 25.03.2025; zgłaszający: Boris Larin, Igor Kuznetsov (Kaspersky); wektor CVSS3.1 wg CISA-ADP: AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H (8.3).

Artefakty i IOCs (wybrane wzorce)

  • Folder modułów: w %LocalAppData%, nazwy katalogu i plików bez rozszerzeń to 8-bajtowe Base64; jeden z plików ma nazwę równą katalogowi — to pomocny wzorzec detekcyjny aktywnej infekcji.
  • Próbki: Kaspersky publikuje skróty (loader/LeetAgent/Dante) w sekcji IOCs.

Atrybucja do Dante / Memento Labs

  • Po zdjęciu VMProtect odkryto ciągi “Dante” oraz odniesienie do wersji “2.0” zgodne z nazwą prelekcji ISS World MEA 2023; wykryto liczne podobieństwa kodowe między późnymi próbkami RCS a Dante. Wniosek: nowy produkt zastąpił dotychczasową bazę w 2022 r.

Praktyczne konsekwencje / ryzyko

  • Ataki bezklikalne po kliknięciu linku: samo otwarcie strony w Chrome wystarczało do naruszenia (brak dodatkowej interakcji).
  • Ryzyko pełnego przejęcia hosta: sandbox escape w Chrome połączony z loaderem i modułami daje zdolności pełnego szpiegostwa (zrzuty ekranu, exfiltracja, keylogging, audio/wideo — typowe dla linii RCS/Dante).
  • Cele wysokoprofilowe: charakter kampanii (APT, spear-phishing, krótkotrwała infrastruktura) wskazuje na ukierunkowaną cyber-szpiegowską operację.

Rekomendacje operacyjne / co zrobić teraz

1) Natychmiastowe działania IT/SecOps

  • Zaktualizuj Chrome do ≥ 134.0.6998.177/.178 (Windows); sprawdź kanał Extended Stable.
  • Hunting po artefaktach: przeszukaj %LocalAppData% pod kątem katalogów/plików nazwanych 8-bajtowym Base64 (bez rozszerzeń) oraz zbieżnych mechanizmów trwałości. Zweryfikuj hosty z podejrzanymi folderami.
  • Weryfikacja IOCs: porównaj próbki z hashami opublikowanymi przez Kaspersky (loader/LeetAgent/Dante).

2) Detekcja i twardnienie

  • EDR/XDR: reguły pod CVE-2025-2783 (Mojo/handle dup), ładowanie niezaufanych DLL, nietypowe child-procesy Chrome → LOLBins, tworzenie trwałości przez rzadko używane ścieżki użytkownika. (Wzorce zgodne z opisem łańcucha Kaspersky).
  • Gateway/Proxy: czasowo-ograniczone, spersonalizowane URL-e — wzmacniać detekcję na krótko żyjące domeny, TLS fingerprinting, anomalię HTTP.
  • Kontrola przeglądarki: polityki blokujące ładowanie Mojo IPC z nieznanych źródeł, ograniczanie rozszerzeń, izolacja profili uprzywilejowanych.

3) Zarządzanie podatnościami

  • CVE-2025-2783 znajduje się w CISA KEV — egzekwuj priorytetową poprawkę zgodnie z terminem BOD 22-01 (organizacje publiczne/regulated).

4) Świadomość i procedury

  • Trenuj rozpoznawanie spear-phishingu i politykę bezpiecznego otwierania linków (otwieranie w przeglądarce izolowanej/VDI dla wrażliwych ról).

Różnice / porównania z innymi przypadkami

  • Pegasus/Intellexa/Candiru vs. Dante: ekosystemy różnią się łańcuchami eksploatacji (mobilne vs. desktopowe), ale model biznesowy (ofensywne zdolności dla rządów) i ukrywanie tożsamości w kodzie są wspólne. W przypadku Dante rzadki jest wprost odnaleziony znacznik nazwy w binariach, co ułatwiło atrybucję.
  • RCS (Da Vinci/Galileo) → Dante: ciągłość kodowa i TTP sugeruje ewolucję produktu po rebrandingu Hacking Team → Memento Labs (2022: przejście na Dante).

Podsumowanie / kluczowe wnioski

  • Operation ForumTroll to przykład APT-grade browser exploit chain: phishing → Chrome 0-day (CVE-2025-2783) → staged spyware. Google załatał błąd 25.03.2025.
  • Atrybucja do Dante/Memento Labs została potwierdzona kombinacją cech kodu, TTP i artefaktów — to “powrót” Hacking Team w nowej odsłonie.
  • Organizacje powinny patchować, huntować wg wzorców FS/IOC, wzmacniać EDR/XDR i segmentować ryzyko przeglądarki.

Źródła / bibliografia

  1. Kaspersky Securelist – “Mem3nt0 mori – The Hacking Team is back! / How we linked ForumTroll APT to Dante spyware” (analiza łańcucha, IOCs, atrybucja do Dante/Memento Labs), 27.10.2025. (Securelist)
  2. Google – Chrome Releases: Stable Channel Update for Desktop 134.0.6998.177/.178 (potwierdzenie CVE-2025-2783; “exploited in the wild”), 25.03.2025. (Chrome Releases)
  3. NVD (NIST) – CVE-2025-2783 (opis, odwołanie do CISA KEV, wektor CVSS), aktual. 24.10.2025. (NVD)
  4. Kaspersky Blog – Operation ForumTroll: APT attack with Google Chrome zero-day exploit chain, 25.03.2025. (Securelist)
  5. Atlantic Council – “Mythical Beasts and where to find them: Mapping the global spyware market…” (kontekst rynku, Memento Labs/Hacking Team), 04.09.2024. (Atlantic Council)

Qilin (Agenda) – jak działa jedna z najaktywniejszych operacji ransomware w 2025 r. według Cisco Talos

Wprowadzenie do problemu / definicja luki

Cisco Talos opisał szereg incydentów z 2025 r., które ujawniają aktualny łańcuch ataku Qilin (dawniej Agenda) – jednego z najbardziej „produktywnych” gangów ransomware. Zespół IR Talosa obserwuje ponad 40 publikacji ofiar miesięcznie na stronie wycieków Qilin, ze szczytami aktywności sięgającymi ~100 przypadków (czerwiec i sierpień 2025). Najmocniej cierpi produkcja, a dalej usługi profesjonalne i handel hurtowy.


W skrócie

  • Model RaaS: Qilin działa jako usługa, rozwijając platformę i udostępniając ją afilantom; podwójny szantaż (szyfrowanie + wyciek).
  • Początkowy dostęp: w badanych sprawach częste są nadużycia ważnych kont/VPN bez MFA, czasem zmiany GPO w AD w celu włączenia RDP; obserwowano także spear-phishing i wykorzystanie wycieków haseł.
  • Eksfiltracja: paczkowanie WinRAR, przesył przez legalne narzędzia (np. Cyberduck do Backblaze), „ręczne” przeglądanie danych nawet notatnikiem/mspaint.
  • Ruch boczny i utrzymanie: PsExec, modyfikacje zapory i RDP, instalacje wielu RMM (AnyDesk, ScreenConnect, Chrome Remote Desktop itd.).
  • Szyfrowanie: wariant Qilin.B (Rust) używa AES-256-CTR lub ChaCha20 + RSA-4096 (OAEP), terminacja usług backup/DB/AV, czyszczenie logów i niszczenie VSS.
  • Skala zagrożenia: w II kw. 2025 Qilin był najaktywniejszym ransomware wobec podmiotów SLTT w USA (MS-ISAC).

Kontekst / historia / powiązania

Qilin (wcześniej Agenda) działa od lipca 2022 r., oferując RaaS i prowadząc wycieki danych na własnym portalu. Z czasem ewoluował technicznie (m.in. przepisany na Rust; utrzymano też wersje Linux/ESXi) i organizacyjnie (aktywny rekrut na forach). W 2024 r. HHS/HC3 publikował profil zagrożenia wskazujący na spear-phishing i warianty Windows/Linux; w 2024/2025 Halcyon śledził wariant Qilin.B z usprawnioną kryptografią i ewakuacją kluczowych artefaktów.

W 2025 r. incydenty przypisywane Qilin odnotowano w różnych sektorach i krajach; przykładem jest głośny atak na japoński Asahi Group (zakłócenia produkcji i publikacja danych).


Analiza techniczna / szczegóły luki

Wejście / inicjalny dostęp

  • Nadużycie ważnych kont i brak MFA na VPN; wzmożone próby NTLM po pojawieniu się haseł w darknecie; możliwe zmiany GPO w celu ułatwienia RDP.
  • (Historycznie) spear-phishing, w tym złośliwe załączniki i kradzież poświadczeń.

Rozpoznanie i zbieranie

  • nltest, net user, whoami /priv, tasklist; narzędzia skanowania sieci; dedykowany pakiet do zrzutu haseł (NirSoft, Mimikatz). Modyfikacja WDigest (UseLogonCredential=1) ułatwiająca pozyskanie plaintextów. Dane agregowane skryptami i eksportowane (SMTP, pliki wynikowe z kodowaniem Windows-1251).

Eksfiltracja

  • Archiwizacja WinRAR, inspekcja dokumentów nawet przez notepad.exe/mspaint.exe/iexplore.exe; nadużycie Cyberduck do chmury (Backblaze) z podziałem na części.

Eskalacja uprawnień i ruch boczny

  • Dodawanie napastniczych kont do Local Administrators, wymuszanie RDP, tworzenie udziałów typu net share c=c:\ /grant: everyone,full; rozproszenie przez PsExec. Obserwacje wielu RMM (AnyDesk, ScreenConnect, Distant Desktop, QuickAssist, Chrome Remote Desktop).

Unikanie obrony

  • Silnie zaciemniony PowerShell z wyłączeniem AMSI, obejściem walidacji TLS oraz włączeniem Restricted Admin dla RDP (hash-based auth).

Przygotowanie środowiska i trwałość

  • Wyłączanie/ubijanie procesów AV/backup/DB, czyszczenie logów, tworzenie Scheduled Task („TVInstallRestore”) i wpisów Run podszywających się pod TeamViewer.

Szyfrowanie (Qilin.B)

  • Kombinacja AES-256-CTR (jeśli dostępne AES-NI) / ChaCha20 (fallback) + RSA-4096/OAEP do ochrony kluczy; noty okupu README-RECOVER-[company_id].txt; rozszerzenia plików wg unikalnego ID ofiary. Wykrywana enumeracja udziałów i dysków, ukierunkowanie na ClusterStorage/CSV (Hyper-V/VM/VHDX) przy jednoczesnym unikaniu pętli po symlinkach. Usuwanie VSS i autodestrukcja binarium.

IOCs i detekcje

  • Talos publikuje wykazy IOC (GitHub), Snort SID oraz ClamAV (np. Win.Ransomware.Qilin, SystemBC, Cobalt Strike).

Praktyczne konsekwencje / ryzyko

  • Czas przestoju: ataki celują w środowiska wirtualizacji i plików współdzielonych (CSV/Hyper-V), co zwiększa wpływ na produkcję i usługi krytyczne.
  • Ryzyko reputacyjne i prawne przez systematyczną ekfiltrację (Backblaze/Cyberduck) oraz publikację na stronie wycieków.
  • Trend rynkowy: Qilin był w Q2 2025 najaktywniejszą rodziną wobec SLTT w USA, co potwierdza jego dojrzałość operacyjną i tempo działania.
  • Incydenty głośne medialnie (np. Asahi) pokazują realny wpływ na produkcję i łańcuch dostaw.

Rekomendacje operacyjne / co zrobić teraz

Kontrole prewencyjne

  1. MFA bez wyjątków na VPN, RDP, poczcie i aplikacjach krytycznych; wymuś klient-based MFA dla kont uprzywilejowanych.
  2. Higiena tożsamości: rotacja haseł po wyciekach, blokady na „password spraying” (T1110.003), monitorowanie NTLM.
  3. Twardnienie RDP: wyłącz zdalne logowanie tam, gdzie zbędne; kontrola fDenyTSConnections, ograniczenia sieciowe/Jump Host; Restricted Admin tylko jeśli świadomie zarządzany.
  4. Egress/Exfil kontrola: DLP/CTI-driven blokady dla Backblaze i nietypowych klientów S3/WebDAV; monitoruj użycie Cyberduck, WinRAR w trybie archiwizacji masowej.
  5. Backup i odzyskiwanie: izolowane kopie, testy odtwarzania, ochrona VSS przed usuwaniem; segmentacja Hyper-V/CSV.

Detekcja i reagowanie (SOC/SIEM/EDR)

  • Reguły: Snort/ClamAV zgodnie z publikacją Talos; korelacje dla PsExec, net share c=, WDigest UseLogonCredential=1, zaciemnionego PowerShell wyłączającego AMSI, nietypowego schtasks /Create /SC ONLOGON.
  • Artefakty RMM: wykrywaj instalacje/połączenia AnyDesk/ScreenConnect/Chrome Remote Desktop/QuickAssist poza listą zatwierdzonych rozwiązań.
  • Kryptonotatki/rozszerzenia: alarmy na README-RECOVER-[company_id].txt oraz nowe rozszerzenia „.[company_id]”.

Procedury IR

  • Izolacja i triage hostów z aktywnością WinRAR/Cyberduck, ścieżkami Backblaze, masową terminacją usług bezpieczeństwa/backup.
  • Łańcuch dowodowy: zabezpieczenie logów przed czyszczeniem (wczesna centralizacja, forward-only, write-once).
  • Komunikacja kryzysowa i ocena ryzyka wycieku (PII, IP, dane produkcyjne).

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

  • Qilin vs. „typowy” RaaS 2025: podobnie jak inne operacje, Qilin intensywnie eksfiltruje i używa RMM/LOLBINs; odróżnia go ukierunkowanie na CSV/Hyper-V i szerokie wykorzystanie legalnych narzędzi do eksfiltracji (Cyberduck).
  • Qilin.B (Rust) wyróżnia kombinowany wybór szyfru (AES-NI → AES-CTR, fallback → ChaCha20) i mocną ochronę kluczy RSA-4096/OAEP, co komplikuje odzysk bez kluczy.
  • Wieloplatformowość: raporty z 2025 r. pokazują nawet wdrażanie binarek Linux na systemach Windows przez RMM/BYOVD, co utrudnia detekcję.

Podsumowanie / kluczowe wnioski

Qilin utrzymuje wysokie tempo kampanii i dojrzały łańcuch ataku: kradzież poświadczeń (WDigest/Mimikatz/NirSoft), ruch boczny (PsExec/RDP/RMM), eksfiltracja przez chmurę (Cyberduck→Backblaze), a następnie szyfrowanie zoptymalizowane dla środowisk wirtualnych (CSV/Hyper-V) i agresywna ewakuacja artefaktów. Obrona wymaga dyscypliny IAM/MFA, twardnienia RDP/VPN, kontroli egress/exfil, oraz predefiniowanych detekcji TTP. Publikacje Cisco Talos i analizy branżowe (HHS/HC3, Halcyon, CIS, Trend Micro) dostarczają praktycznych wskaźników i reguł do natychmiastowego wdrożenia.


Źródła / bibliografia

  1. Cisco Talos – Uncovering Qilin attack methods exposed through multiple cases, 26 października 2025 (TTP, IOCs, Snort/ClamAV). (Cisco Talos Blog)
  2. Halcyon – New Qilin.B Ransomware Variant…, 24 października 2024 (kryptografia, mechanika szyfrowania). (Halcyon)
  3. HHS/HC3 – Qilin (aka Agenda) Threat Profile, 18 czerwca 2024 (wektory wejścia, Windows/Linux). (hhs.gov)
  4. CIS (MS-ISAC) – Qilin: Top Ransomware Threat to SLTTs in Q2 2025, 11 września 2025 (trend aktywności). (CIS)
  5. Trend Micro – Agenda Ransomware Deploys Linux Variant on Windows Systems…, 23 października 2025 (nietypowe wdrożenia Linux przez RMM/BYOVD). (www.trendmicro.com)

SafePay atakuje Xortec: grupa ransomware grozi publikacją danych niemieckiego dostawcy monitoringu wizyjnego

Wprowadzenie do problemu / definicja luki

Grupa ransomware SafePay dodała Xortec GmbH (niemiecki dystrybutor i integrator systemów profesjonalnego monitoringu wizyjnego oraz infrastruktury IP) na swoją stronę wyciekową i twierdzi, że wykradła dane spółki. Według pierwszych doniesień termin spełnienia żądań przypada na 27 października 2025 r. (dzisiaj), co ma zwiększyć presję negocjacyjną na ofierze. Na ten moment brak publicznych dowodów ujawnionych plików, lecz wpis na DLS (Data Leak Site) zwykle poprzedza publikację „dowodu życia” lub pakietów danych.

W skrócie

  • Kto? SafePay – jedna z najbardziej aktywnych grup ransomware 2025 r.
  • Co? Roszczenie ataku na Xortec; wpis na stronie wyciekowej (double extortion).
  • Kiedy? Wpis wykryto 24–27 października 2025 r.; deadline wyznaczony na 27.10.2025.
  • Dlaczego to ważne? Xortec obsługuje rozwiązania dla monitoringu i infrastruktury sieciowej – ewentualny wyciek może ujawnić dane projektowe, konfiguracje, schematy klientów i dostęp serwisowy.
  • Kontekst rynkowy: SafePay od końca 2024 r. konsekwentnie rośnie, celując w organizacje w DE/UK/US; raporty branżowe plasują ją w czołówce operacji ransomware 2025 r.

Kontekst / historia / powiązania

SafePay pojawił się jesienią 2024 r. i szybko stał się jedną z najaktywniejszych operacji, budując reputację dzięki agresywnemu double extortion (szyfrowanie + kradzież danych) i głośnym kampaniom przeciw dużym podmiotom. Analitycy zwracają uwagę na szybkie tempo publikacji ofiar oraz presję czasową w żądaniach okupu.

Analiza techniczna / szczegóły luki

TTPs SafePay (wybór, na podstawie raportów publicznych):

  • Wektory dostępu początkowego: częste wykorzystanie słabych/kompromitowanych poświadczeń i ekspozycji zdalnego dostępu (VPN/RDP), a także spear-phishing i „call-back” (vishing) do eskalacji uprawnień.
  • Ekfiltracja i przygotowanie wycieku: exfil danych przed szyfrowaniem; strukturyzacja listingów na DLS z twardymi deadline’ami; użycie wskaźników (mutexy) zapobiegających wielokrotnemu uruchomieniu ładunku.
  • Model operacyjny: niezależna operacja (nie klasyczny RaaS), szybkie „time-to-encrypt”, elementy kodu i praktyk znane z ekosystemu LockBit (modyfikacje narzędzi i taktyk).

Uwaga: w przypadku Xortec szczegóły wektora wejścia i zakres potencjalnie wykradzionych danych nie zostały publicznie potwierdzone w momencie publikacji; jedynym twardym artefaktem jest wpis na stronie wyciekowej przypisany SafePay.

Praktyczne konsekwencje / ryzyko

  • Ryzyko dla klientów i partnerów Xortec: możliwe ujawnienie dokumentacji projektowej, topologii sieci, konfiguracji kamer/NVR, kont serwisowych oraz danych kontaktowych partnerów i klientów. Taki wyciek ułatwia ransomware z wtórnej kompromitacji i atak łańcucha dostaw (pivotowanie do środowisk klientów). W branży bezpieczeństwa fizycznego ekspozycja konfiguracji bywa równoznaczna z ułatwieniem sabotażu systemów CCTV. (Wniosek analityczny na podstawie profilu biznesowego Xortec i modus operandi SafePay).
  • Ryzyko ciągłości działania: presja czasu (deadline 27.10.2025) zwiększa prawdopodobieństwo publikacji paczek „proof-pack” i eskalacji taktyk wymuszających kontakt.

Rekomendacje operacyjne / co zrobić teraz

Dla Xortec i podmiotów pokrewnych (dystrybutorzy/integratorzy security-tech):

  1. Zarządzanie incydentem: izolacja segmentów, rotacja poświadczeń uprzywilejowanych, przegląd kont serwisowych i dostępów klientowskich; weryfikacja dzienników VPN/IdP pod kątem anomalii.
  2. Redukcja ekspozycji zdalnej: wymusić MFA na wszystkich kanałach zdalnych (VPN/RDP/SSH), odciąć przestarzałe profile i nieużywane konta.
  3. Kontrola danych klientów: poinformować partnerów o potencjalnym wycieku, udostępnić wskaźniki kompromitacji (IoC) i rekomendacje rotacji haseł/API.
  4. Twarde zabezpieczenia endpointów/serwerów: blokady wykonywalnych w ścieżkach użytkownika, deny-by-default dla skryptów i makr, polityki application allow-listing/ring-fencing dla narzędzi administracyjnych.
  5. Przygotowanie na publikację danych: plan PR/obsługi prawnej, monitoring DLS/paste-sites; gotowe playbooki de-tokenizacji/rotacji kluczy, natychmiastowe unieważnianie certyfikatów i kluczy dostępowych, jeśli pojawią się w wycieku.
  6. Współpraca z organami i zespołami CSIRT: raport do właściwych służb i skorzystanie z publicznych wytycznych dot. reakcji na ransomware.

Dla klientów końcowych (używających rozwiązań dystrybuowanych/serwisowanych przez Xortec):

  • Zmień poświadczenia (lokalne i chmurowe) powiązane z usługami serwisowymi Xortec; przejrzyj listy zaufanych adresów IP i kluczy API.
  • Audyt konfiguracji CCTV/NVR/VMS: wyłącz domyślne konta, włącz logowanie i alertowanie o nieudanych logowaniach, wymuś TLS i segmentację sieci (oddziel CCTV od sieci biurowej).
  • Śledź publikacje wyciekowe przypisywane do Xortec – szybka rotacja sekretów minimalizuje okno nadużycia.

Różnice / porównania z innymi przypadkami

W porównaniu z klasycznymi operacjami RaaS, SafePay działa bardziej „jednolicie” (mniej afiliantów, bardziej spójne TTPs), częściej stosuje agresywną presję czasową oraz dużą liczbę ofiar miesięcznie. Raporty z 2025 r. potwierdzają wysoką dynamikę (dziesiątki ofiar/miesiąc), co zbliża SafePay do topowych graczy ubiegłych lat pod względem skali, choć zestaw narzędzi i procedur wskazuje na adaptacje znanych technik (np. elementy z ekosystemu LockBit).

Podsumowanie / kluczowe wnioski

  • Incydent nie został jeszcze oficjalnie potwierdzony przez Xortec, ale wpis SafePay na DLS oraz monitoring niezależnych serwisów śledzących ransomware zwiększają wiarygodność roszczenia.
  • Ryzyko wtórne dotyczy partnerów i klientów – szczególnie jeśli w wycieku znajdą się konfiguracje systemów i dane dostępowe.
  • Organizacje w ekosystemie security-tech powinny od razu wykonać rotację sekretów i twarde utwardzenie zdalnych dostępów, bazując na sprawdzonych guideline’ach reagowania na ransomware.

Źródła / bibliografia

  1. Security Affairs – „Safepay ransomware group claims the hack of Xortec (DE)” (27.10.2025). (Security Affairs)
  2. Ransomware.live – wpis ofiary „xortec.de” (24.10.2025). (ransomware.live)
  3. Quorum Cyber – SafePay Ransomware Report (TTPs, aktywność 2025). (Quorum Cyber)
  4. Bitdefender – „SafePay Ransomware: How a Non-RaaS Group Executes…” (analiza trendów 2025). (Bitdefender)
  5. CISA – Ransomware Guide (wytyczne reagowania i prewencji). (CISA)

Nowa technika „CoPhish”: kradzież tokenów OAuth przez agentów Microsoft Copilot Studio

Wprowadzenie do problemu / definicja luki

Badacze Datadog Security Labs opisali nową technikę phishingu — CoPhish — która wykorzystuje agentów Microsoft Copilot Studio jako „wrapper” do dostarczania fałszywych żądań zgody OAuth z legalnej domeny Microsoftu (copilotstudio.microsoft.com). Atak kończy się uzyskaniem tokenu dostępu użytkownika i może prowadzić do przejęcia skrzynki pocztowej, OneNote czy innych zasobów przez Microsoft Graph. Microsoft potwierdził, że pracuje nad poprawkami w produktach, podkreślając jednocześnie element socjotechniczny ataku.

W skrócie

  • Wejście: ofiara trafia na udostępnioną stronę „demo” agenta Copilot Studio hostowaną w domenie Microsoftu i klika Login.
  • Przebieg: przycisk logowania przekierowuje do złośliwej aplikacji OAuth (wewnętrznej lub zewnętrznej), a po akceptacji uprawnień agent automatycznie ekfiltruje User.AccessToken np. przez żądanie HTTP do serwera atakującego (np. Burp Collaborator). Żądanie wychodzi z IP Microsoftu, więc ruch ofiary nie zdradza exfiltracji.
  • Zasięg uprawnień: nawet po niedawnych zmianach w Entra ID, konta z rolami administracyjnymi nadal mogą nadać szerokie uprawnienia aplikacjom; zwykli użytkownicy wciąż mogą zgodzić się na pewne zakresy (np. OneNote).
  • Status: Microsoft zapowiada dodatkowe zabezpieczenia i „utwardzenie” doświadczeń związanych ze zgodą/zarządzaniem aplikacjami.

Kontekst / historia / powiązania

CoPhish to wariant dobrze znanego „consent phishing” (MITRE ATT&CK T1528 – Steal Application Access Token), w którym ofiara sama przyznaje dostęp złośliwej aplikacji. W 2025 r. Microsoft zaostrzał domyślne polityki zgody w Entra ID, ograniczając możliwość nadawania niektórych uprawnień przez użytkowników końcowych. Jednak wektor pozostaje aktualny, zwłaszcza wobec administratorów aplikacji i w scenariuszach wewnętrznych.

Analiza techniczna / szczegóły luki

  1. Host zaufany przez użytkowników
    Atakujący tworzy agenta Copilot Studio (we własnym tenantcie lub w skompromitowanym) i włącza „Demo website”, uzyskując URL w domenie Microsoftu. To znacząco zwiększa wiarygodność kampanii.
  2. Backdoor w systemowym „Sign-in topic”
    Wbudowany temat logowania można modyfikować. Po akcji „Authenticate” badacze dodali krok „HTTP Request”, który wysyła zawartość zmiennej User.AccessToken w nagłówku (np. Token) do kontrolowanego endpointu.
  3. Złośliwa aplikacja OAuth (multi-tenant)
    Atakujący rejestruje aplikację z odpowiednimi zakresami Graph i redirect URL https://token.botframework.com/.auth/web/redirect, po czym wpisuje client ID/secret do konfiguracji uwierzytelniania agenta. Kliknięcie „Login” kieruje ofiarę do workflow zgody.
  4. Tokeny i zakresy
    W scenariuszu użytkownika wewnętrznego badacze uzyskali token z Mail.ReadWrite, Mail.Send, Notes.ReadWrite. Dla Application Administrator możliwe są nawet zakresy aplikacyjne (Application.ReadWrite.All) i szerokie Files/Sites.*.All.
  5. Ślady w logach
    • Entra ID Audit: „Consent to application”.
    • Microsoft 365 Audit: operacja „Consent to application”.
    • Copilot Studio (Power Platform): BotCreate, BotComponentUpdate na *.topic.Signin.

Praktyczne konsekwencje / ryzyko

  • Business Email Compromise-as-a-Service: token daje atakującemu możliwość czytania/wykonywania akcji w imieniu użytkownika (np. wysyłka spear-phishingu z wewnętrznego konta).
  • Uprawnienia administracyjne: jeśli ofiarą jest Application Administrator, konsekwencje obejmują szerokie uprawnienia w Graph i potencjalne trwałe mechanizmy utrzymania dostępu.
  • Efekt „zaufanej domeny”: link w domenie Microsoftu zmniejsza czujność użytkowników i może obchodzić proste filtry reputacyjne.

Rekomendacje operacyjne / co zrobić teraz

  1. Zaostrz polityki zgody w Entra ID
    • Ustal niestandardową politykę ograniczającą, kto i na jakie zakresy może wyrażać zgodę; przypisz ją jako domyślną.
    • Minimalnie: „Allow user consent for apps from verified publishers, for selected permissions (Recommended)” albo surowiej — wyłącz zgodę użytkownika i włącz workflow żądań od użytkowników.
  2. Odbierz wszystkim możliwość rejestracji aplikacji
    Domyślnie każdy członek może tworzyć aplikacje. Zablokuj to ustawienie, aby utrudnić wewnętrzny „consent phishing”.
  3. Monitoring i detekcja
    • Alerty na „Consent to application” (Entra/M365 Audit).
    • Zdarzenia Power Platform: BotCreate, BotComponentUpdate z *.topic.Signin.
    • Korelacje z anomaliami w Graph (np. wysyłka z konta, nietypowe dostępy do OneNote/Files).
  4. Ogranicz powierzchnię ataku w Copilot Studio
    • Przeglądaj modyfikacje systemowego Sign-in topic.
    • Wyłącz i usuwaj nieużywane lub dziwnie nazwane boty/„demo websites”.
  5. Zasady dla kont uprzywilejowanych
    • MFA phishing-resistant, PIM/JIT dla ról Application/Cloud Application Admin.
    • Oddzielne konta admin-only (bez licencji do codziennej pracy), zasady CA blokujące „risky consent”. (Najlepsze praktyki zgodne z dokumentacją Microsoft).
  6. Edukacja użytkowników i zespół helpdesk
    • Szkolenia dot. zgody na aplikacje i rozpoznawania UX Copilot Studio vs. Microsoft 365 Copilot.
    • Procedura szybkiego cofania zgody i unieważniania tokenów (w tym odwołanie grantów w Entra).

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

  • Typowy „consent phishing” wykorzystuje link do strony zgody z domen niezwiązanych z Microsoftem lub z generics. CoPhish „owija” go w zaufaną domenę Copilot Studio i automatyzuje exfiltrację tokenu po stronie agenta (serwer Microsoft), co zaciemnia ślady w sieci ofiary.
  • Zmiany w Entra utrudniają część kampanii — ale nie dotyczą ról administracyjnych i niektórych wewnętrznych zakresów, więc powierzchnia ataku pozostaje.

Podsumowanie / kluczowe wnioski

CoPhish to nie „magiczna” luka w kryptografii OAuth, lecz sprytne nadużycie funkcji Copilot Studio i procesu zgody. Siłą ataku jest legitymizacja (domena Microsoft) i automatyzacja wycieku tokenu. Krytyczne są polityki zgody, odebranie prawa rejestracji aplikacji, monitoring zdarzeń oraz higiena ról administracyjnych. Microsoft zapowiada dalsze utwardzenie mechanizmów — nie zwalnia to jednak z wdrożenia kontroli po stronie tenantów.

Źródła / bibliografia

  1. Datadog Security Labs — CoPhish: Using Microsoft Copilot Studio as a wrapper for OAuth phishing (analiza techniczna, IoC, detekcje). (securitylabs.datadoghq.com)
  2. BleepingComputer — New CoPhish attack steals OAuth tokens via Copilot Studio agents (komentarz Microsoft, kontekst). (BleepingComputer)
  3. Microsoft Learn — Manage app consent policies (Entra ID; konfiguracja polityk zgody). (Microsoft Learn)
  4. Microsoft Learn — Configure how users consent to applications (ustawienia zgody użytkownika; zalecenia). (Microsoft Learn)
  5. MITRE ATT&CK — T1528: Steal Application Access Token (mapowanie techniki). (MITRE ATT&CK)