Cover your bases: 5 common pitfalls that enable ransomware attacks

As a technical account manager who works hand in hand with Red Canary’s incident response (IR) partners, I am in the unique position of being involved in hundreds of IR engagements every year. In light of recent headlines warning of an uptick in ransomware threats targeting hospitals, I looked over my notes in search of commonalities that have led companies to seek third-party assistance in responding to a cyber incident. What follows are five common pitfalls that, over and over again, have resulted in successful ransomware attacks.

1. Email attachments

For better or worse, email is still a core part of almost every organization, which is one reason why it remains the largest attack surface. Understanding this, you have to look at the email attack problem holistically and determine where the easy wins are to shore up your email security posture.

Many of the IR engagements I have seen started with a simple attachment that successfully executed a piece of code and spread ransomware throughout an entire organization in a matter of minutes. Oftentimes the attachment in question is a JavaScript file or compressed file like a ZIP file, and allowing these files to execute as email attachments makes it way too easy for an adversary to introduce malicious code into an organization.

Quick-win tip: Validate unusual attachment types

Query all inbound emails over the past three months and validate your top five most common attachments. These will most likely be the files from Office products, such as Microsoft Word docs and Excel XLS files. Everything else should be blocked and handled on a one-off basis. Delivery of unusual file types should be accomplished by other means in a controlled manner whenever possible.

2. External-facing assets

There are really two types of external-facing assets: intended and unintended. While I have witnessed both being targeted, unintended external-facing assets are more problematic because they were never meant to be exposed to the internet in the first place. To be more specific, assets that have exposed services like remote desktop protocol (RDP) or server message block protocol (SMB) are extremely vulnerable to attack. I have observed these services being fully exploited on numerous occasions, either by brute-force attacks or by exploiting an existing vulnerability to gain full access to a corporate network. It is absolutely crucial that organizations understand what external-facing infrastructure they have and develop methods to quickly identify when that infrastructure changes.

Quick-win tip: Take stock of your exposed infrastructure

Use an external third party to verify all external-facing assets. If you want to keep the task in house you can utilize a service like Shodan to determine what external-facing assets are present and in your public IP address space. Define a regular cadence to gather and review this information. Ensure that user accounts will get locked out when too many login attempts are performed against a specific account. Keep an especially close eye on service accounts; these often have more privileges than end user accounts and often have backend configurations that auto reset the login attempts or completely disable lockout policies so as to not interrupt business operations.

3. Process injection

Process injection was the number one technique observed across the entire Red Canary customer base in 2019, including all incident response engagements. One key aspect to process injection is arbitrary code execution. I have observed adversaries utilizing this technique to inject arbitrary code into legitimate running processes. TrickBot uses the legitimate svchost.exe to inject into and run arbitrary code on the system to further take control of the environment. This stealthy technique makes this type of attack hard to detect—even when looking directly at the current running processes on a host.

Quick-win tip: Limit admin privileges

Arbitrary code execution is dependent on the user context under which it is running. As an example, a legitimate executable running under the signed-in user is very different from an executable being run by a system administrator account. Take extra steps to remove as many administrative rights from end users as possible. This will reduce the success rate of arbitrary code execution across an environment. If you suspect an endpoint may be compromised, take note of any legitimate executables performing abnormal actions. One example would be a process like svchost.exe calling out to a remote IP address with no command-line arguments present.

4. Inventory asset management

Incident responders face a unique challenge: you not only have to be technically adept to the latest techniques and tactics being used by threat actors, but you also have to understand the nuances of how a significant incident impacts core business operations. However, there is one aspect of incident response that is very clear and easy to understand: the more infrastructure you have visibility into, the better chance you stand to detect abnormalities in an environment.

I have seen an unfortunate number of situations where an attacker succeeded because the asset in question was not being properly monitored by IT security staff. Even more concerning, I have observed numerous environments fully recover from a ransomware attack only to be compromised again because a small number of endpoints did not receive the preventive policies to stop the ransomware from spreading to other unprotected endpoints. The IT staff apparently did not realize that the endpoints existed until adversaries attempted to compromise other remediated hosts.

Quick-win tip: Track your assets

Organizations need to be relentless in their pursuit to understand every single asset under their control. There is purpose-built software for inventory management as well as built-in tooling like PowerShell that an administrator can utilize to gather this information on a consistent basis. I’d like to note that inventory management is never ending. A point-in-time understanding is great but the best approach is to learn continually and track differentiation.

5. User error

You can have the greatest security team in the world with the greatest security products at their disposal and still fall victim to human error. As you can imagine, a lot of IR engagements originate with a single employee opening an email that should have never been received. Don’t get me wrong, a lot of the human element of security can be removed by software, policy, and process. But even the most careful employees can get duped.

I have seen some organizations fall into the trap of blaming end users to the point of self sabotage. However, I have also seen a lot of organizations see their end users as the best security asset they could possibly have. I can confidently say that organizations that take the latter stance will be more successful in their fight against adversaries.

Quick-win tip: Adopt a culture of security at work

Make security a core part of your organization’s values and culture. Too many organizations only touch on the importance of being a good steward of security on day one of the employee orientation only to then forget about it until a security incident occurs. Organizations that push mass changes across the company to respond to an incident are always in a better position going forward and receive significantly less pushback from other stakeholders in the company.

Act now

I hope these five actionable insights provide a glimpse of everyday life in the world of incident response. It is important to note that these examples are not the end all be all, as there are many other aspects that can lead to a company requiring incident response assistance. At the end of the day, every organization is unique, with a lot of moving parts that only get more complex when dealing with a security incident.

Do what you can now by putting together an incident response plan in addition to implementing some of the aforementioned tips and your organization will be much better prepared to handle a security incident.