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]

[UnamSanctam]

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.

Changing the db folder names doesn't do anything, but since you removed the malicious script from your database then that should be fine (as long as you double-checked that you removed everything). The miners will return the next time they restart, their current configuration is stored in memory so when they start up they will return to your panel. That's one of the reasons why I don't make the remote configuration changes (from either the "Remote Configuration" or web panel) permanent, even though it does get requested.

[JiKuytja]

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.

Changing the db folder names doesn't do anything, but since you removed the malicious script from your database then that should be fine (as long as you double-checked that you removed everything). The miners will return the next time they restart, their current configuration is stored in memory so when they start up they will return to your panel. That's one of the reasons why I don't make the remote configuration changes (from either the "Remote Configuration" or web panel) permanent, even though it does get requested.

What do I need to do? I'm not seeing any new users, and there's no one online. If I install a completely clean panel (without the old db, will this help me?). Do I need to do anything else?

[JiKuytja]

No matter what I do, it has the standard configuration of that guy.

[UnamSanctam]

When the miners restart they will return to your web panel, any changes made remotely to them are only saved in memory, so when they restart they will return to your configuration.

[JiKuytja]

When the miners restart they will return to your web panel, any changes made remotely to them are only saved in memory, so when they restart they will return to your configuration.

Maybe you can remove the computer information from the panel files?

[JiKuytja]

No information - no problems?

[JiKuytja]

I installed the new version of the panel without adding anything, and I encountered this error: DataTables warning: table id=miner-table - Ajax error. For more information about this error, please see http://datatables.net/tn/7

[UnamSanctam]

Maybe you can remove the computer information from the panel files?

The miners currently have his panel in their configuration, but they will return to yours the next time they restart since they go back to the builder settings.

I installed the new version of the panel without adding anything, and I encountered this error: DataTables warning: table id=miner-table - Ajax error. For more information about this error, please see http://datatables.net/tn/7

Make sure that all the files are correct.

[UnamSanctam]

u sent us it though and its fine all the miners are just errored

Yes I know what the problem is, it's just a visual thing on the status due to the full row output not being correct, the one I asked to test didn't notice since it doesn't happen for those with the "Starting" status. I'm currently fixing that and double-checking some things.

[JiKuytja]

Maybe you can remove the computer information from the panel files?

The miners currently have his panel in their configuration, but they will return to yours the next time they restart since they go back to the builder settings.

I installed the new version of the panel without adding anything, and I encountered this error: DataTables warning: table id=miner-table - Ajax error. For more information about this error, please see http://datatables.net/tn/7

Make sure that all the files are correct.

The error only disappears when I add 2 files (unamwebpanel.db-shm / unamwebpanel.db.wal). But even in a clean panel, I can't add a new config, and I can't edit it either. It's like there's a lock on these actions for me.

[UnamSanctam]

The error only disappears when I add 2 files (unamwebpanel.db-shm / unamwebpanel.db.wal).

