Wojciech Ciemski, Autor w serwisie Security Bez Tabu

CVE-2025-67586: luka Broken Access Control w WordPress Highlight and Share 5.2.0 umożliwia nieautoryzowaną wysyłkę e-maili

Wprowadzenie do problemu / definicja

Wtyczki WordPress odpowiadające za udostępnianie treści często korzystają z mechanizmów AJAX dostępnych bezpośrednio z poziomu publicznego interfejsu serwisu. Jeżeli implementacja po stronie serwera nie weryfikuje prawidłowo uprawnień użytkownika, pojawia się klasa błędów określana jako Broken Access Control, czyli nieprawidłowa kontrola dostępu. W przypadku CVE-2025-67586 problem dotyczy wtyczki Highlight and Share w wersjach do 5.2.0 włącznie, gdzie możliwe jest wywołanie funkcji współdzielenia treści przez e-mail bez uwierzytelnienia.

W skrócie

Podatność dotyczy wtyczki Highlight and Share dla WordPress i została sklasyfikowana jako brak autoryzacji. Problem występuje w wersjach do 5.2.0 włącznie i może zostać wykorzystany bez posiadania konta w aplikacji, jeśli napastnik pozyska poprawny nonce powiązany z publicznie dostępnym wpisem. W efekcie atakujący może wymusić wysyłanie wiadomości e-mail z poziomu witryny.

Dotknięty komponent: WordPress Highlight and Share
Wersje podatne: do 5.2.0 włącznie
Typ błędu: Broken Access Control / Missing Authorization
Skutek: nieautoryzowana wysyłka wiadomości e-mail
Zalecenie: aktualizacja do wersji 5.3.0 lub nowszej

Kontekst / historia

Ekosystem WordPress od lat pozostaje jednym z najczęściej analizowanych środowisk pod kątem bezpieczeństwa, szczególnie w obszarze dodatków rozszerzających funkcjonalność CMS. Wtyczki odpowiedzialne za udostępnianie treści, formularze kontaktowe czy integracje społecznościowe często wykorzystują publiczne akcje AJAX, co zwiększa powierzchnię ataku. W omawianym przypadku luka została opisana publicznie i zarejestrowana jako CVE-2025-67586.

Charakter podatności wskazuje na dobrze znany problem projektowy: logika aplikacyjna dopuszcza wykonanie operacji biznesowej na podstawie parametrów żądania i nonce, ale bez pełnego sprawdzenia, czy żądanie pochodzi od użytkownika faktycznie uprawnionego do skorzystania z tej funkcji. To istotne rozróżnienie, ponieważ nonce w WordPress nie jest mechanizmem autoryzacji, lecz jedynie dodatkowym zabezpieczeniem kontekstowym.

Analiza techniczna

Sedno problemu polega na tym, że akcja AJAX odpowiedzialna za przesyłanie treści wpisu przez e-mail nie wymaga skutecznego sprawdzenia uprawnień użytkownika. Jeżeli aplikacja ufa samemu nonce i nie wymusza aktywnej, uwierzytelnionej sesji lub dodatkowej walidacji po stronie serwera, możliwe staje się wywołanie tej funkcji przez osobę nieuprawnioną.

Przykładowy scenariusz ataku może wyglądać następująco:

napastnik identyfikuje witrynę korzystającą z podatnej wersji wtyczki,
odwiedza publicznie dostępny wpis obsługiwany przez funkcję „share via email”,
pozyskuje ważny nonce ujawniony w interfejsie lub ruchu aplikacyjnym,
wysyła własne żądanie POST do endpointu wp-admin/admin-ajax.php,
przekazuje parametry wiadomości, takie jak odbiorca, temat, treść i identyfikator wpisu,
serwis realizuje wysyłkę bez wymogu logowania.

Taki model błędu oznacza, że backend przyznaje zbyt duże zaufanie danym pochodzącym z warstwy frontendowej. Nie dochodzi tu bezpośrednio do zdalnego wykonania kodu ani przejęcia konta administratora, ale atakujący zyskuje możliwość wykonania realnej operacji biznesowej w imieniu witryny. Jeżeli dodatkowo brak ograniczeń liczby żądań, filtrowania odbiorców czy mechanizmów antyspamowych, skala nadużycia może gwałtownie wzrosnąć.

Konsekwencje / ryzyko

Najbardziej bezpośrednim skutkiem podatności jest możliwość nieautoryzowanego wysyłania wiadomości e-mail z witryny. Nawet jeśli funkcja ogranicza się do szablonu współdzielenia treści, może zostać wykorzystana do rozsyłania spamu, testowania aktywnych adresów odbiorców lub budowania wiarygodności wiadomości phishingowych poprzez użycie prawdziwej domeny serwisu.

Z perspektywy operacyjnej ryzyko obejmuje nie tylko samo nadużycie funkcji, ale również skutki wtórne związane z reputacją i dostępnością poczty wychodzącej.

obciążenie infrastruktury pocztowej,
pogorszenie reputacji domeny i adresu IP,
możliwe wpisanie na listy blokujące,
wzrost liczby zgłoszeń abuse,
utrudnienia w dostarczaniu legalnej korespondencji,
wykorzystanie witryny jako pośrednika w kampaniach socjotechnicznych.

W środowiskach firmowych skutki mogą być szczególnie odczuwalne, gdy serwis korzysta ze wspólnej infrastruktury SMTP lub usług transakcyjnych współdzielonych z innymi aplikacjami. Nawet pozornie ograniczona luka może więc przełożyć się na realne koszty operacyjne i straty wizerunkowe.

Rekomendacje

Podstawowym działaniem naprawczym jest aktualizacja wtyczki Highlight and Share do wersji 5.3.0 lub nowszej. Jeżeli wdrożenie poprawki nie jest możliwe od razu, warto tymczasowo wyłączyć funkcję współdzielenia przez e-mail albo dezaktywować całą wtyczkę do czasu usunięcia ryzyka.

Administratorzy i zespoły bezpieczeństwa powinni dodatkowo wdrożyć następujące działania:

zweryfikować, czy w środowisku działa podatna wersja wtyczki,
przeanalizować logi żądań do wp-admin/admin-ajax.php,
sprawdzić nietypowe serie wywołań akcji związanych z udostępnianiem treści,
przejrzeć logi SMTP i wolumen poczty wychodzącej,
wdrożyć rate limiting oraz reguły WAF dla publicznych endpointów AJAX,
ograniczyć liczbę publicznie dostępnych akcji AJAX do niezbędnego minimum,
egzekwować autoryzację po stronie serwera zamiast polegać wyłącznie na nonce,
monitorować reputację domeny i adresów IP wykorzystywanych do wysyłki.

Dla deweloperów to kolejna lekcja, że nonce nie zastępuje mechanizmu kontroli dostępu. Każda operacja mająca skutki biznesowe, zwłaszcza wysyłanie wiadomości, modyfikacja danych czy eksport informacji, powinna być objęta jednoznaczną walidacją uprawnień oraz kontekstu żądania.

Podsumowanie

CVE-2025-67586 pokazuje, jak pozornie niewielki błąd w logice autoryzacji może doprowadzić do praktycznych nadużyć w środowisku WordPress. Luka w Highlight and Share do wersji 5.2.0 włącznie umożliwia nieautoryzowane wywołanie funkcji wysyłki e-maili, co może skutkować spamem, pogorszeniem reputacji domeny i wykorzystaniem serwisu w kampaniach phishingowych. Kluczowe działania to szybka aktualizacja, analiza logów pod kątem nadużyć oraz przegląd sposobu zabezpieczania publicznych endpointów AJAX.

