WordPress.org

Ready to get started?Download WordPress

Forums

BulletProof Security
[resolved] BPS File Targeted and Hacked (21 posts)

  1. BrattDev
    Member
    Posted 2 years ago #

    I installed the Bulletproof plugin a few weeks ago after a wave of hacking by the "Kurdish Sniper Team" (fun). Everything was quiet for those two weeks but yesterday, the hackers hit one of our WordPress sites which had BPS, Login Limit, and File Monitor installed and fully activated. They hit two files -- index.php (the main page) and the plugin file bulletproof-security.php. So they were specifically targeting this plugin. The hackers managed to login to WordPress and disable the plugin.

    So disappointing! A few questions -- has anyone else experienced this? Is an immediate fix in the works? If not, is there a better alternative to this plugin that we could use instead?

    And finally, if the plugin developer needs to see the bulletproof-security.php file so they can see what the hackers left us, I can get that to you.

    Thanks for any info or advice on how to prevent future hacks -- we'd really appreciate it. Also, potential users -- know that, at least for now, BPS will not protect you from this particular flavor of hack.

    http://wordpress.org/extend/plugins/bulletproof-security/

  2. BrattDev
    Member
    Posted 2 years ago #

    Another site was hacked today by hackers calling themselves FBI.

    They also hacked the bulletproof-security.php file in the plugin's folder and added a text file called fbi.txt at the root level.

    Help! Do I need to deactivate BPS everywhere now? This is really a problem.

    thanks!

  3. AITpro
    Member
    Plugin Author

    Posted 2 years ago #

    Hate to tell you this, but there is nothing that can protect your websites if someone has stolen or hacked your passwords. BPS and other website security plugins are designed to protect against external attacks like RFI, Code injection, SQL Injection, XSS, etc. by blocking the hackers code from being successful. WordPress protects your website with authentication. If authentication is compromised then you don't have any security at all and there is nothing that can protect your sites. And i really hate to tell you this. There is no point in trying to salvage a website that a hacker has been able to log into. If the hacker is smart he put in 100's of backdoor scripts to allow access anytime they want without having to log in via WordPress, which also brings up another point. If you have an unpatched version of Timthumb then a hacker can upload his own login shell and does not need to use the WordPress login to login into your website.

    A good analogy is if you have a top of the line car alarm, but you left the keys to your car in the ignition with the doors unlocked then the car alarm cannot protect your car and will benefit the criminals by boosting up the selling price of your stolen car to a chop shop.

    My sites get attacked by these 2 same groups on a daily basis as well as 100's of other random hacking attempts per day. Creating a website security plugin obviously makes you a target. ;) I don't mind at all because i now have a huge collection of hacker scripts to play around with. BPS Pro logs and tracks them so i just follow the yellow brick road back to the hackers websites and the originating script path and download the hackers scripts to play around with. I have collected many timthumb exploit scripts that allow hackers to upload files, modify files, login via shells and do anything else that they want to do with your website.

    Ok back to the point. You need to isolate how they got in. The first thing to check is for timthumb exploits. This is the most common hacking attempt i am seeing on my sites on a massive scale. Then they could have hacked into your web host's server and stolen your password, they could have stolen your passwords from a file that is stored pubicly, they could have intercepted an email that contained your passwords, etc etc etc. You need to notify your web host in any case. If they have a vulnerability on their servers that can be exploited then they need to be informed about it so they can fix it. They can also assist you in finding the entry point on your sites. Thanks.

    Note: BPS Pro 5.0 does not have logging and tracking. BPS Pro 5.1 will be released in 4-10 days and does have logging and tracking.

  4. BrattDev
    Member
    Posted 2 years ago #

    Hi and thanks for getting back to me.

    What threw me was that hacking incidents had been few and far between in the past few years (we keep our WP and plugin software up to date) but after installing BPS, we had two sites hacked in less than a couple days (about 2 weeks later) and in both cases, the hackers specifically hacked the bulletproof-security.php file and then left one other calling card.

    In other words, they appeared to be targeting the BPS plugin.

    I don't see how the WordPress login could be compromised since I would never store that kind of information on the server. The sites hacked were so insignificant that I can't believe any hacker would be interested in them. It isn't every site on the server, just two out of maybe 20. Weird.

    I'll report this to our hosting people and see if they have any insights and look into "timthumb exploits" which I've never heard of. I'll also keep an eye on the other 30 WP sites we maintain, which all have BPS on them now.

  5. AITpro
    Member
    Plugin Author

    Posted 2 years ago #

    It seems to me that hacking the bulletproof-security.php file was done to intentionally send you a message like "gotcha". I have never had a hacker specifically targeting the bulletproof-security.php file on any of my sites. There is nothing of any real importance happening in that file and to hack it would give the hacker away so at least you are not dealing with high level hackers. The low level hackers want to show off. The high level hackers do not want you to know your site has been hacked - they are professionals focused on making money.

    The timthumb exploit thing has been going on for at least a few months now. I estimate that a minimum of 100,000 websites have been hacked that did not patch or download the new timthumb.php script. When you Google this you will find lots of info on it. BPS is currently allowing thumbnailer scripts to display images. This unfortunately allows an unpatched or older version of timthumb.php to be hacked. For testing purposes i have several testing sites that do have the old timthumb.php script on them. On a testing site that BPS is blocking the old script - 2 things occur - the thumbnail images do not display and the hackers are unable to exploit the timthumb script. On a testing site where BPS is not blocking the old script - 2 things occur - the thumbnail images are displayed and the site is successfully hacked on an average of about once per hour. I am sent a notification each time that that site is successfully hacked so that i can restore it to an unhacked state - reset the trap again. ;)
    Obviously if you want thumbnail images to be displayed then the solution is to get the new patched version of timthumb.php. I have tested it extensively and have not found any exploits in the new timthumb.php script.

    Not all of your sites on the Server were hacked. This is a very good thing because it means that the Host server was not hacked / compromised.
    Not all of your sites with BPS installed have been hacked so it is not an issue or vulnerability in BPS itself.
    It appears that the hackers have not compromised your WordPress Database and only have the capability to upload, modify, create, edit and / or inject code into files - this is a classic timthumb.php exploit pattern capability and typically indicates that the hackers have successfully uploaded a Shell script to your website using RFI. A shell script allows them to do anything they want on your website. It is basically a WP Dashboard on steroids and allows them to do even more than you can do with your WP Dashboard. Google "AluCar Shell".

    My gut is telling me that since you were not aware of the timthumb.php exploit, i log about 200-250 timthumb exploit attack attempts per day on my main and blog sites and my "hackable" testing site that uses the old exploitable timthumb.php script with BPS allowing this hack gets hacked about once per hour then most likely this is how your sites were hacked.

    Search all your sites for these files - timthumb.php, thumb.php, thumbs.php and phpthumb.php. If you find this file on any of your sites then make sure it is the new patched version of the script.

    If you are not sure if the timthumb.php file / script is the new patched version then replace this code in the root .htaccess file until you find out for sure...

    # TimThumb and all other Thumbnailer Images not displaying - Red X instead of Images
    # If your theme uses an image thumbnailer script file this fix will work to display images correctly
    # as long as thumb is part of the file name like timthumb.php, thumb.php, thumbs.php or phpthumb.php
    RewriteCond %{REQUEST_FILENAME} ^(.*)thumb(.*)$ [NC]
    RewriteRule ^(.*)$ - [S=30]

    ...with this code. This code is a snippet of the new root .htaccess code that will be releasd in BPS .46.5 - expected release date is 11-20.

    # ALLOW THUMBNAILER SCRIPTS TO DISPLAY IMAGES
    # To forbid allowing requests for these file names replace [S=1] with [F,L]
    # If you delete or remove the RewriteRule below you will need to change the above skip rules
    # Example: RewriteRule S=2 above will need to be changed to S=1, change S=3 to S=2, etc.
    # If you forbid requesting of these files your thumbnail images will not be displayed if you are
    # using the timthumb.php or one of the other image thumbnailer scripts listed below.
    # It is fine to allow these files to be requested as long as they are the security patched versions.
    RewriteCond %{REQUEST_FILENAME} thumb.php [NC,OR]
    RewriteCond %{REQUEST_FILENAME} thumbs.php [NC,OR]
    RewriteCond %{REQUEST_FILENAME} timthumb.php [NC,OR]
    RewriteCond %{REQUEST_FILENAME} phpthumb.php [NC]
    RewriteRule . - [F,L]

    Let me know how it all turns out. If this is something new then i would be very interested in collecting the data / method, but most likely it is just a standard timthumb.php hack.

    Thanks.

  6. MickeyRoush
    Member
    Posted 2 years ago #

    First I'm not trying to hack this thread, but offer a suggestion(s). I'm pretty sure you'll be able to improve on them, but just a suggestion.

    # as long as thumb is part of the file name like timthumb.php, thumb.php, thumbs.php or phpthumb.php
    RewriteCond %{REQUEST_FILENAME} ^(.*)thumb(.*)$ [NC]
    RewriteRule ^(.*)$ - [S=30]

    Make this a bit more specific as the above will cause the rules to skip ([S=30]) the thumbs.db hack:

    RewriteCond %{REQUEST_FILENAME} ^(tim|php)?thumb(s)?\.php$ [NC]
    RewriteRule ^(.*)$ - [S=30]

    Instead if you want to really get deep into stopping (not skipping [S=30]) malicious fingerprinting of the timthumb and variants, how about this?

    # Forbid fingerprinting variants of timthumb and thumbs.db
    # (with or without tim or php prefixes, s (plural), various php and db extensions, or infected theme cache directory files)
    RewriteCond %{REQUEST_FILENAME} ^(tim|php)?thumb(s)?\.(php[2-5]?|db)$ [NC,OR]
    RewriteCond %{REQUEST_FILENAME} /wp-content/themes/.+/cache/[a-f0-9]+\.php[2-5]?$ [NC]
    RewriteRule .* - [F]

    ----------------------------------------------------
    And what about doing something to stop people from fingerprinting your plugin?

    How about adding a line like so:

    RewriteCond %{REQUEST_FILENAME} ^bulletproof-security\.php$ [NC]
    RewriteRule .* - [F]

    Not sure if using a RewriteCond or just using a straight RewriteRule above would be better, you'd have to test.

    Or better yet, putting some allow,deny directives in an .htaccess in the plugin directory itself.

  7. AITpro
    Member
    Plugin Author

    Posted 2 years ago #

    Very good input Mickey. :)

    Major changes have been made in the upcoming release of BPS .46.5. One of those changes is dealing with thumbnailer scripts. Yep the old timthumb is rule is way too general. The new rules specify the exact thumbnailer script filename and gives people the option to allow or deny thumbnailer script requests on their site. I have gone through the new timthumb script and it looks safe to use. Personally i would never use a thumbnailer script on any of my sites because of the potentially dangerous actions that it performs. It is throwing hackers a bone and i don't like giving them an inch. ;)

    Regarding fingerprinting. Currently if you try to access or request bulletproof-security.php on my sites you get a 500 Internal Server Error. I've got BPS Pro 5.1 installed though. I am pretty sure that .46.5 will also generate a 500 error, but i am not currently working in that area yet.

    I have done all kinds of testing with fingerprinting and here is what i ended up with. You can't make the page return a 403 because that tells a hacker that BPS exists. if someone is allowing php errors to display then it will display a php error message and show that BPS exists. The ideal solution is to make the page die quietly i guess, but that also fingerprints that BPS exists. To make a long story short i found that trying to add fingerprinting blockers or prevention always ended up at the same place. The best solution is a 500 Internal Server error because their is no point in trying to hide the BPS fingerprint. I was also looking at adding fingerprinting WP version protection, but i came to the same conclusion. A hiding approach in general is not really a good or effective security approach. Besides surface HTTP stuff going on there is a lot of Perl, Python, etc recon going on so hiding does not really work. Displaying PHP errors to the world is of course different because it gives away the exact folder path for your site making the target pinpointed. So people need to create their own custom php.ini files as a standard security measure. Most hacking is automated, but if someone wanted to manually go after a particular site then the Document root path is not a good thing to expose. That is a php.ini thing so it does not relate to BPS Free only Pro.

    Any way the new root .htaccess file for .46.5 is a beast! :)
    thanks for the great input! ;)

  8. MickeyRoush
    Member
    Posted 2 years ago #

    hmmm....

    You can't make the page return a 403 because that tells a hacker that BPS exists.

    How about using [G] (Gone) instead of [F] (Forbidden)?

    RewriteRule .* - [G]

    Or just send them back to the home page:

    RewriteCond %{REQUEST_FILENAME} ^bulletproof-security\.php$ [NC]
    RewriteRule .* http://example.com [L]

  9. AITpro
    Member
    Plugin Author

    Posted 2 years ago #

    Well it's kind of the same difference. The HTTP Status code is 410 instead of 403. The ideal scenario would be to mimic that the page does not exist at all. I will tinker with this down the road. Currently i get a fair amount of people trying to look at the bulletproof-security.php file on several of my sites, but they are not successful since it bounces them with a 500. Thanks.

  10. AITpro
    Member
    Plugin Author

    Posted 2 years ago #

    And actually I made a major bad statement to BrattDev. If the hackers are using a Shell like C99, r57 or AluCar then they have full access to your DB and stored data as well as full access to anything else stored in your folders.

    It appears that the hackers have not compromised your WordPress Database and only have the capability to upload, modify, create, edit and / or inject code into files - this is a classic timthumb.php exploit pattern capability and typically indicates that the hackers have successfully uploaded a Shell script to your website using RFI. A shell script allows them to do anything they want on your website. It is basically a WP Dashboard on steroids and allows them to do even more than you can do with your WP Dashboard. Google "AluCar Shell".

  11. BrattDev
    Member
    Posted 2 years ago #

    Thanks for all the info. I did a complete search of the hacked sites and unfortunately, there is no timthumb.php script on either one (I searched all variant file names too). We do have a couple sites that use that script -- one was hacked months ago after the client went crazy with dicey plugins. The other has not been hacked, and I'll contact the plugin developer to make sure the timthumb.php script has been patched.

    But that leaves me more or less where I was. I don't know how they got in so I can't plug the hole (yet). I have a positive feeling about BPS but I really hate that hackers are motivated to hack it.

    Here's what I think I'm going to do -- see what you think. I will change the main server password again. I will check the logs on both sites and see if there's any hints. Reading log files isn't my strong suit but I should be able to see something will report back if I find anything fishy. My server people should be able to help with this too.

    So we'll see what we can find out and let you know. I won't sleep until this is resolved, or at least, not well.

  12. BrattDev
    Member
    Posted 2 years ago #

    Ok, I found the hack in the access logs (or at least I'm pretty sure I did). The time corresponds to the time the bulletproof-security.php file was altered. I'm happy to send you a copy, AITPro, if you want to see it. They hit wp-admin/login.php a bunch of times, then got a bunch of plugin files including and esp BPS. I'm not qualified to judge how they managed to do this or what exactly they did but they left a lengthy trail over the 10 or 11 minutes it took them to hack the site.

    Would you mind if I emailed the log excerpt to you for your expert opinion?

    thanks again.

  13. AITpro
    Member
    Plugin Author

    Posted 2 years ago #

    Well I think that it is ok if hackers were to go after BPS files directly, but I am not seeing that many "hacking" attempts directed at BPS files directly on any of my lives sites, client sites or any test sites. I do occaisonally see some amateurish attempts at accessing the BPS files directly from a browser, but not very many and they appear to be just random exploration attempts. And no real professional hacking attempts so far. I think what happened in your case is the hacker just did a "in your face" to you. Hacking the bulletproof-security.php file only serves one purpose - to let you know that your site has been hacked. Like i said the pro hackers do not do this. They don't want you to know that they own your website.

    Your site has been fully compromised so unless you are a professional coder and security expert then there is no point in trying to salvage the current site. The learning curve on a website salvage mission is huge so do not even bother wasting your time trying. ;)

    So...

    The first thing you need to do is search your entire site for any and all .htaccess files. You should only find a root and wp-admin .htaccess file on your site. Check the BPS .htaccess files and make sure that no additional .htaccess code has not been added to them. If you find other .htaccess files then download them, take a look at them and if they are not .htaccess files that you created then delete them from your website.

    Then put your site in Maintenance Mode - this allows only your current IP address to gain access to your site - PERIOD - Even if they have installed a Shell, which most likely they have. Maintenance Mode adds an .htaccess file in your website root folder that allows only your current IP address to access your site. If for some reason you cannot log back in via your WP login then you will have to manually FTP to this file or use your host CP to edit this file. Example: if your current IP address changes to a new IP address while you are doing what you need to do next.

    Then change all of your passwords - Host account, FTP, WordPress DB (in your host control panel phpMyadmin and also in the wp-config.php file) and your WordPress Dashboard admin login passwords.

    Make a zip backup of your entire site. Xcloner does this very nicely and quickly and backs up both your files and DB. Download the Xcloner zip backup file to your computer.

    Now you will need to restore your site from a known good backup that has not been hacked. You will also need to restore your WP database from a known good backup that has not been hacked. Your restored site may or may not have any security yet so you should add security ASAP immediately after restoring the site. You could also just put the restored site in Maintenance Mode until you are sure it is locked down securely.

    The only data that you want to import back into your restored WP DB is any newer post content that a backup does not have. Or you can always do a manual copy and paste directly from your existing site if you do not have much new content / posts to your restored site. And if you want to add any additional files back to your restored site then check the coding in them before uploading to your restored site.

    Now you want to monitor your restored site very closely for at least a couple of weeks. If the site is hacked again then you need to know within a 1 hour window of exactly when the hack occurred. This will make checking your Server log or any intruder logs that you have in place very simple. You will see the Origin, Method and Destination.

    Thanks,
    Ed

  14. AITpro
    Member
    Plugin Author

    Posted 2 years ago #

    Yep sure send me the log file. edward[at]ait-pro[dot]com

    They hit wp-admin/login.php a bunch of times, then got a bunch of plugin files including and esp BPS.

    hmm going after login.php usually indicates a brute force attack to guess a password. If you are using the default WP "admin" user account then delete that account as well as changing your admin account passwords.

    And like i said there is no point in trying to salvage the current site, but knowing how they got in is very helpful. ;)
    Thanks,
    Ed

  15. AITpro
    Member
    Plugin Author

    Posted 2 years ago #

    The log file you sent me does not conclusively tell me the method of attack, but the IP address -- 109.127.86.107 in your log files is a known bad IP address used in Dictionary Attacks >>> http://projecthoneypot.net/ip_109.127.86.107 and is also blacklisted on several other monitoring sites.

    All the clues you have given me point to a brute force dictionary attack used to crack your WP admin password. If the default WordPress user account "admin" is in use a password can be cracked in anywhere from 3 minutes to 1 year. There are several free password cracking tools on the Internet that can do this.

    You should not assume that this was how the hack was definitely done, but you need to make sure that this is not a possibility by deleting the default "admin" account and creating ONLY unique obscure usernames for any admin accounts and only very complex secure passwords using lots of random characters like !#@* etc. An example of a secure password that would take a very, very long time to crack would be this >>> pV!*b04#z!Rs@!Xp

    I have clients that bitch and moan about having to use obscure and complex usernames and passwords. I do a live demonstration for them and show them how quickly i can crack the username and password that they wanted to use. Then they fully understand that convenience should never take priority over security. ;)

    Thanks,
    Ed

  16. AITpro
    Member
    Plugin Author

    Posted 2 years ago #

    Also i want to point this out >>> when you create an Admin account you want to make sure that "Display name publicly as" is not the same as the user account name. Otherwise the username is displayed publicly under comments, posts, etc and is the same thing as using the WP default username "admin". You give the hackers a huge starting point and they can then just run their automated dictionary cracking program until the password is eventually cracked. ;) Passwords should be changed a minimum of every 30 days.

    Thanks,
    Ed

  17. AITpro
    Member
    Plugin Author

    Posted 2 years ago #

    Also currently BPS is recommending the standard WordPress file and folder permissions. This will change in .46.5. If your web host allows 705 folder permissions then your should change folder permissions from 755 to 705. I have tested this extensively and WordPress is not breaking nor are any plugins breaking. There are more and more hackers exploiting Group Permissions to inject code so Group Permissions should not be on checked or allowed.

    All of these folder and file permission recommendations work fine on GoDaddy hosting, but they may not work on other web hosts. There are many different factors involved with how each web host handles files, php, etc like DSO, mod_php, suPHP, suExec, etc so give them a try and if stuff breaks then revert back to the WP standard permissions recommendations.

    X means unchecked or off or not allowed
    On means checked or on or allowed

    705 Folder Permissions
    Owner Permissions - Read On - Write On - Execute On
    Group Permissions - Read X - Write X - Execute X
    Public Permissions - Read On - Write X - Execute On

    604 File Permissions
    If your web host allows this then 604 permissions are recommended
    Owner Permissions - Read On - Write On - Execute X
    Group Permissions - Read X - Write X - Execute X
    Public Permissions - Read On - Write X - Execute X

    Mission Critical Files that should be locked down. These files below are targeted for code injection and if your host server is compromised and if these files have 644 permissions then a code injection hack will be successful. These file permissions will cause conflicts if editing of any of these files is needed from within WP or by a plugin and the permissions will need to be manually temporarily changed when necessary. Normal operation of WordPress works fine with these file permission settings.

    root .htaccess - 404 - BPS will not be able to edit or write to the root .htaccess file with the built-in File Editor.
    root index.php - 400
    root wp-config.php - 400 -
    root wp-blog-header.php - 400

    404 File Permissions
    Owner Permissions - Read On - Write X - Execute X
    Group Permissions - Read X - Write X - Execute X
    Public Permissions - Read On - Write X - Execute X

    400 File Permissions
    Owner Permissions - Read On - Write X - Execute X
    Group Permissions - Read X - Write X - Execute X
    Public Permissions - Read X - Write X - Execute X

    Thanks

  18. BrattDev
    Member
    Posted 2 years ago #

    Thanks for all the information. I'm going to work my way through it and will let you know how we do. We have had to recover from a couple hacks in the past and were able to do so by cleaning up the db, replacing all WP files, and obviously changing passwords and usernames too in some cases. Since the sites haven't been hacked since, we feel ok.

    We will be monitoring more closely from now on, and have File Monitor installed to help us do that. The login limit plugin should help too. Both were enabled on these sites but I need to make the File Monitor plugin scan more frequently for changes to server files. My feeling is that the hack may have already occurred just before we installed the anti-hacking plugins and so further more obvious hacking was able to take place afterward.

    Again, I really appreciate your help and feedback on this and will let you know if there are any further attacks once we've taken more precautions.

    One thing this year has taught me is that WordPress out of the box is not nearly as secure as we had thought. I've worked with the "hardening WordPress" post and feel that some of this stuff should be incorporated into standard installation instructions. With the case of the Limit Login feature, I honestly think that should be built in to the core software at this point.

  19. AITpro
    Member
    Plugin Author

    Posted 2 years ago #

    My pleasure. ;)

    Well WordPress is pretty darn secure right out of the box, but yep there are a couple of ways someone can shoot themselves in the foot if they are not very familiar with "hardening WordPress" and using general "best practices for securing a website". ;)

    The new BPS .46.5 root .htaccess file incorporates the wp-admin folder forbidden rule that the WP guys put together under "hardening WordPress". And it contains a massive amount of new thoroughly tested Exploit filters.

    Having a secure .htaccess file is not enough website security protection in my opinion. You also need to add a very restrictive custom php.ini file for your website, lock down your files and add additional security monitoring, logging and tracking.

    Thanks.

  20. Heiner
    Member
    Posted 1 year ago #

    AITpro, thank you for the information. My site had an attack which left some malware in my index.php, home.php etc. I noticed it as "they" kept modifying my htaccess to produce a 500. I re-installed WordPress and most of the plugins from the original source files and cleaned out my theme manually. The attacks did not stop so I installed BPS. This went well for a while until I moved servers. I must have "woken up" something as the attacks started again in spite of BPS installed. The funny thing was the site went down each time I let http://sucuri.net perform a test. Strangely enough the site stayed up when I set the root htaccess to WordPress standard and Sucuri said the site was clean. After reading the above texts I deleted BPS and re-installed it from scratch. Now I could test with sucuri and the site was certified clean. I then modified the permissions on index.php etc. according to your suggestions. This was yesterday and the site is still up.

  21. AITpro
    Member
    Plugin Author

    Posted 1 year ago #

    Depending on which hacker or hacker group has hacked your website you will have varying levels of disaster recovery to do. If your site gets hacked by a "defacer" hacking group then you will have minimal things to clean up and a restore of your website is usually not necessary. Unfortunately, the majority of hacker groups will ensure that even if you remove the hacker code that you can find then most likely you will not find all the backdoor scripts that they have uploaded to your website, which means they still have full control of your website and can do anything they want anytime they want to your website.

    This was yesterday and the site is still up.

    If you are very lucky then you got all the hackers code already, if not...

    BPS is designed to keep hackers out, but if they have already hacked your website and already have their files inside your website then there is very little BPS can do because they are already past the BPS defenses.

    If you have a good backup of your files and your WordPress Database i recommend that you restore your website from backup. If you do not have a good backup then you should download all your website files and download your WP database, then delete all your files and delete your old database, then re-install a new WordPress site and import Only your content tables back into your new database.

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic