If It’s Outdated, It’s a Target: Running Credentialed Vulnerability Scans with Qualys

Deliberately installing vulnerable software, scanning it with an enterprise-grade vulnerability management tool, remediating the findings, and learning what the vulnerability lifecycle actually looks like from the inside.

DISCLAIMER: This lab was built entirely in an isolated environment using Oracle VirtualBox on my personal home network. The Windows 10 VM scanned in this lab was provisioned specifically for this exercise and decommissioned afterward. Outdated software was installed deliberately to simulate real-world vulnerability conditions. This write-up is published for educational purposes, intended for security students, blue teamers, and SOC analysts who want to understand vulnerability management from the ground up before they encounter it in a production environment.

Overview

Every organization has vulnerabilities. The question isn't whether they exist , it's whether you know about them before an attacker does.

Vulnerability management is the structured process of finding, prioritizing, and remediating weaknesses in an environment before they can be exploited. It sits at the foundation of any mature security program, and it's one of the most direct ways a security team can measurably reduce risk over time.

This lab walks through two of the core steps in that lifecycle, scanning and remediation. Using Qualys Community Edition, one of the most widely deployed vulnerability management platforms in the enterprise space. A Windows 10 VM was deliberately loaded with outdated, vulnerable versions of Firefox and VLC Media Player to simulate the kind of software debt that accumulates in real environments, then scanned with an authenticated Qualys scan to surface findings. Two remediations were performed and a second scan was run to verify the results.

The outcome: 61 vulnerabilities on the first scan. 22 on the second. A 64% reduction from two remediations. And a clear picture of what the vulnerability management lifecycle looks like in practice.

Background: What Is Vulnerability Management?

Vulnerability management is the ongoing process of identifying, evaluating, treating, and reporting on security vulnerabilities in systems and software. It's not a one-time audit, it's a continuous cycle, because new vulnerabilities are discovered constantly and environments change constantly.

The core lifecycle typically looks like this: discover assets, scan for vulnerabilities, prioritize findings by severity and exploitability, remediate or accept the risk, and verify that remediations actually worked. Then repeat.

In a SOC context, vulnerability management data is directly relevant to triage work. When an alert fires on a host, knowing that host has unpatched critical vulnerabilities changes how you prioritize the investigation. A confirmed intrusion on a fully patched host looks different from a confirmed intrusion on a host with 20 outstanding criticals and a known exploit in the wild. The vulnerability posture of the affected asset is context that shapes the severity of the finding.

Many organizations operate in SMB and mid-market space environments where formal vulnerability management programs are often immature or nonexistent, where software goes unpatched for months or years, and where outdated applications are common. Understanding what a vulnerability scan surfaces in that kind of environment, and what remediation actually accomplishes, is directly applicable to the threat landscape those organizations face.

Background: What Is Qualys?

Qualys is one of the leading enterprise vulnerability management platforms in the industry. It operates as a cloud-based service with lightweight scanner appliances deployed on-premises or in cloud environments to scan assets within a network. Qualys maintains a continuously updated vulnerability knowledge base, maps findings to CVEs and severity scores, and produces detailed scan reports that break down findings by severity, category, and asset.

Qualys Community Edition is a free tier that provides access to the core scanning functionality, enough to run credentialed scans, generate reports, and work through the vulnerability management lifecycle in a lab environment. It's the same platform used by enterprise security teams, just without the scale and automation features of a full license.

Background: Credentialed vs. Non-Credentialed Scans

Not all vulnerability scans are equal. The distinction between credentialed and non-credentialed scanning is one of the most important concepts in vulnerability management.

A non-credentialed scan, sometimes called an "unauthenticated scan", probes the target from the outside, the same way an attacker without credentials would. It can identify exposed services, open ports, and some externally visible vulnerabilities, but it can't see inside the operating system. Missing patches, vulnerable installed software, insecure configurations buried in the registry, none of that is visible to an unauthenticated scan.

A credentialed scan, also called an authenticated scan, runs with valid credentials for the target system. It can log in, enumerate installed software, check patch levels, read configuration files, and surface vulnerabilities that are completely invisible to an unauthenticated scanner. Credentialed scans consistently find significantly more vulnerabilities than unauthenticated scans against the same target, because they're seeing the system the way an attacker with valid credentials would.

Both scans in this lab were credentialed. That's why the first scan surfaced 61 findings on a single Windows 10 VM, the scanner could see everything.

Lab Environment

Vulnerability Scanner: Qualys Community Edition Scanner Appliance: TylersVA (Scanner 14.3.10–1, Vulnerability Signatures 2.6.192–4) Target: Windows 10 VM (local network, static IP) Hypervisor: Oracle VirtualBox Deliberately Installed Vulnerabilities: Outdated Firefox, Outdated VLC Media Player

