Malicious code not recognised

Hello, first of all it’s important to understand that the Sucuri WordPress plugin DOES NOT contains a proactive (server-side) malware detection system. This is only provided by our premium services [1]. The plugin is offered as a complementary tool for our paying clients and some of the features can be used for free.

Because I have no access to your web server to conduct a proper investigation, I cannot answer the question “How was the hacker able to inject the backdoor in the first place?” but with the information that you currently have I have some suggestions that could help you track down the infection itself.

1. Search “adelia” across your entire project [2],
2. Search “file-manager” across your entire project [3],
3. Search “business-proposal” across your entire project [4],
4. Search “adelia” across your entire database [5],
5. Search “file-manager” across your entire database [6],
6. Search “business-proposal” across your entire database [7],

Marking as resolved, let me know if you need more information, good luck!

[1] https://sucuri.net/website-security-platform/
[2] grep -rni "adelia" -- ~/public_html/
[3] grep -rni "file-manager" -- ~/public_html/
[4] grep -rni "business-proposal" -- ~/public_html/
[5] SELECT * FROM [table] WHERE [column] LIKE '%adelia%';
[6] SELECT * FROM [table] WHERE [column] LIKE '%file-manager%';
[7] SELECT * FROM [table] WHERE [column] LIKE '%business-proposal%';

[…] the free version […] is meant to demonstrate Sucuri’s capabilities.

As far as I know, this is not true.

Since I took the development of the Sucuri plugin +3 years ago, the code has been written pretty much independently to the other products that Sucuri provides as a subscription (Firewall, Backups, Monitoring, Support). Originally, the plugin was simply a client that allowed the execution of SiteCheck [1] from the commodity of the WordPress admin dashboard. Later, when the Sucuri Firewall was built, I integrated the plugin with the Firewall API to allow the users to change the settings of their Firewall account and monitor their security logs, also from the commodity of their WordPress admin dashboard.

Never during the last +3 years I have been asked to demonstrate the capabilities of our systems nor services through the Sucuri WordPress plugin. This is why I wanted to clarify the purpose of the plugin in my previous comment. The “Server Side Scanner” is a component that is part of the Sucuri Platform, and more specifically, part of the Monitoring system.

The plugin is not connected to the Sucuri Monitoring system, it cannot detect an internal infection, only the effects if — and only if — the infection shows itself in the form of malicious code in the HTML, CSS, JavaScript or HTTP headers. The back-door that is being injected in your website is not part of these categories, that’s why the plugin missed it.

Is the premium version any more likely to find the malicious code if the free version can’t?

Indeed, you can read more about what features are provided by our premium services (Monitoring, Firewall, Backups, Support) visiting this link [2]. Also, feel free to chat with one of my co-workers via the chat available at the bottom-right corner of the Sucuri website.

The site is on a shared server, so I can’t use grep as far as I know.

This is only true in servers owned by very restrictive hosting providers. In the majority of cases, you can execute any Unix command via SSH or even through a script uploaded to your own account. You may need to contact the support team of your hosting provider to confirm the availability of the grep command.

The suggested database queries produce errors: #1064 – You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ‘[table] WHERE [column] LIKE ‘%adelia%&#039’ at line 1

Both [TABLE] and [COLUMN] are examples. Because I don’t have access to your web server, I cannot mention the real names for the tables that you have created in your database, nor the columns in these tables. The rest of the SQL statements are correct, the important part is the LIKE '%[QUERY]%' but you have to modify the rest to make it work in your own database since you are the only one who knows the names of the tables.

[1] https://sitecheck.sucuri.net/
[2] https://sucuri.net/website-security-platform/