Operational design to reduce reinfection rate after WordPress malware removal

We will explain the operational design to reduce the reinfection rate after WordPress malware removal.

Causes of WordPress Hacking

The chart below shows the causes of WordPress hacking as researched by WordFence.
No. 1 Plugin vulnerability
No. 2 Brute force (brute force password cracking of admin rights)
No. 3 Core file vulnerability
No. 4 Theme vulnerability
5th Hosting server vulnerability

https://www.wordfence.com/blog/2016/03/attackers-gain-access-wordpress-sites/

In our experience, if you take care of 1, 2, and even 3, you can almost prevent WordPress from being hacked, although it is not 100%.

Operational design to prevent plugin vulnerabilities from being used in attacks

Hackers will target vulnerabilities that are deployed on more sites and that allow them to more easily modify files on the server.
(There are tools available to exploit one well-known vulnerability after another, and they use them to attack random sites.)

For this reason, it is ideal to keep all plug-ins up-to-date.
However, since plug-ins often cause site malfunctions when updated, we recommend the following operational policy as a minimum measure.

– Remove unused plug-ins from the server (not by deactivating them, but by deleting the programs in the plug-ins’ folders). Use only the most selective plug-ins possible.

– Check the site once a month for plugin vulnerabilities.

– If vulnerabilities are found, update the plug-ins as soon as possible.

– Once a year or so, we update the plugins and the entire WordPress site in a test environment, check that they are working properly, and then adapt them to the production environment.

Plugin vulnerabilities that are constantly being updated can be checked with the [Free] WordPress: Malware Scan & Security Plugin [Malware and Virus Detection and Removal].

Operational design to prevent brute force (password cracking of administrative privileges by brute force)

The countermeasure here is very simple. All you need to do is to make the password for the WordPress administrator privileges strong enough to satisfy the following rules.

– Use a password of at least 12 characters that contains at least one upper-case lower-case alphanumeric character and at least one lower-case symbol, and that has no meaning.

Such a password cannot be breached by a brute force attack because, in principle, it would take more than 12 million years to break such a password in a brute force attack.

Operational Design to Prevent Core File Vulnerability Attacks

Although serious vulnerabilities in WordPress core files are very rarely discovered, abandoned sites may use very old WordPress (WordPress version 3 or 4 units), which can be used for hacking.

WordPress comes with an automatic minor version upgrade mechanism.

WordPress 3.7 introduces “Automatic Background Updates” functionality.

Therefore, it is important not to stop this feature.

// Disable automatic updates *Do not write such a setting
define( 'AUTOMATIC_UPDATER_DISABLED', true );

We also recommend that you update the core WordPress files at least once a year or so in a test environment to ensure that they are working properly before adapting them to the production environment.

Do the same for all sites on the server.

Malware nowadays often spreads its infection beyond individual domain folders on the server.
For this reason, it is important that the above measures be taken for all sites on the server.

If there are unused and abandoned sites on the server, we recommend that you delete the entire site folder.