Nessus-Schwachstellenscan-Lab — Azure

Vollständiger Lebenszyklus des Schwachstellenmanagements — scannen, finden, beheben, verifizieren — durchgeführt in meiner Live-Azure-AD-Lab-Umgebung mit einem dedizierten, per Terraform bereitgestellten Nessus-Scanner.

Was dieses Lab demonstriert

Ich habe eine dedizierte Ubuntu-24.04-Scanner-VM in meiner bestehenden Azure-AD-Lab-Umgebung bereitgestellt, einen nicht authentifizierten Basisscan und einen Scan mit Anmeldedaten gegen einen Domänencontroller, einen Dateiserver und einen in die Domäne eingebundenen Client ausgeführt, die Ergebnisse analysiert, einen Befund mit hohem Schweregrad (CVE-2013-3900) durch Härtung der Registry per PowerShell behoben und den Fix mit einem erneuten Scan verifiziert. Dies ist der vollständige Workflow, den Unternehmensprogramme für Schwachstellenmanagement kontinuierlich ausführen.

Dieser Sprung bei den Befunden ist das gesamte Argument für das Scannen mit Anmeldedaten — der in diesem Lab behobene Befund CVE-2013-3900 mit hohem Schweregrad ist eine lokale Prüfung, die der nicht authentifizierte Scan überhaupt nicht sehen konnte.

Architektur

Dedizierte NESSUS01-Scanner-Appliance auf Subnet-Servers mit authentifizierten Scan-Pfaden zu allen drei Windows-Zielen. Die Verwaltungsebene ist nur über einen SSH-Tunnel von der Admin-Workstation aus erreichbar — Port 8834 ist niemals öffentlich exponiert.

Der Scanner wird in das bestehende Lab-VNet aus meiner Enterprise Azure Infrastructure Automation-Reihe eingebunden und als unabhängige Terraform-Konfiguration mit eigenem Remote-State bereitgestellt.

Design-Entscheidungen, die ich getroffen habe:

• Dedizierte Scanner-VM statt Installation von Nessus auf einem Ziel. Unternehmens-Scanner werden als unabhängige Netzwerkappliances mit ungehinderter Sichtlinie zu ihren Zielen platziert — das Scannen von einem Host, der selbst ein Ziel ist, verfälscht die Ergebnisse.
• Terraform-Datenquellen gegen die bestehende Infrastruktur. Die Scanner-Konfiguration referenziert das bestehende VNet und Subnetz über data-Blöcke, anstatt sie zu duplizieren. Der State ist in einem eigenen nessus-scanner.tfstate-Schlüssel isoliert, sodass der Scanner erstellt und zerstört werden kann, ohne den Kern-Lab-State zu berühren.
• Die Nessus-Web-UI (Port 8834) ist niemals öffentlich exponiert. Die NSG erlaubt nur SSH (22) von meiner Admin-IP; ich erreiche die UI über einen SSH-Tunnel (ssh -L 8834:localhost:8834). Die Exponierung der Verwaltungsebene ist der häufigste Weg, auf dem Scanner-Appliances kompromittiert werden.
• Nur SSH-Schlüsselauthentifizierung — ed25519-Schlüsselpaar, keine Passwort-Authentifizierung auf dem Scanner.

Phase 0 — Sicherheitsüberprüfung vor dem Start (Übe, was du scannst)

Bevor ich etwas bereitgestellt habe, habe ich die bestehenden NSG-Regeln geprüft — und genau die Art von Fehlkonfiguration gefunden, die dieses Lab aufdecken soll: Die RDP-Regel erlaubte Quelle * (beliebige IP im Internet).

Überprüfung vor dem Start: Die Abfrage az network nsg list deckt auf, dass Allow-RDP-3389 für jede Quelle (*) offen ist.

Ich habe sie vor dem Fortfahren auf meine aktuelle öffentliche IP eingeschränkt:

az network nsg rule update -g RG-FileServerLab --nsg-name NSG-RDP \
  -n Allow-RDP-3389 --source-address-prefixes $(curl -s ifconfig.me)

