HackTheBox - vulnerability Assessment : Nessus

Découverte des scanners de vulnérabilités : différence avec un pentest, types de scans et outils disponibles

Posted Dec 18, 2025

Vulnerability Scanning Overview

By Alexy Canu

36 min read

HackTheBox - vulnerability Assessment : Nessus

Informations sur le module

Ce module introduit le concept du vulnerability scanning (scan de vulnérabilités) et explique son rôle dans une évaluation de sécurité. Il couvre les différences entre un scan et un véritable test d’intrusion, les types de tests effectués, et présente les outils principaux du marché.

Lien : Vulnerability Scanning Overview

Objectifs d’apprentissage

Ce module couvre les compétences suivantes :

Comprendre la différence entre vulnerability scanning et penetration testing
Identifier les types de scans (statiques vs dynamiques, authentifiés vs non-authentifiés)
Découvrir les principaux outils de scan du marché
Comprendre les limites et les faux positifs des scanners automatisés

Qu’est-ce que le vulnerability scanning ?

Le rôle du scan de vulnérabilités

Le vulnerability scanning sert à identifier des failles potentielles dans les équipements réseau et les applications. J’ai appris que ces scans ciblent plusieurs types d’actifs :

Équipements réseau (routeurs, firewalls, switches)
Serveurs et postes de travail
Applications web et services

Pour les débutants : Un scanner de vulnérabilités est un outil automatisé qui analyse vos systèmes pour détecter des failles de sécurité connues, un peu comme un antivirus qui chercherait des portes d’entrée pour les attaquants.

Ce qui m’a marqué : La validation humaine est indispensable

Un point crucial que j’ai retenu : les scanners ne sont pas infaillibles. Ils détectent des vulnérabilités potentielles, mais un humain doit ensuite :

Valider manuellement chaque résultat
Distinguer les vrais problèmes des faux positifs
Exclure les faux positifs des futurs scans

Les scanners automatisés ne peuvent généralement pas exploiter les vulnérabilités eux-mêmes (sauf exceptions). C’est un outil d’identification, pas d’exploitation.

Scan vs Penetration Test : Une distinction importante

Mon observation sur la confusion courante

Beaucoup confondent vulnerability scanning et penetration testing. Voici ce que j’ai compris de la différence :

Vulnerability Scan :

Processus automatisé
Identifie des vulnérabilités potentielles
Rapide et exhaustif
Fait souvent partie d’un pentest

Penetration Test :

Processus manuel et créatif
Exploite réellement les vulnérabilités
Nécessite des compétences humaines
Inclut bien plus qu’un simple scan

Un scan peut accélérer un pentest ou augmenter sa couverture, mais ne le remplace jamais. Le pentest va beaucoup plus loin dans l’exploitation et l’analyse.

Types de tests effectués par les scanners

Tests statiques vs dynamiques

J’ai découvert que les scanners utilisent deux approches complémentaires :

Tests statiques

Comment ça fonctionne :

Le scanner identifie la version d’un logiciel ou service
Il compare cette version aux CVE publiques connues
Si une correspondance existe, il signale une vulnérabilité

Limitation que j’ai comprise : Cette méthode n’est pas toujours fiable car :

Un patch peut avoir été appliqué manuellement
La cible peut ne pas être affectée par ce CVE spécifique
La version peut avoir été modifiée

CVE (Common Vulnerabilities and Exposures) : Base de données publique recensant les vulnérabilités connues avec un identifiant unique. Exemple : CVE-2023-12345.

Tests dynamiques

Comment ça fonctionne :

Le scanner envoie des payloads bénins (non dangereux)
Il teste des vecteurs comme :
- Credentials faibles (admin/admin, etc.)
- Injections SQL basiques
- Injections de commandes simples
Si le payload retourne un résultat positif, la vulnérabilité est probablement réelle

Mon analyse : Les tests dynamiques sont plus fiables que les statiques car ils testent réellement la présence de la faille, pas juste la version du logiciel.

Scans authentifiés vs non-authentifiés

Scans non-authentifiés

Ce que j’ai testé :

Simulent la vision d’un attaquant externe
N’utilisent aucune credential
Identifient les vulnérabilités accessibles publiquement

Scans authentifiés

Pourquoi c’est important :

Utilisent des credentials légitimes
Permettent de voir les vulnérabilités internes
Détectent les patches manquants sur le système

Les organisations devraient effectuer les deux types de scans régulièrement pour avoir une vision complète de leur exposition.

Intégration dans un programme de patch management

Mon observation sur la continuité

Les scans de vulnérabilités ne sont pas ponctuels. J’ai compris qu’ils doivent :

Tourner en continu selon un planning établi
Alimenter le programme de patch management
Détecter les nouveaux actifs ajoutés au réseau
Vérifier l’application des patches

Un scanner qui tourne une fois par an est inutile. Les vulnérabilités sont découvertes quotidiennement, et les réseaux évoluent constamment.

Les outils principaux du marché

Scanners commerciaux

J’ai identifié trois plateformes reconnues :

Outil	Disponibilité	Particularité
Nessus	Version gratuite communautaire	Limité à 16 hôtes en version gratuite
Qualys	Version gratuite communautaire	Plateforme cloud
Nexpose	Essai 30 jours	Nécessite achat après période d’essai

Solution open-source : OpenVAS

Alternative gratuite pour ceux qui n’ont pas de budget :

Complètement open-source
Pas de limitation de nombre d’hôtes
Communauté active

Documentation OpenVAS : OpenVAS Official Documentation

Focus sur Nessus Essentials

Ce que j’ai découvert sur Nessus

Nessus Essentials est la version gratuite de Tenable :

Avantages :

Gratuit pour usage personnel
Parfait pour débuter
Interface intuitive

Limitations :

Maximum 16 hôtes seulement
Fonctionnalités réduites par rapport à la version pro
Suffisant pour apprendre et tester

