File appears to be malicious or unsafe: site/eanrf.php

Also, My scan was not completed. Getting bellow error.

__________________________

Scan Failed
The scan has failed to start. This is often because the site either cannot make outbound requests or is blocked from connecting to itself. Click here for steps you can try.

Hello @holidaystory17 and thanks for reaching out to us!

That file does appear to be malicious. We will want to get it removed and fix your scan issues.

Can you send a diagnostic report to wftest @ wordfence . com? You can find the link to do so at the top of the Wordfence Tools > Diagnostics page. Then click on “Send Report by Email”. Please add your forum username where indicated and respond here after you have sent it.

Thanks!

Hi,

I have sent the email. Kindly check.

Thanks
Ruma

New error (Note I am using the latest wordpress 5.6)

_____________

Scan Failed
The scan has failed because we were unable to contact the Wordfence servers. Some sites may need adjustments to run scans reliably. Click here for steps you can try.

The error returned was:

The Wordfence scanning servers are currently unavailable. This may be for maintenance or a temporary outage. If this still occurs in an hour, please contact support. [502]

I was not able to locate your diagnostic in our email. You can use the “Export” on the Diagnostic page and then attach it in an email to wftest @ wordfence . com and please put your username as the subject.

Thanks!

Hi

Just sent you the diagnostic file through the mail. Please check

any update?

The good news is that your diagnostic looks good. Were you able to remove that file that was being detected?

Some causes of a hack are impossible for any WordPress security plugin to protect against:
1) If you are using a weak password for your hosting account control panel or FTP account then a hacker may gain entry this way, with full access to your site’s file system and database.
2) You are storing unmaintained, unarchived backups of your site that are publicly accessible that contain exploitable vulnerabilities.
3) You are hosting more than one PHP application, such as more than one installation of WordPress, in the same hosting account and infection can spread from another application to this site.
4) You have unmaintained or vulnerable 3rd party scripts installed in your hosting account. Examples would be the Adminer or SearchReplaceDB database management tools.
5) A nulled theme or plugin with malware already pre-installed. If you paid for a theme or a plugin outside of the vendor’s website at a massively reduced price, that seemed too good to be true, then it is likely to be nulled.
6) If you are using a shared hosting account a neighboring account can be infected and spread the infection to this site.
7) Your WordPress wp-config.php configuration file could be readable to the hacker, either directly via your hosting account, via a vulnerable plugin, or via another hacked site on the same server.
8) The hosting accounts on the server may not be properly isolated so the hacker has access to your database via another user’s database.
9) The server software has vulnerabilities that allow the hacker to get root access – such as running an end-of-life version of PHP on the hosting server that has unpatched vulnerabilities.
10) If the hack took place at a time when you only had the free version of Wordfence installed then you wouldn’t have had access to the latest firewall rules that premium customers have access to.
11) You may be using a plugin or theme with a vulnerability that is so severe that Wordfence can not protect against it and we may be unable to create a custom firewall rule for the vulnerability. However, being unable to create a custom firewall rule is very rare.

Wordfence protects against a vast variety of attacks. Whether you were hacked because of an unknown attack method or because there is some other issue in your system impossible to say at this stage without an extensive investigation. There are some aspects of your site security that are completely beyond our control such as vulnerabilities on your hosting server as described above. Although rare, for examples of hosting provider vulnerabilities please see these two articles below:
https://www.wordfence.com/blog/2019/06/service-vulnerability-four-popular-hosting-companies-fix-nfs-permissions-and-information-disclosure-problems/
https://www.wordfence.com/blog/2018/02/service-vulnerability-nfs-permissions-problem/

that’s gr8..but still, I don’t understand what to do with the infected file,

I recommend doing a back up of your site, then remove the infected file.

Let me know if this works!

Thanks!

Hi

Please note that the scan is still not completed yet today.

__________________

Scan Failed
The current scan looks like it has failed. Its last status update was 5 mins ago. You may continue to wait in case it resumes or stop and restart the scan. Some sites may need adjustments to run scans reliably.

Can you do the following so I can get the information I need to help you?

• Kill the existing scan if it is still running (The “Start New Scan” button turns in to a “Stop” button while the scan is running)
• Go to your Scan > Scan Options and Scheduling page and locate the “Performance Options”
  Set “Maximum execution time for each scan stage” to 20 on the options page
• Click to “Save Changes”
• Go to the Tools > Diagnostics page
• In the “Debugging Options” section check the circle “Enable debugging mode”
• Click to “Save Changes”.
• Start a new scan
• Copy the last 20 lines from the Log (click the “Show Log” link) or so of the activity log once the scan finishes and paste them in the post.

On occasion, this fixes it straight away. That’s because adding 20 for the “Maximum execution time for each scan stage” tells the scan to pause every 20 seconds and start again where it left off. If this fixes the issue and scans run again, you can leave all the settings above except for “Enable Debugging Mode”.

Thanks!

I use custom scan, click both

Note – when I uncheck both options, scan completed but “server state” is yellow.

_________________________

