Categoría: Seguridad Web

Si tienes un sitio web en Chile y ya instalaste un banner de cookies, es probable que creas que tu trabajo sobre la Ley 21.719 terminó ahí. En menos de 10 segundos te demostraré por qué eso es un error: si tu banner dice “Usamos cookies. Aceptar”, no estás pidiendo permiso, estás confesando que ya violaste la privacidad del usuario.

El 1 de diciembre de 2026 entra en vigencia plena la Ley 21.719. Las multas por incumplimiento técnico llegan hasta los 100 millones de pesos o el 4% de los ingresos brutos anuales.

El error más común no es no tener banner, sino tener uno que es puro decorado. Diseñar una interfaz bonita no sirve de nada si por debajo de esa capa visual tu sitio web está filtrando datos a Meta y Google sin permiso. El lujo en la web no es una etiqueta estética, es una experiencia completa de seguridad, velocidad y respeto por el usuario.

La conveniencia no puede estar peleada con el sentido común

Para el marketing, es muy “conveniente” rastrear al usuario apenas entra a la página para saber qué hace. Pero ese sentido común comercial choca de frente con la ley.

La Ley 21.719 exige consentimiento previo, libre, informado y expreso. Si el tracking ya se activó cuando aparece el aviso, tu banner es una burla. Es como entrar a la casa de alguien, sentarte en el sofá a comer de su refrigerador y, cuando te descubre, decirle: “Ah, voy a estar aquí, ¿te parece?”. No le diste la opción de decir que no antes de entrar.

Cómo se ve un banner que NO cumple (y por qué te hace ver mal)

Si tienes que explicarle a la gente por qué tu sitio es seguro, ya perdiste. Un sitio que cumple se nota solo. Estos son los patrones que delatan un banner inútil:

• El botón “Aceptar todo” brilla y el “Rechazar” no existe o es un enlace minúsculo. Si rechazar las cookies lleva más clics que aceptarlas, no es consentimiento libre.
• El cerrar la ventana (la “X”) o seguir navegando cuenta como aceptación. El silencio no es consentimiento. Si el usuario cierra el banner, debe interpretarse como un rechazo.
• El banner solo aparece después de un scroll. Si el usuario tuvo que bajar para ver el aviso, ya dejó rastros de su visita en servidores de terceros.

Un sitio que hace esto transmite una cosa: desorden técnico y desinterés por la privacidad.

Cómo se ve uno que sí cumple (la experiencia premium)

Un sitio que realmente cumple con la normativa ofrece una experiencia impecable:

1. Aparece de inmediato, bloqueando la interacción hasta que el usuario toma una decisión.
2. Tiene dos botones con el mismo peso visual: “Aceptar todo” y “Rechazar todo”.
3. No carga ningún script de terceros hasta que el usuario hace clic en “Aceptar”.

Ese es el estándar de un sitio corporativo que cuida su marca y a sus clientes. No es un plugin gratuito instalado en cinco minutos; es infraestructura de confianza.

Cómo comprobarlo tú mismo en 30 segundos

No necesitas saber de código para auditar esto hoy. Hay dos caminos.

El método simple (ventana de incógnito + navegador)

1. Abre tu sitio web en una ventana de incógnito de Chrome o Edge.
2. Antes de hacer cualquier clic, presiona F12 (o clic derecho > “Inspeccionar”).
3. Ve a la pestaña Network (Red) y recarga la página (F5).
4. En la barra de búsqueda de esa pestaña, escribe: analytics, gtag, fbevents o collect.

Si ves que el navegador está cargando archivos que coinciden con esos nombres antes de que hagas clic en “Aceptar” en tu banner, tu sitio no cumple. El rastreo ya comenzó sin tu permiso.

Si eso te suena a chino: qué pedirle a quien te hizo la web

Si las herramientas de desarrollador no son lo tuyo, está bien. Escribe un correo a tu agencia o desarrollador y hazles esta pregunta exacta:

“¿Nuestro sitio web bloquea la ejecución de scripts de terceros (como Google Analytics o el píxel de Meta) hasta que el visitante hace clic en Aceptar en el banner de cookies?”

Si la respuesta es “no”, “es muy complicado” o “no se puede”, tu sitio no cumple y estás expuesto a multas.

Los scripts que más se disparan antes del consentimiento

En mis auditorías de seguridad, estos son los “invitados” que más veces encuentro colándose en la fiesta antes de que el portero (el banner) les pida el carnet:

• Google Analytics (gtag.js): El rastreador más común. Recoge datos de tráfico y comportamiento.
• El píxel de Meta (Facebook): Trata datos personales con fines publicitarios.
• Google Tag Manager (GTM): Si GTM se carga antes del consentimiento, todo lo que tenga adentro también se está ejecutando.
• Mapas de Google y Chats en vivo: Guardan datos de ubicación y comportamiento apenas entra el visitante.

Por qué implementar el bloqueo previo no es gratis ni automático

Los consumidores (y muchos dueños de negocios) tampoco entienden la tecnología detrás del banner. ¿Para qué sirve exactamente? ¿Por qué cuesta dinero arreglarlo si el plugin era gratis?

Arreglar esto no es cambiar un texto. Es alterar la forma en que tu sitio web sirve el código. En lugar de cargar los scripts de seguimiento directamente, los “envolvemos” en un contenedor de JavaScript que los pausa. El navegador los descarga, pero no los ejecuta. Solo cuando el usuario hace clic en “Aceptar”, el contenedor desbloquea los scripts. Si hace clic en “Rechazar”, se destruyen.