Pour un lab personnel ou pour apprendre, Nessus Essentials est largement suffisant. Pour une entreprise, la version professionnelle sera nécessaire.

Ce que Nessus fait

Le scanner Nessus va :

Tenter d’identifier toutes les vulnérabilités présentes
Générer un rapport avec niveaux de criticité
Proposer des recommandations de correction

Démarrer avec Nessus

Téléchargement et installation

Obtenir le binaire Nessus

Pour commencer, je me suis rendu sur la page de téléchargement Nessus pour récupérer le bon paquet selon mon système. Dans mon cas, j’ai téléchargé le paquet Debian pour Ubuntu.

Pour les débutants : Un paquet Debian (.deb) est un format d’installation pour les systèmes Linux basés sur Debian/Ubuntu, similaire à un .exe sous Windows.

Demander une licence gratuite

Avant d’installer, j’ai dû récupérer un code d’activation sur la page d’activation Nessus. Ce code est indispensable pour activer la version gratuite Nessus Essentials.

Le code d’activation est envoyé par email instantanément après la demande. Pense à vérifier tes spams si tu ne le reçois pas.

Installation du paquet

Une fois le binaire et le code en main, j’ai installé le paquet avec dpkg :

dpkg -i Nessus-8.15.1-ubuntu910_amd64.deb

Ce que j’ai observé pendant l’installation :

Selecting previously unselected package nessus.
(Reading database ... 132030 files and directories currently installed.)
Preparing to unpack Nessus-8.15.1-ubuntu910_amd64.deb ...
Unpacking nessus (8.15.1) ...
Setting up nessus (8.15.1) ...
Unpacking Nessus Scanner Core Components...
Created symlink /etc/systemd/system/nessusd.service → /lib/systemd/system/nessusd.service.
Created symlink /etc/systemd/system/multi-user.target.wants/nessusd.service → /lib/systemd/system/nessusd.service.

Mon analyse :

Nessus crée automatiquement un service systemd (nessusd.service)
Le service est configuré pour démarrer avec le système
Les composants du scanner sont décompressés automatiquement

Lancement du service Nessus

Démarrer nessusd

Après l’installation, j’ai démarré le service Nessus :

sudo systemctl start nessusd.service

Le service nessusd est le daemon (processus en arrière-plan) qui fait tourner Nessus. Il doit être actif pour accéder à l’interface web.

Commandes utiles que j’utilise :

  
# Vérifier le statut du service
sudo systemctl status nessusd.service

# Activer le démarrage automatique au boot
sudo systemctl enable nessusd.service

# Arrêter le service
sudo systemctl stop nessusd.service

Configuration initiale

Accéder à l’interface web

J’ai accédé à Nessus via mon navigateur à l’adresse :

https://localhost:8834

Attention : Le navigateur affichera un avertissement de sécurité car Nessus utilise un certificat auto-signé. C’est normal, tu peux accepter l’exception de sécurité.

Sélection de la version

Sur la page de setup, j’ai sélectionné Nessus Essentials pour la version gratuite, puis j’ai entré mon code d’activation reçu par email.

Création du compte administrateur

Ensuite, j’ai créé un compte utilisateur avec un mot de passe fort.

Nessus impose des règles strictes pour le mot de passe : longueur minimale, complexité avec majuscules, minuscules, chiffres et caractères spéciaux.

Compilation des plugins

Ce qui m’a surpris : Après la création du compte, Nessus a commencé à compiler les plugins automatiquement. Cette étape peut prendre plusieurs minutes (voir dizaines de minutes selon la machine).

Les plugins sont les signatures de vulnérabilités que Nessus utilise pour scanner. La base contient des milliers de checks et doit être compilée avant le premier scan.

Environnement de lab fourni

Accès au VM de lab

Pour ce module HTB, un environnement pré-configuré est fourni dans la section Nessus Skills Assessment :

Détails de connexion :

URL : https://<IP>:8834
Username : htb-student
Password : HTB_@cademy_student!

Accès SSH également disponible :

ssh htb-student@<IP>
# Password: HTB_@cademy_student!

Cette VM a Nessus déjà installé avec les targets en cours d’exécution. Pratique pour suivre le module sans installer Nessus localement.

Exploration de l’interface

Page de paramètres

Une fois le setup terminé, j’ai exploré la page Settings qui offre de nombreuses options :

Configuration réseau :

Configuration d’un Proxy Server (utile en environnement d’entreprise)
Configuration d’un serveur SMTP pour l’envoi de rapports par email

Gestion des comptes :

Création/suppression d’utilisateurs
Gestion des permissions
Configuration de l’authentification

Paramètres avancés :

Interface utilisateur : Personnalisation de l’apparence
Scanning : Réglages de performance des scans
Logging : Configuration des logs
Performance : Optimisation selon les ressources disponibles
Security : Options de durcissement de Nessus

Mon observation : Nessus offre énormément d’options de configuration. Pour débuter, les paramètres par défaut fonctionnent bien, mais pour un usage professionnel, il faut passer du temps à optimiser ces réglages.

Prochaines fonctionnalités disponibles

Maintenant que Nessus est configuré, je peux :

Créer des scans personnalisés
Configurer des scan policies (politiques de scan)
Définir des plugin rules (règles pour activer/désactiver certains checks)
Customiser les paramètres selon mes besoins

Dans les prochaines sections du module, on verra comment créer et configurer des scans de vulnérabilités efficaces.

Configurer un scan Nessus

Créer un nouveau scan

Accéder aux templates de scan

Pour lancer un nouveau scan, j’ai cliqué sur New Scan dans l’interface Nessus. J’ai alors découvert que les templates sont organisés en trois catégories :

Discovery (Découverte)
Vulnerabilities (Vulnérabilités)
Compliance (Conformité)

