Recuperación de un sitio WordPress tras malware y .htaccess bloqueado

Cuando un sitio WordPress es comprometido por malware, especialmente si se usó una contraseña débil como
usuario-12345, las consecuencias pueden ir más allá de simples inyecciones de archivos.
En este caso, el ataque provocó que el archivo .htaccess quedara bloqueado en modo de solo lectura (0444),
impidiendo cualquier modificación manual. Aquí documentamos el proceso completo de diagnóstico y recuperación.

1. Síntomas iniciales

• El sitio mostraba errores en páginas internas.
• El archivo .htaccess se regeneraba automáticamente con permisos 0444, sin posibilidad de edición.
• Sospechas de reglas maliciosas inyectadas por malware y reforzadas por configuraciones de Apache/cPanel.

2. Acciones iniciales

1. Conectarse al servidor vía SSH como root.
2. Revisar el estado del archivo:

   ls -l .htaccess

   Salida:

   -r--r--r-- 1 root root ... .htaccess

3. Respaldar y crear un .htaccess limpio:

   
   mv .htaccess .htaccess_backup
   echo "# test htaccess" > .htaccess
   chmod 644 .htaccess
         

3. Investigación en Apache/cPanel

Se detectó que el archivo se regeneraba desde configuraciones relacionadas con
WordPress Toolkit y plantillas de seguridad de cPanel.

grep -R "FilesMatch" /etc/apache2/conf.d/

4. Solución aplicada

1. Reconstruir el VirtualHost:

   
   /scripts/ensure_vhost_includes --user=USUARIO
   service httpd restart
         

   Reemplaza USUARIO por la cuenta afectada en cPanel.

2. Confirmar permisos:

   ls -l .htaccess

   Salida esperada:

   -rw-r--r-- 1 usuario usuario ... .htaccess

3. Restaurar contenido de WordPress:

   
   # BEGIN WordPress
   
   RewriteEngine On
   RewriteBase /
   RewriteRule ^index\.php$ - [L]
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteCond %{REQUEST_FILENAME} !-d
   RewriteRule . /index.php [L]
   
   # END WordPress
         

5. Medidas de seguridad posteriores

• Contraseña segura: evitar combinaciones obvias como usuario-12345.
• Revisión de usuarios en WordPress y en cPanel.
• Escaneo de malware en archivos y base de datos.
• Actualización de plugins, temas y core de WordPress.
• Revisar crons sospechosos con:

  crontab -l

• Habilitar firewall/WAF para bloquear accesos a wp-login.php y xmlrpc.php.

6. Conclusión

Este caso demuestra cómo un ataque por contraseña débil puede desencadenar consecuencias serias:
bloqueo del .htaccess, sobreescritura automática por configuraciones de servidor y caída de páginas internas.

La solución estuvo en reseteo del VirtualHost y la restauración manual del .htaccess.
Con pasos claros y medidas preventivas, se evitó que el problema vuelva a ocurrir.

¿Quieres que prepare un script automatizado en Bash que haga respaldo, reset y restauración del .htaccess en un solo paso?