KI-unterstützte PaperCut-Angriffe decken zweiten RCE und weltweites Opfernnetzwerk auf

Zusammenfassung

Ein russischsprachiger Bedrohungsakteur führte eine gezielte Kampagne gegen die ukrainische Infrastruktur durch, wobei der Schwerpunkt auf dem Datenaustauschekosystem und Graylog-Logging-Servern lag. Der Angreifer nutzte eine Log4Shell-basierte JNDI-Injektionskette, um Remote-Code-Ausführung zu erreichen und Reverse Shells zu deployen. Obwohl mehrere Exploits gegen MikroTik- und Fortinet-Systeme versucht wurden, stützte sich der primäre erfolgreiche Zugriff auf eine wiederverwendbare CommonsBeanutils2-Deserialisierungskette.

Untersuchung

Die Untersuchung begann, nachdem Forscher ein auf einer öffentlichen IP-Adresse freigelegtes Operator-Staging-Verzeichnis für etwa 17 Stunden entdeckt hatten. Analysten stellten die Arbeitsdateien des Angreifers wieder her, darunter Exploit-Skripte, Payload-Builder, Shell-Historie und Aufklärungsausgabe. Diese Exposition machte es möglich, die gesamte Angriffskette zu rekonstruieren, von der anfänglichen Masscan-Aufklärung bis zur erfolgreichen Code-Ausführung auf Graylog-Instanzen.

Abschwächung

Organisationen sollten die Patching von Graylog-Deployments priorisieren und sicherstellen, dass JNDI-Nachschläge deaktiviert oder durch angemessene Java-Sicherheitskontrollen stark eingeschränkt sind. Strikte Egress-Filterung sollte durchgesetzt werden, um unbefugte LDAP- und RMI-Verbindungen von Anwendungsservern zu blockieren. Sicherheitsteams sollten auch ungewöhnliche Kindprozesse überwachen, die von Java-basierten Diensten gestartet werden, und CSRF-Schutzmaßnahmen auf sensiblen API-Endpunkten durchsetzen.

Reaktion

Wenn verdächtige JNDI-Aktivitäten oder unerwartete Kindprozesse, die von Webdiensten stammen, erkannt werden, isolieren Sie den betroffenen Host sofort. Überprüfen Sie Anwendungsprotokolle auf erfolgreiche Exploit-Muster, insbesondere mit Augenmerk auf den /api/system/sessions Endpunkt. Führen Sie eine Host-Level-Forensikanalyse auf unbefugte SSH-Schlüssel, Reverse Shells oder persistente Tunnel durch, die möglicherweise zum Pivoting verwendet wurden.

Simulationsausführung

• Angriffserzählung & Befehle: Der Gegner versucht, eine Schwachstelle in einer staatlichen Webanwendung zum Austausch auszunutzen. Um sich mit dem Administrationsverkehr zu vermischen, verwenden sie einen bestimmten Header X-Requested-By: cli. Sie zielen auf den Sitzungsverwaltungsendpunkt /api/system/sessions und versuchen, die Ausführung eines bösartigen Shell-Skripts namens fire3.shauszulösen. Das Vorhandensein des UXP Verifier Strings in der Antwort ist ein bekanntes Merkmal des spezifischen Toolkits, das von diesem Bedrohungsakteur verwendet wird. Das Ziel ist es, Remote-Code-Ausführung über den Webserver zu erlangen.

• Regressionstestskript:

  #!/bin/bash
  # Simulationsskript, um die Erkennungsregel auszulösen
  # Dies simuliert eine Anfrage, die alle vier Erkennungskriterien erfüllt
  
  TARGET_URL="http://localhost/api/system/sessions"
  
  echo "[+] Zielgerichtete Angriffsanfrage simulieren..."
  
  # Wir verwenden curl, um die genauen Header und den Anforderungspfad nachzuahmen.
  # Hinweis: Da wir den 'ResponseBody' eines echten Servers nicht leicht kontrollieren können 
  # ohne einen Mock-Server zu hosten, geht diese Simulation davon aus, dass die Logs 
  # von einem abfangenden Proxy oder einem Mock-Webdienst erzeugt werden, der 
  # "UXP Verifier" zurückgibt. 
  
  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 "[+] Simulationsbefehl gesendet."

• Bereinigungskommandos:

  # Keine dauerhaften Änderungen am System vorgenommen, aber wenn ein Mock-Server gestartet wurde:
  # pkill -f "python3 -m http.server"
  echo "[+] Bereinigung abgeschlossen."