Archiwa: Malware - Strona 25 z 292

PrettyPrague: publiczny PoC dla rzekomego 0-day w Avast Antivirus stawia pytania o bezpieczeństwo silników ochronnych

Wprowadzenie do problemu / definicja

Na początku września 2026 roku w społeczności bezpieczeństwa pojawił się proof-of-concept o nazwie PrettyPrague, opublikowany przez badacza posługującego się pseudonimem Chaotic Eclipse. Materiał został przedstawiony jako exploit dla rzekomej podatności typu zero-day w GenDigital Avast Antivirus, która ma umożliwiać lokalną eskalację uprawnień w systemach Windows.

Sprawa budzi szczególne zainteresowanie, ponieważ dotyczy oprogramowania ochronnego, które z definicji powinno utrudniać przejęcie hosta, a nie stawać się elementem łańcucha ataku. Jeżeli deklarowany scenariusz jest poprawny, luka może prowadzić do uzyskania uprawnień SYSTEM na stacji roboczej.

W skrócie

PrettyPrague to publicznie udostępniony PoC, który według autora działa na w pełni zaktualizowanych instalacjach Avast Antivirus oraz Windows 11 25H2. Opis wskazuje, że atak ma wykorzystywać mechanizmy Avast Sandbox do uzyskania dostępu do bazy SAM i uruchomienia powłoki z najwyższymi uprawnieniami.

PoC ma umożliwiać lokalną eskalację uprawnień do SYSTEM.
Opis obejmuje możliwość zrzutu bazy Security Account Manager.
Autor sugeruje potencjalny wpływ także na inne produkty z ekosystemu Gen Digital, w tym AVG i Norton.
Na moment publikacji nie przedstawiono publicznie pełnego, niezależnego potwierdzenia całego zakresu oddziaływania.

Kontekst / historia

Chaotic Eclipse jest kojarzony z publikacjami proof-of-concept dla podatności typu zero-day, szczególnie dotyczących komponentów systemowych Windows oraz produktów ochronnych. Takie działania regularnie wywołują debatę o granicach odpowiedzialnego ujawniania podatności, zwłaszcza gdy działający kod trafia do domeny publicznej przed oficjalnym stanowiskiem producenta lub przed publikacją poprawki.

Publikacja PrettyPrague wpisuje się w szerszy trend zainteresowania rozwiązaniami bezpieczeństwa jako celem badań i potencjalnych ataków. Produkty AV, EDR i sandboxy działają często z wysokimi uprawnieniami, są silnie zintegrowane z systemem operacyjnym i posiadają własne sterowniki, usługi oraz mechanizmy izolacji. To sprawia, że ewentualny błąd w takim komponencie może mieć poważniejsze skutki niż w zwykłej aplikacji użytkowej.

Analiza techniczna

Z technicznego punktu widzenia opisywany scenariusz dotyczy nadużycia uprzywilejowanego komponentu ochronnego. Jeżeli sandbox lub inny moduł antywirusowy nieprawidłowo waliduje operacje wykonywane z kontekstu lokalnego użytkownika, może otworzyć drogę do eskalacji uprawnień.

Według opisu autora PrettyPrague ma wykorzystywać podatność w Avast Sandbox do uzyskania dostępu do bazy Security Account Manager, czyli magazynu przechowującego lokalne informacje o kontach i skróty haseł. Sam dostęp do SAM jest już zdarzeniem bardzo wrażliwym, ale w połączeniu z możliwością uruchomienia powłoki SYSTEM oznacza krytyczne naruszenie integralności hosta.

W realistycznym scenariuszu atak mógłby zostać użyty po wcześniejszym uzyskaniu dostępu do stacji roboczej przez malware działający z uprawnieniami zwykłego użytkownika. Kolejnym krokiem byłaby lokalna eskalacja do SYSTEM, a następnie wyłączenie zabezpieczeń, kradzież poświadczeń, utrwalenie obecności lub przygotowanie ruchu bocznego. Taki model ataku jest szczególnie niebezpieczny w środowiskach firmowych, gdzie ten sam produkt ochronny działa na dużej liczbie punktów końcowych.

Warto jednak podkreślić, że publiczny PoC nie jest automatycznie równoważny pełnemu, niezależnie potwierdzonemu advisory producenta. Mimo to samo opublikowanie działającego kodu istotnie obniża próg wejścia dla operatorów malware, zespołów red team i innych podmiotów zainteresowanych szybkim wykorzystaniem błędu.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem potencjalnej podatności jest możliwość lokalnej eskalacji uprawnień do poziomu SYSTEM. Dla organizacji oznacza to ryzyko obejścia modelu najmniejszych uprawnień i przejęcia pełnej kontroli nad hostem z wykorzystaniem zaufanego oprogramowania ochronnego.

kradzież lokalnych poświadczeń z systemu Windows,
dezaktywacja lub osłabienie ochrony endpointa,
uruchamianie złośliwego kodu z najwyższymi uprawnieniami,
przygotowanie środowiska pod ransomware lub narzędzia post-exploitation,
zwiększenie skuteczności ruchu bocznego w infrastrukturze.

Dodatkowym czynnikiem ryzyka jest możliwy wpływ na więcej niż jeden produkt z ekosystemu Gen Digital. Jeżeli problem dotyczy wspólnego komponentu lub zbliżonej architektury, skala potencjalnego oddziaływania może być większa niż w przypadku pojedynczego rozwiązania konsumenckiego.

