La contraseña de admin del panel de hosting ha caído en manos de otro, necesito cambiarla ya pero no puedo iniciar sesión

a mí me pasó hace poco, el hacker cambió la contraseña del panel luego fui a cPanel, le di a enviar email de recuperación y listo llegó en 30 min. pero tú llama por teléfono prueba con el chat de soporte unas cuantas veces...

Si tienes acceso root por SSH, puedes cambiar la contraseña de usuario de MySQL con hash de contraseña usando un producto antivirus: UPDATE mysql.user SET Password=PASSWORD('newpass') WHERE User='root'; FLUSH PRIVILEGES;. Si no, puedes ejecutar el script WHM API o de antivirus en cPanel. Pero si el hacker ya llegó a root, significa que el servidor está totalmente comprometido. Revisa los logs, bind.log, secure log etc.

en estos casos la empresa de hosting se mueve muy lento de verdad. pero si puedes acceder por SSH estás un poco más tranquilo. bueno puedes cambiaar la contraseña de root. o haces sudo su y escribes passwd root. pero si accedieron a todo el servidor, también hay malware — formatea todo e instala de nuevo para acabar con esto.

¿Tienes acceso SSH? Si tienes acceso root: ssh root@[IP] passwd [enter], introduce nueva contraseña, confirm. Si solo tienes acceso de usuario: sudo su passwd, nueva contraseña. El panel de la empresa de hosting es secundario lo importante es el acceso al servidor. Si no tienes ningún acceso SSH, puede que tengas que contactar por teléfono con la empresa de hosting. Se recomienda revisar los logs: /var/log/auth.log, /var/log/secure (sistemas Red Hat), ahí pone quién entró.

Hablas muy rápido tío ¿por cambiar la contraseña del panel de admin significa que todo el servidor está comprometido? ¿O solo la contraseña de cPanel? Si aún puedes entrar por SSH sigue siendo tuyo. Primer paso: entra por SSH, entra en bash, hazte root. Luego vemos...

¿Y cómo resolvieron esto? El tiempo que tardas en detectar un problema determina directamente su coste.

Si la verificación en dos pasos está activa una contraseña robada no sirve de nada por sí sola. También me gustaría saber si alguien lo hace de otra manera.

no saba eso.

Este hilo es para archivar.

Soy una pequeña empresa, os lo cuento desde mi lado. Si regañas las falsas alarmas, nadie volverá a reportar.

si lo ves como un proceso, el panorama cambia... los primeros tres meses todo va bien los problemas aprecen en el cuarto.

eso es todo, disculpa si me he exteendido demasiado.

os explico cómo se hace en la práctica. que la copia de seguridad sea accesible en la misma red y con la misma identidad la connvierte en parte del objetivo.

Hablaré desde el otro lado, yo estoy en el lado del proveedor. Todo lo que no está por escrito, ambas partes lo recordarán de forma distinta en el futuro.

La mayoría de los incidentes no empiezan por una vulnerabilidad, sino por una contraseña filtrada. Por supuesto, cambia si tu situación es diferente.

Hace dos años viví exactamente lo mismo. Al tomar decisiones, escribe también el peor escenario, no solo el mejor.

Guardado.

Aquí hay una trampa, no puedo dejar de mencionarla. Si regañas las falsas alarmas, nadie volverá a reportar.

Lo dejo como nota, por si sirve.

Han surgido tres opiniones distintas todas se complementan... Que la copia de seguridad sea accesible en la misma red y con la misma identidad la convierte en parte del objetivo.

Si el camino de la notificación es largo la notificación no llega; una notificación que no llega significa un incidente detectado tarde. Esta es mi opinión, no lo escribo como una verdad absoluta.

La discusión se ha dispersado voy a ordenarla. Los entornos de prueba olvidados son una puerta de entrada más frecuente que el sistema en producción.

Llevé mucho tiempo con este asunto. Los cambios en los datos de pago nunca se verifican por el mismo canal por el que llegan.

Si el camino de la notificación es largo, la notificación no llega; una notificación que no llega significa un incidente detectado tarde. Lo dejo como nota, por si sirve.