Mi WordPress se vuelve a infectar: ¿por qué regresa el malware?

Bienvenidos a DIVICON BWA. Hoy tenemos sobre la mesa una serie de bitácoras de incidentes y notas de nuestro equipo de investigación. Y la verdad, es un tema que, híjole, le quita el sueño a cualquier dueño de negocio en internet. Sí, totalmente, es de esos temas que causan pesadillas reales. Exacto, y nuestra misión en este análisis profundo es resolver una gran duda, o sea, por qué una página de WordPress vuelve a infectarse justo después de que supuestamente ya la habían limpiado.

Es una pregunta supercrítica. Y, digo, revisando estos reportes forenses, queda clarísimo que para quienes administran negocios digitales, esto no es nada más un problema técnico de, ah, veo códigos raros en una pantalla. No, claro que no, es dinero perdido. Exacto, es una fuga constante de tiempo, de energía y de ingresos, haz de cuenta que cuando un equipo jura que ya resolvió el hackeo, y a los dos días el malware vuelve a aparecer, la sensación de vulnerabilidad es inmensa.

Sí, es como si el piso de tu propio negocio se estuviera moviendo, ¿no? Como que no hay de dónde agarrarse. Literalmente, y creo que es una frustración que paraliza por completo la operación. Pues sí. Y para entender realmente la anatomía de esta pesadilla digital, creo que no hay mejor forma que retomar una historia que ilustra esto a la perfección. Vamos a desempolvar los expedientes y regresar al caso de la mercería de Doña Coneja.

Ah, claro, el famoso caso de la mercería. Sí, ese mero. Habíamos hablado de ella en nuestra investigación anterior, viendo cómo su tienda en línea de repente empezó a mandar a los clientes a un casino clandestino. Pues la historia sigue y esta se pone bastante intensa. Y, ojo, porque este caso es el reflejo de una estadística alarmante que vemos en los registros forenses todos los días.

No es un caso aislado. Para nada. A ver, pongamos un poco de contexto, estamos en pleno diciembre. La mejor época del año para vender. Exactamente, la temporada más fuerte. Y la mercería de Doña Coneja, pues parecía haber vuelto a la normalidad absoluta. Después del susto del casino, los pedidos de estambres, esferas, los listones rojos, o sea, todo salía a tiempo.

Las cajas ahí apiladas, listas para la paquetería, me imagino. Sí, sí, el incidente ya se sentía como una anécdota lejana y fea, nada más. Hasta que de la nada, suena el teléfono en el local. Y es una clienta de toda la vida avisando que pues que quiso comprar en la página, pero le saltó una pantalla roja enorme. Ay, no me digas, la clásica pantalla roja.

Esa misma. Una de esas advertencias letales que dicen que el sitio es engañoso o que tiene software malicioso. Digo, imagínate el impacto de eso en plena temporada alta. Es un balde de agua fría absoluto para cualquiera. Totalmente. En ese instante, al abrir la compu y ver esa alerta roja, la dueña del negocio siente que todo el infierno de hace semanas vuelve a empezar desde cero.

Y pues hace lo lógico. Llamar a su diseñador, ¿no? Al Oso Hormiguero. Exacto, llama al Oso Hormiguero para que revise qué diablos está pasando. Y el pobre oso entra en acción. Se mete a revisar las entrañas de la tienda y otra vez encuentra publicaciones raras en el blog, o sea, cosas que nada que ver con la mercería. Seguramente usuarios falsos también.

Sí, detecta usuarios con permisos de administrador que nadie del equipo creó y archivos súper extraños en las carpetas. Entonces hace su chamba lo mejor que puede. Borra los usuarios fantasma, limpia lo que logra identificar y pues la tienda, en apariencia, vuelve a funcionar. Pero el problema es que regresan los síntomas. Una y otra vez. O sea, el oso borra algo el lunes y para el jueves en la madrugada ya está todo de vuelta.

Es desesperante. Y en medio de toda esa frustración, el Oso Hormiguero hace una deducción brillante, viendo algo súper cotidiano ahí en el local físico de la mercería. A ver, cuéntame esa parte porque me parece increíble. Haz de cuenta que un día está viendo el mostrador de madera y nota que hay una fila de hormigas saliendo de una rendijita en el suelo.

Y entonces razona y dice, a ver, he limpiado este mismo espacio un montón de veces. Ajá, barre y trapea el piso. Exacto, aplica desinfectante y todo, pero a las pocas horas las hormigas siguen apareciendo en el mismo lugar. Wow. Es que es una metáfora brutal para la ciberseguridad. Porque el oso se da cuenta de que quitar unas cuantas hormigas no soluciona nada, porque van a salir más.

