Krajobraz zagrożeń 21-27/07/25

cert.orange.pl 2 dni temu

Przegląd tygodniowy rozpoczynamy od kontynuacji tematu krytycznych podatności w SharePoint, które przez cały czas nie pozwalają o sobie zapomnieć. Podobnie z krytycznymi podatnościami w produktach Cisco, które zaczęły być wykorzystywane w atakach. Przyjrzeliśmy się także tematom związanym z grupami APT takimi jak kampania Fire Ant dotykająca infrastruktury wirtualizacji czy kampania cyberszpiegowska od indyjskiej grupy APT. Analizowaliśmy również kampanię phishingową, podkreślającą istotę dodatkowych elementów kontrolnych przy implementacji MFA z mechanizmem FIDO. Tematy złośliwego systemu opisaliśmy w kampanii z fałszywą ofertą pracy, analizie loadera MaaS i incydencie z wprowadzeniem złośliwego kodu do asystenta AI Amazona.

Na skróty:

Temat tygodnia: ToolShell – Ataki i obrona: SharePointy na celowniku.
Zaawansowane zagrożenia: Kampania FireAnt – wirtualizacja jako Tier-0 cyberataków.
Cybercrime: Oferty pracy w pakiecie z malware’em.
Future: Asystent AI do programowania z funkcją wipera.
Oszustwa i podszycia: PoisonSeed – Quishing na FIDO.
Cyberwar: Słoń kontra drony, czyli kampania APT wymierzona w Turcje.
Złośliwe oprogramowanie: Nowy MaaS – Castle Loader.
CVE Tygodnia: Trzy krytyczne podatności w produktach Cisco.

Temat tygodnia

ToolShell – Ataki i obrona: SharePointy na celowniku.

Sprawa krytycznych podatności serwerów SharePoint (on-premises) dalej się rozwija i wciąż pojawiają się nowe informacje dotyczące zaobserwowanych ataków z ich wykorzystaniem. Mowa oczywiście o podatnościach CVE-2025-53770 (RCE, powiązana z CVE-2025-49704) i CVE-2025-53771 (bypass CVE-2025-49706), o których pisaliśmy już w poprzednim Krajobrazie Zagrożeń. Według analiz Microsoft, instancje dostępne z internetu były atakowane m.in. przez chińskie grupy klasy APT i spodziewane są dalsze tego typu działania. Violet Typhoon oraz Linen Typhoon to nazwane grupy, które wykorzystywały podatności określane jako ToolShell. Najszerzej jednak opisano łańcuch ataku przeprowadzany przez prawdopodobnie powiązaną z Chinami grupę Storm-2603.

Podatność w SharePointach dostępnych z internetu została wykorzystana do uzyskania dostępu do serwera i zainfekowania infrastruktury ransomware Warlock. Zaobserwowane w ataku narzędzia to między innymi PsExec, Mimikatz i Impacket (warto dodać, iż to trzy najczęściej wyklorzystywane narzędzia w łańcuchu ataku ramsomware). W trakcie infekcji komendy były wykonywane dzięki WMI, wyłączano Microsoft Defender, a propagacja ransomware w infrastrukturze odbywała się dzięki Group Policy Objects (GPO). Pierwsze tego typu ataki zaobserwowano 18 lipca i to ta data była pierwotnie uznawana za początek aktywnego wykorzystywania podatności przez atakujących, ale Microsoft informuje, iż Linen Typhoon i Violet Typhoon podejmowały próby ataków już 7 lipca.

W swoich publikacjach firmy Microsoft, Trustwave SpiderLabs i Unit42 podzieliły się listą Indicators of Compromise (IoC), których co prawda część należałoby nazwać Indicators of Attack (IoA), ale na ich podstawie warto przeanalizować logi pod kątem prób wykorzystania podatności we włąsnej infrastrukturze i potwierdzenia, czy któraś z nich mogła być udana. Pojawiły się tam atakujące adresy IP, C2, nazwy oraz hashe złośliwych plików, ale istotne są także informacje dotyczące zapytań kierowanych do serwerów SharePoint przez atakujących.

Ścieżki w zapytaniach HTTP POST:
/_layouts/15/ToolPane.aspx?DisplayMode=Edit
/_layouts/15/ToolPane.aspx?a=/ToolPane.aspx

Referer w nagłówku HTTP:
/_layouts/SignOut.aspx