Źródła

Exploit Database – https://www.exploit-db.com/exploits/52511
NVD – https://nvd.nist.gov/vuln/detail/CVE-2025-67586
Patchstack – https://patchstack.com/database/Wordpress/Plugin/highlight-and-share/vulnerability/wordpress-highlight-and-share-plugin-5-2-0-broken-access-control-vulnerability
Wordfence Intelligence – https://www.wordfence.com/threat-intel/vulnerabilities/id/9ddcdc04-d381-4870-bc57-af76e0b5185a

Natywne techniki LOTL w macOS rosnącym zagrożeniem dla środowisk firmowych

Wprowadzenie do problemu / definicja

Techniki Living off the Land, określane skrótem LOTL, polegają na wykorzystywaniu legalnych i wbudowanych w system operacyjny narzędzi do realizacji działań ofensywnych. W praktyce oznacza to, że napastnik nie musi dostarczać klasycznego złośliwego oprogramowania, ponieważ może użyć zaufanych komponentów systemowych do uruchamiania poleceń, budowy persystencji, rozpoznania środowiska oraz eksfiltracji danych.

W środowisku macOS zjawisko to zyskuje na znaczeniu wraz z rosnącą obecnością komputerów Apple w organizacjach. Dotyczy to szczególnie zespołów deweloperskich, administratorów, działów bezpieczeństwa i kadry technicznej, czyli grup mających dostęp do najbardziej wrażliwych zasobów przedsiębiorstwa.

W skrócie

Ataki na macOS coraz częściej opierają się na nadużywaniu natywnych mechanizmów systemowych zamiast klasycznych plików malware. Szczególnie istotne są komponenty takie jak AppleScript, osascript, launchctl, curl, mechanizmy automatyzacji aplikacji oraz funkcje związane z metadanymi systemowymi.

Dla obrońców oznacza to wyraźne utrudnienie detekcji, ponieważ aktywność przeciwnika może do złudzenia przypominać zwykłe działania użytkownika lub administratora. W efekcie organizacje muszą odejść od wyłącznie sygnaturowego podejścia do ochrony stacji roboczych i postawić na monitoring behawioralny.

Kontekst / historia

Przez długi czas macOS był postrzegany jako platforma mniej atrakcyjna dla cyberprzestępców niż Windows. Ten obraz stopniowo się zmienia. W nowoczesnych przedsiębiorstwach komputery Mac są dziś szeroko wykorzystywane w obszarach o wysokiej wartości biznesowej, w tym przy dostępie do repozytoriów kodu, systemów CI/CD, środowisk chmurowych, kluczy SSH, tokenów sesyjnych i narzędzi administracyjnych.

Wraz ze wzrostem znaczenia tych urządzeń rośnie zainteresowanie nimi ze strony operatorów infostealerów, grup przestępczych i aktorów prowadzących ataki ukierunkowane. Dodatkowym problemem jest to, że natywne techniki LOTL w macOS są wciąż słabiej opisane niż analogiczne scenariusze znane z ekosystemu Windows, co utrudnia modelowanie zagrożeń i tworzenie skutecznych reguł wykrywania.

Analiza techniczna

Największą siłą technik LOTL jest wykorzystanie zaufania, jakim objęte są legalne binaria i usługi systemowe. Atakujący korzystają z faktu, że takie komponenty są obecne na każdej stacji, często podpisane i zwykle nie wywołują alarmów opartych na reputacji plików.

Pierwszym ważnym obszarem jest wykonanie poleceń i automatyzacja. W macOS duże znaczenie mają AppleScript, JavaScript for Automation oraz narzędzie osascript, które pozwalają uruchamiać skrypty i sterować aplikacjami. Mechanizmy te mogą zostać użyte do wywoływania kolejnych etapów ataku, interakcji z legalnym oprogramowaniem lub działania w kontekście aktualnie zalogowanego użytkownika.

Drugim obszarem jest persystencja. Napastnicy mogą wykorzystywać launchctl, LaunchAgents i LaunchDaemons do automatycznego uruchamiania swoich komponentów po zalogowaniu użytkownika albo przy starcie systemu. Z perspektywy operacyjnej takie zmiany często wyglądają jak zwykła konfiguracja administracyjna, co utrudnia ich szybkie wychwycenie.

Trzecim elementem jest obchodzenie zabezpieczeń. W praktyce może to obejmować usuwanie atrybutu kwarantanny, nadużywanie legalnych ścieżek uruchamiania aplikacji oraz opieranie się na działaniach wykonywanych ręcznie przez użytkownika w wyniku socjotechniki. Dzięki temu część mechanizmów ochronnych, takich jak kontrole uruchamiania, może zostać osłabiona bez potrzeby dostarczania klasycznego exploita.

Czwarty obszar to rozpoznanie i eksfiltracja. Narzędzia takie jak system_profiler mogą służyć do zbierania informacji o systemie i sprzęcie, a curl, dig oraz podobne komponenty mogą zostać wykorzystane do pobierania dodatkowych ładunków, komunikacji z infrastrukturą sterującą lub przesyłania danych na zewnątrz organizacji. Badacze wskazują również na nadużycia mniej oczywistych funkcji, takich jak zdalne sterowanie aplikacjami czy użycie metadanych Spotlight do ukrywania poleceń lub payloadów.

W rezultacie atak nie musi opierać się na jednym łatwo identyfikowalnym dropperze. Zamiast tego organizacja obserwuje ciąg pozornie legalnych operacji, takich jak pobranie pliku, uruchomienie skryptu, odczyt metadanych, rejestracja agenta startowego i komunikacja sieciowa z użyciem standardowych narzędzi systemowych.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem stosowania technik LOTL jest utrata widoczności. Jeżeli środowisko obronne opiera się głównie na sygnaturach malware oraz reputacji plików, aktywność napastnika może przez długi czas pozostać niezauważona. Szczególnie niebezpieczne jest to w organizacjach, gdzie komputery Mac mają dostęp do systemów krytycznych i zasobów uprzywilejowanych.

Drugim ryzykiem jest skuteczna kradzież tożsamości i sekretów. Współczesne kampanie wymierzone w macOS często koncentrują się na pozyskiwaniu cookies, tokenów sesyjnych, danych przeglądarkowych, poświadczeń systemowych oraz kluczy dostępowych do usług chmurowych. Jedno przejęte urządzenie dewelopera lub administratora może otworzyć drogę do znacznie szerszego naruszenia całej infrastruktury przedsiębiorstwa.

Trzecim zagrożeniem jest ruch boczny i eskalacja skutków incydentu. Jeżeli stacja macOS pełni rolę uprzywilejowanego hosta roboczego, atakujący może wykorzystać zdobyte dane do przejmowania kont, modyfikowania kodu, osadzania backdoorów w pipeline’ach i przygotowania dalszego ataku na środowisko produkcyjne.

Rekomendacje

Organizacje powinny traktować macOS jako pełnoprawny element powierzchni ataku i objąć go porównywalnym poziomem nadzoru jak systemy Windows i Linux. Ochrona nie może kończyć się na podstawowym antywirusie i kontroli zgodności urządzeń.

