> For the complete documentation index, see [llms.txt](https://capcap-1.gitbook.io/capcap/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://capcap-1.gitbook.io/capcap/readme/ctf-modules/vulnerability-assessment/vuln-assessment.md). # Vuln Assessment Use a vulnerability assessment to find known weaknesses fast. It checks systems, applications, and configs against common risks and security baselines. ### What a vulnerability assessment does * Finds known vulnerabilities. * Validates important findings. * Supports remediation and compliance work. Typical sources include: * Vulnerability scanners * Manual validation * Security standards such as PCI DSS or OWASP ### What it does not do A vulnerability assessment does not try to fully simulate an attacker. It usually does **not** include: * Privilege escalation * Lateral movement * Full attack chaining ### Vulnerability assessment vs pentest #### Vulnerability assessment Use this when you want broad coverage and regular checks. Focus: * Identify known issues * Confirm critical findings * Produce a remediation list #### Penetration test Use this when you want to measure real impact. Focus: * Exploit weaknesses * Chain findings together * Show what an attacker can actually reach ### When to use each Start with vulnerability assessments if the environment still needs baseline hardening. Add pentests after the team can consistently fix findings and manage scope. {% hint style="info" %} Both are useful. They solve different problems. {% endhint %} ### Other assessment types * **Security audit** — checks compliance against required standards. * **Bug bounty** — invites external researchers to report flaws. * **Red team** — simulates a real attacker with a defined objective. * **Purple team** — combines offensive and defensive teams in one exercise. ### Quick notes * Define the scope first. * Scan the target assets. * Validate important findings manually. * Rate issues by risk. * Build a remediation plan. ### Key terms * **Vulnerability** — a weakness in a system, application, or process. * **Threat** — something that can exploit a weakness. * **Exploit** — code or a technique that uses a weakness. * **Risk** — the likelihood and impact of harm. ### Assessment standards Standards keep assessments consistent, defensible, and repeatable. They also help meet legal, regulatory, and customer requirements. ### Compliance standards Common compliance frameworks include: * **PCI DSS** — requires controls and scanning for cardholder data environments. * **HIPAA** — requires risk assessment and protection of healthcare data. * **FISMA** — requires documented security controls for government systems. * **ISO 27001** — requires an effective information security management system. {% hint style="info" %} Compliance matters, but risk should still drive the program. {% endhint %} ### Pentest standards Pentests need clear scope, legal approval, and rules of engagement. They should prove risk with minimal disruption. Common standards include: * **PTES** — covers pre-engagement, analysis, exploitation, post-exploitation, and reporting. * **OSSTMM** — covers human, physical, wireless, telecom, and data network testing. * **NIST** — follows planning, discovery, attack, and reporting phases. * **OWASP** — focuses on web, mobile, and application security testing. ### Standards to remember * Use compliance standards to meet external requirements. * Use pentest standards to structure how testing is performed. * Keep scope and authorization clear before any assessment starts. ### CVSS [CVSS](https://www.first.org/cvss/) is the standard way to score vulnerability severity. Scanners often assign a CVSS score automatically. You should still understand how the score is built and what it means. ### What CVSS measures CVSS rates a vulnerability by combining: * Exploitability * Impact * Environmental context The score helps teams prioritize remediation work. ### Base metrics Base metrics describe the core technical severity of the issue. #### Exploitability Exploitability looks at: * Attack vector * Attack complexity * Privileges required * User interaction #### Impact Impact looks at the CIA triad: * **Confidentiality** — what data can be exposed * **Integrity** — what data can be changed * **Availability** — what services can be disrupted ### Temporal metrics Temporal metrics change as the situation changes. They include: * **Exploit code maturity** — how usable public exploit code is * **Remediation level** — whether a fix or workaround exists * **Report confidence** — how well the issue is confirmed ### Environmental metrics Environmental metrics adjust the score for a specific organization. They reflect how much confidentiality, integrity, and availability matter in that environment. The same vulnerability can have a different priority in different networks. ### Quick example A remote code execution bug with no user interaction usually scores high. The score may rise further if public exploit code exists and the target system is business-critical. ### Related model [DREAD](https://en.wikipedia.org/wiki/DREAD_\(risk_assessment_model\)) is another risk rating model. It considers: * Damage potential * Reproducibility * Exploitability * Affected users * Discoverability ### Useful reference Use the [NVD CVSS calculator](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator) when you need to score a finding manually. ### OVAL and CVE Use OVAL and CVE to describe vulnerabilities in a standard way. They help scanners, reports, and analysts talk about the same issue clearly. ### OVAL [OVAL](https://oval.mitre.org/) is a standard for describing system state and security checks. It helps identify issues without directly exploiting the target. #### What OVAL is used for * Identify system configurations * Evaluate the current state * Report findings in a structured way #### Common OVAL definition types * **Vulnerability definitions** — identify known vulnerabilities * **Compliance definitions** — check policy compliance * **Inventory definitions** — detect installed software * **Patch definitions** — check whether required patches exist OVAL content is commonly used in compliance and scanner templates. ### CVE [CVE](https://cve.mitre.org/) is the standard catalog for publicly known vulnerabilities. Each issue gets a unique ID such as `CVE-2021-34527`. That ID gives teams one shared reference for the same flaw. #### Why CVE matters * Standardizes vulnerability names * Makes scanner output easier to track * Links issues to vendor advisories and references ### How a CVE is obtained The process usually looks like this: 1. Confirm the issue is new and qualifies as a vulnerability. 2. Contact the affected vendor. 3. Work with the right CNA or a third-party coordinator. 4. Submit the request if needed. 5. Share supporting details until the CVE is assigned and published. ### Responsible disclosure Disclose issues to the vendor before public release when possible. That gives the vendor time to investigate and prepare a fix. If a vulnerability is public before a patch exists, it may become a `zero day`. ### Example CVEs * [CVE-2020-5902](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5902) — unauthenticated remote code execution in BIG-IP TMUI. * [CVE-2021-34527](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-34527) — PrintNightmare remote code execution in the Windows Print Spooler. ### Vulnerability scanning overview Vulnerability scanning uses automated checks to find known issues in: * Network devices * Servers and workstations * Applications Scanners help with coverage. They do **not** replace manual validation. ### What scanners do Scanners usually: * identify known vulnerabilities * flag missing patches * detect weak configurations * test for common application issues Some checks are static. Some are dynamic. ### Static vs dynamic checks #### Static checks Static checks match versions, banners, or configurations against known issues. They are fast, but they can produce false positives. #### Dynamic checks Dynamic checks send safe test payloads to confirm likely weaknesses. Examples include: * weak credentials * SQL injection probes * command injection probes ### Authenticated vs unauthenticated scans Run both when possible. * **Unauthenticated scans** show what an external attacker may see. * **Authenticated scans** show missing patches and internal misconfigurations more accurately. Scanning should support a regular patch management process. ### Common tools Common vulnerability scanners include: * **Nessus** * **Qualys** * **Nexpose** * **OpenVAS** ### Nessus [Nessus Essentials](https://community.tenable.com/s/article/Nessus-Essentials) is the free entry version of Nessus. It is useful for learning the platform and running small scans. ### OpenVAS [OpenVAS](https://www.openvas.org/) is an open-source vulnerability scanner from Greenbone. It supports both authenticated and unauthenticated network scanning. ### Nessus notes * Start with **Basic Network Scan** for a general pass. * Main template groups: **Discovery**, **Vulnerabilities**, and **Compliance**. * Use common ports first, then widen scope if needed. * Leave fragile device checks off unless they are clearly in scope. * Keep **safe checks** enabled by default. * Use web checks only for web targets. * Use authenticated scans when valid credentials are available. * Only enable brute force or user enumeration if the rules allow it. ### Nessus policies * Policies are reusable scan templates. * Use them for repeatable client, web, or compliance scans. * Policies can be imported and exported. * Saved policies appear under **User Defined** templates. ### Nessus plugins * Nessus uses [NASL](https://en.wikipedia.org/wiki/Nessus_Attack_Scripting_Language) plugins. * Plugins contain detection logic, impact, and remediation details. * Severity levels: `Critical`, `High`, `Medium`, `Low`, `Info`. * Use plugin rules to hide accepted false positives for specific hosts. ### Credentialed scanning notes * Credentialed scans improve coverage and patch visibility. * Nessus supports SSH, Kerberos, LM/NTLM, passwords, and database authentication. * It also supports plaintext authentication for some services such as FTP, HTTP, IMAP, IPMI, and Telnet. * Confirm in scan results that authentication actually succeeded. {% hint style="info" %} Use scanners for coverage. Validate high-value findings manually before you report them. {% endhint %} ### Working with Nessus output * Nessus can export reports for sharing, analysis, or archiving. * Raw scan data can also be exported for other tools. * Tools such as [EyeWitness](https://github.com/FortyNorthSecurity/EyeWitness) can help review web findings faster. ### Nessus report formats * **PDF** — good for sharing readable results * **HTML** — good for browsing findings interactively * **CSV** — good for filtering, analytics, and imports into other tools PDF and HTML reports can include an executive summary or custom report content. CSV exports are useful for remediation tracking and analysis. {% hint style="info" %} Do not use a raw Nessus export as the final client deliverable. Use it as appendix or supporting data. {% endhint %} ### Nessus export formats * **`.nessus`** — XML export with scan settings and plugin output * **`.db`** — includes the `.nessus` content plus scan knowledge base, audit trail, and attachments Use raw exports when you need to: * archive scans * reimport into other tooling * automate analysis ### Output handling notes * Group findings by issue and affected assets. * Prioritize critical and high findings first. * Validate important findings before escalation. * Export to CSV when you need sorting, filtering, or bulk review. ### Automation notes * Nessus supports API-based automation. * CLI scripts can download reports in multiple formats. * Custom scripts can automate exports and reporting workflows. ### Scanning issues Scans can cause false positives, missed results, or network impact. Sensitive, legacy, or high-availability systems may need special handling. ### Mitigation notes * Confirm whether sensitive hosts should be excluded. * Scan critical systems separately when needed. * Run disruptive scans outside business hours when possible. * Fine-tune scan settings when results look wrong. * Keep stakeholders informed before and after scanning. ### Common fixes * If firewalls distort host discovery, disable `Ping the remote host`. * Reduce `Max Concurrent Checks Per Host` on busy systems. * Exclude fragile devices such as printers when they are not required. * Use `nessusd.rules` when host-level scan control is needed. * Keep **safe checks** enabled. * Avoid Denial of Service checks unless they are explicitly approved. ### Network impact notes * Vulnerability scans can generate significant traffic. * Impact is worse on congested or low-bandwidth links. * Monitor network usage before and during scans when needed. * Tune rate limits and concurrency to reduce disruption. ### Quick takeaway * Communicate scope early. * Protect fragile systems. * Tune scan settings carefully. * Log scan activity in case investigation is needed later. ### OpenVAS notes * [OpenVAS](https://openvas.org/) is Greenbone's open-source vulnerability scanner. * It supports authenticated and unauthenticated scans. * It is useful for network discovery, vulnerability detection, and compliance-style checks. ### OpenVAS targets * Define targets before you scan. * A target can be a single host or a host list. * Target settings can include ports, authentication, and alive-check behavior. * Authenticated scans usually return better coverage than unauthenticated scans. ### OpenVAS scan configs Common scan configurations: * **Base** — host status and OS info only * **Discovery** — services, ports, hardware, and software info * **Host Discovery** — checks whether hosts are alive * **System Discovery** — deeper host fingerprinting * **Full and fast** — practical default for vulnerability scanning ### OpenVAS NVT notes * OpenVAS uses **NVTs** — Network Vulnerability Tests. * NVT families cover areas such as Windows, Linux, and web applications. * Scan configurations decide which NVTs run. ### OpenVAS scan notes * Create tasks from existing scan configurations. * Match the configuration to the goal before you run it. * Use authenticated scans when you have approved credentials. * Expect scans to take time on larger or slower targets. ### OpenVAS quick takeaway * Set targets carefully. * Pick the right scan config. * Prefer authenticated scans when possible. * Use **Full and fast** as the usual starting point. ### OpenVAS reporting notes * OpenVAS stores results as reports under the scan task. * Reports can include findings, OS details, open ports, and discovered services. * Review findings by severity and affected host before exporting. ### OpenVAS export formats Common export formats: * **XML** * **CSV** * **PDF** * **TXT** * **ITG** ### OpenVAS export notes * Use **XML** when you want to parse or transform the data. * Use **CSV** for filtering and spreadsheet review. * Use **PDF** for readable sharing. * Group findings by severity, host, and service before reporting. ### Reporting tool notes * XML exports work well with external parsers and reporting tools. * Tools such as [openvasreporting](https://github.com/TheGroundZero/openvasreporting) can convert XML into spreadsheet-style reports. * Converted reports can make remediation tracking easier. ### OpenVAS reporting takeaway * Review the report in the console first. * Export in the format that matches the use case. * Use parsed output when you need cleaner summaries or spreadsheet views. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://capcap-1.gitbook.io/capcap/readme/ctf-modules/vulnerability-assessment/vuln-assessment.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.