Database changes detected

Did you check this discussion, you may have a similar issue:
https://www.ads-software.com/support/topic/sql-injection-passes-through-firewall/

Change your database password ASAP, and make sure the DB is not remotely accessible. If there’s nothing in your logs, it’s likely that they access the DB directly. If you have other sites installed on this account, they could access the DB from them.

Thanks for the advice. I checked and it looks like the database cannot be accessed remotely. The hosting is on VPS with WHM/cPanel. There are other sites hosted in the same server but in their own cPanel accounts. I believe cPanel has their own jailed environment to isolate the different accounts. The site having this issue is on its own account an no other sites are sharing the same cPanel account. Other than the database change mentioned earlier, scans didn’t find anything and the site looks ok.

The client does have access to the cPanel account but I am not sure if that may contribute to the issue since the database can only be accessed via localhost.

I’ve updated the salt keys and also changed the DB password. Will monitor to see if any issues.

Check if you can access the /home/[username]/.lastlogin file, it will show you the last connections to your [username] cPanel account. Changing its login password would be a good idea.

Have you been hacked lately, before you installed NinjaFirewall?

Have you been hacked lately, before you installed NinjaFirewall

Nope, this is the first. The site was deployed with Ninjafirewall from a fresh install so I believe its protected from the start.

I was able to access the .lastlogin file. There are only 5 lines in there and the IPs belong to mine and the client.

Anyway, the issue just repeated again. The database password got changed which was detected by Ninjafirewall. And this time there was also a malicious file in the root folder named uploads.php. The site turned into a file manager / webshell when I visited it.

So I had to move out all the files from the root folder and reuploaded a clean set of files, then repeated the change of database passwords, salt etc. This time round I also changed the cpanel password.

When I looked through Ninjafirewall logs, I didn’t notice any UPLOAD event. However when I checked the website access logs, I noticed POST requests to the login page and theme-editor.php file.

I’m still not sure how the password got changed and the malicious files got into the server. My guess is maybe they got access to the FTP using the cPanel password, or plugin issue, or somehow managed to bypass the firewall (unlikely I feel).

For now I’ve ensured all plugins and core is updated. I’ve set DISABLE_FILE_MODS to true in wp-config. And in Ninjafirewall, I’ve also enabled the option to block POST requests in theme folder. Let’s see how it goes.

Aside to this, we have another site hacked on the same VPS server but in another cPanel. Not sure if this is linked.

That doesn’t look good. They were able to log in.

How many admin users do you have? Did you change all their passwords since last hack (you only mentioned DB password and salt keys)? Is their contact email address correct? Check also email forwarding in cPanel, often hackers add their email address to that section to receive password reset notification.

How about the contact email from the “Settings > General” page?

Make sure to run the firewall in “Full WAF” mode and enable both “File Check” and “File Guard” in the monitoring section.

• This reply was modified 4 years, 6 months ago by nintechnet.

Thanks for the quick responses. We have 3 admin users (2 used by developers, 1 used by client) and 1 editor account. I didn’t change all their passwords for the previous hack. But the 2nd round I changed for all the accounts. The contact email address for all the admin accounts are correct. The contact email in Settings > General page is correct too.

I have turned on Full WAF and also enabled File Check + File Guard. I’ve also enabled all the options in “Block direct access to any PHP file located in one of these directories”.

We will be migrating the site to a new server tonight after doing offline scans and checks.

My main concern is still regarding the allowing of users to upload files from the contact form. Could that be the entry point?

Some other info:

Wordpress is latest 5.5 now. Before the hack it was 5.4.2.

Here are the plugins used:

Advanced Custom Fields 5.9.0
DynamicConditions 1.4.6
Ele Custom Skin 3.0.0
Elementor 2.9.14
Elementor Pro 2.10.3
Google Tag Manager for WordPress 1.11.4
Make Column Clickable Elementor 1.3.1
NinjaFirewall (WP Edition) 4.2.4
NinjaScanner 2.0.7
Radio Buttons for Taxonomies 2.0.5
Yoast Duplicate Post 3.2.5
Yoast SEO 14.8.1

I’ve checked these plugins inside the https://wpvulndb.com/ and versions seem to look ok.

Make sure your contact form uses a whitelist of allowed files, user shouldn’t be allowed to upload PHP scripts, system files etc.
In Full WAF mode, if someone uploaded a PHP scripts and accessed it, it would trigger an alert from the “File Guard” feature.

I am reposting this as the previous post doesn’t seem to go through. Please remove the previous post if necessary.

I got a few triggers from NinjaFirewall’s File Guard detection from an IP address in Ukraine.

Nothing else happened. No database changes detected. New server is using nginx and we have implemented some blacklist and whitelist rules. Here are some info – https://pastebin.com/raw/wZ9PYqkV

Seems like they are trying to exploit a plugin vulnerability?

This line looks strange. That particular access came from an Amazon AWS IP.

"GET /submit/?elementor-preview=156&ver=

It is an attempt to preview a post created by Elementor, but it should fail if the user isn’t allow to edit it:
https://plugins.trac.www.ads-software.com/browser/elementor/tags/3.0.2/includes/preview.php#L171

Thank you @nintechnet

We are still monitoring the site on our new server. It seems that our previous server had all the WordPress sites hacked. We see malicious php.ini files which enabled shell_exec and turned off disable_functions.

I guess the old server was not hardened by the previous sysadmin as we can see cPanel security advisor reported quite a few serious issues. When checked thoroughly, the remote mysql was actually enabled. We have disabled it now. It’s going to be a long week ahead to try and restore this.

We plan to install NinjaFirewall for all the sites using wp-cli. But the default install requires us to manually activate Full WAF mode. Is there a way to do this via the wp-cli? If we could enable the full WAF mode and apply an exported configuration with wp-cli would be good.

It’s not possible yet because WP CLI uses the PHP command line interpreter and it doesn’t populate some $_SERVER variables, unlike the PHP web interpreter.
We’re working on it but I’m not sure if that will be possible or not.

Thank you. I guess we will install and setup invidually per site. It seems to be doing OK for now so we will continue monitoring and mark this as resolved.