Archiwa: Encryption - Strona 8 z 9 - Security Bez Tabu

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

Wprowadzenie do problemu / definicja luki

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

W skrócie

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

Kontekst / historia / powiązania

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

Analiza techniczna / szczegóły luki

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

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

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

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

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

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

Praktyczne konsekwencje / ryzyko

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

Rekomendacje operacyjne / co zrobić teraz

Prewencja

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

Detekcja

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

Reagowanie

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

Różnice / porównania z innymi przypadkami

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

Podsumowanie / kluczowe wnioski

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

Źródła / bibliografia

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

CVE‑2019‑0708 „BlueKeep”

TL;DR

BlueKeep (CVE‑2019‑0708) to przed‑autentykacyjna podatność RCE w usłudze Remote Desktop Services/TermService (RDP) w starszych Windows (XP, Vista, 7; Server 2003/2008/2008 R2). Umożliwia zdalne wykonanie kodu bez interakcji użytkownika i ma potencjał „wormowalny”. NLA redukuje ryzyko automatycznej propagacji, ale nie eliminuje RCE jeśli atakujący ma ważne poświadczenia — łatka jest obowiązkowa (np. KB4499164/KB4499175, KB4499180, KB4500331). CVSS v3.1: 9.8 (Critical).


Krótka definicja techniczna

CVE‑2019‑0708 to błąd w implementacji RDP w komponencie jądra (m.in. termdd.sys/RDS), który pozwala niezalogowanemu napastnikowi na wysłanie specjalnie przygotowanych PDU w fazie zestawiania kanałów RDP i osiągnięcie zdalnego wykonania kodu w kontekście systemowym. W praktyce umożliwia to wejście (Initial Access) lub ruch boczny (Lateral Movement) przez RDP.


Gdzie występuje / przykłady platform

  • Windows XP SP3 (x86/x64/Embedded), Server 2003 (SP2/R2), Vista SP2, Windows 7 SP1, Windows Server 2008 / 2008 R2 — podatne bez aktualizacji. Microsoft wydał poprawki, łącznie dla systemów EoL. Windows 8/10/11 nienarażone.
  • Środowiska chmurowe (AWS/Azure/GCP) — ryzyko ekspozycji dotyczy głównie instancji z otwartym 3389/TCP na Internet (Security Groups/NSG). To mapuje się do T1190/T1021.001 i wymaga kontroli reguł sieciowych. (Źródło ogólne — ATT&CK).
  • AD/ESXi/K8s/M365 — sama podatność dotyczy Windows; dla tych platform istotne są punkty ekspozycji RDP (jump/bastion), polityki segmentacji i bram RDP.

Szczegółowy opis techniki (jak działa, cele, dlaczego jest skuteczna)

BlueKeep wykorzystuje błąd w przetwarzaniu kanałów/strumienia RDP podczas handshake’u (przed uwierzytelnieniem). Atakujący nawiązuje połączenie do 3389/TCP i wysyła sekwencję PDU, które prowadzą do korupcji pamięci jądra i przejęcia kontroli nad wykonaniem. Skuteczność wynika z:

  • Pre‑auth RCE (brak logowania / brak interakcji),
  • Wormowalności (możliwa automatyczna propagacja),
  • Powszechnej ekspozycji RDP w sieciach firmowych oraz często w Internecie.
    NLA wymaga uwierzytelnienia przed dotarciem do podatnej ścieżki i utrudnia automatyczne rozprzestrzenianie, ale nie chroni, jeśli napastnik ma ważne poświadczenia (np. z wycieku). Dlatego aktualizacja pozostaje jedyną trwałą mitigacją.

Artefakty i logi (tabela)

ŹródłoArtefakt / poleCo obserwowaćWartość dla detekcji
Windows/SystemEvent ID 56, Provider: TermDD„The Terminal Server security layer detected an error in the protocol stream…”; skoki liczby błędów z jednego źródłowego IPIndykator skanów/nieudanych exploitów BlueKeep; korelować z 3389/TCP i restartami usług.
Windows/Security4624/4625 (LogonType=10)Udane/nieudane logowania RDP; źródłowe IPDo odróżnienia legalnych adminów od zewnętrznych adresów; koreluj z ekspozycją portu.
Windows/TerminalServices‑RemoteConnectionManager/Operational1149„User authentication succeeded” (i czasem niektóre nieudane)Linia czasu sesji RDP; łączyć z 4624 i źródłowym IP.
Windows/System7031 (Service Control Manager)Nieoczekiwane restarty Remote Desktop ServicesCzęsto przy niestabilnych exploitach/handshake’ach; korelować z Event 56 i portem 3389.
EDR„RDP service spawning child”svchost.exe (TermService) → nietypowe dzieci (cmd/powershell)Rzadkie w admin rutynie; mocny sygnał post‑exploitation. (wiedza ogólna)
Sieć/Firewall/ProxyPołączenia TCP/3389 z InternetuNowe źródła, wysokie wolumeny, nietypowe ASNWczesne ostrzeżenie o skanach/atakach.
AWS CloudTrailAuthorizeSecurityGroupIngress (EC2)Reguły SG z 3389 do 0.0.0.0/0Ekspozycja RDP w chmurze (Initial Access/T1190).
Azure ActivityMICROSOFT.NETWORK/NETWORKSECURITYGROUPS/SECURITYRULES/WRITENSG otwierające 3389 na „Internet/Any”Jak wyżej (chmura).
K8s audit / M365——[nie dotyczy]

Detekcja (praktyczne reguły)

Sigma (gotowe reguły)

A) TermDD burst — możliwy skan/eksploit BlueKeep

title: Windows RDP TermDD Protocol Errors Burst (BlueKeep/Scan)
id: 2f2f8e8a-6a1a-45d2-9b6f-td56-burst
status: experimental
description: Wykrywa nagłe skoki błędów TermDD (EventID 56) sugerujące skany lub nieudane próby eksploatacji CVE-2019-0708.
author: Badacz CVE
logsource:
  product: windows
  service: system
detection:
  selection:
    EventID: 56
    Provider_Name: 'TermDD'
  timeframe: 5m
  condition: selection
# Uwaga: Agregacje zależą od backendu. Zalecane korelowanie: >=20 zdarzeń/5min z jednego SourceIP/hostu.
level: medium
tags:
  - attack.T1210
  - attack.T1021.001
  - cve.2019-0708

B) Wyłączenie NLA — modyfikacja rejestru (Sysmon)

title: RDP NLA Disabled via Registry
id: 3a6eaeee-1f6b-4592-a1a1-nla-off
status: stable
description: Wykrywa ustawienie UserAuthentication=0 dla RDP-Tcp (wyłączenie NLA).
author: Badacz CVE
logsource:
  product: windows
  service: sysmon
detection:
  sel_path:
    EventID: 13
    TargetObject|endswith: '\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\UserAuthentication'
  sel_val:
    Details|contains: 'DWORD (0x00000000)'
  condition: sel_path and sel_val
level: high
tags:
  - attack.T1021.001
  - attack.T1112
falsepositives:
  - Rzadkie legalne zmiany GPO/Intune

(NLA/UserAuthentication = 1 włącza NLA; 0 ją wyłącza).


