hack3rs.ca network-security

/learning/openvas-greenbone-credentialed-vs-unauthenticated-scans :: module-8

student@hack3rs:~/learning$ open openvas-greenbone-credentialed-vs-unauthenticated-scans

OpenVAS / Greenbone Scanning: Credentialed vs Unauthenticated Scans

OpenVAS vulnerability scanning gives defenders two very different views of a system depending on whether credentials are used. Understanding why credentialed scans produce dramatically more accurate results is essential before treating any scanner output as a reliable basis for remediation decisions.

Teams that treat scanner output as ground truth without understanding coverage limitations end up with remediation queues that do not reflect actual risk. An unauthenticated scan shows external exposure. A credentialed scan shows the installed software state and configuration issues that an attacker with any foothold could exploit. Using only one or treating them interchangeably leads to both missed findings and wasted remediation effort.

learning-objectives

$Explain the purpose and limitations of unauthenticated scans.
$Explain how credentialed scans improve software/configuration visibility.
$Interpret scanner findings in the context of asset role and compensating controls.
$Build a basic scan schedule and exception process.

example-dataflow-and-observation-paths

Trace each step and identify which log or capture point gives you evidence at that stage. Most triage mistakes happen when someone skips a hop and draws conclusions from an incomplete picture.

$Unauthenticated scan runs against target -> reports open ports and externally visible service fingerprints -> credentialed scan uses SSH or WMI to log in -> checks installed package versions against vulnerability database -> produces findings that unauthenticated scanning cannot see.
$Scanner reports a finding -> analyst SSHs to the target and runs `dpkg -l | grep <package>` or `rpm -qa | grep <package>` to confirm the version -> checks whether the CVE's affected range matches -> if confirmed, opens a ticket with the installed version and CVSS score as evidence.
$Scan runs on schedule -> analyst reviews new findings sorted by CVSS -> filters for CVSS >= 7.0 on internet-facing assets -> assigns owner and due date -> re-scan after patch is applied -> confirms finding is gone or risk-accepted with documented rationale.

baseline-normal-before-debugging

$A credentialed scan against a Debian host returns specific installed package versions that match `dpkg -l` output on the target.
$After a patch is applied and the host is rebooted, a re-scan shows the CVE as absent from the findings report.
$Findings grouped by asset owner show a stable count; a sudden spike without a corresponding change window warrants review.

Expert tip: Record what normal looks like in your actual environment before you test any edge case. A baseline you measured beats a baseline you assumed every time.

concept-breakdown-and-mastery

1. What Scanners Actually Do

$ core idea: Vulnerability scanners probe exposed services, inspect protocol banners, test known behavior patterns, and — in credentialed mode — query the host directly for installed packages, versions, patch state, and configuration settings. They estimate risk based on what they can observe, but they do not replace analyst context and architecture knowledge.

$ defender angle: Scanner output always includes false positives, duplicate findings, and technically valid findings that are operationally low risk because of segmentation, disabled code paths, or compensating controls. Reading scanner output without architecture knowledge produces misleading prioritization.

$ prove understanding: Explain the purpose and limitations of unauthenticated scans.

2. Unauthenticated vs Credentialed Scanning

$ core idea: An unauthenticated scan shows what an external or network-adjacent attacker can directly observe: open ports, service banners, exposed management interfaces, and protocol-level behavior. That is exactly the exposure view you need for internet-facing assets and external attack surface audits. The limitation is that version information may be imprecise and internally installed packages are invisible.

$ defender angle: A credentialed scan uses approved credentials to log into the system and inspect installed software versions, patch state, configuration settings, and local file contents. Coverage improves substantially. The tradeoff is that credentials must be managed carefully — shared scanning accounts with excessive privileges and poor key handling introduce their own risk.

$ prove understanding: Explain how credentialed scans improve software/configuration visibility.

3. Operationalizing Scan Results

$ core idea: Raw scanner severity is a starting point, not a queue. Sort findings by asset criticality, internet exposure, real-world exploitability, and ownership to build a prioritized remediation list that reflects actual risk rather than CVSS arithmetic.

$ defender angle: Define remediation states and stick to them: new, validated, in progress, exception with compensating control, mitigated, remediated, risk accepted. Ambiguous statuses mask backlog growth and create reporting confusion. Reviewers cannot tell how the program is performing if "in progress" means anything from "patching this week" to "been sitting here for eight months."

$ prove understanding: Interpret scanner findings in the context of asset role and compensating controls.

deep-dive-notes-expanded

Read each section, then immediately test the concept in your lab. Theory that you have not verified with a real command or log line does not stick.

1. What Scanners Actually Do

Vulnerability scanners probe exposed services, inspect protocol banners, test known behavior patterns, and — in credentialed mode — query the host directly for installed packages, versions, patch state, and configuration settings. They estimate risk based on what they can observe, but they do not replace analyst context and architecture knowledge.