Important : Les scans présentés dans ce module ont déjà été pré-exécutés pour gagner du temps. Si tu relances un scan, il est préférable d’analyser les vulnérabilités au fur et à mesure qu’elles apparaissent plutôt que d’attendre la fin complète du scan, car ils peuvent prendre 1 à 2 heures.

Types de scans disponibles

Ce que j’ai observé comme options :

Catégorie	Type de scan	Utilité
Discovery	Host Discovery	Identifier les hôtes actifs et ports ouverts
Vulnerabilities	Basic Network Scan	Scan de vulnérabilités standard
Vulnerabilities	Advanced Scan	Scan avec options personnalisées
Vulnerabilities	Malware Scan	Détection de malwares
Vulnerabilities	Web Application Tests	Tests spécifiques aux applications web
Compliance	Credentialed Patch Audit	Audit des patches avec credentials
Targeted	Badlock Detection	Détection CVE spécifique
Targeted	Bash Shellshock Detection	Détection CVE spécifique
Targeted	DROWN Detection	Détection CVE spécifique

Pour plus de détails sur chaque type de scan : Nessus Scan Templates Documentation

Configuration du scan basique

Pour cet exercice, j’ai choisi Basic Network Scan et configuré les paramètres suivants :

Paramètres généraux :

Name : Windows_basic
Folder : My Scans
Target : 172.16.16.100

Targets du module HTB :
Windows : 172.16.16.100
Linux : 172.16.16.160

Section Discovery : Découverte des hôtes

Host Discovery : Appareils fragiles

Mon observation sur les appareils fragiles :

Dans la section Host Discovery, Nessus propose une option pour scanner les appareils fragiles (Fragile Devices). J’ai appris que cette option est désactivée par défaut pour une bonne raison.

Pourquoi c’est important :

Scanner des imprimantes réseau peut les faire imprimer des pages de texte incompréhensible
Cela peut rendre les appareils inutilisables pendant le scan
Mieux vaut laisser cette option désactivée sauf besoin spécifique

Types d’appareils fragiles :

Imprimantes réseau (Network Printers)
Hôtes Novell Netware
Appareils OT (Operational Technology - systèmes industriels)

Pour les débutants : Les appareils OT sont des systèmes de contrôle industriel (SCADA, automates, etc.). Un scan peut perturber leur fonctionnement, d’où l’option spécifique.

Port Scanning : Choix de la portée

Options de scan de ports disponibles :

J’ai découvert trois stratégies de scan :

Common ports (ports communs)
- Scan rapide des ports les plus fréquents
- Idéal pour une première reconnaissance
All ports (tous les ports)
- Scan exhaustif de 0 à 65535
- Plus long mais plus complet
Custom range (plage personnalisée)
- Définir exactement quels ports scanner
- Utile quand on connaît déjà la cible

Paramètres additionnels que j’ai notés :

Test local Nessus host : Teste aussi la machine hébergeant Nessus
Fast network discovery : Accélère la découverte réseau
Use netstat if credentials provided : Utilise netstat pour lister les ports ouverts si on a des credentials
Use SYN scanner if necessary : Utilise les SYN scans (plus discrets)

Techniques de ping utilisées :

TCP ping : Envoie des paquets TCP
ARP ping : Utilise ARP sur réseau local
ICMP ping : Le ping classique

Nessus effectue 2 retries (tentatives) par défaut pour chaque méthode de ping avant de considérer un hôte comme inactif.

Service Discovery : Identification des services

Probe all ports to find services :

Cette option est activée par défaut et permet à Nessus de :

Envoyer des sondes (probes) sur tous les ports détectés
Identifier précisément quel service tourne sur chaque port

Mon inquiétude initiale : J’ai noté que le cours mentionne qu’une application mal conçue pourrait crasher à cause de ces sondes. Cependant, la plupart des applications modernes sont suffisamment robustes pour gérer ces tests.

Si tu scannes des systèmes critiques ou anciens, désactive cette option par précaution.

Détection SSL/TLS :

Nessus cherche automatiquement les services SSL/TLS et peut :

Identifier les certificats expirants
Détecter les certificats révoqués
Analyser la configuration SSL/TLS

Section Assessment : Évaluation approfondie

Web Application Scanning

Ce que j’ai activé :

Si la cible inclut des applications web, je peux activer le Web Application Scanning avec des options avancées :

Personnalisation du User-Agent :

Mozilla/4.0

Pour les débutants : Le User-Agent est l’identifiant que le navigateur envoie au serveur web. Nessus peut le personnaliser pour simuler différents navigateurs ou éviter la détection.

Configuration du Web Crawler :

Start from : / (racine du site)
Exclude : /server_privileges.php|logout (exclure certains chemins)

Mon observation : Exclure les pages de logout est intelligent car cela évite de se déconnecter en plein scan si on utilise des credentials.

Tests RFI (Remote File Inclusion) :

Nessus peut tester les vulnérabilités RFI en spécifiant une URL personnalisée pour les tests d’inclusion de fichiers distants.

Authentication Testing

Deux approches disponibles :

1. Credentialed scanning :

Utiliser des credentials fournis manuellement
Nessus tente de s’authentifier sur les services découverts
Plus précis et moins bruyant

2. Brute-force attacks :

Utiliser des listes de usernames et passwords
Nessus teste toutes les combinaisons
Plus agressif et détectable

Exemples de tests automatisés :

Oracle Database : Test des comptes par défaut
Hydra : Brute-force activé en permanence pour attaques par force brute

Le brute-force génère énormément de logs et peut déclencher des alertes IDS/IPS. À utiliser avec précaution.

User Enumeration : Énumération des utilisateurs

Techniques disponibles :

J’ai découvert plusieurs méthodes pour énumérer les utilisateurs Windows :

Méthodes activées par défaut :

SAM Registry : Lecture du registre SAM (Security Account Manager)
ADSI Query : Requêtes Active Directory Service Interfaces
WMI Query : Windows Management Instrumentation

