Archiwa: Admin - Strona 29 z 33

Microsoft: globalna awaria DNS/AFD uderza w Azure i Microsoft 365 — co się stało i jak się przygotować na „następny raz”

Wprowadzenie do problemu / definicja luki

29 października 2025 r. Microsoft doświadczył globalnej awarii usług chmurowych — użytkownicy i administratorzy raportowali problemy z logowaniem i dostępnością Microsoft 365, przerwę w działaniu portalu Azure i usług zależnych (m.in. Intune, Purview, Entra ID) oraz kaskadowe błędy w aplikacjach firm trzecich. Początkowo wskazywano na problemy DNS, a następnie Microsoft doprecyzował, że wyzwalaczem był niezamierzony change konfiguracyjny w Azure Front Door (AFD) — globalnej warstwie brzegowej/CDN używanej przez wiele usług Microsoftu.

W skrócie

Start incydentu: ok. 16:00 UTC (29.10.2025) — wzrost opóźnień, timeoutów i błędów w usługach korzystających z AFD.
Diagnoza: „inadvertent configuration change” w AFD; obserwowane również symptomy DNS na brzegu sieci.
Mitigacja: blokada zmian w AFD, roll-back do „last known good” i globalne wypychanie poprawnej konfiguracji; recovery AFD powyżej 98% dostępności przed pełnym przywróceniem.
Czas pełnej mitigacji AFD: 00:05 UTC (30.10.2025) wg osi czasu na stronie Azure Status History.
Zasięg: Microsoft 365, Azure Portal, Xbox/Minecraft oraz podmioty z wielu branż (linie lotnicze, retail, telekom, instytucje publiczne).

Kontekst / historia / powiązania

AFD jest warstwą przyjmującą ruch (entry point) dla portali i API Microsoftu. To drugi poważny incydent brzegowy w październiku 2025 r. — wcześniej Microsoft publikował retrospekcje dot. dostępności portali/AFD w innych regionach, co pokazuje jak zmiany w konfiguracji i automatyzacja potrafią nieintencjonalnie poszerzyć promień rażenia. Jednocześnie incydent nastąpił tydzień po głośnej awarii AWS, co unaocznia systemową zależność Internetu od kilku hiperskalerów.

Analiza techniczna / szczegóły luki

Wyzwalacz: niezamierzona zmiana konfiguracyjna w AFD, która spowodowała błędne trasowanie oraz degradację dostępności portali i usług zależnych; raportowano również symptomy DNS (timeouts, błędy serwera, utrata pakietów na brzegu sieci Microsoft).
Działania natychmiastowe:
- Blokada wszystkich zmian w AFD (change freeze).
- Rollback do ostatniego poprawnego stanu i globalny rollout naprawionej konfiguracji.
- Częściowo ręczna rekonwergencja węzłów oraz stopniowe kierowanie ruchu do zdrowych instancji.
Oś czasu (kluczowe punkty Azure Status History):
- 17:26 UTC — portal odcięty od AFD,
- 17:30 UTC — blokada nowych zmian,
- 17:40/18:30 UTC — wdrożenie i globalne wypychanie „last known good”,
- 00:05 UTC (30.10) — potwierdzenie mitigacji AFD.

Praktyczne konsekwencje / ryzyko

Dostęp administracyjny: brak lub opóźnienia w Microsoft 365 Admin Center oraz Azure Portal; utrudnione działania operacyjne (policy w Intune, funkcje Purview, dodatki/łączność Outlook).
Tożsamość i logowanie: przejściowe problemy z Entra ID (d. AAD) i logowaniem użytkowników do platform firmowych; skutki wtórne w SSO do aplikacji SaaS.
Łańcuch zależności: zatrzymanie lub degradacja usług u operatorów, linii lotniczych i detalistów — check-in, płatności online, serwisy konsumenckie.
Ryzyko powtarzalności: zmiany konfiguracyjne w warstwie brzegowej/CDN + automatyzacja rolloutów = potencjalny „blast radius” globalny bez błyskawicznych mechanizmów canary/guardrails.

Rekomendacje operacyjne / co zrobić teraz