Rekomendacje

Organizacje korzystające z Avast, AVG lub Norton powinny potraktować pojawienie się PrettyPrague jako sygnał do podniesienia poziomu czujności operacyjnej. Nawet jeśli pełen zakres podatności nie został jeszcze formalnie potwierdzony, obecność publicznego PoC uzasadnia działania prewencyjne.

Zweryfikować aktualne wersje produktów ochronnych oraz systemów Windows.
Monitorować komunikaty producentów pod kątem poprawek, obejść i oficjalnych advisory bezpieczeństwa.
Włączyć wzmożone logowanie zdarzeń związanych z uruchamianiem procesów uprzywilejowanych, dostępem do SAM oraz nietypowym zachowaniem komponentów AV.
Wdrożyć reguły detekcyjne dla prób tworzenia powłoki SYSTEM z procesów powiązanych z oprogramowaniem antywirusowym.
Ograniczyć możliwość lokalnego uruchamiania nieautoryzowanego kodu przez użytkowników.
Stosować application control, WDAC, AppLocker lub równoważne mechanizmy ograniczania wykonywania binariów.
Przeprowadzić testy wykrywalności w EDR i SIEM pod kątem lokalnych eskalacji uprawnień oraz dumpingu poświadczeń.
Sprawdzić, czy konta lokalne i serwisowe są odpowiednio zabezpieczone, a hasła właściwie rotowane.
Utrzymywać segmentację sieci i ograniczać skutki kompromitacji pojedynczego hosta.

W środowiskach o podwyższonych wymaganiach bezpieczeństwa warto rozważyć również dodatkowe kontrole kompensacyjne, takie jak ograniczenie lokalnych uprawnień administracyjnych, izolacja stacji wysokiego ryzyka i priorytetowe huntingi pod kątem aktywności post-exploitation.

Podsumowanie

Publikacja PrettyPrague przypomina, że narzędzia bezpieczeństwa pozostają atrakcyjnym celem badań nad podatnościami i potencjalnych ataków. Jeśli deklaracje autora okażą się trafne, chodzi o bardzo poważny scenariusz lokalnej eskalacji uprawnień w produkcie ochronnym, który może zostać wykorzystany do pełnego przejęcia hosta.

Nawet bez formalnego potwierdzenia wszystkich szczegółów technicznych organizacje powinny potraktować taki PoC jako impuls do wzmożonego monitoringu, przeglądu konfiguracji zabezpieczeń endpointów i szybkiego reagowania na komunikaty producentów.

Źródła

https://securityaffairs.com/198243/hacking/chaotic-eclipse-releases-gendigital-avast-antivirus-zeroday-prettyprague.html
https://github.com/
https://www.gendigital.com/
https://www.avast.com/
https://learn.microsoft.com/windows/security/

UAC-0099 wykorzystuje prompt injection w malware, by zakłócać analizę AI

Wprowadzenie do problemu / definicja

Rosnąca rola modeli językowych w cyberbezpieczeństwie otwiera nową powierzchnię ataku. Coraz częściej systemy oparte na AI wspierają triage incydentów, analizę skryptów, klasyfikację zagrożeń i reverse engineering, dlatego napastnicy zaczynają testować metody, które nie tylko omijają detekcję, ale także zakłócają sam proces analityczny.

Przykładem takiego podejścia jest prompt injection osadzony bezpośrednio w złośliwym kodzie. W tym scenariuszu celem nie jest wykonanie dodatkowej funkcji na urządzeniu ofiary, lecz wywołanie błędnej reakcji po stronie narzędzia AI analizującego próbkę. To przesuwa ciężar ataku z tradycyjnej obfuskacji na manipulację semantyczną.

W skrócie

Grupa UAC-0099, wiązana z operacjami prowadzonymi przeciwko celom w Ukrainie, miała wykorzystać technikę określaną jako GuardBreaker. Mechanizm polegał na umieszczeniu w złośliwym skrypcie VBS komentarza zaprojektowanego tak, aby aktywować zabezpieczenia modelu językowego i skłonić go do odmowy dalszej analizy.

Skrypt był elementem łańcucha ataku związanego z loaderem MATCHBOIL, odpowiedzialnym za pobieranie kolejnych komponentów. Incydent pokazuje, że środowiska bezpieczeństwa korzystające z AI mogą być podatne nie tylko na klasyczne techniki unikania detekcji, ale również na celowe zanieczyszczanie kontekstu interpretacyjnego modeli.

Kontekst / historia

UAC-0099 to aktor zagrożeń kojarzony z kampaniami wymierzonymi między innymi w sektory o podwyższonym znaczeniu operacyjnym, takie jak transport i energetyka. Dotychczas grupa była łączona z działaniami wykorzystującymi złośliwe komponenty podszywające się pod legalne elementy oprogramowania oraz z operacjami opartymi na wieloetapowym dostarczaniu ładunków.

Nowa technika nie jest całkowitym odejściem od wcześniejszych metod, lecz ich rozwinięciem. Wcześniejsze obserwacje z rynku bezpieczeństwa wskazywały już, że napastnicy potrafią osadzać w plikach i pakietach teksty zaprojektowane tak, by zmylić narzędzia wykorzystujące modele językowe. Jeśli system AI potraktuje treść próbki jak instrukcję, a nie niezaufane dane, może dojść do błędnej klasyfikacji lub przerwania analizy.

Analiza techniczna

