I recently spoke to a Chief Information Security Officer (CISO) whose concerns about website vulnerabilities made me realize that a lot of businesses lack understanding and are unprepared to recover from a client-side attack. In our conversation, this CISO explained that he disliked marketing and saw it as a risk and cost center to his business. He seemed to believe that everything his company’s marketing team did on its website was a risk and even called some standard marketing practices “reckless.”
I get it. To those who are unfamiliar with marketing, a lot of what marketers do can seem strange and intimidating. It is the marketing team’s job to make sure prospects know the business exists and convince them to interact with the business by reading blogs, downloading content, and sharing their contact information. Collecting a prospect’s contact information and safely storing that information is key to building business relationships, conveying product/service value propositions, and, ultimately, generating revenue.
By digging deeper in the conversations with the CISO, I discovered that he had a deep fear that his company’s marketing team and any assets they controlled (e.g. the website, third-party applications, etc.), would become the weakest link in the security chain.
Conceptually, his fear was justified. Reducing website breach risk is crucial, because website attacks are a very real and dangerous thing. Fortunately, there are things that can be done to mitigate a breach when it happens and prevent breaches before they do significant damage. Let me walk you through some steps and best practices on how you can quickly recover from a website breach.
A Client-Side Attack is Discovered: What Should Businesses Do?
Step 1: Keep Calm and Carry On
First things first. Take a deep breath. Accept that your website or web application has experienced a client-side attack, and keep in mind that the attack may have been ongoing for weeks or months. The damage has been done and the task at hand is to recover quickly but not make things worse or demotivate your people. If your business already has an incident response plan in place, go ahead and follow it. In the event that this is your first client-side breach, work closely with your team to learn and grow together. Encourage them to use the opportunity to enhance their skill set.
Step 2: Contain The Breach
Do whatever is recommended and necessary to contain the breach. This may mean temporarily shutting the website down, so that the attacker can’t steal any more data or engage in other malicious deeds. Although, depending on the type of attack, this may or may not be the best strategy. For example, some security investigation teams may want to keep the system up for a short time to stealthily observe intruder activity to help ascertain the type of threat and even possibly identify the intruder. (This is particularly important if it is an insider threat.) Further, if you take the site down for a week to contain the breach, only to find out that the attack wasn’t targeted at your customers and you could’ve investigated while the website remained functional, the effect on operations and sales may be significant. Ultimately, though, it is important that you take whatever steps you feel are necessary to protect your customers, particularly if they are the ones being victimized by the attack. This may mean that you shut your site down for a time, while you investigate and remove any malicious code.
Step 3: Investigate
The investigation process involves carefully reviewing each first- and third-party script operating on your website to understand what data the scripts have access to and why. For example, are any of your scripts sending data to a foreign country or to a known command and control domain (C2)? Are any of these scripts unused or are they zombie scripts? If you find unidentifiable scripts, then shut these scripts down or change their configurations to prevent them from accessing sensitive data, until you can ascertain their authenticity. In addition, deploy a Zero Trust approach across the website to prevent any remaining scripts from accessing or manipulating data that the scripts have no need to retrieve.
Step 4: Shut Down Malware, Malicious Scripts, and Backdoors
At this point, you likely have zeroed in on any corrupt third-party or malicious scripts, malware, or backdoors running on your website. Typically you will be able to find suspicious or unauthorized client-side applications or scripts running on your website or web application. Learn as much as you can from them, such as the file path and where data might have been sent, and then shut them down immediately.
Step 5: Identify the Point-of-attack Origin
If you are able to identify the attacker, you may be able to determine whether the attack is the result of an insider threat or an external cybercriminal. You may also be able to determine the point of origin or entry for the attack. This is critical to avoid future breaches and enhance any current security controls (or add new security controls to cover an exposed gap).
Step 6: Recover
Once you are comfortable that your website or web application is operating safely again, it’s time for damage control. If customer data was exfiltrated, you need to follow your local laws and regulations to inform your customers of the breach. It is important to note that depending on the compliance regulations, cyber insurance policy terms, or any contractual obligations you have with your customers, you might need to notify the authorities and your customers and partners ASAP, even before you have recovered from the incident. Talk to your legal and public relations teams to determine the best approach.
When you do notify your customers, they will want to know what information was exposed and how you plan to ensure a breach doesn’t happen again. There are a few key items to outline for them if you decide to announce the breach:
- Breach details:
- What was taken, broken, or stolen?
- How did the attacker get in, what did they deploy, and what might they do with what they stole?
- How significant was the breach?
- Future protective measures:
- What will your business do to secure your client-side applications in the future?
- What should your customer do to protect themselves moving forward?
- What did your business learn from the breach and how will you do better?
- Is your business still vulnerable to similar breaches?
Three Key Steps to Prepare for Future Attacks
Once the breach has been contained and you’re certain your business and customers are no longer at risk, then you need to prepare for future attacks, because in spite of your best efforts, no web application or code is going to be perfect, and the threat of future attacks is always looming in the distance.
Step 1: Learn, Learn, Learn
If you are like most organizations, a client-side attack is something new and unknown. In order to properly prepare for future attacks, you have to collect as much data, intelligence, and information as possible. Here’s a quick list of the types of information your organization should capture:
- List of all your web applications and websites.
- List of access details and credentials for databases and technologies.
- List of customer, prospect, or user data collected.
- List of all approved first- and third-party scripts used on your website.
- List of all approved data first- and third-party scripts used on the website.
- Configuration file names and paths.
- List of applicable log files collected from your website, web applications, software, system files, etc.
- List of API keys, security tokens, and integration details.
- Vendor contact information (if your website is hosted externally, and if you have any marketing or other technologies integrated with your client-side applications).
Step 2: Scan for Vulnerabilities
Threat actors love to find vulnerabilities in your code so that they can exploit them. When preparing for future attacks, it is important to ascertain whether your website is up to date. Are you using the most secure code libraries? Have you deployed all available patches? Take your time to scan your website or web application and mitigate risk as much as possible. If there are any vulnerabilities without an available patch, track it, or find a work around. Make sure you identify:
- Web server misconfigurations
- Old software versions
- Known vulnerabilities in software versions
- Available patches for known vulnerabilities
- Inappropriate access to file and system locations or data
One thing to note, traditional vulnerability scanners are designed to scan back-end code and systems, a.k.a. server-side technologies. It is unlikely that they will be able to detect every client-side vulnerability that a industrious threat actor might use against you. To learn more about client-side vulnerability scanning, check out our blog.
Next, patch all vulnerabilities you uncovered immediately. If there isn’t an available patch, do some research to find out if there is a way to reduce the risk of vulnerability exploitation. You will likely have to end any unauthorized or foreign processes, remove corrupted or unauthorized files, and, if the threat actor modified any client-side script, replace modified files with approved or sanitized versions.
Step 3: Test Your Defenses
Once you have regained control over your web applications and websites, use the intelligence you have collected to validate and, if necessary, upgrade your defenses. Use the threat actor tactics, techniques, and procedures (TTPs) that successfully breached your website previously to see if the same TTPs still work. Use the client-side cyber threat intelligence (CTI) you have collected and look it up in open-source CTI feeds or in paid feeds like VirusTotal. Learn more about your attacker, see how else they might attack you, and pressure test your website to see if those other TTPs might work.
You may also wish to create a clone of your website to test your defenses. If you are using real TTPs, you don’t want to harm your customer-facing website. The goal is not to disrupt your businesses ability to grow and interact with your customers.
In Closing
Client-side attacks are growing in frequency and in ferocity. According to The Safety Mag, cyberattacks on web applications were up by 800% in 2020. Threat actors see the client-side as their new frontier. Security teams have been focused on securing the server-side, the legacy security perimeter, and anything behind the firewall. They are slowly starting to focus on the client-side, as part of the expanded security perimeter. Threat actors are moving much faster. In order to detect client-side threats and/or block them in real-time, organizations need to deploy client-side attack surface monitoring products and JavaScript security permissions. I would like to encourage you to check out our Inspector and PageGuard products. They are specifically designed to save you time, effort, and money when preparing for and investigating potential breaches, by continuously scanning and protecting your business from website and web application attacks. If you would like to see our products in action, please request a demo here: link.
