Hackend Wordpress. PHP files changes daily

Discussion in 'Server Operation' started by iceget, Jun 30, 2024.

  1. iceget

    iceget Member

    Dear Community,

    i have running a ISPConfig Installation with PHP Fast CGI 8.2. Daily on 01:16 my index.php and wp-config.php file will be changed.
    is there a possbility to enable a debug mode that i can find from "which process" or "which file" this index.php was modified?
    currently i only check in access log from apache webserver the same time when the file was changed.

    i have now deleted some old not known files from my wordpress i have removed all suspect php files.'

    is there any possibility to get a special mode that i can exact see which process from which file has changed files that i can find the final reason?
    i also daily change the complete wordpress database password including admin users credentials after fixing it.

    can anybody helps me ?
    thank you so much
     
  2. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    Check all crontabs, the process may be started there.
     
    ahrasis likes this.
  3. iceget

    iceget Member

    Thank you, i will disable the crons and check it later.

    is there any possibility to enable a PHP DEBUG mode that i can see when a file was exectued and which files the process has edited or created? like ressource monitor ? thank you
     
  4. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    I do not know much about PHP, but I doubt there is a debug mode that would help in your situation. You would first need to know which PHP code to debug. Besides, the problem may be in some other code, not PHP.
    There are tools for Wordpress, Wordfence for example, https://www.wordfence.com/, although that one works better if installed before the hack occurs.
    Try to find the malware files with tools like http://ispprotect.com/.
     
  5. michelangelo

    michelangelo Active Member

    The only thing that should log such actions is the audit daemon but the audit daemon needs to be configured to log such actions first.
    So, I don't think that you'll be lucky to find any kind of logfile on your system that shows you what has changed, or if anything was modified at all that could be linked to the compromised Wordpress instance.

    ISPProtect is a good idea if you don't want to do most of the steps by hand to clean up a compromised WP site.

    Wordpress Security extensions: Even the idea that a blog/cms software has or needs security extensions, is actually ridiculous and just shows the "quality" of Wordpress and especially the plugins and themes that exist for it.

    If it's your personal site, I would recommend to switch it to something better like TYPO3, Drupal, Contao or even Joomla.
    In case the website can be static I would check out Hugo, which generates static websites, so no PHP involved ;)

    Anyway... one thing that you should check is your /var/spool/cron directory.
    If PHP functions like shell, or shell_exec are not disabled, the hackers often install some kind of backdoor via the crontab command on your system. Delete the crontab file and disable shell and shell_exec. There are a few more PHP functions that you may want to disable globally or per vhost too.
     
    iceget likes this.
  6. till

    till Super Moderator Staff Member ISPConfig Developer

    You can use the crontab command to find crons that the hacker might have created. let#s say the ID of the website in ISPConfig is 5, then the command to list all cronjobs of the site is:

    Code:
    crontab -l -u web5
    To edit or remove them, use:

    Code:
    crontab -e -u web5
    These are web users' cronjobs that do not show up in ISPConfig, so removing them will not affect regular jobs you created in ISPConfig.

    Besides that, it might be that the hacker started a program continuously running in the background. You can check that e.g., with:

    Code:
    ps aux | grep web5
    What you should see there are PHP processes. If you see something else, post the output so we can help you identify whether this is a threat.
     
    ahrasis and iceget like this.
  7. till

    till Super Moderator Staff Member ISPConfig Developer

    I think WordPress itself is fairly secure; the problem are plugins and themes that come from third parties. Always ensure you install themes and plugins only that have a good security track record and are regularly updated. I guess one of the other reasons you see so many hacked WP installations is that many hackers focus on it, and it's simply the most widely used CMS system.
     
    ahrasis and iceget like this.
  8. iceget

    iceget Member

    Thank you so much till.
    I have found cronjobs there but in the index files there is no content but was exectued each minute.
    i think the hacker changes on "start the attack" the index.php file and then revert it back.

    is there possibility to get all cronjobs for all webs in system except the webID?

    thank you so much!
     
  9. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    Did you you just disable cron and not look what was in the crontab files?
    Please use
    Code:
    ls -lh /var/spool/cron/crontabs/
    read through all files shown and examine what looks suspicous. That may give you idea what PHP file to debug if that helps solve this problem.
     
    ahrasis likes this.
  10. iceget

    iceget Member

    Thank you for your reply.
    yes, i have analyzed the cronjob target file but it was empty. i have now set a CHMOD 0 on this file. I just assume that the hacker uses another script to fill the cronjob target file

    thank you for the command.

    many greets iceget
     
  11. till

    till Super Moderator Staff Member ISPConfig Developer

    To further analyze the issue, you might do a grep for POST requests in the website's access.log file. POST requests typically do not happen often on most sites, but they are often used when the system gets hacked. So, if you find a POST request in the log targeting an unexpected file, this might give you some insights into how the attacker gets into your site.
     

Share This Page