RID Brute Forcing (désactivé par défaut) :

RID (Relative Identifier) : Identifiant numérique unique attribué à chaque compte utilisateur Windows. Exemple : 1000, 1001, 1002…

Comment j’ai configuré le RID Brute Forcing :

Si j’active cette option, je peux définir :

Pour les utilisateurs du domaine :

Start UID : 1000
End UID : 1200

Pour les utilisateurs locaux :

Start UID : 1000
End UID : 1200

Mon analyse : Cette technique essaie tous les RIDs dans la plage spécifiée pour découvrir des comptes cachés ou non documentés.

Option supplémentaire :

Request SMB Domain information : Désactivée par défaut, permet de récupérer des infos sur le domaine SMB

Section Advanced : Paramètres avancés

Safe Checks : Vérifications sécurisées

Activé par défaut :

L’option Enable safe checks empêche Nessus d’exécuter des tests qui pourraient :

Faire crasher le système cible
Provoquer un déni de service
Corrompre des données
Perturber le réseau

Si tu fais un scan sur un environnement de production critique, laisse TOUJOURS cette option activée.

Gestion de la performance réseau

Options de throttling que j’ai découvertes :

Détection de congestion réseau :

Nessus peut ralentir automatiquement le scan s’il détecte de la congestion
Évite de saturer le réseau pendant le scan

Gestion des hôtes non-réactifs :

Stop scanning unresponsive hosts : Arrête de scanner les hôtes qui ne répondent plus
Évite de perdre du temps sur des machines éteintes ou filtrées

Ordre de scan aléatoire :

Scan IPs randomly : Scanner les IPs dans un ordre aléatoire
Utile pour éviter les patterns détectables par les IDS

Paramètres de performance

Configuration par défaut :

Paramètre	Valeur	Signification
Network timeout	5 secondes	Temps d’attente avant abandon
Max checks per host	4	Nombre de tests simultanés par hôte
Max hosts per scan	30	Nombre d’hôtes scannés en parallèle

Mon observation : Ces valeurs sont conservatives pour éviter de surcharger le réseau. Sur un réseau rapide et dédié au pentest, on peut augmenter ces valeurs pour accélérer le scan.

Augmenter trop ces valeurs peut rendre le scan instable ou faire crasher Nessus. Procède par petites incrémentations.

Paramètres avancés de Nessus

Scan Policies : Créer des politiques de scan personnalisées

Qu’est-ce qu’une Scan Policy ?

Mon observation :

Les Scan Policies sont essentiellement des scans personnalisés réutilisables. Au lieu de reconfigurer les mêmes paramètres à chaque scan, je peux :

Définir des options de scan spécifiques
Sauvegarder la configuration comme “policy”
Retrouver cette policy dans Scan Templates lors de la création d’un nouveau scan

Cas d’usage que j’ai identifiés :

Type de policy	Utilité
Slow & Evasive Scan	Scan lent et discret pour éviter la détection
Web-Focused Scan	Scan ciblé sur les vulnérabilités web
Client-Specific Scan	Scan avec credentials spécifiques à un client

Portabilité des policies :

Les policies peuvent être exportées d’un scanner Nessus
Puis importées dans un autre scanner Nessus
Pratique pour standardiser les scans entre différentes équipes

Créer une Scan Policy personnalisée

Ma démarche :

J’ai cliqué sur New Policy en haut à droite
J’ai choisi Advanced Scan comme base (aucune recommandation pré-configurée)
J’ai nommé ma policy : HTB_Policy
J’ai ajouté une description (optionnelle)

Options de personnalisation disponibles :

Settings : Configurer tous les paramètres de scan
Credentials : Ajouter des credentials pour scan authentifié
Compliance : Spécifier des standards de conformité
Plugins : Activer/désactiver des familles de plugins ou plugins individuels

Une fois sauvegardée, la policy apparaît dans un nouvel onglet User Defined sous Scan Templates. Très pratique pour réutiliser des configurations complexes.

Nessus Plugins : Le cœur du scanner

Comprendre les plugins Nessus

Ce que j’ai appris :

Les plugins Nessus sont écrits en NASL (Nessus Attack Scripting Language) et permettent de détecter de nouvelles vulnérabilités et CVE.

Pour les débutants : Un plugin est comme une “signature” de vulnérabilité. Chaque plugin sait comment tester la présence d’une faille spécifique.

Contenu d’un plugin :

Nom de la vulnérabilité
Impact de la faille
Solution de remédiation
Méthode de test pour vérifier la présence de la vulnérabilité

Niveaux de sévérité

Classification par gravité :

Niveau	Signification
Critical	Critique - Exploitation immédiate possible
High	Élevé - Risque important
Medium	Moyen - Risque modéré
Low	Faible - Risque limité
Info	Information - Pas de risque direct

Chiffres impressionnants (au moment de la rédaction du cours) :

145,973 plugins publiés par Tenable
Couvrant 58,391 CVE IDs
Couvrant 30,696 Bugtraq IDs

Base de données searchable disponible sur : Tenable Plugins Database

Cas pratique : Gérer les faux positifs

Situation rencontrée :

J’ai scanné un serveur utilisant Microsoft DirectAccess (technologie permettant aux clients d’accéder au réseau interne via Internet). Nessus a détecté des cipher suites non sécurisées.

Vérification manuelle avec sslscan :

sslscan example.com

Résultat obtenu :

Preferred TLSv1.0  128 bits  ECDHE-RSA-AES128-SHA          Curve 25519 DHE 253
Accepted  TLSv1.0  256 bits  ECDHE-RSA-AES256-SHA          Curve 25519 DHE 253
Accepted  TLSv1.0  128 bits  DHE-RSA-AES128-SHA            DHE 2048 bits
Accepted  TLSv1.0  256 bits  DHE-RSA-AES256-SHA            DHE 2048 bits
Accepted  TLSv1.0  128 bits  AES128-SHA                   
Accepted  TLSv1.0  256 bits  AES256-SHA

