How to Recover from a Client-Side Attack
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?
