Travelex recently faced a scenario that every organization dreads: an attack that results in either significant data loss or the complete crippling of business technology. What follows is a day-by-day account of how the foreign exchange company’s new year cyber nightmare unfolded.
If you already know the story and want to get hands on with Sodinokibi in Immersive Labs Lite, you can get free access here.
31st Dec 2019
Travelex was hit with what it called a ‘Software Virus’ on the last day of 2019. Customers discovered that there was a problem when trying to access the Travelex UK website https://travelex.co.uk, where they were greeted with an ugly error message.
For the next two days, Travelex services remained unavailable with only this generic screen visible.
2nd January 2020
Travelex issued its first public statement via Twitter. This informed customers that their websites were offline and that some limited services remained in branches while a team of specialists worked on restoring services.
It became clear that this issue was not limited to website access for customers, as staff in their retail sites were using pen and paper to complete transactions.
With no further official information coming from Travelex, members of the cybersecurity community began to search for intelligence that could shine some light on the cause of this catastrophic outage.
Security researcher Kevin Beaumont soon published an image of a publicly accessible Windows server with remote desktop enabled.
Experts also spotted that Network Level Authentication (NLA) was not enabled for this device.
Going end of life in January 2020, this version of Windows (Server 2008 R2) will no longer receive updates. This is especially important when we consider vulnerabilities such as BlueKeep which have existed for years but were only recently discovered.
4th January 2020
Threat intelligence firm Bad Packets responded to Beaumont’s post, saying they had notified Travelex of vulnerable SSL installations in their network back in September 2019 but received no response.
This vulnerability allowed attackers to steal credentials and even run commands to potentially gain access inside the VPN.
6th January 2020
Computer Weekly became the first news outlet to put a name to Travelex’s pain, suggesting that the ‘Software Virus’ was actually a ransomware family known as ‘Sodinokibi’ or ‘REvil’ and that the attackers were asking for $3 million to decrypt the data.
It was also reported that the same hackers stole 5GB of user data from the Travelex networks. This is counter to the notification from Travelex that says ‘… no indication that any personal or customer data has been compromised’.
Sodinokibi was first seen in April 2019. The bad guys offer it as ‘Ransomware As a Service’, which works as follows:
- Bad guy gets a custom copy of the ransomware from a service operator.
- Bad guy infects a company or a user with their version of the malware.
- If the victim pays the ransom demand, the money is handed to the service operator.
- The service operator takes a cut (around 40%).
- The remainder is paid to the bad guy.
As ransomware goes, Sodinokibi is fairly standard in terms of its encryption methodology, and to date there is no known way of decrypting the data outside of paying the ransom demand.
It has a variety of delivery techniques that have been used by threat groups to infect devices. These techniques include brute-forcing RDP connections and using automated scans for known CVEs and other exploitable vulnerabilities.
It has also been observed that some threat groups have deployed Sodinokibi into already compromised networks. In these instances, once the threat group has identified sensitive data that is likely to result in payment, they can then encrypt the data and maximize the impact by deleting backups, preventing anti-malware from running or applying other techniques.
8th Jan 2020
Travelex officially confirmed that the attack was Sodinokibi and claimed to have successfully contained its spread while having reinstated a number of internal systems (though its website remained down). The company said there was no indication of customer data being breached, and the Information Commissioner’s Office said it had received no report from Travelex.
However, the attackers who claimed responsibility told the BBC that they had ‘gained access to the company’s computer network six months ago and downloaded 5GB of sensitive customer data’. They said dates of birth, credit card information and national insurance numbers were all in their possession.
It was impossible to know who was right at this stage, but the bargaining chip of customer data would certainly justify the hefty $6m ransom they were demanding. The share price of Travelex’s parent company Finablr had fallen around 16% since the start of trading.
What can we learn?
Though the attackers claimed to have had access to Travelex systems for six months, it’s likely the actual ransomware attack was launched on 31st December to benefit from Travelex having fewer available staff. This could account for the delay in both rectifying the downed web server and the lack of timely communications with customers and the media.
It is almost certain that Travelex had an incident response plan in place; however, documents that determine what should happen in certain scenarios are only useful when regularly drilled with relevant teams and individuals in realistic fashion. Exercises and simulations can help and should deliver valuable insights into where further training or tools might be needed to increase human capability in the event of an actual attack.
Immersive Labs allows you to run and analyze the Sodinokibi ransomware in a safe environment, learn how to set a Yara rule capable of detecting it, and get to grips with how Process Monitor can be used should you face a similar situation. To get started, head over to Immersive Labs Lite and click on the ‘Sodinokibi Ransomware’ objective.