Mon analyse :

Dans ce cas précis, les cipher suites faibles sont intentionnelles car :

SSL/TLS n’est pas requis pour DirectAccess
L’implémenter aurait un impact négatif sur les performances
C’est donc un faux positif (false positive)

Créer une Plugin Rule

Ma solution : Créer une règle pour cacher ce résultat sans désactiver le plugin globalement.

Étapes suivies :

Aller dans Resources > Plugin Rules
Créer une New Rule
Configurer la règle :
- Host : L’IP ou hostname concerné
- Plugin ID : ID du plugin Microsoft DirectAccess
- Action : Hide this result

Cette approche permet de garder le plugin actif pour tous les autres hôtes tout en masquant le faux positif sur l’hôte spécifique.

Exclure des plugins non pertinents

Autre exemple pratique :

Les certificats auto-signés (SSL Self-Signed Certificate) ne sont pas directement exploitables mais Nessus les remonte quand même.

Pour exclure ce type de détection :

Configuration de la règle :

Host : yourhost.com
Plugin ID : 57582 (ID du plugin SSL Self-Signed Certificate)
Expiration Date : Optionnelle (pour que la règle expire automatiquement)
Severity : Hide this result

Mon observation : L’expiration date est utile pour les exceptions temporaires. Par exemple, si un certificat auto-signé doit être remplacé dans 3 mois, je peux faire expirer la règle à cette date.

Scanning with Credentials : Scans authentifiés

Pourquoi scanner avec des credentials ?

Avantages que j’ai identifiés :

Détection plus précise des patches manquants
Moins de faux positifs (le scanner peut vérifier directement les versions installées)
Accès aux vulnérabilités internes (pas visibles depuis l’extérieur)
Scan moins bruyant (moins de probing agressif nécessaire)

Authentification host-based

Pour les hôtes Linux/Unix via SSH :

Nessus supporte plusieurs méthodes :

Password : Authentification par mot de passe
Public key : Authentification par clé SSH publique
Certificate : Authentification par certificat
Kerberos : Authentification Kerberos

Pour les hôtes Windows :

Méthodes disponibles :

Password : Mot de passe en clair (chiffré en transit)
Kerberos : Authentification Kerberos
LM hash : Hash LM (obsolète, déconseillé)
NTLM hash : Hash NTLM (méthode courante)

Options de sécurité activées par défaut :

Never send credentials in clear : Ne jamais envoyer les credentials en clair
Do not use NTLMv1 authentication : Ne pas utiliser NTLMv1 (version obsolète et faible)

NTLMv1 est vulnérable à diverses attaques. Nessus désactive cette méthode par défaut pour renforcer la sécurité.

Authentification base de données

Bases supportées par Nessus :

Oracle
PostgreSQL
DB2
MySQL
SQL Server
MongoDB
Sybase

Exemple de configuration SQL Server :

Authentication method : Password
Username : dba
Port : 1433 (port par défaut SQL Server)
Windows auth type : Spécifié si nécessaire

Credentials pour le lab HTB

Credentials fournis pour les scans authentifiés :

Linux :

Username : htb-student_adm
Password : HTB_@cademy_student!

Windows :

Username : administrator
Password : Academy_VA_adm1!

Ces scans authentifiés ont déjà été configurés dans l’environnement Nessus du lab pour gagner du temps.

Authentification services plaintext

Services supportés :

Nessus peut s’authentifier en plaintext sur :

FTP
HTTP
IMAP
IPMI
Telnet
Et bien d’autres…

Exemple de configuration HTTP :

Paramètres pour formulaire de login :

Method : Login form
Username : admin
Login page : /login.php
Submission page : /process_login.php

Mon observation : Nessus peut automatiser l’authentification sur des formulaires web, ce qui est très utile pour scanner des applications protégées.

Vérifier le succès de l’authentification

Comment confirmer que l’authentification a fonctionné :

Dans l’output de Nessus, je vérifie la présence de messages comme :

Exemple pour SQL Server :

Info: Microsoft SQL Server login possible

Description: Nessus logged into MS SQL server using credentials

Output: Credentialed checks enabled for MSSQL on port 1433, version 14.0.0.0

Si l’authentification échoue, Nessus basculera sur un scan non-authentifié standard, mais avec moins de précision dans la détection des vulnérabilités.

Ce qui confirme le succès :

Message “login possible” ou “logged into”
Mention “Credentialed checks enabled”
Affichage de la version exacte détectée (ici 14.0.1000.0)

Travailler avec les résultats de scan Nessus

Formats d’export disponibles

Exporter les rapports de scan

Ce que j’ai découvert :

Nessus offre plusieurs formats d’export selon l’usage prévu. J’ai identifié deux catégories principales :

1. Rapports pour humains :

.pdf : Format PDF portable
.html : Format HTML interactif
.csv : Format tableau pour analyse

2. Formats techniques :

.nessus : Résultats bruts pour import dans d’autres outils
.db : Base de données complète du scan

Pour les débutants : Le format .nessus peut être importé dans des outils tiers comme EyeWitness, qui prend automatiquement des screenshots de toutes les applications web détectées par Nessus.

Rapports PDF et HTML

Types de rapports disponibles

Deux options principales :

1. Executive Summary (Résumé exécutif)

Ce qu’il contient :

Liste des hôtes scannés
Nombre total de vulnérabilités par hôte
Option Show Details pour voir :
- Niveau de sévérité
- Score CVSS
- Numéro de plugin
- Nom de chaque vulnérabilité

Mon observation : Le numéro de plugin est cliquable et renvoie vers la base de données Tenable avec la description complète du plugin. Très pratique pour approfondir une vulnérabilité.

2. Custom Report (Rapport personnalisé)