Kanały awaryjne zarządzania: utrzymuj procedury i uprawnienia do zarządzania programatycznego (PowerShell/CLI/REST) na wypadek niedostępności portali; skonfiguruj Azure Service Health alerts (e-mail/SMS/webhook).
Failover na brzegu: przygotuj Traffic Manager / DNS-based failover do originów alternatywnych lub ścieżek niezależnych od AFD (gdzie to możliwe). Microsoft wskazywał ten kierunek mitigacji podczas incydentu.
Tryb „readiness”: zweryfikuj polityki change freeze, canary/gradual rollout dla konfiguracji brzegowych, a także testy chaos/simulation dla edge/CDN. Wprowadzaj pre-walidację konfiguracji na środowiskach replik danych.
Ścieżki alternatywne UI: gdy portal jest niedostępny, sprawdź preview.portal.azure.com jako tymczasowy fallback.
Mapowanie zależności: zinwentaryzuj aplikacje zależne od AFD/DNS i określ RTO/RPO oraz runbooki operacyjne (np. obejścia dla SSO). Potwierdź, że monitoring syntetyczny obejmuje brzeg Microsoft/AFD i mierzony jest z wielu vantage points (np. rozwiązania klasy ThousandEyes).
Komunikacja do biznesu: przygotuj szablony komunikatów i procedury ręcznej obsługi krytycznych procesów (np. check-in, płatności), by zredukować chaos w łańcuchu dostaw usług online.

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

AWS (poprzedni tydzień): oba incydenty miały wektor w warstwie DNS/edge, ale w przypadku Microsoftu kluczowa była konfiguracja AFD; w AWS raportowano „major DNS failure”. Wniosek: odporność na błędy konfiguracji brzegowej jest równie krytyczna jak redundancja regionów. (wnioskowanie na podstawie relacji prasowych)
Wcześniejsze awarie Azure (październik 2025): retrospekcje Microsoftu pokazują, że automatyzacja zmian i niekompatybilności API potrafią usunąć wartości konfiguracyjne i wywołać efekt domina — stąd nacisk na walidacje runtime i regionalne rollouty.

Podsumowanie / kluczowe wnioski

Incydent nie miał charakteru ataku — czynnik ludzki/procesowy (zmiana konfiguracji) w AFD doprowadził do globalnych zaburzeń.
Krytyczne znaczenie ma operacyjna gotowość: dostęp programatyczny, alerty Service Health, scenariusze Traffic Manager/DNS-failover, fallback portali i monitoring z punktów zewnętrznych.
Organizacje muszą mapować zależności od brzegów hiperskalerów i ćwiczyć procedury na wypadek utraty AFD/DNS, bo konsekwencje biznesowe wykraczają daleko poza „samą” chmurę.

Źródła / bibliografia

BleepingComputer: raport o awarii DNS/Azure Front Door (29–30 października 2025). (BleepingComputer)
Azure Status History — oś czasu i szczegóły mitigacji AFD (29–30 października 2025). (Azure Status)
Reuters: potwierdzenie przywrócenia usług Azure, wpływ branżowy. (Reuters)
The Verge: „inadvertent configuration change”, lista usług dotkniętych, status recovery. (The Verge)
Cisco ThousandEyes: techniczne obserwacje (timeouts, packet loss) na brzegu sieci Microsoft (AFD). (ThousandEyes)

ISA/IEC 62443 – Kompletny Przewodnik Po Standardzie Cyberbezpieczeństwa OT/ICS

Czym jest standard ISA/IEC 62443 i dlaczego ma znaczenie dla bezpieczeństwa OT/ICS

ISA/IEC 62443 to międzynarodowa seria standardów definiujących wymagania i procesy dla cyberbezpieczeństwa systemów automatyki przemysłowej i sterowania (Industrial Automation and Control Systems, IACS) oraz infrastruktury OT. Standard ten został opracowany przez International Society of Automation (ISA) i przyjęty przez International Electrotechnical Commission (IEC), tworząc wspólne, konsensusowe ramy ochrony dla wszystkich sektorów przemysłu wykorzystujących systemy ICS.

Czytaj dalej

TEE.Fail: nowy atak, który podważa „confidential computing” na CPU Intela, AMD i w ekosystemie GPU NVIDIA

Wprowadzenie do problemu / definicja luki

