How to secure legacy Windows XP systems: building an isolation lab

Still running an old Windows XP machine? Then this story is a must-read.

On a recent project, we stumbled upon something all too familiar: a few aging Windows XP machines, quietly chugging away in a modern enterprise environment.

Fortunately, these machines weren’t serving internet-facing production workloads. Instead, they were the main development and build systems for critical legacy applications—built in Visual Basic 6, classic ASP 3.0, and COM+ components. A tech stack that screams late 90s, yet still deeply embedded in daily business operations.

These XP boxes were responsible for compiling deployable .exe files, DLLs, and classic ASP web apps—artifacts that were then deployed to more modern Windows Server environments. So while they didn’t look like a high-risk asset, they posed a serious threat under the surface.

The issue? These machines sat in the same network zone as production servers. No segmentation. No isolation. That meant a vulnerable XP box, with no patches since 2014 and full of weak protocols, was just a hop away from everything else.

This blog walks you through how we tackled that risk—by building an isolation lab. Not only did it shield the organization from legacy vulnerabilities, it became a powerful enabler for change: from internal awareness to hands-on testing, collaboration, and modernization planning.

Windows XP Vulnerabilities

As we all know, Windows XP is highly vulnerable due to several reasons. To name some important few:

• No updates since 2014
• Does not support a modern antivirus solution with attack surface reduction
• No encrypted remote desktop protocol (RDP) making it vulnerable to cleartext password sniffing
• Only supports the insecure RC4 encryption type in Kerberos authentication
• Only supports the insecure file and printer sharing protocol SMB version 1 exposing it to attacks like EternalBlue and WannaCry
• Allows fairly easy privilege escalation so if a domain admin recently logged on the XP machine, you can easily become king of the castle

So anyone can sense the urgency -or even better emergency- to get these business applications rewritten as soon as possible on a modern development stack with security by design incorporated.

But then the questions come. How much will it cost? How long will it take? Will we have to retrain our users? Do we really need to start from scratch? Can’t we reuse or refurbish some code? Will a new solution support important custom business logic our company is famous for? What about compliancy with external regulations? And so on, and so forth.

So from a time and security perspective, there aren’t really many other options then than to isolate these machines.

Isolation?

Yes, isolation. This means: put the machines in a separate network zone, shield them off with a firewall and only allow what is necessary. You will also need to heavily monitor this zone for any suspicious activity. And you do all of that until a new solution is in place.

And PLEASE, make the higher management aware that this should absolutely be a temporary situation. Convince them to provide proper funding and investments to set up projects to reprogram, replatform, refactor, redo whatever is necessary to get rid of these legacy systems as soon as possible. Isolating the machines will give better protection, but wil not solve the vulnerabilities. The longer you wait to treat them, the harder and more expensive it becomes.

Read-Only Domain Controller (RODC)

Next to isolating the machines with the firewall, another very important component in the architecture, is a Read-Only Domain Controller or RODC.

It is a special type of domain controller that contains a read-only copy of your Active Directory. It allows you to harden the security on all the machines in your trust zone -including your main domain controllers- and at the same time keep your Windows XP machines functional.

An RODC:

• Provides crucial AD functionality like Kerberos authentication and group policy
• Reduces attack surface
• Does not store passwords by default
• Is specifically designed for use in less secure network zones (like branch offices)
• Allows filtering of sensitive AD attributes
• Only introduces minimal overhead because it gets all Active Directory objects synced from the main domain controllers
• Removes the risk of affecting the main domain controllers
  • That way a hacker cannot destroy the main writable DC’s from an isolated legacy machine.

You can find the full documentation on Microsoft’s RODC here. 

As Windows XP only supports the insecure RC4 encryption for Kerberos authentication and the even more vulnerable SMBv1 protocol for group policy processing, the main rationale is to lower the security only on the RODC that the XP’s will use, while hardening our main domain controllers and other machines by removing the insecure RC4 and SMBv1 on them.

Isolation lab

All of the above looks nice in theory, but how does one really tackle this in practice? In a living organization in constant change?

Well, we started off by trying to convince our stakeholders by building an isolation lab.

It very soon turned out to become one of our most important tools for many reasons:

• You can demonstrate the actual security measures
• You can test (even pentest) actions without touching the corporate infrastructure
• You can immediately ’talk tech’ with the system and network engineers. The lab will trigger important discussions and keep them ongoing.
• You can do stuff that you are not allowed to do in a corporate environment: disable firewalls, suspend the antivirus detection, install hacking tools like mimikatz, use Wireshark to sniff the network traffic, etc.

Lab overview