Jeżeli złośliwy plik ASPX został poprawnie umieszczony na serwerze, to następowały żądania GET z następującą ścieżką:
/_layouts/15/spinstall0.aspx

Podano także lokalizacje, w których na serwerze mogą znajdować się złośliwe pliki umieszczone przez atakujących lub pojawiające się w toku infekcji:
C:\PROGRA~1\COMMON~1\MICROS~1\WEBSER~1\16\TEMPLATE\LAYOUTS\spinstall0.aspx
C:\PROGRA~1\COMMON~1\MICROS~1\WEBSER~1\15\TEMPLATE\LAYOUTS\spinstall0.aspx
C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\debug_dev.js

Ponadto, w artykułach znajdują się opisy taktyk, technik i procedur (TTP) oraz łańcuchów wykonania złośliwego kodu pozwalające zastosować bardziej zaawansowane metody wykrywania i proaktywnego poszukiwania zagrożeń (threat hunting), które zwrócą naszą uwagę na podejrzane działania choćby o ile atakujący zmodyfikują wykorzystywane pliki lub adresy IP. Zakodowane komendy Powershell, niestandardowe drzewa procesów, komendy służące do rekonesansu, nieoczekiwane wykorzystanie PsExec lub zrzut pamięci LSASS (na przykład dzięki Mimikatz), to przykłady wskaźników o szerokim zastosowaniu.

Przypominamy również o kluczowych mitygantach udostępnianych przez Microsoft w rekomendacjach dla klientów:

instalacja najnowszych aktualizacji dla SharePoint (on-premises) i zaprzestanie wykorzystywania wersji EOL (end-of-life),
zablokowanie dostępu z internetu do podatnego SharePointa,
potwierdzenie, iż AMSI jest uruchomione i poprawnie skonfigurowane,
wdrożenie i konfiguracja systemu antywirusowego na serwerze.

W przypadku posiadania dostępnego z internetu serwera SharePoint warto zastosować podejście assume breach, czyli założenia, iż przełamanie zabezpieczeń już nastąpiło. Poza instalacją poprawek konieczne w takiej sytuacji jest również zaktualizowanie (rotacja) kluczy kryptograficznych, które mogły zostać wykradzione i pozwalają atakującym utrzymać już uzyskany dostęp.

Więcej informacji:
https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/in-the-wild-exploitation-of-cve-2025-53770-and-cve-2025-53771-technical-details-and-mitigation-strategies
https://www.microsoft.com/en-us/security/blog/2025/07/22/disrupting-active-exploitation-of-on-premises-sharepoint-vulnerabilities/
https://unit42.paloaltonetworks.com/microsoft-sharepoint-cve-2025-49704-cve-2025-49706-cve-2025-53770/

Wybrane zagrożenia tygodnia

Zaawansowane zagrożenia

Kampania FireAnt – wirtualizacja jako Tier-0 cyberataków.

Od początku 2025 roku firma analityczna Sygnia prowadziła dochodzenie w sprawie zaawansowanej kampanii określanej mianem Fire Ant. Grupa APT, według analityków Sygnii, powiązana z Chinami celowała w infrastrukturę wirtualizacji oraz sieci – głównie VMware vCenter, ESXi oraz urządzenia sieciowe jak F5. Fire Ant wykorzystywał wielowarstwowe ścieżki ataku, aby uzyskać dostęp do zasobów znajdujących się w sieciach izolowanych lub segmentowanych, wcześniej uważanych za bezpieczne. Atakujący wykazali się wysoką zdolnością adaptacji – choćby po działaniach naprawczych wracali do sieci, rotowali narzędzia, wdrażali redundancję i rekonfigurowali środowisko, by przywrócić dostęp.