Ese es el punto clave. Se da cuenta de que en algún lado, bajo ese piso, hay un hormiguero entero que no está viendo. Y eso nos deja una regla de oro de verdad para cualquier persona que administre una web, quitar las hormigas que ves no significa haber encontrado el hormiguero. Totalmente de acuerdo. Digo, de nada sirve aplastar las hormigas que cruzan por ahí si no descubres de dónde demonios están saliendo.

Pero bueno, quiero hacer una pausa aquí para reivindicar un poco al oso. Sí, es superimportante hablar de su rol porque la documentación forense hace mucho énfasis en esto. Hay que dejar clarísimo que este diseñador no es ningún incompetente. Para nada, al contrario, es un profesional superresponsable. O sea, él fue quien diseñó una tienda exitosa, armó todo el catálogo, conectó los pagos.

Hizo que la mercería vendiera a nivel nacional, o sea, su trabajo funciona. El detalle está en que pues diseñar una página web bonita y funcional y hacer una investigación forense de un hackeo son dos disciplinas completamente diferentes. Claro. Es como, o sea, si tú contratas a un arquitecto maravilloso para que te construya una casa espectacular, y de repente, un día alguien fuerza la cerradura, se mete a robar y hace un hoyo en la pared.

Ajá, no le llamas al arquitecto para eso. Exacto, la primera llamada no es para el arquitecto para que busque huellas dactilares o analice por dónde entraron. Digo, el arquitecto hizo una casa funcional, pero para un crimen, pues llamas a un especialista en seguridad, ¿no? Es el mejor ejemplo. Y la ética del Oso Hormiguero resalta precisamente por eso, por reconocer sus propios límites técnicos.

Él tiene la madurez de decirle a Doña Coneja, oye, puedo seguir barriendo las hormigas visibles, pero antes de asegurar que el sitio es seguro, necesitamos localizar el hormiguero. Y para eso se necesitan herramientas que un diseñador normal pues no tiene a la mano. De verdad, me quito el sombrero ante el oso por ser tan honesto. Sí, mis respetos para él.

Pero bueno, vamos a diseccionar un poco este misterioso hormiguero digital, porque leyendo las bitácoras, la gran duda que me queda es: ¿qué es exactamente una reinfección a nivel de código? Ok, vamos a meternos un poco a lo técnico. Sí, o sea, cuando decimos que el malware regresó, ¿qué es lo que está operando ahí en las entrañas de WordPress? Mira, siguiendo con la metáfora.

Una reinfección pasa cuando eliminas los síntomas, o sea, borras el spam y los usuarios falsos, pero la actividad maliciosa resurge porque las condiciones que permitieron el ataque siguen ahí, intactas. Ok, o sea, no es que les caiga un rayo dos veces por pura mala suerte. Para nada, la tormenta nunca se fue. Borran los posts del casino, sí, pero la puerta de acceso de los atacantes sigue abierta de par en par.

Pues, vamos a desglosar cómo operan estas puertas porque el nivel de sofisticación me parece fascinante. Según nuestras notas, hay varios factores que causan este ciclo infinito. Así es. El primero es la famosa puerta trasera o el backdoor. Y para entenderlo, a ver, imagínate que sacas a un ladrón que entró a una casa por una ventana rota. Ok, lo sacas y reparas la ventana.

Exacto, pones un vidrio nuevo, unos barrotes y pues ya, cantas victoria. Pero de lo que nunca te diste cuenta es que mientras el tipo estuvo adentro, se fue a la cocina y le sacó un molde de cera a la llave de tu puerta principal. Wow, sí, excelente analogía. Digo, puedes blindar esa ventana mil veces, pero el ladrón va a seguir entrando por la puerta principal como si fuera su casa.

Y ese mecanismo es exactamente lo que es un backdoor en WordPress. El atacante logra entrar al sistema, casi siempre por alguna vulnerabilidad en un plugin, pero sabe que tarde o temprano el dueño va a notar el daño. Entonces deja un seguro de vida. Exacto, como seguro para mantener su acceso, inyecta un archivo malicioso chiquito. O de plano, modifica una sola línea de código dentro de un archivo legítimo de WordPress.

