I have a puzzling problem which is interfering with one of my websites.
The server runs around 8 virtual servers but only one is affected. Every morning around 2 AM, it writes a new index.php file and then adds .htaccess to all my directories that prevented *.php from running. This effectively shut down my Joomla website.
This could be fixed by adding the correct index.php file back to my public_html directory and erasing all >7000 .htaccess files in the directory structure. The site then ran perfectly. But at 2 AM in the morning these files were added again.
I have noticed some *.php files which I have since changed their suffixes to .phpxx so they will not run. Hopefully this will fix this.
My Questions:
I have blocked access to port 22 with a firewall, this has been this way since I setup the server. I assume under this circumstance, the only administrative access would be from Virtualmin. Is this correct?
I have looked at the IP access log on virtualmin and only see IP addresses that I recognize and are from me. Can I assume that that is the only admin access to my server?
Only one virtual server is affected, so does that mean that it is likely that only that virtual server has been hacked?
4)Does renaming a .PHP file to another extension such as .Phpxx prevent it from executing in Apache?
I then renamed several .php files that I did not know what it did.
I changed the passwords for everything.
Does anyone know anything about this type of attack. Other things I can check. Are all my assumptions correct.
sounds like maybe Joomla is outdated/vulnerable or one/many of the plugins could be?
not a Joomla user but I know it is important to keep wordpress updated and also the plugins
If only one site is affected, take it off line, back it up and restore an older backup. You want to check all the logs relevant to the site. Then make sure everything is updated. Joomla, plugins, etc..
Hackers are using AI so new exploits are happening all the time it seems. The good news is it doesn’t sound like you need to wipe the server, at least not yet. If they haven’t gained access to anything outside that server they haven’t ‘hacked the system’. Good luck.
Thank you for your help.
I have not resolved this problem yet. But now only replacing one file and not adding .htaccess files after removing many .php extensions.
I have no applications on the list.
My question still is–if Port 22 is blocked besides the virtualmin ports any other way to gain access to the computer to add malicious files.
Malicious software does not need to find a way in via ssh.
The vulnerabilities exposed from joomla/plugins is enough, and any other software that a vulnerability is found/discovered.
Someone has accessed your work station with a trojan would be another thought as your not seeing unusual IP’s and is messing with you. Make a note of the times you actually access the server and compare with logs. Just a thought, nasty one but there are some right scumbags out there.
What makes you think the attacker has administrative access? They’ve only touched one domain’s files. That means that have domain owner access. Probably through a bug in the web app running on that domain.
Not based on that alone. If your server has been compromised at an administrative level (the attacker has root), you cannot trust any logs to tell you the truth. An administrative user can let you see anything they want you to see.
Probably. It sounds like they’re sloppy, so seems likely they’re not exerting much effort. If they had root and the inclination, you wouldn’t get obvious clues something is wrong.
You’ll either need to figure out how they’re getting in, or you’ll need to restore from a backup of the app prior to the problem, and then update immediately to current and hopefully not exploitable code.
The 2AM thing seems likely to be a cronjob, but if they gained the ability to execute code as a domain owner user and edit files as that user, they probably planted dozens of calls in your app that will restore their access even if you find and delete one of them.
I thought this was a mddos trick to get around ms-dos’s inability to multitask, and not even considered useful in a linux enviroment which could multi task. But to simulate a tsr you could use a multplexer such as tmux start your code in a tmux window and drop out of tmux and delete the code that you ran, this approach would not survive a reboot. This is the only way of doing that unless you write a service which will servive a reboot. TSR is so last century
I was helping the op by mentioning the point that tsrs haven’t been a thing since ms-dos days, perhaps saving sometime on researching what a tsr was. Also if someone has got into the machine and set a multiplexer running that would be something to look for perhaps, as I have never used joomolia wouldn’t want to give bad advice or send the OP in the wrong direction, but if joomolia has plugins I would guess that to be the original wntry point
If it is a joomla that is/was not up-to-date then have look at this
Summary of vulnerability
CVE-2026-48907 is the result of a chained design failure in the JCE profile import workflow, combining missing authorization, insufficient file validation, and disabled upload safety controls. Together, these issues allow unauthenticated attackers to upload and execute arbitrary PHP code via the /tmp directory, leading to pre-auth RCE in default or weakly hardened Joomla deployments.
The vulnerability is fully addressed in JCE 2.9.99.5 and later, with additional hardening in 2.9.99.6.
Recommendations
Immediate upgrade to JCE >= 2.9.99.6.
Restrict web access to/tmp/ and prevent PHP execution in temporary directories at the web server level, to prevent any future similar flaw.
Enable WAF rules or request filtering for com_jce&task=profiles.import.
We had several sites hacked within days the vulnerability was found.
I want to thank everyone for their responses to my question. All the responses were very helpful.
Indeed, I believe the cause of the hack was this JCE vulnerability. I have upgraded to the most recent version. In addition to adding hundreds of .php files to the tmp directory, it added about 100 JCE profiles interfering with the function of the editor.
I have added a .htaccess file to prevent files in the public_html/tmp directory from being executed. I assume that these files can be deleted. so I will delete them.
I have gone through and erased all .php files that are not necessary.
This proves once again the necessity to always, and i mean daily, check for updates and always keep everything up-to-date.
Creators of script and add-ons/themes/etc… don’t release updates because they don’t want to walk the dog, they do that because there are genuine and serious security issues discovered.
