In a previous job, I had the mission of protecting a huge Windows infrastructure from ransomware. I had the resources to investigate and implement the necessary security controls. This is what I learned.
Be informed about the latest ransomware attacks, especially those affecting companies similar to you. Talk to them and ask what happened: how they got infected, which security controls worked and which did not, what was the impact, how they recovered, and whatever you think could be useful for your organization.
It is important to be on top of new ransomware TTPs to design and implement new security controls.
Gather IoCs from attacks you know about, and implement security controls based on them, like blocking the execution of files with specific hashes or browsing to malicious URLs. Apart from adding block rules and alarms for those IoCs, you can do threat hunting: assume the breach and try to find the IoCs in your organization.
The risk of ransomware infecting you has two parts: probability and impact. Preventive controls eliminate attack vectors and make the remaining ones less probable.
Linux by default
Nowadays, ransomware actors are focused on the Windows OS. The first action you can implement is establishing a policy of Linux by default in your company. This doesn’t mean that Linux cannot be a victim of ransomware. But ransomware criminals are not targeting it with the same intensity they target Windows. Probably because it is not as popular as Windows among end-users. It is worthier to target Windows than Linux. A Linux by default policy means that if a solution can run on Windows or Linux, choose Linux. I remember a big beer manufacturing company affected by ransomware that changed its SAP deployment from Windows to Linux after the incident.
Block it at the perimeter
Block malicious IPs upfront. If you don’t have a special requirement for allowing them, block Tor exit node IPs. A lot of malicious traffic comes from there.
Apart from Tor IPs, there exist dynamic reputation lists of IPs that you can configure on the firewall to be blocked.
If you can inspect traffic, inspect the emails and web navigation. Try to identify malicious payloads and block the associated traffic.
Finally, some firewalls have C2 detection capabilities. Research if your firewalls have this capability and enable it.
Email security gateway
Many ransomware attacks start with a malicious email. Usually, they include a malicious attachment or a malicious link.
Malicious email attachments can have different extensions. Each extension has different characteristics and its risk is different. It is worth considering that some extensions are easier to execute than others. For some extensions, you just double-click on them, and malicious code is executed. For other extensions, users have to do more actions. The better the security awareness, the less likely users will execute multi-step the actions to get infected. In come malicious campaigns, malicious encrypted ZIP files are sent, and the email explains how to decrypt it.
Block executable attachments at the email gateway. Some email clients, like Outlook, block a default list of extensions. One more layer of security would be to block them on the gateway. Is it worth that you allow *.exe files to reach you through email? If you have concerns about blocking certain extensions because you can disrupt the business, measure first, during some brief time, how many attachments do your organization receive with that extensions. When you are sure that the disruption is not going to be that much, block them.
These are some of these extensions: https://support.microsoft.com/en-us/office/blocked-attachments-in-outlook-434752e1-02d3-4e90-9124-8b81e49a8519
Configure the security capabilities that the email protocol and its extensions have.
Configure your email gateway to block emails that don’t comply with an SPF strict configuration and mark those that don’t comply with a soft SPF, for example by adding a [SUSPICIOUS] tag to the subject. Configure DKIM and DMARC.
Malicious attackers usually use hacked legitimate email accounts. These accounts comply with these standard email security measures. However, it is necessary to be prevented against the possibility of an attacker trying to spoof a legitimate email address. Additionally, these controls will protect you against other threats like phishing.
Antivirus engine on the email security gateway
If the email security gateway does have an antivirus engine, it is a good thing to have it enabled.
Try to use an antivirus engine that is different from the one that you use at the endpoint. That way you will be analyzing the suspicious attachments with two different engines.
It is difficult to identify statically some malicious code. This security control consists of sending the suspicious documents or binaries to a “sandbox” and “detonate” (open or execute) them there. Some malware is better identified during runtime. A sandbox is a specialized and isolated environment where a malicious document can be opened and analyzed safely. This analysis allows us to see its behavior and decide if it is malicious, suspicious, or safe. Sandbox engines usually give you the possibility of blocking the document, quarantining it, or pass the file as safe. Usually, you can configure different thresholds to establish how you want the sandbox to behave.
Some sandboxes block the delivery of the email or the attachment while they are detonating it. This is sometimes confusing for the end-users (especially management) that tend to notice when an email is not arriving. Other sandboxes let the suspicious file enter while it analyzes it. If the analysis is positive they try to delete the email from the inbox or throw an alert to try to contain the damage. But then it will be maybe too late. Depending on your business you will be able to configure the sandbox more strictly or not.
Malicious links in emails
Sometimes attackers use malicious links on emails instead of attachments. As security gateways have reputation lists that include known malicious domains, attackers try to use good reputation sites. They can do that by exploiting the legitimate functionality of the site or by hacking it.
Some email security gateways have the capability of rewriting the links. They change all links to redirect the user to the email gateway. When the user clicks the rewritten link, the email security gateway analyzes the content of the URL and decides if it is malicious or not. In some campaigns, the attackers send a link that doesn’t point to a malicious file at first, but they put it there after some hours. That way they bypass the email security gateway. With this rewriting capability, the email gateway analyzes the URL at the moment the user is trying to open it. The problem with this functionality is that you hide the URL to the user, and they cannot check by themselves if the site is where they want to go or not.
If you have a navigation proxy and all the web egress traffic passes through it, it is another place where you can implement security controls.
First, you can check the reputation for each domain your users try to navigate to. If the reputation is under a threshold, block the traffic or alert the user.
Web pages are usually categorized. New domains can be uncategorized. That can be a signal of a malicious domain. Some companies block all uncategorized websites with a warning. If the user thinks it is an error, he can alert the security team to analyze the site and unblock it if necessary. Blocking uncategorized sites can have false positives, but it is usually a control worth implementing.
Browsing directly to IP addresses is also possible, but not frequent. That possibility can be blocked too.
Some DNS servers have the functionality of checking the reputation of the domains. If a domain is malicious or suspicious over a threshold, instead of resolving the domain to the real IP, the DNS server resolves it to an internal IP that alerts the user about the risk.
Block it at the endpoint
Antivirus (signatures and behaviors)
Not all antivirus software is equal. Some of them implement more modern techniques that detect many more threats.
Choose an antivirus that implements advanced signatures. For example, it must detect behavioral patterns like a process being launched by Word or Adobe Acrobat or a process that is doing “process hollowing”. Antivirus software with these capabilities are much more effective.
Block its execution
On many occasions, the malicious payload is executed through a macro in a Word or Excel document. If you can block macros completely, you are reducing the current risk of ransomware infecting your company a lot. However, many organizations cannot block macros: they need them for their business.
You can research internally which departments use macros and verify if they can change them to another solution. If that’s possible, maybe you are also improving their workflow at the same time.
If you have to live with macros enabled, there are other more granular controls to block them only in certain cases. It is possible to block macros only from documents downloaded from the Internet.
The usual payload included in a Word document is a “dropper”. A dropper is a kind of program that downloads something from the Internet to continue the attack. Sometimes, what is downloaded is a binary, but other times it can be a Powershell script or another kind of executable code. If you can detect when a macro tries to connect to the Internet and download something, and you block that macro, at that moment, you are reducing the risk in a significant way.
If you have an advanced antimalware solution or an EDR, you can also block macros when that try to navigate to the Internet.
Some extensions are executable in Windows by default. Some of these extensions are *.js or *.hta. These are extensions that are not usually used and it is safe to associate them with the notepad. Changing the association makes them not executable with only a double-click.
Block its propagation
I don’t think it is frequent that ransomware exploits a vulnerability to propagate. I guess the reason is that they have been able to thrive by using native functionality in patched systems. I have heard about some initial compromises by exploiting RDP vulnerabilities, but I was not able to verify that myself.
Anyway, having systems not patched is making it easier for attackers. You have to patch your systems and eliminate this threat vector.
If there was not a problem with permissions, ransomware would only infect and encrypt the files of the user who has clicked on the malicious attachment or link. However, ransomware threats are encrypting whole companies. How?
Frequently, users in Windows infrastructures work with local admin privileges. With local admin privileges, it is possible to escalate to domain admin if a domain admin has accessed the system sometime before. With domain admin privileges, the malicious process can access the domain controllers, and from there, launch the encrypt command to all associated workstations and servers.
If you can, don’t let users work as local admins. Instead, give them just the permissions they need to work.
About domain admins, reduce the number of them to the minimum. It is usually not necessary to work with domain admin privileges, but system administrators tend to use them continuously because it is faster than changing users when needed. On the other hand, it is bad for security. If someone needs to work with domain admin, study the case, but try to avoid that.
System administrators that sometimes need to use accounts with domain admin privileges could have two or more accounts with different permissions. They would use each account only when necessary, and by default, they would use the account with fewer privileges.
Domain and network segmentation
Another security control you can implement is domain and network segmentation. If you can, design and implement an infrastructure where compromising one domain controller doesn’t mean compromising the whole infrastructure.
Another common recommendation is to implement network segmentation. However, from my point of view, the data flows related to ransomware use ports that you cannot usually block if you share domain controllers between segments.
Although you implement the security controls above, you still face a residual probability of being infected and impacted. By implementing detective controls you increase the probability of detecting the threat while you are being attacked and before being impacted. This potentially reduces the impact of the breach.
What can you detect?
“Detecting” means receiving an alarm when something happens. We want to have few and meaningful alarms. The fewer and the more meaningful, the better. It is more important that they are meaningful: if our alarms are very meaningful and we have many that’s because we are being very attacked so we want to have all the alarms that are necessary, not less. However, having too many alarms is usually a sign that they are not too meaningful.
Here I would like to talk about what I call High Risk Events (HREs). An HRE is an event that means that something that should not have happened, has happened. For example, a malware that is detected and blocked at the endpoint but that it should have been blocked at the perimeter. We should have alarms for HREs. That the firewall blocks an IP is not an HRE, because that’s what is expected and everything has worked well. Detect and investigate each HRE and do whatever is necessary to fix the security controls that should have blocked that threat before and they have not done it.
HREs are different in each company because they depend on the security controls implemented.
Adjust the number of alarms to something that you can manage. If you receive too many alarms and you cannot analyze them all, you have to reduce the quantity. Choose those that are more meaningful. But you have to research and learn from them all. It is better to have one alarm that when you receive it you know you have a problem than having many alarms and not notice the one that means you have been compromised.
Despite all the preventive and detective controls, you have to assume that someday you are going to receive the call: “We have a computer here that is saying that it has been encrypted and that we have to pay a ransom to recover it”. What are you going to respond? What are you going to do? Does it depend on something (for example where is the computer)? You have to have a plan for that moment.
The main objective is to contain the attack. But the plan is different for each company. It revolves around shutting down computers (or not), contain the propagation (which usually is launched from the domain controllers), having a continuity plan to continue working, communicating the breach to stakeholders, and gathering information about the impact and how it happened.
When you have contained the attack and you know what happened and how, you can start the recovery.
You should have backups of all the relevant information that is not easily and fast recoverable by other means. The backups should be stored offline! Attackers try to find and delete the backups before initiating the encryption process, so better you have your backups well protected offline. If they are online, they will be ransomed too! Your organization should test backups at regular intervals through a meaningful process. It is not enough to check that you can recover a file. You have to test that you can recover a full server. Only by doing a realistic exercise of recovery do you find the usual problems with backups.
The backups may include full virtual machines already ready in functional production-ready storage. Take into account that recovering huge amounts of data may be very slow and your business may require to recover the production faster. This is a cost/benefit issue. Decide the times you can assume and the budget you have and with that decide what kind of backups you should have.
As you may have disconnected some systems, you have to include in your plan potential displacements of people to go to different places to recover the backups.
The plan should also include the priority in which systems are recovered to avoid having to decide that during the breach.
These are my recommendations based on my experience. The fundamental thing is to be on top of what is happening. You have to understand how the risks threatening your organization work. You have to implement sound security controls to reduce the probability and the impact. It is not enough to blame the users for clicking a malicious link. There are many things that security teams can do, but it requires time and effort, and a clear vision of what can be done.
What other security controls can we implement?