Actividades posteriores a la explotación observadas a partir de la falla de Samsung MagicINFO 9 Server

Esta semana, Huntress observó actividad de explotación limitada que involucraba al Samsung MagicINFO 9 Server, un sistema de gestión de contenido usado para pantallas de señalización digital. Como describimos en nuestra Respuesta Rápida a principios de esta semana, el 30 de abril se hizo pública una prueba de concepto (PoC) para una vulnerabilidad que afecta a la versión más reciente (21.1050.0) de Samsung MagicINFO 9 Server. Huntress verificó de forma independiente la PoC contra las versiones 21.1050.0 y 21.1040.2, y también ha observado explotación activa que afecta a la versión más reciente.

A pesar de que había más de 75 equipos distintos con MagicINFO instalado entre nuestros clientes, Huntress solo ha detectado hasta ahora tres incidentes independientes relacionados con esta vulnerabilidad. Dos de estos incidentes involucraron atacantes organizados con comandos idénticos, y el otro incidente probablemente seguía en "modo de investigación". Los comandos de los atacantes pueden verse en el siguiente gist.

Los comandos menos organizados correspondían a dos comandos de reconocimiento distintos:

cmd.exe /c whoami
cmd.exe /c arp -a

Lo interesante es que el atacante en el primer equipo pareció tener dificultades para lograr que su servicio se ejecutara con los comandos de script. Como el servicio no inició, intentaron el ataque de nuevo. Sin embargo, el servicio tampoco inició a pesar de sus esfuerzos. Esto se confirmó al examinar el registro de eventos del sistema, donde se encontró una entrada que mostraba que el servicio no pudo iniciarse después de ser instalado:

El primer intento de instalar el servicio (Event ID 7045) según se observa en el registro de eventos:

[snip]
<EventID Qualifiers="16384">7045</EventID>
[snip]
<TimeCreated SystemTime="2025-05-04 08:06:04.284672"></TimeCreated>
[snip]
<EventData><Data Name="ServiceName">PHP5.3.8</Data>
<Data Name="ImagePath">C:\MagicInfo Premium\tomcat\bin\php-cli.exe</Data>
<Data Name="ServiceType">user mode service</Data>
<Data Name="StartType">auto start</Data>
<Data Name="AccountName">LocalSystem</Data>
[snip]

El segundo intento de instalar el servicio:

[snip]
<EventID Qualifiers="16384">7045</EventID>
[snip]
<TimeCreated SystemTime="2025-05-04 08:14:52.502483"></TimeCreated>
[snip]
<EventData><Data Name="ServiceName">PHP5.3.8</Data>
<Data Name="ImagePath">C:\MagicInfo Premium\tomcat\bin\php-cli.exe</Data>
<Data Name="ServiceType">user mode service</Data>
<Data Name="StartType">auto start</Data>
<Data Name="AccountName">LocalSystem</Data>
</EventData>
</Event>

El servicio no logra iniciarse, como lo muestra Event ID 7000:

[snip]
<EventID Qualifiers="49152">7000</EventID>
[snip]
<TimeCreated SystemTime="2025-05-04 08:14:52.510757"></TimeCreated>
[snip]
<EventData><Data Name="param1">PHP5.3.8</Data>
<Data Name="param2">%%2</Data>
<Binary>UABIAFAANQAuADMALgA4AAAA</Binary> # se traduce como PHP5.3.8
[snip]

En el segundo equipo afectado, solo había una entrada que mostraba que el servicio se había instalado, y no había ninguna entrada que mostrara que había fallado.  También había pruebas de ejecución de los binarios descargados a partir de datos de EDR que mostraban el servicio en ejecución.

Figura 1: Una descripción general de los tres ataques, en forma de meme

Otro detalle curioso sobre los comandos de los atacantes fue que, aunque descargaron un ejecutable originalmente llamado srvany.exe desde su sitio de preparación, parecían haberlo nombrado php-cli.exe en el equipo de la víctima. Descargaron un ejecutable llamado php_cli.exe, y lo renombraron como php-fpm.exe en su lugar. Así que, a primera vista, parecería que tenían los comandos de descarga invertidos, con solo observar estas solicitudes; sin embargo, quedó claro que esto fue deliberado al examinar los comandos después de que se descargaron.  No está claro si esto fue solo un error en la asignación de nombres, o algún tipo de técnica de "ofuscación".

Era evidente que los ataques contra los primeros dos equipos estaban relacionados. Los comandos eran idénticos, y claramente estaban guionizados debido a su rápida sucesión, y además la dirección de correo electrónico y la contraseña de la puerta trasera eran las mismas. Además, ocurrieron con 40 minutos de diferencia entre sí. El tercer ataque ocurrió bastante más tarde, al día siguiente. La Figura 2 destaca las líneas de tiempo del inicio de cada uno de estos ataques.

Figura 2: Líneas de tiempo de los ataques

Como recomendamos anteriormente, lo mejor es asegurarse de que cualquier servidor que ejecute MagicINFO no esté expuesto a internet, ya que actualmente no existe un parche que proteja contra la actividad de los atacantes. Si bien no está del todo claro por qué no hemos visto más de estos ataques hasta ahora, puede que sea simplemente porque la mayoría de nuestros clientes potencialmente afectados ya estaban detrás de firewalls que protegían contra este tipo de ataque más sencillo.

Indicadores de compromiso