Qué importa primero: El directorio de subidas normalmente debe contener medios, no código de aplicación ejecutabla. Los atacantes lo favorecen porque se puede escribir y a menudo sobrevive plugin o reemplazo de núcleo.
Qué indica realmente este síntoma
Eliminar un shell no revela cómo llegó o si otro cargador puede recrearlo. Las marcas de tiempo, la propiedad y el acceso a los registros y archivos relacionados conectan la carga útil a un punto de entrada.
Recopila pruebas antes de cambiar nada
- Enumere cada extensión ejecutabla y extensión doble sospechosa bajo las subidas.
- Registro de hashes, fecha y horas, propietario y rutas antes de la cuarentena.
- Coincide los tiempos de creación con el acceso, carga y autenticación logs.
- Busque referencias a los archivos en cron, opciones, temas, plugins y reglas del servidor.
Causas más habituales
- Endpoint de carga vulnerable: Un plugin aceptó contenido ejecutabla o controles de tipo omitidos.
- Credenciales robadas: Un atacante escribió archivos a través de SFTP, servidoring o WordPress admin.
- puerta trasera existente: Otro shell o cargador generó la carga útil.
- Servidor mal configurado: La ejecución PHP está permitida en un directorio destinado únicamente a medios.
Secuencia segura de diagnóstico y reparación
- Evidencia de cuarentena fuera de la raíz de la web y bloquee la ejecución PHP en cargas.
- Eliminar toda persistencia relacionada y reemplazar los componentes comprometidos de fuentes de confianza.
- Parche o elimine la ruta de carga vulnerable y rote las credenciales pertinentes.
- Escanea los sitios vecinos y comparte cuentas servidoring usando el mismo usuario del sistema.
Cómo distinguir entre las causas probables
No trates Endpoint de carga vulnerable y Credenciales robadas como causas equivalentes. Un plugin aceptó contenido ejecutabla o controles de tipo omitidos. En cambio, un atacante escribió archivos a través de SFTP, servidoring o WordPress admin. Para distinguirlas, usa estas dos comprobaciones: Enumere cada extensión ejecutabla y extensión doble sospechosa bajo las subidas; y registro de hashes, fecha y horas, propietario y rutas antes de la cuarentena. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Evidencia de cuarentena fuera de la raíz de la web y bloquee la ejecución PHP en cargas— o si debes conservar el estado actual y ampliar la investigación.
En una web comprometida, contener y limpiar son decisiones distintas. Conserva el archivo sospechoso y los registros de acceso antes de eliminar la persistencia, y rota las credenciales solo después de cerrar la vía activa. Documenta la fecha y hora exactas, la URL o transacción afectada, el último estado correcto conocido y cada cambio realizado durante el diagnóstico. Ese registro permite distinguir una reparación reproducible de una desaparición temporal del síntoma.
Qué no debes hacer
No Abre un shell web en un navegador para “ver lo que hace.” Analizar una copia preservada fuera de línea y asumir que cada solicitud podría desencadenar lógica atacante.
Cómo verificar la reparación
- No quedan archivos ejecutablas en los directorios de medios de escritura.
- El servidor rechaza los intentos de ejecución bajo carga.
- El monitoreo no muestra recreación y la ruta de escritura original está cerrada.
Que el síntoma visible desaparezca no es suficiente. Cierra la incidencia solo cuando la acción original que fallaba, el recorrido de negocio relacionado y los registros relevantes confirmen que el problema ha desaparecido.