En potensiell kunde forsøkte å kjøre ekstern kode gjennom Gits innebygde hooker.

SToFU Systems · Hendelsesundersøkelse · 20. oktober 2026

Innhold

1. Det begynte med en forespørsel om utvikling
2. Nedlasting og inspeksjon av filene
3. Hvordan Gits post-checkout-hook kunne kjøre
4. Hva Git-hookens nedlaster gjør
5. Var det skjult en applikasjon i arkivet?
6. Hva nedlastingsserveren returnerte
7. Kunne dette ha vært et legitimt hjelpeprogram?
8. Å gjennomgå et ukjent Git-kodearkiv
9. Etter gjennomgangen av arkivet
10. Korrespondanse og bevisfiler

Det begynte med en forespørsel om utvikling

Den første meldingen kom gjennom nettstedet vårt 15. oktober 2026. Avsenderen ønsket hjelp til å bygge en plattform for å oppdage økonomisk svindel. Det foreslåtte systemet skulle gi transaksjoner en risikoskår og bruke atferdsanalyse, med verifisering via blokkjede og rapportering blant de øvrige kravene.

19. oktober mottok vi nedlastingslenken. E-posten som fulgte med, henviste oss til grenen conf for arkitekturen og grenen NDA for avtalen. Den gjentok forespørselen om å gjennomgå og signere taushetserklæringen.

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

Å følge disse instruksjonene ville føre en gransker fra å pakke ut arkivet til å bytte gren i Git. E-posten fremstilte begge operasjonene som en del av å lese dokumentasjonen. Den sa ingenting om å kjøre et nedlastet program.

E-posten med prosjektarkivet og instruksjonene om å åpne NDA-grenen. Identifiserende opplysninger er dekket med grå rektangler.

Nedlasting og inspeksjon av filene

Lenken førte til en vanlig fildelingsside på Dropbox. Vi lastet ned AI-Fraud-Detection_Blockchain.tar.gz til et isolert granskningsmiljø og beholdt originalarkivet som referanse. Den konkrete delingsadressen publiseres ikke her.

Vi listet innholdet i arkivet og leste de medfølgende Git-objektene direkte. Det lot oss hente dokumentene fra alle tre grenene uten å sjekke ut en gren eller kjøre den medfølgende koden. I grenenes trær fant vi 15 Markdown-filer og ett Word-dokument.

Gren	Filer	Hva vi fant
master	8 Markdown-filer	En README, en prosjektoversikt, produktkrav og bruksområder i virksomheten. Andre dokumenter omhandlet ytelse, sikkerhet, testing og drift.
conf	7 Markdown-filer	Veiledning for et utviklingsforslag, blokkjedearkitektur og integrasjon, krav til smartkontrakter, data- og API-design, en KI-basert risikomotor og leveransemilepæler.
NDA	1 DOCX-fil	En taushetserklæring med et signaturfelt og plassholdere fra en mal.

Det foreslåtte produktet kombinerte transaksjonsanalyse, svindelregler og maskinlæringsskårer med verifisering via blokkjede. Den foreslåtte teknologistakken brukte Node.js og TypeScript med Express, PostgreSQL, Python-biblioteker for maskinlæring og Ethereum. Leveransedokumentet beskrev seks milepæler over 24 uker. Vi fant planleggingsdokumenter i de medfølgende trærne, uten noen applikasjonsimplementasjon, trent modell eller kildekode for smartkontrakter å gjennomgå.

Noen detaljer fortjente en nærmere titt. API-eksemplene inneholdt de bokstavelige strengene <built-in function id> og <built-in function hash> i endepunktstiene. Taushetserklæringen inneholdt fortsatt plassholdere fra malen. Disse inkonsekvensene reiste spørsmål om hvor grundig materialet var forberedt.

Den kjørbare filen .git/hooks/post-checkout var et mer alvorlig funn. Kommentarene beskrev et hjelpeprogram for oppdatering av en nettleser eller utvidelse, uten noen åpenbar forbindelse til gjennomgangen av dette prosjektet. Da vi leste skriptet, fant vi instruksjoner om å laste ned et eksternt program og starte det i bakgrunnen. E-postens forespørsel om å bytte gren kunne føre en gransker inn i denne kjøringsbanen under forsøket på å lese taushetserklæringen.

