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

Encontrar Entrada Persistencia

Cómo documentar el punto de entrada más probable sin adivinar

Documenta la entrada probable usando cronologías, versiones, peticiones, cuentas, niveles de confianza y explicaciones alternativas.

Los informes suelen convertir el primer síntoma en causa: «el plugin estaba desactualizado» o «la contraseña era débil». Una conclusión útil conecta los eventos fiables con una capacidad y declara qué no puede probarse.

Construye una cronología, compara hipótesis y asigna confianza.

Separa hechos e interpretaciones

Son hechos la versión instalada, ruta y estado de petición, login correcto, hora de creación de usuario, hash o cambio de archivo y alerta del proveedor. Las interpretaciones los conectan con una posible entrada.

Etiqueta cada afirmación. No uses la fecha de detección del escáner como hora del ataque sin logs. Trabaja en una zona horaria y referencia las fuentes.

Define la actividad más antigua

Retrocede desde redirecciones, spam o administradores hasta el primer archivo, cuenta, petición o configuración. Compara con la última copia fiable y la retención de logs.

Acciones posteriores pueden usar logins normales o herramientas subidas y ocultar el origen. No confundas el payload más visible con la entrada. Registra el límite de evidencia disponible.

Construye hipótesis candidatas

Incluye explotación anónima de plugin, sesión WordPress robada, hosting/SFTP, herramienta MySQL pública, toma del correo o despliegue inseguro de staging.

Para cada opción, lista evidencia esperada y presente. Añade alternativas legítimas como un despliegue autorizado o una migración fallida. No reproduzcas exploits en producción.

Valida si aplica la vulnerabilidad

Para plugins o temas, registra versión, fuente, estado activo, configuración, requisitos y cronología de divulgación.

Un aviso para otra versión o que exige administrador no explica por sí solo ejecución anónima. Ser vulnerable demuestra exposición, no explotación. Referencia el aviso fiable en el informe interno.

Correlaciona cuentas

Revisa usuarios, sesiones, restablecimientos, claves y contraseñas de aplicación en WordPress, hosting, correo y DNS. Compara accesos correctos con cambios maliciosos.

IP o país son contexto, no prueba de identidad. VPN, redes compartidas y sesiones robadas complican la atribución. Conserva IDs antes de revocar.

Correlaciona evidencia técnica

Relaciona peticiones web, cambios de archivos o base, cron, correo y dominios salientes. Usa hashes, IDs y horas sin compartir payloads o clientes.

Las fechas de archivos pueden manipularse y MySQL puede usar otra zona horaria. Prefiere varias fuentes independientes y declara huecos de logging.

Busca contradicciones

Pregunta si cada causa existía antes de la primera actividad y si otorgaba los permisos observados. Revisa zona horaria, deriva del reloj, fechas restauradas y rotación.

Si el plugin se instaló después del primer usuario malicioso, no fue la entrada original. Si un acceso al hosting precede todo WordPress, los logs de aplicación quizá solo muestran acciones posteriores. Registra las contradicciones.

Asigna confianza y alternativas

Usa expresiones como confirmado, muy probable, plausible o indeterminado con una justificación breve. Incluye la alternativa más fuerte y la evidencia que permitiría distinguirla.

No conviertas etiquetas en porcentajes sin método. No nombres a una persona cuando solo identificas una cuenta. Actualiza la conclusión si llegan nuevos logs.

Haz el informe reproducible

Referencia nombres de logs, criterios de búsqueda, hashes, avisos y IDs de capturas para que otro técnico pueda verificar. Guarda originales por separado y restringidos.

No pegues payloads ni datos personales en la narrativa. Los ejemplos censurados deben conservar horas e IDs de correlación. Define fecha de revisión si faltan datos del proveedor o dispositivo.

Conecta la conclusión con controles

Indica qué se parcheó o retiró, credenciales rotadas, persistencia revisada, sistemas afectados y monitorización añadida. Cierra todas las rutas plausibles de alto impacto, no solo la hipótesis preferida.

Conserva evidencias según el proceso y minimiza datos personales. Si la causa afecta al alcance legal o hay reinfección, solicita revisión especializada compartiendo cronologías, versiones y fuentes censuradas, nunca exploits o claves.

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