EPF · Nota técnica
El 31 de agosto de 2026 llegó a contacto@epf-edu.com un correo que aparentaba ser de Hostinger. El asunto advertía sobre el supuesto vencimiento del servicio de hosting y el mensaje incluía un botón negro con el texto “Proceed with payment”.
La capa que delata el fraude no está en esta vista.
A simple vista, el correo se veía limpio, profesional y bastante convincente.
Pero había un problema: en los headers y en el código HTML, la historia de fondo era otra.
Esta nota documenta cómo analizamos el mensaje, de dónde salió, qué técnicas utilizó para intentar evadir los filtros antispam y, sobre todo, por qué no era un correo legítimo de Hostinger.
¿Qué veía el destinatario?
El correo utilizaba una estructura muy simple:
- Logo de Hostinger.
- Aviso de supuesto vencimiento del servicio.
- Monto a pagar: $14,18.
- Fecha de vencimiento: 02-09-2026.
- Botón “Proceed with payment”.
- Cierre genérico: “Please do not reply to this email”.
También aparecía un error de tipeo en el texto: paym ent.
¿Era suficiente para detectar el fraude?
No necesariamente.
Los correos legítimos también pueden contener errores, formatos extraños o detalles poco prolijos. Por eso, en un análisis de este tipo la apariencia visual es secundaria.
La evidencia importante está en una capa que normalmente el usuario no ve: los encabezados y el código fuente del mensaje.
La cadena de entrega
Analizando los headers de abajo hacia arriba aparece una cadena bastante clara.
1. El mensaje fue generado por una aplicación
Entre los encabezados aparece:
Received: by ... with HTTP
Esto indica que el mensaje fue generado mediante una aplicación o API, no mediante un usuario enviándolo manualmente desde Outlook, Thunderbird u otro cliente tradicional.
2. El envío pasó por Mailgun
El relay utilizado fue:
c64.c5341538.usw1.send.mailgun.net
IP:
198.244.56.64
La infraestructura corresponde a Mailgun Technologies, AS396479.
Hasta acá no hay nada necesariamente malicioso. Mailgun es una plataforma legítima de envío de correo transaccional.
El problema aparece cuando cruzamos esa información con las identidades del mensaje.
3. DKIM y SPF estaban en verde
El correo presentaba:
- DKIM: PASS, con
d=zapiermail.com - SPF: PASS, sobre el envelope
bounce+...@zapiermail.com - DMARC: none
Y acá aparece una confusión muy común:
SPF y DKIM en verde no significan que el correo sea de Hostinger.
Significan que el mensaje fue enviado correctamente desde una infraestructura autorizada para zapiermail.com.
Es decir:
El canal de envío era auténtico. La identidad que se estaba representando en el contenido era falsa.
Las identidades que no cierran
Los headers contienen varias señales de alerta.
| Campo | Valor | Problema |
|---|---|---|
| From | Support <no-reply.6in245@zapiermail.com> | Hostinger no opera desde zapiermail.com |
| Sender | no-reply.6in245@zapiermail.com | Es una cuenta de envío de Zapier |
| To | user.8920028@hostinger.t.me | No corresponde al destinatario real |
| Delivered-To | contacto@epf-edu.com | Es la verdadera casilla de entrega |
| Subject | Hostinger - Avoid interruption... | Suplanta la identidad de la marca |
| CTA | zpr.io/... | Acortador de Zapier, no dominio de Hostinger |
La diferencia entre To y Delivered-To es particularmente llamativa.
El mensaje terminó correctamente en contacto@epf-edu.com, pero el destinatario indicado dentro del MIME era:
user.8920028@hostinger.t.me
Eso no es un detalle menor.
El formato @hostinger.t.me resulta completamente ajeno a la dirección institucional que recibió el correo y sugiere que la plantilla utilizada no fue preparada específicamente para EPF.
Probablemente estamos ante una campaña, lista o automatización reutilizada.
El dominio del remitente lo delata
El remitente visible era:
no-reply.6in245@zapiermail.com
No era:
hostinger.com
support.hostinger.com
emails.hostinger.com
zapiermail.com
Por lo tanto, aunque el mensaje utilizara el logo, los colores y la identidad visual de Hostinger, el dominio autenticado por DKIM no pertenecía a Hostinger.
Esta es una de las reglas más importantes para cualquier análisis de phishing:
No confíes en el nombre que aparece junto al remitente. Mirá el dominio real.
El truco del texto invisible
Uno de los elementos más interesantes del mensaje estaba escondido dentro del HTML.
El cuerpo visible era corto y relativamente limpio, pero el código contenía bloques similares a:
<em style="font-size:0;">Analizar almacén sin cerebro ulceración ...</em>
El texto estaba configurado con:
font-size:0
Por lo tanto, el destinatario no lo veía.
¿Para qué sirve?
Para intentar modificar la forma en que los filtros antispam interpretan el contenido.
La técnica se conoce como hidden text o content stuffing.
La idea es sencilla: en lugar de enviar únicamente palabras asociadas a una factura, un pago urgente o una cuenta que está por vencer, el atacante agrega grandes cantidades de vocabulario aparentemente inocente, extraño o heterogéneo.
El usuario ve:
“Su servicio está por vencer → pagar”
El filtro, en cambio, encuentra una cantidad mucho mayor de palabras que pueden alterar su clasificación.
No es una técnica nueva, pero sigue siendo útil cuando se combina con infraestructura de correo legítima.
El logo tampoco necesitaba a Hostinger
Otro detalle interesante es que el logo no se descargaba desde hostinger.com.
Estaba embebido directamente dentro del mensaje mediante:
data:image/png;base64,...
Esto significa que la imagen viajaba dentro del propio correo.
El resultado es simple: el mensaje puede mostrarse correctamente aunque no tenga que conectarse a los servidores de Hostinger para descargar la imagen.
Visualmente, el correo queda completo y convincente.
¿Qué es zpr.io?
El botón “Proceed with payment” no apuntaba directamente a Hostinger.
Utilizaba un enlace zpr.io.
zpr.io pertenece al ecosistema de Zapier y funciona como acortador/redireccionador.
Que el dominio sea legítimo no significa que el destino final sea legítimo.
Un servicio de redirección puede ser utilizado por una automatización para enviar al usuario hacia distintos destinos.
Por eso, un dominio conocido tampoco convierte automáticamente en confiable el enlace que aparece dentro de un correo.
Y hay otra regla importante:
No hace falta abrir el enlace para confirmar el phishing.
Seguirlo puede proporcionar al operador información adicional, como la hora del clic, dirección IP, navegador o dispositivo utilizado.
En este caso, no se hizo clic.
¿De dónde salió realmente?
Con los headers podemos afirmar varias cosas:
- El envío fue generado mediante una automatización.
- La entrega utilizó Mailgun.
- La identidad autenticada correspondía a
zapiermail.com. - El mensaje utilizaba una plantilla falsa relacionada con un supuesto pago de Hostinger.
- Se incorporó texto invisible como mecanismo de evasión antispam.
- El enlace utilizaba
zpr.io.
Lo que no podemos determinar únicamente a partir del EML es quién estaba detrás de la automatización.
No podemos afirmar el nombre, país o identidad del operador.
Mailgun y Zapier son plataformas multiusuario. La información necesaria para identificar una cuenta concreta está del lado de sus sistemas y de sus equipos de abuso.
En criollo:
Zapier y Mailgun son el caño. El que abrió la canilla es un tercero.
¿Por qué casi parece legítimo?
El mensaje combina tres elementos que funcionan bastante bien juntos.
1. Infraestructura con buena reputación
No llegó desde un servidor casero o una dirección IP obviamente sospechosa.
Pasó por infraestructura de correo transaccional conocida y tenía SPF y DKIM válidos para el dominio utilizado.
2. Una copia visual mínima
No necesitaba un diseño sofisticado.
Logo + importe + fecha + botón de pago.
Eso alcanza para construir una apariencia convincente.
3. Urgencia y monto bajo
El mensaje planteaba una interrupción inminente del servicio y mostraba un importe relativamente pequeño: $14,18.
La combinación de:
“Avoid interruption” + vencimiento cercano + monto bajo
puede reducir las sospechas del destinatario.
¿Qué hicimos?
La respuesta fue sencilla:
- No se hizo clic en el botón.
- Se conservó el EML completo.
- Se reportó el mensaje a Hostinger mediante el canal correspondiente, enviando el original como adjunto.
- La información disponible también permite reportar la infraestructura utilizada ante los equipos de abuso correspondientes.
Conservar el EML completo es fundamental.
Una captura de pantalla permite ver el aspecto del mensaje.
El EML permite investigar cómo llegó, desde dónde, qué autenticaciones pasó y qué contiene realmente.
Sin headers no hay análisis forense. Hay una captura linda.
Reglas prácticas para el equipo
A partir de este caso, conviene quedarse con cuatro reglas simples.
1. El nombre del remitente no demuestra nada
Que aparezca:
“Support – Hostinger”
no significa que el correo sea de Hostinger.
Hay que revisar el dominio real del remitente y, cuando sea necesario, la identidad DKIM.
2. Revisá el destinatario real
Si el To: del mensaje no corresponde a nuestra dirección, hay una señal de alerta.
No demuestra por sí sola que sea phishing, pero sí que probablemente estamos frente a una campaña o plantilla reutilizada.
3. Nunca pagues desde un botón recibido por correo
Si existe una duda sobre una factura o vencimiento:
entrar al panel escribiendo la dirección oficial manualmente o utilizando la aplicación correspondiente.
No utilizar el botón del correo.
4. Guardá el EML
Si el mensaje resulta sospechoso, conservar el original permite analizarlo posteriormente.
Un .eml contiene información que desaparece cuando simplemente reenviamos el mensaje o hacemos una captura.
Conclusión
El mensaje analizado corresponde a un phishing que suplanta la identidad de Hostinger, utilizando infraestructura legítima de terceros y varias técnicas para aumentar su apariencia de autenticidad.
La cadena observada fue:
Automatización → Zapier → Mailgun → EPF
Mientras tanto, el contenido intentaba representar a:
Hostinger → supuesto vencimiento → pago
A eso se sumaron:
zapiermail.comcomo identidad de envío.zpr.iocomo redireccionamiento.- Texto oculto mediante
font-size:0. - Logo embebido en Base64.
- Un destinatario MIME que no coincidía con la casilla real de EPF.
- Urgencia y un importe pequeño para incentivar el clic.
No hay evidencia, por el solo hecho de haber recibido este correo, de que epf-edu.com o la cuenta de Hostinger de EPF hayan sido comprometidos.
El riesgo comenzaba en el momento de hacer clic.
Y ese clic no se hizo.
Si vuelve a aparecer una variante de esta campaña, la firma ya está identificada:
zapiermail.com + zpr.io + texto invisible + identidad de Hostinger + destinatario extraño.
En ese escenario, no hay que investigar haciendo clic.
A la basura, al reporte y seguimos trabajando.
Tambien te puede interesar la lectura de esta nota => https://epf-edu.com/seguridad-digital-emails-celular-redes-sociales/
ES: No se permiten comentarios con publicidad, enlaces promocionales o spam. Todos los comentarios pasan por moderación y requieren aprobación antes de publicarse.
EN: Comments containing advertising, promotional links, or spam are not allowed. All comments are moderated and must be approved before being published.