Archiwa: PowerShell - Strona 3 z 63

Fałszywe instalatory wyłączają Windows Update i osłabiają Microsoft Defender

Wprowadzenie do problemu / definicja

Nowa kampania malware pokazuje, że fałszywe instalatory popularnego oprogramowania nadal pozostają skutecznym narzędziem infekcji. Atakujący tworzą podrobione strony pobierania, które do złudzenia przypominają legalne witryny producentów, a następnie nakłaniają ofiary do uruchomienia spreparowanego pliku instalacyjnego.

Najgroźniejszym elementem tej operacji nie jest jednak samo dostarczenie złośliwego ładunku, lecz działania wykonywane już po uruchomieniu próbki. Malware aktywnie osłabia mechanizmy ochronne systemu Windows, wyłącza elementy odpowiedzialne za aktualizacje i przygotowuje środowisko do dalszej kompromitacji.

W skrócie

Atak wykorzystuje fałszywe strony pobierania i archiwa ZIP z rzekomymi instalatorami.
Po uruchomieniu malware uzyskuje persystencję przez zaplanowane zadania.
Złośliwy kod dodaje wykluczenia w Microsoft Defender i usuwa kopie woluminów.
Infekcja sabotuje Windows Update poprzez zatrzymywanie usług i ingerencję w komponenty aktualizacji.
Kampania jest wiązana z klastrem zagrożeń Silver Fox, znanym z dystrybucji zdalnych trojanów i narzędzi szpiegowskich.

Kontekst / historia

Podszywanie się pod legalnych dostawców oprogramowania nie jest nową techniką, ale obecna kampania wyróżnia się wysoką jakością przygotowania infrastruktury. Strony pobierania są projektowane tak, aby maksymalnie przypominały oficjalne serwisy, co zwiększa skuteczność socjotechniki i obniża czujność użytkowników.

Według dostępnych ustaleń działania są ukierunkowane przede wszystkim na użytkowników chińskojęzycznych oraz chińskie oddziały międzynarodowych organizacji. Jednocześnie schemat operacji wpisuje się w szerszy trend nadużywania legalnych narzędzi systemowych, podpisanych komponentów i technik ukrywania aktywności malware w procesach wyglądających na wiarygodne.

Badacze bezpieczeństwa od dłuższego czasu obserwują aktywność powiązaną z rodzinami malware takimi jak Gh0st RAT czy ValleyRAT. Obecna kampania wzmacnia obraz dojrzałego ekosystemu zagrożeń, w którym fałszywe instalatory są jedynie pierwszym etapem prowadzącym do szerszej kompromitacji środowiska.

Analiza techniczna

Łańcuch ataku rozpoczyna się od wizyty na podrobionej stronie pobierania. Ofiara otrzymuje archiwum ZIP zawierające plik udający legalny instalator. Charakterystycznym elementem kampanii jest zmienność hashy pobieranych próbek, co sugeruje dynamiczne generowanie lub modyfikowanie ładunku po stronie serwera.

Po uruchomieniu pliku wykonywalnego malware działa jako wrapper instalacyjny, który zamiast instalować oczekiwane oprogramowanie wdraża złośliwe komponenty. W części przypadków do uruchomienia próbki wykorzystywany jest również zaufany proces msiexec.exe, co zwiększa wiarygodność operacji i może utrudniać detekcję opartą wyłącznie na reputacji plików.

Następnie malware tworzy mechanizmy persystencji z użyciem zaplanowanych zadań, często nazwanych w sposób przypominający rutynowe zadania administracyjne. Kolejnym krokiem jest wykonanie serii działań mających osłabić ochronę hosta, w tym:

dodanie wykluczeń w Microsoft Defender,
usunięcie shadow copies,
modyfikacja uprawnień do katalogów z payloadem,
utrudnienie usunięcia plików przez standardowe konta użytkowników.

Szczególnie niebezpieczny jest sabotaż usług aktualizacji Windows. Złośliwe oprogramowanie zatrzymuje i wyłącza usługi odpowiedzialne za dostarczanie i naprawę aktualizacji, takie jak wuauserv, UsoSvc, uhssvc oraz WaaSMedicSvc. Dodatkowo może czyścić katalog SoftwareDistribution i ingerować w biblioteki DLL związane z mechanizmem aktualizacji, co wydłuża czas pozostawania systemu bez poprawek bezpieczeństwa.

Po przygotowaniu środowiska malware zestawia komunikację command-and-control na niestandardowych portach. Taka łączność umożliwia operatorom wydawanie poleceń, pobieranie kolejnych modułów oraz rozwijanie kompromitacji. W szerszym ujęciu powiązane rodziny malware są znane z funkcji takich jak zbieranie informacji systemowych, przechwytywanie schowka, wykonywanie zrzutów ekranu, rejestrowanie klawiszy czy pobieranie dodatkowych komponentów.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem tej kampanii jest trwałe obniżenie poziomu bezpieczeństwa endpointu. Gdy Windows Update zostaje wyłączony lub uszkodzony, host przestaje otrzymywać poprawki, przez co organizacja traci jedną z podstawowych warstw ochrony przed znanymi podatnościami.

Równoległe osłabienie Microsoft Defender zmniejsza szanse na lokalne wykrycie kolejnych etapów ataku. Usunięcie kopii woluminów utrudnia odtwarzanie danych, a zmiana uprawnień do katalogów komplikuje remediację i może wydłużyć czas obsługi incydentu.

Z perspektywy biznesowej zagrożenie jest istotne również dlatego, że punkt wejścia wygląda na rutynową i niskoryzykowną czynność. Użytkownik pobierający popularny program często nie traktuje takiego działania jako potencjalnego początku poważnego incydentu, co zwiększa skuteczność kampanii.

W środowisku firmowym zainfekowana stacja może zostać wykorzystana do dalszego ruchu bocznego, kradzieży danych, wdrożenia dodatkowego backdoora lub prowadzenia długotrwałego szpiegostwa. Im dłużej sabotaż usług bezpieczeństwa pozostaje niezauważony, tym większe ryzyko eskalacji incydentu.

Rekomendacje

Organizacje powinny ograniczyć możliwość instalowania aplikacji wyłącznie do zatwierdzonych źródeł i centralnie zarządzanych kanałów dystrybucji. Bezpośrednie pobieranie oprogramowania z internetu przez użytkowników końcowych powinno być objęte kontrolą polityk bezpieczeństwa, filtrowaniem DNS oraz rozwiązaniami web filtering.

W praktyce warto wdrożyć monitoring i alertowanie na następujące zdarzenia:

próby zatrzymywania lub wyłączania usług Windows Update,
polecenia PowerShell modyfikujące wykluczenia Microsoft Defender,
tworzenie nietypowych zaplanowanych zadań,
użycie narzędzi administracyjnych do zmiany uprawnień w katalogach aplikacyjnych i tymczasowych,
uruchamianie instalatorów z katalogów pobrań oraz archiwów ZIP,
podejrzane procesy potomne uruchamiane przez msiexec.exe.

Dodatkową warstwę ochrony zapewni wdrożenie mechanizmów application control i allowlistingu. Istotne jest również stosowanie analiz behawioralnych, które potrafią wykryć ciąg powiązanych działań, nawet jeśli pojedynczy plik nie został wcześniej sklasyfikowany jako złośliwy.

W przypadku podejrzenia kompromitacji należy niezwłocznie odizolować host, zabezpieczyć artefakty do analizy, sprawdzić integralność usług aktualizacji, przywrócić konfigurację Defendera oraz przeanalizować harmonogram zadań. Po remediacji warto przeprowadzić hunting na pozostałych stacjach roboczych i serwerach w poszukiwaniu podobnych wzorców aktywności.

Podsumowanie

Opisana kampania potwierdza, że fałszywe instalatory pozostają bardzo skutecznym wektorem ataku, zwłaszcza gdy są wspierane przez wiarygodnie przygotowane klony stron producentów. Kluczowym zagrożeniem nie jest wyłącznie sam malware, ale jego zdolność do systematycznego osłabiania ochrony systemu i utrudniania dostarczania poprawek.

Dla zespołów bezpieczeństwa oznacza to konieczność patrzenia szerzej niż tylko na pojedynczy złośliwy plik. Równie ważne staje się monitorowanie zmian konfiguracyjnych, kontrola źródeł oprogramowania oraz szybkie wykrywanie sabotażu usług bezpieczeństwa i aktualizacji.

Źródła

Cyberprzestępcy nadużywają Faronics Deploy do instalacji ScreenConnect i przejęcia zdalnego dostępu

Wprowadzenie do problemu / definicja

Cyberprzestępcy coraz częściej rezygnują z klasycznych loaderów i trojanów na rzecz nadużywania legalnych narzędzi administracyjnych. W najnowszym obserwowanym schemacie wykorzystywana jest platforma Faronics Deploy, która po uruchomieniu przez ofiarę może zostać użyta do zapisania stacji roboczej do wdrożenia kontrolowanego przez napastnika, a następnie do zdalnej instalacji oprogramowania ScreenConnect.

To podejście wpisuje się w model „living off trusted software”, w którym atak bazuje na zaufanym, podpisanym i powszechnie używanym oprogramowaniu. Dzięki temu początkowa faza kompromitacji wygląda wiarygodnie i może nie wzbudzić podejrzeń ani użytkownika, ani części mechanizmów ochronnych.

W skrócie

Atak rozpoczyna się od phishingu podszywającego się pod dokumenty biznesowe, takie jak faktury lub pliki podatkowe.
Ofiara trafia na stronę zachęcającą do pobrania legalnego instalatora Faronics Deploy, często przebranego za aktualizację Adobe lub czytnik dokumentów.
Po uruchomieniu instalatora urządzenie zostaje przypisane do wdrożenia kontrolowanego przez napastnika.
Atakujący wykorzystuje funkcje zdalnego wdrażania i uruchamiania skryptów do pobrania kolejnych komponentów.
Finalnym etapem jest instalacja ConnectWise ScreenConnect, zapewniającego trwały i interaktywny kanał zdalnego dostępu.

Kontekst / historia

Faronics Deploy to rozwiązanie do zarządzania punktami końcowymi, używane do rejestracji urządzeń, dystrybucji oprogramowania oraz zdalnego wykonywania skryptów. Właśnie te funkcje, zaprojektowane do legalnej administracji, zostały wykorzystane jako element łańcucha ataku.

Opisana aktywność była obserwowana od 21 lipca do 20 sierpnia 2026 roku i miała objąć ponad 457 punktów końcowych. Kampania opierała się na socjotechnice oraz podszywaniu się pod znane aplikacje użytkowe, co zwiększało szansę, że użytkownik sam uruchomi podpisany instalator.

Według ustaleń po zgłoszeniu incydentu producent wdrożył dodatkowe mechanizmy ograniczające nadużycia oraz kontaktował się z organizacjami potencjalnie dotkniętymi incydentem. Spadek aktywności po 21 sierpnia sugeruje, że działania obronne przyniosły efekt, jednak sam model operacyjny pozostaje istotnym sygnałem ostrzegawczym dla zespołów bezpieczeństwa.

Analiza techniczna

Łańcuch ataku składa się z kilku etapów. Najpierw ofiara otrzymuje wiadomość phishingową z przynętą odnoszącą się do dokumentów biznesowych. Link z wiadomości prowadzi do strony kontrolowanej przez napastnika, która może nie tylko oferować fałszywy plik do pobrania, ale również profilować środowisko odwiedzającego i unikać ujawnienia pełnego zachowania w warunkach analizy.

Kolejny krok to pobranie legalnego, podpisanego instalatora Faronics Deploy. W analizowanych przypadkach pliki były nazywane w sposób sugerujący oprogramowanie Adobe lub narzędzia do otwierania dokumentów. Po ich uruchomieniu host zostaje przypisany do wdrożenia kontrolowanego przez operatora ataku.

Kluczowym elementem po stronie napastnika jest możliwość zdalnego wykonywania skryptów PowerShell z użyciem funkcji dostępnych w Faronics Deploy. Dzięki temu dalsza kompromitacja może przebiegać bez dodatkowej interakcji użytkownika. Skrypty pobierają następne komponenty z infrastruktury atakującego lub zewnętrznych lokalizacji, wykorzystując przy tym takie narzędzia jak curl, mshta czy msiexec.

Ostatecznym celem obserwowanych działań była instalacja ConnectWise ScreenConnect. Daje to napastnikowi drugi, niezależny kanał dostępu zdalnego do systemu. Nawet jeśli nieautoryzowane wdrożenie w Faronics Deploy zostanie wykryte i usunięte, ScreenConnect może utrzymać możliwość dalszej interakcji z hostem, co zwiększa odporność operacji na działania zespołów SOC i IR.

Z perspektywy dochodzeniowej szczególnie ważne są artefakty lokalne związane z Faronics Deploy. Istotnym śladem może być plik ScriptRunner.log w katalogu C:\ProgramData\Faronics\Logs\, który może zawierać nazwy wykonywanych skryptów i adresy pobierania. Dodatkowym wskaźnikiem kompromitacji może być parametr ck obecny w żądaniach konfiguracyjnych, pozwalający powiązać urządzenie z konkretnym wdrożeniem lub kontem klienta.