Vi holdt kodearkivet inaktivt og undersøkte hooken som tekst. De relevante arkivmetadataene og skriptets oppførsel følger nedenfor.

Hvordan Gits post-checkout-hook kunne kjøre

Filen AI-Fraud-Detection_Blockchain.tar.gz er 779,429 byte lang. De 100 TAR-oppføringene omfatter 60 vanlige filer. En fullstendig .git-katalog fulgte med dokumentene.

Hook-katalogen inneholdt de vanlige .sample-filene og en kjørbar fil med navnet post-checkout.

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

Det finnes ikke noe .sample-suffiks. TAR-mode er 0777, som omfatter kjørerettigheter, og lengden er 2,774 byte.

Git kaller post-checkout etter å ha oppdatert arbeidstreet gjennom operasjoner som checkout eller switch, forutsatt at miljøet tillater at hooken kjøres. Git-dokumentasjonen beskriver utløseren.

Hvorfor den arkiverte .git-katalogen er viktig

En vanlig git clone kopierer ikke kildearkivets lokale klienthooker, slik Pro Git forklarer. Denne leveransen inneholdt den eksisterende .git-katalogen i et arkiv, så den lokale hooken fulgte med.

Hookens sti, mode og størrelse lest direkte fra den opprinnelige TAR-filen. Vi brukte ikke den mottatte katalogen som et Git-kodearkiv.

Vi undersøkte beholderen og Git-objektene direkte, uten å kjøre checkout eller switch i det mottatte kodearkivet.

Hva Git-hookens nedlaster gjør

Kommentarer i skallskriptet beskriver et hjelpeprogram for oppdatering av en nettleser eller utvidelse. Vi fant ikke noe krav om et slikt hjelpeprogram i prosjektdokumentene. Skriptet er ren tekst som ikke er obfuskert.

Den ubrukte størrelsesterskelen

Skriptet setter THRESHOLD til 100 og ber Git om en liste over endrede filnavn. Det initialiserer TRIGGER til null.

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

Inne i løkken beregner det SIZE. Det finnes ingen sammenligning med THRESHOLD og ingen tilordning som endrer TRIGGER. Nedlastingsblokken kjører når TRIGGER er null.

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

Langs den normale banen gjennom dette skriptet er betingelsen sann selv når listen over endrede filer er tom. Terskelen begrenser ikke nedlastingen.

Opprinnelige linjenumre er beholdt. TRIGGER forblir null. THRESHOLD deklareres, men brukes aldri i en sammenligning.

Separate nedlastinger for Linux, macOS og Windows

Verdien som returneres av uname -s, avgjør nedlastingsstien og det lokale filnavnet.

Oppdaget system	Serversti	Lokalt filnavn
Linux	/api/l	run-command.sh
Darwin / macOS	/api/m	run-command.sh
MINGW, MSYS, CYGWIN, Windows_NT	/api/w	run-command.cmd
Ukjent system	/api/l	run-command.sh

URL-ene deler én vert, her erstattet med <DOWNLOAD_DOMAIN>. Vi har beholdt den usladdede hooken privat. Forgreningene dekker Linux, macOS og Windows, med Linux som reservevalg for et ukjent system. Vi testet ikke kjøring på disse systemene.

Nedlasting av filen og forsøk på å kjøre den

Hooken lagrer filen i ${TMPDIR:-/tmp} ved hjelp av curl, eller wget hvis curl ikke er tilgjengelig. Ingen signatur eller forventet hash kontrolleres før de følgende kjøringsinstruksjonene.

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

Det avsluttende og-tegnet starter kommandoen i bakgrunnen. Både standard utdata og standard feil går til /dev/null.

Etter kjøringsforsøket skriver hooken azuku til .git-checker i den midlertidige katalogen. Den ser aldri etter denne markøren før den laster ned på nytt. Den venter heller ikke på at bakgrunnsprosessen skal lykkes før filen skrives. Markøren kan derfor finnes etter et mislykket kjøringsforsøk.

De opprinnelige instruksjonene for nedlasting, chmod, bakgrunnskjøring og skriving av markøren. Programmet i andre trinn er ikke med i dette utdraget.