Section 1: Installing Virtual Machine Software

Why this matters: Oracle VirtualBox is the hypervisor that hosts the target VM, the environment the scanner will be probing. In enterprise vulnerability management deployments, scanners operate against production systems on real networks. In a lab, VirtualBox provides the isolated equivalent, a self-contained network where the scanner and target can communicate without exposing anything to the internet.

Understanding the infrastructure behind a vulnerability scan matters for SOC work. Knowing whether a scan was run against a production host, a segmented network segment, or an isolated lab environment changes how you interpret the findings and whether they represent real exposure.

[Screenshot — VirtualBox installation]

Section 2: Downloading a Windows 10 ISO

Why this matters: The target VM needs an operating system, and a fresh Windows 10 installation is the baseline, a relatively clean environment before any deliberate vulnerabilities are introduced. Starting from a clean OS image also means that any vulnerabilities surfaced by the scanner beyond the intentionally installed software are inherent to the Windows 10 baseline itself, missing patches, default configurations, built-in services with known weaknesses.

That baseline finding is one of the more instructive parts of this lab. Even a freshly installed operating system isn't a clean bill of health.

[Screenshot — Windows 10 ISO download]

Section 3: Downloading Outdated VLC Media Player

Why this matters: VLC Media Player is ubiquitous. It's installed on personal machines, office workstations, and shared computers in small businesses everywhere. Older versions of VLC have well-documented vulnerabilities, memory corruption issues, remote code execution possibilities, and other findings that show up clearly in a credentialed scan.

Installing a deliberately outdated version simulates something that happens in real environments constantly, not maliciously, but through neglect. Software gets installed, updates get deferred, IT teams don't have visibility into what's running on every endpoint, and outdated versions accumulate over time. In the SMB environments that mentioned earlier, this is not an edge case. It's the baseline.

[Screenshot — Outdated VLC Media Player download]

Section 4: Downloading Outdated Firefox

Why this matters: Firefox is one of the most commonly installed browsers in business environments. Outdated browser versions are a persistent vulnerability class, they're frequently targeted by exploit kits, drive-by downloads, and phishing campaigns that exploit known browser vulnerabilities. An unpatched browser on an endpoint is a direct path to initial access for an attacker who knows what version is running.

Deliberately installing an outdated version of Firefox alongside outdated VLC creates a realistic simulation of an endpoint with software debt, the kind of asset that vulnerability management programs exist specifically to find and remediate.

[Screenshot — Outdated Firefox download]

Section 5: Setting Up Qualys Community Edition

Why this matters: Qualys Community Edition provides access to the same scanning engine used in enterprise deployments. Setting it up, creating an account, configuring the scanner appliance, and understanding the platform's structure, is the foundation everything else builds on.

In enterprise vulnerability management programs, the scanner configuration is a significant operational concern. Which assets are in scope? Which scan profiles are being used? How frequently are scans running? Are credentialed scans configured correctly for all asset types? Getting hands-on with the platform at the setup level builds familiarity with those questions before encountering them in a production context.

[Screenshot — Qualys Community Edition setup]

Section 6: Importing the OVA File to VirtualBox

Why this matters: The Qualys scanner appliance is distributed as an OVA file, a pre-configured virtual machine image that gets imported into VirtualBox and runs as the scanning engine on the local network. This is the component that actually connects to Qualys's cloud platform and performs scans against local assets.

In enterprise deployments, Qualys scanner appliances are deployed as virtual machines or physical hardware within network segments to ensure they can reach the assets they're scanning. Understanding how the appliance fits into the network architecture, and why it needs to be local rather than cloud-only is useful context for understanding how vulnerability management scales in larger environments.

[Screenshot — Qualys OVA import into VirtualBox]

Section 7: Verifying the Scanner is Ready

Why this matters: Before running any scans, the scanner appliance needs to be confirmed as active and connected to the Qualys cloud platform. A scanner that appears deployed but isn't actually communicating upstream will produce no results silently. Verifying scanner health before relying on it for findings is a basic operational discipline that applies equally in lab and production environments.

In a mature vulnerability management program, scanner health monitoring is part of the operational baseline. Dead scanners create blind spots, and blind spots create false confidence, the appearance of a clean scan result when the scanner simply wasn't functioning.

[Screenshot — Qualys scanner appliance verified and active]

Section 8: Creating the Windows 10 VM

Why this matters: The Windows 10 VM is the target, the system that will be scanned, found vulnerable, remediated, and rescanned. Building it from the ISO downloaded earlier creates a controlled baseline environment. No pre-installed bloatware, no prior configuration drift, just a clean Windows 10 install that will receive the deliberately outdated software in the next steps.