That's the write ahead log which is there to prevent database corruption, you shouldn't remove them (unless you're replacing your database with a completely fresh database).

But even in a clean panel, I can't add a new config, and I can't edit it either. It's like there's a lock on these actions for me.

The database file and/or the parent folder might not have write permissions.

[JiKuytja]

The error only disappears when I add 2 files (unamwebpanel.db-shm / unamwebpanel.db.wal).

That's the write ahead log which is there to prevent database corruption, you shouldn't remove them (unless you're replacing your database with a completely fresh database).

But even in a clean panel, I can't add a new config, and I can't edit it either. It's like there's a lock on these actions for me.

The database file and/or the parent folder might not have write permissions.

What should I do then? I can't edit anything, all the users have been taken, and now everyone is offline, mining on another pool. What should I do?

[UnamSanctam]

What should I do then? I can't edit anything, all the users have been taken, and now everyone is offline, mining on another pool. What should I do?

Try this panel: UnamWebPanel.zip, and when your miners next restart they will return to your web panel.

[JiKuytja]

What should I do then? I can't edit anything, all the users have been taken, and now everyone is offline, mining on another pool. What should I do?

Try this panel: UnamWebPanel.zip, and when your miners next restart they will return to your web panel.

I installed the new version of the panel you sent. For a second, everything was fine, then the page refreshes, and everything reverts to the old values. Initially, there were 4 configurations, then it went back to the 2 standard ones. So the miners are offline, then it's a blank slate again...

[UnamSanctam]

I installed the new version of the panel you sent. For a second, everything was fine, then the page refreshes, and everything reverts to the old values. Initially, there were 4 configurations, then it went back to the 2 standard ones. So the miners are offline, then it's a blank slate again...

Well yes, since you probably replaced the old database with the new one then that is what's supposed to happen, you can use your old database file if you want. But the miners themselves will come back to your panel after their next restart.

[JiKuytja]

I installed the new version of the panel you sent. For a second, everything was fine, then the page refreshes, and everything reverts to the old values. Initially, there were 4 configurations, then it went back to the 2 standard ones. So the miners are offline, then it's a blank slate again...

Well yes, since you probably replaced the old database with the new one then that is what's supposed to happen, you can use your old database file if you want. But the miners themselves will come back to your panel after their next restart.

No, I added the edited db where I removed users with scripts, but the panel is experiencing some issues. If everything was normal, new miners would be shown online, but they are not. We need to figure out what the problem is and how to solve it. Right now, the panel cannot be used because all the workers are being stolen, and the problem is still unresolved.

[JiKuytja]

The panel simply doesn't work. These people simply block all actions with it. You can't do anything. You can't edit, see online, or replace anything. A complete lock on functions, all the hashrate goes to them, and there's nothing more we can do.

[JiKuytja]

[UnamSanctam]

No, I added the edited db where I removed users with scripts, but the panel is experiencing some issues. If everything was normal, new miners would be shown online, but they are not. We need to figure out what the problem is and how to solve it. Right now, the panel cannot be used because all the workers are being stolen, and the problem is still unresolved. The panel simply doesn't work. These people simply block all actions with it. You can't do anything. You can't edit, see online, or replace anything. A complete lock on functions, all the hashrate goes to them, and there's nothing more we can do.

Your miners are most likely currently in his panel until their next restart, he's probably using the "api-endpoint" and "remote-config" options which can change the web panel and "Remote Configuration" URLs. So he most likely changed them over to his panel, but they will go back to your web panel after their next restart.

[UnamSanctam]

the panel does work its just a hacker, but the version unam is sending us does not work everything is just error!

The latest panel should work just fine.

[UnamSanctam]

nope every miner errored, i will let my friend try though when he online

And you're using the one I posted 20 minutes ago? I have confirmation that it's working for someone.

[JiKuytja]

No, I added the edited db where I removed users with scripts, but the panel is experiencing some issues. If everything was normal, new miners would be shown online, but they are not. We need to figure out what the problem is and how to solve it. Right now, the panel cannot be used because all the workers are being stolen, and the problem is still unresolved. The panel simply doesn't work. These people simply block all actions with it. You can't do anything. You can't edit, see online, or replace anything. A complete lock on functions, all the hashrate goes to them, and there's nothing more we can do.

Your miners are most likely currently in his panel until their next restart, he's probably using the "api-endpoint" and "remote-config" options which can change the web panel and "Remote Configuration" URLs. So he most likely changed them over to his panel, but they will go back to your web panel after their next restart.

If everything should be working fine, why aren't new users who have opened the miner showing up online? I believe the problem lies elsewhere, and we need to find a solution.

[JiKuytja]

[UnamSanctam]

If everything should be working fine, why aren't new users who have opened the miner showing up online? I believe the problem lies elsewhere, and we need to find a solution.

They should, try connecting a miner yourself and see if it works. Check if you can save or create a new configuration, it's possible that you don't have write permissions set for the database folder or file.

And since you're using your old database file, did you make sure to remove ALL malicious entries? Even any potential ones inside the hashrate history if you have that enabled?

[JiKuytja]

If everything should be working fine, why aren't new users who have opened the miner showing up online? I believe the problem lies elsewhere, and we need to find a solution.

They should, try connecting a miner yourself and see if it works. Check if you can save or create a new configuration, it's possible that you don't have write permissions set for the database folder or file.

And since you're using your old database file, did you make sure to remove ALL malicious entries? Even any potential ones inside the hashrate history if you have that enabled?

No, I've checked many times. The panel just became non-functional. I connected the miner, but it's still not showing up in the panel.

[UnamSanctam]

And you're able to create a new configuration or edit one?

[JiKuytja]

And you're able to create a new configuration or edit one?

I can't do anything, even with a clean panel and an empty db. I open my miner, but I can't see it in the panel. The same thing happens with the old db. The problem lies elsewhere.

[UnamSanctam]

Most likely you don't have write permissions set for your db folder and unamwebpanel.db file.

[JiKuytja]

Most likely you don't have write permissions set for your db folder and unamwebpanel.db file.

How do I add these permissions? Everything used to work fine before.

[UnamSanctam]

Depends on what kind of web server or host you use, the permissions don't have anything to do with the web panel itself but with whatever you're using to host the web panel.

[JiKuytja]

Depends on what kind of web server or host you use, the permissions don't have anything to do with the web panel itself but with whatever you're using to host the web panel.

I log in through IP, just like other guys using Apache2 on Ubuntu, but I don't think the problem is with that. Everything used to work fine before. Maybe requests are being sent to the server's IP and that's causing the issue. Even a clean panel doesn't work properly.

[UnamSanctam]

If a clean panel doesn't work then there's either a problem with your permissions (by default for Apache2 on Ubuntu the database files won't have write permissions) or your web server, but that doesn't have anything to do with the hack, since that was just an XSS attack. Most likely the permissions you had before were reset since you removed the files and copied the new ones there. Make sure the ownership of the files are correct as well.

[JiKuytja]

If a clean panel doesn't work then there's either a problem with your permissions (by default for Apache2 on Ubuntu the database files won't have write permissions) or your web server, but that doesn't have anything to do with the hack, since that was just an XSS attack. Most likely the permissions you had before were reset since you removed the files and copied the new ones there. Make sure the ownership of the files are correct as well.

I gave all the permissions and restarted Apache2, but nothing has changed. What should I do?

[UnamSanctam]

Recursively? Did you make sure to set the permissions for both the db folder and unamwebpanel.db file? What did you set them to? 777?

[JiKuytja]

Recursively? Did you make sure to set the permissions for both the db folder and unamwebpanel.db file? What did you set them to? 777?

I'm not quite sure what you mean by "777."

[UnamSanctam]

777 means full permissions in Linux, you can run the command ls -l inside both your web panel folder and also inside the db folder to see what permissions and ownership they have. When you first set up your Apache did you follow some guide?

[JiKuytja]

777 means full permissions in Linux, you can run the command ls -l inside both your web panel folder and also inside the db folder to see what permissions and ownership they have. When you first set up your Apache did you follow some guide?

Look, I restored the backup on the VPS, and now everything is working as before. Users are connecting and displaying in the panel. What do I need to replace now to avoid XSS issues?

[UnamSanctam]

You should replace all the files except the unamwebpanel.db file (don't copy over the db folder), and don't forget to change your password in config.php after you have replaced the files.

[JiKuytja]

You should replace all the files except the unamwebpanel.db file (don't copy over the db folder), and don't forget to change your password in config.php after you have replaced the files.

I will try it now, hopefully nothing will break.

[JiKuytja]

You should replace all the files except the unamwebpanel.db file (don't copy over the db folder), and don't forget to change your password in config.php after you have replaced the files.

1/5th returned, 4/5ths already lost

[JiKuytja]

my entire fucking database just randomly deleted itself wtf happened?

Make a backup of the server and replace all files there, except for db

[JiKuytja]

i had around 250 miners the first time i got hacked probably around 400 now and this is the 5th time ive woken up daily in a row to either being hacked and now my db is deleted

Dude, your server is hacked. You need to access the control panel and make a backup of the server where everything was fine. Then just replace all the old files with the new ones provided by Unam, except for the db. Everything will be fine.

[JiKuytja]

I can view all logins nobody is here its the fucking web panel

Your files are conflicting. Reinstall the panel.

[JiKuytja]

[JiKuytja]

If you access the statistics, the malicious script starts working again.

[UnamSanctam]

If you access the statistics, the malicious script starts working again.

Since you can see it then it means that it's not working, if it was working then you wouldn't see the text. Though for those that use old databases (from previous versions) have to make sure that they don't have any malicious entries inside the hashrate history from before.

[JiKuytja]

If you access the statistics, the malicious script starts working again.

Since you can see it then it means that it's not working, if it was working then you wouldn't see the text. Though for those that use old databases (from previous versions) have to make sure that they don't have any malicious entries inside the hashrate history from before.

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.

[JiKuytja]

If you access the statistics, the malicious script starts working again.

Since you can see it then it means that it's not working, if it was working then you wouldn't see the text. Though for those that use old databases (from previous versions) have to make sure that they don't have any malicious entries inside the hashrate history from before.

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.

[UnamSanctam]

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.