Dieselbe Regel nach der Behebung — Quelle auf eine einzelne Admin-IP eingeschränkt.

Eine Exposition in der eigenen Umgebung zu finden und zu beheben, bevor man einen Scanner darauf richtet, ist der Denkwechsel vom „Ausführen eines Tools" zum „Sicherheit betreiben".

Phase 1 — Den Scanner mit Terraform bereitstellen

Fünf Ressourcen — öffentliche IP, NSG, NIC, NSG-Zuordnung und die Ubuntu-VM — in weniger als zwei Minuten bereitgestellt:

terraform apply: 5 hinzugefügt, 0 geändert, 0 zerstört. Die Ausgaben enthalten den einsatzbereiten SSH-Befehl.

Anschließend habe ich mich per SSH verbunden und die Headless-Installation von Nessus Essentials 10.12.1 durchgeführt:

Erste SSH-Verbindung zu NESSUS01 mit schlüsselbasierter Authentifizierung — Ubuntu 24.04 läuft unter 10.0.1.8 und ist bereit für die Headless-Nessus-Installation.

Phase 2 — Nicht authentifizierter Basisscan

Erster Scan: keine Anmeldedaten — das sieht ein Angreifer im Netzwerksegment.

Basic Network Scan, der alle drei Hosts anvisiert: 10.0.1.5, 10.0.1.6, 10.0.1.7.

Basisergebnisse: 35 Befunde auf 3 Hosts, die Auth-Spalte zeigt Fail — Nessus konnte sich nicht anmelden, sodass jedes Ergebnis ausschließlich aus externer Beobachtung stammt.

Phase 3 — Scan mit Anmeldedaten

Das Scannen mit Anmeldedaten ist der Unternehmensstandard für internes Schwachstellenmanagement. Ich habe die Windows-Ziele vorbereitet, indem ich den Dienst Remote Registry aktiviert und die erforderlichen Firewall-Regelgruppen im Domänenprofil geöffnet habe:

Set-Service -Name RemoteRegistry -StartupType Automatic
Start-Service RemoteRegistry
Set-NetFirewallRule -DisplayGroup "File and Printer Sharing" -Enabled True -Profile Domain
Set-NetFirewallRule -DisplayGroup "Windows Management Instrumentation (WMI)" -Enabled True -Profile Domain

Zielvorbereitung auf FS01 — RemoteRegistry läuft mit automatischem Start, WMI- sowie Datei- und Druckerfreigabe-Regeln sind für das Domänenprofil aktiviert.

Ich habe die Windows-Anmeldedaten im Scan mit den Sicherheitsoptionen konfiguriert, die Unternehmen verlangen: Anmeldedaten niemals im Klartext senden, nur NTLMv2.

Konfiguration der Windows-Anmeldedaten — Domäne LAB, NTLMv1 deaktiviert, Klartextübertragung von Anmeldedaten deaktiviert, automatischer Start von Remote Registry für den Scan aktiviert.

Ergebnisse mit Anmeldedaten: 64 Befunde — eine Steigerung um 83 % gegenüber dem nicht authentifizierten Basisscan auf exakt denselben drei Hosts.

Nach Schweregrad sortierte Befunde, wobei die lokale Prüfung WinVerifyTrust mit hohem Schweregrad nun sichtbar ist — ein Befund, den der nicht authentifizierte Scan nicht erkennen konnte.

Phase 4 — Den Befund mit hohem Schweregrad analysieren: CVE-2013-3900

Plugin #166555 hat WinVerifyTrust Signature Validation (CVE-2013-3900) auf DC01 und FS01 gemeldet — CVSS-v3-Basisscore 8.8, Tenable VPR 9.0. Der Registrierungswert EnableCertPaddingCheck fehlte, sodass sich die Hosts in einem Zustand befanden, in dem ein Angreifer schädlichen Inhalt an eine signierte ausführbare Datei anhängen konnte, ohne deren Authenticode-Signatur ungültig zu machen.

