Prometei botnet and its cryptomining shenanigans

By Bhabesh Raj Rai, Associate Security Analytics Engineer, LogPoint

On Wednesday, July 22, Cisco Talos discovered that the cryptocurrency mining botnet attack Prometei has been quietly active since March. The operators behind Prometei employ a myriad of techniques to spread across the network, like abusing the Server Message Block (SMB) protocol to steal credentials, EternalBlue exploit, PSExec, and WMI. Cisco Talos claims this is the first time anyone has ever documented Prometei’s operations.

Prometei has extensive modular design, and the adversary behind the botnet is actively maintaining all the modules. The adversary has armed Prometei with auxiliary modules like a modified Mimikatz (miwalk.exe), Tor module, and open port scanner. The modules help the botnet increase the ability to compromise systems to participate in its Monero-mining pool.

The Prometei botnet has more than 15 executable modules that are downloaded by the main module from the command-and-control (C2) server over HTTP. The botnet has two main branches, a C++ branch tasked with cryptocurrency mining operations and a .NET branch that focuses on credential theft, SMB abuse, and obfuscation. However, the adversary has designed the botnet in such a way, that the main branches can be operated independently from one another.

The botnet has a modified version of Mimikatz (miwalk.exe) to steal credentials and other passwords and send them to C2 for reuse. The C2 then shares the stolen credentials with other modules attempting to verify their validity on other systems using SMB and RDP protocols. If that doesn’t work, the EternalBlue exploit is used for propagation.

The botnet uses various tactics, techniques, and procedures (TTPs) to accomplish tasks, such as downloading modules from C2, propagating in the network via SMB, and so on. LogPoint can detect TTPs, ranging from tracking the malicious network flow to pinpointing the compromised endpoint.

From the IoCs provided by Talos, we can create a list of hashes, URLs, domains, and more to detect artifacts.

Sysmon is used to check the hashes in process-creation events in Windows endpoints.

norm_id=WindowsSysmon label="Process" label=Create hash_sha256 IN PROMETEI_HASHES

Similarly, firewalls or proxy server logs can be queried for associated URLs and IPs.

(url IN PROMETEI_URL) OR (resource IN PROMETEI_URL)

source_address IN HOMENET destination_address IN PROMETEI_IPS

Either Sysmon or Cisco Umbrella is used to query the DNS logs to check for domain artifacts.

norm_id=WindowsSysmon label=DNS label=Query query IN PROMETEI_DOMAINS

norm_id=CiscoUmbrella event_category=DNS query IN PROMETEI_DOMAINS

For other log sources, we can use the general query.

domain in PROMETEI_DOMAINS

Talos has added and modified multiple rules in their July 23 update, including detection for Prometei botnet network activity.

(norm_id=Snort OR norm_id=SuricataIDS) message="*Prometei*"

Apart from this, there are existing rules available for detecting Monero-mining activity.

(norm_id=Snort OR norm_id=SuricataIDS) message="*CryptoMining*Monero*"

The botnet uses PowerShell to download the modules picked up by Snort/Suricata based upon the default User Agent string of PowerShell.

(norm_id=Snort OR norm_id=SuricataIDS) message="*Powershell*UserAgent*"

The botnet uses the famous EternalBlue(MS17-0101) exploit, also used by WannaCry, as a last resort, and this can be picked up by Snort/Suricata if the EternalBlue rules are activated.

(norm_id=Snort OR norm_id=SuricataIDS) message="*EternalBlue*"

Talos stated the botnet was discovered by investigating telemetry information coming from Cisco AMP. If Cisco AMP is deployed in the enterprise, then its Exploit Prevention feature can readily detect Prometei.

norm_id=CiscoAMP label=Malware label=Detect malware="*Prometei*"

The botnet user PowerShell’s ability to use internal .NET Classes to download modules from C2. Our existing alert can easily detect this for PowerShell.

norm_id=WinServer label="Process" label=Create "process"="*\powershell.exe" command="*Net.WebClient*Download*"

In the future, if the botnet iterations use encoded commands to avoid static detection, then the activity can be detected if PowerShell Script Block Logging is activated.

norm_id=WinServer label="Process" label=Create "process"="*\powershell.exe" command IN ["* -enc *", "* -ec *"]

PowerShell’s Script Block Logging will log the full decoded command line in its Event ID 4104.

norm_id=WinServer event_id=4104 script_block="*Net.WebClient*"

If the PowerShell Script Block logging is activated, but the botnet uses the legacy PowerShell version 2 that does not have an advanced logging feature, then enterprises can check for use of PowerShell version 2. It is not a good sign if enterprises detect that PowerShell version 2 is running and the activity should be investigated under any circumstance.

norm_id=WinServer event_id=400 hostversion="2.0"

All the downloaded modules are placed in C:\Windows folder, which is detected using Sysmon to look at any EXE or DLL drops in folders such as C:\Windows.

norm_id=WindowsSysmon label=File label=Create path="C:\Windows" file IN ["*.exe", "*.dll"]

One of the botnet’s modules is named svchost.exe to make it look like the legitimate Windows Service Host binary but is placed in C:\Windows folder. This rogue process can be detected by looking at the process to create events of Windows Event logs.

norm_id=WinServer label="Process" label=Create "process"="*\svchost.exe" -"process"="C:\Windows\System32\svchost.exe"

There are also other hints in detecting this rogue process, such as looking at its odd command line parameter (/sha1chk), which looks like integrity checking functionality for downloaded modules.

norm_id=WinServer label="Process" label=Create "process"="*\svchost.exe" command="*svchost.exe /sha1chk*"

The botnet also sets up a service UPlugPlay by invoking the native sc.exe via command prompt. This invocation of the service control binary by command prompt is picked by exploring the parent-child relationship of processes, or we can use LogPoint’s existing alert named New Service Creation that alerts on new service creation on endpoints.

The main payload delivered to the compromised host is SearchIndexer.exe, a disguised XMRig v5.5.3 binary. One naive and inflexible option is to directly search for the process name or its hash. The better option might be to query for its command-line parameters.

norm_id=WinServer label="Process" label=Create command="*-o stratum+tcp://*"

We can also query for the Monero wallet address since it is a command-line option for the SearchIndexer.exe payload.

norm_id=WinServer label="Process" label=Create command="*4A1txQ9L8h8NqF4EtGsZDP5vRN3yTVKynbkyP1jvCiDajNLPepPbBdrbaqBu8fCTcFEFdCtgbeSsTf17B1Mhy*"

The botnet communicates with the C2 server over HTTP and is visible. The command and the result of commands are transferred using RC4 encryption with a key generated on the client computer and stored in the registry values HKLM\SOFTWARE\Microsoft\Fax\MachineKeyId and HKLM\SOFTWARE\Microsoft\Fax\Encrypted\MachineKeyId.

norm_id=WindowsSysmon label=Registry label=Key label=Map target_object="*\SOFTWARE\Microsoft\Fax\*MachineKeyId"

The spreader module of the botnet changes the WDigest registry value (a common occurrence for malware) to extract clear-text credentials.

norm_id=WindowsSysmon label=Registry label=Key label=Map target_object="*SecurityProviders\WDigest\UseLogonCredential" detail="0x00000001"

What makes this botnet more dangerous is that it is not just a generic miner, rather it can be operated as a normal Trojan or info-stealing malware. Threat actors behind the botnet are evolving rapidly, thus adding new modules to enhance the functionality of the botnet.

LogPoint has pre-existing alerts to detect the TTPs used by the Prometei botnet, such as for PowerShell, WMI, and Sysmon. System administrators are advised to check up on their logs from March onwards to determine any Prometei botnet activity in their environment.