SOC Prime Bias: Critical

19 Oct 2026 17:09 UTC

UNC7017 apunta a AOMEI Technology en ataque a la cadena de suministro de software

Author Photo
SOC Prime Team linkedin icon Seguir
UNC7017 apunta a AOMEI Technology en ataque a la cadena de suministro de software
shield icon

Detection stack

  • AIDR
  • Alert
  • ETL
  • Query

Resumen

UNC7017 llevó a cabo una sofisticada campaña de la cadena de suministro de software, dirigida a la infraestructura de actualización de AOMEI Technology. El actor de amenaza utilizó ventanas breves de manipulación de configuración para redirigir solicitudes de actualización hacia servidores maliciosos, ayudando a evadir la inspección tradicional en tiempo real. La campaña entregó una cadena de carga útil de múltiples etapas que incluía el descargador CROSSROAD y el backdoor SHINYROAD.

Investigación

La investigación fue realizada conjuntamente por el Grupo de Inteligencia contra Amenazas de Mandiant Google (GTIG) y el Laboratorio de Análisis de Amenazas de ManageEngine (METAL). Los investigadores detectaron la campaña a través de la telemetría de EDR y confirmaron que el adversario dependía de ventanas de manipulación efímeras que duraban solo cinco a diez minutos. El análisis también mostró un cambio de infraestructura de proveedores en la nube a dominios temáticos de proveedores dedicados y almacenamiento en la nube legítimo.

Mitigación

Los proveedores deben aplicar la verificación criptográfica de firmas de extremo a extremo para todos los ejecutables descargados y los archivos de configuración. Las organizaciones deben implementar un riguroso anclaje de destino para los clientes de actualización para evitar la redirección hacia dominios no autorizados. Restringir esquemas URI dentro de los controladores de la aplicación también puede ayudar a prevenir ataques de coacción de credenciales NTLM basados en WebDAV.

Respuesta

Los equipos de seguridad deben llevar a cabo búsquedas retrospectivas en endpoint y red que cubran el periodo de abril a julio de 2026. Priorizar la supervisión de procesos secundarios no firmados lanzados por actualizadores legítimos y signos de redirección de red no autorizada. Los analistas deben inspeccionar archivos de configuración de endpoint en caché localmente en lugar de confiar únicamente en verificaciones en vivo de URLs alojados por proveedores.

Flujo de Ataque

Todavía estamos actualizando esta parte.

Detecciones

Tarea Programada Sospechosa (vía auditoría)

Equipo SOC Prime
19 Oct 2026

Posible Proceso de Ejecución de Powershell en Directorio Sospechoso (vía cmdline)

Equipo SOC Prime
19 Oct 2026

Software de Acceso Remoto/Administración Alternativo (vía process_creation)

Equipo SOC Prime
19 Oct 2026

Intento de Comunicaciones de Dominio de Consulta de IP Posible (vía dns)

Equipo SOC Prime
19 Oct 2026

IOCs (HashSha256) para detectar: Investigando la Manipulación Efímera de la Cadena de Suministro

Reglas AI de SOC Prime
19 Oct 2026

IOCs (SourceIP) para detectar: Investigando la Manipulación Efímera de la Cadena de Suministro

Reglas AI de SOC Prime
19 Oct 2026

IOCs (DestinationIP) para detectar: Investigando la Manipulación Efímera de la Cadena de Suministro

Reglas AI de SOC Prime
19 Oct 2026

Detección de Redirecciones Maliciosas de Actualización de Software de AOMEI [Proxy]

Reglas AI de SOC Prime
19 Oct 2026

Detección de Actividad de Malware CROSSROAD y SHINYROAD [Windows Sysmon]

Reglas AI de SOC Prime
19 Oct 2026

Detección de DLL Maliciosas y Servicio Temporal para la Campaña SHINYROAD [Evento de Archivo de Windows]

Reglas AI de SOC Prime
19 Oct 2026

Ejecución de Simulación

  • Narrativa & Comandos de Ataque: Un adversario ha desplegado con éxito un descargador CROSSROAD en una estación de trabajo a través de una violación de la cadena de suministro (T1195.002). Para evitar que múltiples instancias del backdoor interfieran entre sí o causen inestabilidad en el sistema, el malware intenta crear un Mutex específico. El objetivo del atacante es establecer un backdoor persistente (T1547) para el control y la exfiltración de datos a largo plazo. La simulación ejecutará un script de PowerShell que imita este comportamiento creando las mismas cadenas de mutex globales y locales identificadas en la regla de detección.

  • Script de Prueba de Regresión:

     # Script de Simulación de Mutex CROSSROAD/SHINYROAD
      # Este script simula la creación de los mutex específicos dirigidos por la regla de detección.
    
      Write-Host "[*] Iniciando Simulación de Mutex..." -ForegroundColor Cyan
    
      # 1. Simular Mutex Global (CROSSROAD)
      try {
          $globalMutexName = "GlobalF9E6E3C0-E11A-4F85-9944-AF4AD6E05883"
          Write-Host "[!] Intentando crear Mutex Global: $globalMutexName" -ForegroundColor Yellow
          $globalMutex = New-Object System.Threading.Mutex($true, $globalMutexName)
          Write-Host "[+] Mutex Global creado exitosamente." -ForegroundColor Green
      } catch {
          Write-Error "[X] No se pudo crear Mutex Global: $($_.Exception.Message)"
      }
    
      # 2. Simular Mutex Local (SHINYROAD)
      try {
          $localMutexName = "Local963d3c60-d406-4ad6-aa1e-dc8e45061ccf"
          Write-Host "[!] Intentando crear Mutex Local: $localMutexName" -ForegroundColor Yellow
          $localMutex = New-Object System.Threading.Mutex($true, $localMutexName)
          Write-Host "[+] Mutex Local creado exitosamente." -ForegroundColor Green
      } catch {
          Write-Error "[X] No se pudo crear Mutex Local: $($_.Exception.Message)"
      }
    
      Write-Host "[*] Los mutex se mantendrán por 30 segundos para asegurar captura de telemetría..." -ForegroundColor Cyan
      Start-Sleep -Seconds 30
    
      # Limpieza (La liberación manual se maneja con la salida del script, pero explícito es mejor)
      if ($globalMutex) { $globalMutex.ReleaseMutex() }
      if ($localMutex) { $localMutex.ReleaseMutex() }
    
      Write-Host "[*] Simulación Completa." -ForegroundColor Cyan
  • Comandos de Limpieza:

     # En caso de que el script sea interrumpido, ejecute esto para liberar los mutex
      # Nota: En PowerShell, si el proceso muere, el sistema operativo usualmente limpia el mutex.
      # Esta es una precaución de seguridad para el corredor de simulaciones.
      Write-Host "[*] Ejecutando Limpieza..."
      # No se necesita un comando específico si el proceso termina, pero aseguramos que no queden manejos colgantes.