Permet de sélectionner exactement quelles informations inclure dans le rapport.

Avantage du format PDF

Pourquoi j’utilise le PDF :

Facilement partageable avec des non-techniques
Format universel lisible partout
Impression simple si nécessaire
Non-modifiable (intégrité du rapport)

Avantage du format HTML

Ce que j’apprécie dans le HTML :

Interactif avec des liens cliquables
Navigation facilitée entre les sections
Recherche rapide avec Ctrl+F
Tri et filtrage possibles

Exemple de rapport HTML :

Dans l’exemple que j’ai analysé, les vulnérabilités sont regroupées ensemble pour :

Avoir une vue claire de chaque problème
Identifier rapidement les actifs affectés
Faciliter la priorisation de la remédiation

Bonne pratique : Toujours grouper les vulnérabilités identiques ensemble plutôt que de les lister par hôte. Cela évite les redondances et facilite la compréhension globale.

Format CSV : Analyse et partage

Utilité du format CSV

Cas d’usage que j’ai identifiés :

1. Import dans des outils d’analyse :

Splunk : Pour analytics et dashboards
Excel/LibreOffice : Pour traitement de données
Scripts personnalisés : Pour automatisation

2. Partage avec stakeholders :

Équipes IT responsables de la remédiation
Responsables de différents actifs
Équipes de conformité

Personnalisation des colonnes :

Nessus permet de sélectionner exactement quelles colonnes exporter :

Plugin ID
CVE ID
Severity
CVSS Score
Host IP
Port
Solution
Description
etc.

Exporter uniquement les colonnes nécessaires rend le fichier CSV plus léger et plus exploitable pour l’usage prévu.

Formats techniques : .nessus et .db

Format .nessus (XML)

Ce que contient un fichier .nessus :

J’ai appris que le fichier .nessus est en réalité un fichier XML qui inclut :

Copie des paramètres de scan (configuration utilisée)
Outputs des plugins (résultats bruts de chaque test)

Utilisation pratique :

Import dans d’autres scanners Nessus
Traitement par scripts XML
Archivage des résultats bruts
Import dans des outils tiers

Format .db (Base de données complète)

Contenu du fichier .db :

Le format .db est plus complet et contient :

Le fichier .nessus complet
La KB (Knowledge Base du scan)
L’Audit Trail des plugins
Les attachments du scan

KB et Audit Trail : Pour plus d’informations sur ces composants, consulter Nessus KB and Audit Trail Documentation.

Mon observation : Le format .db est utile pour une conservation complète incluant toute la traçabilité du scan, pas juste les résultats finaux.

Avertissement important sur les rapports

CRITIQUE : Les rapports Nessus ne doivent JAMAIS être donnés directement au client comme livrable final. Ils doivent uniquement servir d’annexe ou de données supplémentaires à un rapport de penetration test ou vulnerability assessment personnalisé et rédigé manuellement.

Pourquoi c’est important :

Les rapports automatisés manquent de contexte business
Ils ne hiérarchisent pas selon les priorités du client
Ils contiennent potentiellement des faux positifs non vérifiés
Ils n’incluent pas de recommandations personnalisées

Automatiser le téléchargement avec l’API REST

Script nessus-report-downloader

Ce que j’ai testé :

J’ai utilisé le script nessus_downloader.rb qui exploite l’API REST de Nessus pour automatiser le téléchargement de rapports.

Exécution du script :

./nessus_downloader.rb

Déroulement interactif :

1. Configuration de la connexion :

Enter the Nessus Server IP: 127.0.0.1
Enter the Nessus Server Port [8834]: 8834
Enter your Nessus Username: admin
Enter your Nessus Password (will not echo):

2. Sélection du scan :

Getting report list...
Scan ID Name                        Last Modified              Status         
------- ----                        -------------              ------         
1       Windows_basic               Aug 22, 2020 22:07 +00:00  completed      

Enter the report(s) you want to download (comma separate list) or 'all': 1

3. Choix du format :

Choose File Type(s) to Download: 
[0] Nessus (No chapter selection)
[1] HTML
[2] PDF
[3] CSV (No chapter selection)
[4] DB (No chapter selection)

Enter the file type(s) you want to download (comma separate list) or 'all': 3

4. Destination :

Path to save reports to (without trailing slash): /assessment_data/inlanefreight/scans/nessus

5. Téléchargement :

Downloading report(s). Please wait...

[+] Exporting scan report, scan id: 1, type: csv
[+] Checking export status...
[+] Report ready for download...
[+] Downloading report to: /assessment_data/inlanefreight/scans/nessus/inlanefreight_basic_5y3hxp.csv

Report Download Completed!

Mon observation : Le script permet de télécharger plusieurs scans et plusieurs formats en une seule exécution. Très pratique pour automatiser la collecte de résultats.

Avantages de cette approche :

Gain de temps : Pas besoin de cliquer manuellement dans l’interface
Automatisation : Peut être intégré dans des scripts de reporting
Batch processing : Télécharger tous les scans d’un coup
Ligne de commande : Utilisable en SSH sans interface graphique

Créer ses propres scripts

Ce que le module suggère :

Nessus expose une API REST complète qui permet de :

Lancer des scans automatiquement
Télécharger les résultats
Créer/modifier des policies
Gérer les credentials
Automatiser tout le workflow de scanning

Mon idée pour la suite : Créer un script Python qui :

Lance un scan quotidien
Attend la fin du scan
Télécharge le rapport CSV
Parse les résultats
Envoie une alerte si des vulnérabilités critiques sont détectées

L’API REST Nessus est documentée sur Tenable Developer Portal. C’est une ressource essentielle pour automatiser Nessus.

Problèmes de scanning et mitigation

Bonnes pratiques avant de scanner

Communication préalable indispensable

Ce que j’ai retenu comme règle absolue :

Avant de lancer n’importe quel scan, je dois communiquer avec :

