Anatomy of a Supply Chain Ransomware Attack and How to Prevent it with Barracuda’s CloudGen WAF on AWS

By Brett Wolmarans, Director of Solutions, Application Security – Barracuda

Barracuda

Ransomware hardly needs an introduction for those of us who work in cybersecurity, maintain web properties, or work in corporate IT.

During the past several months, a steady stream of blogs, webinars, videos, and other types of content regarding the topic of ransomware has filled our screens and inboxes on an almost daily basis.

So much so that we may even feel desensitized and a degree of alert fatigue when it comes to this particular topic. “Oh great, another blog on ransomware.” But you should read this one, and I’ll tell you why—because ransomware is likely to increase and can spread in ways you may not have thought about.

According to a recent alert from the U.S. Cybersecurity and Infrastructure Security Agency (CISA), ransomware markedly increases on holidays and weekends. Your organization’s best defense is to stay alert, learn as much as you can, and implement a ransomware defense strategy in a proactive manner.

In my role as director of application security solutions at Barracuda Networks, I listen carefully to customers about their security needs and help shape the product development of Barracuda’s application security solutions accordingly.

In this post, I will describe the role application security plays in preventing the spread of ransomware, and I’ll give several examples of how you can use Barracuda’s solutions to further protect your applications running on Amazon Web Services (AWS).

Barracuda CloudGen WAF on AWS

With Barracuda being an AWS Security Competency Partner, businesses trust Barracuda CloudGen Web Application Firewall (WAF) to secure their applications.

With dynamic profiling and application-awareness to minimize false positives, Barracuda CloudGen WAF protects against today’s advanced, persistent, and zero-day threats. Support for AWS CloudFormation templates enables automated bootstrap and cluster initialization for higher throughput and resiliency.

Barracuda CloudGen WAF is available on AWS Marketplace, and has an accompanying AWS Quick Start to streamline the deployment using CloudFormation templates.

Application Security and Ransomware

While ransomware is often thought to be associated mainly with phishing or remote desktop protocol (RDP) attack vectors, most web applications, if unprotected, may well play a pivotal role in the ransomware attack chain. This post addresses the importance of web application security in the context of various stages of a ransomware attack.

Let’s take the recent example of a major supply chain hack that made headlines in July 2021, where SQL injection vulnerabilities in a public-facing internet managed service provider (MSP) application were exploited to spread ransomware to their customers.

SQL injection has existed for decades but remains a common vulnerability that may exist on many web applications. By itself, SQL injection is reason enough to justify web application security for every web property you own, but it’s only an initial step in a longer attack chain that can lead to ransomware. Attackers need more than just a SQL injection exploit in order to be successful.

We need to double-click on this topic to understand how unprotected web applications can unwittingly be enablers of ransomware. The following is an imaginary (yet probable) story told as a series of steps that an average attacker might follow to exploit weak application security.

Please note that many details have been omitted intentionally so I don’t literally provide a recipe for disaster in this post. The key points are in place, however, to help convey the big picture.

Use Case: A Hacker’s Story

In this story, our first actor is an imaginary attacker named “Miyuki.”

Miyuki has decided to leverage a combination of technical and social engineering to achieve their goal of obtaining a large payment in cryptocurrency. Miyuki needs a way to attract victims and has chosen to take advantage of the (re)emerging wave of browser extensions or plug-ins that offer coupon and cash-back incentives based around the most popular shopping websites.

There are four websites in our attack chain story, and we need to pay attention to these as we follow the twists and turns of this attack chain. We’ll call them websites A, B, C, and D, for the sake of anonymity.

There are two other actors in this story: Starbuck, an intermediary, and our final victim, Brett. Although there are only four websites and three actors here, this story scales to internet levels. If you were to picture the same scenario but extrapolated over the millions of websites and users in the world, you can begin to visualize the potential scope of this problem.

Next, I’ll dive into the detailed steps of how a web application hack opens the door for ransomware to take hold in an unsuspecting victim’s system.

Step 1: Constructing a Facade

In this step, there exists a website for one of these popular coupon extensions, which we’ll refer to as Website A. This website has basic OWASP Top 10 protection in place, so it’s immune to SQL injection. That’s the good news; the bad news is that this site doesn’t have protection against web scraping, which is a type of web application attack that doesn’t necessarily align with any of the OWASP Top 10.

