Windows XP was one of the most successful Microsoft operating systems. Released in 2001, according to Wikipedia, “Upon its release, Windows XP received critical acclaim, with critics noting increased performance and stability (especially in comparison to Windows Me), a more intuitive user interface, improved hardware support, and expanded multimedia capabilities.”
Windows XP mainstream support ended in 2009, while the extended support ended in 2014. Nevertheless, due to the fact that Windows XP was still in use by many organizations (specifically in Point of Service (PoS) devices), additional support was extended until 2019. In that year a critical update was released for an important remote vulnerability.
As of september 2020, Windows XP is still used in many computers. According to StatCounter, it has a market share of 0.8%:
But those computers are just normal users connecting to the Internet. Windows XP-based computers, machines and devices are installed in internal networks from different industries.
They include the white box PCs running important manufacturing, process or production applications on the plant floor, in control rooms and in engineering offices. They also include ruggedized PCs running PLC, DCS and other device configuration/monitoring applications in your processes. Or an electroencephalograph in a hospital. Or an ATM. The medical, industrial, military and financial sectors’ (among others) continued use of Windows XP is partly due to applications being incompatible with later versions of Windows.
Last year the response to a parliamentary question in the UK shared some figures about how many Windows XP devices were still running inside the National Health Service (NHS): as of July 2019, approximately 2.300 computers were using Windows XP from a total of around 1.4 million (0.16%).
Windows XP Security
Everyone understands that running Windows XP nowadays is probably not a good idea; not only because of the lack of official support (and patches), but also because its security features are rather limited.
Playing devil’s advocate we could argue that the majority of current attack and exploit frameworks wouldn’t support Windows XP operating systems; or any new malware binaries wouldn’t also be able to be executed. That’s partly true, because all those fancy attack frameworks (like Empire, or Cobalt Strike) strongly rely on PowerShell or WMI features that weren’t available on Windows XP. Others like Covenant may use newer .NET capabilities not available in old systems.
But the reality is that many of the existing tools used by current threat actors for internal lateral movements do also work in Windows XP. For instance, you can use Remote Desktop or PsExec without any problems.
Here Comes the Deception Director
Now that we agree that there are still a significant number of Windows XP devices running in the world, we can now explain how we can use Windows XP devices in our deception campaigns.
One of the key characteristics of our campaigns is credibility. That’s the main reason why we only use real devices, operating systems and applications, and simulate activity so that it is really difficult to detect they are part of our campaigns.
So now, using MITRE Shield definitions, Windows XP is a Decoy System that can be deployed in any network where we have other Windows XP computers (DPR0033) and can offer a number of opportunities like:
- An opportunity to deploy a tripwire that triggers an alert when an adversary touches a network resource or uses a specific technique (DOS0005)
- There is an opportunity to determine if an adversary already has valid account credentials for your network and if they are trying to use them access your network via remote services (DOS0009)
That deployed computer can be part of a simple or advanced attack tree that can guide our threat actors through it. Let’s see some of the events generated:
As you can see, we are detecting several connection attempts (both successful and unsuccessful), as well as other network connections that tried to reach our Windows XP. Even though we don’t have a full instrumentation as we have in more recent Windows Operating Systems, we can set up our campaign so that specific events in our Windows XP can trigger actions in other parts of the campaign.
The above picture shows a ValidAuth event in Windows XP. In this case we were using a Remote Desktop connection with the Administrator user. As you can see in the picture, we are tagging this event as T1021.001 (Remote Services: Remote Desktop Protocol) and T1078 (Valid Accounts). We are also tagging the event with Shield techniques: DTE0027 (Network Monitoring), DTE0010 (Decoy Account) , DTE0017 (Decoy System), DTE0008 (Burn-In) and DTE0012 (Decoy Credentials). Those Shield techniques are the ones used in our Windows XP computer, but they can also be consequently used in further steps in our attack path.