W opisywanym przypadku istota techniki GuardBreaker opiera się na prostym założeniu: model językowy analizujący kod może zinterpretować osadzony w nim komentarz jako istotny komunikat wymagający reakcji. Jeśli treść zostanie powiązana z tematyką objętą mechanizmami bezpieczeństwa modelu, system może odmówić odpowiedzi albo zakończyć analizę przed oceną właściwego działania malware.

Złośliwy skrypt VBS zawierał komentarz, którego zadaniem nie było wpływanie na wykonanie kodu na hoście. Jego funkcja była czysto antyanalityczna. To zasadniczo odróżnia tę technikę od klasycznej obfuskacji, gdzie celem jest ukrycie logiki programu przed silnikami skanującymi. Tutaj napastnik próbuje wywołać określoną reakcję poznawczą w warstwie AI.

Skrypt był powiązany z dostarczeniem MATCHBOIL, loadera napisanego w C#, wykorzystywanego do pobierania i instalowania kolejnych elementów ataku. Oznacza to, że prompt injection nie stanowił jedynie eksperymentalnego dodatku, ale był praktycznym komponentem pełnego łańcucha operacyjnego. W środowiskach SOC lub sandboxach opierających się na wstępnej ocenie LLM taki zabieg może doprowadzić do wygenerowania niepełnego raportu lub zbyt wczesnego zakończenia analizy.

Z punktu widzenia architektury bezpieczeństwa szczególnie narażone są organizacje, które zintegrowały modele językowe z analizą kodu, klasyfikacją artefaktów, przeglądem pakietów supply chain oraz narzędziami wspierającymi analityków malware. Jeśli zawartość pliku nie jest jednoznacznie traktowana jako dane wejściowe niebudzące zaufania, nawet prosty komentarz może zaburzyć pracę całego pipeline’u.

Konsekwencje / ryzyko

Najpoważniejsze ryzyko wynika nie z pojedynczego przypadku, lecz z możliwości systemowego obchodzenia procesów bezpieczeństwa wspieranych przez AI. Jeżeli organizacja nadmiernie ufa pierwszej interpretacji próbki wykonanej przez model językowy, atakujący może wpłynąć na priorytetyzację incydentu i opóźnić reakcję.

złośliwa próbka może zostać błędnie oznaczona jako nieprzeanalizowana lub niesklasyfikowana,
narzędzie AI może odmówić odpowiedzi i nie zwrócić informacji o rzeczywistej funkcji malware,
zanieczyszczony wynik modelu może trafić do dalszych systemów orkiestracji, ticketingu lub wzbogacania telemetrii,
analityk może otrzymać niepełny lub mylący opis zagrożenia,
organizacja może utracić część korzyści operacyjnych wynikających z automatyzacji opartej na LLM.

W praktyce zagrożenie dotyczy zwłaszcza przedsiębiorstw, które wdrożyły AI do przyspieszania triage, analizy załączników phishingowych, oceny skryptów administracyjnych oraz przeglądu zależności open source. Nawet jeśli pozostałe warstwy ochrony pozostaną skuteczne, osłabienie pierwszego etapu analizy może mieć istotny wpływ na czas wykrycia i jakość reakcji.

Rekomendacje

Organizacje wykorzystujące AI w cyberbezpieczeństwie powinny przyjąć zasadę, że wszystkie dane wejściowe przekazywane do modelu językowego są niezaufane. To założenie powinno znaleźć odzwierciedlenie zarówno w projektowaniu promptów systemowych, jak i w architekturze kontroli wejścia, wyjścia oraz eskalacji wyjątków.

oddzielać treść analizowanego pliku od instrukcji sterujących dla modelu,
stosować prompty systemowe nakazujące traktowanie zawartości próbek wyłącznie jako danych,
ograniczać automatyczne decyzje podejmowane wyłącznie na podstawie odpowiedzi LLM,
łączyć analizę AI z klasycznymi metodami statycznymi i dynamicznymi,
wykrywać nietypowe komentarze i frazy charakterystyczne dla prompt injection,
logować przypadki odmowy odpowiedzi przez model i kierować je do ręcznej weryfikacji,
testować pipeline’y pod kątem odporności na adversarial prompts osadzone w kodzie, skryptach i pakietach.

Dodatkowo warto wdrożyć mechanizmy fail-safe. Jeśli model odmówi analizy albo zwróci odpowiedź niejednoznaczną, próbka powinna automatycznie trafić do alternatywnego silnika analitycznego lub do manualnego przeglądu. Takie podejście ogranicza ryzyko, że pojedyncza manipulacja semantyczna sparaliżuje cały proces oceny zagrożenia.

Podsumowanie

Przypadek UAC-0099 pokazuje, że atakujący zaczynają świadomie uderzać nie tylko w systemy końcowe i mechanizmy detekcji, ale również w warstwę AI wspierającą obronę. GuardBreaker stanowi ważny sygnał ostrzegawczy dla organizacji rozwijających nowoczesne SOC i automatyzację analityczną opartą na LLM.

W kolejnych miesiącach można oczekiwać dalszego rozwoju technik prompt injection wymierzonych w sandboxy, narzędzia klasyfikacyjne i łańcuchy automatyzacji bezpieczeństwa. Im większa rola AI w operacjach cyberobrony, tym większa potrzeba wdrażania zabezpieczeń architektonicznych, które uniemożliwią traktowanie złośliwej treści jako instrukcji dla modelu.

Źródła

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