Le client (si scan externe)
Les stakeholders internes (si scan interne)
Le personnel IT concerné

Pour les débutants : Un scan de vulnérabilités peut perturber le réseau, faire crasher des services, ou générer des alertes de sécurité. La communication préalable évite les surprises et les incidents.

Identifier les systèmes sensibles

Questions à poser avant le scan :

1. Hôtes legacy/sensibles à exclure ?

Vieux systèmes qui pourraient crasher
Équipements médicaux ou industriels
Systèmes de production critiques

2. Hôtes haute priorité/haute disponibilité ? Ces systèmes nécessitent un traitement spécial :

Scanner en dehors des heures ouvrables
Utiliser des configurations de scan allégées
Scanner séparément des autres hôtes

Mon observation : Mieux vaut exclure un système critique du scope que de risquer un incident en production.

Problèmes courants et solutions

Problème : Résultats incohérents dus aux firewalls

Symptômes rencontrés :

Certains firewalls causent des résultats bizarres :

Tous les ports apparaissent ouverts (faux positifs massifs)
Aucun port n’apparaît ouvert (alors qu’il y en a)

Solution que j’ai appliquée :

Créer un Advanced Scan
Désactiver l’option “Ping the remote host”

Pourquoi ça fonctionne :

Nessus n’utilise plus ICMP pour vérifier si l’hôte est vivant
Le scan procède directement sans vérification préalable
Évite les messages “ICMP Unreachable” mal interprétés

Mon analyse : Certains firewalls retournent “ICMP Unreachable” pour tous les pings, ce que Nessus interprète comme un hôte actif, générant ensuite plein de faux positifs informationnels.

Problème : Impact sur systèmes sous charge

Mitigation via rate-limiting :

Pour les hôtes très sollicités (ex: application web à fort trafic), j’ajuste les Performance Options :

Paramètre clé :

Max Concurrent Checks Per Host : Réduire cette valeur

Effet :

Limite le nombre de plugins exécutés simultanément
Réduit la charge sur l’hôte cible
Allonge le temps de scan mais évite les crashes

Si une application web gère 1000 utilisateurs simultanés, un scan trop agressif pourrait la saturer et provoquer un déni de service involontaire.

Problème : Systèmes legacy et imprimantes

Bonnes pratiques d’exclusion :

Systèmes legacy :

Les exclure complètement du scope
Ou utiliser le fichier nessusd.rules pour configuration avancée

Imprimantes réseau :

Ne jamais les scanner (sauf demande explicite)
Elles pourraient imprimer des pages de garbage
Option vue précédemment : désactiver “Scan Network Printers”

Documentation sur nessusd.rules : Nessus Rules Configuration

Denial of Service checks : À éviter

Règle stricte sur les DoS

Ma position claire :

JAMAIS effectuer de Denial of Service checks sauf si explicitement demandé par le client.

Comment s’en assurer :

Toujours activer l’option “Safe Checks” qui :

Désactive automatiquement les plugins DoS
Évite les plugins réseau à impact négatif
Réduit le risque de crash de daemon réseau

Important : Activer “Safe Checks” ne garantit PAS zéro impact, mais minimise significativement les risques et réduit également le temps de scan.

Ce que “Safe Checks” ne fait pas :

Ne garantit pas une absence totale d’impact
N’empêche pas tous les crashs possibles
Reste une précaution, pas une protection absolue

Documentation et logs

Traçabilité indispensable

Ce que je fais systématiquement :

Avant le scan :

Informer toutes les parties prenantes
Documenter les exclusions et raisons
Noter l’heure prévue du scan

Pendant le scan :

Conserver des logs détaillés de l’activité
Monitorer l’impact réseau
Surveiller les alertes éventuelles

Après le scan :

Archiver tous les logs
Documenter tout incident survenu

Pourquoi c’est crucial : Si un incident survient (crash, alerte sécurité, dégradation performance), les logs permettent de :

Prouver que le scan était autorisé
Analyser la cause de l’incident
Déterminer si le scan est responsable ou non

Mesurer l’impact réseau

Utiliser vnstat pour monitorer la bande passante

Outil installé :

sudo apt install vnstat

Pour les débutants : vnstat est un outil de monitoring réseau qui mesure l’utilisation de la bande passante sur une interface réseau donnée.

Test comparatif : Avant/Pendant le scan

Baseline : Monitoring sans scan

J’ai d’abord monitoré l’interface eth0 sans aucun scan :

  
sudo vnstat -l -i eth0

Résultat observé (réseau au repos) :

Monitoring eth0...    (press CTRL-C to stop)

   rx:       332 bit/s     0 p/s          tx:       332 bit/s     0 p/s
   rx:         0 bit/s     0 p/s          tx:         0 bit/s     0 p/s

Statistiques sur 40 secondes :

Métrique	RX (Réception)	TX (Transmission)
Bytes	572 B	392 B
Max	480 bit/s	332 bit/s
Average	114 bit/s	78 bit/s
Packets	8	5
Max p/s	1 p/s	0 p/s

Mon observation : Trafic réseau quasi nul, normal pour un réseau au repos.

Pendant le scan Nessus (un seul hôte)

Même commande pendant le scan :

  
sudo vnstat -l -i eth0

Résultat observé (scan en cours) :

Monitoring eth0...    (press CTRL-C to stop)

   rx:   307.92 kbit/s   641 p/s          tx:   380.41 kbit/s   767 p/s

Statistiques sur 38 secondes :

Métrique	RX (Réception)	TX (Transmission)
Bytes	1.04 MiB	1.34 MiB
Max	414.81 kbit/s	480.59 kbit/s
Average	230.57 kbit/s	296.72 kbit/s
Packets	18,252	22,733
Max p/s	864 p/s	969 p/s

Temps d’exécution :

real  0m38.588s
user  0m0.002s
sys   0m0.016s

Analyse comparative