Splunk (SPL)

A) Skoki TermDD (Event 56):

index=wineventlog sourcetype="WinEventLog:System" EventCode=56 SourceName=TermDD
| stats count by host, Message, _time, ComputerName, dest
| timechart span=5m count by host

B) RDP sukcesy spoza prywatnych adresów (4624, LogonType=10):

index=wineventlog sourcetype="WinEventLog:Security" EventCode=4624 Logon_Type=10
| eval isPublic=if(cidrmatch("10.0.0.0/8", Source_Network_Address) OR cidrmatch("172.16.0.0/12", Source_Network_Address) OR cidrmatch("192.168.0.0/16", Source_Network_Address), 0, 1)
| search isPublic=1
| stats count values(Source_Network_Address) as src_ip by ComputerName, Target_User_Name
| where count>0

KQL (Azure/Microsoft Sentinel)

A) Udane logowania RDP spoza prywatnych podsieci:

SecurityEvent
| where EventID == 4624 and LogonType == 10
| extend SrcIp = iff(isempty(IpAddress), tostring(parse_xml(EventData).EventData.Data[?(@.Name=="IpAddress")][0]."#text"), IpAddress)
| where SrcIp !startswith "10." and SrcIp !startswith "172.16." and SrcIp !startswith "192.168."
| summarize dcount(SrcIp) by Computer, TargetUserName, bin(TimeGenerated, 1h)

B) Zmiany NSG otwierające 3389 na Internet (Azure Activity):

AzureActivity
| where OperationNameValue =~ "MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/SECURITYRULES/WRITE"
| extend p=parse_json(Properties)
| extend src=tostring(p.responseBody.properties.sourceAddressPrefix),
         dport=tostring(p.responseBody.properties.destinationPortRange),
         access=tostring(p.responseBody.properties.access)
| where dport in ("3389","*") and src in ("Internet","0.0.0.0/0","Any") and access == "Allow"
| project TimeGenerated, Caller, ResourceGroup, Resource, src, dport, access

CloudTrail query (CloudWatch Logs Insights)

Otwieranie 3389/TCP na 0.0.0.0/0 (EC2 Security Groups):

fields @timestamp, userIdentity.arn, sourceIPAddress, eventName, requestParameters
| filter eventSource="ec2.amazonaws.com"
| filter eventName in ["AuthorizeSecurityGroupIngress","ModifySecurityGroupRules","UpdateSecurityGroupRuleDescriptionsIngress"]
| filter requestParameters like /3389/ and requestParameters like /0\.0\.0\.0\/0/
| sort @timestamp desc

Elastic / EQL

A) Wyłączenie NLA w rejestrze (Elastic EQL):

registry where
  registry.path :
    "*\\System\\CurrentControlSet\\Control\\Terminal Server\\WinStations\\RDP-Tcp\\UserAuthentication" and
  registry.data.strings : ("0","0x00000000")

B) RDP z Internetu (Elastic Query DSL – Beats flow):

network where destination.port == 3389 and
  not cidrmatch(source.ip, ["10.0.0.0/8","172.16.0.0/12","192.168.0.0/16"])

Heurystyki / korelacje (co łączyć)

  • Wejście → błąd protokołu → restart usługi: Inbound 3389 z nowego publicznego IP + TermDD/56 burst + SCM/7031 dla TermService ⇒ podejrzenie skanów/nieudanych exploitów BlueKeep.
  • Wejście → sukces logowania → nietypowe procesy: 3389 z Internetu + 4624/LogonType=10 + svchost.exe (TermService) spawnujący cmd.exe/powershell.exe ⇒ post‑exploitation.
  • Chmura: zdarzenia SG/NSG otwierające 3389 ⇒ natychmiastowe skanowanie Internetu; łączyć z logami RDP.
  • NLA: zmiana UserAuthentication na 0 + wzrost 4625/LogonType=10 ⇒ próby brute‑force lub przygotowanie do eksploatacji (chociaż BlueKeep jest pre‑auth, wyłączenie NLA bywa celem operatorów, aby ułatwić dalsze działania).

False positives / tuning

  • Event 56 (TermDD) może wynikać z błędów sieciowych/starych klientów RDP — filtrować progiem (np. ≥20/5min per źródłowe IP) i utrzymywać listę zaufanych skanerów.
  • 4624/10: legalne logowania adminów/jumphostów — whitelisty dla źródeł ASN/VPN, kont serwisowych i okien serwisowych.
  • 7031: restart różnych usług — koreluj wąsko z TermService i 56.
  • Zmiany rejestru: wdrożenia GPO/Intune — taguj „change windows” i weryfikuj źródło (PID/Signer).

Playbook reagowania (IR)

  1. Triaging & izolacja
  • Odłącz host od sieci lub przełącz do VLAN kwarantanny.
  • Zanotuj netstat -ano | find ":3389" oraz tasklist /svc | find /I "TermService".
  1. Weryfikacja podatności/łatek
  • Sprawdź OS i łatki:
    • Windows 7/2008 R2: Get-HotFix -Id KB4499164,KB4499175
    • Vista/2008: Get-HotFix -Id KB4499180
    • XP/2003: wmic qfe | find "4500331"
      Jeśli brak — patch ASAP (odpowiednie KB dla wydania).
  1. Twardnienie
  • Włącz NLA:
    Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication -Value 1 (restart RDS).
  • Ogranicz 3389 do VPN/jumphost (SG/NSG/Firewall), wyłącz ekspozycję 0.0.0.0/0.
  1. Hunting
  • Przejrzyj Event 56/7031 (skoki), 4624/10 (źródła publiczne), 1149 (osi czasu).
  • Sprawdź anomalia procesów od svchost.exe -k termsvcs i autostarty.
  1. Eradykacja & recovery
  • Zastosuj poprawki, wymuś restart RDS/hosta, zmień hasła adminów, wymuś MFA do zdalnych dostępl.
  1. Lessons learned
  • Segmentacja, JIT RDP (Azure), bastiony, skanowanie podatności.

Przykłady z kampanii / case studies

  • Listopad 2019 — pierwsze potwierdzone wykorzystanie BlueKeep in‑the‑wild do kryptominera (kampania masowa, niestabilne exploity).
  • Fortinet/Microsoft potwierdzają ataki oraz apelują o natychmiastowe łatanie.
  • Szacunki ekspozycji: setki tysięcy hostów publicznie podatnych po publikacji (2019). (kontekst historyczny)

Lab (bezpieczne testy)

Wyłącznie w odizolowanym labie. Brak exploitów. Celem jest weryfikacja ekspozycji i telemetrii.

  • Sprawdzenie stanu RDP/NLA na hoście:
# Czy RDP jest włączone
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections

# Czy NLA jest włączona
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication
  • Weryfikacja łatek (Win7/2008 R2):
Get-HotFix -Id KB4499164,KB4499175
  • Skan bezpieczny z zewnątrz (wersja RDP, bez exploitów):
nmap -Pn -p3389 --script rdp-enum-encryption,rdp-ntlm-info <cel>
  • Generowanie zdarzeń do detekcji: krótka sesja RDP z jump‑hosta (udane/nieudane logowania) → potwierdź 4624/4625(LogonType=10), 1149, brak nadmiarowych 56.

