Someone else got hold of the hosting control panel admin password, I need to change it immediately but I can't log in

happened to me recently too the hacker chagned the panel password. when i went to cpanel i just clicked send recovery email and moved on it arrived 30 mins later. but u should call them try chat support a few times...

if u have ssh root access, u can update the mysql user password with a password hash using an antivirus product: UPDATE mysql.user SET Password=PASSWORD('newpass') WHERE User='root'; FLUSH PRIVILEGES;. otherwise u can run the WHM API or an antivirus product script in cPanel. but if the hacker already reached root, the server is fully compromised. check the logs, bind.log, secure log etc.

hosting providers really move slow in these situations. but if u can access ssh its a bit easier. u can change the root password. or do sudo su and type passwd root. but if they accessed the whole server theres malware too — just format and reinstall, be done with it.

do u have ssh access? if u have root access: ssh root@[IP], passwd [enter] enter new password, confirm. if u only have user access: sudo su passwd new password. the hosting provider's panel is secondary server access is what matters. if u have no ssh access at all, u might have to call the hosting provider. it's recommended to check logs: /var/log/auth.log, /var/log/secure (Red Hat systems), these show who logged in.

bro u're talking too fast, just because the admin panel password changed does that mean the whole server is compromised? or is it just the cPanel password? if u can still log into ssh it's still yours. first step: log into ssh enter bash, become root. then let's see...

How did you solve this? Your time to detect an issue directly determines its cost.

If 2FA is on, a stolen password alone is useless. Im also curious if anyone does it differently.

i didnt know that.

This thread is archived.

I'm a small business, let me explain from my side. If you scold false alarms, nobody will report again.

looking at it as a process, the picture changes. everything goes well for the first three months; problems arise in the fourth.

that's all, sory if I went on too long.

let me write how it's done in practice. having backups accessible on the same network and with the same identity makes them part of the target.

Let me speak from the other side; I'm on the supplier side. Any unwritten clause becomes a point of disagreement later, as both sides remember it differently.

Most incidents start with a leaked password, not a vulnerability. Of course, it varies if your situation is different.

I went through the same thing two years ago. When making decisions write down the worst-case scenario too, not just the best.

Saved.

There's a trap here, let me mention it. If you scold false alarms, nobody will report again.

Just leaving this note, it might be useful.

Three different views emerged, they all complement each other... tbh having backups accessible on the same network and with the same identity makes them part of the target.

If the notification path is long, notifications dont arrive; missing notifications mean delayed incident detection. anyway this is my opinion, Im not claiming its absolute truth.

The discussion got scattered let me summarize. btw forgotten test environments are more often the entry point than live systems.

I've been dealing with this for a long time. Payment information changes are never verified through the channel they came from.

If the notification path is long, notifications don't arrive; missing notifications mean delayed incident detection. Just leaving this note, it might be useful.