Proveedor Terraform falso: malware dentro de .woff

En pocas palabras: Un provider falso de AWS para Terraform, terraform-provider-awsbeta_v1.0.0, escondía malware cifrado con AES-256-CBC dentro de archivos .woff. Zscaler lo reportó el 8 de octubre de 2026, y los payloads se bajaban de un host DNS dinámico, GitHub y un sitio en Vercel, sin que ninguna plataforma esté comprometida.

Un proveedor Terraform falso de AWS, llamado terraform-provider-awsbeta_v1.0.0, escondía malware dentro de archivos .woff. Zscaler ThreatLabz detectó la campaña en julio de 2026 y la publicó el 8 de octubre de 2026, con sospecha de que detrás está el grupo norcoreano TraderTraitor.

terraform-provider-awsbeta_v1.0.0 es un binario en Go que se hace pasar por un provider de AWS para Terraform y ejecuta código malicioso apenas Terraform lo carga. Baja payloads cifrados disfrazados de fuentes web .woff, los descifra con AES-256-CBC y despliega FLATROOF, un backdoor en Rust, junto con stealers en Python que apuntan a credenciales de navegador y wallets cripto. Corre igual en laptops de desarrollo que en runners de CI/CD.

¿Qué es un provider de Terraform y por qué es un buen blanco?

Un provider de Terraform es un plugin ejecutable que Terraform carga para hablar con una plataforma de infraestructura, como AWS. Corre en la máquina donde ejecutás terraform init, plan o apply, así que hereda todo lo que esa máquina o ese pipeline ya pueden hacer. Los providers se publican en el Terraform Registry bajo una dirección tipo hashicorp/aws.

Escenario hipotético: te pasan un repo con un provider “beta” de AWS que no conocías y corrés terraform init en la laptop donde tenés el navegador logueado y las claves cloud a mano. Ahí no hace falta ningún exploit. Zscaler aclara que no sabe cómo llegó el binario a la víctima, así que no hay que asumir que pasó por el Registry.

¿Cómo se escondía el malware dentro de archivos de fuente .woff?

Cada archivo .woff trae datos reales de una fuente señuelo, el marcador @@ENDFONT@@ y, después, un ejecutable cifrado con AES-256-CBC. Según Zscaler, el loader extrae lo que viene tras el marcador, lo decodifica de Base64 y lo descifra con Python, Node.js, Perl u OpenSSL, lo que haya instalado en la máquina. Relacionado: desplegar una app React con Vite.

Los nombres que reporta dev.to son HiraginoSans-Bold.woff, NotoSansCJK-Regular.woff y MalgunGothic-Italic.woff. El loader arma el nombre según el sistema (familia de fuente) y la arquitectura (estilo), y Zscaler da el ejemplo de HiraginoSans-Regular.woff para un macOS con procesador ARM64.

Sistema	Familia en el nombre del .woff	Ruta del payload	Persistencia de FLATROOF
Linux	NotoSansCJK	$HOME/.config/git/update	Servicio
macOS	HiraginoSans	$HOME/Library/com.apple.iTunesCloud/SystemUpdate	Hook de logout del shell
Windows	MalgunGothic	$HOME/AppData/Local/Microsoft/Edge/service.exe	Clave Run del registro

Los estilos de arquitectura son Bold (x86_64/amd64), Regular (arm64), ExtraBold (ARMv7/ARMv6) e Italic (x86 de 32 bits). Por lo tanto, un MalgunGothic-Italic.woff apunta a Windows de 32 bits, una inferencia nuestra a partir del mapeo de Zscaler.

Ojo con esto: el cifrado no es lo ingenioso. Lo ingenioso es que un pedido de una “fuente” desde una URL raw de GitHub o un subdominio de Vercel es tráfico que un pipeline genera todo el día. Según dev.to, ninguna de esas plataformas fue comprometida; los atacantes usaron cuentas comunes.

¿Cómo actúa el proveedor Terraform falso de AWS al cargarse?

