Persistencia en servidores de correo: cuando el atacante controla el MTA

Has asegurado tus registros SPF, DKIM y DMARC. Sin embargo, los registros de auditoría muestran correos perfectamente firmados y alineados que tú no has autorizado. El problema ya no es una suplantación externa; el atacante ha tomado el control del Mail Transfer Agent (MTA). Has pasado de un problema de reputación a un compromiso crítico de infraestructura.

Cuando un atacante logra persistencia en el servidor de correo, las defensas perimetrales se vuelven irrelevantes. En este artículo analizarás los métodos de intrusión en binarios de transporte, la manipulación de colas de salida y las técnicas de exfiltración silenciosa que convierten a tu servidor en un nodo de distribución de amenazas de alta confianza.

El compromiso de un MTA (como Postfix, Exim o Sendmail) implica que el atacante posee privilegios de ejecución en el sistema operativo que gestiona el flujo de correo. A diferencia del phishing tradicional, donde se busca engañar al receptor, aquí se busca la autoridad del emisor. El atacante ya no necesita falsificar firmas; utiliza tus propias claves privadas almacenadas en el servidor para validar sus envíos.

Este acceso se obtiene generalmente mediante la explotación de vulnerabilidades en protocolos de red (como el histórico CVE-2019-10149 en Exim), malas configuraciones de Relay abierto o credenciales administrativas débiles en interfaces de gestión web. Una vez dentro, el objetivo no es enviar spam masivo de inmediato —lo que activaría alarmas de volumen—, sino establecer una presencia persistente y difícil de detectar.

La persistencia en un servidor de correo se logra mediante la alteración de los flujos de ejecución estándar del sistema. El atacante busca sobrevivir a reinicios y auditorías básicas del sistema de archivos.

Inyección en Milters y filtros de contenido

Muchos MTAs utilizan Milters (Mail Filters) para procesar el correo (antivirus, firmas DKIM). Un atacante puede sustituir un binario de milter legítimo por uno malicioso o modificar su configuración para que cada correo entrante y saliente pase por un script de captura de datos antes de ser entregado.

Scripts en colas y tareas cron

La inserción de scripts en /etc/cron.d/ o la manipulación de los scripts de mantenimiento de las colas de Postfix (como postfix-flush) permite al atacante reinyectar mensajes maliciosos en la cola de salida de forma periódica sin dejar procesos activos permanentes en la memoria.

# Reinyecta una plantilla de phishing en la cola de Postfix cada 30 minutos
*/30 * * * * root /usr/sbin/postdrop -r < /var/lib/postfix/hidden/.malicious_msg

El control del MTA otorga acceso a la mail queue. El atacante puede leer correos en tránsito antes de que sean cifrados por TLS en el siguiente salto. Esto es crítico para el espionaje corporativo y la interceptación de tokens de restablecimiento de contraseñas.

Exfiltración mediante copia ciega (BCC) forzada

Una técnica común es configurar el MTA para que realice un Always BCC. Cada correo enviado o recibido por la organización se copia automáticamente a una dirección externa controlada por el atacante. Al ser una directiva del propio servidor, no aparece en las carpetas de "Enviados" del usuario final.

Modificación de mensajes en vuelo

El atacante puede programar el MTA para que detecte palabras clave (como "número de cuenta" o "instrucciones de pago") y altere el contenido del cuerpo del mensaje o de los adjuntos antes de que el correo salga hacia el destinatario. Dado que el servidor posee la clave DKIM, puede refirmar el correo modificado para que el receptor lo considere legítimo.

Para categorizar el nivel de riesgo en un incidente de infraestructura de correo, aplicamos la siguiente taxonomía basada en el comportamiento del atacante dentro del servidor.

1. Observador Pasivo

El atacante no envía correos. Su objetivo es la inteligencia. Monitoriza los archivos /var/mail/ o intercepta el tráfico en la cola para extraer datos sensibles. Es el compromiso más difícil de detectar sin herramientas de integridad de archivos (HIDS).

2. Inyector Activo

Utiliza la reputación del servidor para enviar campañas de malware o phishing altamente dirigidas. El volumen es bajo para evitar bloqueos por tasa de envío (rate limiting), pero la efectividad es máxima al pasar todos los filtros de autenticación.

3. Redireccionador de Tráfico

Modifica las tablas de transporte (transport_maps) para que correos dirigidos a dominios específicos sean desviados a servidores controlados por el atacante, permitiendo ataques de Man-in-the-Middle a nivel de protocolo SMTP.

4. Nodo de Comando y Control (C2)

Utiliza el protocolo SMTP como canal encubierto para enviar instrucciones a otros sistemas comprometidos dentro de la red. El tráfico de correo es tan habitual que suele pasar desapercibido para los firewalls de inspección profunda.

Imagina un escenario donde un atacante ha obtenido acceso root. En lugar de cambiar contraseñas, modifica la configuración de Postfix para crear un milter invisible.

1. Modificación de main.cf: El atacante añade un parámetro de inspección de contenido.

   content_filter = scan:[127.0.0.1]:10025

2. Creación del proxy: Abre un socket en el puerto 10025 que recibe el correo, guarda una copia en un directorio oculto y lo reenvía al proceso real de Postfix en el puerto 10026.
3. Ofuscación: Renombra su script de captura como postfix-log-cleaner para evitar sospechas en el listado de procesos (ps aux).

El resultado: el atacante tiene una copia de cada mensaje que entra o sale, y el servidor sigue funcionando con normalidad técnica.

La recuperación de un MTA comprometido no consiste en borrar scripts maliciosos; requiere la reconstrucción de la confianza en el sistema.

• Aislamiento y rotación: Si se confirma la intrusión, se deben rotar inmediatamente todas las claves privadas DKIM y certificados TLS. Las claves antiguas deben considerarse comprometidas.
• Auditoría de configuración: Comparar los archivos main.cf y master.cf (en el caso de Postfix) con versiones conocidas y seguras almacenadas en sistemas de control de versiones.
• Hardening de binarios: Utilizar herramientas como debsums o rpm -V para verificar que los binarios del MTA no hayan sido alterados.
• Principio de mínimo privilegio: Asegurar que los procesos del MTA corran bajo usuarios dedicados sin privilegios de ejecución sobre el resto del sistema operativo.

Ignorar estas señales puede prolongar la presencia del atacante durante meses:

• Confiar en el estado de DMARC: Un DMARC pass solo indica que el correo es legítimo desde el punto de vista del servidor, no que el contenido sea seguro.
• No monitorizar los logs de correo local: Ignorar mensajes de error en /var/log/mail.log que indiquen intentos de envío fallidos a direcciones IP extrañas desde el usuario www-data o postfix.
• Ignorar el uso de CPU/Red: No investigar picos de tráfico SMTP saliente que no coincidan con las campañas de marketing programadas.