Atak zaczynał się od wykorzystania krytycznej podatności CVE-2023-34048 umożliwiającej zdalne wykonanie kodu na vCenter. Po kompromitacji napastnicy pozyskiwali poświadczenia konta „vpxuser”, które jako systemowe konto vCenter może administrować wszystkimi powiązanymi hostami ESXi i jest odporne na tryb lockdown.
Ruch lateralny w środowisku realizowany był przez wykorzystanie zdobytych poświadczeń oraz implementację własnych narzędzi – w tym modyfikowanych VIB-ów (instalowanych z opcją „– force”), omijających kontrolę podpisów cyfrowych. Wstrzykiwane przez napastników komponenty (np. z rodziny VIRTUALPITA) oraz implanty Pythonowe (takie jak „autobackup.bin”, działające jako daemon na porcie 8888), zapewniały utrzymanie trwałego dostępu choćby po restarcie hostów. Dla uzyskania odpornej trwałości w systemie manipulowane był pliki startowe w /etc/rc.local.d/, a logowanie systemowe wyłączane było przez zabicie procesu „vmsyslogd”, co blokuje zarówno lokalny syslog, jak i przekazywanie logów zdalnych oraz praktycznie uniemożliwia standardową analizę powłamaniową.

W ramach Fire Ant, w następnej fazie przejmowano kontrolę nad maszynami wirtualnymi bezpośrednio z poziomu hypervisora. Najgroźniejszym narzędziem w tym kontekście było wykorzystanie CVE-2023-20867 – podatności w VMware Tools, umożliwiającej wykonywanie poleceń na VM-ach przez PowerCLI oraz Invoke-VMScript bez uwierzytelniania po stronie gościa. Dzięki temu napastnicy mogli omijać wszelkie zabezpieczenia wewnątrz maszyn wirtualnych, kopiować ich pamięć (snapshoty) i ekstrahować z nich hasła, także domenowe. Dobrze udokumentowane są przypadki wykradania hashy i danych z kontrolerów domeny czy systemów zarządzania tożsamością.
W celu przełamania segmentacji i ograniczeń sieciowych w kampanii Fire Ant kompromitowano również urządzenia F5 (wykorzystując CVE-2022-1388) i instalowano webshelle, m.in. w katalogach obsługujących interfejs zarządzania. Ruch pomiędzy segmentami prowadzony był przez tunele (np. Neo-reGeorg, V2Ray), a napastnicy korzystali z tricków, takich jak przekierowania portów (netsh portproxy) oraz wykorzystywanie IPv6, aby ominąć typowe, skonfigurowane na IPv4 reguły ACL i firewalli. Złożone łańcuchy kompromitacji pozwalają atakującym na szybkie odtwarzanie dostępu do środowiska – choćby po podjętych próbach usunięcia ich narzędzi przez zespoły bezpieczeństwa.

Elementem odróżniającym kampanię od ataków masowych jest reakcja na działania zespołów reagowania na incydenty. Atakujący monitorowali obecność narzędzi analizy powłamaniowej i choćby zmieniali nazwy swoich plików, udając takie narzędzia, a także rekonfigurowali własne komponenty w odpowiedzi na działania obronne. Operacje były prowadzone z pełnym zrozumieniem topologii sieci, polityk bezpieczeństwa i typowych schematów reagowania po stronie broniących się organizacji.
Fire Ant to kampania cybernetyczna demonstrująca rekordowo wysoki poziom techniczny w obszarze ataków na infrastrukturę wirtualizacyjną. Podniósł on poprzeczkę dla ataków na wirtualizację. Pokazuje, iż cały stos bezpieczeństwa na poziomie hypervisora, łańcucha zarządzania i urządzeń sieciowych musi być traktowany jako „Tier-0”, z monitoringiem integralności, szybkim identyfikowaniem anomalii ruchu oraz rotacją kont systemowych i natychmiastowym wdrażaniem poprawek bezpieczeństwa – bo tradycyjne EDR/XDR i audyt na poziomie VM-ów są z po prostu omijane.

Więcej informacji:
https://www.sygnia.co/blog/fire-ant-a-deep-dive-into-hypervisor-level-espionage/

Cybercrime

Oferty pracy w pakiecie z malware’em.

Larva-208, znana również jako EncryptHub, to grupa cyberprzestępcza aktywna od czerwca 2024 roku, któa znana była głównie z obierania na cel pracowników IT. Do swoich ataków używali spear-phishingu i różnych zaawansowanych metod socjotechnicznych. Natomiast niedawno, obrali za cel bardzo konkretną grupę użytkowników – Web3 deweloperów, a wszystko przy użyciu fałszywej platformy „AI”, Norlax AI która jest kopią Teampilot.