El binario conserva un scaffold funcional de provider, pero el atacante sumó un paquete malicioso llamado awsbeta y llamó a su rutina desde main. En palabras de Zscaler (traducción nuestra), “el código malicioso se ejecuta cuando Terraform inicia el provider”, mientras el provider sigue respondiendo con normalidad.

• Marca de ejecución única. Busca un archivo session.lock en el directorio temporal; si no existe, sigue.
• Descarga del loader. Pide por HTTPS un script Bash a hashicorp-terraform[.]io, un dominio que imita a HashiCorp, lo guarda como safari_updater y lo lanza como proceso desacoplado.
• Elección del payload. El script arma el nombre del .woff y lo intenta bajar de un DNS dinámico, de GitHub y de Vercel, en ese orden.
• Ejecución. Descifra y corre el binario. En macOS quita el atributo de cuarentena y aplica una firma ad hoc.

Sobre fechas: Zscaler dice que descubrió la actividad en julio de 2026 y publicó el 8 de octubre de 2026. Cuándo infectó a alguien, no está dicho. Si querés ver cómo se publica un sitio en Vercel, uno de los tres orígenes de descarga, tenés la guía para publicar tu web gratis en Vercel.

¿Qué hacen FLATROOF y ROOFDECK una vez instalados?

FLATROOF es un backdoor multiplataforma en Rust que se instala con persistencia propia y lanza stealers en Python. ROOFDECK es el segundo backdoor, que encuentra su servidor de control por canales redundantes. Dicho esto, el propio dev.to admite que el malware desempacado no es especialmente novedoso.

• Persistencia. Servicio en Linux, hook de logout en macOS y clave Run en Windows.
• Canales de control de FLATROOF. API de bots de Telegram, polling a un repositorio de GitHub y un webhook HTTP; no todos vienen configurados en cada muestra.
• Datos que roba. Credenciales y cookies de Chrome, Edge, Brave y Firefox, historial de shell y procesos en ejecución. En Windows suma Credential Manager y extensiones de MetaMask, Phantom, Trust Wallet y Rabby; en macOS, historial de Safari y login.keychain-db.
• ROOFDECK. Según Zscaler, descubre el C2 por configuración local, un paste de Pastebin firmado criptográficamente y metadatos de perfil de Nostr.

Así se lee la cadena en una sola oración: corrés terraform init, el provider responde como cualquiera, el loader baja un .woff que parece tráfico de build, el backdoor se instala con su persistencia, los stealers empaquetan cookies y claves de navegador, y desde afuera nada de eso se distingue de un día normal de trabajo. Zscaler también ve indicios de que partes de los scripts en Python se generaron con ayuda de un LLM (comentarios largos, emojis, nombres inconsistentes), pero eso es una inferencia suya.

¿Quién está detrás del ataque y qué está confirmado?

Zscaler vincula la campaña, como sospecha, con TraderTraitor (también rastreado como Jade Sleet, UNC4899, Pressure Chollima y Slow Pisces), un actor respaldado por el gobierno norcoreano que apunta al sector cripto. El título del informe dice “Suspected”, y esa palabra importa. La nota de dev.to no menciona atribución.

• Confirmado en el informe de Zscaler: la mecánica del provider, el loader, los nombres de archivo, las familias FLATROOF y ROOFDECK, y el solapamiento con el incidente KelpDAO. SentinelLabs reportó actividad relacionada de forma independiente.
• Sin confirmar: la autoría firme, cómo llegó el binario a la víctima, la fecha exacta de cada intrusión.
• Sin datos en las fuentes: cantidad de víctimas o dinero robado. No lo inventamos.

¿Cómo verificar que un provider de Terraform es legítimo?

Fijá el source y una versión exacta (por ejemplo hashicorp/aws con el operador “=”, no un rango), verificá checksums y no cargues providers que no reconocés en una máquina con credenciales. Eso es lo que recomienda dev.to, junto con dos prácticas más: Ya lo cubrimos antes en comparativa entre Vercel y AWS Amplify.

• Entornos descartables. Ejecutá Terraform lejos de perfiles de navegador y wallets; si la máquina nunca tuvo eso, los stealers no tienen qué llevarse.
• CI/CD con el mismo recelo que una laptop. Credenciales de corta duración, roles IAM de mínimo privilegio y runners sin estado entre jobs.

