Septiembre en Bolivia: usaron su nombre, pero no su cuenta
Llegaron errores de entrega por correos que una persona nunca había enviado. Detrás había un falso pago, una identidad copiada y un archivo esperando el clic.
El primer error de entrega pudo parecer una equivocación. Después llegaron más. Todos hablaban de un pago y devolvían mensajes que la persona nunca había escrito. Su dirección figuraba como remitente, pero ella no había enviado nada.
La cuenta protegida por Piensa Maildog permanecía intacta. Los mensajes se habían enviado desde servidores ajenos a nuestro servicio, usando el nombre y la dirección de la persona como disfraz.
Una identidad conocida y un falso comprobante ya son un engaño convincente. Cuando se suman servidores que no verifican bien al remitente, la combinación se vuelve peligrosa: el mensaje puede ganar una confianza que no merece. Proteger el correo también consiste en comprobar ese origen, antes de confiar en lo que aparece en pantalla.
Ese fue uno de los casos que dejó septiembre en el correo de empresas bolivianas. Piensa Maildog detectó 12,8 % menos correos sospechosos que en agosto, pero aumentó el peso de los mensajes con adjuntos peligrosos: pasaron de 3,1 % a 11,4 %. Los comprobantes y las cotizaciones merecían una segunda mirada.
El cierre de mes trajo el mayor pico
El 30 de septiembre reunió 14,0 % de los correos sospechosos detectados durante el mes. El día 2 también destacó, con 8,4 %. Y la mayor parte de la actividad coincidió con la semana laboral: 87,5 % llegó de lunes a viernes.
Eran mensajes capaces de mezclarse con una compra pendiente, una confirmación de pago o una respuesta a proveedores. El engaño empezaba en un terreno conocido: lo que una persona espera encontrar mientras trabaja.
La protección detrás de este boletín
Nuestros clientes cuentan con Antivirus & AntiSpam Piensa Maildog y atención especializada como parte del servicio de Correo Corporativo Empresarial. Este boletín se elabora a partir de los mensajes y adjuntos que esa protección identifica como no deseados o peligrosos.
En el caso que contamos a continuación, la cuenta del cliente permaneció intacta. Su identidad fue suplantada en envíos originados fuera de nuestro servicio.
El “Pago” que llevaba una identidad prestada
El asunto decía “Pago”. Nada más. Dentro, una petición breve: confirmar la recepción de una transferencia hecha el día anterior. El supuesto comprobante venía adjunto.
Para alguien que coordina cobros o revisa proveedores, era una solicitud corriente. Precisamente por eso podía funcionar. No pedía hacer algo extraño; pedía terminar una tarea.
El remitente aparente era una persona real. Su dirección prestaba al mensaje una confianza que el atacante no había ganado. Al abrirlo, quien lo recibiera podía pensar primero en el pago y después en comprobar de dónde venía.
Las copias conservadas en los rebotes incluían un archivo comprimido 7z. El mensaje buscaba acercar ese archivo a alguien dispuesto a revisarlo.
Los envíos no salieron del buzón de la persona suplantada: se realizaron desde fuera de nuestro servicio, falsificando el remitente. Para poner tu dirección en un correo, un atacante no siempre necesita tu contraseña.
Y después llegaron las devoluciones
Parte de los destinatarios rechazó los mensajes. Algunos sistemas enviaron entonces el aviso de error a la dirección que figuraba como remitente: la de la persona suplantada.
Así, una cuenta inocente recibió las consecuencias de un envío ajeno. Es el fenómeno conocido como backscatter: rebotes de correos que no salieron de tu buzón.
La escena puede alarmar. Ves tu dirección, un asunto que no reconoces y mensajes devueltos por distintos servidores. Pero el rebote, por sí solo, no prueba que alguien haya entrado en tu cuenta. Hay que comprobar el origen.
Los avisos devolvieron además una pista: esos mensajes no superaban las comprobaciones de identidad y no llevaban firma DKIM. El nombre que aparecía en pantalla no coincidía con una identidad autenticada.
Ahí cobra valor la configuración del correo. SPF, DKIM y DMARC ayudan a comprobar qué servidores pueden enviar por un dominio y si el mensaje está autenticado para la identidad que muestra. El receptor debe aplicar esas comprobaciones. Reconocer el nombre de una persona no las reemplaza.
La cotización escondía un programa
El 2 de septiembre apareció otro señuelo de trabajo: una cotización dentro de un RAR. Maildog identificó JS.Muldrop.1419, un programa malicioso escrito en JavaScript.
El archivo parecía una respuesta comercial. En realidad, la detección correspondía a una familia de pequeños programas que puede poner en marcha otro software malicioso. La cotización era la excusa para dar ese primer paso.
Para la persona frente a la pantalla, el riesgo empieza antes de ver síntomas. Ejecutar un archivo ajeno puede abrir paso a una infección que busque contraseñas, sesiones o documentos accesibles desde el equipo. El nombre “cotización” no reduce ese riesgo.
El supuesto PDF era un programa
En otro envío, el nombre lo decía casi todo: ordendecomprapdf.exe.
La parte “pdf” invitaba a leerlo como un documento. El final “.exe” revelaba un programa de Windows. El truco dependía de una revisión rápida, justo cuando una orden de compra parece una buena noticia y quieres abrirla.
Maildog señaló ese programa como peligroso. Para reconocerlo sin ser especialista, basta una regla práctica: mira la extensión completa, no solo la palabra que te resulta familiar. Un PDF no termina en “.exe”.
Si esto ocurre en tu empresa
Primero hay que comprobar si alguien copió tu dirección o consiguió entrar en tu cuenta. La respuesta cambia según lo que haya ocurrido.
- Conserva una muestra del rebote y pide una revisión a quien administra tu correo. No abras el mensaje original adjunto ni elimines automáticamente todos los errores de entrega: también podrías ocultar problemas de tus envíos reales.
- Confirma los pagos por otro canal. Usa un teléfono o contacto que ya conocías, especialmente si el mensaje cambia instrucciones, cuentas bancarias o pide abrir un archivo.
- Revisa la protección de tu dominio. Pide que comprueben SPF, DKIM y DMARC, además del filtrado de mensajes y adjuntos. Tener correo con tu nombre de empresa requiere mantener esos controles.
- Protege también los equipos. Mantén el antivirus actualizado. Si alguien ejecutó un archivo sospechoso, desconecta ese equipo de la red y solicita una revisión antes de seguir trabajando.
- Activa la verificación en dos pasos. Si hubo acceso ajeno o se entregó una contraseña, cámbiala desde un equipo limpio, cierra las sesiones y revisa los reenvíos y métodos de recuperación.
En PiensaHost combinamos estas capas en nuestro Correo Corporativo Empresarial, con Antivirus & AntiSpam Piensa Maildog. Si buscas proteger el correo de tu empresa en Bolivia, podemos revisar contigo qué necesita tu operación.
Correos sospechosos: respuestas para quien los recibe
¿Por qué mi correo envía mensajes solo o manda spam?
Puede haber dos causas muy distintas: alguien entró en tu cuenta o alguien falsificó tu dirección desde otro servidor. Un aviso de devolución no permite distinguirlas por sí solo. Conviene revisar los accesos recientes, los reenvíos y el mensaje original antes de decidir qué ocurrió.
¿Por qué recibo correos rebotados que no envié?
Un atacante puede haber puesto tu dirección como remitente de sus envíos. Algunos servidores devuelven entonces los errores a tu buzón. Se llama backscatter. Guarda una muestra y solicita una revisión; no abras los archivos que acompañen al supuesto mensaje original.
¿Cómo saber si un correo es falso en Gmail u Outlook?
Comprueba la dirección completa, qué te pide hacer y si esperabas ese mensaje. Para un pago o cambio de cuenta bancaria, confirma por otro canal conocido. Que el correo tenga un logo correcto o pase una comprobación de identidad no garantiza que el contenido sea seguro. Puedes consultar las recomendaciones de Google sobre phishing.
¿Un correo de alguien conocido también puede ser peligroso?
Sí. Pueden copiar su nombre, utilizar un dominio parecido o enviar desde una cuenta auténtica a la que hayan accedido. Si el pedido cambia una forma de pago, solicita contraseñas o trae un archivo inesperado, confirma con esa persona por un contacto que ya conocías.
¿Qué hago si abrí un enlace, ejecuté un adjunto o escribí mi contraseña?
Si solo abriste el enlace, ciérralo y no descargues ni completes formularios. Si escribiste una contraseña, cámbiala desde el servicio auténtico, cierra sesiones y revisa los métodos de recuperación. Si ejecutaste un archivo sospechoso, desconecta el equipo de la red y pide una revisión. Informa también de cualquier aprobación de acceso que hayas concedido.
¿Es seguro abrir un archivo que viene dentro de un error de entrega?
No necesariamente. El aviso puede incluir una copia del correo rechazado y sus adjuntos. Si nunca enviaste ese mensaje, no abras los archivos para averiguar qué pasó: conserva el aviso y deja que quien administra tu correo lo revise.
¿El antivirus y el antispam hacen lo mismo?
Cumplen tareas distintas y se complementan. El antispam ayuda a identificar mensajes no deseados y patrones de engaño; el antivirus busca indicios de programas maliciosos. La protección del correo también necesita comprobar remitentes, revisar enlaces y mantener seguras las cuentas.
¿Qué conviene pedir al contratar correo corporativo para una empresa en Bolivia?
Pregunta cómo protegen tu dominio frente a la suplantación, cómo filtran mensajes y adjuntos, cómo puedes activar la verificación en dos pasos y quién investiga un incidente. Revisa también las opciones de respaldo y recuperación: disponer de una copia no equivale a haber comprobado que se puede restaurar.
Para quien administra el correo: cabeceras, SPF, DKIM, DMARC y errores de entrega
¿Cómo ver las cabeceras completas de un mensaje en Gmail y Outlook?
En Gmail desde una computadora, abre el menú del mensaje y elige “Mostrar original”. En Outlook, la opción depende de la versión: puede aparecer como detalles del mensaje o encabezados de Internet. Las guías oficiales de Gmail y Outlook explican cómo obtenerlas. Una captura de pantalla no contiene toda esa información.
¿Qué revisar en Received, Return-Path y Authentication-Results?
Received ayuda a reconstruir el recorrido entre servidores. Return-Path identifica la dirección utilizada para las devoluciones. Authentication-Results registra comprobaciones como SPF, DKIM y DMARC. Hay que contrastar la cadena y confiar en los resultados del sistema receptor conocido: un atacante también puede insertar cabeceras engañosas. Una IP puede indicar un servidor o intermediario, no necesariamente al autor del ataque.
¿Por qué aparece SPF pass pero DMARC fail?
SPF puede aprobar un dominio distinto del que el usuario ve en From. Para que DMARC apruebe, al menos una comprobación válida de SPF o DKIM debe estar alineada con ese dominio visible. Es habitual revisar esta diferencia cuando una aplicación, una plataforma de facturación o un proveedor externo envía en nombre de la empresa. Microsoft explica esa alineación de DMARC.
¿Qué significan los errores 550 5.7.1 y 550 5.7.26?
Indican rechazos cuyo motivo hay que leer completo. Un 5.7.1 puede responder a políticas del receptor; no identifica por sí solo una infección. Gmail utiliza 5.7.26 para determinados fallos de autenticación o políticas relacionadas con SPF y DMARC. Conserva el texto del error antes de cambiar DNS o reintentar envíos. La tabla oficial de errores de Gmail distingue los casos.
¿Qué diferencia hay entre DMARC p=none, quarantine y reject?
None permite observar resultados sin solicitar una acción por el fallo DMARC; quarantine pide tratar el mensaje como sospechoso y reject solicita rechazarlo. El receptor aplica sus políticas. Antes de endurecer la configuración, identifica todos los sistemas legítimos que envían por tu dominio y revisa los informes. Google recomienda un despliegue progresivo de DMARC.
¿Cómo comprobar los registros SPF, DKIM y DMARC de un dominio?
Son consultas de lectura. En un equipo con dig, puedes consultar los TXT así:
dig +short TXT example.comdig +short TXT _dmarc.example.comdig +short TXT SELECTOR._domainkey.example.comEn Windows puedes utilizar:
nslookup -type=TXT example.comnslookup -type=TXT _dmarc.example.comnslookup -type=TXT SELECTOR._domainkey.example.comSustituye example.com por el dominio que administras y SELECTOR por el valor s= de su firma DKIM. Tener registros publicados no prueba que un envío concreto supere las comprobaciones: contrástalo con las cabeceras de una entrega real y con la alineación del remitente.
¿Por qué mis correos legítimos llegan a spam aunque SPF y DKIM estén bien?
La autenticación es una parte de la evaluación. También influyen la reputación de envío, los mensajes que los usuarios marcan como spam, los enlaces y las prácticas de envío. Comprueba los resultados del mensaje real y el diagnóstico del receptor; no añadas servidores al SPF ni desactives filtros sin identificar la causa.