Existen plugins que prometen hacer esto, pero requieren una configuración rigurosa para que no rompan el diseño ni el rendimiento. En sitios construidos con arquitecturas de alto rendimiento (como brante.dev, que usa Astro consumiendo WordPress por REST), bloqueamos los scripts en el servidor o usamos Consent Mode v2 en modo básico, que no carga las etiquetas de Google hasta que la persona acepta.

La conexión mental: de un banner roto a un sitio blindado

Aquí es donde mi trabajo cobra sentido. Cuando un cliente me escribe porque su sitio pierde ventas por lento o porque recibió una notificación de incumplimiento, no le vendo “arreglar el banner”. Le vendo una Auditoría de Seguridad o una Póliza de Mantenimiento que deja su sitio blindado.

El bloqueo previo de scripts no solo te salva de una multa de 100 millones de pesos; también mejora drásticamente tus tiempos de carga (WPO) y tu puntaje en PageSpeed, porque dejas de cargar código innecesario que ralentiza el sitio. Seguridad y rendimiento son las dos caras de la misma moneda.

Preguntas frecuentes

¿Es obligatorio tener un banner de cookies en Chile?

Sí, si tu sitio web utiliza herramientas que recogen datos personales mediante cookies (analítica, marketing, formularios). La Ley 21.719 exige que obtengas el consentimiento del usuario antes de tratar esos datos.

¿Cuánto es la multa por no cumplir la Ley 21.719?

Las multas administrativas pueden llegar hasta 100 millones de pesos o el 4% de los ingresos brutos anuales del responsable, lo que sea mayor. Además, la Agencia puede ordenar el cese del tratamiento de datos.

¿Puedo usar un banner que dice “Seguir navegando” como aceptación?

No. El consentimiento no puede presumirse por acciones pasivas del usuario como seguir navegando o cerrar el aviso. Debe ser una acción afirmativa (un clic en “Aceptar”).

¿Las cookies esenciales también necesitan consentimiento?

No. Las cookies estrictamente necesarias para el funcionamiento del sitio (como las del carrito de compras o la seguridad de la conexión) no requieren consentimiento, pero sí deben declararse en la política de cookies.

¿Qué hago si mi banner no bloquea los scripts?

Debes contactar a un desarrollador para que implemente el bloqueo previo al consentimiento. Para revisar el estado técnico general de tu sitio hoy, puedes usar mi Escáner de cumplimiento Ley 21.719.

---

Si hiciste la prueba de los 30 segundos y descubriste que tu banner es solo decoración, no esperes a diciembre. Revisa de inmediato el estado técnico de tu sitio con mi Escáner de cumplimiento Ley 21.719. Te dará una nota de la A a la F en segundos.

Escanear mi sitio ahora

Nota honesta: En brante.dev cubro la adecuación técnica de tu sitio (bloqueo de scripts, cifrado, cabeceras de seguridad). La parte legal —redacción de la política de privacidad por un abogado o el registro en la Agencia— requiere revisión de un especialista legal, y te indicaré con claridad dónde termina mi alcance.

Hace unos días abrí Google Search Console para revisar cómo iba la indexación de mi blog y me encontré con algo que no esperaba: treinta páginas de casinos online, en polaco, ruso, azerí, checo e italiano, publicadas dentro de uno de mis propios subdominios. Mostbet, 1xbet, Pin-Up, Vavada. Ninguna la había creado yo.

Escribo sobre seguridad WordPress. Tengo una herramienta forense propia y una guía publicada sobre cómo detectar un sitio comprometido. Y aun así, esto me pasó a mí. Lo cuento porque el diagnóstico final terminó siendo bastante más interesante que el incidente en sí: el problema real no estaba en WordPress ni en un plugin desactualizado. Estaba en una configuración de DNS que llevaba meses ahí, a la vista, y que yo mismo había dejado pasar.

Cómo lo detecté (y por qué no fue un plugin)

No me avisó ningún sistema de monitoreo. No saltó una alerta. El subdominio comprometido no tenía instalado ningún plugin de seguridad, ni Wordfence ni ningún otro, porque era un proyecto abandonado que en mi cabeza “no existía”.

Lo detecté en Google Search Console, revisando el informe de páginas no indexadas. Ahí, mezcladas entre mis páginas legítimas marcadas con noindex, aparecían decenas de URLs con títulos como “Najpopularniejsze promocje Mostbet” o “Aktual’noe zerkalo Vavada na segodniashnii den’”, todas colgando de un subdominio mío.

Ese detalle es la primera lección del incidente: el sistema que me avisó no fue una herramienta de seguridad, sino una de SEO. Google rastreó, indexó y me reportó contenido que yo no había publicado. Si no hubiera estado revisando Search Console por otro motivo, ese spam podría haber seguido creciendo durante meses sin que nadie lo notara.

El método que uso y recomiendo para verificar esto en cualquier sitio es el más simple que existe: buscar en Google site: seguido del dominio. Si aparecen páginas que tú nunca creaste, hay una inyección de contenido activa. Toma diez segundos y no requiere instalar nada.

Qué era ese subdominio (y por qué eso importa)

El subdominio comprometido alojaba un SaaS que había empezado a construir hacía meses y que nunca llegué a usar. Un WordPress levantado para prototipar, sin tráfico, sin usuarios, sin datos de clientes, sin plugins de seguridad y —lo más relevante— sin nadie mirándolo.

