42 Waffensysteme GitHub-Repositories enthüllen einen verborgenen npm-Herausgeber

Zusammenfassung

Eine raffinierte Kampagne, die verfolgt wird als testmetest verwendet bösartige npm-Pakete und kompromittierte GitHub-Repositories, um Anmeldeinformationen zu stehlen und automatisierte bösartige Paketveröffentlichungen durchzuführen. Die Angreifer verlassen sich auf polymorphe Wrapper, native Node.js-Addons und verschlüsselte Payloads, um der Erkennung zu entgehen. Die Kampagne umfasst auch Infrastruktur, die zum Scannen und Ausnutzen von Schwachstellen in cPanel verwendet wird.

Untersuchung

JFrog Security-Forscher identifizierten 42 bewaffnete GitHub-Repositories zusammen mit mehreren bösartigen npm-Paketen. Sie stellten fest, dass die Angreifer eine native Addon-Tarnungstechnik verwendeten, bei der eine kompilierte .node -Datei zur Laufzeit eine versteckte Payload entschlüsselt. Die Untersuchung verband die Aktivität auch mit Shellpanel Scannern, die cPanel-Systeme über CVE-2026-41940 anvisieren.

Minderung

Benutzer sollten die identifizierten bösartigen npm-Pakete entfernen und betroffene Systeme aus vertrauenswürdigen Quellen neu aufbauen. Organisationen müssen alle potenziell kompromittierten Anmeldeinformationen, einschließlich GitHub-, npm- und Cloud-Tokens, austauschen. Es ist auch wichtig, Repositories auf unautorisierte Konfigurationsdateien wie .github/init.js zu überprüfen und unerwartete Ausführungshooks in package.json -Dateien oder Makefiles zu untersuchen.

Reaktion

Wenn bösartige Aktivitäten entdeckt werden, sollten exponierte Geheimnisse widerrufen und Anmeldeinformationen sofort ausgetauscht werden. Suchen Sie nach Persistenzmechanismen wie net-health-checker or pkg-runtime. Überprüfen Sie die GitHub Actions-Protokolle auf unautorisierte Workflows und überwachen Sie Systeme auf entschlüsselte Payloads, die in temporäre Verzeichnisse geschrieben wurden.

Simulation Execution

• Angriffserzählung & Befehle: Der Angreifer hat erfolgreich eine bösartige JavaScript-Payload im temporären Verzeichnis des Benutzers abgelegt und sie benannt .nc um möglicherweise eine Netcat-bezogene Datei zu imitieren oder einfach ihren Zweck zu verschleiern. Um dies auszuführen, verwendet der Angreifer einen Loader, der den CreateProcessA Win32 API verwendet, um den Windows Script Host (wscript.exe) mit der temporären Datei als Argument zu starten. Diese spezielle Sequenz—die ANSI-Version der Prozess-Erstellungs-API zu verwenden, um ein Skript von %TEMP%—ist genau das Muster, das die Erkennungsregel abfangen soll.

• Regression Test Script:

   # Simulationsskript: Auslösen von 'Verdächtige Prozesserstellung und temporäre JS-Dateiausführung'
  
    # 1. Pfade definieren
    $tempPath = $env:TEMP
    $targetFile = Join-Path $tempPath ".nc"
  
    # 2. Erstellen einer Dummy-bösartigen JS-Datei im %TEMP%-Verzeichnis
    # Hinweis: Wir benennen sie .nc gemäß der Anforderung der Erkennung
    "WScript.Echo('Simulierte bösartige Aktivität');" | Out-File -FilePath $targetFile -Encoding ascii
  
    Write-Host "[+] Bösartige Datei erstellt unter: $targetFile"
  
    # 3. Simulation der Ausführung über wscript.exe
    # In einem realen Szenario wird der 'CallTrace', der 'CreateProcessA' enthält, 
    # von dem zugrunde liegenden Windows API-Aufruf generiert, der vom Malware-Loader verwendet wird.
    # Das Ausführen über PowerShell/CMD erzeugt das Prozesserstellungsereignis.
    Write-Host "[+] Ausführungsbefehl zur Erkennung ausgelöst..."
    Start-Process "wscript.exe" -ArgumentList "`"$targetFile`""
  
    Write-Host "[+] Simulationsbefehl gesendet."

• Bereinigungskommandos:

   # Bereinigungsskript: Entfernen von Simulationsartefakten
    $tempPath = $env:TEMP
    $targetFile = Join-Path $tempPath ".nc"
  
    if (Test-Path $targetFile) {
        Remove-Item -Path $targetFile -Force
        Write-Host "[+] Bereinigung erfolgreich: $targetFile entfernt."
    } else {
        Write-Host "[!] Bereinigung fehlgeschlagen: Datei nicht gefunden."
    }