Konsekwencje / ryzyko

Najpoważniejsze ryzyko wynika z faktu, że atak wykorzystuje zaufane oprogramowanie administracyjne zamiast typowego malware. W praktyce zwiększa to szansę obejścia zabezpieczeń opartych na reputacji pliku, podpisie cyfrowym czy prostych regułach allowlistingu.

Kompromitacja pojedynczego hosta może szybko przekształcić się w trwały zdalny dostęp, umożliwiający dalsze działania operatorskie, rozpoznanie środowiska, transfer plików, a nawet przygotowanie gruntu pod kradzież danych lub wdrożenie ransomware. ScreenConnect jest w takim scenariuszu narzędziem szczególnie użytecznym, ponieważ pozwala na wygodne i stabilne zarządzanie przejętym systemem.

Dodatkowym problemem jest trudność odróżnienia działań legalnych od złośliwych. W organizacjach, które już korzystają z platform RMM lub narzędzi do zarządzania endpointami, wykrycie nieautoryzowanego wdrożenia wymaga zwykle korelacji wielu źródeł telemetrycznych, takich jak logi EDR, zapisy PowerShell, historia instalacji oraz ruch sieciowy.

Rekomendacje

Organizacje powinny przyjąć, że legalne narzędzia administracyjne mogą zostać użyte jako wektor ataku i odpowiednio dostosować monitoring oraz procesy reagowania.

Zweryfikować, czy Faronics Deploy jest używany w środowisku, oraz zinwentaryzować autoryzowane konta, tenanty, polityki wdrożeniowe i listy zarządzanych urządzeń.
Traktować każde nieznane przypisanie hosta do wdrożenia jako potencjalny incydent bezpieczeństwa.
Monitorować nietypowe instalacje Faronics Deploy na stacjach, które wcześniej nie korzystały z tego rozwiązania.
Śledzić wykonania PowerShell inicjowane przez agenta zarządzającego oraz łańcuchy potomne obejmujące curl, mshta i msiexec.
Wykrywać nowe lub nieautoryzowane instalacje ScreenConnect oraz komunikację do nieznanych zasobów pobierających skrypty lub pakiety instalacyjne.
Analizować logi w katalogach Faronics, historię wykonania skryptów, nowe usługi, zadania harmonogramu, klucze autostartu i aktywne sesje zdalnego wsparcia.
Wzmocnić odporność użytkowników na phishing związany z fałszywymi aktualizacjami i rzekomymi czytnikami dokumentów.
Rozważyć polityki ograniczające uruchamianie narzędzi skryptowych i instalacyjnych w nietypowych kontekstach oraz wdrożyć reguły behawioralne EDR analizujące relacje rodzic–dziecko między procesami.

Podsumowanie

Nadużycie Faronics Deploy do instalacji ScreenConnect pokazuje, jak skuteczne stają się ataki oparte na legalnych narzędziach administracyjnych. Nie jest to jedynie kampania phishingowa, lecz wieloetapowy mechanizm przejęcia zdalnej kontroli nad hostem z użyciem podpisanego oprogramowania, zdalnych skryptów i redundantnego kanału dostępu.

Dla obrońców kluczowe znaczenie ma szybkie wykrywanie nieautoryzowanych wdrożeń, analiza logów lokalnych oraz korelacja zdarzeń związanych z narzędziami zdalnego zarządzania. Granica między administracją a nadużyciem staje się dziś jednym z najważniejszych obszarów walki w cyberbezpieczeństwie.

Źródła

https://www.bleepingcomputer.com/news/security/hackers-abuse-faronics-deploy-admin-tool-to-install-screenconnect/

Breeze Comet uderza w brazylijskie systemy płatnicze i realizuje setki nieautoryzowanych transakcji

Wprowadzenie do problemu / definicja

Breeze Comet to grupa cyberprzestępcza nastawiona na zysk, która koncentruje się na przejmowaniu dostępu do środowisk finansowych oraz manipulowaniu procesami płatniczymi w Brazylii. W odróżnieniu od klasycznych kampanii wymierzonych w pojedynczych użytkowników, operatorzy tej aktywności atakują organizacje mające bezpośredni dostęp do infrastruktury bankowej, interfejsów API oraz krajowych systemów rozliczeniowych.

Taki model działania oznacza istotną zmianę w krajobrazie zagrożeń. Celem atakujących nie jest już wyłącznie kradzież danych logowania lub przejęcie jednego rachunku, lecz infiltracja środowisk odpowiedzialnych za inicjowanie i autoryzowanie transferów środków.

W skrócie

Breeze Comet od co najmniej 2024 roku prowadzi kampanie przeciwko podmiotom z sektorów finansowego, handlowego i e-commerce w Brazylii. Na celowniku znajdują się organizacje mogące realizować operacje przez krajowe mechanizmy płatnicze, takie jak Pix, STR i Boleto.

Grupa uzyskuje dostęp początkowy m.in. przez password spraying, socjotechnikę oraz kompromitację podatnych serwerów JBoss.
Po wejściu do środowiska wykorzystuje legalne narzędzia zdalnego dostępu, tunele sieciowe, własne backdoory i przejęte konta uprzywilejowane.
Końcowym celem jest wykonywanie masowych, nieautoryzowanych transakcji i zacieranie śladów aktywności.

Kontekst / historia

Aktywność przypisywana Breeze Comet była wcześniej łączona z innymi klastrami zagrożeń obserwowanymi przez firmy bezpieczeństwa. Grupa działa co najmniej od 2023 roku i stopniowo rozszerza swój arsenał, przechodząc od prostszych, komercyjnych narzędzi do bardziej złożonych implantów oraz własnej infrastruktury pośredniczącej.

Na wcześniejszych etapach kampanii operatorzy opierali się głównie na legalnych rozwiązaniach RMM, które zapewniały trwały i pozornie wiarygodny dostęp do stacji roboczych i serwerów. Z czasem schemat działania rozbudowano o kompromitację zaufanych witryn, wykorzystanie podatnych systemów pośrednich, nadużycia w środowiskach chmurowych oraz wdrażanie niestandardowego malware.

Co istotne, grupa nie ogranicza się do bezpośrednich ataków na banki. Celem są także procesory płatności, fintechy, dostawcy oprogramowania bankowego, sieci handlowe oraz inne organizacje podłączone do krytycznych ścieżek transferu środków.

Analiza techniczna

Łańcuch ataku Breeze Comet jest wieloetapowy i dobrze dopasowany do realiów środowisk finansowych. W fazie initial access napastnicy stosują password spraying oraz socjotechnikę z podszywaniem się pod wsparcie IT. Ofiary są nakłaniane do instalacji narzędzi zdalnego dostępu, takich jak AnyDesk, albo do uruchamiania skryptów PowerShell pod pretekstem aktualizacji aplikacji firmowych.