Zespół badaczy z Georgia Tech i Purdue przedstawił technikę TEE.Fail, która z użyciem taniego (≈< 1000 USD) interposera magistrali DDR5 pozwala odczytywać tajemnice z TEE (Trusted Execution Environment) nowej generacji – m.in. Intel TDX/SGX oraz AMD SEV-SNP (nawet z włączonym Ciphertext Hiding). Co więcej, wykradzione klucze atestacyjne umożliwiają podszywanie się pod zaufane środowiska i podważają modele zaufania także w GPU Confidential Computing NVIDII (np. H100).

W skrócie

Vektor ataku: pasywny podsłuch ruchu pamięci DDR5 z interposerem; brak potrzeby modyfikacji danych w locie.
Słaby punkt: deterministyczne szyfrowanie pamięci TEE (ta sama dana → ten sam szyfrogram), co umożliwia korelację wzorców i ekstrakcję kluczy.
Skutki: kradzież kluczy ECDH i kluczy atestacyjnych TDX/SGX, fałszowanie atestacji (także dla GPU-CC NVIDII), uruchamianie zadań poza TEE przy „zielonej” atestacji.
Koszt/próg wejścia: komponenty „z półki”, całość < 1000 USD.
Status vendorów: Intel potwierdził badania i utrzymuje, że ataki fizyczne pozostają poza modelem zagrożeń dla SGX/TDX; publikacja ogłoszenia bezpieczeństwa 28 października 2025 r.

Kontekst / historia / powiązania

TEE.Fail to następca ataków WireTap i Battering RAM, które dotyczyły DDR4 oraz starszych platform (gł. SGX/SEV bez DDR5). Kluczowa różnica: pierwsza demonstracja praktycznej skuteczności na DDR5 oraz CVM (Confidential VMs) opartych o Intel TDX i AMD SEV-SNP – czyli rozwiązania stanowiące fundament współczesnych wdrożeń „confidential computing”.

Analiza techniczna / szczegóły luki

Interposer DDR5. Badacze zbudowali interposer podpinany do jednego kanału DDR5 DIMM (DDR5 ma dwa kanały na moduł, co upraszcza konstrukcję) i pasywnie przechwytywali cały ruch DRAM między CPU a pamięcią. Zapis/odczyt są widoczne nawet przy szyfrowaniu pamięci przez TEE.

Szyfrowanie deterministyczne. SGX/TDX oraz SEV-SNP używają trybów szyfrowania pamięci, które w praktyce są deterministyczne (identyczny plaintext → identyczny ciphertext w tej samej lokalizacji). To umożliwia budowę słowników i korelację wzorców; na ilustracjach badaczy różnica między prawidłowym szyfrowaniem a deterministycznym jest wyraźna.

Ekstrakcja i fałszowanie atestacji (Intel). Z przechwyconych śladów udało się pozyskać Provisioning Certification Key – per-CPU klucz z łańcucha zaufania SGX/TDX. Mając go, atakujący fałszuje raporty atestacyjne i może uruchamiać obciążenia poza TEE, a jednak przekonać systemy, że działają w zaufanym CVM (nawet na innej architekturze CPU). Intel potwierdza i podkreśla, że fizyczne interposery są out-of-scope dla modelu zagrożeń TDX/SGX.

AMD SEV-SNP z Ciphertext Hiding. Badacze pokazali, że ataki działają nawet przy aktywnym Ciphertext Hiding (Zen 5/EPYC 5. gen), a więc mimo ograniczania widoczności szyfrogramów przez hypervisor. Dodatkowo zademonstrowano ekstrakcję kluczy podpisu OpenSSL wewnątrz VM chronionej przez SEV-SNP.

GPU Confidential Computing (NVIDIA). Ponieważ GPU-CC NVIDII opiera się na atestacji CVM CPU (TDX/SEV-SNP), przejęcie/wyłudzenie kluczy atestacyjnych CPU pozwala „pożyczać” atestacje GPU i prezentować zadania AI jako uruchomione w zabezpieczonym środowisku, choć faktycznie tak nie jest. To łamie model zaufania dla zadań AI (np. chaty LLM, inferencja modeli) na H100.

Praktyczne konsekwencje / ryzyko

