Contenido vulnerado: que pasa de verdad cuando el sitio mismo, y no un anunciante, es el que se ve comprometido
La primera senal casi nunca llega de alguien oficial. Son unas cuantas direcciones extranas en Search Console que nadie del equipo recuerda haber creado, o el trafico organico que cae sin causa visible en los paneles habituales, o un anunciante que escribe para preguntar por que la pagina de su anuncio redirige a algo que no tiene nada que ver con el sitio. A veces es un visitante que avisa de que el navegador se nego a abrir la pagina. Nada de esto parece fraude de un anunciante, y nada se parece al caso del anuncio malicioso que hace marcar un sitio sin que su propio codigo tenga ninguna culpa.
Este es el otro caso, y es un problema distinto con una solucion distinta. Aqui, algo se anadio de verdad a los archivos o a la base de datos del sitio sin que nadie del equipo lo hubiera puesto ahi. Un directorio de esta categoria no puede permitirse parecer poco fiable ni una semana: ni ante Google, ni ante un procesador de pagos que ya trata al sector como mas arriesgado que la media, ni ante un proveedor de alojamiento que puede estar a una queja de suspender la cuenta. Saber exactamente que paso, que revisa Google en realidad y en que orden funciona de verdad la solucion vale mas aqui de lo que valdria para el blog de una pequena empresa cualquiera, porque el coste de hacer el orden mal es mayor.
Como entra realmente un atacante, y rara vez es algo espectacular
A este nivel, casi nadie apunta especificamente a un directorio de clasificados para adultos. El patron habitual es un bot que recorre la web abierta buscando cualquier sitio que use cierto software con un fallo conocido y sin corregir, de la misma forma que recorre sitios de restaurantes o blogs de despachos de abogados. El sitio recibe el golpe porque resulta que usa el mismo CMS, el mismo plugin o la misma libreria desactualizada que un millon de otros sitios, no porque alguien lo haya observado y decidido que merecia el esfuerzo.
El software desactualizado es un factor real y comun, pero no es toda la historia, y tratarlo como si lo fuera deja sin cubrir la mitad de los puntos de entrada reales. El informe de sitios vulnerados de Sucuri, sobre los sitios que limpio en 2023, encontro que el 39,1% de las instalaciones de CMS comprometidas ejecutaba software desactualizado en el momento de la infeccion, por debajo del 50,58% del ano anterior. El mismo informe encontro que solo alrededor del 14% de esos sitios todavia tenia un plugin o tema vulnerable identificable una vez que Sucuri examino de cerca la reparacion. Dicho de otro modo, la mayoria de los sitios que limpio no fueron vulnerados en realidad a traves del fallo de software que un operador esperaria tener que corregir primero.
La otra mitad del panorama son las credenciales. El Informe de Investigaciones de Filtraciones de Datos 2025 de Verizon, que mira a cada sector que rastrea y no solo a los sitios web, encontro las credenciales robadas o adivinadas ligeramente por delante de las vulnerabilidades de software explotadas como la forma en que los atacantes consiguen su primer punto de apoyo: 22% de las filtraciones frente a 20%. No es una cifra construida solo con sitios de clasificados, pero coincide con lo que Sucuri observa en limpiezas especificas de plataformas CMS. Una contrasena administrativa reutilizada de una cuenta de correo personal que se filtro en una brecha sin relacion anos antes es, en la practica, una via de entrada tan probable como un plugin sin actualizar.
La consecuencia practica es que proteger un sitio es un trabajo en dos frentes de peso casi igual, no uno solo. Un calendario de parches cierra la mitad de las brechas de software. Una disciplina aparte sobre quien tiene acceso, cual es realmente su contrasena y si se reutiliza en otro sitio cierra la otra mitad. Un operador que solo mantiene los plugins actualizados ha hecho la mitad del trabajo y puede que nunca se de cuenta, porque la pantalla de aviso aparece identica sin importar cual mitad se salto.
Como lo llama Google en realidad, y por que es un problema distinto de un anuncio malicioso
Aqui ya se ha tratado un tipo distinto de aviso de Chrome: aquel en el que una red publicitaria contratada sirve una creatividad enganosa o maliciosa a traves de los propios espacios publicitarios del sitio, y Google marca el sitio por un contenido que nunca toco. Este no es ese caso. Aqui se anadio algo a las paginas o a la base de datos del sitio sin que el operador lo supiera, que es exactamente lo que las politicas de spam de Google definen como contenido vulnerado: contenido colocado en un sitio sin el permiso del propietario, por una debilidad en la propia seguridad del sitio.
La documentacion de Google distingue tres patrones concretos. La inyeccion de codigo es codigo malicioso, normalmente JavaScript, insertado directamente en paginas o iframes que ya existian. La inyeccion de paginas son paginas nuevas anadidas al sitio que antes no estaban, construidas para manipular el posicionamiento en buscadores o para montar un intento de phishing, mientras que las paginas que un visitante ya conocia a menudo no muestran ningun signo visible de que algo vaya mal. La inyeccion de contenido es aun mas sutil: texto o enlaces ocultos anadidos a paginas existentes mediante trucos de CSS o HTML, visibles para el rastreador de un buscador pero no para una persona que mira la misma pagina en el navegador.
La inyeccion de paginas suele ser el patron que los operadores descubren el ultimo, y conviene entender por que un atacante se molesta en hacerlo en lugar de construir sencillamente un sitio desechable propio. Un dominio que ya tiene historial, enlaces entrantes existentes y una posicion consolidada en los resultados de busqueda blanquea contenido de spam en el posicionamiento mucho mas rapido de lo que lo haria un dominio recien creado, asi que los atacantes prefieren tomar prestada la reputacion de un sitio existente antes que construir la suya desde cero. Es un mecanismo distinto del ataque externo basado en enlaces tratado en otro lugar: alli, el ataque dirige enlaces de otros sitios hacia el objetivo desde fuera; aqui, las paginas de spam estan construidas para vivir en el propio dominio del objetivo, dentro de su propia estructura de archivos.
Una vez que ese contenido existe en el sitio, las consecuencias se acumulan. El informe de Problemas de seguridad de Search Console marca la propiedad directamente, algunas paginas pueden quedar excluidas de los resultados o sustituidas por un aviso en el listado, y el Safe Browsing de Chrome puede empezar a mostrar a los visitantes la misma pantalla roja interstitial ya descrita para el caso de la red publicitaria, esta vez activada porque el sitio aloja de verdad contenido malicioso o enganoso, no por una creatividad defectuosa que pasa por el.
Conseguir que quiten el aviso: el orden que funciona de verdad
La guia de Google es especifica sobre el orden, y la mayor parte del tiempo que se pierde en la practica viene de hacer estos pasos fuera de secuencia. El primer trabajo es encontrar y eliminar cada instancia del contenido inyectado, no solo la pagina de muestra que Search Console cito como ejemplo del problema. Esa direccion es una muestra, no un inventario, y una limpieza que se detiene tras corregirla suele dejar en pie la mayor parte de la inyeccion real.
El segundo trabajo es averiguar como entro el atacante y cerrar exactamente ese agujero, ya fuera un plugin sin actualizar, una credencial filtrada o un permiso mal configurado, porque borrar las paginas de spam sin corregir el punto de entrada solo reinicia el reloj hasta que el mismo atacante, o el mismo rastreo automatizado, vuelva a entrar por la misma puerta. La documentacion de Google es explicita en que la correccion debe cubrir todo el sitio, no solo la pagina de inicio o la pagina que un visitante denuncio, y una parte relacionada de la misma guia recomienda cambiar todas las contrasenas vinculadas a una cuenta con acceso administrativo: el inicio de sesion del CMS, el panel de control del alojamiento, FTP o SFTP, y la base de datos, precisamente porque el punto de entrada suele ser uno de esos y no la pagina donde aparecio el sintoma.
La parte que los operadores suelen invertir es cuando pedirle a Google que vuelva a mirar. Pedir una revision antes de que la limpieza anterior este realmente terminada no acelera nada; Google dice claramente que pedir una revision mientras el problema sigue existiendo solo prolonga el tiempo que el sitio queda marcado. Los tiempos de revision varian segun la categoria: una revision de malware sencillo suele tardar unos dias, una de phishing cerca de un dia, pero una revision de contenido vulnerado que incluye paginas de spam inyectadas puede tardar hasta varias semanas, porque Google trata esa categoria como una que puede necesitar una revision realmente manual en vez de una reverificacion automatica.
Una segunda ronda del mismo aviso despues de que una revision ya haya pasado suele ser senal de que el punto de entrada nunca se cerro de verdad la primera vez, solo el sintoma. Borrar las paginas de spam visibles parece terminar el trabajo, pero si el plugin vulnerable sigue ahi o la contrasena filtrada todavia funciona, el mismo agujero vuelve a usarse, a veces en cuestion de dias desde que se quito el aviso.
Que previene esto de verdad, con un presupuesto que este negocio puede sostener
Nada de esto requiere contratar un equipo de seguridad dedicado, y los operadores que se saltan lo basico suelen hacerlo porque la lista suena mas larga de lo que realmente es. El CMS, su tema y cada plugin instalado necesitan un calendario de actualizacion fijo, revisado cada semana en lugar de "cuando haya tiempo", y todo lo que se instalo una vez y ya no se usa deberia eliminarse por completo en lugar de dejarse inactivo, porque un plugin inactivo sigue siendo una puerta que nunca se cerro con llave.
La disciplina de credenciales pesa tanto como los parches, visto lo que muestran de verdad las cifras de Sucuri y Verizon citadas arriba. Eso significa una contrasena unica para cada cuenta que pueda tocar el sitio, generada y guardada en un gestor de contrasenas en lugar de en la memoria, autenticacion de dos factores activada en cada inicio de sesion que la ofrezca, y ningun inicio de sesion compartido entre personal o moderadores, ya que un inicio de sesion compartido es tambien un acceso que nadie puede rastrear hasta una persona concreta cuando algo sale mal.
Las copias de seguridad importan tanto como la prevencion, porque son lo que devuelve un sitio a la red en horas en lugar de esperar una revision de Google que puede durar semanas. Una copia de seguridad que vive en la misma cuenta de alojamiento que el sitio que deberia proteger no es gran cosa como copia de seguridad, porque un atacante con acceso administrativo normalmente tambien puede llegar a ella; una copia guardada en otro sitio, y de verdad probada restaurandola al menos una vez en lugar de dejada corriendo sin verificar, es la diferencia entre una semana mala y un mes malo.
La ultima pieza es simplemente enterarse pronto. Las alertas por correo de Search Console hacen que el informe de Problemas de seguridad llegue a una bandeja de entrada que alguien realmente lee, en lugar de que el operador se entere del problema por la queja de un visitante o por una hemorragia lenta de trafico organico dias o semanas despues de los hechos. Ninguno de estos pasos cuesta mas que tiempo, y todos salen mas baratos hechos ahora que despues de que la pantalla de aviso ya se haya comido una semana de trafico mientras se arregla la limpieza.
El orden, si el aviso ya aparecio, es limpiarlo todo primero, cerrar el agujero concreto que lo permitio, y solo entonces pedirle a Google que vuelva a mirar, nunca al reves. El orden, si todavia no ha pasado nada, es hacer de todos modos las mismas cuatro cosas en un calendario esta semana: actualizar lo que esta instalado, cambiar cada contrasena con acceso administrativo, activar la autenticacion de dos factores donde se ofrezca, y probar una restauracion real desde copia de seguridad. En cualquiera de los dos casos, la solucion nunca tuvo que ver con la jurisdiccion del certificado ni con el tamano del despacho de abogados contratado: tiene que ver con quien puede iniciar sesion, con cuan actualizado esta el software, y con si alguien se daria cuenta a tiempo.