Mapowania (Mitigations, powiązane techniki)

Mitigations (wg MITRE, powiązane z T1210):

  • M1051 Update Software (patch management), M1042 Disable or Remove Feature or Program (wyłącz/ogranicz RDP), M1030 Network Segmentation, M1035 Limit Access to Resource Over Network (gateway/JIT), M1048 Application Isolation/Sandboxing, M1050 Exploit Protection, M1016 Vulnerability Scanning, M1026 Privileged Account Management.

Powiązane techniki ATT&CK:

  • T1133 External Remote Services (ekspozycja zewnętrzna), T1562 (Defense Evasion — wyłączanie zabezpieczeń/NLA), T1112 (Modify Registry), T1021 (Remote Services — rodzina). (mapowanie merytoryczne na podstawie opisów ATT&CK).

Źródła / dalsza literatura

  • Microsoft MSRC: Prevent a worm by updating RDS (CVE‑2019‑0708) — o NLA i „wormowalności”. (Microsoft)
  • Microsoft Support: Customer guidance for CVE‑2019‑0708 — listy platform i KB (w tym EoL). (Microsoft Support)
  • Microsoft KB: KB4499164 (Monthly Rollup Win7/2008 R2), KB4499175 (Security‑only). (Microsoft Support)
  • NVD: CVE‑2019‑0708 (CVSS 9.8, zmiany 2024). (NVD)
  • CISA Advisory AA19‑168A. (CISA)
  • MITRE ATT&CK (v18): T1210, T1021.001, T1190 (wersje i daty). (MITRE ATT&CK)
  • Microsoft Tech Community: TermDD Event ID 56 — protokół RDP error. (TECHCOMMUNITY.MICROSOFT.COM)
  • Unit 42: analiza wewnętrzna RDP/BlueKeep. (Unit 42)
  • Tenable/Microsoft/Kryptos Logic: pierwsze ataki i telemetria. (Tenable®)
  • Informacja kontekstowa o nienarażonych Windows 8/10/11. (Wikipedia)

Checklisty dla SOC / CISO

SOC – codzienna kontrola

  • Alerty na Event 56 (TermDD) bursty + korelacja z 3389/TCP.
  • Monitor 4624/10 i 1149 z publicznych IP; whitelisty dla jump‑hostów.
  • Wykrywanie NLA=OFF (UserAuthentication=0) i zmian SG/NSG otwierających 3389.
  • Regularne skany podatności/asset inventory dla hostów z RDP.

CISO – decyzje i governance

  • Polityka: RDP tylko przez VPN/jumphost/JIT; brak 0.0.0.0/0.
  • SLA na Patch Tuesday + raport KB (KB4499164/KB4499175/KB4499180/KB4500331).
  • NLA wymagane (GPO/Intune), MFA dla zdalnego dostępu.
  • Segmentacja (M1030), regularny red/blue tabletop dla RDP‑borne incydentów.

„Czarne” LLM-y wzmacniają początkujących hakerów: WormGPT 4 i KawaiiGPT w praktyce

Wprowadzenie do problemu / definicja luki

Zła wiadomość: „odblokowane” (pozbawione barier) duże modele językowe przestały być ciekawostką z podziemia. Najnowsze śledztwo Unit 42 (Palo Alto Networks) opisuje dwa aktywnie używane przez cyberprzestępców modele — WormGPT 4 oraz KawaiiGPT — które dostarczają gotowe komponenty do ataków: od generowania realistycznych kampanii BEC/phishing, przez skrypty do ruchu bocznego, po funkcjonalne fragmenty „lockera” do szyfrowania plików. Dziennikarze i analitycy branżowi potwierdzają: bariera wejścia dla mniej doświadczonych napastników dalej spada.

W skrócie

  • WormGPT 4 (płatny, „bez ograniczeń”) generuje m.in. działający skrypt szyfrujący i profesjonalne noty okupu; sprzedawany jest w modelu subskrypcyjnym lub „lifetime” (w doniesieniach pada $50/mies. lub $220 jednorazowo).
  • KawaiiGPT (wariant społecznościowy, lokalny) automatyzuje spear-phishing, przygotowuje skrypty Python do ruchu bocznego (np. z użyciem paramiko) i prostą eksfiltrację.
  • Oba modele mają aktywną bazę użytkowników na Telegramie i forach, co obniża próg wejścia dla „script kiddies”.
  • Instytucje rządowe (CISA/NSA) publikują wytyczne zabezpieczenia danych i systemów AI — AI w środowiskach firmowych trzeba traktować jak system o podwyższonym ryzyku.

Kontekst / historia / powiązania

WormGPT po raz pierwszy wypłynął w 2023 r. Projekt zniknął, ale w 2025 r. wrócił jako WormGPT 4, deklarując „brak ograniczeń etycznych” i profilowanie pod cyberprzestępcze use-case’y. Jednocześnie rozkwita ekosystem „ciemnych LLM-ów” (dark LLMs), które — choć często technicznie przeciętne — wyrównują kompetencje mniej zaawansowanych sprawców, dając im język, scenariusze i kod-szablony. Relacje branżowe i prasowe (BleepingComputer, Dark Reading, The Register) zbieżnie opisują trend oraz model monetyzacji.

Analiza techniczna / szczegóły luki

WormGPT 4 (testy Unit 42)

  • Locker: model wygenerował PowerShell szyfrujący wskazane typy plików (np. PDF) algorytmem AES-256, z możliwością konfiguracji ścieżek/rozszerzeń. Badacze odnotowali nawet opcję eksfiltracji przez Tor.
  • Ransom note: spójna, perswazyjna notatka z „military-grade encryption” i deadline’em 72h.
  • Socjotechnika/BEC: „wiarygodna manipulacja językowa”, minimalne błędy językowe, dobrze „udające” komunikację biznesową.

KawaiiGPT (testy Unit 42)

  • Spear-phishing: generowanie dopracowanych szablonów z wiarygodnym spoofingiem domen i łańcuchami linków do zbierania poświadczeń.
  • Ruch boczny: generowanie skryptów Python korzystających z paramiko do zdalnego wykonania poleceń.
  • Eksfiltracja: proste skrypty wyszukujące pliki (np. os.walk) i wysyłające pakiety na kontrolowany adres (np. smtplib).
  • Noty okupu: szablony z możliwością dostosowania instrukcji płatności i terminów.

Uwaga redakcyjna: powyższe to opis wyników badań. Nie publikujemy kodu ani kroków operacyjnych.

Praktyczne konsekwencje / ryzyko

  • Skalowanie ataków: mniej doświadczeni napastnicy uzyskują „asystenta” do szybkiego tworzenia treści phishingowych i „klejenia” łańcuchów ataku. Efekt: więcej poprawnie napisanych maili i krótszy czas przygotowania.
  • Wiarygodność treści: „czarne LLM-y” niwelują charakterystyczne błędy językowe; filtry w secure email gateways wymagają silniejszego ML i korelacji kontekstowej.
  • Model biznesowy: tani dostęp (subskrypcja/lifetime) + kanały Telegram → łatwe wejście i szybkie „uczenie się” przez społeczność.
  • Ryzyko dla compliance: użycie niezweryfikowanych LLM-ów przez pracowników (shadow AI) = ryzyko wycieku danych i naruszeń polityk. CISA/NSA zalecają traktować dane i pipeline’y AI jako zasób krytyczny.

