Defending the Realm

We keep seeing organization get hit, in some kind of a sick way I think me and some of my friends in the industry are bored with the over dramatic responses of “sophisticated” “advanced” and “unpreventable” because most times the kill chains simply are not like this. But still the onslaught keeps coming. Well I know this much, whilst I would love to deploy with the team and harden everyone’s networks that simply isn’t possible. So what we thought we would do is write something to try and spread the knowledge a bit further and hopefully have some positive impact.

Ransomware 101

It’s not just that your data will be encrypted, it will likely be exfiltrated and sold. You will likely have access sold, data sold and be extorted. The Ransomware business model is adapting to defender responses. Even if you can restore from backup they will likely try and attempt to extort. This brings a key point in this equation, the best position is to NOT get pwn3d to start with. Ok that might sound silly to say but when we look at these kill chains you might start to see the world from my perspective a little.

Initial Access

Ok this part is actually really hard for the attacker when considering a single business but when they spread out across all of them this gets a bit easier. The typical initial access routes for ransomware include:

Dictionary Attacks on exposed remote access services (often exposed RDP on TCP 3389 or near ports) which are insecurely configured. They often have NLA disabled and often there are not account lockouts, MFA or monitoring. RDP ransomware according to Coveware accounts for about 50% of all initial access vectors historically, though this has dropped off in Q4 2020 with a preference to phishing:

https://www.coveware.com/blog/ransomware-marketplace-report-q4-2020

Exposed services remote code execution vulnerabilities (RCEs) are another major vector. There are a range of CVEs relating to this but they include:

Exchange Server
Pulse VPN
Vmware
Citrix
Various VPN and Firewall products

The remaining vector tends to fall largely then down to phishing. Now the phishing side of this can lead to remote access by the criminals in a few ways. Key parts here can include:

Credential Harvesting leading to remote access
Malware execution on the target device
Social engineering to give the criminals user assisted remote access (e.g. using software such as TeamViewer or windows remote assist)

So what can we do here to identify, prevent and detect? Well looks take a look at the checklist:

Initial Access Prevention Checklist

Audit you internet facing attack surface
Audit your remote access services configuration
Ensure perimeter security services are up to date and running in a hardened and secure configuration
Ensure you have strong authentication controls.
Ensure you have good password policies and controls deployed.
Ensure account lockouts are enabled.
Ensure password audits are conducted.
Ensure event logs are shipped and monitored.
Where possible deploy multi-factor authentication.
Where possible add layers e.g. a VPN (note this is not a magic bullet as you will have realised by the number of RCEs in VPN products in 2020)
Ensure you have mail security services.
Where possible disable macros on endpoint devices.
Ensure you are running antimalware services.
Ensure you have logging enabled.
Deploy hardened configurations.
Deploy Application/Binary Allow lists (e.g. applocker)
Disable unsafe file extensions e.g. MSHTA, VBS, WSH, JS etc.
Disable Powershell
BLock risky extentions e.g. ISO, VHD/VHDX
Restrict risky egress traffic.
Leverage a protective DNS service.

For more ransomare guidance check out our blog but also other awesome resources such as this from the NCSC:

https://www.ncsc.gov.uk/guidance/mitigating-malware-and-ransomware-attacks

Summary

If the threat actors don’t get the initial access part of the kill chain their game is over. Preventing initial access is a key step, there’s no need to make it easy for a criminal threat to get their foothold. It’s not an easy task but it’s not impossible to harden the attack surface. Password audits are relatively simple to conduct, protective DNS isn’t insanely complex to deploy and deploying hardening is usually just case of actually spending the time and effort to actually do it. Some things will get through but that’s not an excuse to simple not try and prevent. This is a key defensive area and so many incidents would have been prevented if this area was paid more attention rather than blinky boxes and grand security programmes being implemented (or simply the other reality where a lot of orgs don’t spend the time and effort to do this because they don’t consider it a priority).

Hopefully this gives some food for thought, we’ll be back with the next stage of the kill chain! Be safe and may the force be with you!

Check out part 2 here: