Huntress researchers Harlan Carvey and Lindsey O'Donnell-Welch published the intrusion analysis on September 24, 2026. The endpoint sequence below comes from their account alone, and no other outlet has independently reported it. The vulnerability's severity, affected versions and history of active exploitation are well documented by Samsung, CISA and others.
Samsung MagicINFO's CVE-2025-4632 Gave the Attacker SYSTEM-Level File Writes
MagicINFO is Samsung's platform for managing digital signage content. Its server component, MagicINFO 9 Server, is a Java web application running on an embedded Apache Tomcat server. On Windows, that shows up as the tomcat9.exe service process. A web-facing Java service that runs with high privileges is a valuable target, and MagicINFO has been attacked repeatedly.
CVE-2025-4632 is a path traversal bug. The server does not properly restrict file paths to their intended directory, so an attacker can write files wherever they choose. Samsung's security bulletin describes it as a flaw that "allows attackers to write arbitrary file as system authority." Samsung patched it by changing the server's input-verification logic. The NVD record rates it 9.8 (Critical) under CVSS 3.1, with a network attack vector, low complexity, and no privileges or user interaction required. Public proof-of-concept code uses the flaw to upload arbitrary files, including JSP web shells, to the web root, giving unauthenticated remote code execution.
The affected range is clear. Korea's internet security agency KISA lists MagicINFO 9 Server before 21.1052 as vulnerable and 21.1052 or later as fixed. Samsung put the fix in its May 2025 security bulletin. CISA added CVE-2025-4632 to its Known Exploited Vulnerabilities catalog on 2025-05-22, with a federal remediation due date of 2025-06-12.
The CVE also has a history. A proof of concept was first thought to exploit an earlier MagicINFO flaw, CVE-2024-7399, but testing showed it still worked on systems patched against that bug. Samsung's bulletin gives the two CVEs nearly identical descriptions, and Huntress says CVE-2025-4632 came after the earlier flaw's fix turned out to be incomplete. The Hacker News reported that CVE-2025-4632 was exploited soon after SSD Disclosure released its proof of concept on April 30, 2025, in some cases to deploy the Mirai botnet. The cryptominer case is therefore another use of a flaw that has been attacked in the wild since spring 2025.
There is one scope gap. Huntress says the activity came from a MagicINFO Premium installation, while the CVE record names MagicINFO 9 Server. The report also says the activity was "reportedly associated" with CVE-2025-4632. Huntress does not present exploit artifacts proving that exact vector, so the link is best read as Huntress's assessment.
tomcat9.exe Process Ancestry Linked the Intrusion to MagicINFO
The key forensic clue was process lineage. When Huntress's EDR flagged the AnyDesk download, the command's grandparent process was tomcat9.exe. That showed the command had run through the Apache Tomcat service that MagicINFO uses. When the attacker later set the AnyDesk password, the parent process was again tomcat9.exe, which pointed analysts back to the MagicINFO vulnerability.
This is the most useful detection pattern in the report. A signage server's Tomcat process has no normal reason to launch cmd.exe, certutil.exe or PowerShell download commands. On any host running MagicINFO, a shell or download tool with tomcat9.exe in its ancestry deserves investigation. Huntress used that relationship to attribute the activity.
The timeline shows that fixing symptoms is not enough. Huntress says the customer was told how to remediate after the first incident report. Eight days later, the same endpoint was flagged again for different post-compromise activity, tied to the same access vector. The report does not give exact calendar dates for either alert. It does show that the attacker's way in was still open more than a week after the first warning.
Microsoft Defender Blocked Two AnyDesk Downloads Before the Third Succeeded
The first detections Huntress describes were attempts to download AnyDesk, a legitimate remote monitoring and management (RMM) tool, from 194.87.89[.]30 on port 8899. The attacker needed three tries.
- The first attempt used
certutil.exewith the-urlcache -split -fswitches to fetch the file intoC:\ProgramData\AnyDesk.exe. Microsoft Defender quickly removed it. - The second attempt used PowerShell's
Invoke-WebRequestto download the same file to the same location. Defender detected and remediated it again. - The third attempt succeeded. Huntress's report does not describe the exact method, but the EDR detection shows
tomcat9.exeas the grandparent process.
Defender stopped the two well-known download methods, but the attacker kept going, and each retry was another chance for defenders to notice. Huntress's advice is to treat repeated remote-access tool downloads as a sign of compromise. A single blocked certutil event can look like an isolated alert. Several blocked attempts to fetch the same RMM tool, all running under a web service, point to an attacker trying to get in.
After installing AnyDesk, the attacker set its access password. Immediately afterwards, they created a new local account called oldadministrator with the same password. Huntress lists it as a newly created local admin account. The attacker now had two ways back in: AnyDesk and a local administrator account. Neither depended on the MagicINFO flaw staying unpatched.
Next, the attacker disabled Microsoft Defender using SystemSettingsAdminFlows.exe, a Windows component tied to the Settings app's administrative actions. Huntress does not say which Defender protection, policy or setting was changed, or whether Tamper Protection was on. This detail matters for Windows administrators. If an intruder with administrative access can switch off Defender through a normal Windows binary, EDR monitoring of Defender state changes is an important backstop.
The SilentXMRMiner Builder Compiled the Payload on the Victim Endpoint
The most unusual step came after Defender was off. EDR telemetry showed Silent XMR Miner Builder.exe running from the new oldadministrator user's Documents folder. Huntress says the tool is a Windows builder for Monero (XMR) miners and is "commonly associated with" the open-source SilentXMRMiner project on GitHub. It stops short of confirming where this copy came from.
Most intrusions that end in cryptomining drop a finished miner binary. This attacker built one on the victim's machine. Huntress saw the builder start multiple instances of the .NET Framework utilities csc.exe (the C# compiler) and cvtres.exe (the resource-to-object converter). Several C toolchain processes followed: tcc.exe, the Tiny C Compiler, plus cc1.exe and gcc.exe from the MinGW64 toolset. It also ran donut.exe, which Huntress quotes as generating position-independent code for in-memory execution of VBScript, JScript, EXE and DLL files and .NET assemblies. All of these ran as child processes of the builder.
Huntress suggests local compilation could help an attacker tailor the payload to the target, for example by optimizing for the endpoint's CPU architecture. That is Huntress's view of a possible benefit. The attacker's actual motive is not established.
The cost of the approach is clear. Huntress says the compiler activity produced "a significant spike in activity," especially from an unsigned parent process. Despite the tool's "Silent" name, the build was one of the noisiest parts of the intrusion. For defenders, this is a detection opportunity that comes before the final payload runs. An unsigned executable in a user's Documents folder launching csc.exe, gcc.exe and tcc.exe in bursts is very unusual on a signage server or most business endpoints.
The compiled miner was a file named x.exe. Huntress published its SHA-256 hash, listed in the indicators table below.
A Monero Miner Hidden Behind explorer.exe Left a Clear Command-Line Signature
The finished miner connected to auto.c3pool.org:19999, an endpoint of the public C3Pool mining pool. It mined Monero using the host's CPU and possibly its GPU. It ran under explorer.exe, so a quick look at running processes would have shown what looked like Windows Explorer.
The command line gave it away. Huntress recorded C:\Windows\explorer.exe running with miner options such as --algo="rx/0" (the RandomX algorithm Monero uses), --randomx-mode=auto, --cpu-memory-pool=1, CUDA tuning hints such as --cuda-bfactor-hint=12, --cpu-max-threads-hint=100, and the pool URL. Huntress redacted the wallet username. As Huntress notes, legitimate Explorer never takes mining arguments. It says this suggests an injected malicious process and can serve as a detection rule.
Mining arguments on a signed Windows binary are a stronger signal than any single file hash, because the hash changes whenever the payload is rebuilt. That is exactly what local compilation allows. The exact flags and pool are specific to this incident, but the pattern of a system process carrying miner-style command-line options applies more widely.
Huntress also argues that the miner itself is not the main threat, although it does use endpoint resources. The real problem is how it got there. An attacker who could write files as SYSTEM, install remote access, create an admin account and disable Defender could have deployed something far worse than a Monero miner.
| Indicator | Type | Context |
|---|---|---|
194.87.89[.]30 (port 8899) | IP address | Download source for AnyDesk |
oldadministrator | Local account | Newly created local admin account |
F@x2020!@# | Password | Reused for AnyDesk and the new account, per Huntress's IOC list |
x.exe | File name | Compiled cryptominer |
0d202e16408770e8b6cceb14e1e3e72946b154bf881d27fe33d0060315b30dd1 | SHA-256 | Hash of x.exe |
auto.c3pool.org:19999 | Mining pool endpoint | Monero mining destination |
The IP address is defanged here. Re-fang it only inside a controlled threat-intelligence platform or SIEM. Treat the password strictly as a detection indicator.
What MagicINFO Administrators Should Check This Week
The first job is to find out which MagicINFO 9 Server version each installation runs. Anything below 21.1052 is exposed to a flaw that has been on CISA's KEV list since May 2025. CISA's required action is to apply mitigations per vendor instructions, or stop using the product if mitigations are unavailable. Samsung's bulletins since then also list many more MagicINFO 9 Server fixes, including July 2025 path traversal and authentication bypass flaws and November and December 2025 issues covering unauthenticated file upload, hardcoded database credentials and local privilege escalation. That makes 21.1052 a minimum, not a target. Update to Samsung's current supported release.
The upgrade path may need extra work. The Hacker News quoted researchers who warned that machines on versions v8 through v9 21.1050.0 remain affected, and that upgrading from MagicINFO v8 to 21.1052.0 requires first upgrading to 21.1050.0 before applying the final patch. Plan for that two-step path on older deployments.
Exposure raises the urgency. Censys counted 1,101 exposed Samsung MagicInfo servers online in its advisory, though it cautioned that not all were necessarily vulnerable because version data was not always available. A MagicINFO server reachable from the internet and not updated since spring 2025 should be treated as possibly compromised, not just unpatched.
Patching alone would not have removed this attacker. Once AnyDesk and the oldadministrator account were in place, the attacker no longer needed the MagicINFO flaw. The recurrence eight days after the first report shows why remediation has to cover persistence as well as the entry point.
- Confirm every MagicINFO 9 Server installation is at 21.1052 or later, and preferably on Samsung's latest supported release. Older v8 systems may need an intermediate upgrade to 21.1050.0 first.
- Search EDR telemetry for
cmd.exe,certutil.exeor PowerShell processes whose ancestry includes MagicINFO'stomcat9.exe, since that lineage is how Huntress tied this intrusion to the application. - Audit MagicINFO hosts for unauthorized AnyDesk or other RMM installs and for unexpected local accounts such as
oldadministrator, and remove any you find along with any credentials they reuse. - Alert on Microsoft Defender being disabled, including through
SystemSettingsAdminFlows.exe, and treat an unexplained change as an active intrusion. - Hunt for bursts of
csc.exe,cvtres.exe,gcc.exe,cc1.exe,tcc.exeordonut.exespawned by an unsigned parent, and forexplorer.execommand lines containing mining options like--algo="rx/0". - Block or alert on connections to
auto.c3pool.organd the listed download IP, but do not rely on thex.exehash, because a locally compiled miner can change with every build.
Huntress's case is a reminder that signage servers are Windows servers too. They run a privileged Java service that has been exploited since April 2025, and a missed patch gave this attacker SYSTEM-level access. The payload was only a cryptominer, and building it on the endpoint made it easy to spot. The access that made it possible could just as easily have delivered something worse. With Samsung patching MagicINFO 9 Server as recently as its December 2025 bulletin, organizations running the platform should expect more of these incidents unless they bring every installation up to Samsung's current release and remove whatever persistence attackers left behind.