Supply-Chain-Angriff auf Axios bezieht bösartige Abhängigkeit von NPM

Zusammenfassung

Ein böswilliges npm-Paket, plain-crypto-js@4.2.1, wurde veröffentlicht und später als transitive Abhängigkeit durch kompromittierte Veröffentlichungen des weit verbreiteten JavaScript-HTTP-Clients Axios eingebunden. Das Paket verwendet ein Post-Installationsskript, um einen mehrstufigen Remote-Access-Trojaner bereitzustellen, der auf Windows, macOS und Linux abzielt. Der Angriff scheint auf langlebigen npm-Token zu beruhen, die es den Bedrohungsakteuren ermöglichen, böswillige Versionen außerhalb des üblichen Veröffentlichungsworkflows des Projekts zu verbreiten. Das frühzeitige Erkennen der manipulierten Abhängigkeit kann den RAT stoppen, bevor er auf betroffenen Systemen ausgeführt wird.

Untersuchung

Socket Research führte eine statische Analyse des setup.js -Droppers durch und entschlüsselte kodierte Zeichenfolgen, um die C2-Domain, die Logik der Payload-Lieferung und die angezielten Dateisystempfade aufzudecken. Die Forscher identifizierten drei kompromittierte Axios-Versionen und zwei zusätzliche npm-Pakete, die denselben böswilligen Code enthielten. Sie extrahierten auch Netzwerkindikatoren, Datei-Pfade und User-Agent-Zeichenfolgen, die für die Erkennungserstellung und Regelgenerierung verwendet werden können.

Abschwächung

Organisationen sollten alle langlebigen npm-Token widerrufen und Anmeldeinformationen für alle potenziell betroffenen Konten ändern. Kompromittierte Axios-Versionen und jegliche Pakete, die von plain-crypto-js@4.2.1 abhängig sind, sollten sofort entfernt oder zurückgestuft werden. Teams sollten auch Lockfiles, CI/CD-Pipelines und Sicherheitskontrollen der Softwarelieferkette überprüfen, um unautorisierte Veröffentlichungstätigkeiten zu identifizieren und die Wahrscheinlichkeit zukünftiger Paketkompromittierungen zu verringern.

Reaktion

Sicherheitsteams sollten npm-Installationsprotokolle auf Verweise auf plain-crypto-js@4.2.1 und die betroffenen Axios-Versionen überwachen. Erkennungsregeln sollten für die Ausführung des Postinstall-Hooks, den Netzwerkzugang zu sfrclak.comund die bösartige User-Agent-Zeichenfolge erstellt werden. Wenn eine Kompromittierung bestätigt wird, sollten betroffene Systeme isoliert, flüchtiger Speicher zur Analyse gesammelt und der Host neu erstellt werden, wenn der RAT gefunden wird.

Simulation Ausführung

Voraussetzung: Der Telemetrie- und Basislinientest muss bestanden worden sein.

Begründung: Dieser Abschnitt beschreibt die präzise Ausführung der Adversary-Technik (TTP), die darauf ausgelegt ist, die Erkennungsregel auszulösen. Die Befehle und Erzählungen MÜSSEN direkt die identifizierten TTPs widerspiegeln und darauf abzielen, die genaue Telemetrie zu erzeugen, die von der Erkennungslogik erwartet wird.

• Angriffs-Narrativ & Befehle:

  Ein Angreifer, der begrenzte Benutzerrechte auf einer kompromittierten Arbeitsstation erlangt hat, möchte eine bösartige VBScript-Payload über ein legitimes npm-Paket (Lieferketten-Szenario) herunterladen. Um generischen PowerShell-Erkennung auszuweichen, kopiert der Angreifer powershell.exe in eine neue Datei namens powershell_renamed.exe hält aber die Zeichenfolge „powershell“ im Dateinamen bei (sodass der Image|contains Check immer noch übereinstimmt). Der Angreifer führt dann eine “where powershell”-Abfrage aus, um den Pfad des umbenannten Binärdatei zu ermitteln und startet schließlich die VBScript-Payload mit cscript //nologo um das Logo-Banner zu unterdrücken.

• Regressionstest-Skript:

  # -------------------------------------------------
  # Schritt 1: Erstellen einer umbenannten Kopie von powershell.exe
  # -------------------------------------------------
  $src = "$env:SystemRootSystem32WindowsPowerShellv1.0powershell.exe"
  $dst = "$env:Temppowershell_renamed.exe"
  Copy-Item -Path $src -Destination $dst -Force
  
  # -------------------------------------------------
  # Schritt 2: Verwenden von 'where', um auf die umbenannte Binärdatei zu verweisen
  # -------------------------------------------------
  $whereOutput = & where.exe powershell_renamed
  Write-Host "Umbenannte PowerShell gefunden unter: $whereOutput"
  
  # -------------------------------------------------
  # Schritt 3: Erstellen einer einfachen bösartigen VBScript-Payload
  # -------------------------------------------------
  $vbsPath = "$env:Tempmalicious.vbs"
  @"
  Set objShell = CreateObject("WScript.Shell")
  objShell.Run "cmd.exe /c echo pwned > $env:Temppwned.txt", 0, False
  "@ | Set-Content -Path $vbsPath -Encoding ASCII
  
  # -------------------------------------------------
  # Schritt 4: Ausführen des VBScript still mit cscript //nologo
  # -------------------------------------------------
  & $dst -Command "cscript //nologo `"$vbsPath`""
  # -------------------------------------------------
  # Ende der Simulation
  # -------------------------------------------------

• Bereinigungskommandos:

  # Entfernen der umbenannten PowerShell-Binärdatei
  Remove-Item -Path "$env:Temppowershell_renamed.exe" -Force -ErrorAction SilentlyContinue
  
  # Löschen der bösartigen VBScript-Datei
  Remove-Item -Path "$env:Tempmalicious.vbs" -Force -ErrorAction SilentlyContinue
  
  # Entfernen von Beweisen für die Ausführung
  Remove-Item -Path "$env:Temppwned.txt" -Force -ErrorAction SilentlyContinue