En kommentar nær slutten sier at den midlertidige nedlastingskatalogen skal fjernes. Det finnes ingen fjerningskommando under den.

Var det skjult en applikasjon i arkivet?

Nettverksnedlastingen reiste et annet spørsmål. Fantes det allerede en applikasjon i arkivet, kanskje i Git-historikken eller taushetserklæringen? Vi undersøkte beholdergrensene, dekodet deretter hvert medfølgende Git-objekt og inspiserte DOCX-innholdet.

Arkivgrensene

Vi registrerte originalarkivets SHA-256 før vi undersøkte innholdet.

6f44ff4e461828dd1fe6ede75ca8d9d4b579c2ac223463629e9a7537b9df5040

Dekomprimering av gzip som data ga en TAR-strøm på 890,880 byte. Gzip-strømmen sluttet korrekt, uten ubrukte byte etter seg. De siste 5,120 bytene etter den siste TAR-oppføringen var nullutfylling.

Deretter undersøkte vi filene og objektene som disse beholderoppføringene omfattet.

Lagrede kontroller av gzip-strømmens slutt og TAR-utfyllingen. Ingen kode fra prøven ble kjørt.

Å finne hooken i TAR-hodet

Hodet til oppføringen post-checkout begynner ved 0xCF600, eller 849,408, i den dekomprimerte TAR-filen. Fildataene begynner ved 849,920. Disse posisjonene viser til TAR-strømmen, ikke den komprimerte .gz-filen.

Ved denne posisjonen begynner hodet med stien til post-checkout.

TAR / heksadesimal visning

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  |................|

I et TAR-hode opptar mode bytene [100:108], og size opptar [124:136]. De dekodede feltene for denne oppføringen følger etter dumpen.

TAR-felt	Rå byte / verdi
mode	b'0000777\x00'
size	b'00000005326\x00'
Oktal mode	0777
Desimal størrelse	2774 byte
Lagret / beregnet kontrollsum	10301 / 10301

Den oktale størrelsen dekodes til 2,774 byte. Den lagrede kontrollsummen i hodet er 10,301. En ny beregning med kontrollsumfeltet fylt med mellomrom gir samme resultat.

Hookens rå TAR-hode og dekodede felt. Navnet, rettighetene og størrelsen er synlige i beholderens byte.

Vi beregnet også hashen til hooken som ble trukket ut fra denne oppføringen.

854b3b88b06fad9d9ffec36b35be0133b1d502084d4d7cce232eda2b2dd03092

Dumpen av TAR-oppføringen og den anonymiserte hooken følger med artikkelen. Hashen over identifiserer den usladdede originalen som oppbevares privat, ikke den sladdede publiseringskopien.

Å lese Git-objekter uten checkout

Det finnes 24 løse objekter i .git/objects, hvert lagret i en zlib-strøm. De dekomprimerte dataene inneholder et Git-hode etterfulgt av objektets kropp.

<type> <size>\0<body>

Vi kontrollerte den oppgitte kroppslengden og beregnet SHA-1 over hele den dekodede sekvensen, inkludert hodet og NUL-byten. Resultatet må stemme med objekt-ID-en i filnavnet. Dette kontrollerer objektets integritet. Det sier ingenting om hvem som opprettet det.

For hvert objekt sammenlignet vi den oppgitte lengden med kroppslengden og verifiserte hashen over alle de dekodede dataene.

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

Vi kontrollerte også slutten på zlib-strømmene. Objektene består av 16 blobber, 5 trær og 3 committer. Ved å følge hodene til de tre grenene, deres foreldrecommitter og underordnede trær kunne vi gjøre rede for alle 24 objekter. Blant de medfølgende objektene finnes det ingen blobber som ikke kan nås.

Git / relasjoner mellom commits

master 4bc26f6c18910ca777c8238d2f88f6e725fcdc3f
  tree   feb0feaf7b8e826b085e90dea5399772d7b91f02
  parent (none)

conf   239b9aa2edc8c5e21fddeea5ed0e937496ae013f
  tree   048b51f9673f94354251ce16a78e663c71667a4c
  parent 4bc26f6c18910ca777c8238d2f88f6e725fcdc3f