W najnowszej swojej kampanii, Larva dzięki platform społecznościowych takich jak X.com (dawniej Twitter), Telegram i Remote3 wysyłała do ofiar (Web3 deweloperów) linki do spotkań pod pretekstem rozmowy o pracę lub recenzji portfolio, które to zaproszenia, przekierowywały do spotkania na Norlax AI. W przypadku Remote3 przez ostrzeżenia platformy, wysłanie linka następowało podczas rozmowy na Google Meet z wyjaśnieniem, iż reszta rozmowy odbędzie się na Norlax AI.

Po trafieniu na fałśzywą stronę, użytkownik był proszony o e-mail i kod zaproszenia, po wpisaniu tych informacji ofiara trafiała na rozmowę, w której nie działał jej mikrofon i po kilku sekundach dostawała fałszywe ostrzeżenie: audio drivers are missing or are outdated. Po naciśnięciu na ten komunikat następowało połączenie z serwerem atakującego i pobranie złośliwego instalatora Realtek HD Audio Driver. W momencie otworzenia pliku, pojawiał się fałszywy instalator, który w tle wykonywał Powershellowe komendy ukryte w pliku setup.dll. To łączyło hosta z serwerem C2 Larvy i na maszynę ofiary był pobierany Fickle Stealer, po czym następował jego start i eksfiltracja danych z hosta. Na serwer przestępców pobierane były między innymi: ip, wersja systemu operacyjnego, kraj, a także dane dostepowe do portfeli kryptowalut, loginy, hasła i inne wrażliwe informacje.

Zaobserwowano też obecność Larvy na platformie Steam, gdzie obrała za cel survivalową grę dostępną w early access pod tytułem „Chemia”. W plikach gry hostowanych przez Steam umieścili oni downloader trojana, który działa w tle. Downloader pobiera Fickle Stealer, HijackLoader i Vidar Stealer. HijackLoader utrzymuje stałe połączenie z hostem, natomiast Fickle Stealer i Vidar Stealer odpowiadają za eksfiltrację danych. Wszystko dzieje się w tle i ofiara nie jest choćby świadoma tego, iż została zaatakowana i jej dane zostały wykradzione, co jest bardzo groźną sytuacją z perspektywy bezpieczeństwa, ponieważ może być już za późno na reakcje.

Gra została już usunięta ze Steam, jej deweloper nie odniósł się do publicznych zarzutów, natomiast Prodaft na swoim githubie opublikował IOC dotyczące tego ataku.

Więcej informacji:
https://catalyst.prodaft.com/public/report/larva-208s-new-campaign-targets-web3-developers/overview#heading-1000
https://github.com/prodaft/malware-ioc/blob/master/LARVA-208/SteamCampaign.md

Future

Asystent AI do programowania z funkcją wipera.

Historia złośliwego promptu umieszczonego w asystencie do kodowania rozpoczyna się 13 lipca, kiedy to użytkownik lkmanka58 commituje podejrzaną zawartość do repozytorium. Cztery dni później, asystent Amazon Q jest wypuszczony jako wersja 1.84.0 ze złośliwym kodem.

Atakujący uzyskując dostęp do oficjalnego repozytorium zmodyfikował kod asystenta, umieszczając w nim złośliwy kod z opcją –trust-all-tools pozwalając na wykonywanie np.: poleceń bez pytania użytkownika o zgodę oraz -no-interactive pozwalając procesowi na uruchomienie się i działanie w tle. Kod zawierał także prompt definiujący działanie asystenta Amazon Q, który przypomina zachowanie wipera usuwającego znalezione zasoby systemowe i chmurowe.

Atakujący dodatkowo commitował złośliwego downloadera do repozytorium na branchu master pozwalając na automatyczne podmienianie prawidłowego kodu na złośliwy tylko jeżeli zmienna środowiskowa była ustawiona na prod – atakujący zadbał o wykonanie kodu jedynie w środowisku produkcyjnym unikając detekcji.

Złośliwa wersja 1.84.0 została opublikowana razem ze złośliwym kodem, a sam produkt, Amazon Q Developer Extension był dostępny do pobrania z poziomu Visual Studio Code ze względu na integrację asystenta AI z IDE.

18 lipca, downloader został usunięty z repozytorium, a następnego dnia wydano wersję asystenta 1.85.0 bez złośliwego kodu.

23 lipca strona 404 media opublikowała artykuł na temat złośliwego asystenta Amazona. Amazon wydał tego samego dnia biuletyn bezpieczeństwa informując o zdarzeniu. Według Amazona, token Githuba dla produktu Amazon Q Developer posiadał źle skonfigurowany zakres uprawnień, pozwalając atakującemu na tworzenie commitów automatycznie dodawanych do kolejnych wydań produktu.