Miyuki (our attacker) uses web scraping and domain impersonation to create a forged version of Website A. Let’s call Miyuki’s new creation Website B, which looks just like Website A right down to the page layout, graphics, and font. It’s also topped off with an almost-identical SSL certificate to go along with the typosquatting domain name.

Finally, thanks to an automated web scraping script, Website B is updated every time Website A changes, making the effect very convincing to users.

Figure 1 – Website impersonation.

Step 2: Credential Theft

Now, suppose we have a legitimate but poorly protected company website, which we’ll call Website C. Due to the almost complete lack of application security here, Miyuki easily exploits an OWASP Top 10 vulnerability (such as SQL injection, the same attack used in the notorious, afore-mentioned supply-chain attack) to perform a breach and steal data such as credentials, usernames, and passwords.

Among the database of stolen credentials, Miyuki steals the credentials of a user named Starbuck. There’s a good chance these credentials will be useful on the next website Miyuki attacks, because users tend to re-use credentials across multiple sites.

Figure 2 – SQL injection.

Step 3: Credential Stuffing

Next, let’s take a legitimate consumer-facing ecommerce website which we’ll call Website D. This has basic application security in place, and is thankfully fully protected against SQL injection so Miyuki can’t easily harvest credentials here. But Miyuki doesn’t have to, instead using the stolen credentials from Website C to begin a credential stuffing attack against this legitimate shopping site.

Unlike quick web attacks which need to execute in sub-second time frames, this type of account takeover is quite the opposite. Ideally, it will run at a slow drip over multiple weeks.

Slow (enough) is desirable in this case to fly under the radar of rate-based security controls that may block a high rate of failed logins. After all, we expect users to mistype their passwords from time to time, so we can’t simply block a user every time this happens.

Miyuki is using their database of stolen credentials from Website C to slowly stuff in usernames and passwords into the login form for Website D. This attack will fail for users that have different login credentials for all of their websites, but it will succeed for any users that used the same login credentials on Website C and Website D—one such user is Starbuck.

Figure 3 – Credential stuffing.

Step 4: Beware the Reviews

To Miyuki’s delight, while stuffing credentials into Website D, it appears the real user Starbuck not only uses the same password, they conveniently have a high reputation (5 stars!) on the ecommerce site by virtue of having completed many successful shopping transactions.

As the next step, Miyuki (now logged in as Starbuck) posts specially-crafted, short reviews under the listings of a random selection of the top hundred popular products. These reviews take the form of “This product is great! I don’t know how I lived without it, but I wish I had saved 50% off the price shown here with this coupon extension—go to Website A to install!”

After doing so, Miyuki logs out so as not to arouse suspicion. The link in the comment looks exactly like a real link to Website A (the real coupon website) but actually takes the clicker to Website B, the forged website that Miyuki set up in Step 1 of this post.

Figure 4 – Creating the trap.

Step 5: Establishing Trust

The trap has been set. Now, let’s imagine another real user of the ecommerce site—our ultimate victim named Brett.

Brett logs on to Website D, stumbles across the malicious product review, and follows the link to Website B. Unless Brett scrutinizes the domain name, URL, site certificate, and other details of Website B, they will be fooled. After all, the product review was written by a user with high reputation.

Website B looks identical to Website A in just about every way; even the domain is similar with maybe an extra dash or dot or Umlat.

Brett just wants to save money and only has a few minutes at lunch break to get this done, so their guard is lowered. Therefore, through a combination of social and technical engineering, Brett now trusts Website B and happily provides contact details in exchange for the 50% off coupon.

Brett may even have to complete a survey to get the coupon, and in doing so provides more personal information such as household income, age range, and favorite websites. All of these contact details are, of course, sent to Miyuki, who now has the email address and personal details of Brett.

Miyuki has truly gained Brett’s trust now, and Brett is impatiently expecting an email with the coupon.

Figure 5 – Trust barriers falling.

Step 6: Same-Day Delivery

Brett receives a personalized email about the product and the coupon, with an attachment for the coupon they are told needs to be installed as a browser extension. Because this email is thoroughly personalized and is expected by the recipient, it’s likely to be allowed through traditional email defenses.

The email contains an executable attachment, and Brett’s operating system wisely prompts them not to install untrusted executables. Brett has attended company training which explained the dangers of opening attachments like this, but at this point Brett has complete trust due to the effective social engineering and spear-phishing.

Brett has been desensitized against installing extensions because of the proliferation of these coupon extensions. Besides, there’s only a minute left in the lunch break. Brett clicks through the warning and installs. The trap has been sprung.

Figure 6 – Spear phishing.

Step 7: Detonation and Regret

Brett installs the attachment, an executable file, and the ransomware attack is launched into memory on Brett’s system. Now, the ransomware can immediately cause havoc; for example, by infecting the master boot record or encrypting the file system table, both of which will lock up Brett’s system.

There are likely other systems connected to Brett’s network, which may be a home or business network. Therefore, Miyuki’s ransomware will also try to move laterally from Brett’s system to other systems on the network.

Shortly after the ransomware detonates, the inevitable demand for payment in cryptocurrency will be delivered to Brett once again using Brett’s email address, which Miyuki has possession of.

Figure 7 – Ransomware detonates on victim’s system.

This tale really is a series of unfortunate events. The ransomware only succeeds because—from the very beginning to almost the final step—web application security vulnerabilities, not phishing, are what allow the attack chain to proceed from one step to the next.

Unfortunately for Brett, social and technical engineering were used to great success in this example.

Recap: A Systemic Failure

To review, Miyuki’s attack chain was comprised of the following steps:

1. Web scraping of a legitimate Website A and fake Website B
   • Prevention: Web application security – Web scraping controls
2. Credentials stolen on Website C
   • Prevention: Web application security – SQL injection controls
3. Credential stuffing on Website D
   • Prevention: Web application security – Credential stuffing controls
4. Comment spam and malicious URL on Website D
   • Prevention: Web application security – Comment spam controls
5. Penultimate spear-phishing email in Step 6
   • Prevention: Training users to not run attachments
6. Ultimate installation and running of the executable in Step 7
   • Prevention: It’s too late for Brett’s system, but a Zero Trust architecture could prevent the ransomware from spreading laterally within the network

Would comprehensive application security at Websites A, B, C, and D have prevented this attack from succeeding? Yes, and with a high degree of certainty.

If adequate protections against web scraping, SQL injection, credential stuffing, and comment spam had been in place, Miyuki would have given up on this particular attack chain early on in the process.

It’s not worth Miyuki’s time to try to defeat a hardened website, as Miyuki will simply point the attack tools at different websites until a vulnerable site is found.

How to Protect Yourself

Application security is somewhat specialized, and application developers often don’t know enough about it to be confident in rolling their own, or they may just not have enough time.

Therefore, one of the most effective approaches to application security is by deploying a web application firewall (WAF).

Look for a WAF solution that has the following features:

• Easy: A WAF cannot fully protect you if you’re not able to configure it for your environment or find it difficult to use, or if it slows down your business cycle. AWS customers should be looking for a solution with strong support for your cloud patterns.
• Scalable: Business growth, digital transformation, and other factors can increase the demand on your applications and websites. Your WAF should be able to grow with your business as needed.
• Comprehensive: OWASP Top 10 protection is table stakes, but organizations must go further. A comprehensive WAF should at least protect against the following, almost all of which were exploited in our ransomware example above:
  • Web scraping
  • SQL injection
  • Comment spam
  • Credential stuffing and account takeover
  • Client-side attacks, data-leakage, malicious bots, and more.
• Contemporary: If you have an older WAF in place today, it may not have kept pace with modern attacks, so consider upgrading. Your WAF should have regular intelligence updates to improve the security and capabilities of the solution. Consider a hosted WAF solution if you prefer to have Barracuda manage the infrastructure. This allows you to focus your time on your security policies, not on managing infrastructure.
• Continuous: New attacks emerge every day, and they can spread around the world within a matter of hours. Your WAF should receive continuous updates on these attacks and employ machine learning to adapt to variants.

Conclusion

Ransomware bad actors will exploit application security to achieve their ends. Per the AWS Shared Responsibility Model, application security is your responsibility. Fortunately, there are solutions available if you understand how your websites may be exploited.

Don’t be a victim, and don’t be a link in the attack chain. Be part of the solution by deploying a comprehensive Barracuda WAF solution from AWS Marketplace, and ensure your websites don’t become a stepping stone for ransomware.

The content and opinions in this blog are those of the third-party author and AWS is not responsible for the content or accuracy of this post.

.

.

Barracuda Networks – AWS Partner Spotlight

Barracuda is an AWS Security Competency Partner that provides CloudGen firewalls engineered for the cloud to give customers flexibility and control over how they deploy security on AWS.

Contact Barracuda | Partner Overview | AWS Marketplace

*Already worked with Barracuda? Rate the Partner

*To review an AWS Partner, you must be a customer that has worked with them directly on a project.