Irańscy operatorzy APT podszywają się pod rekruterów i infekują programistów wieloplatformowymi RAT-ami

Wprowadzenie do problemu / definicja

Kampanie wymierzone w programistów coraz częściej wykorzystują proces rekrutacyjny jako skuteczny wektor początkowego dostępu. W opisywanym scenariuszu atakujący podszywają się pod rekruterów i przesyłają kandydatom pozornie wiarygodne zadania techniczne, które po uruchomieniu instalują złośliwe oprogramowanie typu RAT.

Szczególnie niebezpieczny jest tu wieloplatformowy charakter zagrożenia. Zamiast skupiać się wyłącznie na systemach Windows, operatorzy przygotowali implanty zdolne do działania także na Linuxie i macOS, czyli środowiskach powszechnie używanych przez zespoły developerskie.

W skrócie

Badacze powiązali kampanię z irańską grupą Nimbus Manticore.
W analizie pojawiły się dwa wcześniej nieudokumentowane malware families: NodeRabbit oraz PollCat.
Złośliwe próbki były dostarczane w archiwach udających zadania programistyczne.
Atak bazował na uruchomieniu lokalnego projektu zawierającego ukryty kod JavaScript lub komponenty Node.js.
Celem kampanii są prawdopodobnie deweloperzy i specjaliści techniczni posiadający dostęp do cennych zasobów organizacyjnych.

Kontekst / historia

Nimbus Manticore jest od pewnego czasu łączona z operacjami cyberszpiegowskimi wykorzystującymi przynęty związane z zatrudnieniem, ofertami pracy i zadaniami kwalifikacyjnymi. Dotychczas aktywność tej grupy była kojarzona głównie z malware tworzonym w C, C++ i Go oraz z technikami nadużywania mechanizmów ładowania bibliotek i osadzania kodu.

Najnowsza kampania pokazuje jednak wyraźną zmianę podejścia. Operatorzy dostosowali narzędzia do realiów pracy współczesnych programistów, którzy regularnie uruchamiają obcy kod w ramach testów, proof-of-conceptów czy zadań rekrutacyjnych. To znacząco zwiększa skuteczność socjotechniki, ponieważ ofiara wykonuje czynność zgodną z jej codziennym profilem zawodowym.

Analiza techniczna

Pierwszy z implantów, NodeRabbit, był ukrywany w archiwum zawierającym rzekome zadanie związane z analizą błędów frontendowych. Instrukcja sugerowała, aby nie modyfikować części serwerowej projektu, ponieważ miała być ona rzekomo poprawna. W praktyce właśnie tam znajdowała się złośliwa logika.

Plik serwerowy importował spreparowany pakiet npm dołączony lokalnie do archiwum zamiast pobieranego z publicznego rejestru. Po uruchomieniu projekt inicjował implant działający w tle jako odłączony proces. Malware komunikował się z infrastrukturą C2 przez API obsługujące rejestrację hosta, pobieranie poleceń i przesyłanie wyników.

Możliwości NodeRabbit obejmowały rozpoznanie hosta, listowanie procesów, wykonywanie poleceń powłoki, enumerację katalogów, odczyt i zapis plików, usuwanie danych, tworzenie katalogów oraz zbieranie informacji o interfejsach sieciowych. Jedna z funkcji pozwalała również zapisywać zakodowany skrypt Node.js do pliku tymczasowego, uruchamiać go, a następnie usuwać artefakt w celu ograniczenia śladów aktywności.

Badacze opisali też kolejne warianty NodeRabbit. W części z nich zastosowano inne spreparowane pakiety npm, dodano mechanizmy utrudniające analizę i częściowe wsparcie dla środowisk korzystających z korporacyjnych serwerów proxy. Rozszerzono także zestaw poleceń oraz zmieniano sposób komunikacji z serwerem dowodzenia.

Mechanizmy trwałości różniły się zależnie od systemu operacyjnego. Dla Windows wykorzystywano klucze autostartu, dla Linux zadania cron, a dla macOS launch agenty. Jeden z wariantów uwzględniał również środowisko WSL oraz możliwość użycia skryptów uruchamianych przez wscript.exe i wsl.exe.

Dodatkowe funkcje obejmowały enumerację dysków, zabijanie procesów, zmianę serwera C2, próbę pozyskiwania danych z artefaktów Outlook PST i OST, instalację fałszywego rozszerzenia VS Code oraz modyfikację Git hooks w lokalnych repozytoriach. To pokazuje, że twórcy malware dobrze rozumieją środowisko pracy deweloperów i szukają sposobów na trwałe osadzenie się w ich łańcuchu narzędziowym.

Drugi implant, PollCat, był dostarczany w podobnym modelu, ale z dodatkową warstwą pozorowanej kontroli dostępu. Ofiara otrzymywała instrukcję wykonania zadania w ograniczonym czasie i wpisania sześciocyfrowego kodu OTP zmieniającego się co 30 sekund. Taki zabieg wzmacniał presję czasu i zwiększał prawdopodobieństwo, że kandydat uruchomi projekt bez pełnej weryfikacji.

Sama infekcja nie była jednak zależna od powodzenia walidacji OTP. Nawet jeśli użytkownik nie uzyskał pełnego dostępu do funkcji zadania, malware nadal mogło zostać uruchomione i nawiązać komunikację z infrastrukturą operatora. PollCat zapewniał trwałość przez cykliczne zadania w Windows, Linux i macOS, a następnie przesyłał informacje o systemie oraz pobierał instrukcje.