Esto encaja con un patrón que veo constantemente en las auditorías que hago: el problema casi nunca está en el sitio principal, el que el dueño revisa todos los días. Está en el proyecto paralelo, el entorno de pruebas, la versión antigua que quedó arriba “por si acaso”, el subdominio de una campaña que terminó hace dos años.

Y hay algo que conviene entender sobre este tipo de ataques: al atacante no le interesaba mi contenido. No buscaba robarme información ni tumbarme el sitio. Buscaba un servidor con reputación de dominio donde publicar enlaces de casino para posicionarlos en Google. Es un ataque de Blackhat SEO puro, automatizado, indiscriminado, y el objetivo era usar mi infraestructura como plataforma de publicación.

Por eso da lo mismo que un proyecto “no tenga nada valioso”. El valor no está en lo que guardas: está en que el servidor existe, responde y tiene un dominio con historial.

El diagnóstico real: el problema no era WordPress

Acá es donde el caso se pone interesante, y donde encontré algo que la mayoría de las guías sobre sitios hackeados no cubre.

Mi primer instinto fue el de siempre: revisar la versión de WordPress, buscar plugins vulnerables, auditar usuarios administradores. Todo eso es correcto y hay que hacerlo. Pero cuando fui a revisar la configuración de DNS en Cloudflare, encontré la causa estructural.

Mis registros DNS se veían así:

Subdominio	Estado
Dominio principal	Redirigido mediante proxy ✅
WordPress principal	Redirigido mediante proxy ✅
Subdominio del SaaS	Solo DNS ❌
Otro subdominio antiguo	Solo DNS ❌

En Cloudflare, cada registro DNS puede estar en dos modos. “Redirigido mediante proxy” (la nube naranja) significa que todo el tráfico pasa primero por la red de Cloudflare: se aplica el firewall de aplicación, el límite de peticiones, la protección contra ataques automatizados, y —crucialmente— la dirección IP real de tu servidor queda oculta detrás de la de Cloudflare.

“Solo DNS” (la nube gris) significa que Cloudflare únicamente resuelve el nombre y se aparta. No filtra nada. El visitante —o el bot— llega directo a tu servidor.

Mi subdominio comprometido estaba en “Solo DNS”. Sin firewall, sin filtro, sin límite de peticiones. Un WordPress desatendido, expuesto de forma directa a internet.

La consecuencia que casi nadie considera

Pero el problema de fondo es peor que eso, y me tomó un momento darme cuenta.

Cuando un solo subdominio está en modo “Solo DNS”, su registro revela públicamente la dirección IP real de tu servidor de origen. Cualquiera puede consultarlo con una herramienta pública de DNS en segundos.

Y si ese servidor aloja además otros sitios que sí están protegidos por proxy, esa protección se puede saltar por completo: basta con atacar la IP directamente, ignorando el nombre de dominio. Todo el trabajo de configurar el firewall, las reglas de seguridad y el proxy queda anulado por un único registro mal configurado en un proyecto que ya no usabas.

En mi caso, en ese mismo servidor conviven otros dos sitios, uno de ellos de un cliente. Un subdominio olvidado no solo se comprometió a sí mismo: expuso la infraestructura completa.

⚠️ ¿Tienes subdominios que ya no usas? Si tienes entornos de prueba, versiones antiguas o proyectos abandonados apuntando a tu servidor, escríbeme por WhatsApp y revisamos juntos cuáles están expuestos. Es una revisión de quince minutos que puede ahorrarte un incidente completo.

Qué hice: contención en cuatro pasos

Apliqué el mismo protocolo que recomiendo en mi guía sobre qué hacer en las primeras horas tras un hackeo, con una diferencia importante que explico más abajo.

Paso 1: Respaldo forense antes de tocar nada. Descargué una copia completa del estado infectado —archivos y base de datos— a mi computador local. Aunque contenga malware, ese respaldo es la única evidencia disponible para analizar después cómo se produjo la intrusión. Borrar primero y preguntar después destruye información que no se recupera.

Paso 2: Revisión del resto de la infraestructura. Antes de limpiar el sitio comprometido, verifiqué si el atacante había saltado lateralmente a los otros sitios del mismo servidor. Cuando varios proyectos comparten un servidor, una intrusión en uno puede escalar a los demás según cómo estén configurados los permisos. Esta revisión es más urgente que limpiar el sitio afectado: si hay propagación, limpiar solo uno es inútil.

Paso 3: Eliminación completa. Acá tomé una decisión que va contra el instinto: no limpié el sitio, lo borré entero. Panel de control, base de datos, usuario del sistema y archivos.

Paso 4: Rotación de credenciales. Cambié las contraseñas de todo el panel de administración del servidor, los accesos SSH, y las credenciales de los otros sitios alojados. Cuando un servidor se compromete, hay que asumir que el atacante pudo ver más de lo que dejó a la vista.

Por qué borré en vez de limpiar

Esta es la parte que suele generar discusión, así que la explico con criterio.

Limpiar un WordPress comprometido bien hecho toma horas: hay que reemplazar el núcleo, auditar la base de datos tabla por tabla buscando inyecciones ofuscadas, revisar los archivos de configuración, verificar que no quedaron puertas traseras en la carpeta de cargas. Y aun haciéndolo con rigor, siempre queda la duda. Los ataques de Blackhat SEO suelen dejar varios puntos de reentrada, y basta que sobreviva uno para que el sitio se reinfecte en días.

Ese esfuerzo se justifica cuando el sitio tiene valor: contenido, historial de posicionamiento, usuarios, datos de clientes. En mi caso, no tenía nada de eso. Era un prototipo abandonado.

