NT-2026.10.02 DOSSIÊ RED TEAM
NESSUS PARA INICIANTES: GUIA PRÁTICO DE VULNERABILITY SCANNING
Aprenda a usar o Nessus para identificar vulnerabilidades, configurar scans, interpretar resultados e aplicar boas práticas de vulnerability assessment.

Introdução ao Nessus
O Nessus, desenvolvido pela Tenable Network Security, é um dos vulnerability scanners mais amplamente utilizados no mundo. Desde sua criação em 1998 por Renaud Deraison, a ferramenta evoluiu para se tornar um padrão da indústria em vulnerability assessment.
Este guia foi escrito para iniciantes que desejam aprender a utilizar o Nessus na prática: desde a instalação até a interpretação dos resultados, passando pela validação de findings e priorização de correções.
Importante: Este guia assume que você possui um ambiente de laboratório autorizado (máquinas virtuais, rede isolada) para praticar. Nunca execute scans contra sistemas sem autorização explícita por escrito.
O que é o Nessus?
O Nessus é um vulnerability scanner que automatiza a descoberta de vulnerabilidades em sistemas, redes e aplicações, verificando:
- Versões de software e serviços expostos
- Configurações inseguras (compliance)
- Patches de segurança ausentes
- Vulnerabilidades conhecidas (CVEs)
- Credenciais padrão ou fracas
- Malware e backdoors
Versões principais:
- Nessus Essentials (gratuito): até 16 IPs, ideal para aprendizado e labs
- Nessus Professional: para pentesters e consultores, scans ilimitados
- Nessus Expert: inclui web app scanning, container scanning, IaC scanning
- Tenable.sc / Tenable.io: plataformas enterprise para gestão contínua de vulnerabilidades
O Nessus utiliza plugins escritos em NASL (Nessus Attack Scripting Language) — cada plugin testa uma condição específica de vulnerabilidade. Atualmente existem mais de 180.000 plugins disponíveis.
Vulnerability Assessment vs Vulnerability Scanning
É fundamental entender a diferença:
| Conceito | Descrição |
|---|---|
| Vulnerability Scanning | Execução automatizada de ferramenta (ex: Nessus) para identificar vulnerabilidades conhecidas. Gera lista bruta de findings. |
| Vulnerability Assessment | Processo completo: scanning → análise → validação → priorização → remediação → verificação. Envolve julgamento humano. |
O Nessus executa o scanning. O profissional de segurança executa o assessment.
Um scan bruto gera ruído (false positives, findings irrelevantes, duplicatas). O assessment transforma esse ruído em decisões acionáveis: o que corrigir primeiro, o que aceitar como risco, o que mitigar com controles compensatórios.
Conceitos Fundamentais
Antes de usar o Nessus, é essencial entender seus blocos de construção:
| Conceito | O que é | Por que importa |
|---|---|---|
| CVE | Common Vulnerabilities and Exposures — identificador único de vulnerabilidade pública | Referência padronizada para pesquisar, rastrear e corrigir |
| CVSS | Common Vulnerability Scoring System — pontuação de severidade (0.0 a 10.0) | Ajuda a priorizar: Critical (9.0-10.0), High (7.0-8.9), Medium (4.0-6.9), Low (0.1-3.9) |
| Plugin | Teste individual escrito em NASL que verifica uma condição específica | Cada plugin = um teste. O Nessus tem 180k+ plugins. |
| Policy | Conjunto de configurações: quais plugins rodar, credenciais, safe checks, performance | Define como o scan é executado. Templates: Basic Network Scan, Advanced Scan, Web App Scan, etc. |
| Target | IP, range CIDR, hostname, ou lista de hosts a serem escaneados | Define o escopo. Pode ser um IP, uma rede (192.168.1.0/24), ou arquivo com lista. |
| Scan | Execução de uma policy contra targets | Gera findings. Pode ser agendado, único, ou recorrente. |
Dica: Sempre use credentialed scans (scans autenticados via SSH/WinRM/SMB) quando possível. Eles revelam muito mais: patches ausentes, configurações locais, software instalado, registry keys.
Instalação Linux
A referência original demonstra a instalação no Ubuntu 18.04 usando o pacote .deb. Os passos atuais para Ubuntu/Debian modernos:
Linux (Ubuntu/Debian):
# 1. Baixe o .deb do site oficial (tenable.com/downloads/nessus)
wget https://www.tenable.com/downloads/api/v2/pages/nessus/files/Nessus-10.8.3-ubuntu1604_amd64.deb
# 2. Altere permissão e instale
chmod +x Nessus-*.deb
sudo dpkg -i Nessus-*.deb
# 3. Inicie e habilite o serviço
sudo systemctl start nessusd
sudo systemctl enable nessusd
Windows:
- Baixe o
.msido site da Tenable - Execute o instalador (next/next/finish)
- O serviço
Nessusinicia automaticamente
Acesso Web:
- Abra navegador em
https://localhost:8834 - Aceite o certificado auto-assinado (Advanced → Accept Risk)
- Crie conta de administrador
- Insira código de ativação (recebido por email ao registrar no site da Tenable)
- Aguarde download/compilação dos plugins (pode levar 10-30 min na primeira vez)
Nota sobre versões: A referência utiliza Nessus 8.2.3 (2019). A versão atual (2024) é 10.8.x. A interface e fluxo permanecem essencialmente os mesmos, mas a numeração de versão e alguns caminhos de download mudaram. Os screenshots da referência continuam válidos para demonstrar o fluxo visual.