Funkcjonalnie PollCat oferował zestaw typowy dla zaawansowanego backdoora: operacje na plikach, wykonywanie poleceń, transfer danych, uruchamianie kodu JavaScript, ładowanie bibliotek DLL, obsługę archiwów ZIP oraz enumerację procesów, wolumenów i punktów montowania. Interesującym elementem było wyszukiwanie katalogów powiązanych z wybranymi dostawcami technologii i bezpieczeństwa, co może wskazywać na profilowanie środowiska ofiary pod kątem wartości wywiadowczej.

Konsekwencje / ryzyko

Ryzyko związane z tą kampanią należy ocenić jako wysokie. Atakujący łączą skuteczną socjotechnikę z technicznie wiarygodnym scenariuszem, w którym ofiara nie otwiera przypadkowego załącznika, lecz wykonuje pozornie uzasadnione zadanie zawodowe. Taki model znacząco obniża poziom ostrożności.

Dla organizacji najgroźniejsza jest możliwość kompromitacji stacji roboczych programistów. To właśnie na nich często znajdują się dostępy do repozytoriów kodu, klucze API, sekrety chmurowe, połączenia z CI/CD oraz narzędzia administracyjne używane w środowiskach developerskich. Modyfikacja Git hooks czy instalacja fałszywego rozszerzenia VS Code może dodatkowo zwiększyć skalę i czas trwania infiltracji.

Malware posiadające możliwość wykonywania poleceń i transferu plików może posłużyć zarówno do kradzieży kodu źródłowego, jak i do ruchu bocznego, dalszej eskalacji uprawnień lub przygotowania kolejnych etapów operacji szpiegowskiej. W praktyce zagrożone są nie tylko pojedyncze urządzenia, ale całe łańcuchy dostępu do środowisk produkcyjnych i danych organizacyjnych.

Rekomendacje

Organizacje powinny przyjąć zasadę, że każde zewnętrzne zadanie programistyczne jest kodem nieufnym. Tego rodzaju projekty należy uruchamiać wyłącznie w środowiskach izolowanych, najlepiej w jednorazowych maszynach wirtualnych lub kontenerach pozbawionych dostępu do firmowych zasobów, sekretów i repozytoriów.

Stacje robocze deweloperów powinny zostać objęte rozszerzoną telemetrią EDR obejmującą Windows, Linux i macOS. Równie istotne jest monitorowanie mechanizmów trwałości, aktywności procesów potomnych uruchamianych z projektów developerskich oraz nietypowych zmian w lokalnych środowiskach pracy.

Ograniczyć uruchamianie lokalnych zależności dostarczonych poza zaufanym łańcuchem dostaw.
Monitorować ręcznie osadzone pakiety w katalogach node_modules.
Wykrywać tworzenie zadań cron, scheduled tasks i launch agentów.
Analizować anomalie w katalogach rozszerzeń VS Code oraz w hookach Git.
Segmentować dostęp deweloperów do krytycznych zasobów i rotować sekrety.
Wdrożyć szkolenia dla zespołów technicznych dotyczące bezpiecznego uruchamiania zewnętrznych projektów.

Od strony procesowej warto wprowadzić procedury zgłaszania podejrzanych kontaktów rekrutacyjnych oraz obowiązek konsultacji z zespołem bezpieczeństwa przed uruchamianiem nieznanych projektów. Wysoką skuteczność może mieć także stosowanie dedykowanych kont i odseparowanych środowisk do testowania kodu otrzymanego od podmiotów zewnętrznych.

Podsumowanie

Opisana kampania pokazuje, że proces rekrutacyjny stał się pełnoprawnym wektorem ataku na organizacje technologiczne. NodeRabbit i PollCat nie są przypadkowymi RAT-ami, lecz narzędziami przygotowanymi z myślą o konkretnym środowisku pracy, konkretnych nawykach ofiar i wieloplatformowej eksploatacji.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że środowiska developerskie wymagają takiej samej dyscypliny ochronnej jak systemy produkcyjne czy administracyjne. Brak izolacji, monitoringu i kontroli zaufania do uruchamianego kodu może przełożyć się na kompromitację kodu źródłowego, infrastruktury oraz strategicznych danych organizacji.

Źródła

The Hacker News — https://thehackernews.com/2026/09/iranian-hackers-pose-as-recruiters-to.html
Kaspersky Securelist — https://securelist.com/
The Record — https://therecord.media/iranian-cyber-spies-target-aviation-fintech-new-malware

13 złośliwych pakietów Packagist atakuje iPhone’y i kradnie frazy seed portfeli kryptowalut

Wprowadzenie do problemu / definicja

Badacze bezpieczeństwa ujawnili kampanię supply chain wymierzoną w ekosystem PHP, w której złośliwe pakiety opublikowane w repozytorium Packagist podszywały się pod legalne motywy wykorzystywane przez serwisy streamingowe i komiksowe. Po wdrożeniu do aplikacji pakiety wstrzykiwały kod JavaScript do stron odwiedzanych przez użytkowników, co umożliwiało zarówno oszustwa reklamowe, jak i uruchamianie łańcucha exploitów na niezałatanych urządzeniach Apple.

To klasyczny przykład ataku na łańcuch dostaw oprogramowania, w którym celem nie jest wyłącznie administrator serwisu, lecz także jego użytkownicy końcowi. W tym przypadku końcowym skutkiem mogła być instalacja spyware oraz kradzież wrażliwych danych, w tym fraz seed i materiału kryptograficznego z mobilnych portfeli kryptowalut.