Rekomendacje operacyjne / co zrobić teraz

  1. Zamknij „shadow AI”: polityka firmowa określająca dozwolone modele, kanały dostępu (SaaS vs. self-host), wymagania DLP i rejestrowanie zapytań. Odwołaj się do zaleceń CISA/NSA dot. bezpieczeństwa danych w cyklu życia AI.
  2. E-mail i web security „pod LLM”: aktualizuj reguły EOP/SEG, dodaj analizę semantyczną treści i sygnały kontekstowe (np. nietypowe domeny, „tylko odpowiedz”, żądania pilnych przelewów). Podbij detekcję BEC korelacją z systemami finansowymi.
  3. Hunting & detections (bez publikacji IoC-ów z podziemia):
    • Nietypowy PowerShell szyfrujący/operujący na masowych plikach;
    • Egzekucje Python z bibliotekami zdalnego dostępu (paramiko);
    • Eksfiltracja SMTP z hostów użytkowników;
    • Aktywność Tor/SOCKS z endpointów biurowych. (Wnioski na bazie testów Unit 42).
  4. Segregacja i kontrola danych dla AI: etykietowanie wrażliwości, guardrails na warstwie promptów, filtry wstępne, red teaming AI; wdrożenie zasad z dokumentu CSI „AI Data Security”.
  5. Szkolenia: nowy moduł „LLM-phishing/BEC” dla użytkowników biznesowych (zmiana tonu/gramatyki, „bezbłędne” maile, presja czasu, prośby o poufność). Potwierdzają to obserwacje Dark Reading o „wyrównywaniu kompetencji” przez dark LLM-y.
  6. Zespół prawny & zakupowy: klauzule bezpieczeństwa danych AI, prawo audytu dostawcy, lokalność przetwarzania, retencja, „no-train” na danych klienta.

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

  • Jailbreaki mainstreamowych LLM-ów vs. dedykowane „ciemne” LLM-y: w 2023–2024 najczęściej próbowano „naginać” polityki ChatGPT/Gemini/Claude. W 2025 mamy produkty tworzone wprost do przestępstw, więc brak barier jest założeniem projektowym.
  • Poziom techniczny: część „dark LLM-ów” bywa niedojrzała technicznie, ale dla „petty crime” to wystarczy, bo automatyzują nudne etapy: treści, glue-code, checklisty.

Podsumowanie / kluczowe wnioski

  • Operacjonalizacja dark LLM-ów stała się faktem — nie są to już „proof-of-concepts”.
  • Dla obrońców to oznacza: nowa fala dobrze napisanych phishingów, proste skrypty do ruchu bocznego i tańszy dostęp do tooling’u.
  • Odpowiedź: polityka AI w firmie + zabezpieczenie danych dla AI + detekcje pod kątem TTP-ów generowanych przez LLM + świadomość użytkowników.
  • Śledź publikacje badawcze (Unit 42) i wytyczne rządowe (CISA/NSA) — tempo zmian jest wysokie.

Źródła / bibliografia

  1. BleepingComputer: „Malicious LLMs empower inexperienced hackers with advanced tools”, 27 listopada 2025. (Przegląd badań Unit 42; konkretne przykłady generowanych artefaktów). (BleepingComputer)
  2. Unit 42 (Palo Alto Networks): „The Dual-Use Dilemma of AI: Malicious LLMs” – raport opisujący WormGPT 4 i KawaiiGPT (publ. w tym tygodniu). (Unit 42)
  3. Dark Reading: „‘Dark LLMs’ Aid Petty Criminals, But Underwhelm Technically”, 26 listopada 2025 (kontekst o wyrównywaniu kompetencji). (Dark Reading)
  4. The Register: „Lifetime access to AI-for-evil WormGPT 4 costs just $220”, 25 listopada 2025 (model monetyzacji, trend narzędzi „bez ograniczeń”). (The Register)
  5. CISA / DoD: „AI Data Security” (CSI), 22 maja 2025 — wytyczne zabezpieczenia danych i pipeline’ów AI w organizacjach. (U.S. Department of War)

CISA ostrzega: aktywne kampanie szpiegowskie przejmują konta w Signal i WhatsApp. Co wiemy i jak się bronić

Wprowadzenie do problemu / definicja luki

Amerykańska agencja CISA wydała 24 listopada 2025 r. alert ostrzegający przed aktywnym wykorzystaniem komercyjnego spyware oraz RAT-ów do przejmowania komunikatorów mobilnych, w szczególności Signal i WhatsApp. Napastnicy używają socjotechniki, złośliwych kodów QR do „połączonych urządzeń”, fałszywych aplikacji oraz – w wybranych przypadkach – łańcuchów zero-click. Celem są osoby o wysokiej wartości wywiadowczej w USA, Europie i na Bliskim Wschodzie.

W skrócie

  • Techniki: phishing/QR do funkcji „Połączone urządzenia” w Signal, fałszywe aplikacje udające Signal/ToTok/WhatsApp, zero-click przez spreparowane obrazy (DNG) w komunikatorach.
  • Kampanie:
    • ProSpy/ToSpy – szkodliwe APK podszywające się pod Signal/ToTok, kradnące SMS-y, kontakty, pliki i backupy czatów.
    • ClayRat – spyware dystrybuowany z Telegrama i stron-klonów, rozprzestrzeniający się poprzez wiadomości SMS do kontaktów ofiary.
    • LANDFALL – komercyjnej klasy spyware na Androida, wykorzystywał zero-day CVE-2025-21042 w bibliotekach Samsunga i był dostarczany złośliwymi obrazami DNG (prawdopodobnie przez WhatsApp).
  • Kogo celują: wysocy urzędnicy, wojskowi, politycy, dziennikarze, NGO, działacze społeczni.
  • Co robić teraz (TL;DR): klucze FIDO2, rezygnacja z SMS-MFA, przegląd „połączonych urządzeń”, aktualizacje, Play Protect/Enhanced Protection, ograniczenie uprawnień aplikacji, Lockdown Mode na iOS, weryfikacja źródeł APK.

Kontekst / historia / powiązania

W 2025 r. Google Threat Intelligence opisał kampanie grup powiązanych z Rosją, które nadużywały funkcji Linked Devices w Signal – ofiara była nakłaniana do zeskanowania złośliwego kodu QR, co dodawało urządzenie atakującego do jej konta i pozwalało czytać zaszyfrowane rozmowy w czasie rzeczywistym. Signal wdrożył dodatkowe zabezpieczenia potwierdzające nowe urządzenia.

Równolegle badacze publikowali analizy mobilnych kampanii spyware: ESET (ProSpy/ToSpy) w ZEA, Zimperium (ClayRat) w Rosji oraz Unit 42 (Palo Alto Networks) – LANDFALL uderzający w urządzenia Samsung Galaxy poprzez podatność CVE-2025-21042 i no-click DNG wysyłane w komunikatorach. Te raporty tworzą spójny obraz, na który właśnie powołuje się CISA.

