
Triage dell'esposizione di credenziali e dati sensibili per condivisioni file
Triage dell'esposizione di credenziali e dati sensibili per le condivisioni di file.
Quando compare una condivisione aperta, la domanda non è mai "questo repo ha una chiave divulgata". È "cosa è stato esposto, e cosa devo revocare prima della chiusura dell'attività." sift è costruito per questa domanda: alto recall, una coda di revisione rapida e un ciclo di feedback per cui qualsiasi cosa individui a occhio diventa una regola che trova le altre duecento copie.

Python 3.11+, solo libreria standard. Niente pip install, niente internet, niente passaggi di build. Funziona su un laptop IR bloccato, che è dove ti serve.```bash sift survey \fileserver\openshare # how big is this thing sift copy \fileserver\openshare C:\IR\case-4471 # take a throttled copy sift scan C:\IR\case-4471 # scan it, opens the triage UI
Anche la scansione in loco funziona. Provatela prima su una condivisione di credenziali fittizie:```bash
sift demo C:\temp\demoshare
sift.cmd è un launcher che funziona da qualsiasi directory. Per digitare sift invece
del percorso completo, aggiungi C:\Dev\sift al PATH:```bash
setx PATH "%PATH%;C:\Dev\sift"
Per una macchina senza alcun Python, `python build_portable.py` genera
`dist/sift-secrets-<version>-portable-win64.zip`: il runtime incorporabile ufficiale di python.org più questo albero sorgente, da decomprimere ed eseguire tramite lo `sift.cmd` incluso. ~11 MB, nessuna installazione, nessun diritto di amministratore, e niente in esso è compilato o ricompattato — vedi la docstring in `build_portable.py` per capire perché questo batte un .exe congelato su un laptop IR bloccato.
---
## Perché non semplicemente gitleaks o trufflehog
Entrambi sono buoni strumenti che risolvono un problema diverso.
Sono strumenti di **precisione** pensati per la CI, dove un falso positivo costa a uno sviluppatore il pomeriggio, quindi scattano principalmente su elementi dalla forma simile a una chiave API nota di un vendor. trufflehog va oltre e preferisce segreti che può *verificare* chiamando l'API del vendor, un segnale davvero eccellente che le regex non possono riprodurre.
Il triage delle condivisioni ribalta l'economia. Un essere umano legge già ogni riscontro, quindi un falso positivo costa tre secondi. Ciò che ti costa è un **falso negativo**.
Le chiavi API dei vendor trapelano eccome nelle condivisioni - un backup della web root, uno script di deploy, la cartella di progetto di qualcuno copiata sull'unità dipartimentale, e c'è un `.env` con una chiave Stripe attiva dentro. Meritano di essere individuati, e sift li individua. Ma sono anche la parte che gitleaks e trufflehog già gestiscono bene. Il vuoto è tutto il resto, e su una condivisione file è la maggior parte:
| Cosa perdono gli scanner CI | Perché lo ignorano |
|---|---|
| `web.config` con una stringa di connessione SQL | Non è un formato di chiave noto, nessun vendor da verificare |
| `Map-Drives.ps1` con `net use ... /user:` | Solo un comando shell con una parola dopo |
| `New Hire Setup Guide.docx` | File Office, letto come binario, saltato del tutto |
| `unattend.xml`, GPP `Groups.xml` | Artefatti di distribuzione Windows per cui nessuno ha scritto un rilevatore |
| `confCons.xml`, `.rdg`, WinSCP.ini | Password memorizzate reversibili, ma non un "formato segreto" |
| `passwords.xlsx` | È uno ZIP. Gli scanner di testo semplice vedono binario e vanno avanti |
| `.kdbx`, `.pfx`, `id_rsa` | Byte opachi - il *nome del file* è il riscontro |
| Un `.bak` con una stringa di connessione dentro | Binario, quindi mai letto |
sift copre questi casi, include le proprie regole per chiavi vendor e **importa pacchetti di regole e riscontri di altri strumenti** - gitleaks TOML, Kingfisher/Titus YAML e trufflehog JSON - così non devi scegliere tra gli strumenti.
Il precedente più vicino è [Snaffler](https://github.com/SnaffCon/Snaffler), che è eccellente nella metà relativa a nomi file e classificazione e che è la diretta ispirazione per le regole sui nomi file. Ciò che non ha - e che si rivela essere il vero collo di bottiglia quando hai 400 riscontri - è un ciclo di revisione.
---
## Il ciclo
1. **Scansiona** la condivisione.
2. **Lavora la coda.** Ogni riscontro mostra le righe circostanti con la corrispondenza evidenziata. I tasti freccia ampliano il contesto; un clic apre l'intero file in VS Code su quella riga, o in Notepad.
3. **Individua un falso negativo.** Ti capiterà. Evidenzialo nell'anteprima e premi `r`.
4. **sift propone pattern** e ti dice in tempo reale quante volte ciascuno corrisponderebbe su tutto ciò che è già stato letto.
5. **Salva.** La riscansione in cache richiede circa un secondo, e i nuovi riscontri appaiono nella coda con le tue decisioni di triage esistenti intatte.
Il passaggio 5 è ciò che rende utile tutto il resto. I riscontri sono indicizzati su `(path, rule, line, value-hash)`, quindi una riscansione reinserisce le stesse righe e si porta dietro stato, note e proprietario. Senza questo, rirevisioneresti gli stessi 300 riscontri a ogni iterazione e ti arrenderesti alla terza.
---
## Comandi```bash
# size it up first: file count, total bytes, biggest folders, transfer estimates
sift survey \\fileserver\share
# take a rate-limited local copy (resumable; gentle = 5 MB/s by default)
sift copy \\fileserver\share C:\IR\case-4471 --speed gentle
# scan a share and open the triage UI
sift scan \\fileserver\share
# maximum recall: more noise, but a human is reading anyway
sift scan D:\dfs\dept --tier 3
# re-open the UI over the most recent scan
sift ui
# build a share of fabricated credentials, scan it, open the UI
sift demo C:\temp\demoshare
# inherit other tools' vendor-key rules, then use them in the live rescan loop
sift import-rules gitleaks.toml # gitleaks TOML
sift import-rules path/to/kingfisher/data/rules # a directory of YAML
# pull in what the other scanners found, into the same queue
trufflehog filesystem \\fileserver\share --json > th.json
sift import-findings th.json
# hand off to the incident record (redacted unless you say otherwise)
sift export --fmt pdf --status confirmed --out ir-4471.pdf
sift export --fmt csv --out ir-4471.csv
sift export --fmt pdf --no-redact # plaintext; handle as evidence
sift rules # what is loaded
sift selftest # detection tests against a synthetic share
# ask vendors whether confirmed findings are still live. NETWORK. Opt-in.
sift validate --status confirmed
Ovunque compaia sift puoi usare python -m sift in alternativa, dalla directory C:\Dev\sift.
| Flag | Effetto |
|---|---|
--tier 1|2|3 | Manopola del recall. 1 = segnale alto, 2 = predefinito, 3 = non perdere nulla |
--redact | Maschera i valori nello store e negli export. Usalo se il DB esce dal perimetro dell'incidente |
--no-ui | Popola lo store ed esce, per esecuzioni scriptate |
--no-browser | Avvia il server UI ma non aprire un browser (utile via RDP) |
--include/--exclude GLOB | Restringi l'esplorazione |
--no-archives | Non aprire i contenitori docx/xlsx/zip |
--no-strings | Non eseguire una passata strings sui binari |
--no-large | Salta i file oltre --max-size invece di leggerli a blocchi |
--jobs N | Processi worker (predefinito: auto) |
--max-size MB | Salta i file sopra questa dimensione (predefinito 25) |
--port N | Porta UI (predefinita 8973) |