Ein potenzieller Kunde versuchte, über die integrierten Git-Hooks entfernten Code auszuführen.

SToFU Systems · Vorfallsanalyse · 20. Oktober 2026

Inhalt

1. Es begann mit einer Entwicklungsanfrage
2. Herunterladen und Untersuchen der Dateien
3. Wie der Git-Hook post-checkout ausgeführt werden konnte
4. Was der Downloader im Git-Hook tut
5. War im Archiv eine Anwendung versteckt?
6. Was der Download-Server zurückgab
7. Könnte dies ein legitimes Hilfsprogramm gewesen sein?
8. Ein unbekanntes Git-Repository prüfen
9. Nach der Archivprüfung
10. Korrespondenz und Belegdateien

Es begann mit einer Entwicklungsanfrage

Die erste Nachricht ging am 15. Oktober 2026 über unsere Website ein. Der Absender suchte Unterstützung beim Aufbau einer Plattform zur Erkennung von Finanzbetrug. Das vorgeschlagene System sollte Transaktionsrisiken bewerten und Verhaltensanalysen nutzen; Blockchain-Verifizierung und Berichterstattung gehörten zu den weiteren Anforderungen.

Am 19. Oktober erhielten wir den Download-Link. Die begleitende E-Mail verwies uns für die Architektur auf den Branch conf und für die Vereinbarung auf den Branch NDA. Sie wiederholte die Bitte, die Geheimhaltungsvereinbarung zu prüfen und zu unterzeichnen.

Please review the project materials and review and sign the NDA in the NDA branch.

Wer diesen Anweisungen folgte, würde nach dem Entpacken des Archivs in Git den Branch wechseln. Die E-Mail stellte beide Vorgänge als Teil der Lektüre der Dokumentation dar. Von der Ausführung eines heruntergeladenen Programms war darin keine Rede.

Die E-Mail mit dem Projektarchiv und den Anweisungen zum Öffnen des NDA-Branches. Identifizierende Angaben sind mit grauen Rechtecken abgedeckt.

Herunterladen und Untersuchen der Dateien

Der Link führte auf eine gewöhnliche Dropbox-Seite zur Dateifreigabe. Wir luden AI-Fraud-Detection_Blockchain.tar.gz in eine isolierte Prüfumgebung herunter und bewahrten das ursprüngliche Archiv als Referenz auf. Die konkrete Freigabe-URL wird hier nicht veröffentlicht.

Wir listeten den Archivinhalt auf und lasen die mitgelieferten Git-Objekte direkt. So konnten wir die Dokumente aus allen drei Branches wiederherstellen, ohne einen Branch auszuchecken oder den mitgelieferten Code auszuführen. In den Verzeichnisbäumen der Branches fanden wir 15 Markdown-Dateien und ein Word-Dokument.

Branch	Dateien	Unsere Funde
master	8 Markdown-Dateien	Eine README-Datei, eine Projektübersicht, Produktanforderungen und geschäftliche Anwendungsfälle. Weitere Dokumente behandelten Leistung, Sicherheit, Tests und Betrieb.
conf	7 Markdown-Dateien	Leitlinien für ein Entwicklungsangebot, Blockchain-Architektur und -Integration, Anforderungen an Smart Contracts, Daten- und API-Design, eine KI-Risiko-Engine und Liefermeilensteine.
NDA	1 DOCX-Datei	Eine Vertraulichkeitsvereinbarung mit einem Unterschriftsblock und Vorlagenplatzhaltern.

Das vorgeschlagene Produkt kombinierte Transaktionsanalyse, Betrugsregeln und Bewertungen durch maschinelles Lernen mit Blockchain-Verifizierung. Der vorgeschlagene Technologie-Stack umfasste Node.js und TypeScript mit Express, PostgreSQL, Python-Bibliotheken für maschinelles Lernen und Ethereum. Das Lieferdokument sah sechs Meilensteine über 24 Wochen vor. In allen mitgelieferten Verzeichnisbäumen fanden wir Planungsdokumente, jedoch keine Anwendungsimplementierung, kein trainiertes Modell und keinen Smart-Contract-Quellcode zur Prüfung.

Einige Einzelheiten verdienten einen zweiten Blick. Die API-Beispiele enthielten in Endpunktpfaden die wörtlichen Zeichenfolgen <built-in function id> und <built-in function hash>. Die Geheimhaltungsvereinbarung enthielt noch Vorlagenplatzhalter. Diese Unstimmigkeiten warfen Fragen dazu auf, wie sorgfältig das Material vorbereitet worden war.

Die ausführbare Datei .git/hooks/post-checkout war ein schwerwiegenderer Fund. Ihre Kommentare beschrieben ein Hilfsprogramm für Browser- oder Erweiterungsupdates, das keinen erkennbaren Bezug zur Prüfung dieses Projekts hatte. Beim Lesen des Skripts fanden wir Anweisungen zum Herunterladen eines externen Programms und zu dessen Start im Hintergrund. Die Aufforderung in der E-Mail, den Branch zu wechseln, konnte Prüfer beim Versuch, die Geheimhaltungsvereinbarung zu lesen, zu diesem Ausführungspfad führen.

Wir ließen das Repository inaktiv und untersuchten den Hook als Text. Die relevanten Archivmetadaten und das Verhalten des Skripts folgen unten.