Wdrożyć telemetrykę procesową i behawioralną, ze szczególnym naciskiem na łańcuchy uruchomień obejmujące osascript, launchctl, curl, dig, bash i zsh.
Monitorować tworzenie oraz modyfikacje LaunchAgents, LaunchDaemons i plików PLIST w lokalizacjach użytkownika oraz systemu.
Ograniczać nadużycia narzędzi administracyjnych poprzez polityki MDM, redukcję zbędnych usług zdalnego zarządzania i kontrolę automatyzacji między aplikacjami.
Wzmocnić ochronę tożsamości, wymuszając odporne na phishing MFA, rotację kluczy, segmentację uprawnień i szybkie unieważnianie sesji po wykryciu incydentu.
Budować reguły detekcyjne oparte na anomaliach, takich jak nietypowe użycie Terminala, pobieranie danych przez curl bez uzasadnienia biznesowego, usuwanie atrybutu kwarantanny czy pojawienie się nowych agentów startowych po otwarciu obrazu DMG.

Podsumowanie

Rosnąca popularność macOS w środowiskach firmowych sprawia, że platforma ta staje się coraz atrakcyjniejszym celem dla cyberprzestępców. Natywne techniki LOTL pozwalają im ukrywać działania wśród legalnych operacji systemowych, omijać klasyczne mechanizmy wykrywania i skuteczniej kraść dane uwierzytelniające oraz sekrety dostępu.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że model obrony musi ewoluować. Kluczowe stają się widoczność operacyjna, analiza zachowań, kontrola mechanizmów persystencji oraz konsekwentne zarządzanie urządzeniami Apple jako integralnym elementem firmowej powierzchni ataku.

Źródła

https://www.infosecurity-magazine.com/news/macos-lotl-techniques-enterprise/
https://news.backbox.org/2026/04/21/bad-apples-weaponizing-native-macos-primitives-for-movement-and-execution/
https://media.defense.gov/2024/Feb/07/2003389936/-1/-1/0/JOINT-GUIDANCE-IDENTIFYING-AND-MITIGATING-LOTL.PDF
https://techcommunity.microsoft.com/blog/microsoftsecurityexperts/hunting-infostealers—macos-threats/4494435
https://www.trellix.com/blogs/research/macos-malware-surges-as-corporate-usage-grows/

AVAST Antivirus 25.11: podatność Unquoted Service Path umożliwia lokalną eskalację uprawnień w Windows

Wprowadzenie do problemu / definicja

W AVAST Antivirus 25.11 opisano problem bezpieczeństwa związany z podatnością typu Unquoted Service Path w systemie Windows. Tego rodzaju błąd pojawia się wtedy, gdy ścieżka do pliku wykonywalnego usługi zawiera spacje, ale nie została poprawnie ujęta w cudzysłów. W efekcie system operacyjny może nieprawidłowo interpretować kolejne fragmenty ścieżki i próbować uruchomić inny plik niż zamierzony przez producenta.

Jeśli atakujący posiada lokalny dostęp do hosta i może zapisać odpowiednio nazwany plik wykonywalny w analizowanej lokalizacji, może doprowadzić do uruchomienia własnego kodu z uprawnieniami usługi. W praktyce oznacza to możliwość przejścia z poziomu zwykłego użytkownika do znacznie wyższego kontekstu bezpieczeństwa.

W skrócie

Zgłoszony przypadek dotyczy komponentu Avast SecureLine wchodzącego w skład AVAST Antivirus 25.11. Publiczny opis wskazuje na niecytowaną ścieżkę wykonywalną usługi działającej w środowisku Windows.

problem ma charakter lokalny i nie dotyczy zdalnego wykonania kodu,
usługa uruchamia się automatycznie,
proces działa z konta LocalSystem,
potencjalnym skutkiem jest eskalacja uprawnień do poziomu SYSTEM,
nie wskazano przypisanego identyfikatora CVE.

Kontekst / historia

Podatności wynikające z niecytowanych ścieżek usług Windows są znane od wielu lat i należą do klasycznych błędów konfiguracyjnych. Mimo dojrzałości platformy Windows oraz szerokiej wiedzy administratorów, problem nadal pojawia się w oprogramowaniu komercyjnym, narzędziach administracyjnych i dodatkowych komponentach instalowanych wraz z aplikacjami bezpieczeństwa.

W analizowanym przypadku opis dotyczy wersji 25.11 produktu AVAST Antivirus testowanej na Windows 11. Wskazano usługę Avast SecureLine, której ścieżka do binarki zawiera spacje i według publicznego opisu nie została prawidłowo objęta cudzysłowami. To szczególnie istotne, gdy usługa startuje automatycznie i działa z wysokimi uprawnieniami systemowymi.

Analiza techniczna

Mechanizm wykorzystania błędu wynika ze sposobu, w jaki Windows rozwiązuje ścieżki do plików wykonywalnych usług. Jeżeli ścieżka zawiera spacje i nie jest ujęta w cudzysłów, system może analizować ją etapami, traktując wcześniejsze segmenty jako potencjalne lokalizacje plików wykonywalnych.

Przykładowo ścieżka w rodzaju C:\Program Files\AVAST Software\SecureLine\VpnSvc.exe bez poprawnego cytowania może zostać zinterpretowana w sposób niezgodny z intencją producenta. Jeśli w jednej z rozpatrywanych lokalizacji znajdzie się złośliwy plik o odpowiedniej nazwie, system może uruchomić go zamiast właściwej binarki usługi.

W opisie podatności podkreślono, że usługa Avast SecureLine działa z konta LocalSystem. To kluczowy aspekt techniczny, ponieważ każda skuteczna podmiana lub przechwycenie ścieżki uruchomieniowej może doprowadzić do wykonania kodu z najwyższymi lokalnymi uprawnieniami w systemie Windows.

Aby atak zakończył się powodzeniem, napastnik musi zwykle spełnić kilka warunków operacyjnych:

uzyskać lokalny dostęp do systemu,
mieć możliwość zapisu do jednej z lokalizacji uwzględnianych przy rozwiązywaniu ścieżki,
umieścić odpowiednio nazwany plik wykonywalny,
doprowadzić do restartu usługi lub całego systemu.

Z tego względu nie jest to podatność służąca do bezpośredniego ataku zdalnego. Jej znaczenie rośnie jednak w scenariuszach po wstępnym naruszeniu hosta, kiedy atakujący szuka skutecznej metody podniesienia uprawnień.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem podatności jest możliwość lokalnej eskalacji uprawnień do poziomu SYSTEM. W środowisku firmowym może to oznaczać pełne przejęcie stacji roboczej, wyłączenie części mechanizmów ochronnych, instalację złośliwego oprogramowania, utrwalenie obecności napastnika oraz przygotowanie gruntu pod dalszy ruch boczny w sieci.

Realne ryzyko wykorzystania zależy od lokalnej konfiguracji systemu i uprawnień do katalogów. Jeżeli użytkownik nieuprzywilejowany nie może zapisywać plików w newralgicznych lokalizacjach, a środowisko jest odpowiednio utwardzone, wykorzystanie błędu może być utrudnione. Mimo to sama obecność usługi działającej jako LocalSystem z nieprawidłowo zdefiniowaną ścieżką uruchomieniową powinna być traktowana jako istotny problem bezpieczeństwa.

zagrożone są przede wszystkim stacje robocze po wstępnym kompromitowaniu,
ryzyko rośnie w środowiskach z nadmiernymi uprawnieniami zapisu,
podatność może zostać użyta jako element większego łańcucha ataku,
skutki obejmują utratę integralności, poufności i kontroli nad hostem.

Rekomendacje

Organizacje korzystające z rozwiązań AVAST powinny przeprowadzić przegląd konfiguracji usług Windows pod kątem niecytowanych ścieżek binarnych. Warto przy tym potraktować problem szerzej i objąć audytem również inne aplikacje firm trzecich działające jako usługi systemowe.