Analiza techniczna / szczegóły luki

1) Przejęcia kont Signal przez „połączone urządzenia”

  • Wektor: podszywanie się pod zaproszenia/grupy i wysyłka złośliwych QR.
  • Efekt: do konta ofiary zostaje dodane urządzenie kontrolowane przez atakującego, co daje pełny podgląd wiadomości bez łamania E2EE.
  • Mitigacje producenta: dodatkowe kroki potwierdzające i przypomnienia o nowo dodanym urządzeniu.

2) ProSpy / ToSpy (Android)

  • Dystrybucja: fałszywe strony i „wtyczki” Signal Encryption Plugin oraz ToTok Pro poza oficjalnymi sklepami.
  • Zdolności: wykradanie SMS, kontaktów, listy aplikacji, szerokie zbieranie plików (dokumenty, multimedia) oraz polowanie na backupy czatów ToTok (.ttkmbackup).
  • Ukrywanie: zmiana ikony/nazwy na „Google Play Services” i przekierowania do prawdziwych stron, by uwiarygodnić instalację.

3) ClayRat (Android)

  • Dystrybucja: kanały Telegram + domeny-sobowtóry WhatsApp/YouTube/TikTok/Google Photos; zachęcanie do włączenia instalacji z „nieznanych źródeł”.
  • Zdolności: exfiltracja SMS, logów połączeń, powiadomień, zdjęć, wykonywanie zdjęć z przedniej kamery, a także samorozprzestrzenianie przez masową wysyłkę SMS do wszystkich kontaktów.
  • Skala: setki wariantów i dziesiątki „dropperów” w kilka miesięcy.

4) LANDFALL (Android/Samsung)

  • Wektor zero-click: złośliwe obrazy DNG zawierające załączony ZIP; exploit na CVE-2025-21042 w bibliotece przetwarzania obrazu Samsunga; ślady dostarczenia przez WhatsApp (nazwy plików).
  • Zdolności: nagrywanie mikrofonu, lokalizacja, zdjęcia, kontakty, logi połączeń – komercyjnej klasy modułowy implant.
  • Zasięg i profil ofiar: ukierunkowane operacje w Bliskim Wschodzie; próbki widoczne w VirusTotal już w 2024 r. (przed łatką).

Praktyczne konsekwencje / ryzyko

  • Eskalacja dostępu: przejęcie konta komunikatora = dostęp do treści, kontaktów, grup, tokenów sesji, a w Androidzie nierzadko do SMS/telefonii (obsługa 2FA).
  • Trwałość: parowanie urządzeń i ukryte ikony utrudniają wykrycie; spyware potrafi utrzymywać się po restarcie i automatycznie dosyłać ładunki.
  • Ryzyko wtórne: przejęte konto staje się wektorem do dalszych ofiar (rodzina, współpracownicy, źródła dziennikarskie).

Rekomendacje operacyjne / co zrobić teraz

Dla osób wysokiego ryzyka (VIP, dziennikarze, NGO, urzędnicy):

  1. Uwierzytelnianie odporne na phishing: klucze FIDO2 (np. do kont e-mail/chmury), zrezygnuj z SMS-MFA tam, gdzie to możliwe.
  2. Higiena „połączonych urządzeń”: w Signal/WhatsApp sprawdź i usuń nieznane urządzenia; włącz powiadomienia o nowych sesjach.
  3. iOS: włącz Lockdown Mode dla osób szczególnie narażonych; regularnie aktualizuj.
  4. Android: korzystaj z telefonów producentów z dobrymi praktykami aktualizacji; włącz Google Play Protect, w Chrome Enhanced Protection, audytuj i cofaj uprawnienia aplikacjom. Nie instaluj APK spoza oficjalnych sklepów.
  5. WhatsApp/Samsung: upewnij się, że urządzenie ma poprawki CVE-2025-21042/CVE-2025-21043 (Samsung – kwiecień/wrzesień 2025). Jeśli otrzymasz „dziwne zdjęcie DNG/RAW” – nie otwieraj; aktualizuj natychmiast.
  6. Szkolenia i SOP: w organizacji wdroż procedurę reagowania na podejrzane QR i fake’owe zaproszenia do grup/kanalów; centralny Mobile Threat Defense i monitorowanie instalacji z nieznanych źródeł.

Różnice / porównania z innymi przypadkami

  • ProSpy/ToSpy vs ClayRat: oba to Android spyware z silnym komponentem socjotechniki i sideloadingu, ale ClayRat dodatkowo samonamiaża się przez SMS i intensywnie korzysta z Telegrama do dystrybucji.
  • LANDFALL odróżnia wektor zero-click poprzez DNG i wykorzystanie podatności producenta (Samsung) – to poziom PSOA/komercyjnych dostawców spyware, a nie „czyste” kampanie phishingowe.
  • Ataki na Signal Linked Devices to bypassy operacyjne, które nie łamią E2EE, ale przejmują endpoint poprzez dołączony klient.

Podsumowanie / kluczowe wnioski

CISA oficjalnie łączy w całość kilka świeżych wątków: szeroko zakrojone oszustwa QR na Signal, kampanie podszywania się pod komunikatory (ProSpy/ToSpy, ClayRat) i zaawansowane łańcuchy zero-click (LANDFALL). Wspólny mianownik: atak na użytkownika i jego urządzenie, nie na kryptografię. Obrona wymaga połączenia hardeningu urządzenia, dobrych nawyków, oraz szybkiego patchowania – zwłaszcza w ekosystemie Android/Samsung.

Źródła / bibliografia

  1. CISA – Spyware Allows Cyber Threat Actors to Target Users of Messaging Applications (24 XI 2025). (cisa.gov)
  2. Google Threat Intelligence – Russia targeting Signal Messenger via Linked Devices (19 II 2025). (Google Cloud)
  3. ESET WeLiveSecurity – New spyware campaigns target privacy-conscious Android users in the UAE (ProSpy/ToSpy) (2 X 2025). (welivesecurity.com)
  4. Zimperium – ClayRat: A New Android Spyware Targeting Russia (9 X 2025). (zimperium.com)
  5. Unit 42 (Palo Alto Networks) – LANDFALL: New Commercial-Grade Android Spyware in Exploit Chain Targeting Samsung Devices (7 XI 2025). (Unit 42)

Sturnus — nowy trojan bankowy na Androida przechwytuje wiadomości z WhatsAppa, Telegrama i Signal

Wprowadzenie do problemu / definicja luki

Badacze ThreatFabric opisali nową, prywatnie rozwijaną rodzinę Sturnus — trojana bankowego na Androida, który potrafi obchodzić E2EE komunikatorów (WhatsApp, Telegram, Signal), przechwytując treści po odszyfrowaniu na ekranie. Malware łączy klasyczne techniki bankerów (overlaye HTML, keylogging przez Accessibility) z pełnym przejęciem urządzenia (VNC/hVNC) i aktywną obroną przed usunięciem. Wstępna telemetria wskazuje na celowanie w użytkowników instytucji finansowych w Europie Środkowej i Południowej.

