원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Nach den Nachrichten über einen Sicherheitsvorfall bleibt keine Zeit, um spät in der Nacht nur zu googeln. Im Mai 2026 wurde eine bösartige Visual Studio Code-Erweiterung verbreitet, wodurch Entwickler-Maschinen kompromittiert und rund 3.800 firmeninterne Quellcode-Repositories unverschlüsselt entwendet wurden. Wenn man in dieser Situation einfach blind den Code löscht oder den Laptop formatiert, gehen alle forensischen Beweise verloren und die Ursache kann nicht mehr ermittelt werden. Lassen Sie uns die Ausführungsprotokolle des Paketmanagers, die Zeitstempel globaler CLIs und die Berechtigungen laufender Prozesse direkt durchforsten, um zu überprüfen, ob ein Angriff stattgefunden hat.
Paketmanager hinterlassen während des Installationsprozesses Transaktionsaufzeichnungen im System-Cache-Verzeichnis. NPM gibt Debug-Logs im Ordner _logs innerhalb des Pfades von npm config get cache aus, während pnpm Artefakte in pnpm store path ablegt. Da bösartige Pakete Umgebungsvariablen oder Anmeldeinformationen über Skripte abgreifen, die im Moment der Installation ausgeführt werden, müssen als Erstes die Lifecycle-Ausführungsprotokolle überprüft werden.
Der folgende Befehl durchsucht die Protokolle der letzten 14 Tage, um das unbefugte Hinzufügen von Paketen oder die Ausführung externer Skripte aufzuspüren. Öffnen Sie das Terminal und führen Sie den Befehl unverändert aus.
`bash
NPM_CACHE_DIR=$(npm config get cache)
find $NPM_CACHE_DIR/_logs/ -type f -mtime -14 -exec grep -Hn "lifecycle" {} +
`
Überprüfen Sie im Ausgabebildschirm, ob nicht beabsichtigte preinstall- oder postinstall-Hooks ausgeführt wurden. Das dauert nur 3 Minuten. Wenn es keine Protokolle über verdächtige externe URL-Kommunikation gibt, können Sie vorerst aufatmen, was die Angst vor einer direkten Kontamination auf Paketebene betrifft.
Angreifer pflanzen bösartige Binärdateien in globale CLI-Tools oder den npx-Cache ein, um auf dem Laptop zu überleben. Listen Sie die global installierten Pakete auf und vergleichen Sie die Erstellungs- und Änderungsdaten der Binärordnerdateien mit den Systemprotokollen, um die Integrität zu überprüfen.
`bash
npm list -g --depth=0 --json
ls -lact $(npm config get prefix)/bin/
`
Wenn die Zeitpunkte der Änderungen mit ungewöhnlichen Zeitfenstern übereinstimmen, ermitteln Sie die Hash-Werte mit dem folgenden Befehl zum Abgleich:
`bash
shasum -a 256 $(npm config get prefix)/bin/
`
Paketskripten werden mit den Berechtigungen des Entwicklerkontos ausgeführt. Im Hintergrund laufende Daemon-Prozesse müssen gestoppt werden.
`bash
ps aux | grep -E "node|npm|pnpm|bun" | grep -v grep
lsof -i -P -n | grep -E "node|npm|pnpm"
`
Wenn ein verdächtiger Prozess mit einem externen C2-Server kommuniziert, stoppen Sie ihn sofort.
`bash
kill -9 [PID]
npm config set ignore-scripts true
`
Ein wiederkehrendes Muster bei Lieferkettenangriffen besteht darin, Konfigurationsdateien zu manipulieren, um die Registry zu kapern. Angreifer betten bösartige Mirror-Server-Adressen in die .npmrc-Datei eines Projekts oder in die globale Konfiguration ein. Da die Download-URL-Pfade innerhalb der Lock-Dateien ausgetauscht werden, um beim eigentlichen Installieren bösartige Tarballs herunterzuladen, müssen alle Konfigurationswerte gründlich durchsucht werden.
Das Verfahren zur Überprüfung, ob nicht autorisierte Overrides in der lokalen und globalen Konfiguration enthalten sind, sieht wie folgt aus. Listen Sie zunächst die Konfigurationsbindungen auf:
`bash
npm config list
pnpm config list
`
Überprüfen Sie als Nächstes, ob der unternehmensinterne Private-Registry-Scope korrekt gesetzt ist:
`bash
npm config get @company:registry
`
Suchen Sie außerdem direkt danach, ob externe Mirror-Adressen im Home-Verzeichnis des Benutzers und in den Konfigurationsdateien des Projektstamms hartcodiert sind.
`bash
grep -Rn "registry" ~/.npmrc ./.npmrc
`
Durch diese drei Schritte lässt sich innerhalb von 5 Minuten feststellen, ob eine verdächtige Mirror-Adresse registriert wurde.
Da die Dateien package-lock.json und pnpm-lock.yaml die ursprünglichen URLs für den Download von Abhängigkeiten aufzeichnen, müssen sie mit regulären Ausdrücken auf Kontaminationen untersucht werden:
`bash
grep -E '"resolved": "https?://' package-lock.json | grep -vE 'registry.npmjs.org|registry.corp.example'
`
Wenn Sie pnpm verwenden, geben Sie den folgenden Befehl ein:
`bash
grep -E 'resolution: {tarball:' pnpm-lock.yaml | grep -vE 'registry.npmjs.org|registry.corp.example'
`
Wenn eine kontaminierte Lock-Datei gefunden wird, muss sie vollständig gelöscht und neu erstellt werden:
`bash
rm -rf node_modules package-lock.json pnpm-lock.yaml
npm cache clean --force
pnpm store prune
npm config set registry https://registry.npmjs.org/
npm ci --ignore-scripts
`
Indem Sie die Ausführung von Lifecycle-Skripten ignorieren und den Abhängigkeitsbaum im unveränderlichen Zustand neu aufbauen, können Sie eine saubere Umgebung wiederherstellen.
Bösartige Binärdateien stehlen unter Linux- und Mac-Umgebungen den Passwortspeicher des Browsers und kratzen sämtliche in Umgebungsvariablen gespeicherten AI-API-Schlüssel, AWS Access Keys und SSH-Schlüssel zusammen. Sie müssen jetzt sofort überprüfen, ob Anmeldeinformationen in der Terminal-Umgebung offengelegt wurden.
`bash
ls -la ~/.ssh/
env | grep -E 'TOKEN|KEY|SECRET|AUTH|AWS|GITHUB|OPENAI|ANTHROPIC'
grep -E '(ghp_[A-Za-z0-9]{36}|AKIA[0-9A-Z]{16}|bearer)' ~/.zsh_history ~/.bash_history
`
Wenn im Klartext exponierte Schlüssel auftauchen, sehen Sie nicht darüber hinweg, sondern widerrufen Sie diese sofort. Überprüfen Sie auch den Token-Scope, mit dem Sie sich bei der GitHub CLI angemeldet haben.
`bash
gh auth status
`
Löschen Sie Classic-Tokens, die Zugriff auf alle Repositories gewähren, sofort. Wenn Sie ein PAT (Personal Access Token) neu erstellen, beschränken Sie es auf bestimmte Repositories und binden Sie es an den minimal erforderlichen Lesebereich.
Um den localhost und die Entwicklungsprozesse zu isolieren, sollte die DevContainer-Struktur verwendet werden. Erstellen Sie die Datei .devcontainer/devcontainer.json im Stammverzeichnis des Projekts und konfigurieren Sie das Image wie folgt:
`json
{
"image": "mcr.microsoft.com/devcontainers/javascript-node:22",
"postCreateCommand": "npm ci --ignore-scripts"
}
`
Wenn Sie den Container auf diese Weise starten, laufen die Paketinstallation und der Build vollständig isoliert von den System-Anmeldeinformationen des Laptops, wodurch potenzielle Abflusswege für unternehmensinterne Assets an der Quelle blockiert werden können.