W skrócie

Kampania obejmowała 13 złośliwych pakietów Composer opublikowanych w kilku przestrzeniach nazw.
Pakiety wstrzykiwały JavaScript do stron, rozszerzając zasięg ataku na wszystkich odwiedzających serwis.
Na urządzeniach mobilnych aktywowano przekierowania reklamowe i hazardowe, a na iPhone’ach dodatkowo uruchamiano łańcuch exploitów.
Atak miał dotyczyć niezałatanych wersji iOS 18.4–18.6.x.
Końcowy payload kradł dane z urządzenia, w tym wpisy z Keychain i frazy seed popularnych portfeli kryptowalut.

Kontekst / historia

Incydent wpisuje się w rosnący trend kompromitacji komponentów open source wykorzystywanych w środowiskach produkcyjnych. Zamiast atakować bezpośrednio użytkownika, przeciwnik publikuje pozornie nieszkodliwy pakiet, który trafia do projektu deweloperskiego jako zależność. Gdy taki komponent zostaje wdrożony, staje się punktem wejścia do dalszej kompromitacji.

Według analizy badaczy wcześniejsze elementy tej samej aktywności obserwowano już w marcu 2026 roku. Początkowo kampania koncentrowała się na przekierowaniach, osadzaniu reklam i zbieraniu adresów URL. Najnowsza odsłona znacząco podniosła poziom zagrożenia, ponieważ z prostego fraudu reklamowego przeszła do dostarczania exploitów oraz spyware dla urządzeń Apple.

Analiza techniczna

Złośliwe pakiety zostały opublikowane pod wieloma nazwami vendorów i przedstawiane jako motywy dla konkretnych wdrożeń CMS. Po stronie serwera komponenty wstrzykiwały kod JavaScript renderowany globalnie na stronach serwisu. Taki mechanizm sprawia, że pojedyncza złośliwa biblioteka może automatycznie objąć swoim zasięgiem wszystkich odwiedzających witrynę.

Łańcuch ataku miał dwa główne scenariusze. Pierwszy polegał na monetyzacji ruchu mobilnego przez przekierowania do treści reklamowych i hazardowych. Drugi był uruchamiany selektywnie na iPhone’ach. Wstrzyknięty skrypt osadzał ukryty iframe, identyfikował wersję systemu i dobierał odpowiedni wariant exploita wykorzystującego luki WebKit oraz kolejne mechanizmy eskalacji uprawnień.

W analizie wskazano wykorzystanie podatności CVE-2025-31277 oraz CVE-2025-43529. Po uzyskaniu wykonania kodu w kontekście przetwarzania treści webowych atak przechodził poza sandbox WebContent, następnie do procesu GPU, a ostatecznie do warstwy jądra za pośrednictwem komponentu IOKit powiązanego z AppleM2ScalerCSCDriver. Taki poziom dostępu otwierał drogę do szerokiej eksfiltracji danych z urządzenia.

Końcowy payload zbierał rozbudowany zestaw artefaktów, w tym bazy Keychain, hasła Wi‑Fi, bazę SMS, książkę adresową, zdjęcia, historię połączeń, historię lokalizacji, ciasteczka przeglądarki i inne dane kont. Zebrane informacje były szyfrowane, a następnie przesyłane do infrastruktury dowodzenia i kontroli. W późniejszej wersji malware dodano moduł wyszukujący dane powiązane z portfelami kryptowalutowymi przechowywane w iOS Keychain.

Na liście interesujących aplikacji znalazły się m.in. Bitget, BitKeep, Bitpie, Phantom, Tonkeeper, Trust Wallet i OKX. Co istotne, część powiązanych pakietów nie zawierała aktywnego ładunku w chwili analizy, ale posiadała mechanizmy umożliwiające zdalne uruchomienie złośliwego kodu, na przykład przez pola typu „Custom JS”. To oznacza, że sama obecność takich komponentów może stanowić istotne ryzyko.

Konsekwencje / ryzyko

Dla operatorów witryn kompromitacja oznacza ryzyko naruszenia bezpieczeństwa użytkowników, utraty zaufania, szkód reputacyjnych oraz potencjalnych konsekwencji prawnych. Problem jest szczególnie poważny, ponieważ szkodliwy komponent może wyglądać jak zwykła zależność projektowa, a jego aktywność bywa trudna do wykrycia bez analizy integralności aplikacji i ruchu sieciowego.

Dla użytkowników iPhone’ów zagrożenie jest jeszcze większe. Samo odwiedzenie zainfekowanej strony w mobilnym Safari mogło wystarczyć do uruchomienia ataku typu drive-by compromise, bez konieczności instalowania aplikacji lub wykonywania dodatkowych działań. Kradzież danych z Keychain, wiadomości, kontaktów, zdjęć i informacji lokalizacyjnych stanowi poważne naruszenie prywatności, a przejęcie seedów portfeli może bezpośrednio prowadzić do utraty środków.

Na uwagę zasługuje także hybrydowy model monetyzacji kampanii. Połączenie masowego fraudu reklamowego z selektywną kradzieżą danych wysokiej wartości sugeruje dojrzałe zaplecze operacyjne oraz zdolność przeciwnika do elastycznego skalowania działań w zależności od profilu ofiary.

