Maybe it’s because for some time the mantra has been “we can’t keep them out” so we “hunt them down once they’re in.” And that just isn’t working when it comes to ransomware. Once in, a wily attacker can hide while they prepare for the moment that they unleash the beast. When they strike it’s then quick, leaving no time for the hunt to stop them.

This is particularly a problem with old systems that should’ve been upgraded years ago. It's why technical debt is real for many organizations. Take Windows 7, for example. The OS is well past its sell-by date, but for many systems it works well enough and is costly to upgrade. the older operating systems, and the applications they run, lack the modern additions that slow the attackers down as they try to get in and move around a system.

What are we up against?

A typical ransomware attack starts with one little crack in the outer defences. Enough to let an attacker get some control on the inside. The most likely target is a user’s workstation. The attacker emails some code to the user and persuades them to run it. In all likelihood the user won’t know this is happening – they just open up an attachment which seems harmless enough – a Microsoft Office document containing macros is a firm favourite. But this isn’t the ransomware. This is something that creates a back door that allows the attacker to control the workstation. Luckily for the attacker, there are many back door kits available, such as Cobalt Strike, so they don’t need to work too hard at this.

The attacker needs to communicate with their back door, but that’s easy. The user will inevitably have access to the web (for browsing, getting software updates etc.) and this connectivity can be used by the back door to receive commands from the attacker. Turning off the web would fix this, but it’s just not a practical thing to do. And spotting the back door’s traffic hidden amongst all the other traffic is not easy (especially as encryption is there to prevent anyone seeing what you are browsing), even if you can afford all the skilled resources to go look for it.

Now the attacker has control of a user’s workstation, they can start to exploit it to get access to more machines on the network. This is easier on older workstations, since some of the techniques used will have been blocked in more modern versions. For example, they might use Mimikatz to recover the passwords of administrators who have logged onto the workstation, allowing them to remotely access key servers within the network infrastructure.

This might go on for a few months. The attacker is preparing the ground, remaining hidden while they work away to get access to as much of the infrastructure as possible. Eventually though, they will be ready for the final move. Armed with access to machines across the network, they can now launch the ransomware. This will encrypt key data, rendering it inaccessible. Then the final touch is to post some data on the web to prove they own your network and leave a ransom note.

Round about this time, your users start complaining things aren’t working. The attacker is no longer hiding in stealth mode, so you can start to track them down. But it’s too late. You are another headline in the news.

Where did it all go wrong?

Simple answer, you let them in at the start. That little crack was enough to give the attacker control on the inside, and from there they escalated up to get control over all your data.

What you should’ve done is stop that first bit of executable code getting into your system. That doesn’t mean looking for unsafe code and blocking it, because if it’s a new attack you won’t recognise it. What it means is, stopping all code, in all its forms, wherever it is hidden.

For users of Microsoft 365 Mail, that’s now easier than ever. Forcepoint recently rolled out a service that strips email of any unsafe content, before it reaches your users’ mailboxes. It uses Zero Trust Content Disarm and Reconstruction, which doesn’t go looking for unsafe data so isn’t fooled by anything new. It looks for the information you need, pulls that out of the email and then builds a new message to deliver the information into the recipients’ mailboxes.

This is a cloud native service that integrates seamlessly into 365 mail. You can turn it on for selected mailboxes in minutes. There’s no need to provision hardware, and there’s no infrastructure to manage – it’s all part of the service.

Now with the mail cleaned up in this way, that first bit of code which gives the initial control is not going to get in. The attacker is stopped before they get started.

Beware of the links

But while email is the favoured method of starting a ransomware attack, it’s not the only one. The email could persuade the user to visit a web site that delivers the unsafe document containing the code (we all know clicking on unsafe links is a bad idea, but how are we supposed to tell good from bad)? Now if your users are behind a web gateway, you would expect this to defend them, but in practice it can only detect known malware so an attacker with a bit of skill will be able to evade it.

Just like with email, detection is not a good defence here, but your web gateway could be updated to invoke Forcepoint’s Zero Trust Content Disarm and Reconstruction technology (either on-prem or in the cloud). Downloaded files get cleaned up, ensuring no code or unsafe data is delivered by the browser.

Controlling downloads is important, but that’s not the whole story. Browsers are designed to run code – every web page out there that’s worth visiting includes code that is downloaded to your browser to be executed. In theory your browser contains the code’s behaviour, stopping it from doing anything unsafe. But this is hugely complex, and attackers sometimes find ways around the controls, especially on older systems.

Browsing at a safe distance

For systems that are business or mission critical (is that all of them these days?), allowing browsers to run code from attackers might be too risky, but if you block all code nothing on the web will work. If you can’t risk bringing that code in, to the user’s browser, you can instead put the browser on the outside and take the user to the browser. This is Remote Browser Isolation (RBI), and Forcepoint’s RBI is a cloud native solution that makes this easy to do.

Web sites that can be fully trusted are accessed as normal, but if a link leads somewhere else the user’s browser is redirected to the RBI web app and an external browser is powered up to follow the link. The RBI web app allows the user to remotely control this external browser, so to them they seem to be surfing the web as normal, but all the code that’s needed to make the web work is running on the outside of the system in the cloud. Any files that are downloaded are passed through Zero Trust Content Disarm and Reconstruction before delivery to the user’s desktop, so the user’s get their work done, but nothing unsafe reaches them.

Zero Trust Content Disarm and Reconstruction

With Zero Trust Content Disarm and Reconstruction embedded in the email and Remote Browser Isolation functions, the attacker cannot get their code onto a user’s workstation. They cannot get started on their ransomware campaign. The security team looking after the network no longer needs to deal with mundane malware alerts, which frees them up to concentrate on the more serious attacks that might get in when users break the rules or because infrastructure is compromised through the supply chain.

Dr. Simon Wiseman