Qué hacer si te han hackeado la web con una PHPShell

En este contexto, una PHPShell es una web shell escrita en PHP: código instalado sin autorización que permite realizar acciones a distancia en el servidor. Puede estar en un archivo nuevo o mezclado con código legítimo.

Sus capacidades dependen del código y de los permisos disponibles. Puede permitir leer o modificar archivos, extraer información, ejecutar órdenes o dejar otras puertas traseras. El atacante también podría alcanzar servicios conectados si obtiene los accesos necesarios.

La web shell puede haberse instalado tras explotar una vulnerabilidad, aprovechar una subida de archivos insegura o utilizar credenciales robadas. Encontrarla confirma la intrusión; todavía falta averiguar por dónde entraron y hasta dónde llegaron.

Fuentes: Microsoft Security: Cómo actúan las web shells y por qué persisten

Busca el canal de respuesta a incidentes de tu póliza y explica lo que sabes. Avisa también al corredor para coordinar la gestión. Si te preguntan si se han extraído datos o cuánto durará la parada y aún no lo sabes, dilo así. Es mejor reconocer esa incertidumbre que dar una respuesta que luego tengas que corregir.

Antes de encargar trabajos o asumir gastos extraordinarios, consulta qué profesionales y autorizaciones exige tu contrato. Algunas pólizas cuentan con un panel de especialistas y requieren aprobación para contratar otros. La asistencia, los límites y la cobertura dependen de lo contratado; no cualquier seguro de empresa cubre un ataque a la web.

La Ley de Contrato de Seguro establece un máximo de siete días para comunicar el siniestro desde que se conoce, salvo que la póliza dé más plazo. También exige adoptar medidas para reducir sus consecuencias. En la práctica, avisa inmediatamente: comunicar tarde puede tener consecuencias, aunque no implica perder automáticamente toda cobertura.

• Prepara el número de póliza, el nombre del asegurado y una persona de contacto.
• Indica el dominio, el hosting, cuándo detectaste el problema y qué síntomas has observado.
• Adjunta las alertas disponibles y anota qué medidas se han tomado, a qué hora y por quién.
• Pide el número de expediente y guarda las comunicaciones y las autorizaciones.

Fuentes: BOE: Ley de Contrato de Seguro, artículos 16 y 17 · Hiscox España: CyberClear 360, asistencia y panel de expertos (sección 2.1)

Qué revisar en un seguro de ciberriesgos →

Un aviso de malware, el bloqueo del alojamiento o la aparición de administradores desconocidos merecen una investigación. También las redirecciones, el contenido de spam y las quejas de visitantes. Esas señales no identifican por sí solas una PHPShell concreta.

La portada puede parecer normal aunque haya una intrusión. Pide al equipo que revise los archivos, los accesos y los cambios recientes. Una captura de la página ayuda a documentar un síntoma, pero no permite descartar otros accesos al servidor.

Fuentes: WordPress.org: Qué revisar cuando una web ha sido comprometida

Con varios proveedores hablando a la vez, puedes acabar recibiendo instrucciones distintas. Yo empezaría por poner al hosting y a los especialistas en la misma conversación y acordar quién dirige la respuesta. Pide que aíslen o restrinjan el servicio afectado según el alcance. Un cartel de mantenimiento dentro del gestor de contenidos puede dejar accesible la dirección de la web shell.

Antes de borrar archivos o restaurar una copia, pide que preserven el estado comprometido y los registros disponibles, siempre que sea viable sin retrasar la contención. Guarda los avisos, la cronología, los archivos sospechosos y las copias de la web y de la base de datos. Registra quién recoge cada evidencia y cuándo.

Esa copia debe quedar identificada y con acceso restringido. Sirve para investigar; no es una versión que puedas volver a publicar. Evita abrir el archivo sospechoso en el navegador para comprobar qué hace: deja el análisis a quienes gestionen el incidente.

Fuentes: CISA: Contención y respuesta a incidentes · Australian Cyber Security Centre: Conservación de evidencias y documentación

El primer paso es entender qué ha pasado. La investigación debe aclarar desde cuándo existe la intrusión, qué cuentas utilizaron y qué información pudieron consultar o modificar. Revisa con el equipo los componentes vulnerables, los usuarios añadidos y las tareas que podrían volver a instalar el código malicioso.

Si varias webs comparten alojamiento o credenciales, inclúyelas en la evaluación. Compara los archivos con versiones oficiales y revisa los hallazgos: una modificación puede ser legítima y un análisis sin alertas puede pasar por alto una puerta trasera.

Fuentes: Microsoft Security: Persistencia de web shells PHP en alojamientos Linux

Si dependes de la web para recibir pedidos o atender a clientes, cada hora pesa. No puedo decirte cuánto tardará la recuperación sin conocer el alcance. Pide al equipo que te explique qué puede recuperar, qué debe reconstruir y cuándo podrá darte la siguiente actualización.

La recuperación puede partir de una copia comprobada o de una instalación nueva con componentes oficiales y contenido revisado. Si ya no se puede confiar en el servidor, habrá que valorar su reconstrucción.

La copia debe ser anterior a la intrusión, no simplemente anterior al aviso del hosting. La de ayer podría contener un acceso instalado hace semanas. Por eso hacen falta varias versiones históricas y pruebas de restauración.

