Post-Exploitation Activities Observed from the Samsung MagicINFO 9 Server Flaw

This week, Huntress observed limited exploitation activity involving the Samsung MagicINFO 9 Server, a content management system used for digital signage displays. As we outlined in our Rapid Response earlier this week, on April 30, a proof-of-concept (PoC) became publicly available for a vulnerability impacting the latest version (21.1050.0) of Samsung MagicINFO 9 Server. Huntress independently verified the PoC against versions 21.1050.0 and 21.1040.2, and has also observed exploitation in the wild impacting the latest version.  

In spite of the fact that there were over 75 different machines that had MagicINFO installed, across our customers, Huntress has currently only seen three separate incidents that involved this vulnerability.  Two of these incidents involved attackers that were organized with identical commands, and the other incident was probably still in “research mode.” The attackers’ commands may be seen in the following gist.

The less organized commands pertained of two separate reconnaissance commands:

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

What was interesting is that the attacker on the first host seemed to run into some difficulty getting their service to run on the first host with the scripted commands. Since the service didn’t start, they tried the attack again. However, the service still didn’t start despite their best efforts. This was confirmed by examining the System event log, and finding an entry that showed the service failed to start after it was installed:

The first attempt at installing the service (Event ID 7045) as illuminated in the event log:

[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]

The second attempt at installing the service:

[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>

The service fails to start, shown by 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> # translates to PHP5.3.8
[snip]

For the second host, there was only one entry that showed that the service was installed, and there was no entry showing that it failed.  There was also proof of execution of the downloaded binaries from EDR data showing the service running.

Figure 1: An overview of the three attacks, in meme form

Another curious thing about the attackers’ commands was the fact that while they pulled an executable that was originally named srvany.exe from their staging website, they appeared to have named it as php-cli.exe on the victim’s machine. They downloaded an executable named php_cli.exe, and renamed it as php-fpm.exe instead. So at first look it would appear as if they had the commands for downloading reversed, just upon looking at these requests, however, it was clear that this was deliberate after examining the commands after they were downloaded.  It’s unclear if this was just a mistake in naming, or some kind of “obfuscation” technique.

It was obvious that the attacks against the first two hosts were related. The commands were identical, and obviously scripted due to quick succession, and also the email address and password for the backdoor were the same. They also occurred within 40 minutes of each other. The third attack occurred quite a bit later the next day. Figure 2 highlights the timelines of the onset of each of these attacks.

Figure 2: Timelines of attacks

As we recommended earlier, it’s best to make sure that any server running MagicINFO is not internet-facing since there currently is not a patch to guard against attacker activity. While it’s not entirely clear why we haven’t seen more of these attacks as of yet, it may just be an artifact that most of our potentially affected customers were already behind firewalls that protected against this easier type of attack.

Indicators of Compromise