Security

Useful blog articles on bleech.de

Website hacked – what to do?

How to protect a website from hackers?

How does website hacking occur? – 10 signs

 

Website hacked?
– Repair Handbook

How to fix hacked websites?

This handbook will guide you through the process of repairing. Simply follow the individual steps in the given sequence.

This handbook is a living document and can be constantly adapted. If there is something you are not sure about or if you like to need more or detailed information. Feel free to ask our support consultants.

1. DON’T PANIC

If a website is hacked it seems that stress comes naturally for everyone who is involved. Stress makes everyone feel uncomfortable. The mind is thigh. This limits our rational thinking – the beginning of our own mistakes. Patience solves stress. Patience is a mind that accepts obstacles peacefully.

Just calmly accept. Then try to fix the hack.

If you later feel stressed again then stop working. Reduce your stress first and then resume your work.

2. Check indicators of compromise

You should notice one or more of these signs:

  • Strong decrease of the website traffics
  • Content appears on the website that does not belong there.
  • Defaced website
  • Your webhoster has disabled your website
  • Browser notification
  • Unable to login
  • Website has been flagged for distributing malware
  • Readers complaining that their desktop AV’s are flagging your site
  • Notice behaviour that was not authorised (i.e. creation of new users)
  • Security plugin alarm
  • Unwanted redirects

It is always a good idea to coordinate with others. If you get hints from someone, check them yourself. Rely only on your own investigation. If it leads you to the conclusion that there really is a hack, then move on to the next step.

3. Build a repair team

The repair team should be at least 2 persons.

Person 1 => Repair manager (RM)

  • Function: team lead, communication and documentation
  • This person should be someone from 1st/2nd level support or pm
  • In best case they should know the project and the client
  • This is the only person who has contact with the client!
  • Communication:
    • Always inform the client about every step:
      • what will happen in the next step
      • what we except
      • how is the status/result
    • Communicate internal in Google Chat
    • Documentate internal in Zendesk (or monday if it’s no support)
    • The communication should not be done by the person who repairs the website.

Person 2 => Repair dev (RD)

  • Function: repairing
  • Developer
  • In best case they should know the project

In case the hacked website is from one of our support clients: start a ticket in Zendesk

4. Start documentation

Use Google Documents for collaborative documentation.

Describe the symptoms

Ask your client or the person how find the hack:

  • What are you seeing that leads you to believe you are hacked?
  • What time did you notice this issue?
  • What actions have you taken recently?
    • Was an update installed?
    • How did make changes on the website / server / database / domain?
  •  Can you reproduce the issue?
    • If not, try to reproduce on our test or dev server

State your assumptions about the causes and justify them

Ask you or your colleagues who could know.

Chronologically record the further course of events

  • Start every entry with date, time and your name
  • Make Screenshots for the status and before and after changing something
    • Insert them into the document with description in the caption (e.g. Link to the website)
    • Also use marker for better presentation (e.g. red arrows)
  • URLs
    • Where should I document?
    • Support: Add a support ticket in Zendesk
    • Others: Just add a Google Document or maybe on Monday
  • In every case: This document could go to the client. It’s the base of the incident report to the client.

5. Collect all access data

Things you may need before the repair dev starts to work:

  • Access to provider administration panel
  • Admin account on WP (super user admin on multisite)
  • SSH access to the web server
  • Access to the database
  • WP-CLI
  • Buddy
  • Github repository
  • ManageWP
  • If support: Zendesk; others monday
  • Google Chat

All access data should be available in 1Password. Otherwise ask PMs and/or 2nd Level Support first before you go to the client.

6. Backup all the things

  • Take an Backup of the hole compromised website: all files and db
  • Put Files and DB dump together in one big tar archive file and never open this.
    • If you need the data later then always take a copy of this backup.
    • This backup can be used for later research and also for documentation.
    • Use tar for backup because you can save the origin user rights. You need to unpack later copies with the -p option for this feature. This feature is not available with zip.
    • Try extracting files with the same ownership as exists in the backup. => –same-owner
    • It’s a good idea also to compress the backup. E.g. with gzip => -z
    • Example command in terminal for a directory recursively incl. origin user rights and gzip compressing.
      Backup: tar -czvf client-name_www.compromised-website.com_2023-01-26–11-11.tar.gz ./folder-with-files-and-database
      Extract: tar –same-owner –keep-directory-symlink -xpf client-name_www.compromised-website.com_2023-01-26–11-11.tar.gz
  • Save this backup locally for your own purposes and also wherever you/your colleagues have access (e.g. Google Drive)
  • Be carefully: Don’t use this compromised files/db in your IDE
  • Make screenshots from noticeable changes

7. Clean and Restore

Now is the time to remove the old website completely and restore the backup data on the server.

Todo for the RM

  • First of all you have to inform the customer inform the client before you’re RD start:
    Very likely there will be some content loss. The restoring data may not be up to date in terms of content.
  • The lost content could eventually be restored. But this should be done later when the website ist fixed as an extra step. This could be very costly. Amount depends on the mass of changes after the restored content where done.
  • The client may not work on the website – not even login – as long as we repair it until we give him permission to do that.

Todo for the RD

  1. Start your work after the client has been informed by the repair manager.
  2. Remove all files and drop the database
  3. Reset all passwords for server and database
  4. Add directory protection
  5. Start an fresh deploy from Buddy
    1. If you don’t have Buddy access: make an little change in the master repo (e.g. add an dot to the readme.md) and merge it to production
    2. If you change the database you need to add this data to the wp-config.php or .env file or wherever this datas are stored.
    3. Change security keys and salts in wp-config.php
  6. Restore the database
    1. with the last secure backup from our ManageWP archive.
  7.  Update core, plugins and themes
  8. Install security plugin / Firewall (ninja or wordfence or…)
    1. 2FA
    2. Password checker
    3. Reduce file permissions to the minimum
      1. Start with the hardest setting and soften it later only when necessary
    4. Reset all user passwords
  9. Test the website:
    1. Looks ok?
    2. All forms working?
  10. Remove the directory protection

7.1. Monitoring

As long as you did not find the cause of the hack it could be possible that the website will still be compromised. Maybe the same symptoms come back later or other symptoms will appear.

This is a sign that your datas are not clean and you have to take much older backups for restoring them. In hope that these older backups are not compromised.

Todo for the RD

Watch and test regularly for the next few days. Find out what the best timing is. For the first time you should check every hour. Later you can check 1 or 2 times per day.

Todo for the RM

ALWAYS inform the client about the monitoring and the results.

 

8. Forensic and fix

1. What is hacked and why?

Todo for the RD

2. What can the client do?

Todo for the RM

  • Ask the client to change all the passwords and implement password rules
  • Offer the client to implement two factor authentication
  • Check what security measures are already done and offer the client more from our [Handbook Number 2].
  • At least you could offer the client also a security workshop for his employees.

3. Remove blacklistings Hand warnings

Todo for the RD
Check if the website is already blacklisted somewhere, e.g.:

  • Hoster
  • Google Search Console
  • McAfee SiteAdvisor
  • Yandex Webmaster

Todo for the RM
Inform the client.

9. Reporting

Todo for RM and RD
Make an report for and/or an meeting with the client where you chronologically explain all details of your work