Inicialização do Serviço
Após a instalação do pacote .deb, inicie o serviço Nessus:
sudo systemctl start nessusd
sudo systemctl enable nessusd
O serviço nessusd ficará ativo e escutando na porta 8834.

Acesso Web e Certificado
Acesse a interface web em https://localhost:8834. Como o Nessus usa certificado auto-assinado, o navegador exibirá um aviso de segurança.
- Clique em Advanced (Avançado)
- Clique em Accept the Risk and Continue (Aceitar o risco e continuar)
Isso é esperado em laboratório. Em produção, configure certificado válido.

Criação de Conta Admin
Após aceitar o certificado, o Nessus solicitará a criação de uma conta de administrador:
- Username: escolha um nome (ex:
admin) - Password: defina senha forte
- Confirm: repita a senha
Clique em Submit para criar a conta.

Ativação com Código
Insira o código de ativação recebido por email ao registrar no site da Tenable (https://www.tenable.com/products/nessus/nessus-essentials).
- Nessus Essentials: código gratuito para até 16 IPs
- Professional/Expert: código de licença paga
Após inserir o código, aguarde o download e compilação dos plugins (pode levar 10-30 minutos na primeira execução).

Dashboard Principal
Após a ativação, você verá o dashboard principal do Nessus:
Menu lateral:
- Scans — lista, cria, executa scans
- Policies — gerencia templates de scan
- Reports — exporta resultados (PDF, HTML, CSV, Nessus)
- Settings — configurações globais: usuários, SMTP, proxy, plugin updates
Atualização de plugins: Settings → Plugin Updates → Check for updates (recomendado: auto-update diário).
Dica: Antes do primeiro scan, ajuste em Settings → Scanner → Advanced:
- Max simultaneous hosts: 10-50
- Max simultaneous checks: 5-10 por host
- Scan timeout: 3600s

Criação de Novo Scan
- Clique em Scans → New Scan
- Escolha um Template (Policy):
- Basic Network Scan — bom ponto de partida
- Advanced Scan — controle total de plugins
- Web Application Scan — para apps web (requer Expert)
- Malware Scan — foco em malware/backdoors
- Compliance Scan — CIS, DISA STIG, PCI DSS

Templates e Policies
A aba Policies permite gerenciar e criar templates de scan personalizados. Cada policy define:
- Quais plugins rodar (famílias, plugins individuais)
- Credenciais para scans autenticados
- Safe checks (ON/OFF)
- Performance: max hosts, max checks, timeouts
- Configurações de rede e porta
Templates pré-definidos cobrem os casos mais comuns.

Templates de Policy
Os templates disponíveis incluem:
- Basic Network Scan: scan de rede padrão, não-credenciado
- Advanced Scan: controle granular de cada plugin
- Web Application Scan: foco em vulnerabilidades web (OWASP Top 10)
- Malware Scan: detecção de malware, backdoors, C2
- Compliance Scan: benchmarks CIS, DISA STIG, PCI DSS
- Mobile Device Scan: iOS/Android (requer Expert)
- SCADA/ICS Scan: protocolos industriais

Configuração do Scan
Após escolher o template, configure:
Basic Settings:
- Name:
Lab-Primeiro-Scan-2024 - Description:
Primeiro scan de laboratório - rede 192.168.10.0/24 - Targets:
192.168.10.0/24(ou IP único:192.168.10.20)
Assessment (opcional):
- Credentials: adicione SSH/Windows/SMB para credentialed scan
- Scan Schedule: Once / Daily / Weekly / Monthly
Advanced (opcional):
- Safe Checks: ON (evita checks que podem derrubar serviços)
- Scan slow: para redes instáveis
- Network: selecione interface se multi-homed
Clique Save → o scan aparece na lista, pronto para execução.

Resultados do Scan
- Na lista de scans, clique no play (▶) ao lado do scan criado
- Status mudará:
Pending→Running→Completed/Failed
Durante a execução:
- Progress bar mostra % de hosts completados
- Hosts discovered vai aumentando
- Vulnerabilities found atualiza em tempo real
- Elapsed time mostra tempo decorrido
Possíveis status:
Running— scan em andamentoCompleted— finalizado com sucessoCanceled— usuário parouFailed— erro (credenciais, timeout, rede)Paused— pausado pelo usuário
Dica: Scans credentialed demoram mais (15-60 min/host). Non-credentialed são rápidos (1-5 min/host) mas superficiais.

Detalhes Vulnerabilidade Critical
Ao clicar em um scan concluído, você verá 4 abas principais:
1. Hosts — lista de hosts descobertos, com IP, OS detectado, portas abertas, contagem de vulns por severidade.
2. Vulnerabilities — lista consolidada de findings:
- Severity (Critical/High/Medium/Low/Info) — cor codificada
- Plugin Name — nome do plugin que detectou
- Family — categoria (ex: Windows, Web Servers, Databases)
- Count — quantos hosts afetados
- Clique no nome → detalhes do finding
3. Remediations — agrupamento por solução
4. Compliance — se usou policy de compliance
Detalhes de um finding Critical (clique no nome):
- Description — o que é a vulnerabilidade
- Solution — como corrigir (patch, config change, workaround)
- See Also — referências: CVE, Bugtraq, vendor advisory
- Risk Factor — Critical
- CVSS v3.1 Base Score + Vector String
- Plugin Output — evidência específica: versão detectada, banner, output do comando
- Hosts — lista de hosts afetados com porta/protocolo

Detalhes Vulnerabilidade High
Finding de severidade High apresenta estrutura similar:
- Severity: High
- Plugin Name: ex: “SMB Signing not required”
- Family: Windows
- Risk Factor: High
- CVSS v3.1: 7.0-8.9
- Plugin Output: detalhes técnicos específicos (ex: configuração SMB, versões TLS)
- Hosts: IPs afetados com porta/protocolo
Exemplo prático: TLS 1.0 habilitado, SMB signing desabilitado — ambos permitem ataques de downgrade e relay.

Instalação Windows
- Baixe o
.msido site da Tenable (https://www.tenable.com/downloads/nessus) - Execute o instalador (next/next/finish)
- O serviço
Nessusinicia automaticamente - Acesse
https://localhost:8834no navegador
O fluxo de configuração inicial (certificado, conta, ativação) é idêntico ao Linux.

Certificado Windows
Assim como no Linux, o Windows apresentará aviso de certificado auto-assinado ao acessar https://localhost:8834.
- Clique em Advanced
- Clique em Accept the Risk and Continue
O procedimento é idêntico ao Linux.

Conta Windows
Crie a conta de administrador no Windows:
- Username:
admin - Password: senha forte
- Confirm: repita a senha
Clique Submit.

Ativação Windows
Insira o código de ativação recebido por email (Nessus Essentials, Professional ou Expert).
Aguarde download/compilação dos plugins (10-30 min na primeira vez).

Scans Windows
Após ativação, a interface de scans no Windows é idêntica ao Linux:
- Scans → New Scan
- Escolha template (Basic Network Scan, etc.)
- Configure targets (ex:
192.168.10.0/24) - Adicione credenciais Windows (SMB/WinRM) para credentialed scan
- Execute e acompanhe resultados
Dica: No Windows, scans credentialed via WinRM/SMB fornecem detalhes de registry, patches KB, software instalado.

Severidade, CVE, CVSS e Classificação
O Nessus classifica findings em 5 níveis (Risk Factor):
| Severidade | CVSS v3.1 Base | Significado | Ação típica |
|---|---|---|---|
| Critical | 9.0 – 10.0 | Exploração remota fácil, impacto total | Corrigir em 24-72h |
| High | 7.0 – 8.9 | Exploração provável, impacto alto | Corrigir em 7 dias |
| Medium | 4.0 – 6.9 | Exploração condicional, impacto moderado | Corrigir em 30 dias |
| Low | 0.1 – 3.9 | Exploração difícil, impacto baixo | Corrigir em 90 dias |
| Info | 0.0 | Informativo, sem risco direto | Revisar se necessário |
CVSS v3.1 Vector String (ex: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H):
- AV (Attack Vector): N=Network, A=Adjacent, L=Local, P=Physical
- AC (Attack Complexity): L=Low, H=High
- PR (Privileges Required): N=None, L=Low, H=High
- UI (User Interaction): N=None, R=Required
- S (Scope): U=Unchanged, C=Changed
- CIA (Confidentiality/Integrity/Availability): H=High, L=Low, N=None
CVE — Identificador único (ex: CVE-2021-44228 = Log4Shell). Permite buscar detalhes no NVD, referências, exploits conhecidos.
Dica: O Nessus mostra Risk Factor (sua classificação interna) que pode diferir ligeiramente do CVSS puro, pois considera exploit availability, age, etc.
Falsos Positivos e Validação
O Nessus classifica findings em 5 níveis (Risk Factor):
| Severidade | CVSS v3.1 Base | Significado | Ação típica |
|---|---|---|---|
| Critical | 9.0 – 10.0 | Exploração remota fácil, impacto total | Corrigir em 24-72h |
| High | 7.0 – 8.9 | Exploração provável, impacto alto | Corrigir em 7 dias |
| Medium | 4.0 – 6.9 | Exploração condicional, impacto moderado | Corrigir em 30 dias |
| Low | 0.1 – 3.9 | Exploração difícil, impacto baixo | Corrigir em 90 dias |
| Info | 0.0 | Informativo, sem risco direto | Revisar se necessário |
CVSS v3.1 Vector String (ex: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H):
- AV (Attack Vector): N=Network, A=Adjacent, L=Local, P=Physical
- AC (Attack Complexity): L=Low, H=High
- PR (Privileges Required): N=None, L=Low, H=High
- UI (User Interaction): N=None, R=Required
- S (Scope): U=Unchanged, C=Changed
- CIA (Confidentiality/Integrity/Availability): H=High, L=Low, N=None
CVE — Identificador único (ex: CVE-2021-44228 = Log4Shell). Permite buscar detalhes no NVD, referências, exploits conhecidos.
Dica: O Nessus mostra Risk Factor (sua classificação interna) que pode diferir ligeiramente do CVSS puro, pois considera exploit availability, age, etc.
Priorização e Remediação
Finding ≠ Vulnerabilidade confirmada. O scanner reporta possíveis vulnerabilidades baseadas em assinaturas e heurísticas.
Causas comuns de false positives:
- Version detection imprecisa (banner spoofing, backported patches)
- WAF/IPS bloqueando exploit mas scanner detecta versão vulnerável
- Configuração não-padrão que mitiga a vuln mas scanner não detecta
- Honeypots / deception technology
- Scanner não consegue autenticar para local check
Metodologia de validação:
- Leia o Plugin Output — qual a evidência exata? (versão, banner, output de comando)
- Verifique no host alvo —
ssh user@host "comando de verificação" - Consulte o vendor advisory — o patch existe? Já foi aplicado? (backporting comum em Linux)
- Teste de exploit controlado (apenas em lab) — o exploit funciona?
- Verifique compensating controls — WAF, EDR, firewall bloqueiam exploração?
- Documente — marque como false positive no Nessus com justificativa
Dica: No Nessus, clique no finding → Mark as False Positive → adicione nota. Isso remove do relatório e melhora futuros scans.
Exemplo Prático: Fluxo Completo
Priorização moderna vai além do CVSS Base:
| Método | O que considera | Ferramenta |
|---|---|---|
| CVSS Environmental | Asset value, security requirements, modified base | Nessus, calculadora FIRST |
| EPSS | Probabilidade de exploração nos próximos 30 dias | FIRST EPSS API, Tenable |
| CISA KEV | Vulnerabilidades ativamente exploradas agora | CISA KEV Catalog, Tenable |
| Asset Criticality | Valor do negócio, exposição, sensibilidade dos dados | CMDB, asset inventory |
| Threat Intelligence | Campanhas ativas, APTs visando seu setor | TIP, feeds |
Fluxo de remediação:
- Patch — aplicar update do vendor (ideal)
- Configuration Change — disable feature, change config, restrict access
- Compensating Control — WAF rule, EDR rule, firewall block, network segmentation
- Risk Acceptance — documentar, assinar, monitorar, revisar periodicamente
SLA sugerido:
- Critical: 72h
- High: 7 dias
- Medium: 30 dias
- Low: 90 dias
Validação pós-correção: Rode novo scan (targeted) apenas nos hosts/portas corrigidos para confirmar.
Nessus em Pentest e Red Team
Ambiente (fictício, autorizado):
- Attacker: Kali Linux (192.168.10.10) com Nessus Essentials
- Target: Windows 10 (192.168.10.20) + Ubuntu 22.04 (192.168.10.21)
- Rede: 192.168.10.0/24 (laboratório isolado)
Fluxo:
- Scan Inicial (Basic Network Scan, targets 192.168.10.20-21, non-credentialed)
- Resultado: 12 findings (3 High, 5 Medium, 4 Low)
- High: SMB Signing not required, TLS 1.0 enabled
- Análise & Validação
- SMB Signing: confirmado via
smbclient -L //192.168.10.20 - TLS 1.0: confirmado via
openssl s_client -connect 192.168.10.20:443 -tls1
- Correção (Remediação)
- Windows: Enable SMB Signing via GPO, disable TLS 1.0/1.1 no registry
- Ubuntu:
sudo apt update && sudo apt upgrade, disable TLS 1.0 no Apache/Nginx
- Re-scan de Validação (targeted scan nos mesmos hosts)
- Resultado: 0 High, 1 Medium (TLS 1.2 only), 3 Low
- Findings High eliminados → validação bem-sucedida
Lições:
- Credentialed scan teria encontrado mais (patches ausentes, config registry)
- Safe checks ON evitou instabilidade
- Documentar cada passo para relatório final
Perspectiva Defensiva (Blue Team)
Como operadores de Red Team usam o Nessus:
- Recon passivo/ativo — Scan inicial mapeia attack surface: hosts vivos, portas, serviços, versões, OS.
- Attack Surface Mapping — Findings revelam:
- Serviços expostos desnecessários (RDP, SMB, WinRM, SSH, DBs)
- Versões vulneráveis (ex: EternalBlue, BlueKeep, PrintNightmare)
- Configurações fracas (SMB signing off, NTLM relay possible, LLMNR enabled)
- Vulnerability Chaining — Encadear findings:
- SMB relay + NTLM relay → Domain Admin
- Kerberoasing (SPN scan) + AS-REP Roasting → credenciais de serviço
- Web app vuln (RCE) → foothold → lateral movement via SMB/WMI
- Credential Reuse — Credenciais encontradas (default/weak) testadas em outros hosts via SMB/WinRM/SSH/RDP.
- Credentialed Scan pós-exploração — Após foothold, rodar credentialed scan a partir do host comprometido (pivot) para enumerar rede interna.
Importante: Red Team valida antes de explorar. O scan guia, não substitui a validação manual.
Boas Práticas e Erros Comuns
Como o Blue Team usa resultados do Nessus:
- Exposure Identification — Mapear ativos expostos na internet e rede interna
- Patch Prioritization — Focar em KEV + asset critical + CVSS High/Critical
- Configuration Hardening — Findings de compliance (CIS, STIG) guiam hardening
- Attack Surface Reduction — Desabilitar serviços desnecessários, segmentar redes
- Detection Engineering — Plugin outputs viram regras de SIEM/EDR
- Compliance Reporting — Relatórios para auditoria (PCI DSS, LGPD, etc.)
Métricas de maturidade de VA:
- MTTR (Mean Time To Remediate) decrescente
- Vulnerability aging controlado
- Recorrência mínima de findings
- Coverage expandindo (credentialed scans, novos segmentos)
Limitações do Nessus
| Boa Prática | Por que | Erro Comum |
|---|---|---|
| Credentialed scans sempre que possível | Revela 3-5x mais findings | Usar só non-credentialed |
| Safe Checks = ON | Evita derrubar serviços frágeis | Desligar para “mais findings” |
| Scan windows definidas | Evita impacto em produção | Scan em horário comercial |
| Excluir IPs sensíveis | Evita derrubar sistemas críticos (SCADA, medical, etc.) | Scan everything |
| Segmentar scans por rede/função | Melhor performance, relatórios focados | Um scan gigante para tudo |
| Atualizar plugins antes de scan crítico | Novos CVEs, novos plugins | Plugins desatualizados |
| Documentar exclusões e justificativas | Auditoria, compliance | “Esqueci de excluir” |
| Re-scan após correção | Valida se correção funcionou | Assumir que patch funcionou |
Performance tuning:
Max simultaneous hosts: 20-50Max simultaneous checks: 5-10Plugin timeout: 300-600sNetwork timeout: 30-60s
Considerações Éticas e Legais
O que o Nessus NÃO faz bem (ou não faz):
| Limitação | Explicação |
|---|---|
| Zero-days | Só detecta vulns com plugin publicado (CVE conhecido) |
| Vulnerabilidades lógicas/negócio | BAC/IDOR, race conditions, auth bypass — requer análise manual/DAST |
| Client-side (XSS, CSRF) | Cobertura limitada; use DAST dedicado (Burp, OWASP ZAP) |
| Custom code / SAST | Código proprietário — use SAST (SonarQube, Checkmarx, Semgrep) |
| Encrypted traffic (TLS 1.3, cert pinning) | Scanner não inspeciona payload criptografado |
| IoT/OT protocols proprietários | Cobertura parcial; use scanners especializados |
| Scan evasion | Fragmentação, timing, encoding podem burlar detecção |
| Credential management | Vault integration limitada; rotação manual |
Responsabilidade do analista:
- Finding ≠ Vulnerabilidade confirmada — valide sempre
- CVSS Base ≠ Risco real — contextualize com asset value, threat intel
- Compliance ≠ Segurança — checklist ≠ postura real
- Tool Output ≠ Relatório — adicione contexto, evidência, recomendação
Conclusão
Use o Nessus apenas em:
- Ativos de sua propriedade
- Ambientes com autorização explícita, por escrito (Rules of Engagement)
- Pentest/Red Team/VA com escopo e regras definidos
- Laboratórios controlados e autorizados
Proibições absolutas:
- Scan de infraestrutura de terceiros sem autorização
- Uso de findings para acesso não autorizado
- Compartilhamento de relatórios com dados sensíveis sem controle
- Tentativa de exploração fora do escopo
- Uso de credenciais encontradas (default/weak) fora do contexto autorizado
Legislação aplicável:
- Brasil: Lei nº 12.737/2012 (Carolina Dieckmann), Lei nº 13.709/2018 (LGPD)
- EUA: CFAA (Computer Fraud and Abuse Act)
- EU: GDPR (Art. 32 — security of processing)
- Internacional: Budapest Convention on Cybercrime
Responsible Disclosure: Se descobrir zero-day durante scan autorizado, reporte ao vendor via canal oficial (ex: Tenable ZDI, vendor security@) antes de divulgar publicamente.
Data Handling: Findings podem conter PII, credenciais, IPs internos. Trate relatórios como confidenciais. Criptografe em trânsito e em repouso. Retention policy definida.