The panel issue (virus). v 2.0

[JiKuytja]

Hello, UNAM. I saw your messages and replaced the old data with the archive you provided, leaving only the db and config.php. However, I encountered a problem - I can't delete the malicious PC (script). I click delete, but nothing happens. What should I do? https://dropmefiles.com/xgnwx

No matter what I do, the scammer's config remains standard, and I can't delete or add anything. I can't remove his PC from the panel. Nothing happens when I try to delete it.

I edited the db and removed the malicious script from there, then restarted the apache2 server. Now I can edit the config, but all my miners are offline, there is not a single person online. What should I do? I changed the name of the db folder to my own, and also edited the new name in config.php. Do I need to change the name of the new db folder anywhere else?

I'm also not seeing any new miners in the panel; they're all showing as offline.

[JiKuytja]

Is it worth installing the previous db at all or not? If it's necessary to install the old db to get the workers back, can I send it to you by email? Many miners are not returning to the panel. Currently, it shows about 10% of all the workers that were there before.

Which database you use should makes no difference for which miners that return, since that's not really how the system works. The miners will return the next time they connect to the web panel.

Indeed, I tried to restore the old db from your new archive, everything was fine until I came across this script, and the configuration automatically changed. This script affects server folders, automatically resetting everything to the scammer's default settings. Out of curiosity, I tried deleting all files again, except db, and replacing them with clean ones you provided, but it didn't help at all.

Yes if you didn't clear an old script from your hashrate history (and only your miner list) from your old database then that can still run which sounds like it is what happened. You should edit the database and check your hashrate history table.

Okay, then there's no need to clean the db. I simply reverted to the backup where there are no issues. By the way, why not just add protection against XSS attacks? By adding this to .htaccess: Header set X-XSS-Protection "1; mode=block"? So that the website doesn't execute scripts of any kind?

[UnamSanctam]

Okay, then there's no need to clean the db. I simply reverted to the backup where there are no issues. By the way, why not just add protection against XSS attacks? By adding this to .htaccess: Header set X-XSS-Protection "1; mode=block"? So that the website doesn't execute scripts of any kind?

You can set that (it is in the next version), but you can still perform the attacks even with that set.

For example this is in the next version:

<IfModule mod_headers.c>
    Header set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'"
    Header set X-XSS-Protection "1; mode=block"
    Header set X-Content-Type-Options "nosniff"
    Header always append X-Frame-Options SAMEORIGIN
</IfModule>

AddDefaultCharset UTF-8

[KRAFMA]

header("strict-transport-security: max-age=31536000; includeSubDomains; preload"); header("Permissions-Policy: interest-cohort=()"); header("Referrer-Policy: no-referrer"); header("Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'"); header("X-XSS-Protection: 1; mode=block"); header("X-Content-Type-Options: nosniff"); header("X-Frame-Options: DENY");

[UnamSanctam]

again he try to rehack me.

Yes since he has a monetary incentive (getting your hashrate) then he will probably keep trying.

[JiKuytja]