Chmura/CVM: dostawca z dostępem fizycznym do serwera może podsłuchiwać i fałszować atestacje, wynosząc dane/klucze bez wykrycia z poziomu software’u.
Blockchain/MEV: demonstracja fałszowania atestacji TDX w sieci BuilderNet (Ethereum block builders), otwierająca drogę do niejawnego frontrunningu i dostępu do poufnych transakcji.
AI/LLM-as-a-Service: możliwość „udowodnienia” GPU-CC przy realnym uruchomieniu poza TEE → ryzyko wycieku danych treningowych/kluczy API i manipulacji wynikiem.
Szeroki ekosystem TEE: Intel oficjalnie klasyfikuje interposery jako poza modelem zagrożeń, co oznacza, że brak łatwych łatek firmware’owych – konieczne będą zmiany w założeniach architektonicznych i procesach operacyjnych.

Rekomendacje operacyjne / co zrobić teraz

Modeluj zagrożenia z fizycznym dostępem – jeśli Twoje ryzyko obejmuje atakującego z dostępem do szafy serwerowej, nie zakładaj, że TDX/SEV-SNP w DDR5 zapewnią pełną poufność. Zaktualizuj oceny ryzyka i umowy z operatorami DC/colocation.
Zarządzaj zaufaniem do atestacji – wiąż atestacje z tożsamością sprzętu i lokalizacją (asset-binding), wdrażaj policyjne listy dozwolonych hostów, łącz atestację z kontrolą łańcucha dostaw/IMD i monitoringiem fizycznym.
Segmentuj dane wrażliwe – minimalizuj ekspozycję tajemnic w TEE (krótkotrwałe klucze, HSM/KMS poza hostem, dzielone sekrety). Dla AI rozważ prywatność po stronie klienta/lokalne szyfrowanie przed wysłaniem do chmury. (Wnioski operacyjne na bazie skutków TEE.Fail).
Twarde kontrole fizyczne – plombowanie, CCTV, ewidencja serwisantów, detection-by-presence (wykrywanie rozpięcia DIMM/risera). (Wnioski operacyjne wynikające z wektora ataku).
Śledź komunikaty vendorów – Intel opublikował ogłoszenie bezpieczeństwa (28.10.2025). Monitoruj zapowiedziane stanowiska AMD i NVIDII dot. dostosowań modelu zagrożeń/mitigacji.
Architektura „defense-in-depth” – TEE traktuj jako warstwę, nie jedyne zabezpieczenie. Odnów procedury DLP, EDR w hipervisorze, izolację sieciową CVM i kontrole dostępu do danych w spoczynku. (Dobre praktyki ogólne poparte kontekstem NCSC).

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

WireTap/Battering RAM (DDR4): atak na starszą generację pamięci/CPU; TEE.Fail eskaluje do DDR5 i CVM (TDX/SEV-SNP), co uderza w aktualne wdrożenia chmurowe.
RMPocalypse (CVE-2025-0033, AMD SEV-SNP): błąd inicjalizacji RMP łamie integralność VMs; TEE.Fail to atak fizyczny/side-channel na poufność + atestację. Razem pokazują, że zarówno błędy implementacji, jak i założenia modelu zagrożeń osłabiają dzisiejsze TEE.

Podsumowanie / kluczowe wnioski

TEE.Fail nie jest „kolejną” podatnością z CVE, lecz uderzeniem w fundamenty zaufania do confidential computing w epoce DDR5. Przy fizycznym dostępie do serwera i deterministycznym szyfrowaniu pamięci, granice TEE znikają: można wyciągnąć klucze, fałszować atestacje i obchodzić GPU-CC. Organizacje muszą przewartościować model zagrożeń, twardo kontrolować fizyczny dostęp oraz wiązać atestację ze sprzętem i lokalizacją. Krótkoterminowo – operacyjne obejścia i polityki; długoterminowo – zmiany w projektach szyfrowania pamięci i łańcuchach atestacji.

Źródła / bibliografia

Strona badaczy: TEE.fail – Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition (FAQ, scenariusze ataku, skutki, mitgacje). (tee.fail)
Intel Security Announcement 2025-10-28-001 (TEE.fail) – stanowisko Intela i zakres modeli zagrożeń. (Intel)
BleepingComputer: „TEE.Fail attack breaks confidential computing on Intel, AMD, NVIDIA CPUs” – przegląd skutków i demonstracji (BuilderNet, fałszywe atestacje, wyciek ECDH). (BleepingComputer)
The Hacker News: „New TEE.Fail Side-Channel Attack Extracts Secrets from Intel and AMD DDR5 Secure Enclaves” – kontekst kosztu sprzętu i nowości względem DDR4. (The Hacker News)
NCSC (Szwajcaria): „Technology brief: Confidential Computing” – tło i modele TEE/CVM dla zrozumienia wpływu TEE.Fail. (ncsc.admin.ch)

