Cómo una invitación falsa a una conferencia de criptomonedas convirtió Google Docs en una herramienta de distribución de malware

La campaña combinó un contexto profesional creíble con servicios digitales conocidos. Una cuenta de X, @HartmansDoeke, afirmaba representar a CoinDesk y contactó a personas vinculadas con Black Hat y DEF CON, primero mediante respuestas públicas y después por mensajes directos. El atacante propuso una supuesta conferencia de criptomonedas organizada por CoinDesk y compartió un Google Doc presentado como material de planificación. 1411

El matiz importante es que el documento de Google podía parecer completamente normal. La actividad maliciosa procedía de una interfaz integrada mediante Google Apps Script y de las instrucciones que aparecían en ella. Los informes disponibles describen un intento de distribuir malware, pero no confirman que el investigador de Huntress ni otros objetivos instalaran la carga. 468

Cómo funcionó el engaño

El primer contacto utilizaba la conferencia como atajo para generar confianza. El suplantador preguntaba, en un inglés deficiente, si el investigador asistiría a otro evento y luego presentaba una conferencia ficticia vinculada a un conocido medio de noticias sobre criptomonedas. Las respuestas públicas servían para localizar o aproximarse a posibles asistentes; los mensajes directos permitían continuar la conversación en privado. 4510

Cuando la persona mostraba interés, el atacante enviaba un documento que aparentaba ser un archivo de organización del evento. La conversación en X incluía además una supuesta clave de cifrado o descifrado. Así, el intercambio se asemejaba a una coordinación profesional y no a un intento convencional de phishing. 68

La trampa dentro de Google Docs

Un usuario de Google que abría el archivo mientras tenía la sesión iniciada veía una barra lateral personalizada junto al documento. Huntress describió esa interfaz como un panel que hacía parecer que el contenido estaba parcialmente cifrado y pedía introducir la clave proporcionada por el atacante. La clave parecía no funcionar, lo que daba pie a seguir los pasos de recuperación sugeridos en el panel. 68

Entre esas opciones había instrucciones del tipo ClickFix y una vía de descarga. Ambas buscaban convencer al destinatario de descargar y ejecutar código malicioso. Es decir, el documento no era simplemente un enlace hacia una página externa sospechosa: el alojamiento legítimo de Google y una interfaz con apariencia nativa de Docs hacían que todo el proceso pareciera familiar. 48

Esa señal de confianza es la principal lección del caso. Que una dirección empiece por google.com o que un archivo se abra dentro de un servicio conocido solo confirma dónde está alojado el contenido; no demuestra que el documento, el script, las instrucciones o las descargas sean seguros.

Malware asociado a la campaña

Las rutas de distribución variaban según el sistema operativo:

• macOS: el ataque intentaba distribuir Atomic macOS Stealer, conocido como AMOS, un malware especializado en robar información. Los informes también vinculan esta ruta con un enlace fraudulento de Dropbox DocSend y un instalador falso. 2
• Windows: la operación involucraba NetSupport RAT, un producto legítimo de asistencia y escritorio remoto reutilizado como troyano de acceso remoto. 2
• Objetivos relacionados con criptomonedas: los investigadores también identificaron un instalador o implante falso de la billetera Ledger, lo que apunta a un posible interés en credenciales y datos vinculados con criptomonedas. 2

Las pruebas disponibles describen las cargas previstas y los mecanismos de entrega, no una intrusión confirmada en el equipo del investigador que analizó la campaña.

Cómo investigó Huntress el intento de ataque

El investigador de Huntress reconoció que el acercamiento era sospechoso, pero siguió conversando con el atacante y fingió colaborar. De ese modo pudo observar los mensajes, recibir el documento y registrar cómo la falsa solicitud de cifrado conducía hacia la ejecución de malware. El investigador no instaló la carga. 1411

La estrategia permitió reconstruir una cadena de ataque especialmente clara: la identidad falsa en X, el pretexto de la conferencia, el Google Doc, la barra lateral de Apps Script, la clave fraudulenta y las rutas de malware específicas para cada sistema operativo.

Qué deberían revisar los equipos de seguridad

El caso demuestra que los contactos relacionados con conferencias deben examinarse con el mismo cuidado que un correo de phishing, incluso cuando llegan a través de una plataforma social conocida y utilizan un servicio legítimo en la nube.

Algunas señales de alerta son:

• un contacto no solicitado de una cuenta que afirma representar a un organizador, medio de comunicación o patrocinador;
• una petición para pasar de una respuesta pública a los mensajes directos antes de verificar la identidad por un canal independiente;
• un documento que solicita una clave, contraseña o paso de “descifrado” enviada en otra conversación;
• un Google Doc que utiliza una barra lateral personalizada o una ventana interactiva inusual para pedir la descarga de software o la introducción de comandos; y
• una billetera, herramienta de asistencia remota o utilidad para una conferencia ofrecida fuera de los canales oficiales confirmados de manera independiente.

Si alguien siguió las instrucciones, la respuesta más segura es aislar el equipo afectado, restablecer las credenciales potencialmente expuestas, rotar secretos y revisar las billeteras de criptomonedas y otras cuentas sensibles. 1819

Qué está confirmado y qué no

Los informes disponibles respaldan los elementos centrales de la campaña: la suplantación en X, el uso de respuestas públicas y mensajes directos, el pretexto de una conferencia cripto ficticia, un Google Doc ampliado con Apps Script, una supuesta clave de descifrado, instrucciones posteriores de tipo ClickFix y el intento de distribuir malware para macOS y Windows. 1246811

El material consultado no incluye una declaración verificada del presunto atacante ni de Google. Tampoco aporta pruebas suficientes para establecer una comparación específica con campañas anteriores atribuidas a gobiernos u otros grupos concretos. En términos generales, el incidente sigue un patrón conocido: ingeniería social personalizada contra profesionales de la seguridad. Su rasgo más llamativo fue utilizar contenido alojado en Google y una interfaz de Apps Script como parte del flujo para entregar la carga maliciosa.