On the project we had a big Azure environment to our disposal, so there was still some room left for our small, cheap, but highly efficient lab.

The diagram below shows the setup:

The names in the example are all fictitious, but they can be mapped one-on-one with the lab we created for the project. The lab is hosted on a dedicated Azure subscription ‘sub-my-subscription’ inside of the resource group ‘rg-my-resourcegroup-sbx-weu-001’. There is no link, peering, VPN, ExpressRoute or whatsoever from the lab to the actual network of the company that hosted the project, to keep it fully isolated.

Network zones and virtual machines

The lab is composed of an Azure Virtual Network (VNET) with fictional IP range 10.2.0.0/24 and the following subnets:

• 10.2.0.0/28: FW: snet-my-isolation-fw-dev-weu-001
  • Subnet containing:
    • vm-my-opnsense-sbx-weu-001
      • Virtual machine running OPNSense (an open source firewall/router)
      • We opted for OPNSense as it is low-cost and ideally suited for a lab setup as compared with commercial products of Palo Alto, Cisco, Fortinet and Check Point.
      • The LAN interface of OPNSense has an IP in this subnet
      • The WAN interface of OPNSense has an IP in the DMZ subnet (see below)
    • vm-my-antix-sbx-weu-001
      • Small virtual machine running AntiX Linux
      • Sits next to the OPNSense firewall to access its web interface via Firefox as OPNSense itself has no graphical user interface
      • In our experience, probably the most lightweight and cheapest machine to host in Azure 😊
• 10.2.0.16/28: RWDC: snet-my-isolation-rwdc-dev-weu-001
  • Subnet containing:
    • vm-my-winsrv2016dc-weu-001
      • The read-write domain controller running Windows Server 2016 Standard with latest updates installed
      • The main domain controller during the project was also running Windows Server 2016, so that is the reason for picking this OS, but you can take a higher OS if you want
      • Host name is MYWINSRV2016DC
      • This machine hosts the fictional domain ‘MYDOMAIN.LOCAL’ with some dummy ‘Hello world’ group policies
• 10.2.0.32/28: RODC: snet-my-isolation-rodc-dev-weu-001
  • Subnet containing:
    • vm-my-winsrv2022dc-weu-001
      • The read-only domain controller running Windows Server 2022 Standard with latest updates installed
      • The RODC that we introduced during the project also ran a Windows Server 2022
      • Host name is MYWINSRV2022DC
      • Synchronizes the fictional domain ‘MYDOMAIN.LOCAL’ from MYWINSRV2016DC
      • IMPORTANT: you will need to provision this machine in Azure from a managed disk as the image in the Azure store is already hardened and will not allow you to lower the security (= lower encryption types to RC4 and install SMBv1)
• 10.2.0.48/28: MB01: snet-my-isolation-mb01-dev-weu-001
  • Subnet containing:
    • vm-my-winxp-weu-001
      • A virtual machine running that latest edition of Windows XP (5.1.2600.5512 Service Pack 3 Build 2600) representing a legacy member machine of the domain MYDOMAIN.LOCAL
      • Uses the read-only domain controller MYWINSRV2022DC for all domain related functionalities (authentication, group policy, LDAP, DNS, etc.)
      • Host name is MYWINXP
      • IMPORTANT: you will need to provision this machine in Azure from a managed disk that you create from Windows XP install media that you either need to extract from the Windows XP machines in your network or grab from the internet. In any case, you will need a valid license key from your existing machines to legally install it.
      • Installing XP on Azure is not supported by Microsoft, so … bear in mind that you’re already on thin ice here.
• 10.2.0.176/26: DMZ: snet-my-isolation-dmz-dev-weu-001
  • Subnet representing the demilitarized zone (DMZ)
    • The WAN network interface card of OPNSense has an IP address in this zone with an associated public IP address allowing internet connectivity
    • By default, internet access is disabled on the firewall, so if you need internet connectivity, you need to enable the respective rules on the firewall
• 10.2.0.192/26: AzureBastionSubnet
  • Subnet needed by Azure Bastion
    • You will need Azure Bastion to RDP or SSH into all virtual machines in the lab.
    • You will also need to setup a number of accounts in your domain. Typically you would create one or two administrators, a couple of normal users and a local admin for your Windows XP. Names like John Doe, Jane Doe, Erika Mustermann, Dom Cobb, etc. work just fine!

Routing

The subnets do not have any Network Security Groups (NSG’s) defined as they are all forced to pass via the OPNSense firewall via a route table ‘rt-my-isolation-sbx-weu-001’.

