Un fraude de empleo desde un tenant legítimo de Odoo: SPF, DKIM y DMARC pasan

Un administrador de sistemas recibió una supuesta invitación de trabajo de Bolt y dedicó un rato a comprobar si era phishing. La conclusión es incómoda: el mensaje salió desde una instancia real de Odoo controlada por quien lo envió, y las cabeceras pasaron SPF, DKIM y DMARC sin un solo fallo.

La dirección del remitente era customer-care@bolt-job-invitation.odoo.com. Quien lo montó no falsificó el dominio de Bolt: creó una base de datos en Odoo llamada bolt-job-invitation y usó la funcionalidad de helpdesk para disparar el correo. La cadena de Received apunta a la infraestructura de correo legítima del proveedor. Es decir, Odoo estaba autorizado a enviar ese mensaje en nombre de ese subdominio, y eso es exactamente lo que certifican los registros de autenticación. La marca suplantada iba en el contenido y en el nombre del tenant, no en el sobre.

La autenticación valida el dominio, no a la persona

Aquí está el malentendido que conviene desmontar. Que un correo pase SPF, DKIM y DMARC significa que el servidor que lo envió tenía permiso para hacerlo sobre ese dominio concreto. No dice nada sobre quién está detrás del dominio ni sobre si representa a la empresa que dice representar. Cualquiera puede registrar un subdominio en un SaaS multiinquilino y quedar perfectamente alineado desde el punto de vista técnico.

El resto de señales apuntaban en la misma dirección. Todos los enlaces llevaban a bolt-job-invitation.odoo.com, mientras que la presencia corporativa y de empleo de Bolt vive bajo bolt.eu. El mensaje no era un correo al uso, sino un ticket de helpdesk (helpdesk.ticket-12) con texto genérico: decía haber encontrado el perfil del destinatario sin mencionar puesto, equipo ni ubicación. En el pie aparecía además una dirección sin relación aparente, terminada en @aniimate.net. Y el nombre del remitente no se podía vincular a Bolt por ninguna fuente pública.

Qué implica para quien filtra correo

Las reglas basadas solo en la alineación de dominios no van a detectar esto, y no es un fallo de configuración: es el comportamiento esperado. Si el filtro de la organización da por bueno todo lo que pasa DMARC, este tipo de campaña entra sin rozar la cuarentena.

Lo que sí ayuda es mirar el dominio de envío y no solo el resultado de la autenticación. Un remitente que se presenta como una empresa conocida desde un subdominio de un proveedor de SaaS ajeno a esa empresa es una señal barata y bastante fiable. Los dominios multiinquilino de plataformas como Odoo, HubSpot o cualquiera con subdominios por cliente son un vector cómodo: no hay que comprar dominio, ni calentar reputación, ni pelear con listas de bloqueo.

Queda por ver si el proveedor toma medidas contra tenants que se usan para suplantar marcas y cuánto tarda en hacerlo. Mientras tanto, la pregunta útil para el lector no es si el correo está autenticado, sino a nombre de quién está autenticado.