Limpiando el Pharma Hack Wp-Page de WordPress

Pharma hacks son infecciones de sitios web comunes categorizados como spam de SEO. Con pharma hacks, el atacante explota sitios web vulnerables para distribuir anuncios farmacéuticos a los visitantes. Los síntomas de pharma hack incluyen links y anchor text en las Páginas o Resultados del Motor de Búsqueda (SERPs). Estos ataques buscan los motores de búsqueda como Google o Bing en un intento de mejorar el tráfico para negocios farmacéuticos ilegales.

Encontrar un sitio web lleno de anuncios farmacéuticos se vuelve interesante cuando se piensa acerca de sus detalles, sus tácticas y técnicas. A veces, una simple limpieza revela una estrategia más amplia de la piratería informática. Recientemente, durante una limpieza de infección de sitios web para un de nuestros clientes, encontramos un pharma hack que estaba suciando su SEO teniendo como blanco el Google SERPs.

El Pharma Doorway Que No Podía Ser Removido

En este caso específico, (descubierto originalmente por Unmaskparasites en nota del Sucuri Labs, The Undeletable Pharma ‘Doorway’), la identificación de la raíz del problema era fácil. Identificamos la infección a partir del archivo: wp-page.php, que inyectó una página de redireccionamiento de spam pharma (i.e., doorway) en el root del sitio web para usuarios de motores de búsqueda.

El payload de ese pharma hack produjo resultados similares para esa captura de pantalla del Google SERP:

El curso de acción era simple – eliminar el archivo lo excluyendo vía el terminal o cliente FTP. Para nuestra sorpresa, cuando intentamos comprobar si se retira la inyección que todavía estaba allí. El contenido de spam continuó apareciendo en las SERPs.

Nuestra primera idea era asegurarse de que la página no se almacenaba en caché. Si es así, podríamos entender por qué el spam aún se estaba representado en los resultados de Google. Cuando las cabeceras mostraron que no era una página en caché, probamos el archivo en el servidor. De hecho, el archivo que habíamos eliminado estaba de nuevo con una nueva fecha de modificación. ¿Qué sucedió?

Eliminamos el archivo de nuevo. Unos segundos más tarde, el archivo había sido recreado. Es un comportamiento típico de malware que utiliza cronjobs para reinfectar sitios web. Entonces, decidimos verificar el crontab del usuario. No hemos encontrado nada sospechoso en cronjobs. Poco después, cambiamos el enfoque de inmediato y empezamos a buscar algún tipo de backdoor.

Identificando y Regenerando el Script

Después de una búsqueda exhaustiva, hemos encontrado al culpable.

Era un archivo llamado nav.php dentro del directório de tema activo del sitio web. La primera pista fue que el contenido del archivo se agregó a wp-page.php para páginas de sitios web legítimos cuando una petición se hizo por Googlebot o Bingbot.

Lo que hemos visto fue:

Añadir wp-page.php a peticiones legítimas no fue el problema real. Se trataba de la regeneración del archivo. Encontramos el mismo archivo añadiendo el wp-page.php a las peticiones responsable por recrear el archivo (si hay o no).

Ok, ahora estamos cerca de la solución. Sólo necesitamos descobrir qué ejecuta el archivo nav.php.

La respuesta estaba en el archivo header.php del tema activo:

Para aquellos que no están familiarizados con cómo funciona el tema, el atacante añade un include en el archivo de cabecera que carga el archivo nav.php cada vez que el tema se cargó por los visitantes.

Ahora podemos ver por qué el contenido malicioso sigue apareciendo. El hacker se inyecta en esta línea en header.php para que el código malicioso se ejecute cada vez que se solicita una página web. Esto se hace principalmente para enviar el spam para crawlers de motores de búsqueda, pero también recrea el wp-page.php como una característica para “remover la protección”. Después de remover el nav.php e incluir elheader.php, nos sentimos aliviados al ver que el spam ha desaparecido de las SERP.

Hay Más que Hacer Después de Remover los Archivos

Este caso demostramos perfectamente que una limpieza del sitio web no termina cuando se encuentra y elimina archivos maliciosos. Después de la limpieza inicial, hay que confirmar que el malware en realidad desapareció completamente y continuasupervisar el sitio web. Si no se verifica, puede permitir que los hackers reinfecten su sitio web a través de una puerta trasera o de una vulnerabilidad de seguridad no corregida. La reinfección puede ocurrir en cuestión de segundos (como se ve aquí) o se tarda días antes de regresar el malware, causando más estrés.

En este caso particular, el monitoreo de la integridad de los archivos core y archivos de temas podrían pagar grandes dividendos al propietario del sitio web. Para aquellos que utilizan WordPress, esto se puede lograr mediante el uso de nuestro plugin de seguridad gratuito para WordPress.

Además, es importante seguir los pasos después del hack después de cualquier compromiso.

Por último, si usted ve a los atacantes inyectando spam en sus páginas web o SERPs,sepa que podemos ayudarle.

Fuente:https://blog.sucuri.net/