Stare luki w wtyczkach GutenKit i Hunk Companion masowo wykorzystywane do ataków na WordPressa

Wprowadzenie do problemu / definicja luki

Defiant (Wordfence) ostrzega przed nową falą masowych ataków na strony WordPress, w których przestępcy wykorzystują trzy krytyczne luki w dwóch popularnych wtyczkach: GutenKit oraz Hunk Companion. Według podsumowania SecurityWeek, kampania ponownie rozkręciła się 8 października 2025 r., a w ciągu dwóch tygodni zablokowano ok. 9 mln prób eksploatacji tych błędów. Ataki polegają m.in. na nieautoryzowanej instalacji/aktywacji wtyczek oraz przesyłaniu plików pozwalających na przejęcie witryny i utrzymanie dostępu.

W skrócie

Dotknięte wtyczki: GutenKit (≤ 2.1.0/2.1.0; naprawa w 2.1.1), Hunk Companion (luki do 1.8.4 i obejście naprawy – CVE-2024-11972; naprawy min. w 1.8.5).
Skutki: możliwość RCE poprzez instalację złośliwych lub podatnych wtyczek, upload backdoorów, automatyczne logowanie jako administrator, masowe „deface’y”.
Skala: miliony zablokowanych prób; fala od 8.10.2025 r., raporty potwierdzające kampanię również poza Defiant.
Działania natychmiastowe: aktualizacja do najnowszych wersji, przegląd logów/plików pod kątem IOC, rotacja haseł i kluczy, twarde reguły WAF i ograniczenia API.

Kontekst / historia / powiązania

Obie luki są „znane” od 2024 r. i mają przypisane identyfikatory CVE-2024-9234 (GutenKit) oraz CVE-2024-9707 i CVE-2024-11972 (Hunk Companion – druga to obejście pierwszej). Mimo że poprawki zostały opublikowane ponad rok temu, niski poziom aktualizacji w ekosystemie WordPress sprawia, że stare błędy pozostają atrakcyjnym celem dla operatorów botnetów i grup przestępczych. Najnowsza fala ataków potwierdza tę tendencję.

Analiza techniczna / szczegóły luki

GutenKit (CVE-2024-9234)

Błąd to brak kontroli uprawnień w funkcji odpowiadającej za instalację/aktywację wtyczek zewnętrznych (REST endpoint install-active-plugin). Skutkiem jest nieautoryzowany upload plików podszywających się pod wtyczki i możliwość aktywacji czegokolwiek – droga do RCE. Podatne były wersje ≤ 2.1.0, naprawa w 2.1.1.

Hunk Companion (CVE-2024-9707 i CVE-2024-11972)

W REST API wp-json/hc/v1/themehunk-import występował brak weryfikacji uprawnień, co pozwalało niezalogowanemu napastnikowi instalować/aktywować dowolne wtyczki z repozytorium, a następnie eskalować do RCE z użyciem podatnych rozszerzeń. Luka CVE-2024-11972 została opisana jako obejście poprzedniej poprawki (patch bypass). Naprawy udokumentowano co najmniej w 1.8.5 (część źródeł mówi o 1.9.0 – zalecamy najnowszą wersję).

Łańcuch ataku i artefakty

Defiant opisał dystrybucję złośliwego archiwum ZIP podszywającego się pod wtyczkę hostowanego na GitHubie. W paczce znajdowały się skrypty‐backdoory zapewniające persistencję, automatyczne logowanie na admina, zmiany uprawnień plików, eksfiltrację (przeglądanie/pobieranie plików, tworzenie ZIP całych katalogów), a nawet narzędzia do hurtowej defacement oraz sniffingu.

Praktyczne konsekwencje / ryzyko