Qué miedo. Esa línea es la copia de la llave, ¿no? Tal cual. Y le permite al atacante ejecutar comandos a distancia sin necesitar ningún usuario ni contraseña del panel. Mientras ese código siga ahí escondido, el atacante nada más inyecta el malware otra vez cuando se le da la gana. Y además el camuflaje es increíble, porque A veces es, digo, una línea de texto incomprensible, escondida al fondo de un archivo que parece superinofensivo.

Pero, oye, esto me lleva a una duda enorme sobre las actualizaciones. A ver, dime. Porque mucha gente asume que con entrar al panel de WordPress y darle al botón de actualizar todos los plugins, pues ya, el problema queda sellado para siempre. Híjole, es un malentendido supercomún y muy peligroso. Piensa en las vulnerabilidades de los plugins como si fueran grietas en la pared.

Actualizar el plugin tapa la grieta y sí, eso es indispensable. Ok, tapas el hoyo por donde entraron. Exacto. Pero actualizar el software no borra mágicamente las modificaciones o los backdoors que el atacante ya dejó sembrados mientras esa grieta estaba abierta. Claro. O sea, cerraste la ventana por donde se metió ayer, pero el tipo ya tiene la copia de la llave principal.

Tiene todo el sentido del mundo. Así es. Parchar el agujero original no expulsa al intruso si ya dejó su puerta trasera en otra carpeta. Qué bárbaro. Y bueno, el siguiente punto en la investigación me dejó pensando bastante. Es el tema de los accesos comprometidos. Ah, ese es un tema gigantesco. Porque uno normalmente jura que si alguien hackea un sitio es porque de seguro adivinaron la contraseña en la pantallita clásica de inicio de sesión, ¿no?

Pero resulta que hay muchísimas otras entradas. Es que el panel de WordPress es nada más la vitrina de la tienda. Dependiendo de qué tan grave fue la intrusión, los atacantes buscan credenciales de niveles mucho más profundos. ¿Cómo cuáles? Hablamos de accesos al panel de control del hosting, conexiones por FTP o hasta ingreso directo a las bases de datos.

Si al notar algo raro solo cambias tu contraseña de administrador de WordPress, pues el falso sentido de seguridad es altísimo. A ver, vamos a intentar aterrizar esto. Si consideramos que WordPress es como el volante y el tablero de un carro, pues la base de datos vendría siendo el motor. ¿Verdad? Exactamente. Entonces, si un mecánico con malas intenciones, o sea, un hacker, tiene acceso directo al bloque del motor, pues le da igual cuántos candados le pongas al volante.

Es una comparación muy atinada. Y si hablamos de las conexiones FTP, haz de cuenta que son como la puerta de carga trasera en una bodega. Ah, claro, por donde meten la mercancía. Exacto, los atacantes ni siquiera necesitan pasar por la puerta principal de la tienda si tienen las llaves de la rampa de carga para mover cajas directamente. Y si logran entrar al motor, a la base de datos, pueden crear usuarios invisibles directamente en las tablas.

O sea, que no importa cuántas veces resetees la contraseña en tu panel. No importa nada, ellos ya están adentro del motor. Wow. Es que es abrumador pensar en todos los frentes que hay que cubrir. Y este, los reportes también mencionan un factor que lo hace todavía más complejo. El entorno compartido. Uf, sí. O sea, es en serio que una página puede infectarse mil veces y la culpa ni siquiera es de su propia seguridad, sino del vecino.

Tristemente sí. Sucede muchísimo en servicios de alojamiento compartido que están mal configurados. En un servidor así, tienes a cientos de páginas distintas compartiendo el mismo disco duro. Como un edificio de departamentos. Exacto, y si los entornos no están bien aislados entre sí y la página de tu vecino tiene una vulnerabilidad grave, el malware se puede desplazar lateralmente.

Cruza las paredes. Literalmente cruza las fronteras dentro del servidor y contamina sitios que estaban completamente sanos. Por eso, al investigar no te puedes limitar a buscar solo en la carpeta obvia. Hay que revisar todo el edificio, básicamente. Ay, es que esto es un thriller de detectives forenses, de verdad. Pero a ver, quiero hacer la de abogada del diablo un segundo.

Adelante, dime. Si un negocio agarra y dice, voy a pagar una buena lana mensual por un plugin de seguridad premium, de esos escáneres famosos que te prometen vigilancia 24/7. Y el dueño corre el escáner, la barrita llega al 100% y le sale un mensajito verde superbonito que dice, cero amenazas detectadas. Ajá, el clásico mensaje verde. ¿No es eso suficiente? Digo, me estás diciendo que eso es puro teatro.