zidentyfikować wszystkie usługi, których ścieżki zawierają spacje i nie są ujęte w cudzysłowie,
sprawdzić uprawnienia NTFS dla katalogów znajdujących się na drodze rozwiązywania ścieżki,
ograniczyć możliwość zapisu dla użytkowników standardowych w katalogach systemowych i aplikacyjnych,
monitorować tworzenie podejrzanych plików wykonywalnych w lokalizacjach pośrednich,
wdrożyć reguły EDR i SIEM wykrywające nietypowe uruchomienia usług oraz procesów z kontekstem SYSTEM,
zweryfikować dostępność poprawek producenta lub zmian konfiguracyjnych eliminujących problem,
uwzględnić audyt usług Windows w regularnych procedurach hardeningu.

Dobrą praktyką jest także przegląd usług uruchamianych automatycznie oraz kontrola, czy nie korzystają one z nadmiernych uprawnień. Ograniczenie powierzchni ataku na poziomie konfiguracji systemu często pozwala wyeliminować błędy, które w innym przypadku mogłyby zostać użyte do przejęcia hosta.

Podsumowanie

Przypadek AVAST Antivirus 25.11 pokazuje, że nawet oprogramowanie związane z bezpieczeństwem może zawierać klasyczne błędy wdrożeniowe prowadzące do lokalnej eskalacji uprawnień. Podatność typu Unquoted Service Path nie jest nową techniką, ale nadal pozostaje skutecznym wektorem nadużyć w systemach Windows, zwłaszcza gdy dotyczy usług uruchamianych automatycznie z konta LocalSystem.

Z perspektywy obrony kluczowe znaczenie ma szybka identyfikacja błędnie skonfigurowanych usług, weryfikacja uprawnień do katalogów oraz stałe monitorowanie anomalii związanych z uruchamianiem procesów o wysokich uprawnieniach. Nawet pozornie prosty błąd konfiguracyjny może stać się ważnym elementem skutecznego łańcucha ataku.

Źródła

ThrottleStop Kernel Driver: lokalna eskalacja uprawnień w Windows przez zapis poza zakresem pamięci jądra

Wprowadzenie do problemu / definicja

Publicznie opisany exploit dotyczący sterownika jądra powiązanego z narzędziem ThrottleStop ujawnia groźną podatność umożliwiającą lokalną eskalację uprawnień w systemie Windows. Problem wynika z niebezpiecznej obsługi żądań IOCTL, która pozwala na dostęp do mapowanej pamięci fizycznej, a następnie na wykonanie zapisu w przestrzeni pamięci jądra.

W praktyce oznacza to, że atakujący posiadający już możliwość uruchomienia kodu na hoście może wykorzystać sterownik do obejścia zabezpieczeń systemowych, przejęcia kontroli nad uprzywilejowanymi procesami i uzyskania bardzo wysokich uprawnień. To klasyczny przykład zagrożenia z obszaru BYOVD, czyli wykorzystywania podatnych sterowników do działań post-exploitation.

W skrócie

Opisywana podatność ma charakter lokalnego błędu typu kernel out-of-bounds write i prowadzi do podniesienia uprawnień w Windows. Publicznie dostępny kod PoC pokazuje, że sterownik może zostać użyty do odczytu i zapisu pamięci jądra poprzez operacje na adresach fizycznych.

atak wymaga wcześniejszego lokalnego dostępu do systemu,
exploit zapewnia silne prymitywy odczytu i zapisu w pamięci jądra,
możliwa jest modyfikacja struktur procesów chronionych, w tym LSASS,
skutkiem może być kradzież poświadczeń, obejście EDR i pełna kompromitacja hosta.

Kontekst / historia

Podatne sterowniki od lat pozostają jednym z najważniejszych wektorów eskalacji uprawnień w środowiskach Windows. W wielu przypadkach atak nie polega na zdalnym wykonaniu kodu, lecz na wykorzystaniu zaufanego lub możliwego do załadowania sterownika, który udostępnia zbyt szeroki dostęp do pamięci, rejestrów lub przestrzeni I/O.

W analizowanym przypadku publiczne materiały wskazują na sterownik ThrottleStop dla Windows oraz wersję 3.0.0.0. Podatność została powiązana z identyfikatorem CVE-2025-7771 i wpisuje się w dobrze znany scenariusz, w którym napastnik po uzyskaniu przyczółka na systemie poszukuje szybkiej ścieżki do praw SYSTEM lub do wyłączenia ochrony kluczowych procesów bezpieczeństwa.

Tego rodzaju błędy są szczególnie niebezpieczne w realnych incydentach, ponieważ często stanowią pomost między początkowym dostępem a pełnym przejęciem kontroli nad stacją roboczą lub serwerem. Z perspektywy obrońców oznacza to konieczność traktowania sterowników jako elementu krytycznego dla powierzchni ataku.

Analiza techniczna

Z technicznego punktu widzenia exploit korzysta z interfejsu sterownika udostępnianego przez urządzenie \\.\ThrottleStop oraz z określonego kodu IOCTL 0x8000645C. Kod PoC definiuje strukturę wejściową zawierającą adres fizyczny i rozmiar operacji, a następnie wykorzystuje mechanizm translacji adresów do odczytu i zapisu wybranych obszarów pamięci jądra.

Kluczowy problem polega na tym, że sterownik zwraca wskaźnik do mapowanej pamięci, co umożliwia procesowi użytkownika wykonanie bezpośredniego zapisu wskazanej wartości. W efekcie powstaje bardzo niebezpieczny prymityw zapisu do pamięci jądra, wystarczający do modyfikowania krytycznych struktur systemowych odpowiedzialnych za integralność i bezpieczeństwo systemu operacyjnego.

Publiczny PoC demonstruje pełny łańcuch ataku. Najpierw sterownik jest ładowany jako usługa typu sterownika jądra, następnie otwierany jest uchwyt do urządzenia, po czym kod lokalizuje bazę jądra systemowego oraz strukturę procesu systemowego. W dalszej kolejności exploit przechodzi po liście aktywnych procesów, odnajduje strukturę EPROCESS procesu lsass.exe i modyfikuje pola odpowiedzialne za jego ochronę.

Najbardziej istotnym elementem demonstracji jest wyłączenie mechanizmów ochronnych procesu LSASS, w tym pól związanych z ochroną typu PPL oraz poziomem podpisu. To sprawia, że proces zaprojektowany do przechowywania wrażliwych danych uwierzytelniających przestaje być odpowiednio chroniony przed narzędziami post-exploitation działającymi z wysokimi uprawnieniami.

Z punktu widzenia atakującego taki wektor jest wyjątkowo wartościowy. Pozwala nie tylko na obejście zabezpieczeń lokalnych, ale również na przygotowanie środowiska do dalszego dumpingu poświadczeń, omijania narzędzi EDR czy utrwalania obecności w systemie na poziomie trudniejszym do wykrycia.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją podatności jest możliwość szybkiej eskalacji uprawnień do poziomu, który umożliwia pełną kontrolę nad systemem Windows. W środowiskach firmowych oznacza to ryzyko przejęcia poświadczeń, wyłączenia mechanizmów ochronnych i ułatwienia dalszego ruchu bocznego w sieci.

Ryzyko operacyjne rośnie z kilku powodów. Po pierwsze, publiczny PoC obniża próg wejścia dla przestępców i operatorów ransomware. Po drugie, wykorzystanie podatnych sterowników często bywa mniej oczywiste z punktu widzenia klasycznych mechanizmów detekcji niż typowe działania malware w przestrzeni użytkownika. Po trzecie, wiele organizacji nadal nie posiada dojrzałej polityki blokowania sterowników podatnych lub niepożądanych.