Zainfekowana wersja 1.84.0 została wycofana i nie jest możliwe jej pobranie, sam token został odpowiednio podmieniony, a wydana wersja 1.85.0 jest rekomendowaną wersją do pobrania. Zespół AWS Security informuje także, iż pomimo dystrybucji złośliwej wersji asystenta, ze względu na błąd składniowy, nie udało się go uruchomić mimo pobrania na stację i integracji z IDE VS Code.

Amazon rekomenduje zastąpienie wersji 1.84.0 na wersję 1.85.0.

Incydent ze złośliwym kodem w Amazon Q Developer Extension jest klasycznym przykładem zatrucia łańcucha dostaw systemu (software supply chain poisoning), w którym atakujący skutecznie wprowadza złośliwe komponenty do oficjalnego kodu źródłowego, który następnie jest automatycznie dystrybuowany do użytkowników. Łatwość przeprowadzenia ataku wskazuje na poważne niedopatrzenia w procedurach bezpieczeństwa CI/CD oraz brak wystarczającej kontroli nad tokenami dostępowymi i procesem publikacji nowych wersji. Dodatkowym problemem jest fakt, iż Amazon nie zidentyfikował incydentu samodzielnie, ale zareagował dopiero po jego publicznym ujawnieniu przez niezależne źródła i media, co podważa skuteczność monitoringu bezpieczeństwa w ich ekosystemie.

Mimo iż złośliwy kod ostatecznie nie został uruchomiony z powodu błędu składniowego, sam fakt jego dystrybucji do użytkowników przez oficjalny kanał (Visual Studio Code Marketplace) pokazuje, jak groźne mogą być choćby krótkotrwałe naruszenia integralności kodu źródłowego. Incydent ten powinien być sygnałem ostrzegawczym dla firm integrujących AI i automatyzację z rozwojem systemu – bezpieczeństwo CI/CD nie może być drugorzędnym tematem.

Więcej informacji:
https://www.404media.co/hacker-plants-computer-wiping-commands-in-amazons-ai-coding-agent/
https://www.mbgsec.com/posts/2025-07-24-constructing-a-timeline-for-amazon-q-prompt-infection/
https://www.mbgsec.com/posts/2025-07-26-tracking-down-the-amazon-q-attacker-through-deleted-prs/
https://aws.amazon.com/security/security-bulletins/AWS-2025-015/
https://www.bleepingcomputer.com/news/security/amazon-ai-coding-agent-hacked-to-inject-data-wiping-commands/

Oszustwa i podszycia

PoisonSeed – Quishing na FIDO.

Firma Expel poinformowała o kampanii phishingowej nazwanej „PoisonSeed”, w której zaobserwowano możliwość rzekomego ominięcia uwierzytelniania FIDO2 poprzez wykorzystanie funkcji logowania między urządzeniami (ang. cross-device sign-in). Według pierwotnej analizy atakujący, po przejęciu danych uwierzytelniających użytkownika dzięki fałszywej strony logowania (np. portalu SSO bazującego na Okta), uruchamiał sesję logowania do prawdziwej instancji usługi i żądał autoryzacji dzięki kodu QR. Wygenerowany kod był następnie przekazywany ofierze w ramach witryny phishingowej, licząc na to, iż użytkownik zeskanuje go własnym urządzeniem FIDO i w ten sposób zatwierdzi dostęp dla atakującego.

Kluczowym elementem tej metody był fakt, iż kod QR wygenerowany w procesie „cross-device sign-in” miałby teoretycznie umożliwiać zatwierdzenie sesji logowania choćby w przypadku, gdy urządzenie użytkownika nie znajduje się w fizycznej bliskości systemu atakującego. W specyfikacji FIDO WebAuthn logowanie między urządzeniami może być realizowane poprzez Bluetooth, NFC lub kod QR – jednak implementacje niektórych usługodawców dopuszczają logowanie zdalne z pominięciem fizycznej obecności. Zdaniem zespołu Expel, taka konfiguracja skutkuje potencjalnym „downgradem” z silnego uwierzytelniania związanego z fizyczną obecnością użytkownika (np. token USB lub NFC) do formy bardziej podatnej na ataki socjotechniczne.

