SToFU Systems · Ricerca sull'incidente · 20 ottobre 2026
Indice
- Tutto è iniziato con una richiesta di sviluppo
- Download e ispezione dei file
- Come poteva essere eseguito l'hook post-checkout di Git
- Cosa fa il downloader dell'hook di Git
- C'era un'applicazione nascosta nell'archivio?
- Cosa ha restituito il server di download
- Poteva trattarsi di un'utilità legittima?
- Esaminare un repository Git sconosciuto
- Dopo l'analisi dell'archivio
- Corrispondenza e file delle evidenze
Tutto è iniziato con una richiesta di sviluppo
Il primo messaggio è arrivato tramite il nostro sito web il 15 ottobre 2026. Il mittente chiedeva aiuto per realizzare una piattaforma per il rilevamento delle frodi finanziarie. Il sistema proposto avrebbe assegnato punteggi di rischio alle transazioni e utilizzato l'analisi comportamentale, con verifica tramite blockchain e rendicontazione tra gli altri requisiti.
Il 19 ottobre abbiamo ricevuto il link per il download. L'email di accompagnamento ci indirizzava al branch conf per l'architettura e al branch NDA per l'accordo. Ribadiva la richiesta di esaminare e firmare l'NDA.
Please review the project materials and review and sign the NDA in the NDA branch.
Seguendo quelle istruzioni, chi esaminava il materiale sarebbe passato dall'estrazione dell'archivio al cambio di branch in Git. L'email presentava entrambe le operazioni come parte della lettura della documentazione. Non menzionava l'esecuzione di un programma scaricato.
L'email con l'archivio del progetto e le istruzioni per aprire il branch NDA. I dettagli identificativi sono coperti da rettangoli grigi.
Download e ispezione dei file
Il link portava a una normale pagina di condivisione file di Dropbox. Abbiamo scaricato AI-Fraud-Detection_Blockchain.tar.gz in un ambiente di analisi isolato e conservato l'archivio originale come riferimento. L'URL specifico di condivisione non viene pubblicato qui.
Abbiamo elencato il contenuto dell'archivio e letto direttamente gli oggetti Git forniti. Questo ci ha consentito di recuperare i documenti da tutti e tre i branch senza effettuare il checkout di un branch né eseguire il codice fornito. Negli alberi dei branch abbiamo trovato 15 file Markdown e un documento Word.
| Branch | File | Cosa abbiamo trovato |
|---|---|---|
master |
8 file Markdown | Un README, una panoramica del progetto, requisiti di prodotto e casi d'uso aziendali. Altri documenti trattavano prestazioni, sicurezza, test e operazioni. |
conf |
7 file Markdown | Indicazioni per una proposta di sviluppo, architettura e integrazione blockchain, requisiti degli smart contract, progettazione dei dati e delle API, un motore di rischio basato sull'IA e tappe di consegna. |
NDA |
1 file DOCX | Un accordo di riservatezza con uno spazio per la firma e segnaposto del modello. |
Il prodotto proposto combinava analisi delle transazioni, regole antifrode e punteggi di apprendimento automatico con la verifica tramite blockchain. Lo stack suggerito utilizzava Node.js e TypeScript con Express, PostgreSQL, librerie Python per l'apprendimento automatico ed Ethereum. Il documento sulle consegne prevedeva sei tappe in 24 settimane. Negli alberi forniti abbiamo trovato documenti di pianificazione, senza alcuna implementazione applicativa, modello addestrato o codice sorgente di smart contract da esaminare.
Alcuni dettagli meritavano un secondo sguardo. Gli esempi delle API contenevano le stringhe letterali <built-in function id> e <built-in function hash> nei percorsi degli endpoint. L'NDA conteneva ancora segnaposto del modello. Queste incongruenze sollevavano dubbi sulla cura con cui era stato preparato il materiale.
Il file eseguibile .git/hooks/post-checkout era una scoperta più seria. I suoi commenti descrivevano un'utilità per aggiornare un browser o un'estensione, senza alcun legame apparente con l'esame del progetto. La lettura dello script ha rivelato istruzioni per scaricare un programma esterno e avviarlo in background. La richiesta nell'email di cambiare branch poteva portare chi tentava di leggere l'NDA su quel percorso di esecuzione.
Abbiamo mantenuto inattivo il repository ed esaminato l'hook come testo. Di seguito riportiamo i metadati pertinenti dell'archivio e il comportamento dello script.
Come poteva essere eseguito l'hook post-checkout di Git
Il file AI-Fraud-Detection_Blockchain.tar.gz è lungo 779,429 byte. Le sue 100 voci TAR includono 60 file regolari. Insieme ai documenti è arrivata una directory .git completa.
La directory degli hook conteneva i consueti file .sample e un eseguibile denominato post-checkout.
AI-Fraud-Detection_Blockchain/.git/hooks/post-checkoutNon è presente il suffisso .sample. Il suo mode TAR è 0777, che comprende i permessi di esecuzione, e la sua lunghezza è di 2,774 byte.
Git richiama post-checkout dopo aver aggiornato l'albero di lavoro tramite operazioni quali checkout o switch, purché l'ambiente consenta l'esecuzione dell'hook. La documentazione di Git descrive l'evento di attivazione.
Perché la directory .git nell'archivio è rilevante
Un normale git clone non copia gli hook locali lato client del repository sorgente, come spiega Pro Git. Questa consegna includeva la directory .git esistente all'interno di un archivio, quindi anche l'hook locale era incluso.
Il percorso, il mode e la dimensione dell'hook letti direttamente dal TAR originale. Non abbiamo utilizzato la directory ricevuta come repository Git.
Abbiamo ispezionato direttamente il contenitore e gli oggetti Git, senza eseguire checkout o switch sul repository ricevuto.
Cosa fa il downloader dell'hook di Git
I commenti nello script shell descrivono un'utilità per aggiornare un browser o un'estensione. Nei documenti del progetto non abbiamo trovato alcun requisito per un'utilità del genere. Lo script è testo semplice non offuscato.
La soglia di dimensione inutilizzata
Lo script imposta THRESHOLD a 100 e chiede a Git un elenco dei nomi dei file modificati. Inizializza TRIGGER a zero.
THRESHOLD=100
FILES=$(git diff --name-only "$OLD_HEAD" "$NEW_HEAD")
TRIGGER=0All'interno del ciclo calcola SIZE. Non c'è alcun confronto con THRESHOLD né un'assegnazione che modifichi TRIGGER. Il blocco di download viene eseguito quando TRIGGER è zero.
if [ "$TRIGGER" -eq 0 ]; thenNel normale percorso di esecuzione dello script, la condizione è vera anche quando l'elenco dei file modificati è vuoto. La soglia non limita il download.
Numeri di riga originali conservati. TRIGGER rimane a zero. THRESHOLD è dichiarato ma non viene mai usato in un confronto.
Download separati per Linux, macOS e Windows
Il valore restituito da uname -s determina il percorso di download e il nome del file locale.
| Sistema rilevato | Percorso sul server | Nome del file locale |
|---|---|---|
| Linux | /api/l |
run-command.sh |
| Darwin / macOS | /api/m |
run-command.sh |
| MINGW, MSYS, CYGWIN, Windows_NT | /api/w |
run-command.cmd |
| Sistema non riconosciuto | /api/l |
run-command.sh |
Gli URL condividono un unico host, sostituito qui con <DOWNLOAD_DOMAIN>. Abbiamo conservato privatamente l'hook non oscurato. Le diramazioni coprono Linux, macOS e Windows, con un ripiego su Linux per un sistema non riconosciuto. Non abbiamo testato l'esecuzione su questi sistemi.
Download del file e tentativo di esecuzione
L'hook salva il file in ${TMPDIR:-/tmp} usando curl, oppure wget se curl non è disponibile. Prima delle successive istruzioni di esecuzione non viene controllata alcuna firma né alcun hash atteso.
chmod +x "$CMD_FILE"
"$CMD_FILE" > /dev/null 2>&1 &La e commerciale finale avvia il comando in background. Sia l'output standard sia l'errore standard vengono inviati a /dev/null.
Dopo il tentativo di esecuzione, l'hook scrive azuku in .git-checker nella directory temporanea. Non verifica mai la presenza di quel marcatore prima di scaricare di nuovo. Né attende che il processo in background abbia successo prima di scrivere il file. Il marcatore potrebbe quindi esistere anche dopo un tentativo di esecuzione non riuscito.
Le istruzioni originali di download, chmod, esecuzione in background e scrittura del marcatore. Il programma di secondo stadio non è presente in questo estratto.
Un commento verso la fine indica di rimuovere la directory temporanea di download. Sotto di esso non c'è alcun comando di rimozione.
C'era un'applicazione nascosta nell'archivio?
Il download dalla rete ha sollevato un'altra domanda. Nell'archivio era già presente un'applicazione, magari nella cronologia di Git o nell'NDA? Abbiamo esaminato i confini dei contenitori, poi decodificato ogni oggetto Git fornito e ispezionato il contenuto del DOCX.
I confini dell'archivio
Abbiamo registrato lo SHA-256 dell'archivio originale prima di ispezionarne il contenuto.
6f44ff4e461828dd1fe6ede75ca8d9d4b579c2ac223463629e9a7537b9df5040La decompressione di gzip come dati ha prodotto un flusso TAR di 890,880 byte. Il flusso gzip terminava correttamente, senza byte inutilizzati dopo la sua fine. Gli ultimi 5,120 byte dopo l'ultima voce TAR erano riempimento con zeri.
Abbiamo quindi esaminato i file e gli oggetti riconducibili alle voci di quei contenitori.
Controlli salvati sulla fine del flusso gzip e sul riempimento TAR. Non è stato eseguito alcun codice del campione.
Individuazione dell'hook nell'intestazione TAR
L'intestazione della voce post-checkout inizia a 0xCF600, ovvero 849,408, nel TAR decompresso. I dati del file iniziano a 849,920. Questi offset si riferiscono al flusso TAR, non al file .gz compresso.
A quell'offset, l'intestazione inizia con il percorso di post-checkout.
TAR / dump esadecimale
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 un'intestazione TAR, mode occupa i byte [100:108] e size occupa [124:136]. I campi decodificati di questa voce seguono il dump.
| Campo TAR | Byte grezzi / valore |
|---|---|
| mode | b'0000777\x00' |
| size | b'00000005326\x00' |
| Mode ottale | 0777 |
| Dimensione decimale | 2774 byte |
| Checksum memorizzato / calcolato | 10301 / 10301 |
La dimensione ottale decodificata corrisponde a 2,774 byte. Il checksum memorizzato nell'intestazione è 10,301. Ricalcolandolo con il campo del checksum riempito di spazi si ottiene lo stesso risultato.
L'intestazione TAR grezza dell'hook e i campi decodificati. Il nome, i permessi e la dimensione sono visibili nei byte del contenitore.
Abbiamo inoltre calcolato l'hash dell'hook estratto da questa voce.
854b3b88b06fad9d9ffec36b35be0133b1d502084d4d7cce232eda2b2dd03092Il dump della voce TAR e l'hook anonimizzato sono inclusi nell'articolo. L'hash sopra identifica l'originale non oscurato conservato privatamente, non la copia oscurata pubblicata.
Lettura degli oggetti Git senza checkout
Sono presenti 24 oggetti non impacchettati in .git/objects, ciascuno memorizzato in un flusso zlib. I dati decompressi contengono un'intestazione Git seguita dal corpo dell'oggetto.
<type> <size>\0<body>Abbiamo verificato la lunghezza dichiarata del corpo e calcolato lo SHA-1 sull'intera sequenza decodificata, compresi l'intestazione e il byte NUL. Il risultato deve corrispondere all'ID dell'oggetto nel nome del file. Questo verifica l'integrità dell'oggetto. Non dice nulla su chi lo abbia creato.
Per ogni oggetto abbiamo confrontato la lunghezza dichiarata con quella del corpo e verificato l'hash su tutti i dati decodificati.
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_idAbbiamo controllato anche la fine dei flussi zlib. Gli oggetti risultano essere 16 blob, 5 tree e 3 commit. Seguendo le teste dei tre branch, i loro commit genitori e i tree figli si ricostruiscono tutti i 24 oggetti. Tra gli oggetti forniti non ci sono blob irraggiungibili.
Git / relazioni tra commit
master 4bc26f6c18910ca777c8238d2f88f6e725fcdc3f
tree feb0feaf7b8e826b085e90dea5399772d7b91f02
parent (none)
conf 239b9aa2edc8c5e21fddeea5ed0e937496ae013f
tree 048b51f9673f94354251ce16a78e663c71667a4c
parent 4bc26f6c18910ca777c8238d2f88f6e725fcdc3f
NDA a1311875d86bf6f1a6b9f2fee6527abbd1ce647d
tree cc020d922090835ea4ac3a3e418d0213d7a2ad94
parent 239b9aa2edc8c5e21fddeea5ed0e937496ae013fL'inventario completo degli oggetti include gli oggetti esterni all'albero di lavoro corrente.
Inventario di tutti i 24 oggetti Git
| ID oggetto | Tipo | Corpo, 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 |
Lunghezza e SHA-1 verificati sulla codifica Git originale di ogni oggetto. Tutti i 24 controlli sono stati superati.
Seguire l'NDA dal suo tree ai suoi byte
Il branch NDA punta a un tree contenente un solo file, Non-Disclosure-Agreement.docx. Una voce di un tree Git memorizza il mode e il nome del file come testo, seguiti da un NUL e da 20 byte grezzi per l'ID del blob. Abbiamo analizzato la voce direttamente dal corpo del tree.
Albero Git / dump esadecimale
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.\.-.|
Byte grezzi del tree NDA e riferimento decodificato al relativo blob DOCX.
Quella voce fa riferimento al blob seguente.
5a51550933b593eb65da458bbdd579f85c082dabDopo la decompressione zlib, l'oggetto inizia con blob 752100\0. Subito dopo l'intestazione si trovano i byte 50 4b 03 04, la firma PK di un contenitore ZIP.
Blob Git / dopo la decompressione zlib
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|
Byte dell'oggetto compresso, intestazione Git decodificata e inizio del DOCX. La lunghezza e l'ID dell'oggetto sono stati verificati sull'oggetto completo.
Il corpo è lungo 752,100 byte. Il suo SHA-256 corrisponde al DOCX che abbiamo salvato separatamente per l'analisi.
9d85170d2c0aa7a9b90dfc3855715a31d971bba7abb563e9efa1153fdc15634fQuesti oggetti ricostruiscono il percorso dal branch NDA ai byte del documento.
Ricostruzione di tutti i 16 blob
Quindici blob si decodificano come documenti di progetto Markdown in UTF-8. Il blob rimanente è il DOCX sopra descritto. Nessuno inizia con un'intestazione PE, ELF o Mach-O.
| Percorso nei tree | Dimensione, byte | Tipo / primi byte |
|---|---|---|
| 04-solution-proposal-guidance.md | 2054 | Testo UTF-8 · 23 20 44 65 76 65 6c 6f 70 6d 65 6e 74 20 43 6f |
| 06-blockchain-architecture.md | 6497 | Testo UTF-8 · 23 20 42 6c 6f 63 6b 63 68 61 69 6e 20 41 72 63 |
| 07-blockchain-integration-specification.md | 2807 | Testo UTF-8 · 23 20 42 6c 6f 63 6b 63 68 61 69 6e 20 49 6e 74 |
| 08-smart-contract-specification.md | 2610 | Testo UTF-8 · 23 20 53 6d 61 72 74 20 43 6f 6e 74 72 61 63 74 |
| 09-data-and-api-architecture.md | 2776 | Testo UTF-8 · 23 20 44 61 74 61 20 26 20 41 50 49 20 41 72 63 |
| 11-ai-fraud-and-risk-engine.md | 3062 | Testo UTF-8 · 23 20 41 49 20 46 72 61 75 64 20 44 65 74 65 63 |
| 14-deliverables-acceptance-and-milestones.md | 6316 | Testo UTF-8 · 23 20 44 65 6c 69 76 65 72 61 62 6c 65 73 2c 20 |
| Detailed/03-business-and-use-cases.md | 3061 | Testo UTF-8 · 23 20 42 75 73 69 6e 65 73 73 20 52 65 71 75 69 |
| Detailed/05-non-functional-requirements.md | 2033 | Testo UTF-8 · 23 20 4e 6f 6e 2d 46 75 6e 63 74 69 6f 6e 61 6c |
| Detailed/10-security-and-privacy-requirements.md | 2433 | Testo UTF-8 · 23 20 53 65 63 75 72 69 74 79 20 26 20 50 72 69 |
| Detailed/12-testing-and-quality-requirements.md | 2425 | Testo UTF-8 · 23 20 54 65 73 74 69 6e 67 20 26 20 51 75 61 6c |
| Detailed/13-deployment-monitoring-and-operations.md | 2281 | Testo UTF-8 · 23 20 44 65 70 6c 6f 79 6d 65 6e 74 2c 20 4d 6f |
| Intro/01-project-overview.md | 8402 | Testo UTF-8 · 23 20 50 72 6f 6a 65 63 74 20 4f 76 65 72 76 69 |
| Intro/02-product-requirements.md | 3191 | Testo UTF-8 · 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 | Testo UTF-8 · 23 20 41 49 20 46 72 61 75 64 20 44 65 74 65 63 |
Tutti i 16 blob forniti sono stati classificati. I tree contengono documenti di progetto; non è stata trovata alcuna implementazione del prodotto.
Abbiamo letto i corpi testuali oltre a verificarne le firme. Il DOCX era l'unico blob non testuale e richiedeva un'ispezione separata del contenitore.
Apertura del DOCX come ZIP
Il documento contiene 25 voci ZIP, costituite da 17 parti di file e 8 directory. Abbiamo letto ogni parte di file e verificato il relativo CRC.
| Parte DOCX | Dimensione, 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 |
Nomi delle parti DOCX, lunghezze e valori CRC32. Abbiamo ispezionato i dati ZIP e XML senza aprire il documento in Office.
Nell'elenco delle parti non è presente vbaProject.bin né un allegato OLE. Due file PNG contengono un logo e l'immagine di una firma. Abbiamo inoltre ispezionato le relazioni XML e trovato un riferimento al percorso di un modello Office locale sul computer dell'autore del documento. Non lo abbiamo risolto né caricato.
L'immagine della firma e i campi autore di Git non offrono un modo affidabile per identificare il mittente. Entrambi possono essere copiati o sostituiti.
Nel contenuto fornito non abbiamo trovato un'applicazione separata né un'implementazione del prodotto. L'hook ottiene il programma successivo tramite la rete. La nostra ispezione dei contenitori non esclude ogni possibile exploit o tecnica steganografica.
Cosa ha restituito il server di download
Abbiamo recuperato i tre URL esatti come dati, senza eseguire le risposte né seguire reindirizzamenti. Il 19 ottobre, tra le 17:29:27 e le 17:29:28 UTC, ciascuno ha restituito HTTP 200. Tutti e tre i corpi contenevano lo stesso messaggio di 21 byte.
Permanently suspended
Le tre osservazioni salvate degli endpoint. Durante la preparazione di questo articolo non abbiamo effettuato ulteriori richieste agli URL del downloader.
Non disponiamo di byte del secondo stadio su cui effettuare reverse engineering. Non sappiamo neppure cosa abbiano restituito quegli endpoint in precedenza, a un altro visitatore o in condizioni di richiesta diverse. Il messaggio di sospensione non fornisce alcuna spiegazione verificata del motivo per cui il servizio sia stato sospeso.
L'hook tenta di scaricare ed eseguire un file esterno. Affermazioni su furti di password, token, codice sorgente o wallet richiederebbero evidenze che non abbiamo.
Poteva trattarsi di un'utilità legittima?
Un programma di aggiornamento interno potrebbe finire per errore in un archivio. Gli hook di Git, i processi in background e curl hanno tutti usi legittimi.
In questo materiale, l'email ci chiedeva esplicitamente di passare a un altro branch. Farlo poteva richiamare il downloader fornito, sebbene il motivo dichiarato del cambio di branch fosse leggere un accordo. L'email non menzionava l'esecuzione. Non abbiamo inoltre trovato alcun legame tra un programma di aggiornamento del browser e il sistema proposto, e il controllo delle dimensioni nello script era incompleto.
Abbiamo trattato il materiale come un tentativo di attacco tramite consegna di codice e impedito l'esecuzione dell'hook. Per riconsiderare questa valutazione servirebbero i sorgenti dei file scaricati e una spiegazione verificabile del motivo per cui un fornitore dovesse eseguirli per esaminare l'NDA.
Non abbiamo accertato l'identità dell'operatore. L'indirizzo del mittente, i metadati dei commit e i nomi all'interno del documento non sono sufficienti per un'attribuzione.
Diagramma di analisi delle fasi di esecuzione descritte dall'hook fornito.
Esaminare un repository Git sconosciuto
Uno sviluppatore che avesse seguito l'email avrebbe potuto raggiungere l'evento di attivazione dell'esecuzione mentre stava ancora leggendo del progetto. Non era necessario compilare o avviare l'applicazione proposta.
Se esaminate materiale inviato dai clienti su un computer con chiavi SSH di produzione o token cloud, uno script inatteso potrebbe avere accesso a queste risorse. Un ambiente usa e getta deve mantenere tali credenziali fuori portata. Le sessioni del browser sul computer di analisi meritano la stessa attenzione.
La verifica dovrebbe comprendere la directory .git fornita e qualsiasi automazione dell'IDE prima che un tecnico inizi a usare i comandi abituali. Anche gli script di installazione richiedono attenzione. Nei log dell'host cercheremmo Git o una shell che scarica un file in una directory temporanea e poi lo esegue. Un processo curl da solo ci dice molto meno.
Conservare l'email e l'archivio originali consente a chi effettuerà un'analisi successiva di verificare cosa sia stato consegnato. Gli hash e gli eventi dell'host aiutano a stabilire cosa sia accaduto sul computer. L'assenza di un marcatore non può dimostrare che un programma non sia mai stato eseguito.
Scaricare o estrarre l'archivio può eseguire questo hook?
Il download e la normale estrazione non richiamano di per sé l'hook post-checkout di Git. In questo campione, l'evento di attivazione documentato è l'aggiornamento dell'albero di lavoro da parte di Git tramite checkout o switch, quando l'esecuzione degli hook è consentita. Abbiamo ispezionato direttamente gli oggetti forniti senza richiamare queste operazioni.
Dopo l'analisi dell'archivio
Ci aspettavamo che lo scambio successivo riguardasse l'architettura e le date di consegna. Abbiamo invece inviato una risposta sull'hook e conservato il materiale per ulteriori analisi. Non possiamo ancora dire cosa facesse il programma remoto o chi lo gestisse. L'hook ci ha dato ragioni sufficienti per interrompere il flusso di lavoro Git richiesto.
Da oltre cinque anni, SToFU Systems e le nostre soluzioni aiutano le aziende a proteggere i propri sistemi, anche da attacchi veicolati attraverso corrispondenza commerciale e materiali di sviluppo. I nostri audit di sicurezza esaminano come codice e accessi possano essere usati impropriamente. Offriamo anche reverse engineering quando un team deve comprendere software sconosciuto.
Se un repository o un binario solleva dubbi, parlate con il nostro team di una verifica tecnica prima di introdurlo nel vostro normale ambiente di sviluppo.
Corrispondenza e file delle evidenze
I quattro messaggi riportati di seguito usano segnaposto per nomi di persone, indirizzi, identità di terzi e link identificativi. Il resto del testo dei nuovi messaggi è conservato. Le citazioni ripetute sono omesse perché ogni email compare separatamente. Anche l'IP del servizio del modulo web e gli indirizzi dei destinatari non pertinenti sono omessi.
1. La prima richiesta tramite il nostro sito web
Email / dati identificativi sostituiti
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.
---
La prima richiesta tramite il nostro sito web. Versione anonimizzata per la pubblicazione dell'email conservata.
SHA-256 dell'EML privato non oscurato: bf7d0f3a59b84f509ca436e0750640e844e9731ce363a42a99d5be60cdf8597e
2. La nostra risposta con la richiesta dei materiali
Email / dati identificativi sostituiti
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>
La nostra risposta con la richiesta dei materiali. Versione anonimizzata per la pubblicazione dell'email conservata.
SHA-256 dell'EML privato non oscurato: 1e5330dd82e02911254722744a3202e9b761c8c1d2950be937cd5d539c1bcad9
3. L'email con l'archivio che indica i branch NDA / conf
Email / dati identificativi sostituiti
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>
L'email con l'archivio che indica i branch NDA / conf. Versione anonimizzata per la pubblicazione dell'email conservata.
SHA-256 dell'EML privato non oscurato: f7007ed3053d3ba2ef71ea01c74ec0c4aebfd48417f757ecec8d9d7d5884bf33
4. La nostra risposta dopo la scoperta dell'hook
Email / dati identificativi sostituiti
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
La nostra risposta dopo la scoperta dell'hook. Versione anonimizzata per la pubblicazione dell'email conservata.
SHA-256 dell'EML privato non oscurato: 31df91adb2eb52be2171836d3e26610328a0a1a1273dbf7d56efe4354bb62e19
- Hook anonimizzato, tutte le 101 righe
- Intestazione TAR e inizio dei dati del file
- Tutti i 24 oggetti Git
- Blob DOCX prima e dopo zlib
- Dump del tree NDA
- Tutti i 16 blob e i loro primi byte
- Tutte le parti DOCX
- Confini gzip e TAR
- Ispezione a livello di byte in formato leggibile da macchina
- Osservazioni salvate dei tre endpoint
- Fonti delle figure e hash
- Provenienza della corrispondenza
Vista anonimizzata dell'hook completo
Tutti i 101 numeri di riga del sorgente sono conservati. I dettagli identificativi sono coperti da rettangoli grigi.
Gli originali non oscurati sono conservati privatamente. I file pubblici delle evidenze usano segnaposto e gli screenshot usano rettangoli grigi opachi. Gli hash contrassegnati come originali identificano la fonte privata, non una copia modificata per la pubblicazione. Le figure sono screenshot di viste locali delle evidenze, con il testo identificativo rimosso prima del rendering. Non è stato eseguito alcun codice ricevuto.
