¿Tu correo corporativo está enviando spam? Cómo investigar qué ocurrió

El incidente suele comenzar con una escena desconcertante: una cuenta corporativa recibe mensajes de “Mail Delivery System” por correos que ninguna persona de la empresa reconoce. Puede tratarse de publicidad no solicitada, destinatarios desconocidos o entregas rechazadas.

Es una señal que merece atención, pero no demuestra por sí sola que el servidor haya sido vulnerado ni que la contraseña haya sido robada. El remitente visible puede haber sido falsificado, puede existir un envío autenticado o pueden coincidir varios problemas diferentes. Antes de cambiar configuraciones a ciegas, hay que reconstruir qué ocurrió.

En una intervención técnica real y completamente anonimizada, la revisión separó los síntomas observados, la evidencia del transporte de correo y las posibles superficies de exposición. Ese criterio resulta más útil que intentar atribuir una causa apenas aparece el primer indicio.

Los rebotes son un síntoma, no una explicación

Un rebote informa que se intentó entregar un mensaje y que algún servidor no pudo o no quiso aceptarlo. Puede incluir el motivo del rechazo y, en ocasiones, una copia del mensaje original. Por sí solo no establece quién originó el envío ni qué mecanismo utilizó.

Para avanzar hay que conservar el mensaje completo, no solo una captura de la bandeja de entrada. El archivo EML, sus encabezados y los registros del servicio de correo permiten comparar lo que afirma el mensaje con lo que realmente aceptó y procesó el servidor.

Spoofing y SMTP autenticado no son lo mismo

El spoofing consiste en falsificar el campo From para que un mensaje parezca provenir de una dirección determinada. En ese escenario, el correo puede haberse originado fuera de la infraestructura de la empresa, del mismo modo que una carta puede llevar un remitente escrito que no corresponde a quien la envió.

Un registro de SMTP autenticado muestra algo distinto: el servidor aceptó credenciales válidas de la cuenta o un mecanismo autorizado para enviar. Eso confirma un uso que debe explicarse cuando la empresa no lo reconoce. No identifica automáticamente a una persona, no demuestra dónde se obtuvo la contraseña y tampoco descarta que una aplicación legítima estuviera configurada con esa cuenta.

Los encabezados describen el recorrido del mensaje; los logs del servidor ayudan a comprobar cómo fue aceptado.

Si los logs correlacionados muestran autenticación SMTP con la cuenta afectada, explicar todo como una simple falsificación externa del From ya no es suficiente.

Qué revisar en el EML, los encabezados y los logs

La lectura debe realizarse de forma correlacionada. Un campo aislado puede ser incompleto, estar ausente o pertenecer a un salto intermedio. En una revisión técnica suelen considerarse, entre otros, estos elementos:

• Las líneas Received, para reconstruir los servidores que registraron el transporte y su orden aproximado.
• Los resultados de autenticación disponibles, como SPF, DKIM o DMARC, entendiendo qué identidad evalúa cada uno.
• La presencia de TLS, que informa si un tramo fue cifrado, pero no demuestra que el remitente fuera legítimo.
• El usuario autenticado o identificador equivalente que figure en el registro SMTP.
• La IP de origen registrada por el servidor, usada como dato de correlación y no como prueba automática de identidad personal.
• Los timestamps, normalizados por zona horaria para evitar relacionar eventos que en realidad ocurrieron en momentos distintos.
• El Message-ID y otros identificadores de cola o transacción que permitan enlazar el mensaje, el rebote y las entradas del log.

La comparación entre esos datos permite determinar si existe evidencia de envío autenticado, si el rebote corresponde al mismo mensaje y si aparecen patrones de actividad no reconocida. El análisis puede hacerse sin publicar direcciones, IP, nombres de host ni otros datos reales del incidente.

Cambiar la contraseña contiene el incidente, pero no explica el origen

Rotar la contraseña es una medida prioritaria cuando hay indicios de uso no autorizado. También conviene cerrar sesiones o credenciales de aplicación relacionadas cuando el servicio lo permita. Después hay que comprobar que cesen los envíos desconocidos y verificar tanto el envío como la recepción legítimos.

Que la actividad se detenga después del cambio fortalece la relación entre la credencial anterior y el envío, pero todavía no explica cómo quedó expuesta. La revisión debe continuar sobre los equipos, aplicaciones, reenvíos y lugares donde la cuenta fue configurada o almacenada.

La evidencia de un incidente puede confirmar el uso no autorizado de credenciales sin permitir determinar de forma concluyente dónde o cómo fueron obtenidas.

Revisar los equipos que utilizaron la cuenta

Los dispositivos que usaron la cuenta forman parte de la superficie de exposición. La revisión debe abarcar los equipos actuales y, cuando sea posible, los equipos históricos o aplicaciones que todavía podrían conservar la credencial.

• detecciones de malware u otro software no confiable;
• extensiones de navegador innecesarias o de procedencia dudosa;
• contraseñas almacenadas en navegadores, clientes de correo o aplicaciones;
• software dudoso que haya solicitado acceso o permisos elevados;
• herramientas de acceso remoto instaladas y su necesidad operativa;
• sistemas operativos, navegadores y aplicaciones desactualizados.