Alternatywną ścieżką wejścia jest kompromitacja podatnych serwerów JBoss, na których osadzane są web shelle umożliwiające dalszą eksploatację. Po uzyskaniu przyczółka grupa rozwija dostęp przy użyciu narzędzi tunelujących i proxy, w tym Chisel, Netcat oraz własnych komponentów.

W środowisku wewnętrznym prowadzone jest rozpoznanie z użyciem narzędzi takich jak Impacket, ADRecon i ADVipscan, a także autorskiego narzędzia do brute force wobec LDAP. Ruch lateralny odbywa się następnie przez nieautoryzowane sesje RDP, udziały SMB oraz przejęte poświadczenia uprzywilejowane.

Jednym z kluczowych komponentów kampanii jest malware COBALTSPIN, opisywany jako narzędzie routujące napisane w Rust. Jego rola polega na tunelowaniu ruchu pomiędzy infrastrukturą dowodzenia a wewnętrznymi systemami finansowymi. Dzięki odwrotnemu proxy SOCKS5 zestawionemu przez WebSocket operatorzy mogą komunikować się z zasobami odpowiedzialnymi za obsługę finansowych API, omijając część zabezpieczeń brzegowych.

Mechanizmy utrzymania dostępu również są rozbudowane. Oprócz komercyjnych narzędzi RMM zaobserwowano złośliwe pody Kubernetes, eksfiltrację sekretów chmurowych oraz kilka niestandardowych backdoorów.

LIGHTPAINT – komponent oparty na Javie służący do wdrażania trwałości z użyciem legalnego VPN.
MILDFROST – pasywny implant JAR wykorzystujący tunele DNS.
KICKPLATE – backdoor w Nim podszywający się pod komponenty Windows Update Health Tools.
BOATBEAM – implant w Go uruchamiający fałszywy serwer HTTPS imitujący IIS.

Aby utrudnić wykrycie, operatorzy wyłączają ochronę czasu rzeczywistego Windows Defendera za pomocą poleceń PowerShell. Następnie, wykorzystując przejęte konta oraz tunele sieciowe, uzyskują dostęp do kluczowych aplikacji finansowych i inicjują masowe, fałszywe operacje płatnicze. Po zakończeniu działań czyszczone są logi zdarzeń, usuwane katalogi robocze i ograniczany jest ślad powłamaniowy.

Interesującą obserwacją jest również to, że część skryptów i komponentów zawiera rozbudowane komentarze oraz ustandaryzowane nagłówki wykonania. Może to sugerować wykorzystanie modeli językowych do przyspieszania tworzenia i modyfikacji narzędzi ofensywnych.

Konsekwencje / ryzyko

Ryzyko związane z Breeze Comet wykracza daleko poza typowy incydent endpointowy. Ponieważ grupa koncentruje się na organizacjach zdolnych do inicjowania lub pośredniczenia w transferach finansowych, skutki kompromitacji mogą obejmować bezpośrednie straty pieniężne, zakłócenie ciągłości operacyjnej, utratę integralności rozliczeń oraz poważne konsekwencje regulacyjne.

Szczególnie narażone są podmioty mające dostęp do infrastruktury międzyinstytucjonalnej, poświadczeń mTLS, środowisk Active Directory, integracji fintech oraz procesów antyfraudowych. Jeżeli napastnik zrozumie logikę autoryzacji transferów i uzyska odpowiedni poziom dostępu do kont oraz interfejsów, część klasycznych mechanizmów detekcji może okazać się niewystarczająca, ponieważ transakcje będą wyglądały jak wygenerowane z legalnego środowiska operacyjnego.

Dodatkowe zagrożenie wynika z użycia skompromitowanych, zaufanych witryn oraz legalnych narzędzi administracyjnych. Taki model znacząco utrudnia wykrywanie oparte wyłącznie na reputacji domen, sygnaturach malware czy prostych wskaźnikach IOC. W praktyce oznacza to konieczność większego nacisku na detekcję behawioralną, monitoring tożsamości oraz analizę nietypowych przepływów transakcyjnych.

Rekomendacje

Organizacje z sektora finansowego, handlowego i płatniczego powinny traktować tego typu aktywność jako atak na proces biznesowy, a nie tylko na infrastrukturę IT. Skuteczna obrona wymaga połączenia kontroli technicznych, nadzoru nad tożsamością oraz monitoringu anomalii transakcyjnych.

Ograniczyć zdalną administrację wyłącznie do zatwierdzonych narzędzi i zaufanych adresów źródłowych.
Wdrożyć odporne na phishing mechanizmy MFA dla dostępu uprzywilejowanego, VPN, paneli administracyjnych i systemów płatniczych.
Regularnie audytować serwery aplikacyjne, zwłaszcza JBoss, pod kątem podatności, web shelli i niestandardowych artefaktów.
Segmentować sieć tak, aby stacje użytkowników, systemy administracyjne, środowiska finansowe i integracje API były logicznie odseparowane.
Monitorować wykorzystanie RDP, SMB, PowerShell, LDAP oraz narzędzi takich jak Chisel, Netcat, AnyDesk i SoftEther VPN.
Wdrożyć detekcję nadużyć w warstwie tożsamości, obejmującą password spraying, nietypowe logowania i eskalację uprawnień.
Chronić i regularnie rotować poświadczenia mTLS, sekrety aplikacyjne oraz klucze używane do komunikacji z systemami płatniczymi.
Rozbudować monitoring transakcyjny o korelację zdarzeń bezpieczeństwa z aktywnością biznesową.
Zabezpieczyć środowiska Kubernetes i chmurowe przed nieautoryzowanym wdrażaniem workloadów oraz eksfiltracją sekretów.
Przygotować procedury incident response obejmujące SOC, IAM, zespoły płatnicze, fraud detection i zgodność regulacyjną.

Podsumowanie

Breeze Comet pokazuje, że współczesna cyberprzestępczość finansowa coraz częściej przenosi się z poziomu oszustw detalicznych na poziom bezpośrednich włamań do organizacji obsługujących płatności. Kluczową cechą tych kampanii jest połączenie socjotechniki, legalnych narzędzi administracyjnych, autorskiego malware, ruchu lateralnego oraz dobrego zrozumienia procesów transferowych.

Dla obrońców najważniejszy wniosek jest jednoznaczny: ochrona systemów płatniczych nie może ograniczać się do zabezpieczeń aplikacyjnych. Musi obejmować tożsamość, segmentację, obserwowalność ruchu wewnętrznego, ochronę poświadczeń, kontrolę narzędzi zdalnych oraz analizę anomalii biznesowych, zanim atakujący przejdzie od dostępu technicznego do realnej kradzieży środków.