Choć podatność nie zapewnia początkowego dostępu, w praktyce może odegrać kluczową rolę w fazie post-compromise. To właśnie lokalna eskalacja uprawnień bardzo często decyduje o tym, czy napastnik z ograniczonego konta użytkownika przejdzie do pełnej dominacji nad hostem i krytycznymi procesami systemowymi.

Rekomendacje

Organizacje powinny rozpocząć od ustalenia, czy podatny sterownik lub powiązane z nim oprogramowanie znajdują się w środowisku. Dotyczy to nie tylko stacji roboczych użytkowników technicznych, lecz także systemów administracyjnych, laboratoriów testowych i maszyn wykorzystywanych do diagnostyki sprzętowej.

Jeżeli komponent nie jest niezbędny biznesowo, najbezpieczniejszym działaniem pozostaje jego usunięcie. Równolegle warto wdrożyć polityki ograniczające możliwość ładowania podatnych sterowników oraz egzekwować reguły integralności kodu i kontroli aplikacji.

zidentyfikować obecność sterownika ThrottleStop i podobnych komponentów niskopoziomowych,
włączyć listy blokowania znanych podatnych sterowników,
monitorować tworzenie i uruchamianie usług typu kernel driver,
analizować nietypowe wywołania DeviceIoControl kierowane do sterowników,
śledzić anomalie związane z ochroną procesu LSASS i dostępem do jego pamięci,
ograniczać lokalnym użytkownikom możliwość uruchamiania nieautoryzowanego kodu.

W środowiskach o wyższym poziomie wymagań bezpieczeństwa wskazane jest także okresowe przeglądanie listy dozwolonych sterowników, testowanie odporności na scenariusze BYOVD oraz stosowanie zasady najmniejszych uprawnień dla kont użytkowników i administratorów.

Podsumowanie

Przypadek sterownika ThrottleStop pokazuje, jak groźne mogą być błędy w sterownikach jądra udostępniających zbyt szerokie możliwości operacji na pamięci. Nawet jeśli atak wymaga wcześniejszego lokalnego dostępu, publiczny exploit dowodzi, że taki przyczółek może zostać szybko przekształcony w niemal pełną kontrolę nad systemem.

Dla zespołów bezpieczeństwa to kolejny sygnał, że skuteczna ochrona Windows nie może ograniczać się wyłącznie do warstwy user-mode. Zarządzanie sterownikami, blokowanie podatnych komponentów i monitoring aktywności w jądrze powinny stanowić integralny element strategii hardeningu i detekcji.

Źródła

Exploit Database – Throttlestop Kernel Driver – Kernel Out-of-Bounds Write Privilege Escalation
https://www.exploit-db.com/exploits/52512
NVD – CVE-2025-7771
https://nvd.nist.gov/vuln/detail/CVE-2025-7771
TechPowerUp – ThrottleStop
https://www.techpowerup.com/download/techpowerup-throttlestop/
Xavi Beltran – Using vulnerable drivers in red team exercises
https://xavibel.com/2025/12/22/using-vulnerable-drivers-in-red-team-exercises/
Microsoft Learn – Driver Security Guidance
https://learn.microsoft.com/windows/security/application-security/application-control/app-control-for-business/design/microsoft-recommended-driver-block-rules

Fałszywe rozmowy rekrutacyjne napędzają ataki na łańcuch dostaw oprogramowania

Wprowadzenie do problemu / definicja

Kampania określana jako „Contagious Interview” to zaawansowany scenariusz socjotechniczny wymierzony w programistów, inżynierów oprogramowania i specjalistów technicznych. Atakujący podszywają się pod rekruterów firm z branży AI, kryptowalut i nowych technologii, a następnie przekazują ofierze rzekome zadanie rekrutacyjne w formie repozytorium kodu.

W najnowszej odsłonie zagrożenia celem nie jest już wyłącznie pojedyncza stacja robocza. Zainfekowany projekt może stać się nośnikiem dalszej propagacji złośliwego oprogramowania w środowisku developerskim, a tym samym przekształcić incydent endpointowy w problem typu software supply chain.

W skrócie

Badacze opisali kolejną falę operacji przypisywanej aktorom powiązanym z Koreą Północną, w której fałszywe procesy rekrutacyjne służą do infekowania środowisk programistycznych. Mechanizm wykorzystuje zaufanie do repozytoriów z zadaniami technicznymi oraz funkcji uruchamianych w Visual Studio Code.

Ofiara otrzymuje pozornie wiarygodne repozytorium jako element rozmowy kwalifikacyjnej.
Po otwarciu projektu i zaakceptowaniu zaufania do workspace’u mogą zostać uruchomione złośliwe zadania.
Malware instaluje backdoory, RAT-y i moduły kradnące dane.
Ukryte pliki konfiguracyjne mogą zostać przypadkowo zatwierdzone do repozytorium i przekazane dalej innym deweloperom.

Kontekst / historia

Scenariusz fałszywych ofert pracy wykorzystywanych przez północnokoreańskie grupy nie jest nowy. Od lat obserwuje się kampanie, w których ofiara otrzymuje atrakcyjną propozycję zawodową, a następnie zostaje poproszona o wykonanie testu technicznego, uruchomienie paczki lub sklonowanie repozytorium zawierającego pozornie legalny kod.

Wcześniej głównym celem takich operacji było przejęcie komputera programisty, kradzież danych uwierzytelniających, dostępów do infrastruktury firmowej czy portfeli kryptowalutowych. Obecna ewolucja zagrożenia przesuwa akcent na ryzyko systemowe: zainfekowany projekt może trafić do repozytoriów open source, zespołowych środowisk pracy i pipeline’ów CI/CD, rozszerzając zasięg kompromitacji poza pierwotną ofiarę.

Analiza techniczna

Atak zwykle zaczyna się od kontaktu inicjowanego przez fałszywego rekrutera. Ofiara otrzymuje link do repozytorium hostowanego na znanej platformie deweloperskiej i prośbę o uruchomienie lub analizę projektu w ramach procesu rekrutacyjnego. Sam projekt wygląda wiarygodnie, a scenariusz odpowiada typowym praktykom branżowym, co znacząco obniża czujność.

Kluczowym elementem ataku jest nadużycie konfiguracji workspace’u w Visual Studio Code. Po otwarciu projektu i zaakceptowaniu zaufania dla przestrzeni roboczej mogą uruchomić się zadania wykonujące ukryty kod. W zależności od wariantu kampanii złośliwy ładunek może być pobierany z zewnętrznej infrastruktury, uruchamiany z dołączonego pliku maskowanego jako zasób projektu albo aktywowany przez osadzony fragment kodu.

Po skutecznym uruchomieniu malware operatorzy uzyskują możliwość instalacji tylnej furtki lub trojana zdalnego dostępu, wykonywania poleceń systemowych, zbierania informacji o środowisku oraz wyszukiwania sekretów. Szczególnie cenne są:

klucze do portfeli kryptowalutowych,
tokeny dostępu i sekrety aplikacyjne,
klucze podpisujące,
dane dostępowe do pipeline’ów CI/CD,
informacje umożliwiające dalszy ruch boczny lub sabotaż procesu build.

Najbardziej niepokojący aspekt dotyczy propagacji. Ukryte katalogi konfiguracyjne, takie jak .vscode, mogą zostać niezauważenie zatwierdzone do repozytorium przez skompromitowanego dewelopera. W efekcie kolejna osoba, która sklonuje projekt i otworzy go w edytorze, może zaakceptować standardowy monit o zaufanie workspace’owi, uruchamiając ten sam łańcuch infekcji. To nadaje operacji cechy zachowania przypominającego robaka, mimo że nadal wymaga interakcji użytkownika.