Pełne przejęcie witryny (RCE) i trwały dostęp dzięki backdoorom.
Masowe nadużycia SEO/defacement, wstrzyknięcia skryptów reklamowych lub przekierowań.
Wycieki danych z wp-content/wp-includes oraz kopii konfiguracyjnych.
Lateral movement na współdzielonych hostingach poprzez wspólne zasoby.

Rekomendacje operacyjne / co zrobić teraz

Natychmiastowa aktualizacja:
- GutenKit → ≥ 2.1.1.
- Hunk Companion → ≥ 1.8.5 (lub nowsza dostępna; część źródeł wskazuje 1.9.0).
Audyt plików i IOC: poszukaj nieznanych katalogów w wp-content/plugins/ i wp-content/uploads/, plików .php w uploads/, świeżych zip/tar, skryptów z funkcjami system()/exec() oraz wpisów w wp_options (active_plugins) dodających obce wtyczki – nawiązanie do artefaktów opisanych przez Defiant.
Twarde reguły WAF: blokuj/ograniczaj dostęp do newralgicznych endpointów REST, w tym install-active-plugin, themehunk-import, metod POST z niezaufanych UA/ASN; włącz weryfikację nonces i nagłówków.
Ograniczenia administracyjne: zablokuj instalację wtyczek z poziomu frontu/REST (np. DISALLOW_FILE_MODS), wymuś MFA dla wp-admin/, zmniejsz powierzchnię API (application passwords, wyłącz nieużywane).
Higiena kont/kluczy: rotacja haseł, keys & salts w wp-config.php; przejrzyj konta adminów (szukaj „nowych” użytkowników).
Reakcja na incydent: jeżeli wykryto ślady kompromitacji – migruj na czyste środowisko, wgraj świeżą kopię WordPressa i motywu, przywróć tylko zweryfikowaną treść, a nie pliki wykonywalne.

Różnice / porównania z innymi przypadkami

W przeciwieństwie do klasycznych RCE przez upload w formularzach, tutaj wektor to funkcje instalacji/aktywacji wtyczek w REST API – przez to atak jest szybki i automatyzowalny (botnety).
Schemat przypomina wcześniejsze fale przeciw popularnym wtyczkom (np. serie przejęć poprzez installer endpoints); niezależne raporty (m.in. BleepingComputer) potwierdzają bieżącą masowość kampanii.

Podsumowanie / kluczowe wnioski

To nie zero-daye, ale stare luki – dlatego kluczowe jest utrzymywanie aktualizacji.
Atakujący wykorzystują REST API do wgrywania i aktywowania komponentów prowadzących do pełnego przejęcia strony.
Administratorzy powinni łączyć patching z kontrolami konfiguracyjnymi (wyłączenie możliwości instalacji, ograniczenie API), monitoringiem integralności plików i MFA.

Źródła / bibliografia

SecurityWeek: opis kampanii (daty, skala, modus operandi ZIP/backdoory). (SecurityWeek)
NVD (CVE-2024-9234 – GutenKit): szczegóły błędu i zakres wersji. (NVD)
NVD (CVE-2024-9707 – Hunk Companion): szczegóły endpointu i wpływu. (NVD)
The Hacker News (CVE-2024-11972 – obejście naprawy, wersja naprawcza 1.8.5). (The Hacker News)
WPScan / Baza podatności (GutenKit < 2.1.1 – Arbitrary File Upload). (WPScan)
(Dodatkowo o bieżącej fali) BleepingComputer: niezależne potwierdzenie masowych ataków (24.10.2025). (BleepingComputer)

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

MFA bez wyjątków na VPN, RDP, poczcie i aplikacjach krytycznych; wymuś klient-based MFA dla kont uprzywilejowanych.
Higiena tożsamości: rotacja haseł po wyciekach, blokady na „password spraying” (T1110.003), monitorowanie NTLM.
Twardnienie RDP: wyłącz zdalne logowanie tam, gdzie zbędne; kontrola fDenyTSConnections, ograniczenia sieciowe/Jump Host; Restricted Admin tylko jeśli świadomie zarządzany.
Egress/Exfil kontrola: DLP/CTI-driven blokady dla Backblaze i nietypowych klientów S3/WebDAV; monitoruj użycie Cyberduck, WinRAR w trybie archiwizacji masowej.
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

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

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

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.
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.
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.
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.
Ś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

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.
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”.
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).
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”.
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).
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

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