La realidad es un poco dura, la verdad. Hay que entender la diferencia enorme entre una herramienta de asistencia automática y una investigación forense real. Ok. Hay una brecha abismal entre decir, el escáner no detectó código malicioso conocido y decir, ya auditamos y corregimos por dónde se metieron. Porque los escáneres funcionan buscando firmas conocidas.

Haz de cuenta como un policía que revisa un catálogo de huellas dactilares que ya tiene. Exactamente eso. O sea, que si el criminal se pone guantes nuevos, pues pasa como si nada. Tal cual. Los creadores de malware se la pasan ofuscando su código. Cambiándole la estructura para que no coincida con el catálogo del escáner. Qué coraje. Y aparte un plugin que vive ahí adentro de WordPress, tiene un alcance bien limitado.

No puede auditar accesos del servidor ni saber si tu contraseña del FTP se filtró en algún foro de la Dark web. Claro. Te sirve como un primer filtro. Es un buen primer paso, sí. Pero jamás va a sustituir a una persona que entiende toda la arquitectura del ataque. O sea, el escáner busca las hormigas que ya conoce, pero no tiene idea de cómo interpretar el diseño del hormiguero.

Y bueno, hablando de herramientas de detección, ¿qué onda con la temida pantalla roja de Google? Ay, la pantalla roja, el terror de todos. Es que imagínate, alguien limpia su sitio a fondo, pero al día siguiente los clientes avisan que la advertencia roja sigue bloqueando la entrada. El pánico es inmediato, o sea, ¿eso significa a fuerza que la infección ya regresó?

Genera un estrés tremendo, pero hay que tener la cabeza fría. Esa pantalla de Google no es un indicador en tiempo real, para nada. Ah, no es instantáneo. No, casi siempre es un retraso en sus procesos de revisión. Una vez que el sitio de verdad está limpio, tú tienes que ir y solicitar formalmente una revisión a Google. Y ellos se toman varios días en volver a rastrear tu código.

Ok, entonces hay un desfase temporal. O sea, el sitio ya está sano, pero la etiqueta de cuarentena sigue pegada ahí en la puerta. Así es, pero ojo. Tampoco hay que pecar de optimistas, asumir que la pantalla roja es puro retraso burocrático, sin haber verificado de verdad que quitaste el malware, es un error fatal. Claro, no puedes tapar el sol con un dedo.

Hasta no tener pruebas reales de que mataste la vulnerabilidad, la alerta podría tener toda la razón. Y me pongo a pensar en la presión de ese momento. Es muchísima presión. Con el sitio caído, sin tráfico o las ventas navideñas atoradas, frente a esa crisis, ¿cuál es el instinto más destructivo que comete la gente por tratar de arreglarlo rápido?

Entrar en pánico. Sin duda el error más catastrófico es empezar a borrar archivos que se ven sospechosos o meterle mano a la base de datos a ciegas. Sin ningún plan ni respaldo. Exacto, es tratar de operar un tumor sin saber nada de anatomía. Es como intentar hacer una cirugía a corazón abierto leyendo un foro de internet de hace 5 años. Peor tantito.

Porque en una tienda en línea, la base de datos no nada más guarda los colores de la página, ahí viven tus inventarios, el registro de tus clientes, los pedidos que no has enviado, todo el negocio, pues. Sí, entonces borrar tablas al azar o restaurar un respaldo viejísimo por pura desesperación, te puede pulverizar semanas de ventas, te quedas sin saber a quién le cobraste ayer y qué paquetes tienes que mandar hoy.

Una verdadera tragedia operativa. Entonces, en lugar de andar borrando cosas en estado de pánico, ¿cómo se ve realmente el trabajo de aislar el problema? Digo, no como un manual, pero cómo fluye una investigación forense real. Pues lo primerito es preservar la escena del crimen. Antes de moverle a nada, tienes que documentar qué está fallando. Tomas capturas de pantalla, revisas a dónde te redirige y súper importante, resguardas los registros del servidor, los famosos logs.

Y a ver, ¿por qué son tan importantes esos registros? Porque son la caja negra del servidor. Ahí queda anotada cada petición que entró a la página, desde qué dirección IP lo hicieron y a qué hora exacta. Órale. Analizando todo eso, puedes reconstruir cómo entró el atacante. Y a la par de juntar esa evidencia, se sella el perímetro de forma temporal.

O sea, cambias y rotas absolutamente todos los accesos. Todo es todo, supongo. Todo. Contraseñas de bases de datos, usuarios del hosting, correos asociados, todo. Y luego viene la parte ruda, ¿no? La cacería de la persistencia. ¿Cómo le hacen para encontrar ese código camuflado? Es una mezcla de análisis automatizado y muchísima revisión manual. Técnicamente, agarras todos los archivos del sitio y los comparas contra las versiones originales y limpias para ver cualquier detallito alterado.