Źródła

Nadużycie Faronics Deploy do instalacji ScreenConnect: nowy wektor przejęcia zdalnego dostępu

Wprowadzenie do problemu / definicja

Legalne narzędzia administracyjne coraz częściej stają się elementem łańcucha ataku. W opisywanym przypadku cyberprzestępcy wykorzystali Faronics Deploy, platformę do zdalnego zarządzania stacjami roboczymi, aby uzyskać kontrolę nad urządzeniami ofiar i wdrożyć dodatkowe oprogramowanie do zdalnego dostępu w postaci ConnectWise ScreenConnect.

To przykład nadużycia zaufanego, podpisanego oprogramowania, które z perspektywy obrony jest trudniejsze do wykrycia niż klasyczny malware. Atakujący nie muszą od razu dostarczać złośliwego pliku — wystarczy, że skłonią użytkownika do uruchomienia legalnego agenta zarządzającego.

W skrócie

Atak rozpoczynał się od kampanii phishingowej z wykorzystaniem przynęt biznesowych i podatkowych.
Ofiary pobierały podpisany instalator Faronics Deploy, często podszyty pod plik lub aplikację Adobe.
Po instalacji endpoint był rejestrowany w infrastrukturze kontrolowanej przez napastników.
Atakujący zdalnie uruchamiali skrypty PowerShell i wdrażali ScreenConnect jako dodatkowy kanał dostępu.
Po działaniach ograniczających po stronie dostawcy skala aktywności wyraźnie spadła.

Kontekst / historia

Faronics Deploy to chmurowe rozwiązanie służące do centralnego zarządzania komputerami końcowymi, wdrażania aplikacji oraz wykonywania zadań administracyjnych. Tego typu narzędzia są powszechnie obecne w firmach i placówkach edukacyjnych, dlatego ich instalacja rzadko budzi natychmiastowe podejrzenia użytkowników lub administratorów.

Z punktu widzenia napastnika takie oprogramowanie ma dużą wartość operacyjną. Jeśli uda się zarejestrować urządzenie w nieautoryzowanej instancji zarządzającej, możliwe staje się wykonywanie poleceń, pobieranie komponentów i uruchamianie skryptów bez potrzeby stosowania bardziej hałaśliwych technik. To wpisuje się w rosnący trend nadużywania legalnych narzędzi administracyjnych do realizacji działań po uzyskaniu dostępu początkowego.

Według dostępnych informacji aktywność była obserwowana od 21 lipca do 20 sierpnia 2026 roku i objęła ponad 457 endpointów. Po 21 sierpnia 2026 roku odnotowano wyraźny spadek incydentów, co sugeruje skuteczność wdrożonych mechanizmów antyabuse.

Analiza techniczna

Łańcuch ataku rozpoczynał się od wiadomości phishingowych. Przynęty nawiązywały do codziennych procesów biznesowych, takich jak faktury, dokumenty czy materiały podatkowe. Celem było nakłonienie użytkownika do kliknięcia odsyłacza prowadzącego do spreparowanej strony pobierania.

Strona mogła profilować ofiarę i odróżniać prawdziwych użytkowników od środowisk analitycznych. W przypadku wykrycia sandboxa lub analizy automatycznej wyświetlany był nieszkodliwy komunikat, na przykład błąd ładowania. W scenariuszu właściwym użytkownik otrzymywał możliwość pobrania legalnego instalatora Faronics Deploy, zamaskowanego nazwą sugerującą plik Adobe, aktualizację lub dokument.

Po uruchomieniu instalatora urządzenie było przypisywane do wdrożenia kontrolowanego przez napastników. Następnie wykorzystywano natywne funkcje platformy do zdalnego wykonywania skryptów, głównie z użyciem PowerShell. Skrypty pobierały kolejne komponenty oraz uruchamiały narzędzia systemowe, takie jak curl, mshta czy msiexec, aby zainstalować dodatkowe elementy infrastruktury ataku.

Kluczowym celem końcowym było wdrożenie ConnectWise ScreenConnect. Faronics Deploy zapewniał początkowy kanał administracyjny, natomiast ScreenConnect dawał wygodniejszy, interaktywny dostęp typu hands-on-keyboard. Taki model zwiększał odporność operacji na częściową detekcję, ponieważ usunięcie jednego narzędzia nie musiało oznaczać utraty dostępu przez przeciwnika.

Z perspektywy śledczej ważne były artefakty pozostawiane przez agenta. Szczególną uwagę zwraca katalog C:\ProgramData\Faronics\Logs\, a zwłaszcza plik ScriptRunner.log, który może zawierać informacje o wykonywanych skryptach i źródłach pobierania. Istotny może być także parametr ck obecny w żądaniach konfiguracyjnych, pomocny przy identyfikacji powiązanego wdrożenia klienta.

Konsekwencje / ryzyko

Największe zagrożenie polega na tym, że atak opiera się na legalnym i podpisanym oprogramowaniu, a nie wyłącznie na klasycznych plikach malware. To znacząco osłabia skuteczność mechanizmów opartych tylko na reputacji plików, podpisie cyfrowym lub prostym allowlistingu producentów.

Dla organizacji oznacza to kilka praktycznych problemów. Użytkownik może uznać instalator za wiarygodny, bo nie wygląda on jak typowy złośliwy plik. Po wdrożeniu agenta przeciwnik uzyskuje możliwości zbliżone do legalnego administratora, w tym zdalne wykonywanie skryptów, instalowanie komponentów i przygotowanie gruntu pod dalszy ruch boczny. Dodatkowa instalacja ScreenConnect wzmacnia trwałość dostępu i utrudnia pełne usunięcie skutków incydentu.

Szczególnie zagrożone są środowiska, w których funkcjonuje wiele narzędzi RMM, EMM i zdalnego wsparcia, a proces ewidencji agentów nie jest rygorystycznie kontrolowany. W takich warunkach nieautoryzowany agent może długo pozostawać niezauważony.

Rekomendacje

Organizacje powinny potraktować ten incydent jako sygnał do przeglądu kontroli nad legalnym oprogramowaniem administracyjnym i zdalnym wsparciem.