In a real vulnerability management program, the targets aren't clean lab VMs, they're production workstations, servers, and cloud instances with years of configuration drift, installed software, and accumulated patches. The lab VM is the simplified version of that complexity, but the scanning and remediation workflow is identical.

[Screenshot — Windows 10 VM created in VirtualBox]

Section 9: Inserting VirtualBox Guest Additions

Why this matters: VirtualBox Guest Additions improve integration between the host machine and the VM, better display resolution, shared clipboard, and importantly for this lab, the ability to easily transfer files between the host and the VM. That file transfer capability is what makes copying the outdated software installers into the VM straightforward in the next step.

[Screenshot — VirtualBox Guest Additions installation]

Section 10: Copying Outdated Software to the VM

Why this matters: With Guest Additions installed, the outdated Firefox and VLC installers can be copied directly into the VM and installed. This is the step that deliberately introduces the vulnerabilities the scanner will find, intentionally recreating the kind of software debt that exists in real environments through neglect rather than intention.

The deliberate nature of this step is worth sitting with. In a production environment, nobody installs outdated software on purpose. But the result looks identical from the scanner's perspective, a host running vulnerable software is a host running vulnerable software, regardless of how it got there. Vulnerability management exists precisely because organizations don't always know what's running on their endpoints or whether it's up to date.

[Screenshot — Outdated software copied and installed on the VM]

Section 11: Assigning a Static IP from the Configured Range

Why this matters: The scanner needs to know where to find the target VM, which means the VM needs a predictable, stable IP address within the range the scanner is configured to probe. Assigning a static IP rather than relying on DHCP, ensures the scanner can consistently reach the target and that scan results are attributed to the correct asset.

In enterprise vulnerability management, asset management and IP address management are tightly coupled concerns. A scanner that can't reliably identify which asset an IP address corresponds to produces findings that are difficult to act on. You know a vulnerability exists, but you're not sure which machine it's on.

[Screenshot — Static IP assignment on the Windows 10 VM]

Section 12: Turning Off Windows Firewall on the VM

Why this matters: For the credentialed scan to work properly, the scanner needs network access to the target VM. The Windows host firewall can block scan traffic even when credentials are correctly configured, which would result in incomplete or failed scans. Disabling it ensures the scanner has full visibility into the target.

This step mirrors a real-world consideration in vulnerability management deployments: host firewalls on endpoints can interfere with authenticated scanning. Enterprise VM programs typically handle this through Group Policy exceptions or scanner-specific firewall rules rather than disabling the firewall entirely, but in a lab environment, disabling it is the practical equivalent.

[Screenshot — Windows Firewall disabled on the target VM]

Section 13: Viewing the Results of the First Authenticated Scan

Why this matters: This is where the lab delivers its first major finding, and the number is instructive.

61 total vulnerabilities on a single Windows 10 VM. No severity 5 or 4 findings, but 9 severity 3s, 7 severity 2s, and 45 severity 1s and information-gathered findings. The top categories: TCP/IP (20 findings), Information Gathering (20 findings), SMB/NETBIOS (5 findings), Web Server (4 findings), and CGI (4 findings). Average security risk score: 1.5.

The Web Server and CGI findings are particularly notable — those categories aren't typically associated with a standard Windows desktop. Their presence almost certainly reflects components bundled with the outdated browser installation, which exposes something important: installing outdated software doesn't just introduce the vulnerabilities in that software. It can introduce entire additional attack surfaces that wouldn't otherwise exist on the host.

61 vulnerabilities on one endpoint. In an environment with hundreds or thousands of endpoints running similar software debt, the math becomes significant very quickly. This is the scale problem that vulnerability management programs exist to address.

[Screenshot — First scan results showing 61 vulnerabilities with severity breakdown and category distribution]

Section 14: Remediation Step 1 Uninstalling Firefox

Why this matters: The first remediation is the most straightforward possible action, uninstall the vulnerable software. No patching, no configuration change, just removal. In a real environment, uninstalling a browser isn't always an option, users need it, business applications depend on it, replacing it with a patched version is the more practical answer. But for the purposes of this lab, uninstallation demonstrates the most direct path from a confirmed vulnerability to its elimination.

This step also illustrates the difference between remediation and patching. Patching updates the software to a version without the known vulnerability. Remediation is broader, it includes patching, but also uninstallation, configuration changes, compensating controls, and risk acceptance. Vulnerability management programs have to choose the right treatment for each finding based on business context, not just eliminate everything that shows up in a scan report.

[Screenshot — Firefox uninstalled from the Windows 10 VM]

Section 15: Remediation Step 2 Uninstalling VLC Media Player

Why this matters: Same approach as Firefox, uninstall rather than patch, for the same reasons. With both pieces of deliberately outdated software removed, the VM's vulnerability posture should be significantly improved on the next scan. The question is by how much, and what remains.