Ojo: el autor de esa nota promociona su propio servicio y acá no lo recomendamos. Si administrás servidores o un VPS en un proveedor local como donweb.com, el criterio no cambia: lo que ejecuta código en tu máquina de administración merece la misma sospecha que lo que corre en el servidor.

Propuesta editorial, no probada por nosotros ni atribuida a Zscaler, para revisar hoy:

• Auditá los source. Listá las direcciones en required_providers; un nombre tipo awsbeta fuera del namespace oficial merece una pregunta.
• Revisá el lock file. Commiteá .terraform.lock.hcl y mirá sus diffs en cada PR. Sirve para detectar cambios, no para probar que un provider es bueno; y si el binario se coló por fuera del Registry, no te cubre.
• Buscá los indicadores. Con los datos del informe, buscá session.lock y safari_updater en el directorio temporal, las rutas de la tabla y el dominio hashicorp-terraform[.]io en logs de DNS. Que no aparezca nada no prueba que estés limpio, pero si aparece, rotá credenciales.

Errores comunes

• Creer que pinear la versión alcanza. Una versión exacta de un source impostor sigue siendo un impostor. Primero verificá quién publica el provider.
• Bloquear GitHub o Vercel. No se comprometió ninguna de las dos, y bloquearlas no es realista. Mirá qué proceso pide el .woff: un provider o un shell en /tmp no es un navegador.
• Filtrar por extensión. Un .woff no parece ejecutable, y justo ahí está el truco. Mirá contenido y contexto de la descarga.
• Dejar runners con estado y credenciales largas. Un pipeline privilegiado con un provider sin verificar es peor que una laptop comprometida.

Preguntas Frecuentes

¿Qué es terraform-provider-awsbeta?

Es un binario en Go que imita a un provider de AWS para Terraform y ejecuta código malicioso al cargarse. Zscaler lo describe en su informe del 8 de octubre de 2026. Conserva un scaffold funcional para que no se note.

¿Cómo puede un archivo .woff contener malware?

Un .woff de esta campaña lleva datos de fuente reales seguidos del marcador @@ENDFONT@@ y un ejecutable cifrado. Un loader corta lo que sigue al marcador, lo descifra y lo corre; la fuente nunca se usa como tal.

¿Qué roba el malware FLATROOF?

Roba credenciales y cookies de Chrome, Edge, Brave y Firefox, historial de shell y procesos. En Windows suma Credential Manager y extensiones de MetaMask, Phantom, Trust Wallet y Rabby; en macOS, el historial de Safari y login.keychain-db. En crear una máquina virtual en Azure con Terraform profundizamos sobre esto.

¿Cómo verifico que un provider de Terraform es legítimo?

Confirmá que el source sea el esperado (por ejemplo hashicorp/aws), fijá una versión exacta y verificá checksums. Corré Terraform en un entorno descartable y con credenciales de corta duración.

¿Quién está detrás del ataque al provider falso de AWS?

Zscaler sospecha de TraderTraitor, un grupo respaldado por Corea del Norte. Es una atribución con reserva: el informe la presenta como “suspected” y las fuentes no traen confirmación independiente de autoría.

Conclusión

Lo que cambia con este caso es que el vector no es un exploit sino un plugin que corrés vos mismo, con tus credenciales. Que el malware no sea novedoso importa poco: el disfraz de fuente web y la entrega desde GitHub y Vercel hacen que las defensas por reputación de dominio lleguen tarde.

Qué hacer esta semana: auditá los source de tus proyectos, commiteá el lock file, buscá los indicadores de Zscaler en endpoints y runners, y sacá las credenciales largas de los pipelines. Y tomá la atribución a Corea del Norte con pinzas hasta que haya más evidencia.

Fuentes

• Zscaler ThreatLabz – Análisis técnico de la campaña con el provider de Terraform troyanizado (8 de octubre de 2026)
• dev.to – Resumen de la campaña y recomendaciones defensivas