Scanner output always includes false positives, duplicate findings, and technically valid findings that are operationally low risk because of segmentation, disabled code paths, or compensating controls. Reading scanner output without architecture knowledge produces misleading prioritization.

The value is in running scans consistently over time, not in treating a single scan run as authoritative. Use scans as a recurring measurement practice — scheduled, compared, and tracked — not as a compliance checkbox.

Normal Behavior

A credentialed scan against a Debian host returns specific installed package versions that match `dpkg -l` output on the target.

Failure / Abuse Pattern

An unauthenticated scan shows 12 findings on a host; a credentialed scan shows 47 — the gap is entirely package-level CVEs that only the authenticated check can see.

Evidence To Collect

Explain the purpose and limitations of unauthenticated scans.

2. Unauthenticated vs Credentialed Scanning

An unauthenticated scan shows what an external or network-adjacent attacker can directly observe: open ports, service banners, exposed management interfaces, and protocol-level behavior. That is exactly the exposure view you need for internet-facing assets and external attack surface audits. The limitation is that version information may be imprecise and internally installed packages are invisible.

A credentialed scan uses approved credentials to log into the system and inspect installed software versions, patch state, configuration settings, and local file contents. Coverage improves substantially. The tradeoff is that credentials must be managed carefully — shared scanning accounts with excessive privileges and poor key handling introduce their own risk.

A mature vulnerability program runs both. Unauthenticated scans for external exposure assessment, credentialed scans for internal patch state and configuration hygiene. Results from each feed different remediation workflows.

Normal Behavior

After a patch is applied and the host is rebooted, a re-scan shows the CVE as absent from the findings report.

Failure / Abuse Pattern

A scanner reports a critical OpenSSL CVE on a host where OpenSSL was patched yesterday — the scan ran before the reboot completed the fix; always re-scan after a restart-required patch.

Evidence To Collect

Explain how credentialed scans improve software/configuration visibility.

3. Operationalizing Scan Results

Raw scanner severity is a starting point, not a queue. Sort findings by asset criticality, internet exposure, real-world exploitability, and ownership to build a prioritized remediation list that reflects actual risk rather than CVSS arithmetic.

Define remediation states and stick to them: new, validated, in progress, exception with compensating control, mitigated, remediated, risk accepted. Ambiguous statuses mask backlog growth and create reporting confusion. Reviewers cannot tell how the program is performing if "in progress" means anything from "patching this week" to "been sitting here for eight months."

Verify closure after patching by rescanning or running a manual check. If a finding persists after a supposedly completed remediation, determine whether the patch was not applied, the detection is a false positive, or there is a second configuration path still exposing the weakness.

Normal Behavior

Findings grouped by asset owner show a stable count; a sudden spike without a corresponding change window warrants review.

Failure / Abuse Pattern

A report with 200 findings sits unreviewed for 60 days because no findings have an assigned owner — scan reports need owner columns populated before they leave the scanner.

Evidence To Collect

Interpret scanner findings in the context of asset role and compensating controls.

terminal-walkthroughs-with-example-output

Each walkthrough shows a command and what useful output looks like. Your lab output will differ — focus on which fields to read, not on matching the exact values shown here.

Greenbone / OpenVAS Workflow (Conceptual CLI)

Beginner

Command

sudo systemctl status ospd-openvas || true

Example Output

● service.service - Active: active (running)
Tasks: ... Memory: ...

$ why this matters: Run this against your lab environment and read the output field by field before moving on to the next command in this block. If you cannot explain what you see, re-read the section on greenbone / openvas workflow (conceptual cli).

Scan Validation Checklist Commands

Intermediate

Command

ssh user@target 'uname -a && cat /etc/os-release'

Example Output

# command executed in lab
# review output for expected fields, errors, and anomalies

Evidence Export Prep

Advanced

Command

mkdir -p reports/vuln-scans

Example Output

# command executed in lab
# review output for expected fields, errors, and anomalies

cli-labs-and-workflow

Run these in a lab VM or network segment you own or are authorized to test against. After each command, write down one thing the output told you that you did not already know.

Greenbone / OpenVAS Workflow (Conceptual CLI)

Beginner

sudo systemctl status ospd-openvas || true
sudo systemctl status gvmd || true
sudo systemctl status gsad || true

Run in a lab or authorized environment. Record what fields change when you alter the test conditions.

Scan Validation Checklist Commands

Intermediate

ssh user@target 'uname -a && cat /etc/os-release'
ssh user@target 'dpkg -l | head'   # Debian/Ubuntu example
ssh user@target 'rpm -qa | head'   # RHEL-family example

Run in a lab or authorized environment. Record what fields change when you alter the test conditions.

Evidence Export Prep

Advanced

mkdir -p reports/vuln-scans
cp scan-summary.csv reports/vuln-scans/  # example exported report

Run in a lab or authorized environment. Record what fields change when you alter the test conditions.

