Windows XP, nowadays, is a dangerous operating system to use. It hasn't been supported in a long, long time, and there are numerous security holes and issues with it that make it significantly easier to target and attack when compared to modern counterparts, such as Windows 11. However, there's an interesting consequence of its age that, almost paradoxically, helps prevent attacks. Because it's so old, it lacks a lot of modern Windows features... and that includes features that malware may look to take advantage of, too. That's why I installed Windows XP, and then tried to install malware on it.

First and foremost, I don't recommend doing this yourself. I created an isolated virtual machine and used a firewall to prevent it from accessing the rest of my home network. Then I downloaded malware and ran it to see what would happen. To my surprise, it was actually very difficult to get modern examples of malware to even run. They looked for system services that weren't there, or tried to execute instructions that didn't exist.

Does that mean Windows XP is a "safe" operating system? I cannot stress how much you shouldn't use Windows XP if you can help it. There is malware out there that will have a field day with your Windows XP setup. With that said, some of the more prevalent malware written with modern evasion techniques that are designed in a way to be more cunning likely won't run on Windows XP. It's pretty interesting, and I used a debugger and Dependency Walker to explore what exactly went wrong.

Some malware only targets 64-bit machines

I didn't expect this to be a problem

Pikabot is a malware downloader and loader, and employs a number of sophisticated techniques in order to evade detection, testing, and debugging. Here's the kicker, though: the malware sample shared by vx-underground is a Win64 executable, so it won't run on most Windows XP installations. Only Windows XP Professional x64 Edition would run it, though that's not what I'm using here. There are other variants of Pikabot that would likely run on our lowly 32-bit Windows XP machine, though.

I came across numerous samples that are Win64 executables, and while I'm sure that most have 32-bit equivalents for the rare occasion where that's required, I wouldn't be surprised if some attackers didn't bother. If your goal is to steal someone's credentials, how likely is it that a 32-bit machine is one that contains valuable information? You could argue that it may be a part of a legacy system in a business, but by and large, I would suspect that it's just not really worth the time or effort.

Think about it: why would a developer even bother building malware that targets both 32-bit and 64-bit installations of Windows, and go to the trouble of supporting Windows XP on top of that? It's a lot of effort for what's likely to be little gain. There is malware that's been built for older Windows platforms, but new and sophisticated samples will have more to gain by targeting and utilizing the more advanced capabilities of modern operating systems rather than trying to adjust their behavior on older systems.

One such malware that appears to do exactly that is CryptBot. It dynamically generates its own code at runtime, and it simply doesn't work on Windows XP.

CryptBot

Sophisticated malware immediately causes problems

CryptBot is a notorious piece of malware that runs as a basic information stealer. It takes screenshots of your desktop, collects credentials to send to a command and control server, and tries to vacuum up every piece of sensitive information that it can get. It's a pretty modern piece of malware, yet executing it on my Windows XP virtual machine doesn't work. It doesn't download anything, doesn't try to steal anything, it just... disappears. Why?

Hopping in a debugger, I was able to quickly work out what the most likely cause is. The first time I executed it, my debugger halted when it reached an access violation. The second time around, it reached an invalid operation and couldn't continue. CryptBot has functionality built in to counter debugging attempts, but the non-deterministic nature and where I landed in memory, a completely undefined location, appears to be as a result of CryptBot's dynamic code generation. This malware is known as polymorphic, as it decrypts and modifies itself at runtime, and if it expects certain Windows functions to be available that aren't actually there, it can lead to unexpected code paths that ultimately result in the application crashing.

There's always the chance that it's still an anti-debugging mechanism, but we've already established that it couldn't run outside of a debugger, either. It's possible that anti-debugging mechanisms could have compounded the issue, but it's clear that it just can't run on XP. From what other researchers have published, running it in a debugger also doesn't land it in a random slice of memory that can't be executed, and should instead end the program. Here it appears to generate scrambled code and just crashes, and it would explain why the result differs every time.

So we've tried PikaBot and CryptBot, but we're going to try out one more: Quasar RAT.

Please just infect my Windows XP VM

I thought it'd be easier

Quasar is a remote access tool, though there are several Remote Access Trojans (RATs) that make use of it, too. In this case, Quasar requires the .NET framework from Microsoft, specifically a minimum of .NET 4.0. This is the last version of the .NET framework that was ever supported by Windows XP, but that doesn't mean the program won't try to call functions only found on modern Windows versions. This was arguably the most interesting error of the lot, though.

In my debugger, at the bottom of the screen, you'll see an 80131506 error code. This is a .NET ExecutionEngineException error code, and there are several potential causes for it. Right before it, my debugger raises an exception with error code E0434352, which is just a generic exception error and doesn't tell us much.

I did, eventually, get it to throw an actual error with more information. The error shown above, clr20r3, says both a lot, and absolutely nothing. It essentially means that there was some kind of exception that wasn't handled. This could mean that there was unexpected data, or there was an unexpected event that the software wasn't programmed to handle. Either way, it provides more evidence towards there being a fundamental Windows XP incompatibility at play, here.

For example, on modern Windows machines, it might be the case that this exception is handled by the system, or the environment behaves as expected. Meanwhile, on our lowly Windows XP machine, something unexpected happens, the .NET runtime doesn't know how to deal with it, and the process terminates. There's nothing here that suggests debug detection or sandbox evasion; it looks just like a plain old incompatibility crash. In other words, the malware is built on a runtime that no longer guarantees XP compatibility, and nobody cared enough to add a fallback.

Don't use Windows XP

It may seem tempting, but don't

I know that Windows XP comes off as a bastion of security here, given that three separate malware samples wouldn't run on it. However, there are countless malware samples out there that will run on it, especially those from that time period. As well, given the lack of software compatibility, it's more likely that you'll come across malware that runs on Windows XP while seeking out software to run on it in the first place. Your pirated software for Windows 11 might not pack malware that runs on XP, but you're not going to be pirating software built for Windows 11 on Windows XP in the first place.

Still, it's an interesting way to demonstrate just how broken software built for newer versions of Windows can be on older versions. A lot of work goes into maintaining compatibility in software, and when that work isn't done... well, this is the result. The software might technically run, but there's no guarantee that it'll work. Just please don't use Windows XP; maybe switch to Linux or something instead.