The Weakness Before the Break-In
Vulnerability assessment is a core piece of any real security program. Standards bodies and regulators treat it as mandatory - you can't claim to be "secure" if you've never systematically looked for your own weak spots. Traditionally security professionals focus on technical flaws (bad software, bad configs) but the concept is broader than that.
Vulnerability Research
An ethical hacker has to stay one step ahead of attackers by actively researching new vulnerabilities and exploits. This means:
- Discovering system design faults and weaknesses that might let attackers compromise a system
- Staying informed about new products/technologies and news related to current exploits
- Checking underground hacking sites for newly surfacing vulnerabilities and exploits
- Watching newly released alerts about relevant innovations and product security improvements
Mnemonic - Staying Ahead: "DIG-U"
DIG-U = Discover design faults → Inform yourself on new products/exploits → Go underground (hacking forums, dark web) → Update on newly released security alerts. Vulnerability research is a constant loop, not a one-time task.
The Seven Flavors of "Broken"
The slides break vulnerabilities down into recurring categories. Each one keeps showing up across every system you'll ever test.
Misconfiguration
The most common vulnerability, mostly caused by human error - disabling security settings, improperly authenticated external systems, running unnecessary services. Attackers scan for these easily and then exploit the backend.
Default Installations
Vendors ship devices tuned for usability, not security. If nobody hardens the defaults before connecting the device to a real network, attackers can just guess the known settings.
Buffer Overflows
A coding error where insufficient bounds-checking lets input overflow into adjacent memory, overwriting values it shouldn't touch. Attackers exploit this to hijack program control; the system may crash or behave erratically.
Unpatched Servers
Servers left unpatched/misconfigured become an entry point into the whole network - leading to data exposure, financial loss, or downtime. Regular patching is the fix.
Design Flaws
Universal logical flaws (weak encryption choices, poor data validation) baked into how a system works, letting attackers bypass detection entirely rather than "break in."
Operating System / Application Flaws
OS flaws open the door to Trojans, worms, viruses. Application flaws (poor validation/authorization) enable data tampering and unauthorized config access. Both need timely patching and secure coding.
Open Services
Unnecessary open ports/services can lead to data loss, DoS, and give attackers a launchpad to attack other connected devices. Admins must continuously audit for unneeded ports.
Default Passwords
Manufacturer defaults left unchanged are trivially guessable, opening the door to brute-force and dictionary attacks. Password confidentiality is the whole ballgame here.
Mnemonic - The 7 Classic Vulnerability Types: "My Dad Buys Us Dinner, Often Pizza"
My Dad Buys Us Dinner, Often Pizza = Misconfiguration, Default installations, Buffer overflows, Unpatched servers, Design flaws, Open services, Passwords (default). Every exam question about "types of vulnerabilities" maps back to this list.
Zero-Day Reality Check
It's impossible to remove every technical vulnerability. Some are zero-days (latent until publicly disclosed - "zero days" since disclosure), some persist because patching legacy/vendor-managed devices is hard, and some are just too costly to fix. Every environment always has multiple latent vulnerabilities at any given time.
Looking, Not Breaking
A vulnerability assessment is the process of identifying and analyzing security weaknesses that might exist in an enterprise - discovery, testing, analysis, and reporting. It can use automated tools or manual techniques, and covers technical, physical, and governance-based weaknesses.
Non-exploitative by nature. The goal is reconnaissance and discovery - finding weaknesses does not require actually exploiting them to prove they exist and apply a fix.
Exploitative by nature - the tester actively tries to break in using the discovered weaknesses to prove real-world impact.
Key Exam Distinction
Vulnerability assessment = "here's what's wrong." Penetration test = "here's what happens when someone abuses what's wrong." Don't mix these up.
Four Ways to Go Looking
NIST Special Publication 800-115, "Technical Guide to Information Security Testing and Assessment," defines four vulnerability assessment activities.
Network-Based Scans
Determine possible network attacks against an org's systems - missing patches, unnecessary services, weak authentication/encryption. Tools like Nessus find open ports, identify running services, and flag associated vulnerabilities.
Host-Based Scans (System-Configuration Reviews)
Run from or with authenticated access to the target computer itself. Catch local exploits that network scans miss, and give deep visibility into configuration and patch details. More comprehensive, but higher overhead and harder to set up.
Wireless Scans
Focus on attack points in Wi-Fi infrastructure - validating strong encryption is enabled, default settings are changed, and hunting for rogue access points that impersonate legitimate networks (e.g. a fake "coffee shop Wi-Fi") to trick victims.
Application Scans
Typically target websites to enumerate software vulnerabilities/misconfigurations (included within penetration testing). Risky - scanning software might alter databases or delete content, so use nonproduction environments or scan production very carefully.
Mnemonic - The Four Scan Types: "Never Have Wild Apps"
Never Have Wild Apps = Network-based, Host-based, Wireless, Application scans. In that exact order from NIST SP 800-115.
Host-Based Scan Scope
| Component | What It Checks |
|---|---|
| Operating System | Patch level, version, kernel parameters, system configuration files |
| Installed Software | Versions of applications (browsers, Java, Adobe), missing updates |
| User Accounts | Password policies, privileged accounts, unused accounts, weak passwords |
| File System | File permissions, sensitive files, log files, integrity of system files |
| Running Processes | Malicious software, unnecessary services, memory usage |
| Network Configuration | Local firewall settings, open sockets, routing tables |
| Registry (Windows) | Security-related keys and values |
Host-Based vs Network-Based Scans
| Feature | Host-Based Scan | Network-Based Scan |
|---|---|---|
| Perspective | Internal (on the host itself) | External (from the network) |
| Access Required | High (Admin/root credentials) | None or limited (network access) |
| Visibility | Deep (files, configs, users, processes) | Shallow (ports, services, OS guess) |
| Accuracy | Very high (exact patches/settings) | Lower (often infers information) |
| Impact | Can consume system resources (CPU/RAM) | Minimal impact on target host |
| Best For | Compliance, precise hardening | Discovery, perimeter testing |
Deciding What, and How Often, to Scan
Once an organization commits to vulnerability scanning and checks which regulatory requirements apply, it must identify the systems the scans will cover. Some orgs scan everything; others decide selectively based on questions like:
- What is the data classification of the information stored/processed/transmitted?
- Is the system exposed to the Internet or other public/semipublic networks?
- What services does the system offer?
- Is the system production, test, or development?
Identifying Vulnerability Management Requirements
Organizations also run automated discovery scans to find every connected system - known or previously unknown - and build a complete asset inventory. You can't scan or patch what you don't know exists.
Determining Scan Frequency
Cybersecurity teams lean on automation to schedule scans regularly, taking the manual burden off administrators.
The Automated Probe
A vulnerability scanner scans computers, networks, or applications for potential weaknesses attackers could exploit. It works by sending probing data to the target and analyzing the fingerprint of the response to determine:
Task automation - reconnaissance, port scanning, service/version detection all happen automatically, faster and more consistent than doing it by hand.
Scanners are loud (easily detected due to heavy traffic), and produce both false positives (reporting vulns that don't exist) and false negatives (missing vulns that do exist).
Practical Advice from the Slides
Automated scanning (e.g. with OpenVAS or Nessus) is aggressive - the sheer traffic volume can crash target hosts/services (a self-inflicted DoS). Only scan hosts you have permission to scan, use multiple tools to rule out false positives, and don't become fully dependent on automated scanners - master manual techniques too.
Once You Know It's Vulnerable...
Many services contain known vulnerabilities that can be exploited. The next step is finding out which services are vulnerable and how to actually exploit them. Two go-to sources:
exploit-db
Run by Offensive Security, alongside the Open Source Vulnerability Database (OSVDB) - a searchable public repository of known exploits.
searchsploit
An offline exploit database included with Kali Linux - lets you search exploit-db's dataset without needing internet access.
Scoring and Naming the Threat
Common Vulnerability Scoring System (CVSS)
CVSS rates the severity of a vulnerability using three metric groups, each scored 1-10 (10 = most severe):
The score is generated from a vector string - a compact block of text encoding the numeric score for each metric group. A CVSS calculator uses this to rank vulnerabilities and give an overall severity/risk rating.
Common Vulnerabilities and Exposures (CVE)
CVE is the standardized naming/reference system for publicly known vulnerabilities, catalogued at nvd.nist.gov/vuln (the National Vulnerability Database). Each CVE ID gives everyone - vendors, researchers, scanners - a shared name for the same flaw.
Mnemonic - CVSS vs CVE: "Score vs Name"
CVSS = "How bad is it?" (a 1-10 score across Base/Temporal/Environmental metrics). CVE = "What is it called?" (the public ID/catalog entry). Score vs. Sticker.
When Scanning Becomes the Law
Many organizations are legally bound by regulations governing how they store, process, and transmit information - especially sensitive personal or government data. The classic example on the exam is PCI DSS.
Payment Card Industry Data Security Standard (PCI DSS)
PCI DSS prescribes specific security controls for merchants who handle credit card transactions and the service providers who assist them. It has arguably the most specific vulnerability-scanning requirements of any standard:
- Organizations must run both internal and external vulnerability scans
- Scans must run at least quarterly, and after any significant network change (new components, topology changes, firewall rule changes, product upgrades)
- Internal scans must be conducted by qualified personnel
- Organizations must remediate high-risk vulnerabilities and re-scan until they get a "clean" report
- External scans must be run by an Approved Scanning Vendor (ASV) authorized by the PCI Security Standards Council
Common Practice
Many organizations run their own internal scans first to make sure they'll pass, before paying for an official ASV scan - avoiding a costly failed assessment.
Exam Tips & Tricks
Assessment ≠ Exploitation
Vulnerability assessment discovers weaknesses without exploiting them - unlike a pentest, which does.
4 NIST Scan Types
Network-based, Host-based, Wireless, Application - remember "Never Have Wild Apps."
Misconfiguration Is #1
Misconfiguration, caused by human error, is called out as the most common vulnerability type.
Zero-Day Definition
"Zero days" refers to zero days since the vulnerability's public disclosure - not zero days to exploit it.
Host vs Network Scan
Host-based scans need credentials and go deep (files/configs); network-based scans are external, shallower, but less invasive.
CVSS Range
Every CVSS metric is scored 1-10; 10 is the most severe. Three metric groups: Base, Temporal, Environmental.
Scanners Are Loud
Automated vulnerability scanners generate heavy traffic - easily detected, and capable of both false positives and false negatives.
PCI DSS Frequency
Remember: quarterly scans, PLUS after any significant network change. External scans require an ASV.
Quick Reference - Everything at a Glance
| Topic | Key Point |
|---|---|
| Vulnerability (NIST) | A weakness in a system, procedures, controls, or implementation that a threat source could exploit |
| Vulnerability Research | Ongoing process: discover design faults, track new exploits, monitor underground sites, watch security alerts |
| Misconfiguration | Most common vulnerability; caused by human error (disabled security settings, unneeded services) |
| Default Installations | Shipped for usability, not security; unchanged defaults let attackers guess settings |
| Buffer Overflow | Insufficient bounds checking lets data overflow into adjacent memory, hijacking control |
| Unpatched Servers | Serve as entry points into the network; regular patching mitigates |
| Design Flaws | Logical flaws (bad encryption/validation) that bypass detection mechanisms entirely |
| OS / Application Flaws | OS flaws enable malware; app flaws enable data tampering/unauthorized access |
| Open Services | Unneeded open ports/services risk data loss, DoS, and lateral attacks |
| Default Passwords | Unchanged manufacturer passwords enable brute-force/dictionary attacks |
| Zero-Day | Vulnerability latent until public disclosure; "zero days" since disclosure |
| Vulnerability Assessment | Non-exploitative discovery, testing, analysis, and reporting of weaknesses |
| vs Penetration Test | Pentest actively exploits found weaknesses; assessment does not |
| NIST SP 800-115 | Defines 4 assessment types: Network, Host, Wireless, Application scans |
| Network-Based Scan | External; finds missing patches, weak auth/encryption; e.g. Nessus |
| Host-Based Scan | Internal/authenticated; deep visibility (configs, patches); higher overhead |
| Wireless Scan | Validates encryption/config; hunts rogue access points |
| Application Scan | Targets websites; part of pentesting; risky on production data |
| Discovery Scans | Automated scans to build a full asset inventory of connected systems |
| Vulnerability Scanner | Probes targets, analyzes response "fingerprint" for ports/services/OS/vulns |
| Scanner Pros | Automates recon/port scan/service detection - fast and consistent |
| Scanner Cons | Loud/detectable; produces false positives and false negatives |
| exploit-db | Offensive Security's online exploit database (with OSVDB) |
| searchsploit | Offline exploit database bundled with Kali Linux |
| CVSS | Scores severity 1-10 via Base, Temporal, and Environmental metrics |
| CVE | Standard public naming/catalog for known vulnerabilities (nvd.nist.gov/vuln) |
| PCI DSS | Requires internal + external scans, quarterly + after major changes, ASV for external |
| ASV | Approved Scanning Vendor authorized by PCI SSC to run external PCI scans |