NDA    a1311875d86bf6f1a6b9f2fee6527abbd1ce647d
  tree   cc020d922090835ea4ac3a3e418d0213d7a2ad94
  parent 239b9aa2edc8c5e21fddeea5ed0e937496ae013f

Den fullstendige objektoversikten omfatter objektene utenfor det gjeldende arbeidstreet.

Oversikt over alle 24 Git-objekter

Objekt-ID	Type	Kropp, byte
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

Lengde og SHA-1 ble verifisert mot den opprinnelige Git-kodingen av hvert objekt. Alle 24 kontroller ble bestått.

---

Å følge taushetserklæringen fra treet til bytene

Grenen NDA peker til et tre som inneholder én fil, Non-Disclosure-Agreement.docx. En oppføring i et Git-tre lagrer mode og filnavn som tekst, etterfulgt av en NUL og 20 rå byte for blob-ID-en. Vi parset oppføringen direkte fra treets kropp.

Git-tre / heksadesimal visning

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.\.-.|

Rå byte fra NDA-treet og den dekodede referansen til DOCX-blobben.

Denne oppføringen viser til følgende blobb.

5a51550933b593eb65da458bbdd579f85c082dab

Etter zlib-dekomprimering begynner objektet med blob 752100\0. Rett etter hodet kommer bytene 50 4b 03 04, PK-signaturen til en ZIP-beholder.

Git-blob / etter zlib-dekomprimering

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|

Komprimerte objektbyte, det dekodede Git-hodet og begynnelsen av DOCX-filen. Lengde og objekt-ID ble kontrollert mot det fullstendige objektet.

Kroppen er 752,100 byte lang. Dens SHA-256 stemmer med DOCX-filen vi lagret separat for analyse.

9d85170d2c0aa7a9b90dfc3855715a31d971bba7abb563e9efa1153fdc15634f

Disse objektene gjør rede for banen fra grenen NDA til dokumentets byte.

Å gjøre rede for alle 16 blobber

Femten blobber dekodes som UTF-8-kodede Markdown-prosjektdokumenter. Den gjenværende blobben er DOCX-filen over. Ingen begynner med et PE-, ELF- eller Mach-O-hode.

Sti i trærne	Størrelse, byte	Type / første byte
04-solution-proposal-guidance.md	2054	UTF-8-tekst · 23 20 44 65 76 65 6c 6f 70 6d 65 6e 74 20 43 6f
06-blockchain-architecture.md	6497	UTF-8-tekst · 23 20 42 6c 6f 63 6b 63 68 61 69 6e 20 41 72 63
07-blockchain-integration-specification.md	2807	UTF-8-tekst · 23 20 42 6c 6f 63 6b 63 68 61 69 6e 20 49 6e 74
08-smart-contract-specification.md	2610	UTF-8-tekst · 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-tekst · 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-tekst · 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-tekst · 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-tekst · 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-tekst · 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-tekst · 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-tekst · 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-tekst · 23 20 44 65 70 6c 6f 79 6d 65 6e 74 2c 20 4d 6f
Intro/01-project-overview.md	8402	UTF-8-tekst · 23 20 50 72 6f 6a 65 63 74 20 4f 76 65 72 76 69
Intro/02-product-requirements.md	3191	UTF-8-tekst · 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-tekst · 23 20 41 49 20 46 72 61 75 64 20 44 65 74 65 63

Alle 16 medfølgende blobber er klassifisert. Trærne inneholder prosjektdokumenter, og ingen produktimplementasjon ble funnet.

Vi leste tekstinnholdet i tillegg til å kontrollere signaturene. DOCX-filen var den eneste blobben som ikke var tekst, og krevde en separat undersøkelse av beholderen.

Å åpne DOCX som ZIP

Dokumentet inneholder 25 ZIP-oppføringer, fordelt på 17 fildeler og 8 kataloger. Vi leste hver fildel og kontrollerte dens CRC.

DOCX-del	Størrelse, byte	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

DOCX-delenes navn, lengder og CRC32-verdier. Vi undersøkte ZIP- og XML-data uten å åpne dokumentet i Office.

Det finnes ingen vbaProject.bin eller OLE-vedlegg i dellisten. To PNG-filer inneholder en logo og et signaturbilde. Vi undersøkte også XML-relasjonene og fant en referanse til en lokal Office-malsti på dokumentforfatterens maskin. Vi slo den ikke opp eller lastet den inn.

