WIG (WebApp Information Gatherer)

Overview

WIG fingerprints web applications passively — it requests a set of known static files (JS, CSS, README/CHANGELOG files, favicons, etc.) and compares checksums/patterns against a large signature database to identify the CMS in use (WordPress, Drupal, Joomla, and many more), platform version, and often specific plugins or themes. It’s a useful early-recon step before targeting CMS-specific vulnerabilities.

Common Usage

Basic scan against a target

wig http://target.com

Increase verbosity to see individual signature matches

wig -v http://target.com

Limit request rate to avoid tripping WAF/rate-limiting

wig -n 5 http://target.com

Output results as JSON for pipeline integration

wig -q http://target.com -o results.json

Recon Workflow

1. Quick fingerprint of the target CMS and version

wig http://target.com

2. Cross-reference the identified version against known CVEs

searchsploit wordpress 5.8

3. Follow up with CMS-specific enumeration (wpscan for WordPress, droopescan for Drupal, etc.)

wpscan --url http://target.com --enumerate vp

Tips

• WIG is entirely passive/GET-based — safe for stealth-sensitive engagements where active scanners like WPScan’s brute-force modules would be too noisy.
• Signature database needs periodic updates to recognize newer CMS versions/plugins.
• Works across many CMS platforms, not just WordPress — useful as a first pass before committing to a CMS-specific deep-dive tool.

usage: wig.py [-h] [-a] [-d] [-n REQUESTS] [-p PROXY] [-q] [-t THREADS]
               [-v] [-w WORDLIST] [-o OUTPUT] url

positional arguments:
  url                   URL to scan

optional arguments:
  -a                    Return all guesses, even low confidence
  -d                    Enable directory listing checks
  -n REQUESTS           Max number of requests to send
  -p PROXY              Proxy to use (e.g. 127.0.0.1:8080)
  -q                    Quiet — only output results
  -t THREADS            Number of concurrent threads
  -v                    Verbose output
  -w WORDLIST           Wordlist for additional path checks
  -o OUTPUT             Write results to file (json)

Vue d’ensemble

WIG fait l’empreinte des applications web de manière passive : il requête un ensemble de fichiers statiques connus (JS, CSS, fichiers README/CHANGELOG, favicons, etc.) et compare les checksums/motifs à une large base de signatures pour identifier le CMS utilisé (WordPress, Drupal, Joomla, et bien d’autres), la version de la plateforme, et souvent des plugins ou thèmes spécifiques. C’est une étape de reconnaissance précoce utile avant de cibler des vulnérabilités spécifiques au CMS.

Utilisation courante

# Scan basique sur une cible
wig http://target.com

# Augmenter la verbosité pour voir les correspondances de signatures individuelles
wig -v http://target.com

# Limiter le débit de requêtes pour éviter de déclencher un WAF/rate-limiting
wig -n 5 http://target.com

# Sortir les résultats en JSON pour l'intégration dans un pipeline
wig -q http://target.com -o results.json

Flux de reconnaissance

# 1. Empreinte rapide du CMS cible et de sa version
wig http://target.com

# 2. Croiser la version identifiée avec les CVE connues
searchsploit wordpress 5.8

# 3. Poursuivre avec une énumération spécifique au CMS
#    (wpscan pour WordPress, droopescan pour Drupal, etc.)
wpscan --url http://target.com --enumerate vp

Conseils

• WIG est entièrement passif/basé sur GET : sûr pour les missions sensibles à la discrétion, là où des scanners actifs comme les modules de brute-force de WPScan seraient trop bruyants.
• La base de signatures a besoin de mises à jour régulières pour reconnaître les versions/plugins de CMS plus récents.
• Fonctionne sur de nombreuses plateformes CMS, pas seulement WordPress : utile comme premier passage avant de s’engager dans un outil d’analyse approfondie spécifique à un CMS.

usage: wig.py [-h] [-a] [-d] [-n REQUESTS] [-p PROXY] [-q] [-t THREADS]
               [-v] [-w WORDLIST] [-o OUTPUT] url

positional arguments:
  url                   URL to scan

optional arguments:
  -a                    Return all guesses, even low confidence
  -d                    Enable directory listing checks
  -n REQUESTS           Max number of requests to send
  -p PROXY              Proxy to use (e.g. 127.0.0.1:8080)
  -q                    Quiet — only output results
  -t THREADS            Number of concurrent threads
  -v                    Verbose output
  -w WORDLIST           Wordlist for additional path checks
  -o OUTPUT             Write results to file (json)