expert-mode-study-loop

$Explain the concept out loud as if briefing a colleague — no notes.
$Pick one CLI command and walk through exactly what the output means field by field.
$Name a specific failure mode and the log line or packet flag that reveals it.
$Write down what normal looks like for your lab before you introduce any anomaly.

Progress marker: Move on when you can brief the topic to someone else, run the commands from memory, and explain what a bad result looks like.

knowledge-check-and-answer-key

Answer each question out loud or in writing before you look at the hints. If you cannot answer it, go back to the section that covers it — do not just read the hint and move on.

1. What Scanners Actually Do

Questions

?How would you explain "What Scanners Actually Do" to a new defender in plain language?
?What does normal behavior look like for what scanners actually do in your lab or environment?
?Which logs, packets, or commands would you use to validate what scanners actually do?
?What failure mode or attacker abuse pattern matters most for what scanners actually do?

Show answer key / hints

Answer Key / Hints

#Explain the purpose and limitations of unauthenticated scans.
#A credentialed scan against a Debian host returns specific installed package versions that match `dpkg -l` output on the target.
#sudo systemctl status ospd-openvas || true
#An unauthenticated scan shows 12 findings on a host; a credentialed scan shows 47 — the gap is entirely package-level CVEs that only the authenticated check can see.

2. Unauthenticated vs Credentialed Scanning

Questions

?How would you explain "Unauthenticated vs Credentialed Scanning" to a new defender in plain language?
?What does normal behavior look like for unauthenticated vs credentialed scanning in your lab or environment?
?Which logs, packets, or commands would you use to validate unauthenticated vs credentialed scanning?
?What failure mode or attacker abuse pattern matters most for unauthenticated vs credentialed scanning?

Show answer key / hints

Answer Key / Hints

#Explain how credentialed scans improve software/configuration visibility.
#After a patch is applied and the host is rebooted, a re-scan shows the CVE as absent from the findings report.
#ssh user@target 'uname -a && cat /etc/os-release'
#A scanner reports a critical OpenSSL CVE on a host where OpenSSL was patched yesterday — the scan ran before the reboot completed the fix; always re-scan after a restart-required patch.

3. Operationalizing Scan Results

Questions

?How would you explain "Operationalizing Scan Results" to a new defender in plain language?
?What does normal behavior look like for operationalizing scan results in your lab or environment?
?Which logs, packets, or commands would you use to validate operationalizing scan results?
?What failure mode or attacker abuse pattern matters most for operationalizing scan results?

Show answer key / hints

Answer Key / Hints

#Interpret scanner findings in the context of asset role and compensating controls.
#Findings grouped by asset owner show a stable count; a sudden spike without a corresponding change window warrants review.
#mkdir -p reports/vuln-scans
#A report with 200 findings sits unreviewed for 60 days because no findings have an assigned owner — scan reports need owner columns populated before they leave the scanner.

lab-answer-key-expected-findings

These are reference answers for a generic environment. Replace them with observations from your own lab — what you measured yourself is more useful than what is written here.

Expected Normal Findings

+A credentialed scan against a Debian host returns specific installed package versions that match `dpkg -l` output on the target.
+After a patch is applied and the host is rebooted, a re-scan shows the CVE as absent from the findings report.
+Findings grouped by asset owner show a stable count; a sudden spike without a corresponding change window warrants review.

Expected Failure / Anomaly Clues

!An unauthenticated scan shows 12 findings on a host; a credentialed scan shows 47 — the gap is entirely package-level CVEs that only the authenticated check can see.
!A scanner reports a critical OpenSSL CVE on a host where OpenSSL was patched yesterday — the scan ran before the reboot completed the fix; always re-scan after a restart-required patch.
!A report with 200 findings sits unreviewed for 60 days because no findings have an assigned owner — scan reports need owner columns populated before they leave the scanner.

hands-on-labs

$Run an unauthenticated scan against a lab host and compare findings with a credentialed scan of the same system.
$Classify findings by exposure and business criticality, not only scanner severity.
$Create a remediation ticket template that includes evidence, owner, due date, and validation steps.

common-pitfalls

$Assuming a "clean scan" means a system is secure.
$Running credentialed scans with overly privileged shared accounts and poor key handling.
$No process for validating false positives before escalating remediation.

tools-and-references

completion-outputs

# A scan strategy document (external vs internal vs credentialed)
# A finding triage matrix for vuln operations
# A remediation validation checklist

related-threat-pages

See where these fundamentals appear in real attack scenarios and what evidence defenders look for during triage.

open /threats/vulnerability-exploitation-and-misconfiguration-abuse Vulnerability exploitation and misconfiguration abuse

<- previous page Nmap Scanning Strategy and Safe Validation Workflows -> next page Exploit-Informed Remediation and Asset Criticality Tagging

learning-path-position

Vulnerability & Exposure / Weeks 7-8 · Module 8 of 12