Masowe ataki na WordPress: przestępcy wykorzystują stare luki w GutenKit i Hunk Companion

Wprowadzenie do problemu / definicja luki

Od 8–9 października 2025 r. obserwowana jest kampania masowych ataków na strony WordPress, której celem są stare, ale wciąż powszechnie używane wersje wtyczek GutenKit oraz Hunk Companion. Według danych cytowanych przez BleepingComputer, dostawca zabezpieczeń Wordfence zablokował 8,7 mln prób w ciągu dwóch dni. Atakujący łączą podatności pozwalające bez uwierzytelnienia instalować dowolne wtyczki lub wgrywać pliki podszyte pod wtyczki, co eskaluje do zdalnego wykonania kodu (RCE).

W skrócie

Na celowniku: GutenKit (≤ 2.1.0 — CVE-2024-9234) i Hunk Companion (≤ 1.8.4 — CVE-2024-9707; ≤ 1.8.5 — CVE-2024-11972). Łatki: GutenKit 2.1.1 (X 2024), Hunk Companion 1.9.0 (XII 2024).
Wektor: nieautoryzowane endpointy REST umożliwiające instalację/aktywację wtyczek lub wgrywanie „fałszywych” paczek.
Łańcuch ataku: po uzyskaniu dostępu napastnicy doinstalowują złośliwą paczkę „up” albo podatną wtyczkę WP Query Console (brak poprawek, RCE), aby utrzymać trwałą kontrolę.
Ślady (IoC): żądania do /wp-json/gutenkit/v1/install-active-plugin, /wp-json/hc/v1/themehunk-import; katalogi: /up, /background-image-cropper, /ultra-seo-processor-wp, /oke, /wp-query-console.

Kontekst / historia / powiązania

Luki w Hunk Companion były już nagłaśniane pod koniec 2024 r. — CVE-2024-11972 jest poprawką/bypassem wcześniejszej CVE-2024-9707; obie ocenione jako CVSS 9.8 (krit.). W praktyce błędy umożliwiają atakującemu instalowanie i aktywowanie dowolnych wtyczek z repozytorium WordPress (także tych wycofanych), co stanowi wygodny „most” do RCE. Równolegle CVE-2024-9234 w GutenKit pozwala uploadować pliki podszyte pod wtyczki i aktywować je bez uprawnień.

Analiza techniczna / szczegóły luki

GutenKit (CVE-2024-9234). Brak właściwej autoryzacji/capability check w funkcji obsługującej install-active-plugin (REST) umożliwia nieautoryzowaną instalację/aktywację wtyczek lub wgranie arbitralnego pliku udającego wtyczkę (do 2.1.0 włącznie).

Hunk Companion (CVE-2024-9707, CVE-2024-11972). Błędy w endpointach themehunk-import (REST) pozwalają na nieautoryzowane POST-y skutkujące instalacją/aktywacją wtyczek. CVE-2024-11972 domyka wcześniejszą łatę i również oceniona jest na CVSS 9.8; wersja naprawcza to 1.9.0.

Eskalacja do RCE. Po pierwszym kroku atakujący:

instalują paczkę „up” (ZIP hostowany m.in. na zewnętrznych repozytoriach), zawierającą zaciemnione skrypty do uploadu, pobierania, usuwania plików i zmiany uprawnień; jeden z komponentów maskuje się jako element All in One SEO i automatycznie loguje napastnika jako admina,
albo doinstalowują podatną wtyczkę WP Query Console ≤ 1.0 (CVE-2024-50498, brak poprawek) i uzyskują RCE bez uwierzytelnienia.

IoC i TTP. W logach ruchu widoczne są żądania do:
/wp-json/gutenkit/v1/install-active-plugin oraz /wp-json/hc/v1/themehunk-import (sygnatura exploitów). W systemie plików sprawdź katalogi: /up, /background-image-cropper, /ultra-seo-processor-wp, /oke, /wp-query-console.

Praktyczne konsekwencje / ryzyko

Przejęcie strony i trwała persystencja (backdoory, automatyczny login na admina).
Eksfiltracja danych (pliki, konfiguracje, dane klientów), modyfikacje treści, wstrzykiwanie SEO-spam/malvertising.
Pivot na serwer — RCE pozwala wykorzystywać host do dalszych ataków (phishing, botnet, cryptomining).
Ryzyka prawne i reputacyjne (RODO, utrata pozycji SEO).
Źródła branżowe raportują o łączeniu kilku luk w jeden łańcuch, co zwiększa automatyzację i skalę kampanii.