Zweryfikować wszystkie instalacje Faronics Deploy i potwierdzić, że są przypisane do autoryzowanych tenantów oraz kont administracyjnych.
Przeanalizować logi w katalogu C:\ProgramData\Faronics\Logs\, zwłaszcza ScriptRunner.log, pod kątem nietypowych skryptów, poleceń i zewnętrznych źródeł pobierania.
Poszukać nieoczekiwanych instalacji ScreenConnect i porównać je z oficjalną inwentaryzacją narzędzi zdalnego dostępu.
Monitorować uruchomienia powershell.exe, mshta.exe, curl.exe i msiexec.exe w kontekście aktywności agentów zarządzających.
Wdrożyć polityki kontroli aplikacji uwzględniające nie tylko podpis kodu, ale także kontekst wdrożenia i przypisanie do zatwierdzonej instancji.
Wzmocnić ochronę przed phishingiem, w tym filtrowanie poczty, analizę domen podszywających się pod dostawców oraz szkolenia użytkowników.
Uzupełnić playbooki SOC i IR o scenariusze nadużycia legalnych narzędzi administracyjnych oraz poszukiwanie alternatywnych kanałów dostępu.

Podsumowanie

Przypadek nadużycia Faronics Deploy pokazuje, jak skuteczne może być połączenie socjotechniki, podpisanego oprogramowania i natywnych funkcji administracyjnych. Atakujący wykorzystali zaufane narzędzie do przejęcia kontroli nad endpointami, a następnie wdrożyli ScreenConnect jako trwały kanał zdalnego dostępu.

Dla obrońców najważniejsza lekcja jest jasna: samo rozróżnienie na oprogramowanie legalne i złośliwe nie wystarcza. Coraz większe znaczenie ma analiza kontekstu użycia, walidacja autoryzowanych wdrożeń oraz szybka korelacja logów z aktywnością skryptową i nieplanowanymi instalacjami narzędzi administracyjnych.

Źródła

TerminalFix: nowy wariant ClickFix wykorzystuje Windows Terminal i tunele zwrotne do infiltracji sieci

Wprowadzenie do problemu / definicja

TerminalFix to nowo opisany wariant ataków z rodziny ClickFix, w którym napastnicy wykorzystują fałszywe ekrany weryfikacji CAPTCHA, aby skłonić użytkownika do ręcznego uruchomienia polecenia PowerShell. W odróżnieniu od wcześniejszych kampanii tego typu, celem nie jest wyłącznie szybkie dostarczenie pojedynczego złośliwego pliku, ale uzyskanie trwałego dostępu do środowiska organizacji oraz stworzenie kanału do dalszej penetracji sieci.

Istotną zmianą jest użycie Windows Terminal lub konsoli PowerShell do uruchamiania bardziej rozbudowanych, wieloliniowych skryptów. Dzięki temu atakujący mogą zrealizować wieloetapowy łańcuch infekcji, obejmujący pobieranie kolejnych komponentów, ustanowienie persystencji i uruchomienie tunelu zwrotnego.

W skrócie

Kampania TerminalFix bazuje na przejętych lub spreparowanych stronach internetowych, które wyświetlają użytkownikowi fałszywą nakładkę CAPTCHA. Ofiara otrzymuje instrukcję uruchomienia polecenia, które pobiera archiwum ZIP zawierające legalnie podpisany plik wykonywalny oraz złośliwą bibliotekę DLL.

atak rozpoczyna się od socjotechniki opartej na fałszywej weryfikacji,
wykorzystywany jest DLL sideloading z użyciem zaufanego binarium,
dodatkowe komponenty są ukrywane w obrazach PNG metodą steganografii,
malware ustanawia persystencję i wykonuje rekonesans środowiska,
końcowym elementem jest reverse tunnel umożliwiający pivoting do sieci wewnętrznej.

Kontekst / historia

Ataki ClickFix od dłuższego czasu opierają się na prostym, ale skutecznym mechanizmie socjotechnicznym. Użytkownik otrzymuje komunikat sugerujący, że aby uzyskać dostęp do treści lub potwierdzić, że nie jest botem, musi wykonać określoną czynność administracyjną. W praktyce oznacza to zwykle skopiowanie i uruchomienie komendy, która inicjuje infekcję.

TerminalFix pokazuje jednak wyraźną ewolucję tego modelu. Zamiast jednofazowego malware, często nastawionego na kradzież danych uwierzytelniających, obserwujemy rozbudowaną kampanię post-exploitation. Zainfekowana stacja robocza staje się kontrolowanym punktem dostępowym, który może posłużyć do rozpoznania infrastruktury, ruchu bocznego i dalszej eskalacji działań napastnika.

Analiza techniczna

Łańcuch infekcji rozpoczyna się od wyświetlenia fałszywej strony weryfikacyjnej, która instruuje użytkownika, by wkleił polecenie do Windows Terminal lub PowerShell. Komenda pobiera archiwum ZIP zawierające prawidłowo podpisany plik wykonywalny oraz złośliwą bibliotekę DLL. To przygotowuje grunt pod zastosowanie techniki DLL sideloading, w której zaufany proces ładuje podstawioną bibliotekę i uruchamia kod atakującego.

Następnie malware pobiera kolejne komponenty ukryte w plikach PNG. Zastosowanie steganografii utrudnia wykrycie, ponieważ dane wykonywalne są osadzane w obrazach, które na pierwszy rzut oka wyglądają niegroźnie. Po odtworzeniu ładunków na dysku uruchamiane są dalsze etapy odpowiedzialne za utrzymanie dostępu i działania rozpoznawcze.

Persystencja jest ustanawiana co najmniej dwoma metodami: przez wpisy w kluczu Run rejestru oraz przez zaplanowane zadania. Równolegle złośliwe oprogramowanie rozpoczyna rekonesans środowiska, identyfikując m.in. kontrolery domeny, serwery baz danych, systemy backupowe, usługi pocztowe, bramy sieciowe i zasoby Active Directory.

Najbardziej niebezpiecznym elementem kampanii jest niestandardowy moduł reverse tunnel napisany w Pythonie. Implant zestawia wychodzące połączenie z infrastrukturą operatora przez szyfrowany kanał WebSocket i obsługuje przekazywanie ruchu TCP do systemów osiągalnych z poziomu zainfekowanego hosta. W praktyce pozwala to napastnikowi wykorzystywać stację ofiary jako punkt przesiadkowy do komunikacji z wewnętrznymi hostami, nawet jeśli nie są one bezpośrednio wystawione do Internetu.

Konsekwencje / ryzyko

TerminalFix należy traktować jako zagrożenie wykraczające poza klasyczną infekcję pojedynczego endpointu. Wdrożenie tunelu zwrotnego powoduje, że zainfekowana maszyna może zostać użyta jako węzeł pivotingu sieciowego. To znacząco zwiększa ryzyko dla organizacji, ponieważ nawet ograniczony początkowo dostęp może zostać wykorzystany do dalszego rozwoju intruzji.

