Ataki PaperCut wspomagane przez AI ujawniają drugie RCE i globalną sieć ofiar

Podsumowanie

Rosyjskojęzyczny podmiot zagrożenia przeprowadził ukierunkowaną kampanię przeciwko ukraińskiej infrastrukturze, koncentrując się szczególnie na ekosystemie wymiany danych i serwerach logowania Graylog. Atakujący wykorzystał łańcuch wstrzyknięcia JNDI oparty na Log4Shell do wykonania zdalnego kodu i wdrożenia odwróconych powłok. Chociaż podejmowano wiele prób wyzysku systemów MikroTik i Fortinet, główny udany dostęp opierał się na wielokrotnie używanej deserializacji CommonsBeanutils2.

Śledztwo

Śledztwo rozpoczęło się po tym, jak badacze odkryli, że katalog stagingowy operatora był wystawiony na publiczny adres IP przez około 17 godzin. Analitycy odzyskali robocze pliki atakującego, w tym skrypty exploitów, generatory ładunków, historię poleceń powłoki oraz wyniki rekonesansu. To zdemaskowanie umożliwiło odtworzenie pełnego łańcucha ataku, od początkowego rekonesansu masscan po pomyślne wykonanie kodu na instancjach Graylog.

Łagodzenie

Organizacje powinny priorytetowo zaktualizować wdrożenia Graylog i upewnić się, że wyszukiwania JNDI są wyłączone lub ściśle ograniczone poprzez odpowiednie kontrole bezpieczeństwa Java. Powinno zostać wprowadzone ścisłe filtrowanie egress w celu zablokowania nieautoryzowanych połączeń LDAP i RMI z serwerów aplikacji. Zespoły bezpieczeństwa powinny również monitorować podejrzane procesy podrzędne uruchamiane przez usługi oparte na Javie i egzekwować zabezpieczenia CSRF na wrażliwych punktach końcowych API.

Odpowiedź

Jeśli zostanie wykryta podejrzana aktywność JNDI lub nieoczekiwane procesy podrzędne pochodzące z usług webowych, natychmiast odizoluj zainfekowany host. Przejrzyj logi aplikacji w poszukiwaniu wzorców udanej eksploatacji, ze szczególnym zwróceniem uwagi na /api/system/sessions punkt końcowy. Przeprowadź analizy kryminalistyczne poziomu hosta w poszukiwaniu nieautoryzowanych kluczy SSH, odwróconych powłok lub trwałych tuneli, które mogły być użyte do pivotingu.

Wykonanie Symulacji

• Narracja ataku i polecenia: Przeciwnik próbuje wykorzystać lukę w aplikacji webowej wymiany stanów. Aby wtopić się w ruch administracyjny, używają konkretnego nagłówka X-Requested-By: cli. Celują w punkt końcowy zarządzania sesją /api/system/sessions i próbują uruchomić złośliwy skrypt powłoki o nazwie fire3.sh. Obecność ciągu UXP Verifier w odpowiedzi jest znaną cechą charakterystyczną używanego przez tego aktora zagrożenia zestawu narzędzi. Celem jest uzyskanie wykonania zdalnego kodu za pomocą serwera webowego.

• Skrypt testu regresji:

  #!/bin/bash
  # Skrypt symulacji do wywołania reguły wykrycia
  # Symuluje żądanie, które pasuje do wszystkich czterech kryteriów wykrycia
  
  TARGET_URL="http://localhost/api/system/sessions"
  
  echo "[+] Symulowanie żądania ataku..."
  
  # Używamy curl, aby naśladować dokładne nagłówki i ścieżkę żądania.
  # Uwaga: Ponieważ nie możemy łatwo kontrolować 'ResponseBody' prawdziwego serwera 
  # bez gospodarza serwera makiety, ta symulacja zakłada, że logi są 
  # generowane przez serwer przechwytujący proxy lub makietową usługę webową, która 
  # zwraca 'UXP Verifier'.
  
  curl -X POST "$TARGET_URL" 
       -H "X-Requested-By: cli" 
       -H "Content-Type: application/json" 
       -d '{"filename": "fire3.sh", "payload": "echo "UXP Verifier""}' 
       --verbose
  
  echo "[+] Komenda symulacyjna wysłana."

• Polecenia czyszczenia:

  # Żadne trwałe zmiany nie zostały wprowadzone do systemu, ale jeśli serwer makiety został uruchomiony:
  # pkill -f "python3 -m http.server"
  echo "[+] Czyszczenie ukończone."