W skrócie

  • Co robi: wykrada dane logowania do bankowości, podsłuchuje czaty po stronie urządzenia, zdalnie steruje telefonem, ukrywa aktywność “czarną nakładką”.
  • Status kampanii: funkcjonalny, lecz w fazie rozwoju/testów; na razie niska skala, celowanie regionalne (EU S/CE).
  • Wejście do systemu: dystrybuowany jako fałszywe APK, m.in. podszywające się pod Google Chrome i “Preemix Box”; wektory prawdopodobne: malvertising/DM.
  • Dlaczego E2EE nie pomaga: Sturnus nie łamie kryptografii — czyta ekran/UI po odszyfrowaniu z użyciem Accessibility i zrzutów ekranu/struktury widoków.

Kontekst / historia / powiązania

Sturnus wpisuje się w trend wzrostu możliwości bankerów na Androida (Herodotus, Crocodilus), którzy łączą Device Takeover z precyzyjnymi overlayami i anti-removal. Media branżowe (SecurityWeek, The Record, BleepingComputer, The Hacker News) potwierdzają wczesną, ale zaawansowaną naturę zagrożenia oraz nacisk na Europę.

Analiza techniczna / szczegóły luki

Łańcuch komunikacji i C2

  • Dwukanałowa łączność: HTTP(S) + WebSocket (WSS); rejestracja klienta, wymiana kluczy RSA→AES, a następnie ruch AES/CBC (IV per wiadomość). WebSocket służy m.in. do sesji VNC.

Pozyskiwanie danych

  • Overlaye HTML (repozytorium szablonów w przestrzeni aplikacji) na popularne aplikacje bankowe; JavaScript bridge do natychmiastowej eksfiltracji. Po zebraniu danych overlay dla danej aplikacji bywa wyłączany, by ograniczyć podejrzenia.
  • Keylogging i obserwacja UI przez Accessibility Service (zdarzenia TYPE_VIEW_*, rekonstrukcja drzewa UI), co pozwala odczytywać tekst oraz kontekst ekranów nawet gdy FLAG_SECURE blokuje standardowy screen capture.

Obchodzenie E2EE komunikatorów

  • Monitorowanie aplikacji pierwszoplanowej i automatyczne włączenie kolekcji UI-tree przy WhatsApp/Telegram/Signal. Dane są widoczne “po stronie ekranu” — po odszyfrowaniu przez legalną aplikację. To nie łamie kryptografii, lecz obchodzi jej model zagrożeń poprzez pełne przejęcie hosta.

Zdalne sterowanie (VNC / hVNC)

  • Dwie ścieżki: strumień obrazu (systemowe przechwytywanie ekranu lub fallback przez Accessibility) oraz sterowanie po drzewie UI (kliki, wprowadzanie tekstu, przewijanie, uruchamianie aplikacji, potwierdzania dialogów). Dostępny czarny overlay ukrywający działania operatora.

Utrzymanie i anty-usuwanie

  • Nadużycie Android Device Administrator; wykrywanie prób odebrania uprawnień i automatyczne wycofywanie użytkownika z ekranu ustawień. Do czasu ręcznego cofnięcia uprawnień odinstalowanie (nawet ADB) jest utrudnione. Rozbudowane monitorowanie środowiska (broadcast receivery, stan baterii/SIM/ADB/SELinux/patch level).

Wejście: fałszywe APK

  • Udokumentowane nazwy pakietów dystrybucyjnych to m.in.:
    • com.klivkfbky.izaybebnx (podszywa się pod Google Chrome)
    • com.uvxuthoq.noscjahae (Preemix Box)
      Dystrybucja prawdopodobnie przez malvertising lub bezpośrednie wiadomości z linkami do APK.

Praktyczne konsekwencje / ryzyko

  • Ryzyko dla bankowości mobilnej: przejęcie sesji, autoryzacji i potwierdzeń (MFA) w czasie rzeczywistym; możliwość wykonania przelewów podczas “czarnej nakładki”.
  • Ryzyko dla prywatności i zgodności: masowy exfil treści rozmów z E2EE, kontaktów i metadanych; potencjalne naruszenia RODO, tajemnicy bankowej i poufności klientów.
  • Ryzyko dla zespołów SOC/CSIRT: tradycyjne wskaźniki sieciowe mogą być skąpe (custom protokół, AES/WSS); konieczność telemetrii na poziomie urządzenia i korelacji zdarzeń Accessibility/overlay.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i zespołów IT

  1. Blokada sideloadingu (MDM/Intune/Endpoint Management): wyłącz nieznane źródła instalacji APK; wymuś Google Play Protect.
  2. Polityki uprawnień: audytuj i ogranicz uprawnienia Accessibility (zezwalaj tylko aplikacjom biznesowo uzasadnionym; alerty na nowe zgody).
  3. EDR/Mobile Threat Defense (MTD): wybieraj rozwiązania wykrywające:
    • stałe połączenia WSS do nietypowych domen;
    • intensywne zdarzenia Accessibility i enumerację UI;
    • tworzenie overlayów i długotrwałe “foreground services”.
  4. Higiena MFA: preferuj out-of-band (np. FIDO2/U2F, klucze sprzętowe) zamiast kodów w tej samej przeglądarce/urządzeniu.
  5. Twarde usuwanie: jeśli urządzenie wykazuje symptomy (czarna nakładka, brak możliwości odinstalowania), wejdź do trybu awaryjnego, cofnij Device Admin, następnie odinstaluj; w razie wątpliwości factory reset + odtworzenie zaufanego backupu.
  6. Szkolenia anty-phishingowe: kampanie o fałszywych APK (Chrome/“update systemu”/“Preemix Box”) i malvertisingu.

Dla banków/fintechów

  • Risk-based authentication i detekcje anomalii mobilnych (np. nienaturalne gesty, wzorce VNC, “czarne overlaye”, zmiany Device Admin).
  • App hardening: utrudnianie overlayów, root/jailbreak/emulator detection, “tapjacking protection”, monitorowanie FLAG_SECURE bypass i anomalii Accessibility.
  • Fraud analytics: korelacja telemetrii transakcyjnej z sygnałami z urządzenia (nagłe wyciszenie UI, brak interakcji człowieka, przewijanie skryptowe).

Różnice / porównania z innymi przypadkami

  • W przeciwieństwie do wielu bankerów, Sturnus mocno inwestuje w pełny podwójny kanał C2 (HTTP+WSS) i sterowanie po drzewie UI, co zmniejsza zależność od samego streamingu ekranu i atrybutów wizualnych.
  • Podobnie jak Herodotus/Crocodilus, skupia się na Device Takeover, ale jego monitoring środowiska (SIM/ADB/SELinux/patch level) i rozbudowana obrona Device Admin są ponadprzeciętnie zaawansowane.

Podsumowanie / kluczowe wnioski

Sturnus nie łamie kryptografii E2EE — omija ją, kompromitując host i odczytując to, co widzi użytkownik. Dla obrony oznacza to przesunięcie nacisku z IoC sieciowych na behawior urządzenia: overlaye, nadużycia Accessibility, uprzywilejowania Device Admin i nietypowe sesje WSS/VNC. Wykrycie na wczesnym etapie i dyscyplina instalacyjna (zakaz sideloadingu) będą kluczowe.