Cada hallazgo ayuda a medir exposición y a decidir qué corregir. Ninguno demuestra por sí solo que ese equipo, el navegador o una herramienta remota haya sido el punto inicial del incidente.

Encontrar malware no demuestra causalidad

Encontrar malware y una cuenta comprometida al mismo tiempo no demuestra automáticamente que el malware haya obtenido la contraseña.

Hecho confirmado

Es aquello que la evidencia permite sostener directamente. En el caso que sirve de base a este artículo, los registros correlacionados confirmaron que el servidor aceptó SMTP autenticado con la cuenta y que la actividad no fue reconocida por sus usuarios.

Indicio

Es un hallazgo relevante que aumenta o reduce una posibilidad, como detectar software malicioso, encontrar una contraseña almacenada o registrar conexiones externas inusuales. Requiere contexto y no debe presentarse como una causa demostrada.

Hipótesis

Es una explicación posible que debe contrastarse con más evidencia. El malware pudo intervenir, la credencial pudo quedar expuesta en otro equipo o una configuración antigua pudo seguir activa; si no es posible comprobarlo, la conclusión correcta es mantener el origen como no determinado.

Dos problemas pueden ocurrir al mismo tiempo

El escenario anonimizado mostró por qué conviene separar líneas de investigación. Una cuenta utilizada para reenvíos legítimos estaba llena y generaba fallos reales de entrega. Al mismo tiempo, otra evidencia confirmó envío no autorizado mediante SMTP autenticado.

El problema de almacenamiento explicaba una parte de los rebotes, pero no la actividad no reconocida. Resolver solo el espacio disponible habría dejado abierta la segunda causa; atribuir todos los rebotes al abuso de la cuenta también habría ignorado el fallo operativo legítimo.

Medidas de contención y recuperación

La respuesta debe adaptarse al servicio, a los equipos involucrados y a la evidencia disponible. Como guía general —no como un checklist universal— puede ser razonable:

1. Cambiar la contraseña de la cuenta afectada mediante un canal y un equipo confiables.
2. Detener o limitar el vector identificado, por ejemplo una credencial, aplicación o sesión que ya no deba enviar.
3. Verificar que el correo legítimo pueda enviarse y recibirse después de los cambios.
4. Revisar los logs posteriores para comprobar si continúan los intentos o envíos no reconocidos.
5. Comprobar reenvíos, reglas, alias y aplicaciones autorizadas asociados a la cuenta.
6. Revisar los equipos que utilizaron la credencial, sin asumir de antemano cuál fue el origen.
7. Actualizar el sistema, el navegador, las aplicaciones y las medidas de seguridad compatibles con el servicio.
8. Rotar credenciales críticas relacionadas cuando exista riesgo de reutilización o exposición compartida.
9. Vigilar nuevos rebotes, bloqueos y alertas para detectar una reaparición temprana.

Después de recuperar la operación, conviene revisar si la infraestructura de correo corporativo, DNS y autenticación del dominio mantiene una configuración coherente con las necesidades actuales de la empresa.

Conservar evidencia evita perder el contexto

Los cambios urgentes pueden eliminar sesiones, rotar identificadores o acortar el periodo disponible de los logs. Por eso conviene guardar, con acceso restringido, los EML originales, encabezados completos, registros relevantes, timestamps normalizados, identificadores de mensaje o cola y capturas que aporten contexto.

Esa evidencia permite reconstruir la secuencia, comparar lo ocurrido antes y después de la contención, explicar decisiones técnicas y evitar que una conclusión dependa solo de recuerdos. Debe conservarse únicamente lo necesario y protegerse porque puede incluir información sensible.

Riesgo operativo y reputacional

El envío no autorizado puede afectar la entrega de mensajes legítimos, activar límites o bloqueos del proveedor y deteriorar la reputación del dominio o de la IP utilizada para enviar. El alcance depende de la infraestructura y de cómo respondan los destinatarios y servicios involucrados; no todos los incidentes producen el mismo efecto.

Para una pequeña o mediana empresa, el impacto no se limita al correo: cotizaciones, facturas, reservas, soporte y coordinación interna pueden retrasarse si los mensajes dejan de llegar. Recuperar la continuidad exige comprobar la operación real, no solo confirmar que la contraseña ya fue cambiada.

Cuándo pedir ayuda técnica

Conviene solicitar apoyo cuando los rebotes continúan, aparecen mensajes desconocidos, el servicio aplica bloqueos, el cambio de contraseña no detiene el problema, la cuenta fue utilizada en múltiples equipos o resulta difícil interpretar los logs. También cuando la entrega del dominio empieza a afectar la operación o existe un riesgo reputacional que requiere actuar con orden.

Un diagnóstico de soporte e infraestructura puede ayudar a correlacionar mensajes, autenticación, registros y equipos, contener la actividad y dejar claros los hechos, indicios e hipótesis. Si el caso requiere atribución, preservación legal de evidencia o un peritaje certificado, debe intervenir un especialista forense con el alcance correspondiente.