Rekomendacje

Administratorzy środowisk PHP korzystających z Packagist powinni niezwłocznie przeprowadzić przegląd zależności Composer i sprawdzić, czy w projektach nie występują wskazane pakiety lub inne artefakty od tych samych vendorów. W przypadku wykrycia konieczne jest ich usunięcie, odtworzenie środowiska z zaufanego źródła oraz szczegółowa analiza integralności aplikacji.

Przeanalizować logi HTTP pod kątem nietypowych przekierowań i ukrytych iframe.
Zweryfikować, czy aplikacja nie renderuje globalnie pól typu „Custom JS”.
Sprawdzić pliki JavaScript i jQuery dostarczane razem z motywami oraz dodatkami.
Zrotować poświadczenia administratorów, tokeny wdrożeniowe i inne sekrety.
Przeprowadzić przegląd IOC oraz śladów komunikacji z infrastrukturą C2.
Wdrożyć allowlisty zależności i automatyczne skanowanie pakietów pod kątem złośliwych zachowań.

Po stronie użytkowników kluczowe znaczenie ma szybkie instalowanie aktualizacji iOS i iPadOS zawierających poprawki bezpieczeństwa. Organizacje powinny egzekwować aktualizacje przez MDM, monitorować symptomy kompromitacji Safari i ograniczać dostęp z niezarządzanych urządzeń. Osoby przechowujące aktywa cyfrowe na smartfonach powinny rozważyć migrację seedów do nowego portfela po każdej podejrzanej ekspozycji oraz oddzielenie urządzenia codziennego od środowiska przechowującego klucze.

Podsumowanie

Opisana kampania pokazuje, że nowoczesne ataki supply chain na komponenty open source coraz częściej łączą kompromitację aplikacji serwerowej z bezpośrednimi atakami na klientów końcowych. Złośliwe pakiety Packagist nie ograniczały się do reklamowego fraudu, lecz pełniły rolę wektora dostarczającego exploity i spyware na niezałatane urządzenia iOS.

Szczególnie niebezpieczne jest to, że ofiarami stają się jednocześnie operatorzy stron i ich użytkownicy, a finalnym celem może być bezpośrednia kradzież danych oraz środków z portfeli kryptowalut. Dla zespołów bezpieczeństwa to kolejny sygnał, że monitoring zależności, kontrola integralności frontendu i szybkie zarządzanie poprawkami muszą być traktowane jako podstawowe elementy obrony.

Źródła

Pięciu obywateli Wenezueli przyznało się do próby jackpottingu bankomatów w Kansas

Wprowadzenie do problemu / definicja

Jackpotting bankomatów to technika ataku, w której przestępcy przejmują kontrolę nad urządzeniem ATM i wymuszają nieautoryzowaną wypłatę gotówki bez udziału legalnej transakcji klienta. Celem nie są w tym przypadku dane posiadacza karty, lecz sam bankomat, jego oprogramowanie, interfejsy serwisowe oraz mechanizmy odpowiedzialne za wydawanie banknotów. Najnowsza sprawa z Kansas pokazuje, że tego typu operacje nadal stanowią realne zagrożenie dla sektora finansowego.

W skrócie

Pięciu obywateli Wenezueli przyznało się do udziału w spisku mającym na celu kradzież pieniędzy z bankomatów w stanie Kansas przy użyciu techniki ATM jackpotting. Z ustaleń śledczych wynika, że grupa próbowała zainstalować złośliwe oprogramowanie bezpośrednio na urządzeniach, a następnie zdalnie uruchomić wypłatę gotówki. Ataki nie zakończyły się sukcesem, ponieważ w jednym przypadku aktywowany został alarm, a w drugim nie doszło do wydania pieniędzy.

sprawcy przyznali się do udziału w spisku dotyczącym kradzieży bankowej,
celem były bankomaty w Kansas,
schemat działania obejmował fizyczny dostęp do urządzeń i instalację malware,
plan zakładał zdalne wyzwolenie mechanizmu wypłaty gotówki,
incydenty wpisują się w szerszy trend ataków na infrastrukturę ATM.

Kontekst / historia

Do zdarzeń doszło w grudniu 2025 roku, gdy grupa podejrzanych przemieszczała się z Indiany do Kansas i obrała za cel bankomaty w miejscowościach Wamego oraz Manhattan. Według dokumentów sądowych model operacyjny zakładał fizyczne naruszenie urządzeń, wgranie złośliwego oprogramowania oraz późniejsze zdalne aktywowanie procesu wypłaty.

Śledztwo doprowadziło do zatrzymania sprawców kilka dni po nieudanych próbach. W toku postępowania wszyscy oskarżeni przyznali się do udziału w spisku w celu popełnienia kradzieży bankowej. Sprawa nie jest jednak odosobniona. Amerykańskie służby od kilku lat ostrzegają, że jackpotting ewoluował z niszowej techniki w dojrzały model działalności grup przestępczych, łączący sabotaż fizyczny z elementami cyberataku.

Analiza techniczna

Ataki typu jackpotting zazwyczaj wymagają wcześniejszego rozpoznania konkretnego modelu bankomatu, jego architektury sprzętowej oraz zastosowanych zabezpieczeń. Przestępcy starają się uzyskać dostęp do warstwy serwisowej urządzenia, portów komunikacyjnych lub komputera sterującego modułem wypłaty gotówki. Kolejnym krokiem jest uruchomienie złośliwego oprogramowania albo narzędzia umożliwiającego wydawanie komend mechanizmowi dystrybucji banknotów.