Źródła / bibliografia

  1. ThreatFabric — Sturnus: Mobile Banking Malware bypassing WhatsApp, Telegram and Signal Encryption (20 listopada 2025). (ThreatFabric)
  2. SecurityWeek — New Sturnus Banking Trojan Targets WhatsApp, Telegram, Signal Messages (20 listopada 2025). (SecurityWeek)
  3. The Hacker News — New Sturnus Android Trojan Quietly Captures Encrypted Chats and Hijacks Devices (20 listopada 2025). (The Hacker News)
  4. BleepingComputer — Multi-threat Android malware Sturnus steals Signal, WhatsApp messages (20 listopada 2025). (Bleeping Computer)
  5. The Record — New Android malware can capture private messages, researchers warn (20 listopada 2025). (The Record from Recorded Future)

Jak Zamienić MITRE D3FEND W Wizualne Mapy Obrony

Dlaczego budujemy mapę obrony z MITRE D3FEND

W świecie cyberbezpieczeństwa Blue Team często korzysta z matrycy MITRE ATT&CK do mapowania taktyk i technik ataków przeciwnika. A co z naszą własną defensywą? Czy potrafimy równie przejrzyście zobrazować, jak broni się nasza organizacja? W tym artykule zobaczymy, jak framework MITRE D3FEND pomaga zbudować wizualną mapę obrony – swoisty dashboard defensywny zespołu SOC. Zamiast domyślać się, gdzie mamy luki, zwizualizujemy techniki obrony tak, by od razu wskazać mocne punkty i obszary wymagające uwagi.

Czytaj dalej „Jak Zamienić MITRE D3FEND W Wizualne Mapy Obrony”

Daily Ransomware Report – 15 listopada 2025: trend „data-theft extortion” i aktywność Qilin

Wprowadzenie do problemu / definicja luki

Dzisiejszy przegląd incydentów wskazuje na 9 nowych ofiar ujawnionych na stronach wyciekowych (DLS) w ciągu ostatnich 24 godzin. Wśród grup najaktywniejszy był Qilin (2 ofiary), a geograficznie najbardziej dotknięte pozostają Stany Zjednoczone. Sektory? Od usług profesjonalnych i edukacji po energetykę i ochronę zdrowia – czyli pełne spektrum, w tym infrastrukturę krytyczną. W warstwie TTP szczególnie istotna jest eskalacja modelu „data-theft extortion” (kradzież danych + wymuszenie), którą prezentuje nowa grupa Kazu operująca przez nadużycia aplikacji webowych zamiast klasycznego szyfrowania zasobów. Źródłowe dane statystyczne i syntetyczne zestawienie grup pochodzą z dzisiejszego raportu Purple Ops.


W skrócie

  • Skala: 9 nowych zgłoszeń/ofiar na DLS; rok-do-dnia: 6564, Q4: 1138.
  • Najaktywniejsza grupa: Qilin (2 ofiary / różne branże, w tym elementy infrastruktury krytycznej).
  • Nowy gracz: Kazu – pierwszy głośny przypadek w Ameryce Płn.: Doctor Alliance (TX, USA), groźba publikacji 353 GB / ok. 1,2 mln plików, żądanie 200 tys. USD.
  • Incydenty dnia (wybrane z monitoringu DLS): m.in. Brotherhood → Ninas Jewellery (AU); wzmianki o Kill Security → Force Brokerage (US); aktywność Qilin wobec podmiotów w Ameryce Płn.
  • Szerszy trend: Qilin utrzymuje wysokie tempo globalne w 2025 r., należąc do najbardziej prolificznych operatorów.

Kontekst / historia / powiązania

Rok 2025 przyniósł stabilnie wysoką aktywność ekosystemu ransomware, a Qilin – obecny od 2022 r. – pozostaje jedną z najprężniej działających operacji (Golang, elastyczne tryby szyfrowania, „double extortion”). W tle mamy ciągłe działania organów ścigania i sankcje wobec infrastruktur wspierających gangi, ale skuteczność odstraszania jest ograniczona – grupy szybko się rekonfigurują i/lub przełączają model biznesowy (np. data-theft bez szyfrowania).

Kazu wpisuje się w rosnący nurt grup, które porzucają ciężkie payloady na rzecz wyłudzeń po samej eksfiltracji, wykorzystując słabości w warstwie aplikacyjnej (portalach, usługach SaaS, hostingach). Pierwsze szeroko opisywane uderzenie w Ameryce Płn. to Doctor Alliance (inne publikacje także potwierdzają wolumen i deadline okupu).


Analiza techniczna / szczegóły luki

1) TTP „data-theft extortion” (Kazu)

  • Wejście: podatności w aplikacjach webowych / panelach (np. auth bypass, RCE w CMS/WAF, błędy uploadu, SSRF, SQLi, IDOR).
  • Ruch lateralny: ograniczony lub zerowy – priorytetem jest szybka eksfiltracja wprost z warstwy aplikacyjnej lub storage’u (S3/Blob/NAS).
  • Eksfiltracja: HTTP(S) do hostów kontrolowanych, czasem kanały chmurowe (niepozorne domeny, CDN), archiwa wieloczęściowe.
  • Wymuszenie: publikacja listingów, zrzuty ekranów, próbki (setki obrazów PDF/JPG z dokumentacją medyczną), licznik czasu i żądanie okupu – tutaj $200k i groźba publikacji 21.11.2025.

2) Qilin – model „double extortion”

  • Wejście: spear-phish + kradzież kredencjałów, RDP/VPN bez MFA, podatne urządzenia perymetryczne, n-day CVE (Fortinet, Ivanti, VMware), czasem łańcuchy supply-chain.
  • Faza przed-encryption: wyłączenie EDR, shadow copies, backup endpointów; kradzież danych wrażliwych (HR/finanse/projekty).
  • Szyfrowanie: wsparcie wielu trybów, sterowane przez operatora; nota okupu + komunikacja przez Tox/Chat. Skala 2025 – setki ofiar globalnie.

3) Inne grupy z dziennego podsumowania

  • Brotherhood → Ninas Jewellery (AU) – zgłoszenie na trackerach DLS.
  • Kill Security / KillSec → Force Brokerage (US) – wpisy w serwisach monitorujących DLS. (Uwaga: szczegóły mogą się zmieniać; w tej chwili brak szerokich, oficjalnych potwierdzeń poza ekosystemem DLS/OSINT).

Praktyczne konsekwencje / ryzyko

  • Ochrona zdrowia: incydenty typu Doctor Alliance oznaczają wysokie ryzyko RODO/HIPAA (pełne dane medyczne, numery ubezpieczeń, plany leczenia). Efekty: kradzież tożsamości, oszustwa ubezpieczeniowe, spear-phish kontekstowy (spoofing lekarzy/placówek).
  • Infrastruktura krytyczna: nawet gdy brak szyfrowania, ujawnienie konfiguracji OT/ICS, schematów, list kont zwiększa ryzyko wtórnych włamań i szantażu.
  • Łańcuch dostaw: wycieki danych dostawców (MSP, billing, dokumentacja) eskalują ryzyko pivotu na klientów.

Rekomendacje operacyjne / co zrobić teraz

