Sift Secrets

Triage von offengelegten Zugangsdaten und sensiblen Daten in Dateifreigaben.

Wenn eine offene Freigabe auftaucht, lautet die Frage nie „Hat dieses Repository einen geleakten Schlüssel?“, sondern „Was wurde gerade offengelegt, und was muss ich noch vor Feierabend rotieren?“ Genau für diese Frage ist sift gebaut: hoher Recall, eine schnelle Review-Warteschlange und eine Feedback-Schleife, damit aus allem, was du mit bloßem Auge entdeckst, eine Regel wird, die die anderen zweihundert Kopien findet.

Python 3.11+, nur Standardbibliothek. Kein pip install, kein Internet, kein Build-Schritt. Es läuft auf einem abgeriegelten IR-Laptop – genau dort, wo du es brauchst.```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

Auch das Scannen an Ort und Stelle funktioniert. Probieren Sie es zuerst mit einer Freigabe mit erfundenen Anmeldedaten aus:```bash
sift demo C:\temp\demoshare

sift.cmd ist ein Launcher, der aus jedem Verzeichnis funktioniert. Um sift statt des vollständigen Pfads einzugeben, fügen Sie C:\Dev\sift zum PATH hinzu:```bash setx PATH "%PATH%;C:\Dev\sift"

Für eine Maschine ganz ohne Python erstellt `python build_portable.py` `dist/sift-secrets-<version>-portable-win64.zip`: die offizielle embeddable Laufzeitumgebung von python.org plus diesen Quellbaum, entpacken und ausführen über das gebündelte `sift.cmd`. ~11 MB, keine Installation, keine Admin-Rechte, und nichts darin ist kompiliert oder neu verpackt – siehe den Docstring in `build_portable.py` für die Begründung, warum das einem eingefrorenen .exe auf einem abgesicherten IR-Laptop überlegen ist.

---

## Warum nicht einfach gitleaks oder trufflehog

Beide sind gute Werkzeuge, die ein anderes Problem lösen.

Sie sind **Präzisions**werkzeuge, die für CI gebaut wurden, wo ein False Positive einem Entwickler den Nachmittag kostet – sie feuern also hauptsächlich auf Dinge, die wie ein bekannter Vendor-API-Schlüssel geformt sind. trufflehog geht noch weiter und bevorzugt Geheimnisse, die es *verifizieren* kann, indem es die API des Anbieters aufruft, ein wirklich exzellentes Signal, das Regex nicht reproduzieren kann.

Die Triage auf Dateifreigaben kehrt die Ökonomie um. Ein Mensch liest ohnehin jeden Treffer, ein False Positive kostet also drei Sekunden. Was dich etwas kostet, ist ein **Übersehen**.

Vendor-API-Schlüssel lecken definitiv auf Freigaben – ein Web-Root-Backup, ein Deployment-Skript, der Projektordner von jemandem aufs Abteilungslaufwerk kopiert, und da ist eine `.env` mit einem aktiven Stripe-Schlüssel drin. Die zu fangen lohnt sich, und sift fängt sie. Aber das ist auch der Teil, den gitleaks und trufflehog bereits gut abdecken. Die Lücke ist alles andere, und auf einer Dateifreigabe ist es der Großteil:

| Was die CI-Scanner übersehen | Warum sie daran vorbeigehen |
|---|---|
| `web.config` mit einer SQL-Verbindungszeichenfolge | Kein bekanntes Schlüsselformat, kein Anbieter zum Verifizieren |
| `Map-Drives.ps1` mit `net use ... /user:` | Nur ein Shell-Befehl mit einem Wort dahinter |
| `New Hire Setup Guide.docx` | Office-Datei, wird als Binärdaten gelesen, komplett übersprungen |
| `unattend.xml`, GPP `Groups.xml` | Windows-Deployment-Artefakte, für die niemand einen Detektor geschrieben hat |
| `confCons.xml`, `.rdg`, WinSCP.ini | Umkehrbar gespeicherte Passwörter, aber kein „geheimes Format“ |
| `passwords.xlsx` | Es ist eine ZIP. Klartext-Scanner sehen Binärdaten und machen weiter |
| `.kdbx`, `.pfx`, `id_rsa` | Undurchsichtige Bytes – der *Dateiname* ist der Fund |
| Eine `.bak` mit einer Verbindungszeichenfolge darin | Binär, also nie gelesen |

sift deckt diese ab, bringt eigene Vendor-Key-Regeln mit und **importiert die Regelpakete und Funde anderer Werkzeuge** – gitleaks-TOML, Kingfisher/Titus-YAML und trufflehog-JSON – du musst dich also nicht zwischen den Werkzeugen entscheiden.

Der nächste verwandte Ansatz ist [Snaffler](https://github.com/SnaffCon/Snaffler), der bei der Dateinamen-und-Klassifizierungs-Hälfte davon exzellent ist und die direkte Inspiration für die Dateinamen-Regeln darstellt. Was er nicht hat – und was sich als der eigentliche Engpass herausstellt, sobald du 400 Treffer hast – ist eine Review-Schleife.

---

## Die Schleife

1. **Scanne** die Freigabe.
2. **Arbeite die Warteschlange ab.** Jeder Fund zeigt die umgebenden Zeilen mit hervorgehobenem Treffer. Pfeiltasten erweitern den Kontext; ein Klick öffnet die gesamte Datei in VS Code an dieser Zeile, oder in Notepad.
3. **Entdecke einen übersehenen Fund.** Das wirst du. Markiere ihn in der Vorschau und drücke `r`.
4. **sift schlägt Muster vor** und zeigt dir live, wie oft jedes Muster auf alles bereits Gelesene passen würde.
5. **Speichere es.** Der gecachte Rescan dauert etwa eine Sekunde, und die neuen Treffer erscheinen in der Warteschlange, während deine bestehenden Triage-Entscheidungen unangetastet bleiben.

Schritt 5 ist der Teil, der den Rest lohnenswert macht. Funde sind auf `(path, rule, line, value-hash)` geschlüsselt, sodass ein Rescan dieselben Zeilen wieder einfügt und dein Status, deine Notizen und der Besitzer mitwandern. Ohne das würdest du bei jeder Iteration dieselben 300 Treffer erneut prüfen und beim dritten Mal aufgeben.

---

## Befehle```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

Überall, wo sift steht, kannst du stattdessen python -m sift verwenden, und zwar aus dem Verzeichnis C:\Dev\sift.

Wissenswerte Optionen