W analizowanej sprawie istotny jest hybrydowy charakter operacji. Z jednej strony konieczna była fizyczna obecność przy bankomacie w celu instalacji malware. Z drugiej strony plan przewidywał zdalne uruchomienie zainfekowanego urządzenia. Oznacza to próbę przejęcia funkcji logicznych ATM, a nie jedynie prostą manipulację obudową czy elementami mechanicznymi.

Taki scenariusz może wskazywać na kilka prawdopodobnych wektorów działania:

wykorzystanie interfejsów serwisowych i narzędzi utrzymaniowych,
uruchomienie nieautoryzowanego kodu w systemie operacyjnym bankomatu,
obejście mechanizmów kontroli aplikacji,
manipulację komunikacją pomiędzy komputerem ATM a modułem wydawania gotówki,
wybór modeli urządzeń uznanych za bardziej podatne na instalację malware.

Warto podkreślić, że sama próba instalacji złośliwego kodu w jednym z przypadków wywołała alarm. To pokazuje, że dobrze skonfigurowane zabezpieczenia antysabotażowe, monitoring zdarzeń oraz szybka reakcja operacyjna mogą zatrzymać atak jeszcze przed etapem wypłaty środków.

Konsekwencje / ryzyko

Ryzyko związane z ATM jackpotting nie ogranicza się do bezpośredniej utraty gotówki. Dla instytucji finansowych oznacza ono także koszty operacyjne, przestoje, analizę śledczą, konieczność przywrócenia urządzeń do bezpiecznego stanu oraz potencjalne szkody reputacyjne. W skrajnych przypadkach konieczna może być modernizacja lub wymiana podatnych bankomatów.

Szczególnie niebezpieczne jest to, że w tym modelu ataku nie są potrzebne skradzione dane klienta ani przejęte karty płatnicze. Atak wymierzony jest bezpośrednio w warstwę infrastrukturalną, dlatego klasyczne mechanizmy antyfraudowe skoncentrowane wyłącznie na zachowaniu użytkowników końcowych mogą okazać się niewystarczające.

straty finansowe wynikające z nieautoryzowanych wypłat,
koszty dochodzenia i przywracania ciągłości działania,
ryzyko reputacyjne i presja regulacyjna,
konieczność modernizacji starszych urządzeń,
wzrost znaczenia ochrony fizycznej i logicznej bankomatów.

Rekomendacje

Operatorzy ATM i instytucje finansowe powinni traktować jackpotting jako zagrożenie przekrojowe, obejmujące bezpieczeństwo fizyczne, cyberbezpieczeństwo i kontrolę operacyjną. Skuteczna ochrona wymaga zarówno hardeningu urządzeń, jak i monitorowania prób manipulacji na poziomie lokalnym oraz centralnym.

przeprowadzenie pełnej inwentaryzacji modeli bankomatów, systemów operacyjnych i komponentów serwisowych,
wyłączenie lub ścisłe ograniczenie nieużywanych portów, interfejsów i lokalnych mechanizmów administracyjnych,
wdrożenie list dozwolonych aplikacji oraz blokad uruchamiania nieautoryzowanego kodu,
regularne aktualizacje oprogramowania ATM, middleware i firmware urządzeń peryferyjnych,
stosowanie kontroli integralności plików i monitorowania zmian systemowych,
segmentację sieci oraz ograniczenie zdalnego dostępu do systemów zarządzania bankomatami,
aktywne mechanizmy wykrywania otwarcia obudowy, naruszenia sejfu i innych zdarzeń antysabotażowych,
korelację logów z bankomatów z systemami SIEM i procesami SOC,
monitoring wideo oraz analizę nietypowych wizyt serwisowych,
testy bezpieczeństwa i ćwiczenia red team ukierunkowane na scenariusze ATM malware,
procedury szybkiego wyłączenia urządzenia z eksploatacji po wykryciu prób manipulacji.

W praktyce duże znaczenie ma również współpraca z producentami bankomatów, dostawcami oprogramowania i organami ścigania. Wymiana informacji o nowych technikach ataku oraz podatnych konfiguracjach może znacząco skrócić czas reakcji i ograniczyć skutki incydentów.

Podsumowanie

Sprawa z Kansas potwierdza, że ATM jackpotting pozostaje istotnym zagrożeniem dla banków i operatorów sieci bankomatowych. Choć atakującym nie udało się doprowadzić do wypłaty gotówki, sam przebieg incydentu pokazuje rosnącą dojrzałość operacyjną grup przestępczych oraz znaczenie ochrony warstwy urządzeniowej. Dla sektora finansowego to wyraźny sygnał, że bezpieczeństwo bankomatów nie może ograniczać się do monitorowania transakcji klientów, lecz musi obejmować podejście wielowarstwowe, łączące zabezpieczenia fizyczne, logiczne i operacyjne.

Źródła

Five Venezuelan Nationals Plead Guilty in Kansas ATM Jackpotting Attempt — https://securityaffairs.com/198233/cyber-crime/five-venezuelan-nationals-plead-guilty-in-kansas-atm-jackpotting-attempt.html
U.S. Department of Justice — Five Venezuelan Nationals Plead Guilty in Kansas ATM Jackpotting Attempt — https://www.justice.gov/
FBI FLASH: ATM Jackpotting Trends and Losses — https://www.fbi.gov/

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.