1) Twardnienie frontów webowych (pod Kazu / „pure exfil”)

Szybkie kontrole:

# Sprawdź ekspozycję paneli (MFA/SSO) i podstawową powierzchnię:
nmap -Pn -sV --script http-auth,http-vuln* -p80,443 <Twoje_ADR_IP/CIDR>

# Wyszukaj nieautoryzowane uploady / webshell:
grep -R --include="*.php" -nE "(base64_decode|eval\(|shell_exec|assert\()" /var/www/html

# Poszukaj świeżych artefaktów w katalogach upload:
find /var/www/html/uploads -type f -mtime -3 -ls

WAF/Reverse proxy:

  • Włącz bot management / anomaly scoring (SQLi/XSS/SSRF/IDOR), rate-limit na endpointach upload/search.
  • MFA „enforce” na wszystkich panelach administracyjnych/helpdesk/portalach B2B. (Raport Purple Ops podkreśla ten wektor przy Kazu.)

Dzienniki i detekcje (przykłady):

Sigma (podejrzane archiwa wyprowadzane przez proces serwera www):

title: Suspicious Large Archive Exfil via Webserver Process
logsource:
  product: linux
  category: process_creation
detection:
  sel:
    Image|endswith:
      - /usr/sbin/apache2
      - /usr/sbin/nginx
    CommandLine|contains:
      - "zip"
      - "7z"
      - "tar"
  cond: sel
fields: [Image, CommandLine, User, ParentProcess, CurrentDirectory]
level: high
tags: [exfiltration, webserver, data-theft]

NGINX – anomalia rozmiaru odpowiedzi (potencjalna eksfiltracja):

# mapuj duże odpowiedzi >100MB do osobnego loga
map $body_bytes_sent $large_body {
  default 0;
  "~^[1-9][0-9]{8,}$" 1;  # >= 100MB
}
log_format exfil '$remote_addr $time_local "$request" $status $body_bytes_sent $http_referer $http_user_agent';
access_log /var/log/nginx/exfil.log exfil if=$large_body;

Splunk – spike dużych transferów z hostów www:

index=web sourcetype=nginx:access OR sourcetype=apache:access
| bucket _time span=15m
| stats sum(bytes) as out_bytes by src, dest, _time
| eventstats avg(out_bytes) as avg stdev(out_bytes) as std by src
| where out_bytes > avg + 3*std
| sort - out_bytes

2) Ransomware (Qilin i podobni) – hygiene + EDR

  • Dostępy zdalne: wyłącz RDP z internetu; VPN tylko z MFA + Device Posture.
  • EDR/AV: blokada LOLBins, monitoring vssadmin, wbadmin, bcdedit; polityki anty-tamper.
  • Backupy: 3-2-1, test odtwarzania, immutable w chmurze (Object Lock/WORM).
  • AppControl: Allow-listing (WDAC/AppLocker), blokada uruchamiania z %AppData%, Temp, udziałów SMB użytkowników.
  • AD tiering: konta uprzywilejowane z PAM, PAW (Privileged Access Workstation).

Windows – logika detekcji „pre-crypto”:

# Podejrzane polecenia dot. shadow copies i bootcfg
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} |
  Where-Object { $_.Properties[5].Value -match 'vssadmin|wbadmin|bcdedit|wmic.*shadowcopy' } |
  Select-Object TimeCreated, @{n='Cmd';e={$_.Properties[5].Value}}, @{n='User';e={$_.Properties[1].Value}}

Sigma – masowe operacje na plikach (renames/encryptors):

title: Ransomware-Like Mass File Rename
logsource:
  product: windows
  service: sysmon
detection:
  sel:
    EventID: 11  # FileCreate
    TargetFilename|endswith:
      - ".locked"
      - ".qilin"
      - ".crypt"
  timeframe: 5m
  condition: selection
level: high

3) Ochrona danych medycznych (PHI) – szybkie kroki IR

  • Segmentacja systemów billing/EMR i oddzielenie od frontów www.
  • DLP + egress control: bloki na uploady do „fresh” domen CDN/chmury poza allowlistą.
  • „Canary records” w bazach PHI (fałszywe, śledzone identyfikatory); alert na odczyt.
  • Notyfikacje prawne – przygotować szablony (HIPAA/RODO), lokalny regulator i klienci.

Różnice / porównania z innymi przypadkami

  • Ransomware klasyczne vs. „pure exfil” (Kazu):
    • Klasyczne: szyfrowanie + exfil; widoczne artefakty (wyłączanie VSS, noty okupu).
    • Pure exfil: brak szyfrowania, krótsze dwell time, mniejszy hałas na hostach – ciężar detekcji przenosi się na warstwę www/egress.
  • Qilin na tle 2025:
    • Skala i tempo – dziesiątki setki przypadków; celowanie w krytyczne sektory i Amerykę Płn.
    • Dowody z OSINT i opracowań branżowych potwierdzają jego czołową pozycję w tym roku.

Podsumowanie / kluczowe wnioski

  1. Dzień zdominowany przez Qilin, ale narrację zmienia Kazu – wymuszenia po samej kradzieży danych są coraz bardziej opłacalne i trudniejsze w detekcji.
  2. USA pozostaje głównym celem, lecz widoczna jest dywersyfikacja sektorowa (usługi, edukacja, zdrowie, energetyka).
  3. Dla SOC/CERT oznacza to konieczność wzmocnienia telemetrii web/egress, a nie tylko host-based anty-crypto.
  4. Organizacje powinny aktualizować playbooki IR o scenariusze „pure exfil” (bez szyfrowania) i mierzyć skuteczność: MTTA/MTTD dla anomalii ruchu wychodzącego, not tylko dla binarek szyfrujących.

Źródła / bibliografia

  1. Purple Ops – Daily Ransomware Report 11/15/2025 – statystyki dnia, zestawienie grup i sektorów. (Purple Ops)
  2. BankInfoSecurity – „Kazu expands reach; Doctor Alliance” – pierwszy głośny przypadek Kazu w Ameryce Płn., 353 GB danych. (bankinfosecurity.com)
  3. TechRadar Pro – Doctor Alliance: ~1,24 mln plików / 353 GB – szczegóły danych, skala i ryzyka dla ofiar. (TechRadar)
  4. HealthExec – żądanie 200 tys. USD, deadline 21.11.2025 – oś czasu i parametry wymuszenia. (Health Exec)
  5. Ransomware.live – „Brotherhood → Ninas Jewellery (AU)” – potwierdzenie wpisu na DLS. (ransomware.live)
  6. (Kontekst techniczny) Ransomware.live – Qilin (profil/TTP) – charakterystyka rodziny, double extortion. (ransomware.live)
  7. (Trend 2025) IndustrialCyber – aktywność Qilin w 2025 – pozycja w krajobrazie roku. (Industrial Cyber)

Uwaga o wiarygodności: część pozycji dziennych (np. Force Brokerage / Kill Security) pierwotnie pochodzi z agregatorów wpisów DLS/OSINT i może nie mieć jeszcze niezależnych, oficjalnych potwierdzeń poza stronami wyciekowymi. Zalecane jest bieżące „threat validation” przed eskalacją reakcji IR.