La regla que aplico es simple: si el costo de reconstruir es menor que el costo de limpiar con certeza, se reconstruye. Cuando el sitio sí tiene valor —una tienda con historial de ventas, un sitio corporativo con años de posicionamiento— la ecuación se invierte y ahí sí corresponde el trabajo forense completo.

Lo que cambié después (y lo que deberías revisar tú)

El incidente cerró con un inventario que debí haber hecho hace mucho:

Auditoría completa de registros DNS. Revisé los catorce registros del dominio uno por uno y respondí tres preguntas para cada uno: ¿esto sigue vivo?, ¿está en proxy o expuesto directo?, ¿alguien lo está mirando? Los que no pasaron el filtro, se eliminaron.

Eliminación de subdominios huérfanos. Encontré un segundo subdominio apuntando al servidor sin ningún sitio asociado, probablemente residuo de una configuración antigua. Cada registro DNS que no cumple una función activa es superficie de ataque gratuita.

Proxy obligatorio. Todo subdominio que apunte a mi servidor va con proxy activado. Sin excepciones, aunque sea un entorno de pruebas.

Restricción a nivel de firewall. El servidor ahora acepta tráfico web únicamente desde los rangos de IP de Cloudflare. Aunque alguien conozca la dirección de origen, no puede llegar al puerto web saltándose el proxy.

Retirada de URLs en Search Console. Solicité la eliminación del índice de todas las URLs de spam. Google las retira solo con el tiempo, pero la solicitud acelera bastante el proceso.

Sobre la Ley 21.719: por qué en este caso no aplicó

Vale la pena aclarar este punto, porque en la mayoría de los incidentes sí aplica.

La Ley 21.719 de Protección de Datos Personales establece que, ante una vulneración que comprometa datos personales, existe la obligación de notificar a la Agencia de Protección de Datos Personales en un plazo máximo de 72 horas desde que se toma conocimiento del hecho. El Artículo 34 quáter califica la omisión intencional de reportar como infracción gravísima, con multas de hasta 20.000 UTM.

En este caso concreto no se activó esa obligación, y la razón es una sola: el subdominio comprometido no almacenaba datos personales de terceros. Era un prototipo sin usuarios, sin formularios activos y sin base de clientes.

Si el mismo ataque hubiera ocurrido en un sitio con formularios de contacto, una tienda con clientes registrados o una base de suscriptores, la situación sería completamente distinta: además del trabajo técnico de contención, habría que evaluar el alcance de la exposición y cumplir con el deber de notificación dentro del plazo legal.

Es un matiz que conviene tener claro antes de que la fiscalización comience en diciembre de 2026. La obligación no depende de la gravedad técnica del ataque, sino de si había datos personales involucrados.

Lo que no sé (y por qué lo digo)

Hay algo que este artículo no puede responder: no tengo certeza del vector exacto de entrada.

Sé que era un WordPress desatendido, sin proxy, sin plugins de seguridad y sin actualizaciones recientes. Cualquiera de esas condiciones basta para explicarlo, y probablemente fue una combinación. Pero no puedo afirmar con precisión forense por dónde entraron ni cuánto tiempo estuvieron dentro antes de que Google indexara el primer contenido.

Lo digo explícitamente porque encontrarás muchas guías que reconstruyen ataques con un nivel de certeza que rara vez se tiene en la práctica. Cuando un sitio no tiene registros de acceso conservados ni monitoreo previo, buena parte del análisis posterior es inferencia razonable, no evidencia.

Y esa es, quizás, la lección más incómoda del incidente: no tener visibilidad no solo te impide prevenir el ataque, también te impide entenderlo después.

Preguntas frecuentes

¿Puede pasarme esto si mi sitio no tiene nada valioso? Sí, y de hecho es el escenario más frecuente. Los ataques de Blackhat SEO no buscan tu información: buscan un servidor con dominio activo donde publicar contenido. Un sitio sin tráfico y sin datos es igual de útil para ese propósito, y suele estar peor protegido.

¿Qué significa exactamente que un subdominio esté en “Solo DNS”? Significa que Cloudflare resuelve el nombre pero no filtra el tráfico. No se aplica el firewall de aplicación ni la protección contra bots, y la dirección IP real de tu servidor queda visible públicamente. Es equivalente a tener el servidor conectado directamente a internet.

¿Un plugin de seguridad habría evitado esto? Probablemente habría ayudado a detectarlo antes, pero no era el problema de fondo. Un plugin de seguridad opera dentro de WordPress; la exposición estaba en la capa de red, por debajo. Ninguna cantidad de plugins compensa una infraestructura mal configurada.

¿Cómo reviso si tengo subdominios expuestos? Entra al panel de DNS de tu proveedor y revisa el estado de cada registro. En Cloudflare, los que aparecen como “Solo DNS” o con la nube gris están expuestos directo. Para cada uno, pregúntate si sigue cumpliendo una función: los que no, se eliminan.

¿Es necesario borrar un sitio comprometido o basta con limpiarlo? Depende del valor de lo que hay dentro. Si el sitio tiene contenido, posicionamiento, usuarios o datos de clientes, corresponde una limpieza forense completa. Si es un proyecto sin uso, reconstruir suele ser más rápido y más seguro que limpiar con certeza.

Cómo revisar tu propia infraestructura hoy