TICK – Scan files outside your WordPress installation
TICK – Scan images, binary, and other files as if they were executable
_____________________________
Scan Failed
The scan has failed to start. This is often because the site either cannot make outbound requests or is blocked from connecting to itself. Click here for steps you can try.

__________________________________________________________

Dec 21 20:24:42] getMaxExecutionTime() returning config value: 20
[Dec 21 20:24:43] Test result of scan start URL fetch: array ( ‘headers’ => Requests_Utility_CaseInsensitiveDictionary::__set_state(array( ‘data’ => array ( ‘date’ => ‘Mon, 21 Dec 2020 14:54:43 GMT’, ‘content-type’ => ‘text/html; charset=UTF-8’, ‘set-cookie’ => ‘__cfduid=d97d412500f72f470b18e04d225ba213e1608562482; expires=Wed, 20-Jan-21 14:54:42 GMT; path=/; domain=.theholidaystory.com; HttpOnly; SameSite=Lax; Secure’, ‘x-robots-tag’ => ‘noindex’, ‘x-content-type-options’ => ‘nosniff’, ‘expires’ => ‘Wed, 11 Jan 1984 05:00:00 GMT’, ‘cache-control’ => ‘no-cache, must-revalidate, max-age=0’, ‘x-frame-options’ => array ( 0 => ‘SAMEORIGIN’, 1 => ‘SAMEORIGIN’, ), ‘referrer-policy’ => array ( 0 => ‘strict-origin-when-cross-origin’, 1 => ‘no-referrer-when-downgrade’, ), ‘x-xss-protection’ => ‘1; mode=block’, ‘strict-transport-security’ => ‘max-age=2592000; includeSubDomains
[Dec 21 20:24:43] Starting cron with normal ajax at URL https://www.theholidaystory.com/wp-admin/admin-ajax.php?action=wordfence_doScan&isFork=1&scanMode=custom&cronKey=417de9eac235d28406b003a64ab19e62&signature=af32b21f64128387ee8486aac4a3cf7c25b0a587503e32e027a2e8465622dd06
[Dec 21 20:24:43] Scan process ended after forking.

Thank you for posting that! I was looking back into your diagnostics and noticed you use Cloudflare.

If your site is protected by Cloudflare, you may need to update your Cloudflare settings to allow your site to connect back to itself. You should be able to do this by going to your Cloudflare control panel.

• Login to Cloudflare
• Go to “Firewall”
• Click the “Firewall Rules” tab
• Click “Create a Firewall rule”
• Name the rule under “Rule Name”
• Set the “Field” under “When incoming requests match…” to “IP Address”
• Enter your site’s IP address under “Value”
• At the bottom, under “Then…Choose an action” change “Block” to “Allow”
• Click “Deploy

Once you have added your site to the Cloudflare Whitelist, head back over to your site and attempt another scan.

Let me know if this helps and if you have any questions!

Thanks!

Hi,

I have created the rule in but again scan failed. And the server state is still yellow.

(Just queries, what the rule is for)

screenshot – https://ibb.co/m82VyPB

__________________

[Dec 22 09:01:31] Entered fork()
[Dec 22 09:01:31] Calling startScan(true)
[Dec 22 09:01:31] Got value from wf config maxExecutionTime: 20
[Dec 22 09:01:31] getMaxExecutionTime() returning config value: 20
[Dec 22 09:01:32] Test result of scan start URL fetch: array ( ‘headers’ => Requests_Utility_CaseInsensitiveDictionary::__set_state(array( ‘data’ => array ( ‘date’ => ‘Tue, 22 Dec 2020 03:31:32 GMT’, ‘content-type’ => ‘text/html; charset=UTF-8’, ‘set-cookie’ => ‘__cfduid=d4c8d4cc916bf3d6c8523aea11891cf371608607891; expires=Thu, 21-Jan-21 03:31:31 GMT; path=/; domain=.theholidaystory.com; HttpOnly; SameSite=Lax; Secure’, ‘x-robots-tag’ => ‘noindex’, ‘x-content-type-options’ => ‘nosniff’, ‘expires’ => ‘Wed, 11 Jan 1984 05:00:00 GMT’, ‘cache-control’ => ‘no-cache, must-revalidate, max-age=0’, ‘x-frame-options’ => array ( 0 => ‘SAMEORIGIN’, 1 => ‘SAMEORIGIN’, ), ‘referrer-policy’ => array ( 0 => ‘strict-origin-when-cross-origin’, 1 => ‘no-referrer-when-downgrade’, ), ‘x-xss-protection’ => ‘1; mode=block’, ‘strict-transport-security’ => ‘max-age=2592000; includeSubDomains
[Dec 22 09:01:32] Starting cron with normal ajax at URL https://www.theholidaystory.com/wp-admin/admin-ajax.php?action=wordfence_doScan&isFork=1&scanMode=custom&cronKey=88c3e4392c8d13dd33b5b17d34345860&signature=a4a9135830b7edb0188e481e4520401e522df6c63e481c1f230af1053f07910d
[Dec 22 09:01:32] Scan process ended after forking.