W środowiskach domenowych szczególnie niebezpieczne jest połączenie rekonesansu Active Directory z możliwością tunelowania ruchu do systemów wewnętrznych. Atakujący mogą w ten sposób enumerować usługi administracyjne, testować dostęp do SMB, RDP, WinRM czy baz danych, a następnie próbować eskalacji uprawnień. Jeśli zainfekowany host ma dostęp do uprzywilejowanych poświadczeń lub wrażliwych segmentów sieci, skutkiem może być pełnoskalowe naruszenie, eksfiltracja danych albo wdrożenie ransomware.

Rekomendacje

Organizacje powinny podejść do TerminalFix jako do połączenia zaawansowanej socjotechniki i technik post-exploitation. Ochrona wymaga zarówno ograniczenia możliwości uruchamiania nieautoryzowanych skryptów, jak i dokładnej obserwacji nietypowych zachowań użytkowników oraz procesów potomnych.

ograniczyć możliwość uruchamiania PowerShell przez użytkowników tam, gdzie nie jest to konieczne,
wymuszać polityki ograniczające wykonywanie skryptów, w tym Constrained Language Mode, jeśli środowisko na to pozwala,
włączyć pełne logowanie aktywności skryptowej, w tym Script Block Logging i Module Logging,
monitorować uruchomienia Windows Terminal i PowerShell po aktywności przeglądarki oraz operacjach schowka,
wykrywać pobrania ZIP, uruchamianie podpisanych binariów z nietypowych lokalizacji i ładowanie bibliotek DLL spoza oczekiwanych katalogów,
analizować ruch wychodzący WebSocket do nieznanej infrastruktury,
szukać artefaktów persystencji, takich jak nietypowe zadania harmonogramu i nowe wpisy Run,
po potwierdzeniu kompromitacji badać nie tylko host końcowy, ale cały zakres potencjalnego ruchu bocznego w sieci.

W przypadku incydentu uzasadnione może być również sprawdzenie sesji uwierzytelniających, wykorzystania kont uprzywilejowanych, rotacja haseł administracyjnych oraz czasowa izolacja segmentów sieci, do których zainfekowany host miał dostęp.

Podsumowanie

TerminalFix potwierdza, że kampanie ClickFix stają się coraz bardziej dojrzałe i nie ograniczają się już do prostych prób infekcji. Połączenie fałszywej CAPTCHA, PowerShell, DLL sideloadingu, steganografii i tunelu zwrotnego tworzy wieloetapowy łańcuch ataku, który może zapewnić realny dostęp do zasobów wewnętrznych organizacji.

Dla zespołów bezpieczeństwa kluczowy wniosek jest jasny: incydenty inicjowane przez użytkownika z poziomu przeglądarki nie powinny być automatycznie traktowane jako odosobnione zdarzenia na pojedynczej stacji. W scenariuszu TerminalFix taki host może szybko stać się bramą do całej sieci, dlatego znaczenie mają szybka detekcja, analiza zasięgu naruszenia oraz zdecydowane działania ograniczające możliwość dalszego pivotingu.

Źródła

https://www.bleepingcomputer.com/news/security/microsoft-warns-of-terminalfix-attacks-deploying-reverse-tunnels/
https://www.microsoft.com/en-us/security/blog/2026/08/28/terminalfix-campaign-deploys-reverse-tunnel-through-multistage-intrusion/

TerminalFix: nowy wariant ClickFix wykorzystuje Windows Terminal i tunele zwrotne do infiltracji sieci

Wprowadzenie do problemu / definicja

W skrócie

atak rozpoczyna się od socjotechniki opartej na fałszywej weryfikacji,
wykorzystywany jest DLL sideloading z użyciem zaufanego binarium,
dodatkowe komponenty są ukrywane w obrazach PNG metodą steganografii,
malware ustanawia persystencję i wykonuje rekonesans środowiska,
końcowym elementem jest reverse tunnel umożliwiający pivoting do sieci wewnętrznej.

Kontekst / historia

Analiza techniczna

Konsekwencje / ryzyko

Rekomendacje

ograniczyć możliwość uruchamiania PowerShell przez użytkowników tam, gdzie nie jest to konieczne,
wymuszać polityki ograniczające wykonywanie skryptów, w tym Constrained Language Mode, jeśli środowisko na to pozwala,
włączyć pełne logowanie aktywności skryptowej, w tym Script Block Logging i Module Logging,
monitorować uruchomienia Windows Terminal i PowerShell po aktywności przeglądarki oraz operacjach schowka,
wykrywać pobrania ZIP, uruchamianie podpisanych binariów z nietypowych lokalizacji i ładowanie bibliotek DLL spoza oczekiwanych katalogów,
analizować ruch wychodzący WebSocket do nieznanej infrastruktury,
szukać artefaktów persystencji, takich jak nietypowe zadania harmonogramu i nowe wpisy Run,
po potwierdzeniu kompromitacji badać nie tylko host końcowy, ale cały zakres potencjalnego ruchu bocznego w sieci.

Podsumowanie

Źródła

https://www.bleepingcomputer.com/news/security/microsoft-warns-of-terminalfix-attacks-deploying-reverse-tunnels/
https://www.microsoft.com/en-us/security/blog/2026/08/28/terminalfix-campaign-deploys-reverse-tunnel-through-multistage-intrusion/

TerminalFix: fałszywe CAPTCHA Cloudflare i nowa odsłona ClickFix z tylnym wejściem reverse-tunnel

Wprowadzenie do problemu / definicja

TerminalFix to nowy wariant kampanii socjotechnicznej rozwijającej technikę ClickFix. W odróżnieniu od wcześniejszych schematów, które zwykle nakłaniały ofiarę do uruchomienia pojedynczej komendy w oknie „Uruchom”, tutaj użytkownik jest instruowany, aby wkleić i wykonać złośliwy skrypt bezpośrednio w Windows Terminal lub PowerShell.

Ta zmiana ma istotne znaczenie operacyjne. Środowisko terminalowe pozwala napastnikom na stosowanie dłuższych i bardziej złożonych łańcuchów poleceń, co zwiększa niezawodność infekcji i umożliwia wdrożenie wieloetapowego ataku już na starcie.

W skrócie

Kampania wykorzystuje przejęte witryny internetowe, na których wyświetlana jest fałszywa weryfikacja CAPTCHA imitująca mechanizmy Cloudflare. Po kliknięciu użytkownik nie przechodzi prawdziwej walidacji, lecz otrzymuje polecenie skopiowane do schowka i instrukcję jego uruchomienia w systemowym terminalu.

fałszywa nakładka CAPTCHA buduje wiarygodność ataku,
PowerShell pobiera kolejne komponenty złośliwego łańcucha,
legalny plik wykonywalny ładuje złośliwą bibliotekę DLL,
ładunki są ukrywane w plikach PNG,
atak ustanawia trwałość i prowadzi rekonesans Active Directory,
końcowym elementem jest implant reverse-tunnel umożliwiający zdalny pivot do sieci ofiary.