Para auditar el estado real de un sitio uso cinco herramientas gratuitas y públicas: PageSpeed Insights, Mozilla Observatory, SSL Labs, SecurityHeaders y Sucuri SiteCheck. Cualquiera puede correrlas y te dan una radiografía inicial del nivel de riesgo técnico.

A eso agrégale dos revisiones que la mayoría no hace y que en este caso fueron determinantes: buscar site:tudominio.cl en Google para detectar contenido inyectado, y auditar tus registros DNS uno por uno verificando cuáles están expuestos directo y cuáles corresponden a proyectos que ya no existen.

Si prefieres ahorrarte la interpretación de métricas, construí un escáner en mi sitio que consolida el análisis de rendimiento y los requisitos técnicos de la Ley 21.719 en un solo informe, con los datos que Google usa para evaluar tu sitio en conexiones móviles.

Y si al revisar tus subdominios encuentras algo que no te cuadra —un entorno de pruebas que quedó arriba, una versión antigua que nadie mira, un registro que no sabes de dónde salió— escríbeme por WhatsApp o agenda una sesión de diagnóstico. Esa revisión toma menos de lo que uno cree, y es exactamente el tipo de problema que solo se ve cuando alguien se sienta a mirarlo.

Si acabas de confirmar que tu sitio web redirige a páginas de apuestas, muestra avisos rojos de advertencia en el navegador o tiene usuarios administradores que tú jamás creaste, guarda la calma. Es una situación agobiante, pero actuar con cabeza fría en las próximas dos horas definirá cuánto tiempo y dinero te costará resolverlo. Si anteriormente revisaste nuestra guía sobre las 5 señales para detectar si tu WordPress está hackeado y confirmaste el compromiso de tu plataforma, ha llegado el momento de ejecutar un protocolo de contención ordenado.

Lo que hagas en este momento define el impacto en tu negocio. El error más caro y común es reaccionar por impulso: cambiar la contraseña del panel, borrar un par de archivos a ciegas y asumir que el problema está solucionado. Limpiar una plataforma no es un proceso de adivinanza; requiere pasos estructurados para aislar la amenaza, resguardar la evidencia técnica y evitar que la página se vuelva a infectar a las pocas horas.

Primero, no hagas esto (Los 5 errores que empeoran la crisis)

Cuando cunde el pánico, es muy fácil tomar decisiones que destruyen evidencia clave o dejan la plataforma inoperativa de forma permanente. Antes de modificar cualquier archivo, evita cometer estos cinco errores destructivos:

1. Borrar archivos a ciegas desde el servidor: Eliminar carpetas con nombres extraños sin conocer la arquitectura interna de WordPress suele romper dependencias esenciales del sistema o dejar intacto el script malicioso que regenera la infección en minutos.
2. Restaurar un respaldo reciente sin auditarlo: El 100% de los sitios que he tenido que recuperar de emergencia contaban con copias de seguridad; el problema es que casi ninguno tenía un respaldo limpio. Si restauras una copia realizada hace tres días pero el atacante ingresó hace un mes, únicamente estarás reinstalando la vulnerabilidad.
3. Cambiar solo la contraseña de WordPress: Si el atacante instaló una puerta trasera (backdoor) en la base de datos o en los archivos del servidor, modificar tu clave desde el panel de control no detendrá su acceso.
4. Reinstalar el tema o los plugins creyendo que eso limpia todo: Aunque descargues versiones oficiales y limpias de tus complementos, el código malicioso suele alojarse en las tablas de la base de datos, en el archivo de configuración .htaccess o dentro de la carpeta /wp-content/uploads/.
5. Poner el sitio en mantenimiento borrando los registros (logs) del servidor: Ocultar la página es correcto, pero reiniciar el servidor o borrar los registros de acceso a nivel de hosting destruye las pruebas que permiten rastrear el vector de entrada original del ataque.

Los 5 pasos inmediatos del protocolo de contención

Para abordar el problema con criterio técnico y sin aumentar el riesgo, sigue esta secuencia ordenada:

Paso 1: Congela la evidencia y realiza un respaldo forense

Antes de editar cualquier línea de código, genera un respaldo completo del estado infectado actual (archivos y base de datos) y descárgalo a tu computador. Aunque contenga malware, este archivo es indispensable para que un especialista pueda analizar los registros (logs) de acceso y determinar cómo se produjo la intrusión.

Paso 2: Cambia accesos desde la infraestructura raíz

Actualiza de inmediato las credenciales de la infraestructura principal, no solo la clave de WordPress. Modifica la contraseña del panel de hosting (cPanel, Plesk o servidor privado), la clave de la base de datos en wp-config.php, los accesos FTP/SFTP y la cuenta de correo vinculada al usuario administrador.

Paso 3: Audita las cuentas de usuario en la base de datos

Ingresa a la base de datos mediante phpMyAdmin o el gestor de tu hosting y revisa la tabla wp_users. Elimina de raíz cualquier cuenta sospechosa con rol de administrador que no reconozcas. Muchos ciberdelincuentes crean usuarios ocultos para mantener el control de la plataforma.

Paso 4: Limpia los archivos del núcleo de WordPress

Descarga una copia limpia de WordPress desde su sitio oficial (wordpress.org) y reemplaza completamente las carpetas /wp-admin/ y /wp-includes/, además de los archivos sueltos de la raíz. Conserva únicamente tu archivo de configuración wp-config.php y la carpeta /wp-content/ tras verificar manualmente que no contengan código inyectado.

Paso 5: Desactiva ejecuciones de código PHP en la carpeta de cargas

