The Travelex Hack – What you need to know and what you need to do about it

On or around 30 December last year, Travelex became the target of a massive ransomware attack which ultimately brought down their entire IT infrastructure.
So great was the disruption that, at the time of writing this, the company is still unable to process foreign currency orders other than manually, using paper invoices.
The knock-on effect has been significant. UK banks rely largely on Travelex for the supply of foreign currency and have been unable to process customer orders as a result.
And it could get worse. The attackers claim to have exfiltrated a significant amount of customer personal information and have threatened to publish this unless their ransom demands are met.

What malware and attack vector were used?

The malware, known as Sodinokibi or REvil, exploits a vulnerability in the win32k.sys component of Windows which was known back in 2018 and assigned CVE-2018-8453.
Microsoft patched this vulnerability late in 2018 and published a security advisory with a set of patches here.
The vulnerability is classified as a 'use after free' issue. These vulnerabilities occur when memory is allocated and then subsequently deallocated but re-used after deallocation.
If the memory area(s) involved are associated with privileged kernel processes, it is possible for malware to exploit use after free vulnerabilities to gain privileged system access.

How did the attackers infiltrate the malware?

Traditionally, ransomware attacks are launched by phishing attacks, where a victim clicks on a malicious link in an email. However, in this case the attack is believed to have been launched via an unpatched vulnerability in the company's Pulse Secure VPN. This vulnerability allowed remote attackers to gain access without a username and password, and also allowed the attackers to view other plaintext passwords.
The vulnerability is discussed in more detail here, and was assigned CVE-2018-13379. It was patched by the vendors in mid-2019.

How can I check if I am vulnerable?

Focusing on the core vulnerability and not the VPN issues, the Microsoft portal shows a complex set of patches which are OS- dependent. To avoid the complexity of trying to reconcile patch history across multiple operating systems, it's probably simpler to focus on the core component that was patched as part of these updates – win32k.sys, which should be located in the c:\windows\system32 folder.
After analysis of the file lists for each of the Microsoft patches and additionally decompressing one of the .msu files for the Windows 10 1703 patch, which is missing the file list for some reason, the following table shows the win32k.sys versions which are believed to be patched by the updates. If the versions on the target systems are later than these, then the file should be patched.

 
*Note: This release was extracted from the patch manifest as the file list associated with the patch was not published on the Microsoft portal for some reason.
Windows 10 builds 1507 and 1511 are no longer supported. If you are running either of these builds, you should upgrade to a supported build as soon as practical.

Windows 10 adds complexity to the check process

We can see that, prior to Windows 10, Microsoft tracked OS components by the primary release identifier, so that Windows 2012 components would all have release identifiers of 6.2.x.x.
This makes vulnerability checking simple because, once a component has been patched, any newer version can automatically be considered patched.
But Windows 10 changes this. As you can see from the table above, all Windows 10 components are versioned 10.0.x.x. This presents a problem. Each build of the OS is now tracked separately, which means that you can’t just assume that a component whose version number is greater than a patched version isn’t vulnerable.
Trying to verify component versions with a simple script means you now have the complexity of first determining which OS and version you have, and then looking up the appropriate version. This could be a challenge to implement, and then you have to somehow get this script out to your estate and collate the results.

Using Tachyon to verify component versions

Fortunately, there’s a much easier solution. Tachyon’s powerful SCALE language makes it easy to verify operating system versions against registry entries and then locate and verify component versions. Unlike traditional scripting solutions, Tachyon embeds powerful functions that retrieve key OS and file information, allowing you to check them quickly and easily.
Here’s the result, run against an internal test lab with some deliberately unpatched endpoints. I’ve used Tachyon’s export functionality to create an Excel spreadsheet and keep the screenshot nice and simple.

The difference between being vulnerable and being protected

Travelex presumably knew about both the VPN and Windows vulnerabilities. But knowing you’re vulnerable and defending against that vulnerability are two separate challenges. As other large organizations have found to their cost, being tardy with patches, even by a few weeks, can result in massive system compromise. Recall that security vulnerabilities are now often disclosed within a 90-day window and that attackers can often weaponize these within days of their disclosure.
Theoretically, for Windows vulnerabilities you rely on Windows updates and possibly Microsoft SCCM to get patches out quickly and efficiently. The problem, however, is that Microsoft update infrastructure is complex, and failures are not uncommon. If you use Microsoft SCCM to implement patching on top of this, there is further complexity to manage. And this is without considering vendor-specific patches.

Managing vulnerabilities through strategy, not just tactics

We’ve focussed here on the tactics associated with vulnerability management. That’s a good idea because, before anything else, you need to respond to a threat and ensure your defenses are sound.
Again, Tachyon can make your life much simpler, as well as make your organization safer. It can monitor patch success and give you an instant ‘heads-up’ on how your organization’s patch infrastructure is functioning. It can verify the health of your SCCM distribution infrastructure. And with 1E Nomad, you can efficiently distribute the increasingly large patch files to your entire estate without interfering with business-critical operations over your network.
But, in many ways, this is really half the story, as tactics alone only allow you to reactively respond to attacks, rather having a proactive strategy for managing them. In the second part of this blog series, I’ll talk about strategic approaches to cybersecurity, and how you can leverage an effective proactive strategy, anticipating threats rather than scrambling to defend against them.