Dodatkowym wyzwaniem dla obrońców jest wykorzystywanie rozproszonej infrastruktury do hostowania i etapowania ładunków. Taki model utrudnia szybkie odcięcie komponentów kampanii oraz ogranicza skuteczność klasycznych działań blokujących.

Konsekwencje / ryzyko

Ryzyko należy rozpatrywać na trzech poziomach. Pierwszy to kompromitacja indywidualnej stacji roboczej dewelopera, prowadząca do kradzieży danych, przejęcia sesji i dostępu do repozytoriów oraz usług chmurowych. Drugi obejmuje środowisko organizacyjne, jeśli ofiara posiada uprawnienia do projektów produkcyjnych, systemów wdrożeniowych lub krytycznych sekretów. Trzeci poziom to klasyczne ryzyko supply chain, gdy zainfekowana konfiguracja lub kod zaczynają rozprzestrzeniać się dalej.

wyciek sekretów i danych uwierzytelniających,
przejęcie kont deweloperskich,
modyfikacja kodu źródłowego,
wstrzyknięcie złośliwych komponentów do procesu build,
kompromitacja artefaktów publikowanych do klientów,
utrata integralności repozytoriów open source i prywatnych.

Z biznesowego punktu widzenia jest to zagrożenie o wysokim potencjale oddziaływania, ponieważ łączy socjotechnikę, infekcję endpointu oraz skażenie procesu wytwarzania oprogramowania. Szczególnie narażone są firmy zatrudniające zdalnych programistów, podmioty z sektora kryptowalut, projekty open source oraz organizacje bez rygorystycznej kontroli zmian w repozytoriach.

Rekomendacje

Podstawową zasadą powinno być traktowanie każdego zewnętrznego repozytorium jako nieufnego, nawet jeśli pochodzi rzekomo z procesu rekrutacyjnego. Zadania techniczne należy uruchamiać wyłącznie w odizolowanych środowiskach testowych, najlepiej w maszynach wirtualnych lub kontenerach pozbawionych dostępu do produkcyjnych sekretów, tokenów, portfeli i prywatnych kluczy.

W praktyce warto wdrożyć następujące środki bezpieczeństwa:

blokowanie lub ścisłe monitorowanie uruchamiania zadań workspace w edytorach kodu,
egzekwowanie polityk bezpieczeństwa dla Visual Studio Code i podobnych narzędzi,
skanowanie repozytoriów pod kątem podejrzanych plików w katalogach konfiguracyjnych,
monitorowanie nieautoryzowanych commitów i anomalii w historii zmian,
wymaganie code review również dla plików ukrytych i konfiguracji developerskiej,
stosowanie ochrony endpointów z detekcją zachowań,
ograniczanie uprawnień deweloperów do niezbędnego minimum,
separację środowisk deweloperskich od krytycznych sekretów i infrastruktury produkcyjnej,
walidację integralności zależności i obowiązkowe lock file w projektach,
przechowywanie kluczy podpisujących poza stacjami roboczymi użytkowników.

W obszarze świadomości bezpieczeństwa organizacje powinny jasno komunikować, że proces rekrutacyjny nie jest kontekstem zaufanym samym w sobie. Każde zadanie od rzekomego rekrutera powinno zostać zweryfikowane niezależnym kanałem, a prośby o uruchamianie kodu, instalację pakietów czy pobieranie archiwów muszą być traktowane jako potencjalny incydent.

Dla zespołów AppSec i DevSecOps istotne jest również objęcie kontrolą artefaktów, które nie są bezpośrednio kodem aplikacji. W nowoczesnych kampaniach to właśnie konfiguracje IDE, skrypty pomocnicze i pliki buildowe stają się nośnikiem kompromitacji.

Podsumowanie

„Contagious Interview” pokazuje, jak szybko zaciera się granica między socjotechniką a atakiem na łańcuch dostaw oprogramowania. Programista staje się celem nie tylko jako użytkownik końcowy, ale również jako operator uprzywilejowanego środowiska tworzenia i publikacji kodu.

Najgroźniejszy element kampanii polega na tym, że zainfekowane repozytorium może dalej przenosić kompromitację na kolejne osoby i projekty. Dla organizacji oznacza to konieczność rozszerzenia modelu zaufania o narzędzia developerskie, proces rekrutacji technicznej oraz nietypowe artefakty pojawiające się w repozytoriach.

Źródła

Dark Reading — https://www.darkreading.com/cyberattacks-data-breaches/dprk-fake-job-scams-self-propagate-contagious-interview
Microsoft Security Blog — https://www.microsoft.com/en-us/security/blog/2026/03/11/contagious-interview-malware-delivered-through-fake-developer-job-interviews/
Huntress — How to Identify Recruiting Scams and How Huntress Fights Back — https://www.huntress.com/blog/identify-recruiting-scams-and-how-huntress-fights-back

The Gentlemen: nowa grupa ransomware błyskawicznie rośnie w siłę

Wprowadzenie do problemu / definicja

The Gentlemen to nowa operacja ransomware-as-a-service, która w bardzo krótkim czasie zyskała znaczącą pozycję w krajobrazie cyberzagrożeń. Mimo nazwy sugerującej łagodność grupa prowadzi klasyczne kampanie podwójnego wymuszenia, łącząc szyfrowanie systemów z kradzieżą danych oraz groźbą ich publikacji. Szczególny niepokój budzi tempo rozwoju zaplecza technicznego i wysoki poziom dojrzałości operacyjnej widoczny już na wczesnym etapie działalności.

W skrócie

The Gentlemen pojawiło się w połowie 2025 roku i szybko awansowało do grona najbardziej aktywnych grup RaaS.
Atakujący wykorzystują m.in. SystemBC, tunele SOCKS5, Cobalt Strike i mechanizmy wyłączania zabezpieczeń Windows.
W kampaniach obserwowano masowe wdrażanie ransomware za pomocą Active Directory Group Policy.
Grupa rozwija także warianty przeznaczone dla środowisk VMware ESXi.
Najbardziej narażone są organizacje korporacyjne z rozbudowaną domeną Windows i scentralizowaną administracją.

Kontekst / historia

Model ransomware-as-a-service od lat obniża próg wejścia dla cyberprzestępców. Twórcy dostarczają oprogramowanie, infrastrukturę oraz kanały negocjacyjne, natomiast afilianci odpowiadają za uzyskanie dostępu do ofiary, ruch boczny i uruchomienie ładunku szyfrującego. Skuteczność takich operacji zależy od jakości narzędzi, atrakcyjności programu partnerskiego oraz zdolności do utrzymania ciągłości działania mimo presji ze strony organów ścigania i branży bezpieczeństwa.

Na tym tle The Gentlemen wyróżnia się wyjątkowo szybkim tempem wzrostu. W krótkim czasie grupa osiągnęła poziom aktywności porównywalny z bardziej ugruntowanymi markami ransomware. Jej rosnąca obecność w raportach branżowych sugeruje, że ma skuteczny model afiliacyjny oraz ofertę atrakcyjną dla operatorów szukających dojrzałego zaplecza technicznego.

Analiza techniczna

W analizowanych incydentach po uzyskaniu dostępu do środowiska atakujący uruchamiali malware SystemBC. To komponent pośredniczący, wykorzystywany do zestawiania tuneli SOCKS5, ukrywania komunikacji z infrastrukturą dowodzenia i kontroli oraz pobierania kolejnych narzędzi. W praktyce stanowi on wygodną warstwę transportową dla dalszych etapów ręcznie prowadzonych operacji.

