Stop thinking that Ransomware is about ‘getting a virus’ or ‘clicking on a malicious email’. Ransomware doesn’t just ‘happen all of a sudden’. Technology to prevent ransomware and other malware has continued to get better with the increase in prevalence and attackers have now gotten smarter and more methodical. We can debate the topic of malware delivery all day long. The reality is, there are many ways that an attacker can deliver and execute malware or ransomware in your environment. The bottom line is that the majority of these issues in most environments start with remote access and the attacker intentionally chooses ransomware to be their best course of action, after they have spent substantial time inside an environment and determined that it is worthwhile.
In almost any industry today, remote access by an unapproved person is a tremendous problem – be it from a regulatory, compliance or governance standpoint. A ransomware attacker is just like any other adversary now; they look for a way in, they survey their situation until they have enough information to identify if there is an opportunity for them, they plan it in depth and then they execute. Oftentimes, this also includes other malware such as Remote Access Tools and ‘living off the land’ scenarios inside your environment and plenty of other scenarios that have nothing to do with the ransomware itself. Assuming that these environments are not using a SIEM to monitor unapproved behavior, here is the breakdown of a scenario that the team at Sedara continues to run into. If you are using a SIEM – make sure to develop your use cases and alarms for some of these scenarios. Just because you put a security tool in place, doesn’t mean that it is already configured for your user base and how your specific organization does business.
Step 1 – Find a way in
Compromised VPN credentials with no multifactor enabled – this is the most common and highest risk. There aren’t exactly a lot of advanced techniques here; All it takes is for 1 user to get phished and for someone to figure out the VPN configuration that you use – which is quite easy to do. If a user logged into your VPN in the middle of the night, would you know it? How long could they be in your network before you figured it out?
VPN with Multi Factor Authentication enabled to push notify for MFA approval; Think you have VPN access covered because you use MFA? We have successfully socially engineered multiple users across many organizations through our penetration testing.
There are many – public facing applications not in a DMZ? Cloud environments that are connected to internal networks via VPN that might be susceptible?
Step 2 – Establish a secondary foothold
Once someone is able to get full access into an environment, the last thing they want is to have their hard work go to waste before they can take advantage of it. They set up another way in. This can come in many forms, but here are some that we have seen in practice;
Setup internal Man in the Middle (not that hard still today) and wait for an IT person to log into their Antivirus system. Change the global policy to whitelist their own remote access tools, so that it is observed by their antivirus to be a legitimate application. They deploy to 2 or 3 computers throughout the environment and confirm that they phone home and you can get in. Voila…now they have multiple ways in, that still no one knows about.
Setup a new VPN user. Easy to do in most environments and depending on if/how you use MFA, many environments could allow a new MFA user to be legitimately created, so there may not even be a violation of internal policy. Are you notified every time a new VPN user is created in your environment? Do you know how many VPN users you are SUPPOSED to have?
Again, many options here; New inbound NAT on a firewall to allow RDP to an internal server, with local credentials; Would you know if this was created? New IPSec tunnel to another location; Would you get an alert if a new tunnel was added to your firewall? How long do you think it would be before you found it?
Step 3 – Plan
Find the backup server and see where it writes. Local Disk? Tape? Cloud Backup? Can any of these be deleted, encrypted, overwritten or removed some other way? Look for other backup jobs – look at every scheduled task on every server and other jobs that may be running to see if there is a secondary backup location – is that one susceptible too? Even if the backups are architected well enough to not be a target, could a ransomware event that takes down every computer and every server still be worth a company making a payment to get out of it? What is their cost of downtime (easy enough to guess this in most companies)?
Find the finance and insurance records — how much money is in the bank today? How profitable is the company? Most organizations have these reports saved somewhere. Here is the big secret…. this is normally how someone is going to decide how much the ransom payment is going to be. They are in business to actually get paid, so they aren’t going to ask for a sum of money that their victims can’t pay. They are going to ask for an amount that will allow you to stay in business if you pay it, and is cheaper than if you had to recover from their attack without paying it.
Find out what antivirus you use and then test the malware/ransomware that you want to run against it outside the environment. Most people that do this type of thing for a living have a pretty good idea what they are up against, once they know what antivirus vendor you use. If it is a traditional AV vendor they will be very happy — 10 minutes to recompile their malware into a hash that they have never used before and they will likely not have any issues getting through. Using a more advanced AV? There is almost always a way around it, including referring back to step 2 — get credentials into the antivirus system and just whitelist the malware you want to run. How many environments out there get an email notification every time you make a change to an antivirus policy? If you aren’t getting notifications when your AV policies change…. you should. It normally doesn’t happen that often, so when it does, you better make sure that it is a legit change.
Step 4 – Execute
This is the easy part – most of this will be already scripted and ready to roll, once all steps above are all completed, they will know exactly what they are going to do already. They will also know things about your business at this stage, such as if you run a 3rd shift manufacturing operation, because they know not to touch those devices until last – once someone becomes aware of their process, then the likelihood of it being stopped becomes higher. By the time a 3rd shift person reports the issue, the attackers are generally almost done.
Step 5 – Wait for payment and open the help desk line in case anyone has questions
That is correct…the legit organizations respond if you have questions about their instructions or how to act on them. They want their money, so they are happy to provide customer service, so that they can get it.
None of this is hypothetical. These are all scenarios that our team at Sedara have actively worked through in the real world. Choosing security tools is just the beginning of the battle. The other 90% is configuring them properly and monitoring them for some of these situations. Do your VPN users typically only work 9-5? If one of them connects at 2 in the morning, do you have the ability to disconnect it and disable that account – or at least check with that user if it is a valid connection? Would you know if someone made changes to your firewall in the middle of the night? If a Remote Access Trojan beaconed out of your environment at any point, could you kill the process and block the destination IP address within a few minutes? If these answers are all ‘no’ then you have some serious risks to mitigate. If the answer is ‘yes’ then congratulations; you are well on your way to being able to build out the rest of your risk-based use cases and drastically reduce the risk to your organization for the long term.