La carpeta /wp-content/uploads/ solo debe almacenar archivos multimedia (imágenes, documentos PDF, videos). Jamás debe ejecutar scripts PHP. Para frenar de golpe el funcionamiento de archivos maliciosos en esta área, crea un archivo .htaccess dentro de la carpeta uploads con la regla de bloqueo deny from all o la restricción de ejecución de scripts de servidor.

⚠️ ¿Tu sitio está caído o redirigiendo a páginas de spam? Si prefieres no arriesgar la información de tu negocio en el proceso, escríbeme directamente por WhatsApp para coordinar una contención de emergencia en tiempo real.

Por qué tu sitio se reinfecta (La trampa de las puertas traseras)

Uno de los escenarios más frustrantes para el dueño de un negocio es realizar una limpieza aparente y descubrir que, 24 horas después, la página vuelve a mostrar enlaces de spam o redirecciones móviles. Esto sucede por la presencia de puertas traseras (backdoors).

Una puerta trasera es un fragmento de código de pocas líneas, habitualmente camuflado o codificado en bloques confusos (base64), que el atacante esconde en ubicaciones atípicas de tu servidor. Su única función es otorgar acceso remoto sin requerir autenticación formal.

En ataques complejos de Blackhat SEO —donde se inyectan masivamente enlaces de casino o textos en caracteres cirílicos dentro de la base de datos—, los escáneres automáticos convencionales no logran detectar las firmas ofuscadas. Durante la resolución de un incidente de este tipo, la falta de visibilidad de los complementos comerciales me llevó a construir AG-Probe, una herramienta de diagnóstico forense propia diseñada para rastrear inyecciones invisibles directamente en las tablas SQL y sanitizar el sistema sin corromper la información del cliente.

Si tenías datos de clientes: La obligación legal bajo la Ley 21.719 en Chile

Este es un aspecto que la gran mayoría de las guías técnicas pasa por alto: en Chile, un hackeo dejó de ser un simple problema informático para convertirse en un evento con responsabilidades legales directas.

La Ley 21.719 de Protección de Datos Personales, promulgada a fines de 2024 y con vigencia plena fijada para el 1 de diciembre de 2026, cambia drásticamente las reglas del juego ante incidentes de ciberseguridad. Si tu sitio web almacena información personal de usuarios (a través de formularios de contacto, carritos de compra en WooCommerce o bases de datos de suscriptores) y sufre un compromiso de seguridad, la norma establece exigencias concretas:

• Obligación de notificar en 72 horas: Ante una vulneración que comprometa datos personales, la empresa tiene el deber legal de informar a la Agencia de Protección de Datos Personales en un plazo máximo de 72 horas desde que tuvo conocimiento del hecho.
• Notificación a las personas afectadas: Si la filtración expone información sensible, datos financieros o registros de menores de edad, también se debe comunicar directamente a los clientes impactados.
• Sanciones por ocultar la brecha: El Artículo 34 quáter de la ley califica la omisión intencional de reportar incidentes de seguridad como una infracción gravísima, sujeta a multas de hasta 20.000 UTM (más de $1.430 millones de pesos chilenos) o hasta el 4% de los ingresos anuales de la empresa en casos de reincidencia corporativa.

Recuperar tu reputación en Google (Safe Browsing y Search Console)

Si Google detectó el compromiso antes de que pudieras contenerlo, es muy probable que al ingresar a tu web aparezca la conocida pantalla roja de advertencia (“El sitio al que intentas acceder contiene programas dañinos”) o que en los resultados de búsqueda se muestre la leyenda “Este sitio puede haber sido hackeado”.

Para eliminar estas alertas y recuperar el tráfico orgánico de tu negocio, sigue este procedimiento tras completar la limpieza profunda:

1. Ingresa a Google Search Console: Dirígete a la sección de Seguridad y acciones manuales y selecciona la pestaña Problemas de seguridad.
2. Revisa los detalles señalados: Google mostrará las URLs de muestra donde detectó el software malicioso o las redirecciones no autorizadas.
3. Solicita una revisión formal: Haz clic en el botón Solicitar revisión. En el formulario, explica de forma breve y técnica las acciones realizadas (por ejemplo: “Se reemplazó el core de WordPress, se eliminaron archivos maliciosos en la base de datos, se actualizaron credenciales y se cerraron las vulnerabilidades del servidor”).
4. Plazos de respuesta: El proceso de verificación por parte de los sistemas automáticos de Google suele tardar entre 24 y 72 horas. Una vez confirmado que el sitio está limpio, la advertencia roja se retirará de forma automática.

Hasta acá puedes llegar tú (Y cuándo se requiere una intervención forense)

Las primeras acciones de contención —aislar la plataforma, modificar contraseñas maestras y revisar la lista de usuarios administradores— son tareas que puedes ejecutar directamente para evitar males mayores.

Sin embargo, cuando el ataque involucra inyecciones complejas en la base de datos, redirecciones condicionales que solo se activan en dispositivos móviles o vulnerabilidades estructurales en el entorno de hosting, el trabajo requiere herramientas de diagnóstico especializadas. Intentar “limpiar” a ciegas mediante la instalación masiva de plugins de seguridad suele empeorar la lentitud del sitio y dejar puertas traseras ocultas que reactivarán el problema semanas después.

En proyectos con arquitecturas exigentes, como la recuperación y optimización que llevamos a cabo en el caso corporativo de Wellboat, la clave para recuperar la estabilidad no consistió únicamente en eliminar el código sospechoso, sino en sanitizar la infraestructura y cerrar los vectores de entrada sin comprometer el rendimiento ni la información de la empresa.