Po publikacji pierwotnej wersji raportu, Expel przeprowadził pogłębioną analizę logów oraz zweryfikował interpretację zdarzenia z dostawcą tożsamości (IdP). W wyniku tych działań stwierdzono, iż sesja uwierzytelniająca nie została faktycznie zakończona sukcesem – choć dane logowania użytkownika zostały przejęte, druga faza uwierzytelnienia, oparta na protokole WebAuthn, nie została pomyślnie zrealizowana. Oznacza to, iż mimo prób wykorzystania kodu QR przez atakującego, dostęp do zasobu nie został faktycznie uzyskany. Tym samym teza o skutecznym ominięciu FIDO została wycofana, a incydent uznano za nieudany.

Atak PoisonSeed nie ujawnia więc podatności w samym protokole FIDO2, ale pokazuje potencjalne ryzyko wynikające z błędów w implementacji logowania między urządzeniami. najważniejszy mechanizm bezpieczeństwa, jakim jest wymóg fizycznej bliskości urządzeń (np. poprzez Bluetooth), musi być bezwzględnie egzekwowany w środowiskach wysokiego ryzyka. W przeciwnym razie możliwe jest, iż socjotechnika – przy odpowiednio zaprojektowanym flow logowania – doprowadzi do nieautoryzowanego dostępu, choćby jeżeli użytkownik dysponuje sprzętowym kluczem uwierzytelniającym.

Warto również podkreślić inny wektor ataku, zaobserwowany równolegle z incydentem PoisonSeed. W tym przypadku atakujący, po uzyskaniu dostępu do konta ofiary (np. przez phishing lub reset hasła), dokonywał samodzielnej rejestracji własnego klucza FIDO w portalu zarządzania tożsamością. Dzięki temu, przy kolejnych logowaniach, możliwe było całkowicie legalne wykorzystanie nowo zarejestrowanego klucza, co całkowicie pomijało wcześniejsze zabezpieczenia MFA. Ten scenariusz nie wykorzystuje luk w FIDO, ale wskazuje na konieczność monitorowania rejestracji nowych urządzeń oraz wdrażania reguł detekcji opartych na kontekście (lokalizacja, fingerprinting urządzenia, czas dostępu, itp.).

Podsumowując, mimo iż atak PoisonSeed nie doprowadził do przełamania mechanizmów FIDO2, stanowi ważne ostrzeżenie dla organizacji wykorzystujących nowoczesne metody uwierzytelniania. Dowodzi, iż implementacja MFA oparta na FIDO powinna być wzbogacona o dodatkowe środki kontrolne, tj. egzekwowanie bliskości fizycznej, ograniczenia geograficzne, logikę wykrywania anomalii oraz szczegółowy audyt rejestracji urządzeń. Bez tych środków choćby najlepiej zaprojektowany protokół może zostać zdegradowany do słabszej formy, co w rękach doświadczonego operatora phishingowego może prowadzić do poważnego naruszenia bezpieczeństwa.

Więcej informacji:
https://expel.com/blog/poisonseed-downgrading-fido-key-authentications-to-fetch-user-accounts/

Cyberwar

Słoń kontra drony, czyli kampania APT wymierzona w Turcję.

Zespół Arctic Wolf Labs ujawnił ukierunkowaną kampanię cyberszpiegowską wymierzoną w turecki przemysł obronny, przypisaną grupie Dropping Elephant (aka Patchwork, Quilted Tiger, Monsoon, APT‑C‑09). Grupa działa co najmniej od 2013 roku, a badacze od lat wskazują na jej indyjskie pochodzenie operacyjne. Dotychczasowe ofiary obejmują podmioty rządowe, dyplomatyczne i przemysłowe, zwłaszcza powiązane z Chinami i gospodarkami Azji Południowej.
W najnowszym incydencie, opisanym 23 lipca 2025 r. celem był wiodący turecki producent systemów rakietowych uzbrojenia precyzyjnego.

