Sign Up Login
Resource Center  >  Blog

Your Website got Hacked? Here is what you should do!

September 22, 2020
Admir Dizdar

Has your website been hacked? Don’t panic! We prepared a simple list of steps for you to follow to recover it.

Even if your website hasn’t already been hacked, bookmark this article! Unfortunately, as with all the exploits and tools available to hackers and software technologies are evolving so rapidly, there is a realistic chance you will need it at some point.

There is even a greater probability you will experience a breach if you are using an open-source CMS with many plugins such as WordPress or Joomla!

Here are the steps you need to take in case your website is hacked:

1. Create an action plan
2. Create a battle sheet
3. Take your system offline
4. Clone your system to a testbed or staging server
5. Scan your website for vulnerabilities
6. Fix the vulnerabilities
7. Bring the fixed version back online
8. Monitor your new website
9. Create a reaction plan for future events

Creating an action plan

Before doing anything, take a few minutes to think through how you can minimize the negative impact and maybe even gain something from the incident.

Write down all the steps you need to take to:

– Preserve the current state. This will help you understand how the breach happened.
– Don’t alert the attacker with any rapid changes. You don’t want the attacker to cover their tracks or cause more damage.
– Collect information and tools necessary to administer the website and related components

Create a battle sheet

Before you take the next step, it’s important you have the following on hand:

– Access details and credentials for your website
– Filenames and paths for any configuration files
– Access details and credentials for the OS or platform underlying your website
– If you are managing the underlying hardware, access details and credentials for the “lights-out” access tools (DRAC, ILO, KVM, local or remote console, etc)
– Telephone numbers, email addresses, and support portal information for any vendor providing you with the web server and any of the underlying layers

Take your system offline

Take your system offline. Taking your system offline will limit any additional damage the attacker may do to your website. This will also prevent attackers from covering their tracks or evidence which may lead you back to them or the methods they used. Taking your system offline will also prevent them from inflicting additional damage on other people.

The specific steps you need to take in order to take your system offline depend on where you are hosting the website. Are you using a hosting company or is the system located at your company premises?

Clone your system to a testbed or staging server

Some of the tests you are going to run as part of your investigation tasks can be quite aggressive. They can damage your website, or in this case to any artifacts left on the system by the attacker.

As those artifacts can lead back to the attacker or the methodology the attacker used to breach your website, it’s important you preserve them.

Clone your system to a separate testbed or staging server. Just make sure you don’t use a hosting provider. The testbed has to be completely isolated from any public IP address spaces. This will insure your system can’t be reached from the outside, but also that your cloned system cannot access or affect third parties.

Scan your Website for vulnerabilities

Now that you populated your testbed, it’s time to test your system.

Scan your entire website for all possible points of entry and simultaneously look for this breach’s specific point of entry.

You can test your entire website for all possible entry points by using automation.

Using a reputable web vulnerability scanner, launch a scan on your cloned testbed. This will help you:

– Identify any misconfiguration of the web server and related software
– Identify old and known vulnerable software versions
– Identify insecure security access methods
– Identify inappropriate access to filesystem locations
– Run a very large battery of specific tests looking for specific known vulnerabilities

If you just restore the website from a backup, it is only reasonable to assume that the attacker can rapidly gain access using the same entry point. For this reason, it’s crucial you find the point of entry for the breach and fix the issue.

To do so, jump to the affected system and:

– Get a list of running processes and look for suspicious running applications or services such as backdoors or trojans
– If your system has been hacked, there is a high possibility that the attacker may have introduced new files with malicious code or changed existing files on your system
– Look at the log files generated by the operating system, the web server software, and any other software also used by your website

When the scan finishes, compare your findings with the list of vulnerabilities the automated web vulnerability scanner found.

Fix the vulnerabilities

Using the information gained from your manual investigation along with the list of vulnerabilities compiled by the web scanner, implement code improvements, server updates and hardening to prevent such an event from repeating and plug other weaknesses.


– Stop any foreign processes
– Remove any extraneous files or executables
– Replace changed files and data sets with fresh or sanitized versions

Check any fixes implemented by repeating the automated scan.

Bring the fixed version of the site back online

Now that your clean up is complete, suspected files and processes have been stopped and eliminated, the points of entry secured, and other security measures are in place, you can bring your website back online.

Monitor your new and improved website

Huray, your website is up and running! But you need to make sure that your fixes are effective. Come up with an early-warning system of an attacker trying to get into your system via the same access vector as the event you have just fixed.

A DAST tool integrated into your development process can help you identify vulnerabilities early and help you remediate them before they go into production. This can help you prevent future security incidents.

If the attacker manages to get back in, you either haven’t identified the entry point correctly, or you have not identified all of them. Repeat the process to again recover from this latest hack. 

Make an action plan for future incidents

After you have completely recovered from this incident and completed all the tasks related it, you should revisit this section, review the action plan you made and use it to build a recovery procedure for any future incidents.

This will allow you and other members of your support team to more effectively and efficiently handle any future incidents.

Related Articles:

Related topics

Dynamic Application Security Testing (DAST) is a crucial component in fortifying web applications against potential vulnerabilities. By taking a proactive stance, DAST systematically detects and addresses security flaws.

See more

By mapping Dynamic Application Security Testing (DAST) to the Payment Card Industry Data Security Standard (PCI DSS) requirements, organizations can

See more

What Is Mobile Application Security Testing?  Mobile application security testing is the process of assessing, analyzing, and evaluating the security

See more

Test Your Web App for 10,000+ Attacks

See Our Dynamic Application Security Testing (DAST) in Action

  • Find & fix vulnerabilities fast
  • Zero false positives
  • Developer friendly

and see how easy AppSec can be

Test Your Web App for 10,000+ Attacks

Integrate vulnerability testing into your DevOps pipeline. Find & fix vulnerabilities fast with zero false positives.
See Our Dynamic Application Security Testing (DAST) in Action
Testing variance Using Legacy Dast Using Dev-Centric Dast
% of orgs knowingly pushing vulnerable apps & APIs to prod 86% 50%
Time to remediate >Med vulns in prod 280 days <150 days
% of > Med vulns detected in CI, or earlier <5% ~55%
Dev time spent remediating vulns - Up to 60x faster
Happiness level of Engineering & AppSec teams - Significantly improved
Average cost of Data Breach (US) $7.86M $7.86M