Następnie operatorzy rozszerzali obecność w sieci, koncentrując się na zasobach o wysokiej wartości, zwłaszcza na kontrolerach domeny. Uzyskanie uprzywilejowanego dostępu do takiego systemu znacząco przyspiesza eskalację ataku, umożliwiając rekonesans, modyfikację polityk bezpieczeństwa, dystrybucję narzędzi oraz przygotowanie masowego wdrożenia ransomware.

Jednym z najbardziej niebezpiecznych elementów działania The Gentlemen jest wykorzystanie natywnej infrastruktury Active Directory. Operatorzy mogą używać Group Policy do jednoczesnego uruchamiania ładunku na wielu hostach domenowych. Dla obrońców oznacza to, że przejęcie jednego kluczowego systemu administracyjnego może bardzo szybko doprowadzić do szyfrowania dużej części środowiska Windows.

Sam ransomware rozwijany jest w języku Go, co wpisuje się w trend tworzenia przenośnych i łatwych do adaptacji binariów. Zaobserwowano funkcje pozwalające wyłączać Microsoft Defender, zaporę systemową oraz wybrane mechanizmy monitorowania i skanowania. Grupa korzysta również z narzędzi zdalnego dostępu oraz komponentów wspierających utrzymanie trwałości w środowisku ofiary.

Istotnym elementem operacji jest także wariant przeznaczony dla VMware ESXi. Wskazuje to na dążenie do skutecznego paraliżowania infrastruktury wirtualnej i zwiększania presji na ofiary. Dodatkowo operatorzy podejmują działania przygotowawcze, takie jak kontrolowane wyłączanie maszyn wirtualnych czy ograniczanie mechanizmów automatycznego odzyskiwania, co zwiększa skuteczność szyfrowania i utrudnia szybkie odtworzenie usług.

Na uwagę zasługuje również dojrzałość modelu afiliacyjnego. Pakiet oferowany przez grupę obejmuje eksfiltrację danych, szyfrowanie, ruch boczny, techniki unikania detekcji i obsługę wielu platform. Dzięki temu nawet mniej doświadczeni afilianci mogą realizować ataki o skali typowej dla bardziej zaawansowanych operatorów.

Konsekwencje / ryzyko

Największe ryzyko dla organizacji wynika z bardzo krótkiego czasu przejścia od początkowej kompromitacji do pełnoskalowego incydentu. Jeśli napastnicy przejmą system brzegowy, a następnie uzyskają dostęp do kontrolera domeny, rozpropagowanie ładunku może nastąpić błyskawicznie. Skutkiem może być jednoczesna niedostępność usług, utrata danych, przerwanie procesów biznesowych, szkody reputacyjne oraz presja negocjacyjna wynikająca z podwójnego wymuszenia.

Szczególnie zagrożone są organizacje z rozbudowanymi domenami Windows, wysokim stopniem centralizacji administracji, niewystarczającą segmentacją sieci i krytycznymi usługami utrzymywanymi na hostach ESXi. Dodatkowym problemem jest wykorzystywanie legalnych narzędzi administracyjnych i popularnych frameworków ofensywnych, co może utrudniać wykrycie anomalii na wczesnym etapie ataku.

Rekomendacje

W pierwszej kolejności organizacje powinny ograniczyć ryzyko kompromitacji systemów wystawionych do Internetu. Niezbędne są regularne przeglądy zasobów publicznych, szybkie usuwanie podatności, wyłączanie nieużywanych usług zdalnych oraz wdrażanie wieloskładnikowego uwierzytelniania tam, gdzie jest to możliwe.

Kluczowe znaczenie ma ochrona warstwy tożsamości i infrastruktury domenowej. Kontrolery domeny powinny być objęte wzmocnionym monitoringiem, segmentacją i ścisłą kontrolą dostępu uprzywilejowanego. Każda nietypowa modyfikacja Group Policy, nagłe wdrożenia skryptów PowerShell czy nieoczekiwana dystrybucja binariów powinny uruchamiać alerty bezpieczeństwa.

Warto również wdrożyć detekcję zachowań charakterystycznych dla etapów poprzedzających szyfrowanie. Dotyczy to w szczególności tuneli SOCKS5, komunikacji z serwerami C2, wyłączania Defendera i zapory, nietypowego użycia narzędzi zdalnego dostępu, aktywności Cobalt Strike oraz gwałtownego wzrostu operacji administracyjnych na wielu hostach. Istotna jest także telemetria z hostów ESXi i monitorowanie zdarzeń związanych z masowym wyłączaniem maszyn wirtualnych.

Z perspektywy odporności operacyjnej niezbędne są odseparowane kopie zapasowe, regularne testy odtwarzania, procedury izolacji segmentów sieci oraz gotowy plan reagowania na incydenty ransomware. Program szkoleniowy dla pracowników i administratorów powinien obejmować rozpoznawanie oznak kompromitacji, zasady pracy z uprzywilejowanymi kontami oraz właściwą reakcję na incydenty z użyciem narzędzi zdalnego dostępu.

Podsumowanie

The Gentlemen to przykład nowej generacji operacji RaaS, która bardzo szybko osiągnęła skalę zwykle zarezerwowaną dla bardziej dojrzałych grup ransomware. Połączenie SystemBC, tunelowania sieciowego, aktywnego ruchu bocznego, wyłączania zabezpieczeń, wykorzystania Group Policy oraz wariantów dla środowisk ESXi sprawia, że zagrożenie ma charakter wysoce operacyjny i stanowi realne ryzyko dla dużych organizacji. Dla zespołów bezpieczeństwa najważniejsze pozostają dziś trzy priorytety: ochrona systemów brzegowych, twarde zabezpieczenie Active Directory oraz szybkie wykrywanie działań przygotowawczych poprzedzających detonację ransomware.

Źródła

Dark Reading — „The Gentlemen’ Rapidly Rises to Ransomware Prominence” — https://www.darkreading.com/threat-intelligence/gentlemen-rapidly-rise-ransomware
Comparitech — „Ransomware roundup: Q1 2026” — https://www.comparitech.com/news/ransomware-roundup-q1-2026/
NCC Group — „Monthly Threat Pulse – Review of February 2026” — https://www.nccgroup.com/newsroom/ncc-group-monthly-threat-pulse-review-of-february-2026/
GuidePoint Security — „Q1 2026 Ransomware and Cyber Threat Insights” — https://www.guidepointsecurity.com/wp-content/uploads/2026/04/Q1-2026_Ransomware_and-Cyber_Threat_Insights.pdf
Silent Push — „No Place to Hide: Following a Serial Ransomware Affiliate from LockBit, Black Basta, and Qilin to The Gentlemen” — https://www.silentpush.com/blog/gentlemen-ransomware/

Eksploity przeciw Microsoft Defender pozwalają eskalować uprawnienia i osłabiać ochronę systemów Windows

Wprowadzenie do problemu / definicja

Microsoft Defender jest domyślnym mechanizmem ochronnym w wielu środowiskach Windows, dlatego wszelkie błędy w jego uprzywilejowanych komponentach mają szczególnie wysoką wartość dla atakujących. Najnowsze analizy pokazują, że określone techniki eksploatacji mogą odwrócić rolę tego rozwiązania i wykorzystać jego zaufane procesy do przejęcia wyższych uprawnień lub osłabienia skuteczności ochrony.

