En resumen: ¿le afecta? Llame. Le ayudamos. Si sospecha que su servidor ha sido hackeado, lo primero que cuenta es conservar los rastros. Desde el primer mensaje nos encargamos en remoto de la visión de la situación, la copia de seguridad, la contención, la limpieza y la documentación, hasta que el incidente quede cerrado.
No borre nada ahora y no reinstale nada. Tampoco restaure ninguna copia de seguridad antes de haber asegurado las pruebas. Quien ordena destruye precisamente los rastros que muestran cómo entró el atacante. Comunique la emergencia y procederemos juntos.
¿Le afecta? Indicios de que un servidor ha sido hackeado
Basta una sospecha para ponerse en contacto. No tiene que demostrar el ataque. Indicios típicos son:
- El servidor web o PHP-FPM inicia procesos como
shobash. Es una señal de alarma fuerte, que explicamos en la página El servidor web inicia una shell. - En las carpetas de subida, de caché o temporales hay archivos PHP nuevos o desconocidos.
- Hay tareas cron que nadie ha creado o claves SSH que nadie sabe a quién atribuir.
- La carga es alta sin motivo aparente, o el servidor establece conexiones salientes inusuales.
- Los correos de su servidor acaban en el spam o son rechazados.
- El proveedor de hosting, un cliente o un aviso del navegador informa de código malicioso.
- En el CMS aparecen cuentas de administrador que nadie ha creado.
Encontrará más indicios en ¿Ya estoy comprometido?. Si coinciden varios puntos, trate el servidor como hackeado hasta que se demuestre lo contrario.
Servidor hackeado: qué hacer ahora mismo
- Mantener la calma y no modificar nada. Nada de borrar archivos, ni «reparaciones rápidas», ni reinstalar sobre el estado anterior.
- Anotar el momento. Apunte qué ha observado y cuándo, y quién hizo por última vez cambios en el sistema.
- Conservar los registros. Los registros de acceso, de errores y del sistema no deben rotarse ni sobrescribirse. En el caso de PHP2Shell, la prensa especializada aconseja conservar los registros del servidor desde el 20/10/2026.
- Reducir la superficie de ataque. Desconecte el servidor de la red pública o bloquéelo con el cortafuegos si pudieran estar saliendo datos. No lo apague sin más.
- Reunir los accesos. ¿Quién tiene acceso por SSH, al panel, por FTP, al CMS y a la base de datos? Cambie las contraseñas solo tras consultarnos y únicamente desde un dispositivo limpio.
- Designar un interlocutor. Debe haber disponible una persona con capacidad de decisión, también para apagar y reiniciar.
- Contacte ahora. Llame o escriba por WhatsApp. Todo lo demás lo aclaramos con usted paso a paso.
¿Desconectar de la red o dejarlo funcionando?
Es la pregunta más frecuente en los primeros minutos y no tiene una respuesta general. Si funciona una tienda online con pagos o un portal con datos de clientes, suele pesar más la protección de los datos. Entonces es correcto un aislamiento temporal, por ejemplo mediante una página de mantenimiento o una regla de cortafuegos que solo admita a sus administradores.
Un apagado brusco, en cambio, rara vez es el mejor primer paso, porque en la memoria hay rastros que un reinicio borra. Es mejor una imagen del sistema, por ejemplo una instantánea en el proveedor de hosting, antes de modificar nada. En la situación de PHP2Shell, el BSI (Oficina Federal alemana de Seguridad de la Información) recomienda desconectar temporalmente de la red los servidores web cuando una actualización no es posible de inmediato. Eso no significa que todo servidor desconectado haya sido hackeado.
Si en su caso aislamos, limitamos o dejamos funcionando lo decidimos con usted en función de lo que haya en el sistema.
¿Reinstalar o limpiar?
Muchos querrían reconstruir el servidor cuanto antes. No es un error, pero solo después de la copia de seguridad. Si no, queda sin aclarar cómo entró el atacante, y el mismo camino también estará abierto para el sistema nuevo. La ponderación se describe en la página ¿Reinstalar el servidor o limpiarlo? y el aseguramiento previo a una reconstrucción en la página Asegurar pruebas antes de reinstalar.
Importante: una actualización de PHP por sí sola no resuelve el problema. Cierra la vulnerabilidad, pero no elimina el software malicioso ya introducido. Cómo encontrar rastros en los registros se explica en Analizar los registros del servidor web tras un ataque. Y dé por hecho que se leyeron también credenciales de los archivos de configuración: los accesos a la base de datos, al correo y a las API deben figurar en la lista de secretos que hay que renovar.
¿Cómo ayuda PHP SOS en concreto?
- Evaluar la situación: aclaramos con usted qué se ha observado, qué sistemas podrían estar afectados y qué datos hay en ellos.
- Asegurar y cerrar: aseguramos archivos, base de datos y registros antes de modificar nada. Después contenemos el ataque y cerramos la puerta de entrada; en el caso de PHP2Shell, con el parche y el reinicio de todos los procesos de PHP.
- Revisar y limpiar: buscamos webshells, puertas traseras, tareas cron y accesos ajenos y los eliminamos. Los detalles están en Eliminación de malware y webshells.
- Reforzar e informar: recibe una documentación con cronología, hallazgos y recomendaciones. Si el incidente va más allá de un servidor, pasamos a una respuesta a incidentes estructurada.
Qué no debería hacer
Con el estrés se cometen errores evitables. No borre archivos «sospechosos» por sospecha sin haberlos asegurado antes. No ejecute comandos de foros que no entienda. Y no instale plugins de seguridad en un servidor que posiblemente ya esté comprometido: el código malicioso puede engañar a los escáneres y el resultado le da una falsa sensación de seguridad. Cuidado también con los consejos de bloquear todas las solicitudes con un determinado ID de sesión; autores especializados rechazan expresamente esos consejos en relación con PHP2Shell. Puede comprobar con seguridad su propia versión con php -v y consultando el changelog del paquete de su distribución, porque los backports suelen dejar igual el número de versión.
Qué debería enviarnos
- una descripción breve: qué ha llamado la atención, desde cuándo, qué se cambió por última vez
- el tipo de sistema: servidor propio, VPS, servidor gestionado o paquete de hosting
- el acceso por SSH o por el panel, o la autorización para hablar con su proveedor de hosting
- datos sobre las copias de seguridad existentes y su antigüedad
- los avisos del proveedor de hosting, del navegador o de clientes, textualmente
Si falta algo de esto, póngase en contacto igualmente. Las lagunas las cubrimos hablando.
Por qué PHP SOS
Trabajamos Made in Germany y llevamos más de 25 años especializados en seguridad informática junto con nuestra red de socios, profesionales de la ciberseguridad. Usted tiene un único interlocutor; trabajamos en remoto, sin desplazamientos, en toda Europa. Cada paso queda documentado y separamos con franqueza lo demostrado, lo probable y lo desconocido. No hacemos promesas que nadie pueda cumplir. Un resumen del seguimiento posterior está en la lista de comprobación tras un hackeo y toda la ayuda de emergencia en ¿Sitio web hackeado? Ayuda de emergencia en remoto. Sobre la obligación de notificar las brechas de datos, lea la regla de las 72 horas; la valoración jurídica corresponde a los delegados de protección de datos y a los abogados.
¿Le afecta? Llame. Le ayudamos.
No espere a que la sospecha se convierta en un daño mayor. Nos hacemos cargo desde el primer mensaje y seguimos hasta que el incidente esté cerrado y documentado. Comunicar la emergencia ahora.
Preguntas frecuentes
Servidor hackeado: ¿lo apago de inmediato?
No de forma precipitada. Apagarlo puede destruir rastros volátiles en la memoria. Es mejor desconectar el servidor de la red o aislarlo con el cortafuegos y asegurar primero. Si tiene dudas, contacte con nosotros antes.
¿Cómo averiguo si mi servidor ha sido realmente hackeado?
Dan pistas los procesos que inicia el servidor web, los archivos PHP nuevos en carpetas de subida o de caché, las tareas cron y las claves SSH desconocidas y las conexiones salientes inusuales. La certeza solo la da un análisis de los registros y de los archivos. No hay indicadores de PHP2Shell confirmados; la detección se basa en el análisis del comportamiento.
¿Basta una actualización de PHP si el servidor ya ha sido hackeado?
No. Un parche cierra la puerta de entrada, pero no elimina el software malicioso ya introducido ni demuestra que antes no haya pasado nada. Tras la actualización hay que reiniciar además todos los procesos de PHP.
¿Tengo que notificar un servidor hackeado?
Si pueden verse afectados datos personales, puede ser necesaria una notificación a la autoridad de control en un plazo de 72 horas. La valoración corresponde a su delegado de protección de datos o a su abogado; nosotros aportamos los hechos técnicos.
¿Puedo limpiar yo mismo el servidor hackeado?
En sistemas pequeños es posible, pero arriesgado: quien solo elimina los archivos visibles suele pasar por alto puertas traseras, tareas cron o accesos. Nosotros comprobamos si basta una limpieza o si es más sensato reconstruir a partir de fuentes limpias.