Un usuario prepara un correo, adjunta un documento que utiliza habitualmente y lo envía. Poco después recibe una respuesta indicando que el mensaje fue rechazado porque contiene un virus o contenido potencialmente peligroso.
Prueba entonces algo aparentemente definitivo: envía exactamente el mismo archivo a Gmail y el mensaje llega.
La reacción es comprensible.
“Si Gmail lo recibe, el problema debe estar en el otro servidor”.
Pero esa conclusión puede ser equivocada.
Que un proveedor acepte un mensaje no demuestra que el archivo sea seguro. Del mismo modo, que otro servidor lo bloquee tampoco demuestra, por sí solo, que el documento esté infectado.
Entre ambos extremos existe una realidad mucho más interesante: cada plataforma utiliza sus propios motores de análisis, firmas, reglas y políticas de seguridad.
Entender esta diferencia es importante antes de cambiar configuraciones, pedir que se desactive el antivirus o incluso abandonar un servicio de correo pensando que está funcionando mal.
Qué significa realmente un error 550 por contenido peligroso
Los errores SMTP 550 pueden aparecer por diferentes razones. Una dirección inexistente, una política de rechazo o determinados problemas de seguridad pueden producir respuestas de esta familia.
Lo importante es leer el mensaje completo.
En el caso que motivó este artículo, la respuesta incluía:
550 This message contains a virus or other harmful content
y posteriormente identificaba una firma concreta:
YARA.ARKBIRD_SOLG_TA505_Maldoc_21Nov_2.UNOFFICIAL
También indicaba que el rechazo se había producido después de transmitir el contenido del mensaje.
Eso ofrece una pista importante.
El servidor no estaba diciendo simplemente que no reconocía al remitente o al destinatario. Había recibido el contenido y uno de sus mecanismos de seguridad encontró algo que coincidía con una regla considerada peligrosa.
En servidores cPanel, por ejemplo, ClamAV puede integrarse con Exim para analizar automáticamente el correo entrante. cPanel documenta expresamente este funcionamiento y permite además configurar análisis del correo saliente. cPanel & WHM Documentation
Por tanto, el rebote puede ser precisamente la consecuencia de una capa de seguridad funcionando antes de que el adjunto llegue al buzón del usuario.
Entonces, ¿por qué el mismo archivo puede llegar a Gmail?
Porque Gmail no utiliza necesariamente las mismas reglas que otro servidor.
Google dispone de sus propios sistemas de análisis y también bloquea contenido que considera peligroso. Su documentación indica expresamente que Gmail puede impedir el envío o recepción de determinados tipos de archivos, documentos con macros maliciosas y ciertos contenidos comprimidos o protegidos. Ayuda de Google
Esto desmonta una idea bastante extendida: Gmail no acepta todo.
Sin embargo, tampoco existe una base antivirus universal que obligue a todos los proveedores de correo a tomar exactamente la misma decisión ante cada archivo.
Un sistema puede utilizar sus propias tecnologías.
Otro puede trabajar con ClamAV.
Otro puede complementar ClamAV con firmas de terceros.
Otro puede utilizar reglas YARA adicionales.
Incluso utilizando herramientas similares, las versiones de las firmas, las configuraciones y los umbrales de decisión pueden ser diferentes.
Por eso dos servicios pueden observar exactamente el mismo archivo y llegar a conclusiones distintas.
Que Gmail permita el mensaje significa que sus sistemas no encontraron, en ese momento y bajo sus criterios, razones suficientes para bloquearlo. No significa que Google haya certificado que el documento está libre de cualquier riesgo.
La diferencia es importante.
Que un correo llegue no siempre es una buena noticia
Estamos acostumbrados a evaluar un servicio de correo con una pregunta muy sencilla:
“¿Llegó el mensaje?”
En seguridad debería existir una segunda pregunta:
“¿Qué llegó dentro del mensaje?”
Un correo puede contener una factura legítima, una propuesta comercial o una hoja de cálculo enviada entre compañeros.
Pero también puede contener un documento diseñado cuidadosamente para parecer una factura, una orden de compra o una hoja Excel de trabajo.
Durante años, los documentos de Microsoft Office fueron utilizados masivamente para distribuir malware mediante correo electrónico.
El procedimiento era efectivo precisamente porque el archivo no parecía peligroso.
La víctima veía Word o Excel.
El atacante veía un mecanismo mediante el cual podía intentar ejecutar código en la computadora.
Ese problema llegó a ser suficientemente serio como para que Microsoft cambiara el comportamiento de Office y comenzara a bloquear de forma predeterminada muchas macros procedentes de Internet.
Microsoft explica actualmente que las macros VBA han sido una vía habitual utilizada por actores maliciosos para desplegar malware y ransomware. La propia compañía recomienda bloquear las macros procedentes de Internet para la mayoría de usuarios empresariales. Microsoft Learn
No fue una modificación menor.
Medios internacionales especializados en seguridad consideraron aquel cambio una medida importante porque los delincuentes llevaban años utilizando documentos de Office enviados por correo para conseguir que los usuarios ejecutaran código. The Record documentó la importancia de la decisión y la presión que durante años había existido desde la comunidad de seguridad para endurecer el funcionamiento de las macros. The Record from Recorded Future
Las macros no son virus
Aquí también conviene evitar exageraciones.
Una macro no es sinónimo de malware.
Miles de empresas utilizan VBA diariamente para automatizar hojas de cálculo, procesar información, preparar reportes financieros, importar datos o realizar tareas que de otro modo requerirían muchas horas de trabajo.
El problema es otro.
Una macro tiene capacidad para ejecutar instrucciones.
Y esa misma capacidad legítima puede ser aprovechada con fines maliciosos.
Es algo parecido a un lenguaje de programación. El lenguaje no es peligroso por sí mismo. Importa lo que alguien programe con él.
Por esa razón un archivo empresarial completamente legítimo puede poseer algunas características que también aparecen en documentos utilizados históricamente para propagar malware.
Aquí entran en escena los sistemas de detección basados en patrones.
Qué es YARA y por qué aparece en algunos rebotes
YARA es una herramienta utilizada ampliamente por investigadores de seguridad para reconocer características dentro de archivos.
Una regla puede buscar cadenas, estructuras y patrones que anteriormente se hayan observado en una familia de malware o en determinados documentos sospechosos.
ClamAV admite reglas YARA y puede cargar archivos .yar y .yara como parte de sus mecanismos de detección. ClamAV Documentación
Esto tiene una ventaja evidente.
El antivirus no necesita depender únicamente del nombre del archivo o de un hash exactamente idéntico al de una muestra conocida.
Puede buscar características.
Pero esa capacidad también tiene una consecuencia: una coincidencia no siempre equivale a una identificación absoluta.
Un documento legítimo podría compartir determinados elementos con documentos utilizados anteriormente en ataques.
Ahí aparece la posibilidad del falso positivo.
Qué nos dice la firma del caso real
La detección que originó esta investigación es especialmente interesante:
YARA.ARKBIRD_SOLG_TA505_Maldoc_21Nov_2.UNOFFICIAL
La regla subyacente puede localizarse en bases públicas utilizadas para investigación de malware.
YARAify, un servicio de abuse.ch, identifica la regla como TA505_Maldoc_21Nov_2, atribuye su autoría a Arkbird_SOLG y señala como descripción original un archivo denominado invitation (1).xls. YARAify
Es decir, hablamos de una regla relacionada originalmente con un documento Excel sospechoso.
Además, muestras analizadas por YARAify que activan esta misma regla presentan simultáneamente otras coincidencias relacionadas con documentos Office que contienen VBA, hojas de macros ocultas y, en determinados casos, reglas asociadas a malware. YARAify
Eso demuestra que la detección tiene un contexto real de seguridad.
Pero hay que interpretar correctamente lo que significa.
Si un documento activa una regla cuyo nombre contiene TA505, no podemos afirmar automáticamente que el usuario tenga un virus de TA505 ni que su computadora haya sido comprometida.
La regla reconoce patrones.
No realiza una investigación forense completa sobre el origen del archivo.
De hecho, la misma regla aparece actualmente coincidiendo con otras muestras y contextos diferentes. Esto refuerza una idea fundamental: el nombre de una regla indica principalmente el contexto para el que fue creada, no constituye por sí solo una atribución definitiva. MalwareBazaar
¿Qué significa UNOFFICIAL?
Esta palabra también puede provocar una interpretación equivocada.
UNOFFICIAL no significa necesariamente “falso” ni “poco fiable”.
ClamAV mantiene bases oficiales de firmas que son administradas por Cisco Talos, pero su arquitectura también permite utilizar bases y reglas adicionales creadas por terceros. La propia documentación de ClamAV señala que las convenciones de nombres utilizadas por bases externas pueden diferir de las empleadas en sus firmas oficiales. ClamAV Documentación
Muchos administradores añaden este tipo de firmas para ampliar la capacidad de detección.
El beneficio es evidente: pueden encontrarse amenazas o patrones adicionales.
La contrapartida es que una firma externa mal ajustada, antigua o excesivamente amplia puede generar falsos positivos.
Y eso también está documentado.
En el proyecto clamav-unofficial-sigs existe, por ejemplo, un incidente histórico en el que determinadas reglas YARA para documentos maliciosos comenzaron a producir numerosos falsos positivos después de un cambio de versión de ClamAV. El reporte menciona incluso hojas XLS vacías y archivos PNG limpios que activaban las reglas. GitHub
Por eso una detección debe investigarse, no aceptarse ciegamente ni descartarse automáticamente.
El falso positivo es el costo de intentar detectar antes
Todo sistema de seguridad trabaja con un equilibrio.
Si las reglas son demasiado permisivas, algunas amenazas pueden pasar.
Si son excesivamente agresivas, documentos legítimos pueden quedar bloqueados.
Para una empresa, ambos escenarios tienen un costo.
Un falso positivo puede retrasar una cotización, impedir que llegue una hoja de trabajo o generar frustración en el usuario.
Un falso negativo puede ser mucho peor.
Puede permitir que un archivo realmente malicioso llegue al escritorio de un empleado.
La pregunta correcta no es cuál plataforma “deja pasar más correos”.
La verdadera pregunta es qué plataforma administra mejor el equilibrio entre seguridad y comunicaciones legítimas.
¿Entonces un servidor que bloquea más es automáticamente mejor?
Tampoco.
Bloquear indiscriminadamente no es una buena estrategia.
Un servidor que rechaza repetidamente archivos legítimos sin investigar la causa termina perjudicando la operación de sus clientes.
Peor todavía, demasiadas falsas alarmas pueden acostumbrar a los usuarios a ignorar los avisos de seguridad.
Por eso un servicio de correo bien administrado necesita dos cosas.
La primera es protección.
La segunda es capacidad para investigar las excepciones.
Cuando un cliente reporta un rechazo debería ser posible identificar qué archivo produjo el problema, qué firma intervino y si existen razones técnicas para considerar el documento peligroso.
Si finalmente se confirma un falso positivo, corresponde estudiar una solución específica.
Lo que no sería razonable es desactivar completamente el antivirus por un único archivo.
Gmail también necesita proteger a sus usuarios
Presentar este problema como una competencia entre Gmail y otros servidores sería un error.
Gmail posee una infraestructura de seguridad muy avanzada y también bloquea adjuntos peligrosos. Google reconoce específicamente la existencia de restricciones sobre archivos ejecutables, archivos comprimidos problemáticos y documentos con macros maliciosas. Ayuda de Google
La diferencia está en cómo cada sistema determina el riesgo.
Gmail puede aceptar un documento que active una regla YARA externa en otro proveedor.
También puede suceder lo contrario: Gmail puede bloquear algo que otro sistema permita.
Por eso utilizar Gmail como único mecanismo de comprobación no constituye un análisis antivirus.
“Llegó a Gmail” no equivale a “el archivo está limpio”.
Solo significa que Gmail decidió permitir ese mensaje bajo sus mecanismos actuales.
Los atacantes también cambian cuando cambian los filtros
Hay otro detalle que demuestra por qué los controles sobre archivos adjuntos son importantes.
Cuando Microsoft endureció la ejecución de macros procedentes de Internet, los delincuentes comenzaron a modificar sus métodos.
BleepingComputer documentó cómo distintas campañas fueron abandonando progresivamente los documentos con macros y utilizando en su lugar archivos ISO, RAR, accesos directos LNK y otros formatos. El mismo análisis citaba una caída importante del uso de macros y un fuerte crecimiento de otros contenedores después de que Microsoft anunciara sus cambios. BleepingComputer
Esto demuestra algo que a veces olvidamos.
Los filtros de seguridad influyen en el comportamiento de los atacantes.
Cuando una puerta se vuelve más difícil de abrir, buscan otra.
Por eso no tiene sentido pensar que un archivo es seguro únicamente porque no termina en .exe.
Un Excel puede ser peligroso.
Un documento Word puede ser peligroso.
Un archivo comprimido puede contener una amenaza.
Un acceso directo puede ejecutar instrucciones.
Incluso formatos aparentemente inocentes pueden utilizarse como parte de un ataque.
La seguridad moderna necesita analizar más que una extensión.
Qué hacer cuando un archivo legítimo es rechazado
La primera reacción no debería ser pedir que el antivirus se apague.
Hay una forma mucho más útil de investigar.
Primero, enviar el mismo correo sin archivos adjuntos. Si llega correctamente, la atención puede concentrarse en los documentos.
Después, probar los adjuntos individualmente. Si existen tres archivos, enviarlos por separado permite descubrir cuál activa la protección.
Revisar el formato del documento. Los Excel antiguos .xls, los .xlsm y otros formatos capaces de contener macros merecen una revisión especial.
Comprobar si las macros siguen siendo necesarias. Hay archivos empresariales que se reutilizan durante años y conservan código que nadie utiliza actualmente.
Si el código es necesario, revisarlo. Una macro legítima debería tener una finalidad conocida. Las organizaciones que realmente dependen de VBA pueden aplicar controles como ubicaciones confiables y firmas digitales según las recomendaciones de Microsoft. Microsoft Learn
Analizar la firma detectada. El texto del rebote suele contener información extremadamente útil. Una cadena como la que hemos estudiado permite investigar qué regla intervino.
No intentar engañar al filtro. Renombrar extensiones, comprimir repetidamente el archivo o utilizar contraseñas únicamente para conseguir que atraviese el antivirus no resuelve el problema. Puede incluso dificultar el análisis.
Si el archivo contiene información confidencial, tampoco conviene subirlo indiscriminadamente a servicios públicos de análisis. Una hoja de cálculo puede contener información financiera, datos de clientes o información interna que no debería compartirse externamente sin evaluar antes las implicaciones.
¿Y si realmente se trata de un falso positivo?
Entonces debe corregirse.
Pero de forma precisa.
Un administrador puede analizar qué base produjo la detección, comprobar si la regla continúa siendo adecuada y decidir si corresponde actualizarla, reportarla o aplicar una excepción concreta.
ClamAV contempla mecanismos para manejar firmas y archivos permitidos precisamente porque ningún sistema de detección es perfecto. ClamAV Documentación
Una excepción específica es muy diferente a apagar toda la protección.
La diferencia es comparable a permitir la entrada de una persona que ha sido identificada correctamente frente a dejar permanentemente abierta la puerta del edificio.
Colocar a toda una empresa en lista blanca tampoco es la mejor solución
Cuando el remitente es un cliente o proveedor importante puede surgir otra petición:
“Permitan todo lo que venga de este dominio”.
Hay que actuar con cuidado.
Un dominio legítimo no garantiza que todos sus futuros mensajes sean seguros.
Las cuentas empresariales también pueden ser comprometidas.
Un atacante que obtiene acceso al correo verdadero de un proveedor puede responder dentro de conversaciones existentes, utilizar nombres conocidos y enviar archivos desde una infraestructura que aparentemente es legítima.
Incluso una correcta autenticación SPF, DKIM o DMARC no certifica que un archivo adjunto esté libre de malware.
Son controles importantes, pero resuelven problemas diferentes.
Por eso las excepciones amplias deberían evitarse siempre que exista una alternativa más precisa.
Seguridad y comodidad no siempre apuntan en la misma dirección
Un servicio de correo que nunca bloquea nada puede parecer cómodo.
Hasta el día en que algo que debía bloquear tampoco sea detenido.
Un servicio que bloquea demasiado puede resultar igualmente problemático.
El objetivo no está en ninguno de los extremos.
La meta debería ser que el correo legítimo llegue y que el contenido peligroso encuentre suficientes barreras antes de alcanzar al usuario.
Eso exige motores actualizados, reglas bien mantenidas y personas capaces de investigar los casos donde la decisión no es evidente.
Un rechazo puede ser una oportunidad para descubrir un problema
Existe una forma distinta de observar estos incidentes.
Supongamos que una empresa lleva años enviando una hoja Excel con macros.
Un día un servidor la rechaza.
Puede tratarse de un falso positivo.
Pero la investigación también podría revelar que el documento contiene una macro antigua que ya nadie necesita, un objeto incrustado desconocido o código heredado cuyo origen nadie recuerda.
En ese caso el bloqueo habría puesto sobre la mesa un riesgo que permanecía oculto.
Incluso cuando finalmente descubrimos que el archivo es legítimo, revisar este tipo de documentos puede mejorar la higiene digital de una organización.
Cambiar de proveedor no debería ser la primera respuesta
Cuando un archivo llega a Gmail pero es rechazado por el correo corporativo, la facilidad con la que Gmail recibe el mensaje puede hacer pensar que migrar resolverá el problema.
Resolverá ese envío concreto.
Pero esa no debería ser la única medida para evaluar un servicio de correo.
Antes conviene preguntar:
¿Por qué se produjo el rechazo?
¿Qué encontró el servidor?
¿Era realmente una amenaza?
¿Se trató de un falso positivo?
¿Puede el proveedor identificarlo y corregirlo?
Estas respuestas ofrecen mucha más información sobre la calidad técnica de un servicio que comprobar simplemente si un archivo logró atravesar el filtro.
El correo más seguro no es el que permite todo
Hay una idea sencilla que resume todo este problema.
Un mensaje entregado no es necesariamente un mensaje seguro. Un mensaje rechazado tampoco es necesariamente una amenaza.
La diferencia está en la investigación.
Si el archivo es peligroso, el bloqueo habrá cumplido una función importante.
Si es legítimo, corresponde identificar el falso positivo y buscar una solución que no debilite la protección de todos los demás usuarios.
Esa es la forma adecuada de administrar correo empresarial.
No se trata de bloquear por bloquear.
Tampoco de permitirlo todo para poder decir que nunca existe un inconveniente.
Se trata de encontrar el equilibrio entre continuidad y seguridad.
Porque, al final, la pregunta más importante ya no debería ser solamente:
“¿Llegó mi correo?”
También deberíamos preguntarnos:
“¿Era seguro que llegara?”