Preguntas frecuentes sobre sitios WordPress comprometidos

¿Por qué mi sitio web fue hackeado si tenía un plugin de seguridad instalado?

Los plugins de seguridad son herramientas de supervisión, pero no son infalibles. Si tu servidor utiliza versiones obsoletas de PHP, contraseñas débiles o complementos desactualizados con fallos de seguridad no corregidos, un atacante puede eludir las reglas del plugin e ingresar directamente al sistema.

¿Es seguro restaurar una copia de seguridad para solucionar un hackeo?

Solo es seguro si la copia proviene de una fecha claramente anterior a la intrusión inicial y si, inmediatamente después de restaurarla, se corrigen las vulnerabilidades que permitieron el acceso. Si restauras un respaldo realizado mientras el sitio ya estaba comprometido, mantendrás la infección activa.

¿Cuánto tiempo demora Google en retirar la pantalla roja de advertencia?

Una vez que el sitio está completamente sanitizado y se envía la solicitud de revisión a través de Google Search Console, el proceso de verificación suele tardar entre 24 y 72 horas en completarse.

¿Qué exige la Ley 21.719 en Chile si hubo una filtración de datos de clientes?

La ley exige notificar el incidente de ciberseguridad a la Agencia de Protección de Datos Personales en un plazo máximo de 72 horas desde su detección. Si la brecha involucra datos sensibles, información financiera o registros de menores, también se debe notificar directamente a las personas afectadas.

Cómo evaluar tu sitio en 5 minutos (y tomar el control de tu infraestructura)

Para auditar el estado real de un servidor, su nivel de rendimiento y su postura de seguridad digital, uso habitualmente cinco herramientas gratuitas: PageSpeed Insights, Mozilla Observatory, SSL Labs, SecurityHeaders y Sucuri SiteCheck. Todas son públicas, de libre acceso y te entregarán una radiografía inicial del nivel de riesgo técnico de tu plataforma.

Sin embargo, para ahorrarte el trabajo de interpretar métricas complejas, consolidar gráficos de red y verificar los puntos críticos de consentimiento y trazabilidad que exige la norma, construí un Escáner de Viabilidad Comercial, Cumplimiento y Rendimiento WPO en mi propio portal.

Si deseas conocer el estado real de tu infraestructura antes de que la Agencia de Protección de Datos Personales comience a fiscalizar en diciembre de 2026, te invito a probar mi herramienta de diagnóstico. El sistema analizará tu código en tiempo real, medirá tus Core Web Vitals en conexiones móviles 4G, evaluará los requisitos técnicos de la Ley 21.719 y calculará automáticamente la pérdida de tráfico estimada y la fuga financiera mensual que la lentitud o los problemas de seguridad le están provocando a tu negocio.

Al finalizar, si tu sitio presenta un estado de riesgo crítico o mejorable, puedes escribirme directamente por WhatsApp para atención inmediata de emergencia o agendar una sesión de diagnóstico de 30 minutos directamente en mi calendario de Google Meet. Revisaremos juntos los cuellos de botella exactos de tu base de datos y trazaremos el plan de rescate técnico definitivo.

El mayor mito sobre la seguridad informática es creer que cuando un sitio web es comprometido por un atacante, la página deja de cargar o muestra un mensaje de secuestro con una calavera en la pantalla. En el mundo real del ciberdelito, una web caída o completamente rota no le genera dinero a nadie, por lo que el objetivo principal de los atacantes modernos no es destruir tu página, sino secuestrar de forma silenciosa tus recursos de servidor, aprovechar tu reputación en Google para inyectar enlaces invisibles o interceptar datos de tus formularios sin llamar la atención. Este silencio malicioso hace que la mayoría de los dueños de negocios en Chile descubran la vulnerabilidad semanas o meses después del ataque, cuando los buscadores ya han bloqueado el acceso o las listas negras han comenzado a rebotar sus correos corporativos. Si sospechas que tu WordPress presenta un comportamiento inusual o simplemente quieres asegurarte de que tu infraestructura de ventas está limpia, te presento un análisis técnico de las cinco señales más comunes para detectar si tu sitio tiene virus y cómo auditarlas tú mismo hoy.

1. Redirecciones condicionales (el ataque que no le ocurre a todos)

La primera señal, y una de las más astutas, se manifiesta cuando el sitio web redirige a otra página, pero solo bajo ciertas condiciones. Los ciberdelincuentes inyectan código malicioso en los archivos del núcleo de WordPress o en el archivo de configuración .htaccess del servidor, programándolo para verificar el origen del visitante antes de activar la redirección. Si escribes tu dominio directamente en la barra del navegador, la página cargará con total normalidad, pero si un usuario móvil llega haciendo clic desde Google o redes sociales, el código lo desviará hacia sitios de estafas o apuestas. Además, el script detecta si estás logeado como administrador para desactivar la redirección y evitar que te des cuenta del problema mientras trabajas. Para verificar este síntoma de forma real, abre una ventana de incógnito, emula la navegación desde un dispositivo móvil y haz clic en tu enlace desde un resultado de búsqueda de Google.

2. Resultados basura en Google que tú jamás escribiste (Spam SEO)

