darkrx1/rxscanCLI Rust pour la reconnaissance réseau bornée : découverte de ports TCP/UDP, identification de services, collecte de preuves DNS/TLS/HTTP et recherche de noms d'utilisateur à partir de sources publiques avec corrélation.
Moteur de reconnaissance et de preuves
Reconnaissance bornée et corrélation de preuves en Rust.
RXScan combine la reconnaissance réseau, la recherche dans des sources publiques, l'investigation et la corrélation de preuves au sein d'une seule CLI.
Il peut découvrir des hôtes et des ports, identifier les services observés, collecter des preuves bornées de protocoles et du web, interroger des fournisseurs publics, corréler les résultats et persister les résultats pour une analyse et une comparaison ultérieures.
RXScan est volontairement prudent quant à ce qu'il rapporte. Un numéro de port n'identifie pas un service, un succès HTTP ne confirme pas à lui seul un compte, et une couverture incomplète est maintenue distincte d'un résultat négatif.
Compiler et installer depuis le dépôt :
git clone https://github.com/DarkRX1/RXScan.git
cd RXScan
cargo install --path . --locked
Vérifiez la version installée :
rxscan --version
rxscan --help
Lancer un scan de reconnaissance normal :
rxscan example.test
Rechercher dans les sources publiques :
rxscan search --username exampleuser
Enquêter et corréler les résultats publics :
rxscan investigate --username exampleuser
Ce sont les trois principaux points d'entrée :
rxscan TARGET
rxscan search ...
rxscan investigate ...
L'analyse par défaut utilise le workflow recon, niveau 3, et des paramètres d'exécution équilibrés.
rxscan example.test
Spécifiez les ports lorsque vous souhaitez une sélection exacte des ports :
rxscan example.test --ports 22,80,443
rxscan example.test --ports 1-1024
rxscan example.test --ports 22,80,443,8000-8100
Analysez la plage complète des ports TCP :
rxscan example.test --all-ports
La découverte UDP est explicite :
rxscan example.test --udp
Afficher le plan effectif et les détails d'exécution supplémentaires :
rxscan example.test --explain
RXScan prend en charge :
rxscan example.test --scan-mode auto
rxscan example.test --scan-mode connect
rxscan example.test --scan-mode syn
Le scan par connexion TCP est la voie de scan portable actuellement utilisée par RXScan sur sa plateforme prise en charge.
Le scan SYN brut est disponible pour IPv4 sous Linux lorsque la capacité requise est disponible. Lorsque la voie SYN demandée ne peut pas être utilisée, RXScan signale le repli effectif plutôt que de présenter silencieusement un scan par connexion comme un scan SYN.
Le scan UDP utilise des sondes natives bornées et reste optionnel.
La découverte UDP actuelle, consciente des protocoles, inclut de petites sondes pour des services tels que DNS, NTP et SSDP.
Le silence UDP n'est pas signalé comme preuve qu'un port est ouvert ou fermé. RXScan préserve l'incertitude résultante open|filtered.
La détection d'OS est explicite et étayée par des preuves, jamais une supposition à partir d'un seul indice :
rxscan example.test --os
--os exécute un plan de sondage borné par hôte dans le périmètre (au plus 6 sondes TCP/ICMP normales, en réutilisant les ports que le scan connaît déjà) et explique chaque candidat : preuves concordantes, preuves contradictoires, preuves indisponibles, couverture et provenance. Sans la capacité de paquets bruts, il se dégrade honnêtement vers des preuves passives avec une confiance réduite. Unknown est un résultat de premier ordre lorsque les preuves sont insuffisantes. Voir docs/OS_FINGERPRINTING.md pour le modèle de preuves, les limitations et la réalité actuelle du corpus.
RXScan identifie les services à partir du comportement protocolaire observé plutôt qu'en attribuant un service uniquement à partir de son numéro de port.
L'identification native actuelle couvre les protocoles courants, notamment :
Selon le protocole et les preuves disponibles, les observations peuvent inclure des informations sur le produit/la version, des bannières, des points de terminaison et titres HTTP, des faits sur les certificats TLS, des informations d'identité SSH et des preuves technologiques normalisées.
Les services inconnus restent inconnus lorsque RXScan ne dispose pas de suffisamment de preuves pour les identifier.
Aucune authentification n'est requise pour ces sondes d'identification.
La recherche par nom d'utilisateur est disponible via :
rxscan search --username exampleuser
La sortie normale se concentre sur les constats positifs et incertains utiles plutôt que d'afficher chaque résultat négatif d'un fournisseur.
Un constat peut distinguer entre un profil observé, une autre ressource observée et un emplacement candidat non confirmé.
Par exemple :
FINDINGS
✓ provider / exampleuser
Profile https://example.test/exampleuser
high · 94% · public profile
? another-provider / exampleuser
Candidate https://example.test/u/exampleuser
low · 25% · weak evidence
Les libellés sont intentionnels :
| Libellé | Signification |
|---|---|
Profile | profil public spécifique à l'identité observé |
Resource | ressource spécifique à l'identité observée qui n'est pas nécessairement un profil public |
Candidate | emplacement spécifique à l'identité qui n'a pas été confirmé |
Les pages d'accueil génériques des fournisseurs ou les points de terminaison API ne sont pas présentés comme des URL de profil confirmées.
RXScan conserve également les résultats des fournisseurs tels que bloqué, limité en débit, inconnu, erreur et non analysé comme des catégories distinctes plutôt que de les convertir en faux négatifs.
Affichez l'ensemble complet des résultats humains avec :
rxscan search --username exampleuser --all
Affichez des détails supplémentaires d'exécution et de classification avec :
rxscan search --username exampleuser --explain
Les résultats publics peuvent être transmis au pipeline d'investigation et de corrélation de RXScan :
rxscan investigate --username exampleuser
La vue par défaut met l'accent sur les comptes, les URL utiles, la confiance et les relations significatives.
Les ressources web secondaires telles que le JavaScript statique, les feuilles de style, les polices et les images sont conservées lorsqu'elles sont pertinentes pour les preuves sous-jacentes, mais ne dominent pas le rapport humain par défaut.
Les vues détaillées peuvent exposer davantage des données de relations collectées.
L'investigation reste passive par défaut. La découverte d'une cible réseau par le biais de preuves publiques n'autorise ni ne déclenche automatiquement un scan réseau.