Buscan la aguja en el pajar. Tal cual. Busquemos cadenas de código ofuscado, cosas que a simple vista parecen letras sin sentido, pero que en realidad esconden el malware. Y checas archivos con fechas de modificación raras. Todo ese trabajo metódico es lo que al final saca a la luz el hormiguero. O sea, esto es trabajo de bisturí, no de machete. Definitivamente.

Y hay algo fundamental aquí sobre las expectativas. A ver. Aún haciendo toda esta limpieza forense profesional, nadie te puede garantizar al 100% que la página jamás en la vida va a volver a ser atacada. Claro, eso es imposible. La honestidad es innegociable en esto. El internet cambia todos los días y los ataques evolucionan. Pero encontrar la persistencia y cerrar los hoyos reduce el riesgo drásticamente.

Lo importante es que los dueños de negocios entiendan que una reinfección no significa que su página ya murió o que tienen que tirar toda la inversión a la basura. Y por supuesto que tampoco significa que su diseñador original haya hecho un mal trabajo, ¿no? Exacto, hay que quitar ese estigma. Pues esto nos regresa a la mercería de nuestra protagonista.

Volvemos al local de Doña Coneja. Las luces de Navidad siguen brillando. Los estambres ahí acomodados, las cajas listas. Todo en calma en la superficie. Pero por debajo, la preocupación sigue viva. Sí. Doña Coneja ya conoce la cruda realidad de la ciberseguridad. Ya entendió perfecto que andar con la escoba barriendo las hormiguitas que cruzan por el piso no le va a devolver la paz.

Sabe que la amenaza sigue latente allá abajo, esperando el peor momento para salir. Exacto. Es un punto de quiebre padrísimo porque define la resiliencia de un emprendedor. Y la verdad nos deja con una intriga tremenda para los que seguimos estos reportes. A ver, cuál. Pues, ¿y si el oso tenía razón? ¿Qué va a pasar ahora que ya aceptaron que el hormiguero sigue ahí, abajo, intacto?

Sin duda eso va a preparar el terreno para nuestra próxima investigación sobre cómo se resuelve el caso. Va a estar superinteresante. Y digo, para todos aquellos que nos escuchan y que tal vez ven los problemas de Doña Coneja reflejados en sus propios negocios, es imperativo que sepan que no tienen por qué hacer este análisis solos. Claro que no. Como parte de DIVICON BWA, nosotros ofrecemos servicios de seguridad y recuperación especializada para páginas WordPress.

Para eso estamos. Exactamente. Nuestro equipo hace esto, investigamos a fondo las modificaciones, encontramos las vulnerabilidades y, lo más importante, erradicamos esos mecanismos de persistencia que causan las reinfecciones. Arrancamos el hormiguero de raíz. Así es. Así que invitamos a quienes necesiten rescatar su sitio y recuperar la tranquilidad a conocer nuestro servicio en divicon.net/seguridad-wordpress/. Ahí podemos analizar su caso a detalle.

Superimportante acercarse a los expertos. Y bueno, antes de cerrar el análisis de hoy, me gustaría dejarles un último pensamiento, un poco provocador, la verdad. Uh, a ver, suéltalo. Hemos estado hablando del malware como si fuera algo estático, ¿no? Unas hormigas con su nido y ya, pero ¿qué va a pasar cuando los atacantes empiecen a meter inteligencia artificial directamente en sus scripts.

Híjole, esos ya son palabras mayores. Imagínate, backdoors que tengan la capacidad de reescribirse y mutar solitos, cada que detecten que borraste una parte del código. O sea, las hormigas se van a volver muchísimo más listas. Es un escenario fascinante y la verdad, bastante escalofriante. Seguro nos va a dar para otro análisis completo muy pronto. Estoy segura de que sí.

Pero bueno, mientras tanto, nos quedamos con la máxima principal de hoy, quiero que se le quede grabada a cualquiera que administre una página web. Recuerden, quitar las hormigas que ves no significa haber encontrado el hormiguero. La regla número uno para romper el ciclo, sin duda. Pues muchísimas gracias a toda nuestra audiencia por acompañarnos en esta profunda investigación.

Los esperamos en la próxima entrega de DIVICON BWA, donde seguiremos desentrañando estas redes de la seguridad web. Hasta la próxima.