--- title: "Astro vor Supply-Chain-Angriffen schützen: Teil 1 – Shai-Hulud 2.0 verstehen und sofort reagieren" description: "Erfahren Sie mehr über den Shai-Hulud-2.0-npm-Supply-Chain-Angriff, der über 700 Pakete kompromittiert hat. Prüfen Sie, ob Ihr Astro-Projekt betroffen ist, und ergreifen Sie sofort Maßnahmen, um Ihre Umgebung abzusichern." source: "https://www.launchfa.st/de/blog/protect-astro-supply-chain-attacks-part-1" author: "Rishi Raj Jain" created_at: 2025-11-30T12:00:00.000Z --- > **Site index for agents** > Fetch https://www.launchfa.st/llms.txt to discover every page on this site. > Every page is also available as Markdown by appending `.md` to its URL. Protecting Astro from Supply Chain Attacks Part 1 > **Dies ist Teil 1 einer zweiteiligen Serie** zum Schutz von Astro-Websites vor npm-Supply-Chain-Angriffen. In diesem Artikel geht es um das Verständnis der Bedrohung und unmittelbare Reaktionsmaßnahmen. In [Teil 2](/blog/protect-astro-supply-chain-attacks-part-2) finden Sie langfristige Sicherheitsmaßnahmen, Monitoring und Best Practices. Im November 2025 erlebte das npm-Ökosystem einen der bislang gravierendsten Supply-Chain-Angriffe: **Shai-Hulud 2.0**. Der Angriff kompromittierte über 700 npm-Pakete, darunter beliebte Bibliotheken von Zapier, PostHog und Postman, und betraf rund 27 % der Cloud- und Code-Umgebungen. Die Malware wurde während der `preinstall`-Phase ausgeführt, stahl Zugangsdaten von GitHub, AWS, GCP, Azure und anderen Diensten und exfiltrierte sie in öffentliche Repositories. Laut [Wiz Research](https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack) wurden über 25.000 bösartige Repositories mit gestohlenen Secrets angelegt; während des Angriffs tauchten neue Repos im Rhythmus von etwa 1.000 alle 30 Minuten auf. Wenn Sie eine Astro-Website betreiben, hilft Ihnen dieser Leitfaden, die Bedrohung zu verstehen und sofort zu handeln. ## Voraussetzungen Sie benötigen Folgendes: - [Node.j 20](https://nodejs.org/en/blog/announcements/v20-release-announce) oder höher - Ein bestehendes Astro-Projekt - Zugriff auf Ihre CI/CD-Pipeline-Konfiguration - Administratorzugriff auf Ihren Paketmanager (npm, pnpm oder yarn) ## 1. Den Shai-Hulud-2.0-Angriff verstehen Beim Shai-Hulud-2.0-Angriff nutzten Angreifer kompromittierte Maintainer-Konten, um trojanisierte Versionen legitimer npm-Pakete zu veröffentlichen. Es handelte sich nicht um eine neue Zero-Day-Schwachstelle oder einen ausgeklügelten Exploit – sondern um die Kompromittierung vertrauenswürdiger Konten, die es den Angreifern ermöglichte, bösartigen Code unter dem Deckmantel legitimer Updates zu veröffentlichen. ### 1.1 Was macht diesen Angriff anders? Im Gegensatz zu traditionellen Angriffen wies diese Variante mehrere besorgniserregende Merkmale auf: #### 1.1.1 Ausführung während der `preinstall`-Phase Die Malware lief während des `preinstall`-Lifecycle-Hooks, was den Schaden erheblich ausweitet. Das bedeutet: - Sie wird ausgeführt, bevor die Paketinstallation abgeschlossen ist - Sie läuft auf Entwicklerrechnern während `npm install` - Sie wird automatisch in CI/CD-Pipelines ausgeführt - Sie lässt sich nicht leicht durch typische Sicherheitsmaßnahmen verhindern ```json // Example of how the malicious package.json looked { "scripts": { "preinstall": "node malicious-script.js" } } ``` #### 1.1.2 Diebstahl verschiedener Credential-Typen Der Angriff beschränkte sich nicht auf einen einzelnen Credential-Typ. Er suchte aktiv nach und exfiltrierte: - **GitHub-Tokens**: Personal Access Tokens, OAuth-Tokens und Deploy Keys - **AWS-Zugangsdaten**: Langzeit-Zugangsschlüssel (AKIA-Format), Secret Keys und Session Tokens - **GCP-Zugangsdaten**: Service-Account-Keys und Anwendungs-Credentials - **Azure-Zugangsdaten**: Service-Principal-Credentials und Storage Keys - **Umgebungsvariablen**: Alle Secrets in `.env`-Dateien oder der Umgebung #### 1.1.3 Cross-Victim-Exfiltration Einer der heimtückischsten Aspekte: Ihre gestohlenen Daten erscheinen möglicherweise gar nicht in Ihrem eigenen GitHub-Konto: ```typescript // Simplified example of the exfiltration logic const victims = getRandomVictimAccounts() const stolenData = gatherCredentials() // Upload to ANOTHER victim's account uploadToGitHub(victims[randomIndex], stolenData) ``` Das bedeutet: - Ihre Secrets könnten in einem fremden öffentlichen Repository liegen - Secrets anderer Opfer könnten in Ihrem Konto auftauchen - Die Erkennung ist deutlich schwieriger - Der Schaden ist viel größer als zunächst sichtbar #### 1.1.4 Backdoor-Workflows Die Malware versuchte, bösartige GitHub-Actions-Workflows für persistenten Zugriff einzuschleusen: ```yaml # Example of injected .github/workflows/discussion.yaml name: Discussion Update on: push: schedule: - cron: '0 */6 * * *' jobs: exfiltrate: runs-on: ubuntu-latest steps: - name: Gather More Secrets run: | # Malicious code here ``` #### 1.1.5 Betroffene weit verbreitete Pakete Der Angriff zielte auf Pakete ab, die im Ökosystem weit verbreitet sind: - `@postman/tunnel-agent` – in 27 % der Umgebungen gefunden - `posthog-node` – in 25 % der Umgebungen gefunden - `@asyncapi/specs` – in 20 % der Umgebungen gefunden - Verschiedene Zapier-Platform-Pakete Das maximierte die Reichweite des Angriffs und konnte Tausende Projekte sofort betreffen. ### 1.2 Angriffszeitplan und Auswirkungen Folgendes ist über den Verlauf des Angriffs bekannt: - **21.–23. November 2025**: Erste Kompromittierung und Upload trojanisierter Pakete auf npm - **24. November 2025 (01:22 UTC)**: Früheste Hinweise auf GitHub-Repositories mit geleakten Secrets - **24. November 2025 (~03:00 UTC)**: Früheste Hinweise auf bösartige Paketversionen auf npm - **25. November 2025 (22:45 UTC)**: Mögliche zweite Phase mit Veröffentlichung privater Repositories beobachtet - **26. November 2025**: GitHub beginnt mit Gegenmaßnahmen durch Token-Widerruf und Privatisierung bösartiger Repositories **Auswirkungen in Zahlen**: - ~700 kompromittierte Pakete auf npm - 25.000+ bösartige Repositories angelegt - ~500 betroffene GitHub-Nutzer - 775+ kompromittierte GitHub-Access-Tokens (verifiziert) - 373+ geleakte AWS-Zugangsdaten - 300+ exponierte GCP-Zugangsdaten - 115+ kompromittierte Azure-Zugangsdaten Die Malware erzeugt spezifische Indikator-Dateien: ```bash cloud.json # Cloud provider credentials contents.json # Repository contents and code environment.json # Environment variables and secrets truffleSecrets.json # Secrets detected by TruffleHog patterns bun_environment.js # Bun runtime environment data setup_bun.js # Setup script for persistence ``` ## 2. Sofortmaßnahmen Wenn Sie vermuten, dass Ihr Astro-Projekt betroffen sein könnte, folgen Sie diesen Schritten unverzüglich. Zeit ist entscheidend – je länger kompromittierte Zugangsdaten aktiv bleiben, desto größer der Schaden. ### 2.1 Abhängigkeiten prüfen Prüfen Sie zuerst, ob kompromittierte Pakete in Ihrem Abhängigkeitsbaum vorkommen. #### 2.1.1 Schnellcheck mit pnpm Audit ```bash # Run a security audit pnpm audit fix # Or with npm npm audit --audit-level=moderate ``` #### 2.1.2 Manuelle Inspektion Überprüfen Sie `package.json` und Lock-Dateien auf Hochrisiko-Pakete: ```bash # Check for specific compromised packages grep -E "@postman/tunnel-agent|posthog-node|posthog-js|@asyncapi/specs|zapier-platform" package.json pnpm-lock.yaml ``` #### 2.1.3 Bekannte kompromittierte Pakete (Auszug) Hier einige der am weitesten verbreiteten betroffenen Pakete: ```json { "high-prevalence-packages": [ "@postman/tunnel-agent", "posthog-node", "posthog-js", "@asyncapi/specs", "@asyncapi/openapi-schema-parser", "zapier-platform-cli", "zapier-platform-core", "zapier-platform-schema", "zapier-async-storage", "get-them-args", "shell-exec", "kill-port" ] } ``` #### 2.1.4 Transitive Abhängigkeiten prüfen Kompromittierte Pakete sind möglicherweise keine direkten Abhängigkeiten. Prüfen Sie den gesamten Abhängigkeitsbaum: ```bash # For pnpm pnpm list --depth=Infinity | grep -E "postman|posthog|zapier" # For npm npm list --all | grep -E "postman|posthog|zapier" ``` #### 2.1.5 Installationsverlauf prüfen Prüfen Sie, wann Pakete zuletzt installiert wurden, um das Expositionsfenster einzugrenzen: ```bash # Check git history of lock file changes git log -p --follow pnpm-lock.yaml | grep -A 5 -B 5 "postman\|posthog\|zapier" ``` ### 2.2 Umgebung auditieren Suchen Sie in Ihrer lokalen Entwicklungsumgebung und in CI/CD-Systemen nach Anzeichen einer Kompromittierung. #### 2.2.1 Nach bösartigen Dateien scannen ```bash # Check for known malware indicator files find . -type f \( \ -name "cloud.json" -o \ -name "contents.json" -o \ -name "environment.json" -o \ -name "truffleSecrets.json" -o \ -name "bun_environment.js" -o \ -name "setup_bun.js" \ \) 2>/dev/null ``` Wenn dieser Befehl Ergebnisse liefert, **wurde Ihre Umgebung kompromittiert**. #### 2.2.2 GitHub-Workflows prüfen ```bash # List all workflow files ls -la .github/workflows/ # Check for the known malicious workflow cat .github/workflows/discussion.yaml 2>/dev/null ``` Der bösartige Workflow weist typischerweise auf: - Name: „Discussion Update“ oder ähnlich - Verdächtige Cron-Zeitpläne - Ungewöhnlichen Zugriff auf Umgebungsvariablen - Base64-kodierte Befehle #### 2.2.3 Git-Historie auf unautorisierte Änderungen prüfen ```bash # Check recent commits for suspicious changes git log --all --oneline --decorate --graph -n 20 # Look for unexpected workflow additions git log --all --full-history -- .github/workflows/ ``` #### 2.2.4 GitHub-Repositories prüfen Melden Sie sich bei GitHub an und prüfen Sie: - Unerwartete öffentliche Repositories in Ihrem Konto - Repositories mit Namen, die geleakte Daten oder Credentials enthalten - Repository-Beschreibungen mit „Shai-Hulud“ oder verdächtigem Inhalt - Neu angelegte Repositories, die Sie nicht erstellt haben #### 2.2.5 CI/CD-Logs prüfen Prüfen Sie Ihre CI/CD-Pipeline-Logs auf: - Unerwartete Netzwerkverbindungen während Builds - Fehlgeschlagene Authentifizierungsversuche - Ungewöhnliche Paketinstallationen - Längere Build-Dauer (Malware-Ausführung braucht Zeit) ```bash # Example: Check GitHub Actions logs gh run list --limit 20 gh run view --log ``` ### 2.3 Alle Zugangsdaten rotieren Wenn Sie kompromittierte Pakete oder verdächtige Dateien gefunden haben, **rotieren Sie sofort alle Zugangsdaten**. Warten Sie nicht, bis das volle Ausmaß der Kompromittierung bestätigt ist. #### 2.3.1 GitHub-Tokens 1. Gehen Sie zu GitHub Settings → Developer settings → [Personal access tokens](https://github.com/settings/tokens) 2. Prüfen Sie alle vorhandenen Tokens: - Notieren Sie, wofür jedes Token verwendet wird - Prüfen Sie das Datum der letzten Nutzung 3. **Widerrufen Sie ALLE Tokens** (auch wenn sie harmlos erscheinen) 4. Erstellen Sie neue Tokens mit minimal erforderlichen Berechtigungen: ```bash # Use the principle of least privilege # Instead of: # - repo (full control) # Use: # - repo:status (read-only) # - public_repo (if possible) ``` 5. Aktualisieren Sie Tokens in: - CI/CD-Secrets (GitHub Actions, CircleCI usw.) - Lokale Entwicklungsumgebungen - Automatisierungsskripte - Drittanbieter-Integrationen #### 2.3.2 AWS-Zugangsdaten Rotieren Sie AWS-Access-Keys sofort: ```bash # 1. List current access keys aws iam list-access-keys --user-name your-username # 2. Create new access keys FIRST aws iam create-access-key --user-name your-username # Save the output immediately - you won't see it again # 3. Update the new keys everywhere they're used: # - CI/CD secrets # - ~/.aws/credentials # - Environment variables # - Application configuration # 4. Test that new keys work aws sts get-caller-identity # 5. Delete old access keys aws iam delete-access-key \ --access-key-id AKIA_OLD_KEY_ID \ --user-name your-username ``` #### 2.3.3 Wichtige AWS-Sicherheitsschritte ```bash # Check CloudTrail for unauthorized activity aws cloudtrail lookup-events \ --lookup-attributes AttributeKey=Username,AttributeValue=your-username \ --max-items 100 \ --start-time 2025-11-20T00:00:00Z # Review recent S3 bucket access aws s3api get-bucket-logging --bucket your-bucket-name # Check for unauthorized IAM changes aws iam get-credential-report ``` #### 2.3.4 GCP-Zugangsdaten Für Google Cloud Platform: ```bash # List service accounts gcloud iam service-accounts list # Create new key for a service account gcloud iam service-accounts keys create new-key.json \ --iam-account=sa-name@project-id.iam.gserviceaccount.com # List all keys for a service account gcloud iam service-accounts keys list \ --iam-account=sa-name@project-id.iam.gserviceaccount.com # Delete old keys gcloud iam service-accounts keys delete KEY_ID \ --iam-account=sa-name@project-id.iam.gserviceaccount.com ``` #### 2.3.5 Azure-Zugangsdaten Für Microsoft Azure: ```bash # List service principals az ad sp list --show-mine # Reset service principal credentials az ad sp credential reset \ --id \ --append # Create new client secret az ad sp credential reset \ --id \ --credential-description "New secret after Shai-Hulud" ``` #### 2.3.6 Datenbank-Zugangsdaten Vergessen Sie nicht, Datenbank-Credentials zu rotieren: ```bash # Example for PostgreSQL # Connect to your database psql -U admin -d postgres # Create new user with same privileges CREATE USER newuser WITH PASSWORD 'strong-new-password'; GRANT ALL PRIVILEGES ON DATABASE yourdb TO newuser; # Update application configuration # Test thoroughly # Then remove old user DROP USER olduser; ``` #### 2.3.7 Umgebungsvariablen und Secrets Aktualisieren Sie alle Umgebungs-Secrets: ```typescript // File: scripts/rotate-env-secrets.ts import crypto from 'crypto' const generateSecureSecret = (length: number = 32): string => { return crypto.randomBytes(length).toString('hex') } console.log('🔐 New secrets generated:\n') console.log(`SESSION_SECRET=${generateSecureSecret(64)}`) console.log(`API_SECRET=${generateSecureSecret(32)}`) console.log(`ENCRYPTION_KEY=${generateSecureSecret(32)}`) console.log(`JWT_SECRET=${generateSecureSecret(64)}`) console.log('\n⚠️ Update these in:') console.log(' - Vercel/Netlify/hosting platform') console.log(' - GitHub repository secrets') console.log(' - Local .env files') console.log(' - Team password manager') ``` ## Nächste Schritte Sie haben wichtige erste Schritte unternommen, um Ihr Astro-Projekt abzusichern. Der Schutz vor Supply-Chain-Angriffen erfordert jedoch dauerhafte Wachsamkeit und robuste Sicherheitspraktiken. In **[Teil 2](/blog/protect-astro-supply-chain-attacks-part-2)** geht es um langfristige Prävention (Dependency-Locking, Integritätsprüfungen, CI/CD-Härtung), Dependency-Isolation, Secret-Management, automatisierte Scans und Monitoring. ## Fazit Der Shai-Hulud-2.0-Angriff erinnert eindringlich daran, dass Supply-Chain-Sicherheit keine Option ist – sie ist ein kritischer Bestandteil moderner Webentwicklung. Die Sofortmaßnahmen in diesem Artikel sind nur die erste Verteidigungslinie. Bei Fragen oder Anmerkungen erreichen Sie mich gerne auf [Twitter](https://twitter.com/direct_messages/create/rishi_raj_jain_).