The table below shows the user defined routes (UDR’s) inside rt-my-isolation-sbx-weu-001 that defines OPNSense’s LAN IP address as the Virtual Network Appliance to use when routing from one subnet to another:

Name	Address prefix	Next hop type	Next hop IP address
route-my-tosnetrwdc-sbx-weu-001	10.2.0.16/28	Virtual appliance	10.2.0.4
route-my-tosnetrodc-sbx-weu-001	10.2.0.32/28	Virtual appliance	10.2.0.4
route-my-tosnetmb01-sbx-weu-001	10.2.0.48/28	Virtual appliance	10.2.0.4
route-my-lantointernet-sbx-weu-001	0.0.0.0/0	Virtual appliance	10.2.0.4

Configuring the firewall

The OPNsense firewall can be exactly configured according to the RODC documentation of Microsoft that you find here. 

One important exception though is the rule regarding dynamic RPC ports in the traffic from the Windows XP machine to the RODC.

The Microsoft documentation only mentions:

Protocol	Source	Destination	Port	Traffic type
TCP	XP	RODC	49152-65535	DNS, DRSUAPI, NetLogonR, SamR LSASS

But you will need to additionally add the ports below as Windows XP uses a much lower and narrow port range:

Protocol	Source	Destination	Port	Traffic type
TCP	XP	RODC	1025-5000	DNS, DRSUAPI, NetLogonR, SamR LSASS

Some lessons learned during lab setup

Lesson #1: I locked myself out!

Bear in mind that to log on the RODC ‘MYWINSRV2022DC’, this machine needs to authenticate against the RWDC ‘MYWINSRV2016DC’, so if connectivity gets cut between those two machines (by changing OPNSense, or as a consequence of playing around with the config, etc.), you will not be able to RDP into this machine via Azure Bastion anymore. There is also no backup local admin account on MYWINSRV2022DC as a domain controller by design does not have a local user database.

In case you lock yourself out, you will first need to remove the user defined routes on the RWDC and RODC that forces all traffic over the OPNSense firewall in order to restore connectivity between MYWINSRV2016DC and MYWINSRV2022DC. After that you can troubleshoot the issue and reimpose the user defined routes afterwards again.

If you changed DNS to 8.8.8.8 temporarily to access the internet and removed the IP address of the RWDC on the RODC, you will also lock yourself out. On the RWDC you can run a PowerShell as Administrator and connect to the RODC:

PS C:\Users\John Doe\Documents> Enter-PSSession -ComputerName MYAWINSRV2022DC

[MYWINSRV2022DC]: PS C:\Users\John Doe\Documents> Set-DnsClientServerAddress -InterfaceIndex (Get-NetAdapter).ifIndex -ServerAddresses (“10.2.0.20”)

Lesson #2: Use legacy tools on legacy machines

It might not come as a surprise, but modern network monitoring tools like Wireshark do not run on Windows XP. There are some old archived versions of Wireshark that can still be run on Windows XP, but it is way easier to use the older Microsoft Network Monitor 3.4 on Windows XP.

Likewise, to better understand the encryption types of Kerberos tickets issued on Windows XP, use the ‘kerbtray’ tool from the ‘Windows Resource Kit Tools’ of the old Windows Server 2003. It runs perfect under XP and allows for easy Kerberos encryption troubleshooting.

Lesson #3: Leave no trace behind

We also did a pentest on our own lab.

Mission: start from the Windows XP machine with a non-privileged account and try to grab the main domain controller.

One outcome that we did not see coming: do not log in with a domain admin on your Windows XP! After logging in, you leave local traces of credentials behind and our pentester was able to use those traces to become domain admin on Windows XP.

From there it was very easy to jump to the RODC and from the RODC to the main domain controller.

To avoid this, one should make separate users in their Active Directory that are only used to access the Windows XP machines. If they need admin rights, you can grant them local admin rights on Windows XP, but keep your Domain Admins shielded.

So not the RODC, not the RC4 encryption, not the SMBv1 proved to be the main vulnerabilities, but a logical flaw in the setup of the identity and access management. Do not make that same mistake!

That’s it!

Well, actually, no. That’s not it, because I could continue for many hours on everything else the lab has taught us, like:

• How group policy works inside and outside the isolation zone;
• The importance of configuring Active Directory Sites & Services;
• The Key Distribution Center of the RODC and the special krbtgt account that goes with it;
• The Windows November 2022 encryption security update forcing higher encryption levels and circumventing this hardening on your RODC;
• And of course, how we actually implemented the full setup in the real production network.

Want to know more about legacy systems, and how to keep them safe? Send us a message.

Keep it secure!

Chris