Support » Plugin: Sucuri Security - Auditing, Malware Scanner and Security Hardening » added htaccess files not recognized by scan file changes

  • Resolved Jonas Lundman



    I’ve a issue with a hacked site right now. A Backdoor (propably) is creating .htaccess files in my wp-includes directory (and others). Sucuri backend scan -find added, changed .php files and non extension files, etc etc BUT not added .htaccess files.

    Is that a bug or a limited function in free version?

    Thanks for a great plugin, interface and a none-cluttered-backend-layout (!).

Viewing 10 replies - 1 through 10 (of 10 total)
  • Plugin Author Daniel Cid


    Mind pasting the content that is being created on the .htaccess?

    That will help us understand what kind of compromise is going on. As far as the plugin not scanning the .htaccess files, we will check on that.

    *this plugin does not have a paid version. It is all free.


    Hi, Thanks for taking time to support!

    This is saved at the top of the htaccess, or as only content in new created htaccess files by the backdoor.

    <IfModule mod_rewrite.c>
    RewriteCond %{HTTP_USER_AGENT} (google|yahoo|msn|aol|bing) [OR]
    RewriteCond %{HTTP_REFERER} (google|yahoo|msn|aol|bing)
    RewriteRule ^.*$ index.php [L]


    this plugin does not have a paid version. It is all free.

    All links in the plugin settings points to a “pricing plan”, so I assumed there is a “pro” setup for Sucuri.

    / Thanks

    Hi Jonas,

    Checking the code, I see the plugin integrity scanner is ignoring the /wp-includes/.htaccess file.

    The .htaccess redirect you mentioned looks like it could be generated by an SEO plugin trying to protect your site from 404s by redirecting search engine traffic to your homepage. Does that make sense? Regardless, that particular redirect doesn’t look malicious.


    Hi eve

    Thanks for your time and support on this forum.

    The code is generated by a hacked file, no plugin (as default). I have cloned sites (same plugins, install etc etc) on none-hacked servers and this created htaccess only appears on the hacked server account.

    I know 100% for shure it is malicious.

    Sucuri scanner does not work reliable then. It’s a sad conclusion while we really liked this interface. Switching to another solution/ plan B.

    / Intervik Media

    Hi Jonas,

    I understand that the redirect could be malicious. I was just suggesting a legitimate alternative. 🙂

    Regarding the /wp-includes/.htaccess, I have raised the topic of the scanning exclusion with the developer.


    I had the same bad surprise recently, one of the WP site I was asked to manage got horribly hacked. The Sucuri plugin was a boon to clean the WP files, but after a while Google Bot started raising many 404 errors, while the website was perfectly fine on any browser.

    After quite a lot of soul-searching (the Google crawler reportedly didn’t find the homepage!), I found the culprit in the .htaccess. There was an added redirection looking exactly like Jonas’ that redirected all major search engine crawlers to a malicious page that didn’t exist anymore on the server thanks to Sucuri.

    Please add the .htaccess file to the file integrity checker to an otherwise awesome plugin!


    • This reply was modified 3 years, 1 month ago by Hypolite.
    Plugin Author Daniel Cid


    Noted. We will get it added.


    Would like to hear an update on this issue. This is what I can tell so far that this attack is trying to do:

    The .htaccess code mentioned redirects all referral traffic from search engines to the rewritten index.php. It does this in as many subfolders as possible, so if you get the files in the root, there’s still a few more lurking.
    The malicious code injected into index.php in turn redirects the traffic to any number of sites, some annoying, some embarrassingly pornographic. if you browse to the site directly it seems like nothing is wrong, but once you try to reach the site via search, then you see the issue.
    The malicious files/code reappear shortly after deleting them.
    I think this action coincides with some entries in the Audit logs showing as coming from “system” aka 127.0.01. Looks a little something like:

    File modified: (multiple entries):
    .htaccess (old size: 12550; new size: 12340)
    wp-content/.htaccess (old size: 412; new size: 414)

    Desperately hoping for a solution. Been spending the last couple of days doing damage control.

    The code that you found in your access control file is in fact malicious and — as a coworker mentioned above — our plugin ignores the existence of the “wp-includes/.htaccess” file as well as other files that we consider irrelevant; you can see the complete list here [2].

    Please do not rely entirely in our plugin for the security of your website. The plugin is a security suite meant to complement your existing security posture. It is expected that you have a system besides or above (like a firewall) to prevent the wide range of attacks that your website might suffer.

    Also notice, even if we remove the exception and start flagging the existence of the “wp-includes/.htaccess” file, the plugin will not read its content, so it will never know if the file is infected or not. This is why it is being ignored, to prevent false/positives when it is clean. You will notice in the code that I linked below that a malicious user can also hide from the WordPress Integrity Checks by writing malware into a “503.php” file, or “404.php”, or “500.php” or even “wp-config.php” because the plugin ignores them all.

    A solution to this problem is to pay close attention to the “Audit Logs”. As @scocknation mentioned if a malicious user is able to create/write/update a “.htaccess” or any of the files ignored by the core integrity tool, the modifications will still appear in the audit logs. Be sure to check that section if you suspect of a new attack.


    I have modified the code that ignores these files during the execution of the core integrity checks. From now on the plugin will ignore just a handful of files that we consider to be really irrelevant, the rest of the files that are in the list will be added (on startup) to a cache file, the website owner can delete one or more of these files from the cache and force the plugin to monitor them. There will be a panel in the scanner section of the settings page called “Core Integrity Checks – Marked As Fixed”.

    For this specific ticket, you can go to this section and delete the “wp-includes/.htaccess” file from the cache. The next time the core integrity checks are executed the plugin will not ignore the changes in this file.

    This was implemented with commit #9da5253 [1].


Viewing 10 replies - 1 through 10 (of 10 total)
  • The topic ‘added htaccess files not recognized by scan file changes’ is closed to new replies.