Atak rozpoczyna się od wiadomości phishingowej stylizowanej na zaproszenie na konferencje o systemach bezzałogowych w Stambule. Załączony plik: Unmanned_Vehicle_Systems_Conference_2025_In_Istanbul.lnk po uruchomieniu wywoływał zaciemniony skrypt Powershell, który sekwencyjnie pobiera pięć komponentów z domeny expouav[.]org schowanej za Cloudflare. Użytkownikowi wyświetlany jest jednocześnie PDF‑wabik kopiujący treści z serwisu konferencyjnego, co maskuje instalację. Do katalogu C:\Windows\Tasks\ trafiają: wabik PDF, legalny vlc.exe, złośliwa libvlc.dll, legalny schtasks.exe przemianowany na Winver.exe oraz vlc.log zawierający zaszyfrowany shellcode. PowerShell tworzy zadanie harmonogramu NewErrorReport uruchamiane co minutę, które startuje vlc.exe. Legalny VLC wykonuje DLL side‑loading z libvlc.dll. Uruchomiona w ten sposób złośliwa biblioteka odszyfrowuje ładunek z vlc.log przechowywanym w kodzie kluczem i uruchamia go w pamięci procesu VLC. Ostateczny payload to plik wykonywalny w architekturze 32 bitowej: x86 EXE z rozbudowaną telemetrią i funkcjami unikania analizy: tworzy muteks ghjghkj, przeprowadza aktywny rekonesans (m.in. GetComputerNameW, GetUserNameW, parametry firmware i CPU), wykonuje zrzuty ekranu (GDI+), korzysta z liczników czasu i cech procesora do detekcji sandboxów, a komunikację C2 prowadzi kanałem HTTPS.

Ewolucja TTP grupy Dropping Elephant obejmuje zmianę finalnego ładunku złośliwego systemu z 64-bitowej biblioteki DLL na 32-bitowy plik wykonywalny oraz dopracowanie komunikacji z serwerami C2. Co więcej grupa kładzie większy nacisk na użycie w atakach legalnych narzędzi lub aplikacji systemowych (VLC, schtasks) w celu efektywnego utrzymania dostępu i maskowania swoich operacji.

Celowanie w producenta systemów rakietowych w państwie, które dominuje na światowym rynku eksportu uzbrojonych UAV (bezzałogowych systemów powietrznych) i zacieśnia współpracę z Pakistanem, jest spójne z interesem informacyjnym Threat Actora o indyjskiej proweniencji. Kampania ma charakter długofalowego rozpoznania technicznego (R&D, łańcuch dostaw, interoperacyjność NATO), a nie destrukcyjny. Równolegle można oczekiwać szumu operacji haktywistycznych (DDoS, defacement) w trakcie napięć politycznych, jednak realne ryzyko wynika z cichej penetracji łańcucha dostaw obronnego i pozyskania planów, schematów, konfiguracji oraz wiedzy o procedurach operacyjnych. To zwiększa zdolności przeciwnika do precyzyjnego modelowania zdolności bojowych, obchodzenia środków obrony i prowadzenia dalszych operacji z użyciem uzyskanych danych.

Więcej informacji:
https://arcticwolf.com/resources/blog/dropping-elephant-apt-group-targets-turkish-defense-industry/

Złośliwe oprogramowanie

Nowy MaaS – Castle Loader.

CastleLoader to nowy, modularny loader Malware-as-a-Service (MaaS) obserwowany od maja 2025 r. Badacze PRODAFT potwierdzili co najmniej 1 634 prób infekcji i 469 skutecznych kompromitacji, przy czym infrastruktura C2 obejmowała siedem serwerów, a złośliwy kod służył do dostarczania m.in. DeerStealer, RedLine, StealC, Hijack Loader oraz różnych RAT-ów.