Wie der Git-Hook post-checkout ausgeführt werden konnte

Die Datei AI-Fraud-Detection_Blockchain.tar.gz ist 779,429 Bytes lang. Ihre 100 TAR-Einträge umfassen 60 reguläre Dateien. Mit den Dokumenten wurde ein vollständiges .git-Verzeichnis geliefert.

Das Hooks-Verzeichnis enthielt die üblichen .sample-Dateien und eine ausführbare Datei namens post-checkout.

AI-Fraud-Detection_Blockchain/.git/hooks/post-checkout

Es gibt kein Suffix .sample. Der TAR-Modus lautet 0777 und umfasst Ausführungsrechte; die Datei ist 2,774 Bytes lang.

Git ruft post-checkout nach der Aktualisierung des Arbeitsbaums durch Vorgänge wie checkout oder switch auf, sofern die Umgebung die Ausführung des Hooks zulässt. Die Git-Dokumentation beschreibt den Auslöser.

Warum das archivierte .git-Verzeichnis wichtig ist

Ein normales git clone kopiert die lokalen clientseitigen Hooks eines Quell-Repositorys nicht, wie Pro Git erläutert. Diese Lieferung enthielt das vorhandene .git-Verzeichnis in einem Archiv, sodass der lokale Hook mitgeliefert wurde.

Pfad, Modus und Größe des Hooks, direkt aus dem ursprünglichen TAR gelesen. Wir haben das erhaltene Verzeichnis nicht als Git-Repository verwendet.

Wir untersuchten den Container und die Git-Objekte direkt, ohne checkout oder switch im erhaltenen Repository auszuführen.

Was der Downloader im Git-Hook tut

Kommentare im Shellskript beschreiben ein Hilfsprogramm für Browser- oder Erweiterungsupdates. In den Projektdokumenten fanden wir keine Anforderung für ein solches Hilfsprogramm. Das Skript liegt als unverschleierter Klartext vor.

Der ungenutzte Größenschwellenwert

Das Skript setzt THRESHOLD auf 100 und fragt bei Git eine Liste geänderter Dateinamen ab. Es initialisiert TRIGGER mit null.

THRESHOLD=100
FILES=$(git diff --name-only "$OLD_HEAD" "$NEW_HEAD")
TRIGGER=0

Innerhalb der Schleife berechnet es SIZE. Es gibt keinen Vergleich mit THRESHOLD und keine Zuweisung, die TRIGGER ändert. Der Download-Block wird ausgeführt, wenn TRIGGER null ist.

if [ "$TRIGGER" -eq 0 ]; then

Auf dem normalen Ausführungspfad dieses Skripts ist die Bedingung selbst dann wahr, wenn die Liste geänderter Dateien leer ist. Der Schwellenwert schränkt den Download nicht ein.

Die ursprünglichen Zeilennummern wurden beibehalten. TRIGGER bleibt null. THRESHOLD wird deklariert, aber nie in einem Vergleich verwendet.

Getrennte Downloads für Linux, macOS und Windows

Der von uname -s zurückgegebene Wert bestimmt den Download-Pfad und den lokalen Dateinamen.

Erkanntes System	Serverpfad	Lokaler Dateiname
Linux	/api/l	run-command.sh
Darwin / macOS	/api/m	run-command.sh
MINGW, MSYS, CYGWIN, Windows_NT	/api/w	run-command.cmd
Nicht erkanntes System	/api/l	run-command.sh

Die URLs verwenden denselben Host, der hier durch <DOWNLOAD_DOMAIN> ersetzt wurde. Den unredigierten Hook bewahren wir unter Verschluss auf. Die Verzweigungen decken Linux, macOS und Windows ab, mit Linux als Rückfalloption für ein nicht erkanntes System. Wir haben die Ausführung auf diesen Systemen nicht getestet.

Herunterladen der Datei und Versuch ihrer Ausführung

Der Hook speichert die Datei in ${TMPDIR:-/tmp} mit curl, oder mit wget, falls curl nicht verfügbar ist. Vor den folgenden Ausführungsanweisungen erfolgt weder eine Signaturprüfung noch ein Abgleich mit einem erwarteten Hashwert.

chmod +x "$CMD_FILE"
"$CMD_FILE" > /dev/null 2>&1 &

Das abschließende kaufmännische Und startet den Befehl im Hintergrund. Sowohl die Standardausgabe als auch die Standardfehlerausgabe werden nach /dev/null geleitet.

Nach dem Ausführungsversuch schreibt der Hook azuku in .git-checker im temporären Verzeichnis. Vor einem erneuten Download prüft er nie, ob dieser Marker vorhanden ist. Er wartet auch nicht darauf, dass der Hintergrundprozess erfolgreich ist, bevor er die Datei schreibt. Der Marker könnte daher auch nach einem erfolglosen Ausführungsversuch vorhanden sein.

Die ursprünglichen Anweisungen für Download, chmod, Hintergrundausführung und Schreiben des Markers. Das Programm der zweiten Stufe ist in diesem Auszug nicht enthalten.

Ein Kommentar gegen Ende fordert dazu auf, das temporäre Download-Verzeichnis zu entfernen. Darunter steht kein Befehl zum Entfernen.

War im Archiv eine Anwendung versteckt?