Signaturbildet og forfatterfeltene i Git gir oss ingen pålitelig måte å identifisere avsenderen på. Begge kan kopieres eller erstattes.

Vi fant ingen separat applikasjon eller produktimplementasjon i det medfølgende innholdet. Hooken henter det neste programmet gjennom nettverket. Vår undersøkelse av beholderne utelukker ikke alle mulige utnyttelsesmetoder eller steganografiske teknikker.

Hva nedlastingsserveren returnerte

Vi hentet de tre nøyaktige URL-ene som data, uten å kjøre svarene eller følge omdirigeringer. 19. oktober, mellom 17:29:27 og 17:29:28 UTC, returnerte hver av dem HTTP 200. Alle tre svarkroppene var den samme meldingen på 21 byte.

Permanently suspended

De tre lagrede observasjonene av endepunktene. Vi sendte ingen flere forespørsler til nedlasterens URL-er under arbeidet med denne artikkelen.

Vi har ingen byte fra andre trinn å foreta omvendt utvikling av. Vi vet heller ikke hva disse endepunktene returnerte tidligere, til en annen besøkende eller under andre forespørselsbetingelser. Suspensjonsmeldingen gir oss ingen verifisert forklaring på hvorfor tjenesten ble suspendert.

Hooken forsøker å laste ned og kjøre en ekstern fil. Påstander om stjålne passord, tokener, kildekode eller lommebøker ville kreve bevis vi ikke har.

Kunne dette ha vært et legitimt hjelpeprogram?

Et internt oppdateringsprogram kan havne i et arkiv ved en feil. Git-hooker, bakgrunnsprosesser og curl har alle legitime bruksområder.

I dette materialet ba e-posten oss uttrykkelig om å gå til en annen gren. Å gjøre det kunne kalle den medfølgende nedlasteren, selv om den oppgitte grunnen til grenbyttet var å lese en avtale. E-posten nevnte ikke kjøringen. Vi fant heller ingen forbindelse mellom en nettleseroppdaterer og det foreslåtte systemet, og skriptets størrelseskontroll var ufullstendig.

Vi behandlet materialet som et forsøk på angrep gjennom levering av kode og hindret hooken i å kjøre. For å revurdere denne vurderingen ville vi trenge kildekoden til de nedlastede filene og en verifiserbar forklaring på hvorfor en oppdragstaker måtte kjøre dem for å gjennomgå taushetserklæringen.

Vi har ikke fastslått operatørens identitet. Avsenderadressen, commit-metadataene og navnene i dokumentet er ikke tilstrekkelige for attribusjon.

Analysediagram over kjøringstrinnene som beskrives av den medfølgende hooken.

Å gjennomgå et ukjent Git-kodearkiv

En utvikler som fulgte e-posten, kunne nå kjøringsutløseren mens vedkommende fortsatt leste om prosjektet. Det var ikke nødvendig å bygge eller starte den foreslåtte applikasjonen.

Hvis du gjennomgår kundemateriale på en maskin med SSH-nøkler for produksjon eller skytokener, kan et uventet skript få tilgang til disse ressursene. Et engangsmiljø må holde disse autentiseringsopplysningene utenfor rekkevidde. Nettleserøkter på granskningsmaskinen fortjener samme hensyn.

Gjennomgangen bør omfatte den medfølgende .git-katalogen og all IDE-automatisering før en utvikler begynner å bruke sine vanlige kommandoer. Installasjonsskript må også granskes. I vertsloggene ville vi se etter Git eller et skall som laster ned en fil til en midlertidig katalog og deretter kjører den. En curl-prosess alene forteller oss langt mindre.

Å bevare den opprinnelige e-posten og arkivet lar en senere gransker kontrollere hva som ble levert. Hasher og vertshendelser bidrar til å fastslå hva som skjedde på maskinen. En manglende markør kan ikke fastslå at et program aldri kjørte.

Kan nedlasting eller utpakking av arkivet kjøre denne hooken?

