Dealing with End of Life Systems
Legacy Operating Systems
While this module primarily focuses on modern operating systems (Windows 10/Windows Server 2016), as we have seen, certain issues (i.e., vulnerable software, misconfigurations, careless users, etc.) cannot be solved by merely upgrading to the latest and greatest Windows desktop and server versions. That being said, specific security improvements have been made over the years that no longer affect modern, supported versions of the Windows operating system. During our assessments, we will undoubtedly encounter legacy operating systems (especially against large organizations such as universities, hospitals/medical organizations, insurance companies, utilities, state/local government). It is essential to understand the differences and certain additional flaws that we need to check to ensure our assessments are as thorough as possible.
End of Life Systems (EOL)
Over time, Microsoft decides to no longer offer ongoing support for specific operating system versions. When they stop supporting a version of Windows, they stop releasing security updates for the version in question. Windows systems first go into an "extended support" period before being classified as end-of-life or no longer officially supported.
Microsoft continues to create security updates for these systems offered to large organizations through custom long-term support contracts. Below is a list of popular Windows versions and their end of life dates:
Windows Desktop - EOL Dates by Version
Windows XP
April 8, 2014
Windows Vista
April 11, 2017
Windows 7
January 14, 2020
Windows 8
January 12, 2016
Windows 8.1
January 10, 2023
Windows 10 release 1507
May 9, 2017
Windows 10 release 1703
October 9, 2018
Windows 10 release 1809
November 10, 2020
Windows 10 release 1903
December 8, 2020
Windows 10 release 1909
May 11, 2021
Windows 10 release 2004
December 14, 2021
Windows 10 release 20H2
May 10, 2022
Windows Server - EOL Dates by Version
Windows Server 2003
April 8, 2014
Windows Server 2003 R2
July 14, 2015
Windows Server 2008
January 14, 2020
Windows Server 2008 R2
January 14, 2020
Windows Server 2012
October 10, 2023
Windows Server 2012 R2
October 10, 2023
Windows Server 2016
January 12, 2027
Windows Server 2019
January 9, 2029
This page has a more detailed listing of the end-of-life dates for Microsoft Windows and other products such as Exchange, SQL Server, and Microsoft Office, all of which we may run into during our assessments.
Impact
When operating systems are set to end of life and are no longer officially supported, there are many issues that may present themselves:
Lack of support from software companies
Certain applications (such as web browsers and other essential applications) may cease to work once a version of Windows is no longer officially supported.
Hardware issues
Newer hardware components will likely stop working on legacy systems.
Security flaws
In some instances, it is difficult or impossible for an organization to upgrade or retire an end-of-life system due to cost and personnel constraints. The system may be running mission-critical software no longer supported by the original vendor. This is common in medical settings and local government, where the vendor for a critical application goes out of business or no longer provides support for an application, so the organization is stuck running it on a version of Windows XP or even Server 2000/2003. If we discover this during an assessment, it is best to discuss with the client to understand the business reasons why they cannot upgrade or retire the system(s) and suggest solutions such as strict network segmentation to isolate these systems until they can be dealt with appropriately.
As penetration testers, we will often come across legacy operating systems. Though I do not see many hosts running server 2000 or Windows XP workstations vulnerable to MS08-067, they exist, and I come across them on occasion. It is more common to see a few Server 2003 hosts and 2008 hosts. When we come across these systems, they are often vulnerable to one or multiple remote code execution flaws or local privilege escalation vectors. They can be a great foothold into the environment. However, when attacking them, we should always check with the client to ensure they are not fragile hosts running mission-critical applications that could cause a massive outage. There are several security protections in newer Windows operating system versions that do not exist in legacy versions, making our privilege escalation tasks much more straightforward.
There are some notable differences among older and newer versions of Windows operating system versions. While this module aims to teach local privilege escalation techniques that can be used against modern Windows OS versions, we would be remiss in not going over some of the key differences between the most common versions. The core of the module focuses on various versions of Windows 10, Server 2016, and 2019, but let's take a trip down memory lane and analyze both a Windows 7 and a Server 2008 system from the perspective of a penetration tester with the goal of picking out key differences that are crucial during assessments of large environments.
Windows Server
Windows Server 2008/2008 R2 were made end-of-life on January 14, 2020. Over the years, Microsoft has added enhanced security features to subsequent versions of Windows Server. It is not very common to encounter Server 2008 during an external penetration test, but I often encounter it during internal assessments.
Server 2008 vs. Newer Versions
The table below shows some notable differences between Server 2008 and the latest Windows Server versions.
X
Partial
Partial
X
X
X
X
X
X
X
X
Partial
X
X
X
Partial
Partial
X
X
X
X
Server 2008 Case Study
Often during my assessments, I come across legacy operating system versions, both Windows and Linux. Sometimes these are merely forgotten systems that the client can quickly act on and decommission, while other times, these can be critical systems that can not be easily removed or replaced. Penetration testers need to understand the client's core business and hold discussions during the assessment, especially when dealing with scanning/enumeration and attacking legacy systems, and during the reporting phase.
For example, medical settings may be running mission-critical software on Windows XP/7 or Windows Server 2003/2008 systems. Without understanding the reasoning "why," it is not good enough to merely tell them to remove the systems from the environment.
In this case, we would have to look at other mitigating controls the client has in place, such as network segmentation, custom extended support from Microsoft, etc.
If we are assessing a client with the latest and greatest protections and find one Server 2008 host that was missed, then it may be as simple as recommending to upgrade or decommission. This could also be the case in environments subject to stringent audit/regulatory requirements where a legacy system could get them a "failing" or low score on their audit and even hold up or force them to lose government funding.
For an older OS like Windows Server 2008, we can use an enumeration script like Sherlock to look for missing patches. We can also use something like Windows-Exploit-Suggester, which takes the results of the systeminfo command as an input, and compares the patch level of the host against the Microsoft vulnerability database to detect potential missing patches on the target
Querying Current Patch Level
A quick Google search of the last installed hotfix shows us that this system is very far out of date.
Running Sherlock
Obtaining a Meterpreter Shell
From the output, we can see several missing patches. From here, let's get a Metasploit shell back on the system and attempt to escalate privileges using one of the identified CVEs. First, we need to obtain a Meterpreter reverse shell. We can do this several ways, but one easy way is using the smb_delivery module.
Rundll Command on Target Host
Open a cmd console on the target host and paste in the rundll32.exe command.
Receiving Reverse Shell
Searching for Local Privilege Escalation Exploit
From here, let's search for the MS10_092 Windows Task Scheduler '.XML' Privilege Escalation module.
Migrating to a 64-bit Process
Before using the module in question, we need to hop into our Meterpreter shell and migrate to a 64-bit process, or the exploit will not work. We could have also chosen an x64 Meterpeter payload during the smb_delivery step.
Setting Privilege Escalation Module Options
Once this is set, we can now set up the privilege escalation module by specifying our current Meterpreter session, setting our tun0 IP for the LHOST, and a call-back port of our choosing.
Receiving Elevated Reverse Shell
If all goes to plan, once we type exploit, we will receive a new Meterpreter shell as the NT AUTHORITY\SYSTEM account and can move on to perform any necessary post-exploitation.
Windows Desktop Versions
Windows 7 was made end-of-life on January 14, 2020, but is still in use in many environments.
Windows 7 vs. Newer Versions
Over the years, Microsoft has added enhanced security features to subsequent versions of Windows Desktop. The table below shows some notable differences between Windows 7 and Windows 10.
X
Partial
X
X
X
X
Partial
X
Partial
X
X
Windows 7 Case Study
To this date, estimates state that there may be over 100 million users still on Windows 7. According to NetMarketShare, as of November 2020, Windows 7 was the second most used desktop operating system after Windows 10. Windows 7 is standard in large companies across the education, retail, transportation, healthcare, financial, government, and manufacturing sectors.
As discussed in the last section, as penetration testers, we must understand our clients' core business, risk appetite, and limitations that may prevent them from entirely moving off all versions of EOL systems such as Windows 7.
A large retail client may have Windows 7 embedded devices in 100s of their stores running their point of sale (POS) systems. It may not be financially feasible for them to upgrade them all at once, so we may need to work with them to develop solutions to mitigate the risk. A large law firm with one old Windows 7 system may be able to upgrade immediately or even remove it from the network. Context is important.
Let's look at a Windows 7 host that we may uncover in one of the sectors mentioned above. For our Windows 7 target, we can use Sherlock again like in the Server 2008 example, but let's take a look at Windows-Exploit-Suggester
Install Python Dependencies (local VM only)
This tool works on the Pwnbox, but to get it working on a local version of Parrot, we need to do the following to install the necessary dependencies.
Gathering Systeminfo Command Output
Once this is done, we need to capture the systeminfo command's output and save it to a text file on our attack VM.
Updating the Local Microsoft Vulnerability Database
Running Windows Exploit Suggester
Suppose we have obtained a Meterpreter shell on our target using the Metasploit framework. In that case, we can also use this local exploit suggester module which will help us quickly find any potential privilege escalation vectors and run them within Metasploit should any module exist.
Looking through the results, we can see a rather extensive list, some Metasploit modules, and some standalone PoC exploits. We must filter through the noise, remove any Denial of Service exploits, and exploits that do not make sense for our target OS. One that stands out immediately as interesting is MS16-032. A detailed explanation of this bug can be found in this Project Zero blog post which is a bug in the Secondary Logon Service.
Exploiting MS16-032 with PowerShell PoC
Let's use a PowerShell PoC to attempt to exploit this and elevate our privileges.
Spawning a SYSTEM Console
Last updated