Ce qui m’a frappé :

Aspect	Sans scan	Avec scan (1 hôte)	Multiplication
Bytes RX	572 B	1.04 MiB	~1,860x
Bytes TX	392 B	1.34 MiB	~3,500x
Packets RX	8	18,252	~2,280x
Packets TX	5	22,733	~4,546x
Avg RX	114 bit/s	230.57 kbit/s	~2,020x
Avg TX	78 bit/s	296.72 kbit/s	~3,800x

Conclusion critique :

Le scan d’un seul hôte génère des milliers de fois plus de trafic que l’activité normale du réseau. Sur un réseau à faible bande passante ou congestionné, cela peut avoir un impact sévère.

Implications pratiques :

Pour un réseau à faible BP :

Scanner hôte par hôte plutôt qu’en batch
Réduire Max Hosts Per Scan
Scheduler les scans hors heures de pointe

Pour équipements fragiles :

Activer throttling (limitation de débit)
Utiliser Safe Checks
Scanner avec rate-limiting agressif

Pour liens congestionnés :

Éviter de scanner pendant les pics d’usage
Coordonner avec l’équipe réseau
Monitorer l’impact en temps réel avec vnstat

Sur un réseau de production, un scan mal paramétré peut saturer complètement la bande passante et rendre les services inaccessibles. Toujours tester sur un petit échantillon d’abord.

Nessus Skills Assessment

Contexte de la mission

Briefing client

Client : Inlanefreight

Demande : J’ai été contracté pour effectuer un vulnerability assessment interne sur l’un de leurs serveurs. Le client souhaite une évaluation rapide pour identifier les vulnérabilités significatives.

Contraintes budgétaires :

Pas de budget pour un penetration test complet cette année
Assessment “cursory” (superficiel mais ciblé)
Les résultats pourraient justifier un budget supplémentaire

Objectif stratégique : Les résultats permettront au CISO de demander un financement additionnel au Board of Directors pour des tests de sécurité plus approfondis l’année prochaine.

Pour les débutants : Un vulnerability assessment est moins approfondi qu’un pentest. On identifie les vulnérabilités mais on ne les exploite généralement pas. C’est moins cher et plus rapide, mais aussi moins détaillé.

Cible du scan

Type de serveur : Windows Server
Usage : Serveur de développement
IP cible : 172.16.16.100

Prérequis techniques

Accès à Nessus

URL d’accès :

https://<IP>:8834

Credentials Nessus :

Username : htb-student
Password : HTB_@cademy_student!

Accès SSH alternatif : Les mêmes credentials permettent de se connecter en SSH au VM cible pour configurer Nessus si nécessaire.

Il peut falloir 1-2 minutes pour que l’instance cible spawn. Patience !

Configuration du scan requis

Type de scan à utiliser

Template sélectionné : BASIC NETWORK SCAN

Modifications obligatoires

1. Configuration des ports :

Modifier le template pour scanner TOUS les ports (ALL ports)
Laisser toutes les autres options par défaut

2. Configuration de la cible :

Target : 172.16.16.100

3. Configuration de l’authentification :

Credentials Windows à utiliser :

Username : administrator
Password : Academy_VA_adm1!

L’authentification est cruciale pour ce scan. Elle permettra à Nessus de vérifier les patches manquants et les vulnérabilités internes que seul un scan authentifié peut détecter.

Paramètres récapitulatifs

Paramètre	Valeur
Scan Type	Basic Network Scan
Ports	ALL (0-65535)
Target	172.16.16.100
Auth Method	Windows Authentication
Username	administrator
Password	Academy_VA_adm1!

Durée du scan

Temps estimé : Jusqu’à 60 minutes

Le scan peut prendre jusqu’à une heure complète.

Alternative : Données pré-populées

Option disponible :

Pour éviter d’attendre la fin du scan, des données de scan pré-populées sont disponibles dans l’environnement Nessus.

Utilisation recommandée :

Utiliser les données pré-populées pour répondre aux questions
Mais pratiquer quand même la configuration et le lancement du scan

C’est une excellente opportunité de s’exercer à configurer un scan authentifié de A à Z, même si tu utilises les résultats pré-calculés pour les questions.

Questions

Quel est le nom d’un des partages SMB accessibles depuis le scan Windows authentifié ? (Un mot)

Ma démarche :

Naviguer dans les résultats du scan authentifié Windows
Chercher les détections liées à SMB shares
Identifier les noms de partages découverts

Quelle était la cible du scan authentifié ?

Réponse évidente : La cible configurée dans le scan.

Quel est le plugin ID de la vulnérabilité de criticité la plus élevée pour le scan Windows authentifié ?

Ma démarche :

Trier les résultats par criticité (severity)
Identifier la vulnérabilité Critical la plus haute
Noter son Plugin ID

Quel est le nom de la vulnérabilité avec le plugin ID 26925 depuis le scan Windows authentifié ? (Sensible à la casse)

Ma démarche :

Utiliser la fonction de recherche dans Nessus
Chercher le Plugin ID 26925
Copier le nom exact (attention à la casse !)

Attention : La réponse est sensible à la casse. Copie-colle le nom exactement comme il apparaît dans Nessus.

Sur quel port tourne le serveur VNC dans le scan Windows authentifié ?

Ma démarche :

Chercher les détections liées à VNC
Identifier le port sur lequel VNC a été détecté
Noter le numéro de port

Rappels importants

Authentification :

Username: htb-student
Password: HTB_@cademy_student!

Cible du scan :

IP: 172.16.16.100

Credentials Windows pour le scan :

Username: administrator
Password: Academy_VA_adm1!

N’oublie pas de configurer l’authentification Windows dans l’onglet Credentials du scan, sinon ce ne sera pas un scan authentifié et tu n’obtiendras pas les résultats attendus.

Cours complété

HackTheBox, Learning

This post is licensed under CC BY 4.0 by the author.