Campaña de phishing EvilProxy aprovecha convincentes suplantaciones de aplicaciones empresariales

Resumen ejecutivo

Okta Threat Intelligence ha identificado una campaña de ataque de alto volumen que, según investigaciones posteriores, ha estado activa desde al menos marzo de 2025, aprovechando el kit de herramientas de phishing como servicio (PhaaS) EvilProxy para ejecutar ataques de phishing en tiempo real diseñados para robar credenciales de usuario y cookies de sesión activas. Realizamos un seguimiento de esta campaña como O-UNC-035.

Esta operación tiene como objetivo organizaciones de numerosos sectores, incluidos las finanzas, el gobierno, la salud y la tecnología, utilizando principalmente señuelos muy convincentes que se hacen pasar por herramientas empresariales populares como SAP Concur y servicios de firma de documentos como Adobe o DocuSign.

Análisis de amenazas

EvilProxy Phishing como servicio

EvilProxy (O-TA-041) es un kit de herramientas PhaaS que utiliza una arquitectura de proxy inverso/adversario en el medio (AitM) para interceptar los inicios de sesión y las cookies de sesión de las víctimas en tiempo real, lo que permite a los atacantes evitar la autenticación multifactor (MFA) y secuestrar cuentas.

Observado originalmente en 2022 y rápidamente convertido en producto en las tiendas de la dark web, EvilProxy se ha utilizado ampliamente en la apropiación de cuentas dirigidas y en las campañas de compromiso de correo electrónico empresarial porque sirve de proxy para sitios legítimos. Esto significa que los usuarios ven mensajes reales de MFA y que el atacante puede capturar tokens y cookies para que el atacante los reproduzca. Debido a que EvilProxy se vende y se mantiene como un servicio, escala los ataques y disminuye la barrera de habilidades para los delincuentes: los operadores pueden lanzar grandes volúmenes de campañas de phishing a medida.

Mecanismos de señuelo

Hemos observado la suplantación de software y servicios de Enterprise de confianza para engañar a los usuarios para que hagan clic en enlaces e ingresen credenciales:

• Servicios de firma de documentos (como Docusign, Adobe Acrobat, Adobe Sign, EchoSign): Un tema constante observado en esta campaña fue la suplantación de proveedores de gestión de documentos y firma electrónica. Los atacantes utilizan la promesa de un documento compartido o una solicitud de firma para atraer a las víctimas.
• Plataformas de gastos y adquisiciones (como SAP Concur, Coupa): Este fue el señuelo más frecuente observado en esta campaña. Se dirige a los empleados suplantando sistemas populares de gestión de gastos y viajes, a menudo con indicaciones para aprobar un informe o revisar un gasto. Un señuelo más genérico utiliza términos como gasto, informe de gastos o soluciones de gastos.
• Microsoft SharePoint: La campaña también se dirige a los usuarios del ecosistema de Microsoft 365 fingiendo un enlace a un documento compartido o a un sitio de colaboración.
• Reuniones en línea: Los atacantes registraron dominios genéricos que incluyen palabras como reunión para hacerse pasar por invitaciones a plataformas de reuniones.
• KnowBe4: Los atacantes se hicieron pasar por una empresa de capacitación en concientización sobre seguridad, en un intento de engañar a los usuarios objetivo para que asumieran que el señuelo de phishing era parte de una prueba de phishing oficial.

Análisis de código

La cadena de redirección del señuelo comienza con un enlace corto en el que la dirección de correo electrónico de la víctima está ofuscada dentro de la ruta URL. Luego, el usuario es rebotado a través de un redirector con la marca del nombre de la empresa objetivo en el subdominio y, finalmente, lo lleva a una página de phishing convincente con la marca de Microsoft que roba credenciales. El JavaScript en el redirector extrae el correo electrónico de la ruta, lo vuelve a codificar y crea una URL de redireccionamiento personalizada que lleva esa identidad a través de cada salto.

Ejemplo 1 de cadena HTTP

Enlace inicial:

hxxps[://]expensereport[.]ch/[coded_string]

Redirector:

hxxps[://][empresa][.]sapconcur[.]sa[.]com/expense/?uid=[uid]&hid=[hid]
&document=[document]&token=[token]&t=[t]

URL final (que muestra el sitio web de inicio de sesión para la recopilación de credenciales):

hxxps[://][32_characters_string][.]laurimarierefling[.]com/?uid=[uid]&hid=[hid]
&document=[document]&token=[token]&t=[token]&[string_7_characters]=[string_32_characters]

Ejemplo de cadena HTTP 2

Enlace inicial:

hxxps[://]sapconcursolutions[.]pl/[coded_string]

Redirector:

hxxps[://][empresa][.]sapconcur[.]sa[.]com/expense/?uid=[uid]&hid=[hid]
&document=[document]&token=[token]&t=[t]

URL final (que muestra el sitio web de inicio de sesión para la recopilación de credenciales):

hxxps[://][32_characters_string][.]concurmgt[.]pl//?uid=[uid]&hid=[hid]
&document=[document]&token=[token]&t=[token]&[string_7_characters]=[string_32_characters]

Cómo el redirector decodifica y personaliza a la víctima

Las páginas de phishing aceptan el último segmento de la ruta e intentan usar varios decodificadores en secuencia (mapeo de tokens personalizados, hexadecimal, Base32 y Base64) hasta que el resultado contenga "@". Ese valor se convierte en el correo electrónico de la víctima para su uso de etapa final, como se muestra en este ejemplo de código de página de señuelo inicial:

let encodedValue = window.location.pathname.split('/').pop();
...
correo electrónico = decodeEmail(encodedValue); // mapa de trigramas personalizado
...
if (!decodingSuccessful && isHexadecimal(encodedValue)) correo electrónico = hexToString(encodedValue);
if (!decodingSuccessful && isBase32(encodedValue)) correo electrónico = base32ToString(encodedValue);
if (!decodingSuccessful && isBase64(encodedValue)) correo electrónico = base64ToString(encodedValue);

El decodificador personalizado reemplaza los tokens de tres caracteres nuevamente en caracteres, utilizando un mapa como:

const encodingMap = {
    "@":"MN3",".":"OP4","a":"QR5","e":"ST6","i":"UV7",
    "o":"WX8","u":"YZ9","s":"ABO","n":"CD1","r":"EF2",
    "d":"GH3","I":"JK4"
};

Puertas de anti-análisis

Antes de redirigir, la secuencia de comandos intenta evitar rastreadores y entornos de prueba:

function isBot() {
    const botPatterns = ['bot','spider','crawl','slurp','baidu','yandex',
        'wget','curl','lighthouse','pagespeed','prerender','screaming frog',
        'semrush','ahrefs','duckduckgo'];
if (navigator.webdriver || navigator.complementos.length === 0 ||
    navigator.languages === "" || navigator.languages === undefined)
return true;
...
}

Si se encuentra una señal de bot/sin cabeza, o si aparece la organización "bloqueada" del operador, la página se redirige directamente al inicio de sesión legítimo de Microsoft, lo que brinda a los equipos de triaje una página limpia mientras los usuarios reales continúan con el phishing. El servicio api.ipify.org se utiliza para devolver la dirección IP pública de la víctima, para compararla con una lista de bloqueo de IP/rango.

Dominios en la lista de bloqueo

El código también contiene dos dominios bloqueados, que si se encuentran en la dirección de correo electrónico de la víctima, harán que el flujo de phishing salga en su lugar a la página de inicio de sesión auténtica de Microsoft:

const blockedDomains = ['belfius', 'baringa'];
const emailDomain = correo electrónico.split('@')[1].toLowerCase();

for (const blocked of blockedDomains) { {
        window.location.href = "https://login.microsoftonline.com/common/login";
return;
    }
}

Se desconoce la procedencia del bloqueo de estos dos dominios. El dominio "belfius" parece referirse a un banco belga, mientras que "baringa" parece estar asociado con una consultora de gestión del Reino Unido.

Parámetros de consulta

En todas las muestras observadas, el redireccionador construye la misma URL parametrizada y solo varía la familia del dominio. Dos parámetros son el correo electrónico de la víctima en diferentes contenedores; el resto son valores únicos (nonces) y una marca de tiempo:

• uid → Base64(correo electrónico)
  • Se puede decodificar utilizando una recetade CyberChef
• hid → hex(Base64(correo electrónico))
  • Se puede decodificar utilizando una recetade CyberChef
• documento, token → identificadores aleatorios (tipo nonce)
• t → Timestamp Unix (ms)
  • Se puede convertir a una fecha legible por humanos usando una recetade CyberChef

flujo de autenticación

Dentro del flujo de autenticación, el nombre de la empresa suplantada aparece en ciertos campos tanto del redirector como de la URL final. Además, el marco de phishing completa automáticamente la dirección de correo electrónico de la víctima en el campo de nombre de usuario de la página de phishing.

Enlace inicial:

hxxps[://]expensereport[.]ch/616c6578616e6465722e652e6261754073662e6672622e6f7267

Redireccionador:

hxxps[://]sf[.]sapconcur[.]sa[.]com/expense/?uid=...&hid=...&document=...&token=...&t=...

URL final

hxxps[://]299afcb76fac4238a0facad80c326230[.]concursolutions[.]asia/?uid=...&hid=...
&document=...&token=...&t=...&u9pPUdqL=...

respuesta ante amenazas

Lo que estamos haciendo:

Estamos activamente involucrados en las siguientes actividades para mitigar esta amenaza:

• Supervisión continua de dominios de phishing recién registrados e infraestructura asociada con esta campaña.
• Presentar de forma proactiva informes de abuso a los registradores y proveedores de alojamiento pertinentes para iniciar solicitudes de eliminación de los sitios maliciosos identificados.
• Proporcionar orientación y asistencia a las organizaciones para mejorar la seguridad de sus entornos Okta y ayudarlas a investigar cualquier actividad sospechosa relacionada con cuentas potencialmente comprometidas.

Controles de protección

Recomendaciones para los clientes

• Inscriba a los usuarios en autenticadores sólidos como Okta FastPass, FIDO2 WebAuthn y tarjetas inteligentes, y aplique medidas de resistencia al phishing en las políticas.
• Las políticas de inicio de sesión de la aplicación Okta (anteriormente "políticas de autenticación") también se pueden usar para restringir el acceso a las cuentas de usuario en función de una variedad de requisitos previos configurables por el cliente. Recomendamos que los administradores restrinjan el acceso a las aplicaciones confidenciales a los dispositivos que son administrados por las herramientas de Administración de extremos y protegidos por las herramientas de seguridad de extremos. Para el acceso a aplicaciones menos confidenciales, requiera dispositivos registrados (usando Okta FastPass) que exhiban indicadores de higiene básica.
• Denegar o requerir mayor seguridad para las solicitudes de redes poco utilizadas. Con Okta Network Zones, el acceso puede ser controlado por ubicación, ASN (Número de Sistema Autónomo), IP y Tipo de IP (que puede identificar proxies de anonimización conocidos).
• Las evaluaciones de Okta Behavior y Risk se pueden utilizar para identificar solicitudes de acceso a aplicaciones que se desvían de los patrones de actividad del usuario establecidos previamente. Las políticas se pueden configurar para actualizar a nivel superior o denegar las solicitudes utilizando este contexto.
• Capacite a los usuarios para que identifiquen indicadores de correos electrónicos sospechosos, sitios de phishing y técnicas comunes de ingeniería social utilizadas por los atacantes. Facilite a los usuarios la notificación de posibles problemas mediante la configuración de Notificaciones para el usuario final y elaboración de informes de Actividad Sospechosa.
• Documente, divulgue y cúmplase con un proceso estandarizado para validar la identidad de los usuarios remotos que se ponen en contacto con el personal de soporte de TI, y viceversa.
• Adopte un enfoque de "Privilegios Cero Permanentes" para el acceso administrativo. Asigne a los administradores Roles de administrador personalizados con los permisos mínimos requeridos para las tareas diarias, y requiera autorización dual para el acceso JIT (justo a tiempo) a roles con más privilegios.
• Aplica el Enlace de Sesión IP a todas las aplicaciones administrativas para evitar la reproducción de sesiones administrativas robadas.
• Habilite las Acciones Protegidas para forzar la reautenticación cada vez que un usuario administrativo intente realizar acciones confidenciales.

Observación y respuesta a la infraestructura de phishing:

• Revise los registros de aplicaciones (registros de Okta, proxies web, sistemas de correo electrónico, servidores DNS, firewalls) para cualquier evidencia de comunicación con dichos dominios sospechosos.
• Supervise los dominios regularmente para ver si el contenido cambia.

Si el contenido alojado en el dominio infringe los derechos de autor o las marcas legales, considere proporcionar evidencia y emitir una solicitud de eliminación con el registrador del dominio y/o el proveedor de alojamiento web.