Evaluación inicial sin contraseñas Presupuesto antes de intervenir Especialista responsable de principio a fin

Hosting Dns Containment

Qué preguntar al hosting durante un incidente de malware WordPress

Solicita evidencias, contención, alcance, acceso de recuperación y criterios de validación durante un incidente WordPress.

El hosting puede detectar archivos, suspender la cuenta o restaurar una copia, pero el proveedor y quien limpia WordPress observan capas distintas. Las preguntas precisas conservan evidencia y evitan el ciclo de «escáner limpio» seguido de reinfección.

Abre un único ticket desde el canal verificado y registra horas y zonas horarias.

Pregunta qué activó la alerta

Solicita rutas exactas, nombres de detección, primera y última aparición, hashes y si se observó phishing, descargas, spam, abuso de recursos o conexiones salientes.

Pregunta si los archivos fueron eliminados, puestos en cuarentena o solo reportados. Conserva el informe original.

No pidas muestras maliciosas por correo; utiliza el proceso seguro de cuarentena o recuperación.

Aclara el alcance de cuenta y servidor

Pregunta qué suscripción, usuario del sistema y webs están afectados y si existen indicadores similares en el servidor. Confirma si funcionó el aislamiento.

Solicita la revisión de accesos de panel, FTP, SFTP, SSH, gestor de archivos y API. Pregunta por cron privilegiado y directivas PHP prepend sospechosas.

El cliente de hosting compartido puede no ver evidencias disponibles para el proveedor.

Solicita conservación de logs

Pide retener logs de acceso y error web, PHP, autenticación, cambios de archivo, correo y panel durante la ventana del incidente.

Confirma duración de retención, zona horaria y método seguro de exportación. Pueden contener datos personales o tokens, así que solicita solo campos relevantes y protege la copia.

No actives retroactivamente logs detallados de cuerpos en una tienda viva.

Acuerda contención y acceso de recuperación

Averigua si la cuenta está suspendida, en solo lectura o disponible por SFTP, SSH o cuarentena. Pregunta cómo servir un aviso limpio sin ejecutar PHP infectado.

Solicita snapshots de archivos y bases antes de remediar. El acceso de recuperación debe ser individual y temporal.

No pidas reactivar públicamente todo solo para entrar a wp-admin.

Comprende los criterios de reparación

Pregunta qué evidencia exige el proveedor para reanalizar y reactivar: rutas eliminadas, componentes actualizados, rotación, revisión de toda la cuenta y periodo de observación.

Averigua cómo apelar falsos positivos en código propio o comercial legítimo.

Superar el escáner del hosting no sustituye revisar base, usuarios, cron y vía de entrada.

Pregunta qué no puede verificar

Aclara si el escáner inspecciona filas de base, usuarios, cron, contraseñas de aplicación, CDN, Workers, DNS, cuentas de correo y gestores de etiquetas. Pregunta si atribuye escrituras o solo detecta contenido después.

Registra evidencias no disponibles y lagunas de retención. Así, cerrar el ticket como «limpio» no se confundirá con una prueba sobre capas nunca examinadas.

Pregunta quién es responsable del sistema operativo, servidor web y aislamiento, y cómo escalar si varios usuarios muestran el mismo indicador.

Consulta las copias con cuidado

Solicita fechas, origen, integridad y cobertura de archivos y bases. Pregunta si las copias antiguas fueron analizadas o pueden contener el mismo indicador.

No sobrescribas el estado actual sin una instantánea. Restaura primero en aislamiento, nunca directamente sobre producción.

Confirma que los backups están fuera de directorios públicos.

Coordina correo, DNS y CDN

Pregunta si aparecieron buzones o reenvíos, cambios DNS o spam saliente. Si el proveedor gestiona DNS o CDN, solicita logs y exportaciones de configuración.

Comprueba si la caché sirve HTML infectado después de limpiar el origen.

Protege el correo del propietario utilizado para restablecer el hosting.

Cierra con un traspaso escrito

Entrega un resumen: causa o evidencias, webs limpiadas, paquetes sustituidos, acciones sobre credenciales, aislamiento y verificación. Solicita resultado final del análisis y limitaciones restantes.

Pide ayuda especializada si no ofrecen recuperación, hay varias suscripciones o puede existir compromiso privilegiado. Solicita un número de incidente y conserva la respuesta con el manifiesto.

Una buena coordinación produce una cronología compartida y un límite limpio verificado, no análisis duplicados sin explicación.

ANTES DE ENVIAR LA SOLICITUD

Preguntas frecuentes.

¿Pedís contraseñas en el formulario?+

No. El formulario público nunca solicita accesos. Los datos seguros se piden únicamente después de aprobar el alcance y el presupuesto.

¿Quién revisa la incidencia?+

La solicitud llega a Jordi Ensenyat, fundador de Code Barcelona y especialista WordPress con más de 15 años de experiencia.

¿Se cambia algo antes del presupuesto?+

No. Primero se revisan los síntomas visibles y se define el alcance. La intervención empieza tras la aprobación y con una vía de vuelta preparada.

¿Trabajáis con webs en inglés y fuera de España?+

Sí. WP Repair atiende incidencias WordPress y WooCommerce en inglés y español, con servicio remoto.

Evaluar mi incidencia