Nedlasting og vanlig utpakking kaller ikke i seg selv Gits post-checkout-hook. I denne prøven er den dokumenterte utløseren at Git oppdaterer arbeidstreet gjennom checkout eller switch, når kjøring av hooker er tillatt. Vi undersøkte de medfølgende objektene direkte uten å kalle disse operasjonene.

Etter gjennomgangen av arkivet

Vi hadde forventet at neste utveksling skulle handle om arkitektur og leveransedatoer. I stedet sendte vi et svar om hooken og bevarte materialet for videre gjennomgang. Vi kan fortsatt ikke si hva det eksterne programmet gjorde, eller hvem som drev det. Hooken ga oss tilstrekkelig grunn til å stoppe den forespurte Git-arbeidsflyten.

I mer enn fem år har SToFU Systems og løsningene våre hjulpet bedrifter med å beskytte systemene sine, også mot angrep levert gjennom forretningskorrespondanse og utviklingsmateriale. Våre sikkerhetsrevisjoner undersøker hvordan kode og tilgang kan misbrukes. Vi tilbyr også omvendt utvikling når et team trenger å forstå ukjent programvare.

Hvis et kodearkiv eller en binærfil reiser spørsmål, snakk med teamet vårt om en teknisk gjennomgang før du tar materialet inn i det vanlige utviklingsmiljøet ditt.

Korrespondanse og bevisfiler

De fire meldingene nedenfor bruker plassholdere for personnavn, adresser, tredjeparters identiteter og identifiserende lenker. Annen ordlyd i de nye meldingene er beholdt. Gjentatte sitater er utelatt fordi hver e-post vises separat. Nettskjemaets tjeneste-IP og adressene til uvedkommende mottakere er også utelatt.

1. Den første forespørselen gjennom nettstedet vårt

E-post / identifiserende opplysninger erstattet

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.
---

Den første forespørselen gjennom nettstedet vårt. Anonymisert publiseringsvisning av den bevarte e-posten.

SHA-256 for privat, usladdet EML: bf7d0f3a59b84f509ca436e0750640e844e9731ce363a42a99d5be60cdf8597e

---

2. Svaret vårt med forespørsel om materialet

E-post / identifiserende opplysninger erstattet

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>

Svaret vårt med forespørsel om materialet. Anonymisert publiseringsvisning av den bevarte e-posten.

SHA-256 for privat, usladdet EML: 1e5330dd82e02911254722744a3202e9b761c8c1d2950be937cd5d539c1bcad9

---

3. E-posten med arkivet som angir grenene NDA / conf

E-post / identifiserende opplysninger erstattet

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>

E-posten med arkivet som angir grenene NDA / conf. Anonymisert publiseringsvisning av den bevarte e-posten.

SHA-256 for privat, usladdet EML: f7007ed3053d3ba2ef71ea01c74ec0c4aebfd48417f757ecec8d9d7d5884bf33

---

4. Svaret vårt etter at vi oppdaget hooken

E-post / identifiserende opplysninger erstattet

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

Svaret vårt etter at vi oppdaget hooken. Anonymisert publiseringsvisning av den bevarte e-posten.

SHA-256 for privat, usladdet EML: 31df91adb2eb52be2171836d3e26610328a0a1a1273dbf7d56efe4354bb62e19

---

• Anonymisert hook, alle 101 linjer
• TAR-hode og begynnelsen av fildataene
• Alle 24 Git-objekter
• DOCX-blobb før og etter zlib
• Dump av NDA-treet
• Alle 16 blobber og deres første byte
• Alle DOCX-deler
• Gzip- og TAR-grenser
• Maskinlesbar inspeksjon på bytenivå
• Lagrede observasjoner av de tre endepunktene
• Figurkilder og hasher
• Korrespondansens opphav

Anonymisert visning av hele hooken

Alle 101 linjenumre i kilden er beholdt. Identifiserende opplysninger er dekket med grå rektangler.

---

Usladdede originaler oppbevares privat. Offentlige bevisfiler bruker plassholdere, og skjermbilder bruker ugjennomsiktige grå rektangler. Hasher merket som original identifiserer den private kilden, ikke en redigert publiseringskopi. Figurene er skjermbilder av lokale bevisvisninger der identifiserende tekst ble fjernet før gjengivelse. Ingen mottatt kode ble kjørt.