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

Copias Restauracion Verificacion

Cómo demostrar que la recuperación de una web hackeada está completa

Demuestra la recuperación con evidencias de contención, código y datos fiables, entrada cerrada, accesos rotados y funciones probadas.

La recuperación no termina porque cargue la portada o un escáner no detecte malware. Hay que demostrar que cesó el comportamiento malicioso, código y datos son fiables, se recuperó el control, se cerró la entrada y funciona el negocio.

Utiliza un registro de aceptación con responsables e incertidumbres.

Demuestra la contención

Registra cuándo dejaron de ocurrir redirects, phishing, spam, riesgo de checkout o acceso no autorizado y qué control lo impidió. Confirma raíces infectadas sin ejecución y sesiones o tokens desconocidos revocados.

Contener no demuestra limpieza. Mantén rollback y suspensión rápida al reabrir y reconcilia el intervalo afectado.

Demuestra la procedencia del software

Lista núcleo, plugins, temas y desarrollo propio con versión, fuente y responsable. Compara paquetes mantenidos con releases fiables y código propio con repositorios revisados.

Documenta componentes abandonados retirados y su sustituto. El código sin propietario no entra en producción. Conserva checksums sin payloads.

Demuestra integridad de datos y uploads

Revisa administradores, roles, contraseñas de aplicación, opciones, cron, snippets, redirects, entradas, plantillas y tablas propias. Valida medios y bloquea ejecutables cuando corresponda.

Registra filas y archivos maliciosos retirados y rollback. Un escaneo por palabras no demuestra que toda MySQL esté limpia. Protege pedidos y formularios.

Demuestra que se cerró la entrada

Indica vector confirmado o probable, evidencia, confianza y alternativas. Registra componentes corregidos, rotaciones y cambios de arquitectura que cierran todas las rutas plausibles de alto impacto.

Si no se conoce la entrada, documenta controles amplios y monitorización sin fingir certeza. Revisa staging y webs hermanas.

Demuestra la seguridad del plano de control

Confirma usuarios y tokens aprobados de WordPress, hosting, SSH/SFTP, MySQL, correo, DNS/CDN, repositorios y pagos. Registra MFA, cierre de sesiones y rotaciones sin valores secretos.

Revisa copias y despliegues para que no restauren malware o bypasses. Elimina accesos temporales y usa identidades individuales con privilegio mínimo.

Crea una matriz requisito-evidencia

Lista cada requisito —redirección eliminada, usuario ajeno retirado, plugin sustituido, cola conciliada— y enlázalo con una comprobación autoritativa, responsable y fecha.

Marca pass, fail, incompleto o no disponible. Un escáner o una página limpia no sustituye pruebas que no cubre. Conserva IDs censurados para repetir el control.

Demuestra integridad empresarial

Prueba login y reset, formularios, checkout sandbox, pagos y webhooks, pedidos, stock, reembolsos, cron, correo, uploads, móvil, idiomas y analytics.

Reconcilia pedidos, leads y usuarios de ventanas de copia, incidente y corte. Un responsable debe aprobar excepciones. No uses tarjetas reales ni leads incontrolados.

Reproduce condiciones originales

Prueba referrer de búsqueda, móvil, primera visita, ciclos cron, calentamiento de caché y login administrador que activaban síntomas.

Monitoriza cambios de archivos, base y cuentas. Confirma que no vuelven indicadores o dominios salientes. Repite desde DNS público después del corte.

Confirma copias y despliegues

Genera una copia nueva protegida y prueba su restauración aislada. Retira malware y bypasses de repositorios y automatizaciones.

Verifica que el siguiente despliegue no sobrescribirá secretos o devolverá componentes retirados. Registra release limpio y hora de copia, separados de la evidencia.

Registra verificación externa

Conserva revisiones del hosting, recuperación del correo, estado del proveedor de pagos y Search Console cuando apliquen. Apoyan, pero no sustituyen las pruebas internas.

Anota fecha, ID y alcance sin datos sensibles. Confirma que las alertas llegan por un canal independiente.

Obtén revisión independiente cuando proceda

Checkout comprometido, posible acceso a clientes, cambios root o reinfección justifican una segunda revisión cualificada. Entrega la matriz, no solo el resumen del limpiador.

Resuelve discrepancias y documenta aceptación de riesgo. La independencia importa especialmente si el mismo técnico diseñó corrección y prueba.

Define monitorización posterior

Asigna responsables y umbrales para administradores nuevos, cambios, cola cron, correo, tráfico saliente e indicadores. Revisa tras intervalos significativos.

Documenta riesgos residuales y fecha de reevaluación. Si hay pagos, clientes o recurrencia, solicita revisión urgente compartiendo la matriz y acceso gestionado, nunca archivos o bases públicas.

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