sif

installation · utilisation · modules · documentation · contribuer

reconnaissance rapide et concurrente jusqu'à l'exploitation en un seul binaire. chaque scanner partage un client HTTP avec pool de connexions.

qu'est-ce que sif ?

sif est un scanner de reconnaissance et d'exploitation qui exécute toute la chaîne en un seul binaire : énumération de sous-domaines, scan de ports, crawler, nuclei, détection de frameworks/CVE, extraction de secrets JS, sondes de vulnérabilités web (CORS/XSS/redirection), vérifications cloud et de prise de contrôle. 25+ types de scan, une seule commande.

sif -u https://example.com -dnslist -ports -crawl -js -framework -nuclei

nuclei et colly sont compilés en tant que bibliothèques plutôt que d'être invoqués via un shell (il n'y a pas de exec.Command dans l'arborescence), ce qui donne un binaire statique unique sans dépendances d'exécution et sans rien à connecter.

chaque scanner passe par un seul client HTTP partagé et un pool de travailleurs avec vol de tâches. -proxy, -H, -cookie et -rate-limit s'appliquent à l'ensemble de la session en une fois, les connexions sont mises en pool et réutilisées tout au long du scan (un scan sur un seul hôte réutilise une connexion pour ~50 requêtes au lieu d'établir 50 connexions), et un hôte lent ne bloque pas les autres. Ce client partagé est la raison pratique d'utiliser cet outil plutôt que d'enchaîner une pile d'outils séparés. Le scan de ports est basé sur connect(), donc rustscan et nmap sont toujours plus rapides pour les scans de ports bruts.

il lit les cibles depuis stdin et affiche les résultats un par ligne sous -silent, ce qui permet la composition :

subfinder -d example.com | sif -silent -crawl -js -nuclei | notify

-diff transforme une renumérisation en moniteur qui ne rapporte que ce qui a changé, -notify envoie les résultats vers slack/discord/telegram/webhook, et exporte au format sarif et markdown.

installation

homebrew (macos)

brew tap vmfunc/sif
brew install sif

arch linux (aur)

installez en utilisant votre assistant AUR préféré :

yay -S sif
# ou
paru -S sif

nix

# nixpkgs (déclaratif : ajouter à configuration.nix ou home-manager)
environment.systemPackages = [ pkgs.sif ];

# ou de manière impérative
nix profile install nixpkgs#sif

# ou simplement l'exécuter sans installer
nix run nixpkgs#sif -- -u https://example.com -headers -sh -framework

le dépôt fournit également un flake si vous voulez construire depuis les sources :

nix run github:vmfunc/sif

debian/ubuntu (apt)

curl -1sLf 'https://dl.cloudsmith.io/public/sif/deb/setup.deb.sh' | sudo -E bash
sudo apt-get install sif

depuis les releases

téléchargez le dernier binaire depuis releases.

depuis les sources

git clone https://github.com/vmfunc/sif.git
cd sif
make

nécessite go 1.25+

aur (installation manuelle)

git clone https://aur.archlinux.org/sif.git
cd sif
makepkg -si

utilisation

# scan basique
./sif -u https://example.com

# fuzzing de répertoires
./sif -u https://example.com -dirlist medium

# énumération de sous-domaines
./sif -u https://example.com -dnslist medium

# scan de ports
./sif -u https://example.com -ports common

# détection de framework JavaScript + mauvaise configuration cloud
./sif -u https://example.com -js -c3

# renseignements sur l'hôte via shodan (nécessite la variable d'environnement SHODAN_API_KEY)
./sif -u https://example.com -shodan

# découverte de domaine via securitytrails (nécessite la variable d'environnement SECURITYTRAILS_API_KEY)
# découvre les sous-domaines + domaines associés, puis scanne tous
./sif -u https://example.com -securitytrails -headers

# recon SQL + scan LFI
./sif -u https://example.com -sql -lfi

# sondes de vulnérabilités web (cors, open redirect, xss réfléchi)
./sif -u https://example.com -cors -redirect -xss

# détection de framework (avec recherche CVE)
./sif -u https://example.com -framework

# une large inspection
./sif -u https://example.com -dirlist small -dnslist small -ports common -headers -sh -cms -framework -git -whois

exécutez ./sif -h pour toutes les options.

commandes

quelques sous-commandes s'exécutent sans scan :

# affiche la version (les builds de release sont estampillés ; les builds locales utilisent git describe)
./sif version

# affiche les notes de la dernière version (également -pn)
./sif patchnote

la première fois que vous exécutez une nouvelle version, sif affiche les notes de cette version une seule fois. définissez SIF_NO_PATCHNOTES=1 pour désactiver.

modules

sif a une architecture modulaire. les modules sont définis en yaml et peuvent être étendus par les utilisateurs.

drapeaux de scan intégrés

options HTTP

ces options s'appliquent à chaque requête sortante sur tous les scanners :

# scan via un proxy socks5 avec un en-tête personnalisé, un cookie et une limite de 20 req/s
./sif -u https://example.com -headers -proxy socks5://127.0.0.1:1080 -H "Authorization: Bearer tok" -cookie "session=abc" -rate-limit 20

un scanner qui définit explicitement un en-tête (ex. une clé API) l'emporte toujours sur la valeur globale par défaut.

export de rapport

écrit les résultats de l'exécution dans un fichier pour CI/CD ou triage :

# scan et émission des rapports SARIF et Markdown
./sif -u https://example.com -headers -cors -sarif out.sarif -md out.md

la sortie SARIF peut être ingérée par GitHub Code Scanning ; le Markdown est un résumé lisible par cible.

mode diff

-diff transforme une renumérisation en moniteur : sif capture les résultats normalisés de chaque cible dans un fichier json, et lors de la prochaine exécution ne rapporte que le delta (+ nouveau / - disparu) par rapport à cette capture, puis la remplace. La première exécution pour une cible n'a pas de base de référence, donc tout est + nouveau. Les captures atterrissent dans -store (un fichier nettoyé par cible) ; lorsqu'il n'est pas défini, il réutilise le répertoire de logs, en dernier recours <user-config>/sif/state.

# exécution de base, puis re-scan plus tard pour voir seulement ce qui a bougé
./sif -u https://example.com -sh -cors -diff
./sif -u https://example.com -sh -cors -diff

la capture est toujours réécrite, donc chaque exécution fait un diff par rapport à la précédente. Le delta est du chrome (il emprunte le flux de sortie normal / stderr sous -silent), pas le flux de résultats.

notification

expédie les résultats vers un sink de chat/webhook pour qu'une exécution de reconnaissance continue alerte sur ce qu'elle découvre. Chaque fournisseur est un unique POST via le client HTTP partagé, donc la configuration globale de proxy/limite de débit/en-tête s'applique.

les fournisseurs sont configurés d'abord par variables d'environnement ; un fichier yaml (-notify-config) remplace par champ. Les clés yaml correspondent à projectdiscovery/notify donc une config existante se transpose :

# alerter Slack sur les résultats de sévérité medium+ découverts pendant un scan
export SLACK_WEBHOOK_URL=https://hooks.slack.com/services/...
./sif -u https://example.com -cors -xss -notify -notify-severity medium

un fournisseur sans destination est ignoré ; sans rien de configuré, -notify est un no-op silencieux. Slack/Discord/Telegram reçoivent un bloc de résultats à largeur fixe ; le webhook générique reçoit du json structuré ({count, findings[]}).

mode pipe

sif lit les cibles depuis stdin et accepte les hôtes nus, il s'insère donc dans un pipeline Unix. -silent redirige tout le chrome (bannière, spinner, logs) vers stderr et affiche un résultat normalisé par ligne ([sévérité] cible module titre) sur stdout :

# subfinder alimente les hôtes, sif les sonde, notify expédie les résultats
subfinder -d example.com | sif -silent -probe | notify

les hôtes sans schéma par défaut utilisent https:// ; un http:///https:// explicite est conservé ; tout autre schéma (ftp://, ...) est rejeté.

modules yaml

lister les modules disponibles :

./sif -lm

exécuter des modules spécifiques :

# par id
./sif -u https://example.com -m sqli-error-based,xss-reflected

# par tag
./sif -u https://example.com -mt owasp-top10

# tous les modules
./sif -u https://example.com -am

modules personnalisés

créez vos propres modules dans ~/.config/sif/modules/. les modules utilisent un format yaml similaire aux templates nuclei :

id: my-custom-check
info:
  name: my custom security check
  author: you
  severity: medium
  description: checks for something specific
  tags: [custom, recon]

type: http

http:
  method: GET
  paths:
    - "{{BaseURL}}/admin"
    - "{{BaseURL}}/login"

  matchers:
    - type: status
      status:
        - 200

    - type: word
      part: body
      words:
        - "admin panel"
        - "login"
      condition: or

voir docs/modules.md pour le format complet des modules.

contribuer

les contributions sont les bienvenues. consultez contributing.md pour les directives.

# format
gofmt -w .

# lint
go run github.com/golangci/golangci-lint/v2/cmd/[email protected] run

# test
go test ./...

communauté

rejoignez notre discord pour du support, des discussions sur les fonctionnalités et des conseils de pentest :

contributeurs

remerciements

• projectdiscovery pour nuclei et d'autres outils de sécurité
• shodan pour l'intelligence d'infrastructure