Cifras del primer semestre de 2026
El Informe de Amenazas de Gen correspondiente al primer semestre de 2026 revela cifras contundentes: los scams representaron casi el 46% de las detecciones, y el malvertising, otro 30%. Gen bloqueó 114,2 millones de ataques de estafas en tiendas online y 20,3 millones de estafas de soporte técnico en el mismo período. Sin embargo, estas estadísticas no muestran la complejidad de cada ataque, como el paso de un señuelo a la ejecución de scripts o la sustitución de una dirección de billetera antes de firmar una transacción.
Campaña de malware bancario
La campaña bancaria atacó a usuarios en Chequia, Eslovaquia, Polonia y Lituania. Los señuelos parecían correos empresariales normales: avisos de envío, facturas o notificaciones de documentos escaneados. En varios casos, los mensajes se enviaron desde buzones corporativos comprometidos. El correo no simulaba provenir de una empresa legítima: provenía de una cuenta legítima que los atacantes ya habían tomado. Los sistemas de autenticación como SPF y DKIM pueden seguir validando mensajes enviados a través de la infraestructura autorizada, mientras que los sistemas de reputación ven un remitente con historial legítimo.
El adjunto ejecutaba un dropper en JavaScript, seguido de etapas en PowerShell hasta llegar al shellcode y las funciones bancarias, con indicadores que apuntaban a GepyS. El malware modificaba la configuración del proxy e instalaba una extensión del navegador, colocándose cerca de la sesión bancaria de la víctima. La cadena simplificada era: buzón comprometido -> dropper JavaScript -> etapas PowerShell -> cargador de shellcode -> manipulación de proxy y navegador.
Un payload de tercera etapa usaba un cargador independiente de posición de 32 bits. El análisis estático mostró instrucciones basura MMX y SSE, saltos a mitad de instrucciones y una rutina de descifrado basada en un flujo de claves generado por LFSR combinado con XOR. Aunque ninguna técnica era nueva, juntas añadían fricción suficiente para dificultar un análisis estático rápido.
A lo largo de la cadena, el correo solo necesitaba que el usuario abriera el adjunto. JavaScript y PowerShell manejaban el staged, el cargador ralentizaba el análisis, y los cambios en proxy y navegador trasladaban la operación a la sesión bancaria. Campañas comparables en el mismo semestre mostraron patrones regionales y operativos similares: en Italia, PDFs de facturas falsas, incluidos señuelos con temática de Booking.com, llevaban a scripts alojados en Vercel con ofuscación de JavaScript por víctima, etapas de PowerShell en Blogspot y XWorm; en Polonia, el phishing con facturas distribuía un cargador .NET esteganográfico que instalaba Remcos RAT.
Campaña de criptomonedas
La segunda campaña abusaba de una interacción de usuario mucho más pequeña: copiar y pegar una dirección de criptomoneda. El payload final era un secuestrador de portapapeles compilado en Rust. Monitoreaba el contenido copiado en busca de direcciones de billetera en 21 tipos de blockchain, incluyendo BTC, ETH y LTC. Cuando reconocía una dirección compatible, la reemplazaba por una controlada por el atacante.
Desde el punto de vista de la víctima, la transacción podía parecer normal: copiar una dirección, pegarla en una billetera o exchange y aprobar el pago. La blockchain no fue comprometida ni se rompió la criptografía de la billetera. La transacción era válida, pero el destino ya se había cambiado localmente antes de firmar. Las direcciones de billetera son cadenas largas y visualmente ruidosas, difíciles de verificar para los humanos. Muchos usuarios solo revisan los primeros y últimos caracteres, lo que da margen a los atacantes para usar direcciones de reemplazo que sobreviven a una mirada rápida.
El diseño de mando y control añadía otra capa. El malware usaba Binance Smart Chain como parte de su resolución de C2 mediante EtherHiding. No almacenaba el backend completo en la cadena; en su lugar, leía punteros de infraestructura de datos almacenados en un contrato inteligente y los usaba para alcanzar la infraestructura controlada por el atacante. El dominio, URL o IP resuelto podía ser bloqueado, derribado o reemplazado, pero los datos del contrato inteligente seguían siendo legibles públicamente, útiles como pivote de investigación y difíciles de eliminar mediante procedimientos normales de derribo. Una lista simple de IoC de red envejecía rápidamente. La dirección del contrato, el método utilizado para leer sus datos, el valor devuelto y la infraestructura alcanzada después debían pertenecer a la misma investigación.
Recomendaciones de detección
Para la cadena bancaria, la autenticación del remitente debe combinarse con telemetría posterior a la entrega. Un adjunto que lanza JavaScript, PowerShell recuperando etapas adicionales, ejecución de shellcode, cambios de proxy y una nueva extensión del navegador deben correlacionarse como una secuencia única en lugar de tratarse como eventos no relacionados. El historial legítimo del remitente no debe reducir la prioridad de esta actividad cuando el buzón en sí puede estar comprometido. Cuando sea operativamente posible, las organizaciones pueden restringir los intérpretes de scripts para usuarios que no los necesiten, aplicar políticas de control de aplicaciones a los adjuntos descargados y alertar sobre cambios inesperados en proxy o extensiones del navegador. Monitorear la toma de control de buzones sigue siendo parte del mismo problema de detección porque la cuenta comprometida es también la infraestructura de entrega.
Para la campaña de criptomonedas, los defensores pueden monitorear procesos que modifican el portapapeles, coincidencia de patrones de direcciones de billetera y consultas a blockchain desde aplicaciones que no tienen razón para hacerlas. El puntero del contrato inteligente y la infraestructura que resuelve deben rastrearse juntos, en lugar de tratar el dominio C2 actual como el conjunto completo de indicadores. Los usuarios que realizan pagos con criptomonedas deben verificar la dirección completa que muestra el dispositivo de firma o la billetera inmediatamente antes de aprobar. Las libretas de direcciones o listas de permitidos reducen la entrada manual repetida, mientras que los destinos nuevos o modificados merecen una comparación completa en lugar de una verificación solo de los caracteres iniciales y finales.
En ambas campañas, la primera decisión de confianza podía parecer legítima mientras que el flujo de trabajo circundante ya había sido alterado. La detección y la verificación deben cubrir los pasos entre el correo autenticado, el valor copiado y la acción final. El Informe de Amenazas de Gen del primer semestre de 2026 cubre el panorama más amplio de estafas, malware, exposición de identidad, privacidad y ataques impulsados por IA.
Puede leer el informe completo en: Informe de Amenazas H1 2026 de Gen. Patrocinado y escrito por Gen Digital.
Deja una respuesta