This is actually the more instructive question in vulnerability management: after you remediate the things you know about, what's left? Remediation is never complete. New vulnerabilities are discovered continuously, and even a well-maintained system will have findings. The goal of vulnerability management isn't a zero-vulnerability state, it's continuous reduction of risk and prioritization of the most dangerous findings.

[Screenshot — VLC Media Player uninstalled from the Windows 10 VM]

Section 16: Viewing the Results of the Second Authenticated Scan After Remediation

Why this matters: The second scan tells the real story, and it's a good one, with an important caveat.

61 vulnerabilities down to 22. A 64% reduction from two remediations. The average security risk score rose from 1.5 to 3.0, which seems counterintuitive until you understand why: removing the large volume of lower-severity findings associated with the outdated software left a smaller set of findings that are proportionally higher severity. The noise went down. The signal got clearer.

The 22 remaining findings, including confirmed vulnerabilities in SMB/NETBIOS and Windows categories are findings that exist on the base Windows 10 installation itself, independent of anything deliberately introduced. Missing OS patches, default configuration weaknesses, SMB-related findings that have been a persistent vulnerability class in Windows environments for years. These are the findings that a real remediation program would need to address next: OS patching, hardening, and configuration management.

The second scan doesn't declare victory. It shows what's left and points to the next phase of work. That's what the vulnerability management lifecycle actually looks like.

[Screenshot — Second scan results showing 22 vulnerabilities with updated severity breakdown and category distribution]

What I'd Look For as a SOC Analyst

Running this lab from the vulnerability management side, building the scan, reading the findings, performing remediations, and verifying the results, made a few things concrete that are directly applicable to SOC work.

Vulnerability data changes how you triage alerts. When an alert fires on a host, the vulnerability posture of that host is immediately relevant context. A confirmed intrusion attempt on a fully patched, hardened workstation looks different from the same attempt on a host with 20 outstanding severity 3 findings and known SMB vulnerabilities. Vulnerability scan data, when it's available and current, should be part of the investigation picture, not siloed in a separate program.

Credentialed scans surface a fundamentally different picture than unauthenticated ones. The 61 findings in this lab's first scan were only visible because the scanner had credentials. An unauthenticated scan of the same host would have produced a fraction of those findings, the externally visible surface only. In environments where credentialed scanning isn't configured, the vulnerability picture is significantly incomplete. That incompleteness is itself a risk.

Remediation verification matters as much as remediation itself. Uninstalling Firefox and VLC without running a second scan would leave the question open…did it work? Did something reinstall? Did a related component persist? The rescan closes that loop. In production environments, remediation tracking and verification are where vulnerability management programs most commonly fall short. A finding that's marked remediated without verification isn't remediated, it's assumed to be.

The residual 22 findings are the real work. The attention-grabbing result is the 61-to-22 reduction. But the 22 that remain, OS-level findings, SMB vulnerabilities, Windows-category confirmed findings — are the findings that require deeper remediation work. Patching, hardening, configuration management. Those aren't two-step fixes. They're the ongoing operational work of a real vulnerability management program.

Software debt is the norm, not the exception. The deliberately outdated software in this lab simulates something that exists in virtually every real environment, applications that haven't been updated, patch cycles that slip, software installed years ago and forgotten. In the SMB environments that security organizations defend, formal patch management programs are often absent entirely. Vulnerability management tools like Qualys exist to find exactly this kind of exposure and give security teams something concrete to act on.

Closing Thoughts: Why the Vulnerability Lifecycle Matters for Blue Teamers

Vulnerability management is sometimes treated as a separate discipline from SOC work, something the vulnerability team handles while analysts focus on alerts and incidents. That separation is a mistake.

Vulnerabilities are the preconditions for most of the alerts a SOC analyst will ever triage. An attacker exploiting a known vulnerability in an unpatched application, moving laterally through an environment via a known SMB weakness, establishing persistence through a misconfigured service, all of those incidents start with a vulnerability that existed before the attack began. Understanding the vulnerability lifecycle, knowing how to read a scan report, and understanding what remediated versus residual risk looks like makes a SOC analyst a more effective investigator.

This lab made that connection concrete. 61 vulnerabilities on one endpoint. 39 of them gone after two remediations. 22 remaining, waiting for the next phase of work. The vulnerability management lifecycle doesn't end, it continues until the asset is decommissioned. Understanding that rhythm, and what it looks like in a real tool, is foundational context for anyone doing security work in environments where that program exists or doesn't.

Tyler Reynolds is a SOC Analyst and cybersecurity practitioner focused on blue team operations, alert triage, and detection. Find more of his work on GitHub and connect on LinkedIn.