Rekomendacje operacyjne / co zrobić teraz

1) Patching i audyt wersji

Natychmiast zaktualizuj:
- GutenKit → ≥ 2.1.1,
- Hunk Companion → ≥ 1.9.0.
Jeśli wtyczki są zbędne — usuń je całkowicie (dezaktywacja to za mało).

2) Detekcja nadużyć (logi i pliki)

Przeskanuj logi HTTP pod kątem:
- "/wp-json/gutenkit/v1/install-active-plugin"
- "/wp-json/hc/v1/themehunk-import"
Przeszukaj system plików:
- katalogi: /up, /background-image-cropper, /ultra-seo-processor-wp, /oke, /wp-query-console.

Przykładowe polecenia (Linux):

# Szukaj podejrzanych żądań w access.log (Nginx/Apache)
grep -E 'wp-json/(gutenkit|hc)/v1/(install-active-plugin|themehunk-import)' /var/log/*/access.log*

# Wykryj "podejrzane" katalogi w instalacji WP
cd /var/www/html
find . -maxdepth 3 -type d -regex ".*/\(up\|background-image-cropper\|ultra-seo-processor-wp\|oke\|wp-query-console\)"

3) Ograniczenia i WAF

Tymczasowo blokuj/limituj dostęp do ww. endpointów REST (np. reguła WAF/ModSecurity) do czasu aktualizacji.
Stosuj Rate Limiting i blokowanie IP/ASN powiązanych z falą skanów (dane z bieżących raportów bezpieczeństwa).

4) Hardening WordPress

Włącz auto-update dla wtyczek i rdzenia.
Ogranicz liczbę adminów, wymuś MFA i klucze aplikacji dla integracji.
Utrzymuj kopie zapasowe offline i testuj odtwarzanie.

5) Incydent response (jeśli są ślady kompromitacji)

Odizoluj witrynę (maintenance/firewall).
Zrzut i analiza artefaktów: nowe konta admin, cron, wp-content/uploads, mu-plugins, wp-config.php.
Usuń backdoory, zaktualizuj do bezpiecznych wersji, zresetuj hasła i klucze salts.
Rozważ przywrócenie z kopii sprzed incydentu i pełny przegląd wtyczek (usuń porzucone).

Różnice / porównania z innymi przypadkami

Klasyczne RCE w wtyczce (np. WP Query Console) zwykle wymaga pojedynczej luki; tutaj napastnicy najpierw wymuszają instalację podatnej wtyczki przez inny błąd (REST), co zwiększa skuteczność automatycznych kampanii.
Specyfika WordPress.org: możliwość sięgnięcia po stare, wycofane paczki w repozytorium, co ułatwia „dowiezienie” RCE po uzyskaniu dostępu do endpointu instalacji.

Podsumowanie / kluczowe wnioski

Trwają zautomatyzowane, masowe ataki na WordPress z użyciem starych błędów w GutenKit i Hunk Companion, z potwierdzonymi milionami prób w krótkim czasie. Priorytetem jest aktualizacja lub deinstalacja podatnych wtyczek, przegląd logów pod kątem specyficznych endpointów REST oraz poszukiwanie charakterystycznych katalogów/pliki IoC. Dla zespołów SecOps to sygnał do tworzenia reguł WAF/IDS oraz blokad na poziomie infrastruktury.

Źródła / bibliografia

BleepingComputer — „Hackers launch mass attacks exploiting outdated WordPress plugins”, 24 października 2025. (BleepingComputer)
NVD — CVE-2024-9234 (GutenKit): opis błędu i wektor ataku. (NVD)
NVD — CVE-2024-11972 (Hunk Companion): brak autoryzacji endpointów, wersja naprawcza. (NVD)
WPScan — WP Query Console ≤ 1.0 — Unauthenticated RCE (CVE-2024-50498) — brak poprawek. (WPScan)
SecurityWeek — łączenie luk Hunk Companion + WP Query Console do przejęcia stron (grudzień 2024). (SecurityWeek)