Take the next step
Talk to us today
Ransomware is a type of malicious software (malware) that prevents or limits users from accessing their system or by locking their files until a ransom is paid.
Authored by David Robinson
Published on
ZX Security has prepared this maturity model to help organisations evaluate their preparedness for a Ransomware attack . The preparations presented here are part of an ongoing process, not just something you review once. As each level is reached, the items on the lower levels should be revisited, as things are continuously changing (both your organisation’s IT systems and the risks posed by Ransomware).
Most of the content and the recommendations in this model should not be new or novel. The protections and mitigations for Ransomware are common security advice, so where possible these have been presented with a justification that ties back to mitigating Ransomware.
This is a large task if everything is completed, but doing some of what is outlined here will be better than nothing. Likewise, this document is not exhaustive, there is also more work that can be done on top of what is discussed here. The information gained in the first three maturity levels should help the organisation understand the risk which they are facing from Ransomware and then decide what tasks are approached next based on the organisation’s risk appetite.
This blog focuses mainly on the business operation side of a Ransomware attack. The NCSC in the UK has put together a document on what board members should know about Ransomware and what questions to ask the organisation’s staff. Additionally, each country will have privacy laws which may mean they have to report these attacks or suffer legal consequences. For instance in Aotearoa failing to notify the Privacy Commissioner of a notifiable privacy breach could result in a fine of up to NZD$10,000.
If you want to quickly assess your companies maturity, take a look at the following model and give yourself a score between 1 and 5. For more information read on below:
The content of the above image is also available as a PDF.
Over the last few years, we have seen Ransomware change from spreading automatically like a worm, to a large coordinated process run by real humans in a business relationship. Recent Ransomware attacks are multiple step processes, often being split between different teams. A Ransomware attack chain may look something like this:
Earlier Ransomware focused on encrypting files, forcing users and organisations to pay for the files to be restored. Now, the business model has changed to gain money even from people who have backups. The Ransomware businesses will now also seek ransom to not publicly disclose the files and other private data, which they exfiltrated before performing the encryption. These may not be files in the normal file sense, the attackers may set up a scraper to scrape all the data from an internal web application as an example. There are now reports that some Ransomware organisations are doing a third-tier ransom where they go to each affected party (customers) and seek payment not to release their individual data.
The first three steps in the list above are the same for most intrusions, so the mitigations discussed in this document will help to defend the organisation against a wide range of security issues, not just Ransomware.
We are saying “Ransomware businesses” as that is what they are. These are not a group of malicious individuals in a basement - these are companies with:
The attackers are organised, you as defenders need to be equally as well organised.
The items listed here are not exhaustive. Rather, this document will help provide a starting point for discussions inside your organisation.
Level 1 is the base starting level for an organisation.
Organisations at level one are likely to not have a full picture of their IT asset base. Shadow IT will make this a task difficult, as the IT department and security team will not have visibility or oversight of the systems which are included in the Shadow IT space. Organisations that don’t have an IT department are also normally operating at this level.
A plan for what happens during a Ransomware attack will likely not be in place.
Level 2 is about understanding the organisation’s systems and what the impact there would be to the organisation if a Ransomware attack were to occur.
The key tenant of being able to defend an organisation is to know what IT assets the organisation has and uses. Without this knowledge, it will be difficult to understand what the threats are and how a Ransomware attack will affect the business. This inventory should include on-premise assets, cloud-hosted assets, and SaaS assets.
Getting a view of Shadow IT assets is important, the assets should be documented and where possible brought under the control of the IT team. The entire organisation is only as strong as its weakest link and Shadow IT is often the minimal viable product with security an afterthought.
In addition to the systems themselves the inventory should also document:
Level 3 is about planning what the organisation will do if there was a Ransomware attack and how to mitigate its impact
If a Ransomware attack was to happen, there needs to be a plan for how the organisation is going to act. There are example playbooks online which can be used as a starting point. These do need to be customised for the organisation, so should be prepared ahead of time. The playbook needs to cover multiple aspects of the response:
Getting the organisation’s IT systems working again might be a very difficult task, as it could be a full cold start scenario that involves setting up a new parallel network with no connection to any existing infrastructure. This new network cannot connect to anything in the infected network, as the Ransomware may spread to the new network. This process may require:
Level 4 is about ensuring all the organisation’s systems have Ransomware protections in place.
What is documented here is not going to be an exhaustive list, but a general list of things organisations need to implement. This is based on ZX Security’s experience testing networks for our customers and the most common issues we see and exploit during our engagements, these have then been thought about from a perspective of a Ransomware attack.
The recommendations in this document are also not unique and have a lot of overlap with guidance put out by other organisations:
The following will look at the various controls through a lens that will focus on how to help mitigate a Ransomware attack. The implementation of these controls will also improve the organisation’s security posture to help protect against a wide range of other potential types of attack, which are not documented below. Do not see this as just protection from Ransomware, but rather that it is helping protect the organisation from a range of attacks.
The first stage of a Ransomware attack is gaining initial access to a single system on the victim’s network. There is a range of methods that can help make this more difficult.
One method which attackers use to access gain is through malicious emails. Malicious emails cover a range of techniques, such as those that contain malicious payloads, or those which are used to phish users.
With malicious payloads, email filtering should ideally be blocking these before they get to the user. The ACSC has a guide on how to handle malicious email. If potentially malicious files need to be handled by users, other controls such as application allow listing and disabling of macros should be implemented (these are discussed further later in this document).
It is best to assume users will get phished and provide credentials to the attacker. The user should never be blamed for this or fault be apportioned to them. There should be controls in place to minimise the impact. The following are discussed later in this document:
These defences will help minimise and limit the scope of impact if the users credentials get stolen.
Internet Facing Systems
Another initial entry location can be internet-facing systems. These could include:
Access could be gained from vulnerabilities in the application or from credential stuffing, password spraying or phished credentials. Credential stuffing is when usernames, email and passwords from previous breaches are used to gain access to other systems.
To stop the exploitation of the vulnerabilities, the vulnerabilities need to be patched.
To minimise the potential impact of credential stuffing, password spraying and credential phishing, Multi-Factor Authentication (MFA) should be used on all external systems and administration access to internal systems. As a stretch goal, it would be good to also add MFA to internal systems.
When implementing MFA, any MFA is better than no MFA, but if a new MFA system is being implemented it would be recommended to use a form of MFA that can not be phished such as U2F or FIDO2.
When MFA is enabled, if an attacker acquires a username and password they will not be able to log into the system that the credentials are for.
Patching
Attackers can use vulnerabilities in systems to gain access to systems. Patching systems will close these vulnerabilities. Unpatched internal-facing system are at risk from direct compromise. Internal systems which are unpatched could make it easier for attackers to gain a further foothold within the environment.
Patching in a timely manner (extreme risks should be patched within 48 hours (refer to ACSC Essential Eight: Patch applications and Patch operating systems)) is also important. Patching can help stop the attackers from getting the initial foothold in the organisation and make their lateral movement and privilege escalation more difficult. As part of the inventory activity (as discussed in Level 2), all systems should have a patching plan which outlines:
At this point the attackers have got their initial access to the system and will be wanting to obtain further access and escalate to a user with more privileges. This is so they can:
Patching
As mentioned previously, patching will make it harder for attackers to gain access to more systems.
Stop common methods for gaining user accounts
Microsoft’s default Windows configuration enables a number of protocols (LLMNR, NBT-NS and mDNS) which can aid an attacker. These are legacy protocols that are left on for backwards compatibility which very few modern networks require. These protocols can be leveraged using a common tool called Responder. Turning LLMNR, NBT-NS and mDNS off will help knock out this common attack vector.
Another common technique which attackers can use to gain access to service accounts is Kerberoasting. This attack uses required Windows behaviour and can be only really be mitigated by using strong unique passwords on service accounts.
These two attacks give the attackers passwords hashes that can be cracked. With these passwords, the attackers can log into more systems in the organisation’s network.
Passwords
Networks should require strong unique passwords for all user accounts. This includes passwords for user accounts and service accounts.
During our engagements, we see a lot of weak passwords, reuse of passwords and spreadsheets full passwords. An enterprise password manager, for all staff, not just administrators, could be helpful here as it will encourage users to:
Application Allow Listing
To gain further access to the organisation’s network and also perform the locking of systems the attackers will need to run applications and scripts. Application Allow Listing will make it difficult to run applications that are not on the allowed list. Similarly, restricting what PowerShell scripts can be run will make it harder for the attacker to gain access to more systems.
Disabling Macros
Ideally, the use of Macros should be disabled in Microsoft Office (and similar applications) and users should not be able to reenable them. Macros are often used as the first code run by the attacker on a target’s system. Blocking Macros will make it harder for an attacker to get their initial foothold in the organisation.
If there is a requirement for Macros in your organisation, they should be configured so users can run macros in documents which are in the document management system, but not from the internet. If documents are in the Document Management System they are more likely to be legitimate than a document delivered directly from the internet. The document management system save process should have a server-side virus check (which can not be bypassed), to give confidence that malicious files are not being stored.
Network Segregation
Firewalls restrictions between different parts of the internal network can make the exploitation of other systems more difficult.
For instance, management interfaces should not be exposed to the general network. Instead, management interfaces should be put on a dedicated network with access through a bastion host. Then, for an attacker to reach a management interface of a system they will first have to gain access to the bastion host. Bastion hosts can be configured with a known minimal level of security/access control, while some devices which may be connected to the network may not reach this minimum level. Microsoft goes into further detail on this in their Enterprise Access Model document.
Outbound network connections should also be restricted. This recommendation is two-fold. Firstly, restricted outbound network access will make Ransomware command and control more difficult. Secondly, it will make the exfiltration of the data more difficult.
Other than proxies, no computer or device should have direct outbound access. All systems should have their traffic directed through a proxy which first logs all traffic, secondly, it can block unexpected traffic. The internal DNS should only resolve internal servers. The proxies which do have external access should have access to a separate set of DNS resolvers that can resolve domains external to the organisation. DNS queries themselves can be used for command & control and data exfiltration, so as many as possible avenues should be restricted.
Least Privilege
The attackers will be searching for a path to obtain higher privileged accounts. This can be made easy if there are users or service accounts who have too many privileges or are privileged on too many servers. For service accounts, there should be one for each service and they should not be reused, passwords should also be checked to ensure they conform to the most recent password policy.
If a Ransomware attack has got this far it may be turning more into damage control and limitation as opposed to stopping it.
The attackers will first want to find the organisation’s data and then send it to servers under their control. The exfiltrated data can be ransomed separately from the locked computers, so that even if the organisation is able to restore from backup, the attackers can threaten to publicly post the stolen data if they are not paid.
Open File shares
Fileshares often have permissions that are too permissive, users can often read and write more than the minimum set of files they require for their job. It is also common to find file shares that do not require usernames/passwords. To a Ransomware crew file shares can be useful:
Document Management Systems
Using a Document Management Systems as opposed to file shares will help mitigate some of the issues above. These systems normally have better Role-Based Access Control (RBAC), so one user will have access to fewer files, assuming the RBAC has been well configured. The Ransomware attacker will be limited to the data that the compromised users’ accounts have access to.
Most document management systems will store previous versions of a file, so even if these files get encrypted they can be recovered. This does assume that users are not allowed to delete the version history and the attackers can not encrypt the underlying datafiles which back the document management system.
Access to files will often be logged, so when forensics is being performed the files which an attacker has accessed and potentially exfiltrated can be better defined to understand the compromise and which documents may be later leaked online.
Web Applications
Ransomware crews may not be able to lock the data stored within web applications, but they can scrape the data on the website for later release. A robust web application will have good auditing so the forensics teams will be able to list what data has been accessed.
The attackers are likely to try and stop, corrupt or delete the backups, to make recovery more difficult and increase the likelihood that the ransom will be needed to be paid to recover the data.
In addition to the obvious need to backup all important data, how the backups are stored needs to be considered. The backups should be stored in such a way that they are write-once or write-only, so it is difficult to delete or tamper with them. Before ageing out old backups, verification should be performed to ensure the new backups are not compromised or corrupted in any way.
Once an attacker is at the stage of deploying their Ransomware to all the computers in the organisation, there is often little which can be done. Once the attacker is at this stage of their attack, they will have gained administrator access to a range of systems through lateral movement and privilege escalation. The attackers can start to use the organisation’s administrator tools to their advantage. They could use tools such as Endpoint Configuration Manager to deploy the Ransomware to all computers, which is the same tool that the administrators use to deploy business applications.
The attacker in this position can also disable:
Disabling these security controls will mean that the Ransomware may run without being detected.
Once the attackers have triggered encryption, the focus needs to move on to the recovery process.
Restoring the data can come from backups. This may be complicated by the risk that the attackers could have left backdoors in the network to regain access and re-encrypt the data again once it is restored. This may require a cold build of the network.
A cold build is when the network is rebuilt from the ground up using new hardware, fresh operating and applications installs, and data once it has been verified as safe. This new network needs to be isolated from the original network, else the attackers may be able to get a foothold in the new network and run their attack again.
Level 5 is about putting the organisation in a position where they are on the front foot regarding Ransomware attacks by running through simulations.
Even with all the protections in place, there is still a possibility that a Ransomware attack could happen, particularly if the organisation is explicitly targeted. The organisation should simulate these attacks and practice dealing with a Ransomware attack. The results from these simulations should feed back into the previous levels to help improve them.
As with other security threats and disaster scenarios there should be regular exercises that let the business practice, and find any issues with their plans. These exercises could be tabletop, or they could use Ransomware (under the organisation’s control) to infect machines/network. These simulated attacks are beneficial as they allow not just the IT teams to test out their procedures, but all the other business units as well. Recovering from a Ransomware attack is not just an IT task, but all the other business units need to be able to function without the use of IT systems.
A lot of businesses are performing regular backups but these are often not tested. Testing restoring from backups is important for two reasons:
When doing the restore, it should be done in a way to replicate the cold start scenario. This is where a new parallel network is created with no connection to the current network, as in a real attack the current network can not be trusted and a connection between the two may allow the attackers to pivot between networks.
Networks should have monitoring in place. This should hopefully raise an alert early on in the attack chain, so that the attackers can be evicted before too much damage is done. It is becoming common to see organisation implementing Endpoint Detection and Response (EDR) tools such as Microsoft Defender for Endpoint or Crowdstrike. These will hopefully give the organisation visibility early on in the attack at a point where it can easily be stopped.
The other controls mentioned in this article should be in place before implementing EDR (or in parallel) as there will be ways to bypass it if the attacker can get a foothold before the alert is processed.
There needs to be processes and methods in place to ensure that when new systems, infrastructure and shadow IT are added to your organisation, they are recorded in an asset register. This will allow the organisation to:
There is no simple fix. Being prepared for a Ransomware attacks falls into two main areas:
The base protections for a Ransomware attack will cover the basics for many IT Security issues. The money and time spent implementing and maintaining these controls will help the business for more than just Ransomware.
As for a starting point, the CERT NZ Critical Controls 2021 and ACSC Essential Eight lists mentioned earlier are great starting points. Implementing those and understanding how they help your organisation’s security posture will put you ahead of a lot of other organisations. Implementing some of these is still going to be better than doing nothing, as often you just need to protect your organisation from large-scale commodity attacks, unless you are specifically targeted.
The contents of this maturity model is just a starting point. Completing what is laid out will go a long way to securing your organisation from Ransomware and other threats, but it is not an exhaustive list.
Thanks to all the people at ZX Security who read this and provided me with feedback.
Talk to us today