Der Netzwerkdownload warf eine weitere Frage auf. Befand sich bereits eine Anwendung im Archiv, möglicherweise im Git-Verlauf oder in der Geheimhaltungsvereinbarung? Wir untersuchten die Containergrenzen, dekodierten anschließend jedes mitgelieferte Git-Objekt und prüften den DOCX-Inhalt.

Die Archivgrenzen

Wir erfassten den SHA-256-Hashwert des ursprünglichen Archivs, bevor wir seinen Inhalt untersuchten.

6f44ff4e461828dd1fe6ede75ca8d9d4b579c2ac223463629e9a7537b9df5040

Die Dekomprimierung von gzip als Daten ergab einen TAR-Datenstrom mit 890,880 Bytes. Der gzip-Datenstrom endete ordnungsgemäß, ohne ungenutzte Bytes danach. Die letzten 5,120 Bytes nach dem letzten TAR-Eintrag waren Nullauffüllung.

Anschließend untersuchten wir die Dateien und Objekte, die durch diese Containereinträge erfasst wurden.

Gespeicherte Prüfungen des gzip-Datenstromendes und der TAR-Auffüllung. Es wurde kein Code aus dem untersuchten Material ausgeführt.

Den Hook im TAR-Header finden

Der Header des Eintrags post-checkout beginnt im dekomprimierten TAR bei 0xCF600 beziehungsweise 849,408. Seine Dateidaten beginnen bei 849,920. Diese Offsets beziehen sich auf den TAR-Datenstrom, nicht auf die komprimierte .gz-Datei.

An diesem Offset beginnt der Header mit dem Pfad zu post-checkout.

TAR / Hexdump

000cf600  41 49 2d 46 72 61 75 64 2d 44 65 74 65 63 74 69  |AI-Fraud-Detecti|
000cf610  6f 6e 5f 42 6c 6f 63 6b 63 68 61 69 6e 2f 2e 67  |on_Blockchain/.g|
000cf620  69 74 2f 68 6f 6f 6b 73 2f 70 6f 73 74 2d 63 68  |it/hooks/post-ch|
000cf630  65 63 6b 6f 75 74 00 00 00 00 00 00 00 00 00 00  |eckout..........|
000cf640  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
000cf650  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
000cf660  00 00 00 00 30 30 30 30 37 37 37 00 30 30 30 31  |....0000777.0001|
000cf670  37 35 30 00 30 30 30 31 37 35 30 00 30 30 30 30  |750.0001750.0000|
000cf680  30 30 30 35 33 32 36 00 31 35 32 35 32 30 30 34  |0005326.15252004|
000cf690  33 30 37 00 30 32 34 30 37 35 00 20 30 00 00 00  |307.024075. 0...|
000cf6a0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|

In einem TAR-Header belegt mode die Bytes [100:108] und size die Bytes [124:136]. Die dekodierten Felder für diesen Eintrag folgen auf den Dump.

TAR-Feld	Rohbytes / Wert
mode	b'0000777\x00'
size	b'00000005326\x00'
Oktaler Modus	0777
Dezimale Größe	2774 Bytes
Gespeicherte / berechnete Prüfsumme	10301 / 10301

Die oktale Größenangabe ergibt dekodiert 2,774 Bytes. Die gespeicherte Header-Prüfsumme lautet 10,301. Eine Neuberechnung mit durch Leerzeichen gefülltem Prüfsummenfeld liefert dasselbe Ergebnis.

Der rohe TAR-Header des Hooks und die dekodierten Felder. Name, Berechtigungen und Größe sind in den Containerbytes sichtbar.

Wir berechneten auch den Hashwert des aus diesem Eintrag extrahierten Hooks.

854b3b88b06fad9d9ffec36b35be0133b1d502084d4d7cce232eda2b2dd03092

Der Dump des TAR-Eintrags und der anonymisierte Hook sind dem Artikel beigefügt. Der obige Hashwert identifiziert das unter Verschluss aufbewahrte unredigierte Original, nicht die redigierte Veröffentlichungskopie.

Git-Objekte ohne checkout lesen

Es gibt 24 lose Objekte in .git/objects, die jeweils in einem zlib-Datenstrom gespeichert sind. Die dekomprimierten Daten enthalten einen Git-Header, gefolgt vom Objektinhalt.

<type> <size>\0<body>

Wir prüften die deklarierte Länge des Objektinhalts und berechneten SHA-1 über die gesamte dekodierte Sequenz, einschließlich Header und NUL-Byte. Das Ergebnis muss mit der Objekt-ID im Dateinamen übereinstimmen. Dies prüft die Integrität des Objekts. Es sagt nichts darüber aus, wer es erstellt hat.

Für jedes Objekt verglichen wir die deklarierte Länge mit der Länge des Objektinhalts und überprüften den Hashwert über die vollständigen dekodierten Daten.

expanded = zlib.decompress(compressed_object)
header, body = expanded.split(b"\0", 1)
kind, declared_size = header.decode("ascii").split()

assert len(body) == int(declared_size)
assert hashlib.sha1(expanded).hexdigest() == object_id

Wir prüften auch die Enden der zlib-Datenströme. Die Objekte ergeben 16 Blobs, 5 Trees und 3 Commits. Wenn man den drei Branch-Spitzen, ihren Vorgänger-Commits und untergeordneten Trees folgt, werden alle 24 Objekte erfasst. Unter den mitgelieferten Objekten gibt es keine unerreichbaren Blobs.

Git / Beziehungen zwischen Commits

master 4bc26f6c18910ca777c8238d2f88f6e725fcdc3f
  tree   feb0feaf7b8e826b085e90dea5399772d7b91f02
  parent (none)

conf   239b9aa2edc8c5e21fddeea5ed0e937496ae013f
  tree   048b51f9673f94354251ce16a78e663c71667a4c
  parent 4bc26f6c18910ca777c8238d2f88f6e725fcdc3f

NDA    a1311875d86bf6f1a6b9f2fee6527abbd1ce647d
  tree   cc020d922090835ea4ac3a3e418d0213d7a2ad94
  parent 239b9aa2edc8c5e21fddeea5ed0e937496ae013f

Das vollständige Objektverzeichnis enthält auch die Objekte außerhalb des aktuellen Arbeitsbaums.

Verzeichnis aller 24 Git-Objekte

Objekt-ID	Typ	Objektinhalt, Bytes
08e2cda2f440c1792c7c35a3499bfd1ade3e9bad	blob	6497
22bb86aacf377c17c7ad0d52c5cefeeb93dfa13e	blob	5123
2a7091bdd006a2f98a8c795fd7d2a04c8ee53056	blob	2610
39e13459086f36bc7c933d4e7b5d249a22db24bd	blob	3061
3f50e45c67dee5aac77147a5418afe551e8871be	blob	2433
476dc872c6def747dcdac549b67a8dc80948b7e1	blob	3191
5a51550933b593eb65da458bbdd579f85c082dab	blob	752100
5e53fd0880963e1767ad23fb8612b76e31f04003	blob	2807
60a7cbff83445488fd34b12de1814dc56c956963	blob	2054
74d479352822f5cc1d03552f517cfb5b2d7aa6d3	blob	2281
84e694473554c8a7c01f038a1b6ef8d9355405f7	blob	2033
bb7b5d8bc28c4a6257f7d87a685c61ba16a3789c	blob	2425
d83c8e0c416766be34276013944f5b94726e8c8f	blob	2776
dfd0f171bca257780eb0d9e22ba2eda1db9d4b68	blob	8402
e3b57e48010fc25fd12e7f5f25e952aca843e537	blob	6316
ed325750862eb6cdc92b216258a00a784312d793	blob	3062
239b9aa2edc8c5e21fddeea5ed0e937496ae013f	commit	213
4bc26f6c18910ca777c8238d2f88f6e725fcdc3f	commit	165
a1311875d86bf6f1a6b9f2fee6527abbd1ce647d	commit	212
048b51f9673f94354251ce16a78e663c71667a4c	tree	438
2cb70db8d9317603cb5f0fee0029b66581a7162e	tree	104
61874365e5498a30c8b61ef63bbb1d28b4cf4e22	tree	320
cc020d922090835ea4ac3a3e418d0213d7a2ad94	tree	57
feb0feaf7b8e826b085e90dea5399772d7b91f02	tree	104

Länge und SHA-1 wurden anhand der ursprünglichen Git-Kodierung jedes Objekts überprüft. Alle 24 Prüfungen waren erfolgreich.

---

Die Geheimhaltungsvereinbarung vom Tree bis zu ihren Bytes verfolgen

Der Branch NDA verweist auf einen Tree mit einer Datei, Non-Disclosure-Agreement.docx. Ein Git-Tree-Eintrag speichert Modus und Dateinamen als Text, gefolgt von einem NUL-Byte und 20 Rohbytes für die Blob-ID. Wir lasen den Eintrag direkt aus dem Tree-Inhalt aus.

Git-Tree / Hexdump

00000000  31 30 30 36 34 34 20 4e 6f 6e 2d 44 69 73 63 6c  |100644 Non-Discl|
00000010  6f 73 75 72 65 2d 41 67 72 65 65 6d 65 6e 74 2e  |osure-Agreement.|
00000020  64 6f 63 78 00 5a 51 55 09 33 b5 93 eb 65 da 45  |docx.ZQU.3...e.E|
00000030  8b bd d5 79 f8 5c 08 2d ab                       |...y.\.-.|

Rohe Bytes des NDA-Trees und die dekodierte Referenz auf seinen DOCX-Blob.

Dieser Eintrag verweist auf den folgenden Blob.

5a51550933b593eb65da458bbdd579f85c082dab

Nach der zlib-Dekomprimierung beginnt das Objekt mit blob 752100\0. Unmittelbar nach dem Header folgen die Bytes 50 4b 03 04, die PK-Signatur eines ZIP-Containers.

Git-Blob / nach zlib-Dekomprimierung