Wektor początkowy opiera się głównie na socjotechnice. Operatorzy wykorzystują metodę ClickFix, czyli fałszywe strony Cloudflare lub komunikaty o błędach, prezentowane użytkownikom po wyszukaniu w Google, które nakłaniają do skopiowania i uruchomienia komend PowerShell. Alternatywnym wektorem są też repozytoria na GitHub-ie imitujące popularne projekty. Deweloper, który klonuje lub instaluje pozornie wiarygodne narzędzie, wprowadza loader na stację roboczą.
Łańcuch infekcji rozpoczyna się od manualnego uruchomienia skryptu Powershell lub plikó wykonywalnych pobranych z Githuba. Loader rozpakowuje w pamięci shellcode zawierający moduł główny, a następnie dokonuje dead code injection w uruchomionym procesie. Technika ta polega na wstrzyknięciu nieużywanych instrukcji (NOP-ów, bezużytecznych gałęzi warunkowych), co zmienia sygnaturę binarną i deformuje model przepływu sterowania, utrudniając statyczną i dynamiczną analizę. Po zaszyciu się w legalnym procesie loader zestawia kanał C2 przez HTTPS, przekazując identyfikator kampanii oraz fingerprint systemu. Panel operatorski zwraca konfigurację, która wskazuje, które z modułów drugiego etapu należy pobrać; obserwowano zrzuty RedLine, DeerStealer, StealC, NetSupport RAT oraz kolejne loadery, co ilustruje modularny charakter usługi MaaS. Każdy moduł jest pakowany i dodatkowo zaciemniany, a jego pobranie następuje przy użyciu HTTP GET z niestandardowym nagłówkiem, po czym następuje kolejny dead code injection w nowym procesie ofiary. Daje to atakującemu elastyczność w doborze ładunku, rozdziela inicjalny artefakt od funkcji końcowej i utrudnia korelację zdarzeń w EDR.

CastleLoader wpisuje się w ewolucję ekosystemów MaaS: wysokiej jakości panel operatorski, łatwość parametryzacji ładunków i wykorzystanie powszechnie zaufanych platform (GitHub, Cloudflare) minimalizują koszty kampanii i zwiększają możliwości dystrybucyjne przestępców. Ryzyko dla organizacji wynika zarówno z kompromitacji stacji deweloperskich, jak i z eskalacji do sieci korporacyjnych przez skradzione poświadczenia lub ruch boczny. Efektywność loadera, której potwierdzeniem jest niemal trzydziestoprocentowy wskaźnik skutecznych infekcji, sugeruje, iż zagrożenie utrzyma się na rynku i będzie adaptowane do kolejnych rodzin szkodliwego oprogramowania

Więcej informacji:
https://catalyst.prodaft.com/public/report/understanding-current-castleloader-campaigns/overview#heading-1000

CVE tygodnia

Trzy krytyczne podatności w produktach Cisco.

Trzy krytyczne podatności (wszystkie CVSS3.1: 10.0) dotyczące produktów Cisco zostały opublikowane w czerwcu 2025. Krótko po tym, do jednej z nich, CVE-2025-20281 opublikowano PoC na Githubie. Obecnie, dwie podatności z trzech, CVE-2025-20281 i CVE-2025-20337 są aktywnie wykorzystywane w atakach.

Podatności CVE-2025-20281 i CVE-2025-20337 dotykają produktów Cisco ISE oraz Cisco ISE-PIC, pozwalając zdalnemu, nieuwierzytelnionemu atakującemu na wykonanie kodu z uprawnieniami root na zadanym systemie. Wykorzystanie podatności opiera się na przygotowaniu odpowiedniego żądania do konkretnego API, które nie posiada walidacji danych wejściowych przekazywanych od atakującego wykonującego żądanie.

W opublikowanym PoC do CVE-2025-20281 możemy sprawdzić, iż wysłanie nieuwierzytelnionego żądania POST do API z przykładową komendą cmd umieszczoną w polu “name” w polu InternalUser, powoduje wykonanie przekazanej komendy jako root w systemie.

Trzecia z podatności, CVE-2025-20282 dotyczy wewnętrznego API w produktach Cisco ISE i Cisco ISE-PIC umożliwiając zdalnemu, nieuwierzytelnionemu atakującemu na umieszczenie plików na zadanym systemie i wykonanie ich jako root. Powodem występowania podatności jest brak walidacji powstrzymujących użytkownika przed umieszczeniem plików w katalogach z uprawnieniami w systemie. Pomyślne wykorzystanie podatności może zatem pozwolić na umieszczenie złośliwych plików w katalogach systemu i wykonanie kodu lub podwyższenie uprawnień do poziomu roota.

Należy zaznaczyć, iż podatności nie są ze sobą powiązane i skuteczne wykorzystanie jednej podatności nie jest wymagane do wykorzystania drugiej.
Obecnie nie są znane obejścia podatności pozwalające na czasową mitygację. Zalecamy stosowanie się do biuletynu producenta i wgranie odpowiedniej wersji z łatką bezpieczeństwa.

Więcej informacji:
https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ise-unauth-rce-ZAd2GnJ6
https://github.com/abrewer251/CVE-2025-20281-2-Cisco-ISE-RCE

Idź do oryginalnego materiału