Problem dotyczy trzech publicznie opisanych metod: BlueHammer, RedSun oraz UnDefend. Dwie pierwsze są kojarzone z eskalacją uprawnień do poziomu SYSTEM, natomiast trzecia pozwala na stopniowe pogarszanie zdolności Defendera do skutecznego aktualizowania i egzekwowania ochrony.

W skrócie

BlueHammer wykorzystuje warunek wyścigu w mechanizmie aktualizacji sygnatur i został powiązany z CVE-2026-33825.
RedSun ma umożliwiać eskalację uprawnień poprzez nadużycie procesu klasyfikacji i remediacji plików.
UnDefend nie służy bezpośrednio do podniesienia uprawnień, ale może cicho osłabiać skuteczność ochrony endpointu.
Zaobserwowane użycie tych technik dotyczy głównie działań po uzyskaniu wstępnego dostępu do systemu.
Dla organizacji kluczowe znaczenie mają szybkie aktualizacje, kontrola wykonywania plików i niezależne mechanizmy monitoringu.

Kontekst / historia

Publiczne informacje wskazują, że zestaw exploitów został udostępniony po nieudanej próbie odpowiedzialnego ujawnienia. W krótkim czasie po publikacji techniki zaczęły być analizowane nie tylko w środowiskach testowych, ale również w realnych incydentach bezpieczeństwa.

Charakter tych incydentów sugeruje raczej działania ukierunkowane niż masowe kampanie automatyczne. Operatorzy po uzyskaniu dostępu do zwykłego konta użytkownika prowadzili rozpoznanie lokalne, sprawdzali kontekst uprawnień i uruchamiali potrzebne narzędzia z katalogów użytkownika, aby ograniczyć widoczność operacyjną. Taki model działania wskazuje na wykorzystanie exploitów głównie na etapie post-compromise.

Analiza techniczna

BlueHammer jest opisywany jako podatność typu TOCTOU, czyli time-of-check to time-of-use. W praktyce oznacza to sytuację, w której system najpierw sprawdza obiekt lub ścieżkę, a następnie wykonuje operację w późniejszym momencie, pozostawiając krótkie okno czasowe na manipulację. Jeśli atakujący wygra taki wyścig, może przekierować zapis lub modyfikację do kontrolowanej lokalizacji i doprowadzić do wykonania operacji z uprawnieniami SYSTEM.

RedSun ma działać według podobnego schematu, ale koncentruje się na procesie odpowiedzialnym za klasyfikację i priorytetyzację wykrytych plików oraz zagrożeń. Według opublikowanych analiz aktywacja ścieżki podatnej może nastąpić nawet z użyciem testowego ciągu EICAR, powszechnie wykorzystywanego do sprawdzania działania silników antywirusowych. Następnie exploit ponownie wykorzystuje warunek wyścigu, aby podstawić obiekt kontrolowany przez napastnika i doprowadzić do wykonania własnego kodu z wysokimi uprawnieniami.

UnDefend różni się celem operacyjnym. Nie koncentruje się na natychmiastowej eskalacji uprawnień, lecz na obniżeniu skuteczności warstwy ochronnej po wcześniejszym przejęciu systemu. Technika ingeruje w proces aktualizacji sygnatur i mechanizmy raportowania, przez co endpoint może wyglądać na poprawnie chroniony, mimo że bieżąca inteligencja o zagrożeniach nie jest skutecznie dostarczana.

Wspólnym elementem wszystkich trzech scenariuszy jest nadużycie zaufania do uprzywilejowanych operacji wejścia/wyjścia wykonywanych przez komponent bezpieczeństwa. Gdy zaufany proces operuje z wysokimi uprawnieniami bez pełnej walidacji ścieżek, blokad i kontekstu wykonania, sam staje się atrakcyjnym wektorem ataku.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem jest możliwość uzyskania uprawnień SYSTEM bez konieczności sięgania po exploit jądra czy klasyczne błędy korupcji pamięci. To znacząco upraszcza działania napastnika po kompromitacji, umożliwiając trwałe osadzenie się w systemie, dostęp do wrażliwych zasobów, obchodzenie zabezpieczeń i przygotowanie gruntu pod dalszy ruch boczny.

Ryzyko szczególnie rośnie tam, gdzie atakujący może najpierw zdobyć lokalny dostęp do zwykłego konta użytkownika, na przykład przez przejęte dane logowania, słabo chroniony zdalny dostęp lub brak uwierzytelniania wieloskładnikowego. W takim scenariuszu publicznie dostępne proof-of-concepty obniżają próg wejścia także dla mniej zaawansowanych operatorów.

Dodatkowym zagrożeniem jest cicha degradacja detekcji. Jeśli organizacja polega wyłącznie na natywnych wskaźnikach stanu, może przez pewien czas funkcjonować w błędnym przekonaniu, że ochrona działa prawidłowo. To zwiększa szansę powodzenia kolejnych etapów ataku, w tym kradzieży danych, wdrożenia ransomware lub długotrwałej obecności intruza w środowisku.

Rekomendacje

Priorytetem powinno być niezwłoczne wdrożenie dostępnych aktualizacji bezpieczeństwa oraz potwierdzenie rzeczywistej wersji platformy antymalware na stacjach roboczych i serwerach. Nie należy opierać oceny wyłącznie na widoku kondycji prezentowanym przez konsolę zarządzającą.

Organizacje powinny założyć, że problem ma szerszy charakter niż pojedyncza poprawka. RedSun i UnDefend wskazują na klasę słabości związaną z walidacją ścieżek, warunkami wyścigu oraz nadmiernym zaufaniem do operacji wykonywanych przez uprzywilejowane procesy ochronne.

Wymusić MFA dla wszystkich kanałów zdalnego dostępu, zwłaszcza VPN i interfejsów administracyjnych.
Zablokować wykonywanie plików z katalogów zapisywalnych przez użytkownika, takich jak Downloads, Pictures i Temp.
Monitorować nietypowe procesy potomne oraz uruchamianie binariów z profili użytkowników.
Objąć krytyczne pliki i usługi ochronne monitoringiem integralności.
Wdrożyć niezależną warstwę detekcji, która nie współdzieli tej samej granicy zaufania co lokalny agent ochronny.
Analizować oznaki ręcznej aktywności po kompromitacji, w tym enumerację uprawnień i próby manipulacji komponentami Defendera.

Podsumowanie

BlueHammer, RedSun i UnDefend pokazują, że nawet natywne mechanizmy bezpieczeństwa mogą stać się narzędziem ataku, jeśli intruz potrafi przejąć kontrolę nad uprzywilejowanymi workflowami plikowymi i aktualizacyjnymi. Nie chodzi więc wyłącznie o pojedynczy błąd, ale o szerszy problem architektoniczny związany z bezpieczeństwem zaufanych procesów działających z wysokimi uprawnieniami.

Dla zespołów bezpieczeństwa najważniejsze pozostają trzy filary: szybkie aktualizowanie środowiska, ograniczanie możliwości uzyskania wstępnego dostępu oraz stosowanie niezależnych mechanizmów detekcji i kontroli integralności. W realiach, w których publiczny exploit może szybko przejść z laboratorium do prawdziwych włamań, tempo reakcji i wielowarstwowa obrona pozostają kluczowe.

Źródła

Dark Reading — Exploits Turn Windows Defender Into Attacker Tool — https://www.darkreading.com/cyberattacks-data-breaches/exploits-turn-windows-defender-attacker-tool
Huntress — Nightmare-Eclipse Tooling Seen in Real-World Intrusion — https://www.huntress.com/blog/nightmare-eclipse-intrusion
National Vulnerability Database — CVE-2026-33825 — https://nvd.nist.gov/vuln/detail/CVE-2026-33825