La segunda señal, conocida en la industria como Spam SEO o Pharma Hack, consiste en la inyección de miles de páginas basura en tu base de datos con palabras clave sobre fármacos o casinos en línea. Los atacantes aplican una técnica de encubrimiento llamada Cloaking, entregando a Googlebot una versión de tu sitio repleta de enlaces de spam para que los indexe, mientras muestran el diseño limpio y normal a los usuarios humanos. Según los reportes globales de seguridad de Sucuri, el Spam SEO está presente en más del 38% de las webs infectadas en el mundo. Esta inyección destruye rápidamente la autoridad de búsqueda que te tomó años construir. Para auditar tu dominio en segundos, realiza la búsqueda site:tudominio.cl en Google; si encuentras resultados extraños sobre apuestas o medicamentos, tu base de datos ha sido comprometida y tienes un wordpress hackeado.

3. Cuentas de administrador fantasma en tu panel

La tercera advertencia es el hallazgo de cuentas de usuario con privilegios de administrador que nadie en tu equipo creó. Los atacantes suelen explotar vulnerabilidades de inyección SQL o fallas en plugins desactualizados para registrar cuentas fantasmas. Los de Patchstack confirman que más del 90% de las brechas de seguridad en WordPress se originan en plugins de terceros desactualizados y no en el núcleo del sistema. Si detectas un administrador sospechoso en la sección de Usuarios de tu WordPress, la intrusión es real. Borrar la cuenta no es suficiente, ya que en la mayoría de los casos los atacantes dejan instalada una backdoor (puerta trasera) en archivos PHP dentro de tu directorio de uploads para de esa manera volver a generar los accesos de forma automática en un par de horas.

4. Google o tu navegador te marcan como sitio no seguro

La cuarta señal es la más drástica y destructiva para las ventas de tu negocio: cuando Google o tu navegador te marcan como sitio no seguro. Si los de Google Safe Browsing detectan que tu web distribuye malware o aloja páginas de phishing, bloquearán el acceso mostrando una pantalla roja de advertencia. Llegar a este punto implica que la infección lleva días activa y que la reputación de tu dominio ha colapsado, lo que detiene el tráfico orgánico, suspende tus campañas de Google Ads y genera alertas urgentes en tu Search Console. Puedes verificar tu estado reputacional ingresando tu URL en el informe de transparencia de Google o revisando la sección de Problemas de seguridad en tu Search Console.

5. Caída libre de visitas o correos que rebotan a SPAM sin explicación

La quinta señal se manifiesta fuera del código visual, afectando directamente la reputación de tus comunicaciones corporativas. Cuando un atacante toma el control de tu servidor, suele usar la función nativa wp_mail() de WordPress para enviar miles de correos de spam por hora en tu nombre. Esta actividad masiva provoca que los proveedores de seguridad ingresen de inmediato la IP de tu servidor en listas negras mundiales como Spamhaus o Barracuda. Si notas que tus visitas caen drásticamente en Google Analytics o que tus correos diarios comienzan a rebotar o llegar directo a la carpeta de SPAM, tu servidor ha sido secuestrado. Puedes diagnosticar esto ingresando tu IP en la herramienta de monitoreo MXToolbox Blacklist Check.

Las herramientas de escaneo externo y el límite de lo que no pueden ver

Existen herramientas públicas gratuitas en internet, como Sucuri SiteCheck o Mozilla Observatory, que te permiten realizar un análisis de superficie en segundos. Sin embargo, es un error técnico asumir que un resultado limpio en estos escáneres externos garantiza que tu sitio web está seguro. Estas herramientas solo leen el HTML que el servidor muestra públicamente. Ningún escáner externo puede ingresar a tu hosting para leer el código fuente de tus archivos PHP o auditar las tablas internas de tu base de datos. Una backdoor oculta en una carpeta de medios profunda nunca será detectada desde el exterior. Además, herramientas automatizadas como Wordfence a veces arrojan falsos positivos al lidiar con configuraciones como auto_prepend_file, lo que demuestra que los complementos de seguridad no sustituyen el criterio de un especialista.

El nexo legal en Chile: Ley N° 21.719 y la notificación de brechas

Este escenario técnico hoy tiene una dimensión legal ineludible en Chile con la entrada en pleno régimen de la Ley N° 21.719 de Protección de Datos Personales. La regulación establece que si un incidente de ciberseguridad compromete datos personales de tus clientes, tienes la obligación de notificar la brecha a la Agencia de Protección de Datos Personales (APDP) en un plazo de 72 horas desde que tomas conocimiento del hecho. Si el ataque involucra la filtración de información y la empresa no contaba con medidas técnicas adecuadas para prevenirla, se expone a multas gravísimas de hasta 20.000 UTM , que con el valor de la UTM para julio de 2026 de $71.649 CLP, equivale a sanciones de hasta $1.432.980.000 CLP. Un hackeo ya no es solo una falla informática, es una contingencia de alto riesgo para tu patrimonio corporativo.

Cómo recuperar el control de tu infraestructura digital

Sanear una plataforma infectada exige un procedimiento de ingeniería riguroso que va mucho más allá de reinstalar plugins o cambiar contraseñas. Si sospechas que tu WordPress está lento, tus correos rebotan o tu base de datos presenta anomalías, no dejes pasar el tiempo de respuesta. Realizo auditorías forenses profundas y desinfección de infraestructura transaccional de forma externa y segura. Analizo el código de tu servidor, elimino el malware de raíz y configuro escudos perimetrales en Cloudflare para blindar tu sitio y evitar nuevas reinfecciones. Escríbeme directamente a mi correo de contacto y coordinemos una evaluación técnica antes de que la inestabilidad de tu sitio afecte tus ventas y tu reputación legal.