Kontekst / historia

ClickFix zyskał rozgłos jako technika socjotechniczna oparta na pozornie niewinnych instrukcjach dla użytkownika. Zamiast klasycznego załącznika lub pliku instalacyjnego, ofiara sama uruchamia komendę pod pretekstem naprawy błędu, aktualizacji albo weryfikacji bezpieczeństwa.

TerminalFix stanowi wyraźną ewolucję tego modelu. Kampania nie kończy się na prostym dropperze czy kradzieży pojedynczych danych dostępowych, ale przechodzi do pełnego, wieloetapowego scenariusza intruzji. Obejmuje on utrzymanie dostępu, rozpoznanie środowiska domenowego i przygotowanie zainfekowanego hosta do roli pośrednika sieciowego.

To sygnał, że techniki oparte na ręcznym wykonaniu polecenia przez użytkownika dojrzewają i coraz częściej stają się narzędziem do ataków o charakterze enterprise.

Analiza techniczna

Pierwszy etap rozpoczyna się na przejętej stronie internetowej, gdzie ofiara widzi interfejs imitujący legalną weryfikację Cloudflare. Elementy takie jak logo, pole wyboru i komunikaty o sprawdzaniu użytkownika mają stworzyć wrażenie autentycznego procesu ochronnego.

Po interakcji z nakładką do schowka kopiowane jest polecenie PowerShell. Użytkownik otrzymuje instrukcję, aby otworzyć Windows Terminal lub PowerShell i wkleić komendę ręcznie. Taki mechanizm omija część naturalnej ostrożności związanej z pobieraniem i uruchamianiem plików wykonywalnych.

Uruchomiony skrypt udaje proces weryfikacji, jednocześnie pobierając archiwum ZIP i rozpakowując je do katalogu w obszarze ProgramData. Następnie inicjowany jest plik wsadowy, który uruchamia legalnie wyglądający komponent wykonywalny. W tym miejscu dochodzi do DLL sideloadingu, czyli załadowania złośliwej biblioteki DLL przez zaufany proces.

Kolejne etapy obejmują pobieranie dodatkowych ładunków ukrytych w plikach PNG. Zastosowanie steganografii utrudnia detekcję, ponieważ z pozoru zwykłe obrazy pełnią funkcję nośników dalszych komponentów malware. Po wydobyciu zawartości atak ustanawia mechanizmy trwałości, między innymi za pomocą wpisów autostartu w rejestrze i zadań harmonogramu.

Ważnym elementem kampanii jest rekonesans Active Directory. Zaobserwowane działania wskazują na zbieranie informacji o systemie, użytkownikach, komputerach, relacjach zaufania między domenami i kontach uprzywilejowanych. Taki profil aktywności sugeruje przygotowanie do dalszego ruchu bocznego oraz identyfikację zasobów o wysokiej wartości.

Końcowym komponentem jest implant reverse-tunnel oparty na Pythonie. Umożliwia on tunelowanie ruchu TCP przez szyfrowany kanał WebSocket, dzięki czemu zainfekowany host może działać jako punkt pośredni pomiędzy infrastrukturą atakującego a zasobami dostępnymi wyłącznie z sieci wewnętrznej organizacji. Dodatkowy mechanizm wykonywania komend PowerShell z pliku poleceń rozszerza możliwości zdalnego sterowania systemem.

Konsekwencje / ryzyko

Największe ryzyko związane z TerminalFix wynika z połączenia skutecznej socjotechniki z technikami poeksploatacyjnymi typowymi dla zaawansowanych intruzji. Użytkownik sam uruchamia polecenie, co może utrudniać szybką identyfikację incydentu i osłabiać skuteczność części zabezpieczeń opartych na klasycznych wzorcach dostarczania malware.

Z perspektywy organizacji zagrożenie nie ogranicza się do pojedynczej stacji roboczej. Reverse tunnel może przekształcić zainfekowany komputer w bramę do zasobów wewnętrznych, a wcześniejszy rekonesans domenowy zwiększa prawdopodobieństwo eskalacji dostępu i dalszego ruchu bocznego.

możliwa jest kradzież poświadczeń i danych,
atakujący mogą rozpoznawać infrastrukturę domenową,
kompromitacja hosta może prowadzić do pivotingu do innych systemów,
utrzymanie trwałości utrudnia pełne usunięcie zagrożenia,
kampania może przygotować środowisko pod kolejne etapy, w tym ransomware.

Rekomendacje

Organizacje powinny traktować tego typu kampanię jako zagrożenie wymagające zarówno kontroli prewencyjnych, jak i monitoringu behawioralnego. Kluczowe znaczenie ma ograniczenie możliwości uruchamiania interpreterów skryptowych przez użytkowników, zwłaszcza w kontekstach nieuzasadnionych biznesowo.

W praktyce warto wdrożyć polityki ograniczające użycie PowerShell, Windows Terminal i podobnych narzędzi administracyjnych. Równie istotne jest monitorowanie nietypowych relacji procesów, takich jak uruchamianie terminala po interakcji z przeglądarką internetową.

włączyć rejestrowanie bloków skryptowych PowerShell,
monitorować oznaki DLL sideloadingu,
analizować tworzenie zadań harmonogramu i modyfikacje kluczy Run,
wykrywać nietypowe połączenia WebSocket i sesje tunelowane,
obserwować zapytania enumeracyjne wobec Active Directory,
szkolić użytkowników, że legalna CAPTCHA nie wymaga wklejania poleceń do terminala.

W przypadku podejrzenia infekcji zainfekowaną stację należy traktować jako potencjalny punkt pivotu. Oznacza to konieczność priorytetowego zbadania ruchu bocznego, połączeń wychodzących oraz aktywności związanej z kontami uprzywilejowanymi.

Podsumowanie

TerminalFix pokazuje, że kampanie ClickFix szybko ewoluują i coraz częściej przybierają formę wieloetapowych operacji umożliwiających trwały dostęp do środowiska ofiary. Połączenie fałszywej CAPTCHA, ręcznie uruchamianych komend PowerShell, DLL sideloadingu, steganografii i tunelowania ruchu tworzy wyjątkowo niebezpieczny łańcuch ataku.

Dla zespołów bezpieczeństwa oznacza to potrzebę łączenia edukacji użytkowników z twardymi kontrolami technicznymi, monitoringiem Active Directory i detekcją anomalii sieciowych. Nawet pojedyncze wykonanie pozornie niewinnego polecenia w terminalu może w takim scenariuszu otworzyć drogę do szerokiej kompromitacji środowiska.