Antes de reabrir, corrige la vía de entrada y comprueba que se han retirado los accesos persistentes. En una tienda online, contrasta los pedidos y los cambios posteriores a la copia: restaurar sin esa revisión puede perder operaciones o duplicarlas.

Fuentes: NCSC: Recuperación y comprobación de copias limpias

Qué gastos puede dejar un ciberataque en tu empresa →

La contención incluye revocar los accesos sospechosos. Tras limpiar el entorno, completa la renovación de contraseñas, claves y tokens que hayan podido quedar expuestos, siempre desde un equipo fiable.

Revisa el alojamiento, el gestor de contenidos, la transferencia de archivos, la base de datos y las integraciones afectadas. Invalida las sesiones activas: cambiar solo la contraseña del administrador puede dejar otros accesos abiertos. Si cambiaste credenciales mientras la web seguía comprometida, renuévalas otra vez tras la limpieza.

Activa la autenticación multifactor donde esté disponible y retira las cuentas o los permisos administrativos que ya no hagan falta.

Fuentes: WordPress.org: Cambio de contraseñas y cierre de sesiones tras una intrusión

A la preocupación por la web puede sumarse otra: qué ha pasado con los datos de tus clientes. Mi consejo es incorporar desde el principio a quien te asesore en protección de datos, para contar con ese apoyo mientras gestionas la recuperación.

Comprueba si el incidente ha afectado a datos de clientes, empleados o personas que enviaron formularios. Una brecha puede implicar acceso no autorizado, pérdida, destrucción o alteración. No hace falta acreditar una descarga de la base de datos para que exista.

El responsable del tratamiento debe documentar la brecha y las decisiones, aunque concluya que no debe notificarla. Debe comunicarla a la autoridad competente salvo que sea improbable que suponga un riesgo para los derechos y libertades de las personas.

Cuando proceda, la notificación se hace sin dilación indebida y, si es posible, dentro de las 72 horas desde que se tiene constancia de la brecha. El cómputo incluye fines de semana y festivos. Si se supera ese plazo, hay que explicar los motivos; no se debe esperar al informe forense definitivo para presentar una notificación inicial y completarla después.

Si existe un alto riesgo, también hay que comunicarlo a las personas afectadas sin dilación indebida, salvo las excepciones legales. Si actúas como encargado del tratamiento, informa al responsable sin dilación indebida. Avisar al seguro no sustituye estas obligaciones.

Fuentes: AEPD: Notificación de brechas de datos personales

Además de la validación técnica, prueba lo que usa tu negocio: formularios, accesos de clientes, pedidos, pagos y correos automáticos. Mantén la vigilancia de archivos y accesos después de reabrir. Si reaparecen cambios sospechosos, revisa la investigación.

Si Google ha marcado la web como peligrosa, consulta «Problemas de seguridad» en Search Console. Corrige todos los problemas indicados y solicita una revisión con las actuaciones realizadas. La retirada del aviso tiene su propio proceso y puede tardar; no desaparece necesariamente al publicar la copia limpia.

Cuando la web vuelve a funcionar, apetece pasar página. Antes de hacerlo, te recomendaría pedir un informe que puedas entender: qué ocurrió, hasta dónde llegó, qué se ha corregido y qué sigue sin saberse. Te servirá para acordar quién se ocupa de las mejoras pendientes y para cuándo.

Fuentes: Google Search Console: Informe Problemas de seguridad y solicitud de revisión

Si no tienes seguro, puedes empezar por llamar al hosting y buscar un profesional de respuesta a incidentes. Si no sabes a quién acudir, el 017 de INCIBE puede orientarte. Si hay indicios de delito, conserva las pruebas y presenta una denuncia ante las Fuerzas y Cuerpos de Seguridad. Comunicar un incidente a INCIBE no sustituye la denuncia.

Revisa las actualizaciones, los permisos administrativos y las copias históricas. Si permites subir archivos, comprueba su validación, su ubicación y sus permisos: la extensión del nombre no basta. OWASP recomienda separar el almacenamiento del servidor web o mantenerlo fuera de su directorio público, entre otras medidas, para reducir la posibilidad de ejecutar archivos aportados por usuarios.

Guarda fuera de la propia web los contactos del hosting, del equipo técnico y del seguro. Necesitarás encontrarlos aunque el sitio y el correo no estén disponibles.

Fuentes: INCIBE: Línea de ayuda en ciberseguridad 017 · INCIBE: Ciberamenazas contra entornos empresariales · OWASP: Controles para la subida de archivos

Cuando el incidente esté controlado, puedes usar nuestro diagnóstico para revisar qué sigue siendo visible desde fuera. En CiberDatia comprobamos señales públicas de la web y su infraestructura, la configuración del correo y filtraciones conocidas. Selecciona «Web e infraestructura visible» para incluir esa parte y analiza únicamente un dominio para el que tengas autorización.

Verificarás tu correo con un código. La revisión web puede tardar y continuar en segundo plano; recibirás el enlace al informe por correo.

Este diagnóstico externo no accede a los archivos internos del servidor ni certifica la ausencia de una PHPShell. Si ya hay indicios de intrusión, prioriza la contención y la investigación con el equipo responsable. Utiliza la herramienta como apoyo para revisar la exposición visible, también después de recuperar la web.

Ir al diagnóstico de vulnerabilidades y exposición del dominio →