00000000  62 6c 6f 62 20 37 35 32 31 30 30 00 50 4b 03 04  |blob 752100.PK..|
00000010  0a 00 00 00 00 00 87 4e e2 40 00 00 00 00 00 00  |.......N.@......|
00000020  00 00 00 00 00 00 09 00 00 00 64 6f 63 50 72 6f  |..........docPro|
00000030  70 73 2f 50 4b 03 04 14 00 00 00 08 00 87 4e e2  |ps/PK.........N.|
00000040  40 a5 76 12 16 69 01 00 00 7b 02 00 00 10 00 00  |@.v..i...{......|
00000050  00 64 6f 63 50 72 6f 70 73 2f 61 70 70 2e 78 6d  |.docProps/app.xm|
00000060  6c 9d 92 c1 4e c3 30 10 44 ef 48 fc 43 94 7b 62  |l...N.0.D.H.C.{b|

Komprimierte Objektbytes, der dekodierte Git-Header und der Anfang der DOCX-Datei. Länge und Objekt-ID wurden anhand des vollständigen Objekts geprüft.

Der Objektinhalt ist 752,100 Bytes lang. Sein SHA-256-Hashwert stimmt mit dem der DOCX-Datei überein, die wir zur Analyse separat gespeichert haben.

9d85170d2c0aa7a9b90dfc3855715a31d971bba7abb563e9efa1153fdc15634f

Diese Objekte belegen den Pfad vom Branch NDA bis zu den Bytes des Dokuments.

Alle 16 Blobs erfassen

Fünfzehn Blobs lassen sich als UTF-8-kodierte Markdown-Projektdokumente dekodieren. Der verbleibende Blob ist die oben genannte DOCX-Datei. Keiner beginnt mit einem PE-, ELF- oder Mach-O-Header.

Pfad in den Trees	Größe, Bytes	Typ / erste Bytes
04-solution-proposal-guidance.md	2054	UTF-8-Text · 23 20 44 65 76 65 6c 6f 70 6d 65 6e 74 20 43 6f
06-blockchain-architecture.md	6497	UTF-8-Text · 23 20 42 6c 6f 63 6b 63 68 61 69 6e 20 41 72 63
07-blockchain-integration-specification.md	2807	UTF-8-Text · 23 20 42 6c 6f 63 6b 63 68 61 69 6e 20 49 6e 74
08-smart-contract-specification.md	2610	UTF-8-Text · 23 20 53 6d 61 72 74 20 43 6f 6e 74 72 61 63 74
09-data-and-api-architecture.md	2776	UTF-8-Text · 23 20 44 61 74 61 20 26 20 41 50 49 20 41 72 63
11-ai-fraud-and-risk-engine.md	3062	UTF-8-Text · 23 20 41 49 20 46 72 61 75 64 20 44 65 74 65 63
14-deliverables-acceptance-and-milestones.md	6316	UTF-8-Text · 23 20 44 65 6c 69 76 65 72 61 62 6c 65 73 2c 20
Detailed/03-business-and-use-cases.md	3061	UTF-8-Text · 23 20 42 75 73 69 6e 65 73 73 20 52 65 71 75 69
Detailed/05-non-functional-requirements.md	2033	UTF-8-Text · 23 20 4e 6f 6e 2d 46 75 6e 63 74 69 6f 6e 61 6c
Detailed/10-security-and-privacy-requirements.md	2433	UTF-8-Text · 23 20 53 65 63 75 72 69 74 79 20 26 20 50 72 69
Detailed/12-testing-and-quality-requirements.md	2425	UTF-8-Text · 23 20 54 65 73 74 69 6e 67 20 26 20 51 75 61 6c
Detailed/13-deployment-monitoring-and-operations.md	2281	UTF-8-Text · 23 20 44 65 70 6c 6f 79 6d 65 6e 74 2c 20 4d 6f
Intro/01-project-overview.md	8402	UTF-8-Text · 23 20 50 72 6f 6a 65 63 74 20 4f 76 65 72 76 69
Intro/02-product-requirements.md	3191	UTF-8-Text · 23 20 50 72 6f 64 75 63 74 20 52 65 71 75 69 72
Non-Disclosure-Agreement.docx	752100	DOCX/ZIP · 50 4b 03 04 0a 00 00 00 00 00 87 4e e2 40 00 00
README.md	5123	UTF-8-Text · 23 20 41 49 20 46 72 61 75 64 20 44 65 74 65 63

Alle 16 mitgelieferten Blobs wurden klassifiziert. Die Trees enthalten Projektdokumente; eine Produktimplementierung wurde nicht gefunden.

Wir lasen die Textinhalte und prüften außerdem ihre Signaturen. Die DOCX-Datei war der einzige nicht textbasierte Blob und erforderte eine gesonderte Containerprüfung.

Die DOCX-Datei als ZIP öffnen

Das Dokument enthält 25 ZIP-Einträge, bestehend aus 17 Dateibestandteilen und 8 Verzeichnissen. Wir lasen jeden Dateibestandteil und prüften seinen CRC-Wert.

DOCX-Bestandteil	Größe, Bytes	CRC32
[Content_Types].xml	1482	ec936159
_rels/.rels	737	1f222201
customXml/_rels/item1.xml.rels	296	7a393f74
customXml/item1.xml	400	4ed0e3fe
customXml/itemProps1.xml	327	457b4363
docProps/app.xml	635	161276a5
docProps/core.xml	595	d5626da7
docProps/custom.xml	722	8d44908d
word/_rels/document.xml.rels	1086	22475620
word/_rels/settings.xml.rels	398	e5802c0c
word/document.xml	91835	4df71596
word/fontTable.xml	4234	2796cccd
word/media/image1.png	712863	09063019
word/media/image2.png	10193	3aea21cf
word/settings.xml	4116	34faa9ef
word/styles.xml	30020	b4e9edbd
word/theme/theme1.xml	6329	ed5975e1

Namen, Längen und CRC32-Werte der DOCX-Bestandteile. Wir untersuchten ZIP- und XML-Daten, ohne das Dokument in Office zu öffnen.

Die Liste der Bestandteile enthält weder vbaProject.bin noch einen OLE-Anhang. Zwei PNG-Dateien enthalten ein Logo und ein Unterschriftsbild. Wir untersuchten auch die XML-Beziehungen und fanden einen Verweis auf einen lokalen Office-Vorlagenpfad auf dem Rechner des Dokumentautors. Wir haben diesen weder aufgelöst noch geladen.

Das Unterschriftsbild und die Git-Autorenfelder bieten uns keine zuverlässige Möglichkeit, den Absender zu identifizieren. Beides kann kopiert oder ersetzt werden.

In den mitgelieferten Inhalten fanden wir keine separate Anwendung oder Produktimplementierung. Der Hook bezieht sein nächstes Programm über das Netzwerk. Unsere Containerprüfung schließt nicht jeden möglichen Exploit oder jede steganografische Technik aus.

Was der Download-Server zurückgab

Wir riefen die drei exakten URLs als Daten ab, ohne die Antworten auszuführen oder Weiterleitungen zu folgen. Am 19. Oktober zwischen 17:29:27 und 17:29:28 UTC gab jede HTTP 200 zurück. Alle drei Antwortinhalte bestanden aus derselben 21 Bytes langen Nachricht.

Permanently suspended

Die drei gespeicherten Endpunktbeobachtungen. Bei der Vorbereitung dieses Artikels stellten wir keine weiteren Anfragen an die Downloader-URLs.

Uns liegen keine Bytes der zweiten Stufe für ein Reverse Engineering vor. Wir wissen auch nicht, was diese Endpunkte früher, einem anderen Besucher oder unter anderen Anfragebedingungen zurückgaben. Die Sperrmeldung liefert uns keine verifizierte Erklärung dafür, warum der Dienst gesperrt wurde.

Der Hook versucht, eine externe Datei herunterzuladen und auszuführen. Aussagen über gestohlene Passwörter, Tokens, Quellcode oder Wallets würden Belege erfordern, die uns nicht vorliegen.

Könnte dies ein legitimes Hilfsprogramm gewesen sein?

Ein internes Updateprogramm könnte versehentlich in ein Archiv geraten. Git-Hooks, Hintergrundprozesse und curl haben allesamt legitime Verwendungszwecke.

Bei dieser Zusendung forderte uns die E-Mail ausdrücklich auf, einen anderen Branch aufzurufen. Dies konnte den mitgelieferten Downloader auslösen, obwohl als Grund für den Branch-Wechsel die Lektüre einer Vereinbarung genannt wurde. Die E-Mail erwähnte die Ausführung nicht. Wir fanden auch keinen Zusammenhang zwischen einem Browser-Updateprogramm und dem vorgeschlagenen System, und die Größenprüfung des Skripts war unvollständig.

Wir behandelten die Zusendung als versuchten Angriff durch eingeschleusten Code und verhinderten die Ausführung des Hooks. Für eine Neubewertung dieser Einschätzung wären der Quellcode der heruntergeladenen Dateien und eine überprüfbare Erklärung erforderlich, warum ein Auftragnehmer diese zur Prüfung der Geheimhaltungsvereinbarung ausführen musste.

Wir haben die Identität des Betreibers nicht festgestellt. Die Absenderadresse, die Commit-Metadaten und die Namen im Dokument reichen für eine Zuordnung nicht aus.

Analysediagramm der vom mitgelieferten Hook beschriebenen Ausführungsschritte.

Ein unbekanntes Git-Repository prüfen

Ein Entwickler, der der E-Mail folgte, konnte den Auslöser der Ausführung erreichen, während er sich noch über das Projekt informierte. Es war nicht nötig, die vorgeschlagene Anwendung zu bauen oder zu starten.

Wenn Sie Kundenzusendungen auf einem Rechner mit produktiven SSH-Schlüsseln oder Cloud-Tokens prüfen, kann ein unerwartetes Skript Zugriff auf diese Ressourcen haben. Eine Wegwerfumgebung muss diese Zugangsdaten außer Reichweite halten. Browsersitzungen auf dem Prüfungsrechner verdienen dieselbe Aufmerksamkeit.

Die Prüfung sollte das mitgelieferte .git-Verzeichnis und jede IDE-Automatisierung einbeziehen, bevor Entwickler ihre üblichen Befehle verwenden. Auch Installationsskripte müssen genau geprüft werden. In Host-Protokollen würden wir nach Git oder einer Shell suchen, die eine Datei in ein temporäres Verzeichnis herunterlädt und anschließend ausführt. Ein curl-Prozess allein sagt uns deutlich weniger.

Die Aufbewahrung der ursprünglichen E-Mail und des Archivs ermöglicht es späteren Prüfern, die Lieferung nachzuvollziehen. Hashwerte und Host-Ereignisse helfen festzustellen, was auf dem Rechner geschah. Ein fehlender Marker kann nicht belegen, dass ein Programm nie ausgeführt wurde.

Kann das Herunterladen oder Entpacken des Archivs diesen Hook ausführen?

Das Herunterladen und gewöhnliche Entpacken rufen den Git-Hook post-checkout nicht selbst auf. Bei diesem untersuchten Material ist der dokumentierte Auslöser eine Aktualisierung des Arbeitsbaums durch Git mittels checkout oder switch, wenn die Hook-Ausführung zulässig ist. Wir untersuchten die mitgelieferten Objekte direkt, ohne diese Vorgänge aufzurufen.

Nach der Archivprüfung

Wir hatten erwartet, dass sich der nächste Austausch um Architektur und Liefertermine drehen würde. Stattdessen antworteten wir zum Hook und bewahrten das Material zur weiteren Prüfung auf. Wir können weiterhin nicht sagen, was das entfernte Programm tat oder wer es betrieb. Der Hook gab uns genügend Anlass, den angeforderten Git-Ablauf abzubrechen.

Seit mehr als fünf Jahren helfen SToFU Systems und unsere Lösungen Unternehmen dabei, ihre Systeme zu schützen, auch vor Angriffen über Geschäftskorrespondenz und Entwicklungsmaterialien. Unsere Sicherheitsaudits untersuchen, wie Code und Zugriffsrechte missbraucht werden können. Wir bieten außerdem Reverse Engineering an, wenn ein Team unbekannte Software verstehen muss.

Wenn ein Repository oder eine Binärdatei Fragen aufwirft, sprechen Sie mit unserem Team über eine technische Prüfung, bevor Sie es beziehungsweise sie in Ihre normale Entwicklungsumgebung übernehmen.

Korrespondenz und Belegdateien

In den vier folgenden Nachrichten werden Platzhalter für Personennamen, Adressen, Identitäten Dritter und identifizierende Links verwendet. Der übrige Wortlaut der jeweils neuen Nachricht bleibt erhalten. Wiederholte Zitate werden ausgelassen, da jede E-Mail separat erscheint. Die Dienst-IP des Webformulars und die Adressen unbeteiligter Empfänger werden ebenfalls nicht veröffentlicht.

1. Die erste Anfrage über unsere Website

E-Mail / identifizierende Angaben ersetzt

Date: Thu, 15 Oct 2026 12:55:21 +0000
From: SToFU Site Form <TEAM_EMAIL>
To: <TEAM_EMAIL>
Subject: SToFU Systems - Contact by <SENDER_NAME> <SENDER_EMAIL>
Reply-To: <SENDER_NAME> <SENDER_EMAIL>

Time: 2026-10-15T12:55:21+00:00
IP: [redacted]
Page: /contact
Name: <SENDER_NAME>
Email: <SENDER_EMAIL>
Attachments: none
Message:
We are currently developing an AI-powered FinTech fraud detection platform designed to help financial organizations identify suspicious transactions, assess potential risks in real time, and strengthen their fraud prevention and investigation processes.
The planned platform will incorporate AI/ML-based fraud detection, transaction risk scoring, behavioral analysis, configurable fraud-detection rules, blockchain-based verification, automated alerts, investigation support, and reporting and analytics.
We are looking to connect with an experienced technology partner with expertise in blockchain, financial technology, AI/ML, and scalable web platform development to help us bring this product to life.
We would welcome the opportunity to discuss your team’s capabilities, experience, and potential role in the project. The specific scope of your team’s involvement, technical responsibilities, and collaboration model can be determined through our discussion, based on your expertise and recommendations.
If this opportunity aligns with your team’s capabilities and interests, I’d be happy to share the project overview and technical roadmap for an initial review.
---

Die erste Anfrage über unsere Website. Anonymisierte Veröffentlichungsansicht der aufbewahrten E-Mail.

SHA-256 der privaten, unredigierten EML-Datei: bf7d0f3a59b84f509ca436e0750640e844e9731ce363a42a99d5be60cdf8597e

---

2. Unsere Antwort mit der Bitte um die Unterlagen

E-Mail / identifizierende Angaben ersetzt

Date: Sat, 17 Oct 2026 19:46:28 -0000
From: <TEAM_MEMBER_NAME> <TEAM_EMAIL>
To: <SENDER_NAME> <SENDER_EMAIL>
Subject: Re: Your AI fraud detection platform
Cc: [redacted: third-party addresses]

Hi <SENDER_NAME>,

Thank you for getting in touch through our website. I'm <TEAM_MEMBER_NAME>, <TEAM_MEMBER_ROLE> of SToFU Systems (<COMPANY_WEBSITE>). You can find me on <PROFESSIONAL_NETWORK> here:
<PROFILE_URL>

Your fraud detection platform sounds like a great project. Helping financial teams spot suspicious transactions and investigate them more effectively is a worthwhile problem to solve, and we'd be very happy to help you bring it to life.

We'd be glad to help with the architecture, development, security, and ongoing maintenance. We'll do everything we can to get the platform launched and keep it running reliably as it grows.

If you plan to seek investment, we can also help prepare the technical side for those conversations, including a working product or demo, clear architecture and documentation, and a practical development roadmap.

Please send over the project overview and technical roadmap you mentioned. It would be helpful to understand what you've already built and what you'd like to tackle first.

I'd be happy to arrange a call to discuss the project and how we could work together. What day and time would suit you? Please include your time zone so we can find a slot that works for both teams.

Thank you again for reaching out, and have a great day!

Best regards,
<TEAM_MEMBER_NAME>
<TEAM_MEMBER_ROLE>
SToFU Systems
<COMPANY_WEBSITE>

Unsere Antwort mit der Bitte um die Unterlagen. Anonymisierte Veröffentlichungsansicht der aufbewahrten E-Mail.

SHA-256 der privaten, unredigierten EML-Datei: 1e5330dd82e02911254722744a3202e9b761c8c1d2950be937cd5d539c1bcad9

---

3. Die E-Mail zum Archiv mit Nennung der Branches NDA / conf

E-Mail / identifizierende Angaben ersetzt

Date: Mon, 19 Oct 2026 09:03:41 +0000
From: <SENDER_EMAIL>
To: <TEAM_EMAIL>
Subject: Re: Your AI fraud detection platform

Hi <TEAM_MEMBER_NAME>,
Thank you for your interest in our AI-powered FinTech fraud detection platform.
I’ve also reviewed your <PROFESSIONAL_NETWORK> profile, and I’m confident that you and your team can make a valuable contribution to our project.
I’m happy to share the project materials for your review.
We’ve prepared the project overview, technical roadmap, and NDA, which provide the key information needed to understand the project, its objectives, and the proposed technical direction.
The platform focuses on AI-driven fraud detection, transaction risk assessment, behavioral analysis, fraud prevention, blockchain-based verification, automated alerts, investigation support, and financial risk analytics.
This is the Link:
<FILE_SHARE_URL>
Please review the project materials and review and sign the NDA in the NDA branch.
The NDA is required because the project materials contain confidential business, technical, architectural, and product information.
So, please send me the signed NDA as soon as possible.
In particular, we would appreciate your initial technical assessment of the proposed system architecture and timeline. The detailed documentation and specifications related to these areas are available in the conf branch.
After your review, we would like to arrange a meeting to discuss your technical observations, recommendations, questions, development approach, and potential partnership opportunities in more detail.
Once you have completed your review, please let me know your preferred meeting date and time and provide the signed NDA.
Please feel free to take the time you need to review the materials thoroughly. I look forward to receiving your feedback and speaking with you about the project.
Kind regards,
<SENDER_NAME>

Die E-Mail zum Archiv mit Nennung der Branches NDA / conf. Anonymisierte Veröffentlichungsansicht der aufbewahrten E-Mail.

SHA-256 der privaten, unredigierten EML-Datei: f7007ed3053d3ba2ef71ea01c74ec0c4aebfd48417f757ecec8d9d7d5884bf33

---

4. Unsere Antwort nach der Entdeckung des Hooks

E-Mail / identifizierende Angaben ersetzt

Date: Mon, 19 Oct 2026 19:37:58 +0200
From: SToFU Systems <TEAM_EMAIL>
To: <SENDER_NAME> <SENDER_EMAIL>
Subject: Re: Your AI fraud detection platform

Hi <SENDER_NAME>,

We reviewed the materials you sent. Unfortunately, we found no application source code or working implementation, only planning documents and an NDA.

Execution of the supplied Git post-checkout hook was disabled during our review. The hook downloads and runs platform-specific files from <DOWNLOAD_DOMAIN>, hides their output, and writes a local marker. Our security policies do not allow the execution of untrusted third-party hooks.

Thank you for your time and for the elaborate attempt to deliver malicious code.

We have traced the technical delivery chain and preserved the archive, hook, download responses, correspondence, and author names and email addresses recorded in the repository. The relevant evidence will be passed to the competent law enforcement authorities in the applicable jurisdictions.

SToFU Systems

Unsere Antwort nach der Entdeckung des Hooks. Anonymisierte Veröffentlichungsansicht der aufbewahrten E-Mail.

SHA-256 der privaten, unredigierten EML-Datei: 31df91adb2eb52be2171836d3e26610328a0a1a1273dbf7d56efe4354bb62e19

---

• Anonymisierter Hook, alle 101 Zeilen
• TAR-Header und Anfang der Dateidaten
• Alle 24 Git-Objekte
• DOCX-Blob vor und nach zlib
• Dump des NDA-Trees
• Alle 16 Blobs und ihre ersten Bytes
• Alle DOCX-Bestandteile
• Gzip- und TAR-Grenzen
• Maschinenlesbare Untersuchung auf Byte-Ebene
• Gespeicherte Beobachtungen der drei Endpunkte
• Abbildungsquellen und Hashwerte
• Herkunft der Korrespondenz

Anonymisierte Ansicht des vollständigen Hooks

Alle 101 Quellzeilennummern wurden beibehalten. Identifizierende Angaben sind mit grauen Rechtecken abgedeckt.

---

Unredigierte Originale werden unter Verschluss aufbewahrt. Öffentliche Belegdateien verwenden Platzhalter, Screenshots undurchsichtige graue Rechtecke. Als Original gekennzeichnete Hashwerte identifizieren die private Quelle, nicht eine bearbeitete Veröffentlichungskopie. Die Abbildungen sind Screenshots lokaler Belegansichten, bei denen identifizierender Text vor dem Rendern entfernt wurde. Es wurde kein erhaltener Code ausgeführt.