Vollständige Befundanalyse: Die Plugin-Ausgabe bestätigt, dass der Registrierungswert auf 10.0.1.5 und 10.0.1.6 fehlt; der genaue Behebungspfad ist im Abschnitt Solution dokumentiert.

Warum dieser Befund wichtig ist: Es handelt sich um eine Schwachstelle, die durch Konfiguration entschärft wird — es gibt keinen Patch, da Microsoft die Korrektur als Opt-in umgesetzt hat. Frische Windows-Server-2025-Images wurden 2026 ohne diese Korrektur ausgeliefert — dreizehn Jahre nach Veröffentlichung der CVE. Genau diese Klasse von Problemen erkennen nur das Scannen mit Anmeldedaten und das Konfigurationsmanagement.

Phase 5 — Beheben und verifizieren

Ich habe den Fix auf den betroffenen Hosts gemäß dem Solution-Abschnitt des Plugins angewendet — EnableCertPaddingCheck = 1 sowohl im 64-Bit- als auch im Wow6432Node-Registrierungspfad — und beide Schlüssel anschließend vor dem erneuten Scan verifiziert:

New-Item -Path "HKLM:\Software\Microsoft\Cryptography\Wintrust\Config" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\Software\Microsoft\Cryptography\Wintrust\Config" `
  -Name "EnableCertPaddingCheck" -Value "1" -Type String

New-Item -Path "HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" `
  -Name "EnableCertPaddingCheck" -Value "1" -Type String

Behebung angewendet und mit Get-ItemProperty verifiziert — beide Registrierungspfade liefern jetzt EnableCertPaddingCheck : 1.

Dann der Schritt, den die meisten überspringen — der Verifikations-Re-Scan. Das Ticket wird erst geschlossen, wenn der Scanner bestätigt, dass der Befund beseitigt ist:

Verifikationsscan (History: 2): Der Befund CVE-2013-3900 mit hohem Schweregrad ist behoben. Der höchste verbleibende Schweregrad ist Mittel.

Finden → analysieren → beheben → verifizieren. Schleife geschlossen.

Demonstrierte Fähigkeiten

Warum das für den Job wichtig ist

Schwachstellenmanagement ist eine Kernfunktion in praktisch jeder Security-Operations-, Cloud-Security- und GRC-Rolle. Dieses Lab deckt den gesamten Job ab — nicht nur das Ausführen eines Scanners, sondern auch das sichere Entwerfen seiner Platzierung, das korrekte Vorbereiten der Ziele, das Unterscheiden von Signal und Rauschen in den Ergebnissen, das Durchführen einer Behebung und den Nachweis, dass sie funktioniert hat. Der Vergleich nicht authentifiziert vs. mit Anmeldedaten und der Verifikations-Re-Scan sind die beiden Dinge, die Praktiker von Tool-Bedienern unterscheiden.

Bewertungsbericht

Das vollständige professionelle Deliverable — Executive Summary, Methodik, detaillierte Befundanalyse zu CVE-2013-3900, Bewertung des Restrisikos und priorisierte Empfehlungen — ist als PDF verfügbar:

Vulnerability-Assessment-Report.pdf

Nessus Essentials enthält keinen Berichtsexport, daher wurde dieses Deliverable unabhängig aus den Scandaten erstellt — genau diese Fähigkeit zur Erstellung von Bewertungsberichten lässt die kostenlose Version außen vor.

Verwandte Labs

Dieser Scanner wird in die Umgebung bereitgestellt, die meine Enterprise Azure Infrastructure Automation-Reihe aufgebaut hat:

• Lab 1 — Terraform-Infrastruktur
• Lab 2 — Active Directory
• Lab 3 — NTFS-Dateiserver & RBAC
• Labs 4–6 — Azure RBAC

In diesem Repository werden keine Geheimnisse gespeichert — der Scanner verwendet ausschließlich SSH-Schlüsselauthentifizierung, und die Scan-Anmeldedaten wurden direkt in der Nessus-Konsole eingegeben, niemals in Code eingecheckt.