Outdated and Unsupported Software
Learn how outdated and unsupported software exposes infrastructure to critical exploits. Includes pentesting techniques, tools, and remediation steps.
What is Outdated and Unsupported Software?
Outdated and unsupported software refers to operating systems, applications, firmware, and libraries that are no longer receiving security updates from their vendors. This includes end-of-life (EOL) operating systems such as Windows Server 2012 R2, deprecated application frameworks, and legacy firmware on network appliances. When software reaches end-of-life status, vendors cease publishing patches for newly discovered vulnerabilities, leaving systems permanently exposed to exploitation.
The prevalence of outdated software in enterprise environments remains alarmingly high. Many organisations maintain legacy systems due to application compatibility requirements, budget constraints, or simple operational inertia. These systems often run critical business processes, making them high-value targets for attackers. Common examples include unpatched Apache Tomcat servers, outdated OpenSSL libraries, legacy IIS installations, and EOL database engines like MySQL 5.5 or PostgreSQL 9.
The risk compounds over time as more vulnerabilities are publicly disclosed without corresponding patches. Exploit code for vulnerabilities in outdated software is frequently available in public repositories and integrated into automated exploitation frameworks. A single outdated system can serve as the initial foothold that an attacker needs to compromise an entire network.
How It Works
Attackers begin by conducting reconnaissance to identify software versions running on target systems. Tools like Nmap with version detection (nmap -sV), banner grabbing techniques, and specialised scanners such as Nessus or Qualys can quickly enumerate software versions across large networks. HTTP response headers, SSH banners, SMTP EHLO responses, and SNMP MIB queries all leak version information that attackers correlate against vulnerability databases like NVD, Exploit-DB, and CVE Details.
Once an outdated component is identified, attackers cross-reference the version against known CVEs. For widely deployed software, exploit modules are often already available in Metasploit, published as proof-of-concept code on GitHub, or packaged in commercial exploit kits. For example, an unpatched Apache Struts server may be vulnerable to CVE-2017-5638 (remote code execution), while an outdated Microsoft Exchange server could be exploited via ProxyShell (CVE-2021-34473). The attacker selects the appropriate exploit, configures the payload, and executes it against the target.
In many cases, exploitation of outdated software requires minimal sophistication. Automated scanners and worm-like malware specifically target known vulnerabilities in common software. The EternalBlue exploit (MS17-010), which targets outdated Windows SMB implementations, was famously used in the WannaCry and NotPetya attacks, affecting hundreds of thousands of systems worldwide. Attackers may also chain multiple vulnerabilities in outdated components to escalate privileges, move laterally, or establish persistent access.
Impact
- Remote code execution allowing full system compromise without authentication
- Exploitation of publicly known CVEs with readily available exploit code
- Inability to remediate vulnerabilities due to lack of vendor support and patches
- Regulatory non-compliance with frameworks such as PCI DSS, HIPAA, and ISO 27001 that mandate timely patching
- Lateral movement from a compromised legacy system into modern, segmented network zones
- Data exfiltration from systems that may contain years of accumulated sensitive data
- Ransomware deployment targeting unpatched systems as the initial entry vector
- Increased attack surface that compounds with every new vulnerability disclosure
Remediation Steps
- Conduct a comprehensive software asset inventory across all infrastructure using tools like Lansweeper, SCCM, or open-source alternatives to identify every software version in the environment
- Establish a software lifecycle management policy that tracks vendor support timelines and triggers upgrade projects at least 12 months before end-of-life dates
- Prioritise upgrading or replacing all end-of-life operating systems and applications with currently supported versions that receive regular security patches
- Where immediate replacement is not feasible, implement compensating controls including network isolation, enhanced monitoring, application whitelisting, and virtual patching via WAF or IPS rules
- Deploy automated vulnerability scanning on a recurring schedule (minimum monthly) to detect newly outdated components as vendor support windows close
- Implement a formal patch management programme with defined SLAs: critical patches within 72 hours, high within 7 days, medium within 30 days, and low within 90 days
- Establish extended support agreements with vendors where available (e.g., Microsoft Extended Security Updates) as a temporary measure while migration plans are executed
- Document all exceptions and risk acceptances for systems that cannot be upgraded, ensuring they are reviewed quarterly by the risk management committee
Testing Guidance
Pentesters should begin by performing comprehensive version enumeration across all in-scope systems. Use nmap -sV -sC -p- --open -oA full_scan target_range to identify services and their versions. Supplement this with targeted protocol-specific probes: HTTP headers (curl -I), SSH banners (ssh -v), and SNMP queries (snmpwalk). Commercial vulnerability scanners like Nessus, Qualys, or Rapid7 InsightVM provide automated version-to-CVE correlation and should be used to generate a comprehensive vulnerability baseline.
For each outdated component identified, research the specific CVEs affecting that version using resources like NVD (nvd.nist.gov), Exploit-DB, and vendor security advisories. Attempt to validate exploitability using Metasploit modules or standalone proof-of-concept code. For example, use msfconsole to search for and configure exploits: search type:exploit name:apache_struts, then set RHOSTS target and exploit. Document the version, associated CVEs, CVSS scores, and whether exploitation was successful or theoretically possible.
Pay particular attention to EOL operating systems (Windows Server 2008/2012, CentOS 6, Ubuntu 16.04), web servers (Apache 2.2, IIS 7), database engines, and network appliance firmware. Use searchsploit from the Exploit-DB archive to find local exploits: searchsploit openssh 7.2. For Windows targets, tools like wmic os get caption,version or CrackMapExec (crackmapexec smb target --shares) can enumerate OS versions remotely. Report each finding with the specific version, years since EOL (if applicable), and the count of unpatched CVEs with critical or high severity.
References
Related Vulnerabilities
Related Checklists
Frequently Asked Questions
What is Outdated and Unsupported Software?
Outdated and unsupported software refers to operating systems, applications, firmware, and libraries that are no longer receiving security updates from their vendors. This includes end-of-life (EOL) operating systems such as Windows Server 2012 R2, deprecated application frameworks, and legacy firmware on network appliances.
How does Outdated and Unsupported Software work?
Attackers begin by conducting reconnaissance to identify software versions running on target systems. Tools like Nmap with version detection (nmap -sV), banner grabbing techniques, and specialised scanners such as Nessus or Qualys can quickly enumerate software versions across large networks.
How do you test for Outdated and Unsupported Software?
Pentesters should begin by performing comprehensive version enumeration across all in-scope systems. Use nmap -sV -sC -p- --open -oA full_scan target_range to identify services and their versions. Supplement this with targeted protocol-specific probes: HTTP headers (curl -I), SSH banners (ssh -v), and SNMP queries (snmpwalk).
How do you remediate Outdated and Unsupported Software?
Conduct a comprehensive software asset inventory across all infrastructure using tools like Lansweeper, SCCM, or open-source alternatives to identify every software version in the environment Establish a software lifecycle management policy that tracks vendor support timelines and triggers upgrade projects at least 12 months before end-of-life dates Prioritise upgrading or replacing all end-of-life operating systems and applications with currently supported...