“Bond007.01”, a new botnet used for cryptocurrency mining and DDoS attacks
Infects servers and earning around a thousand dollars a day
This new botnet coming out of China and was discovered by researchers at GuardiCore Labs.
The infected systems (up to 15,000 Windows servers) make up a wide variety of government, corporate, university, city and hospital computers.
Currently the botnet seems focused on using the infected computers to mine a variety of cryptocurrencies such as ZCash, RieCoin and Monero: however, could be weaponized in order to starting DDoS attacks.
The attacker behind Bondnet breaches the victims through a variety of public exploits and installs a Windows Management Interface (WMI) trojan that communicates with a Command and Control (C&C) server. Operating under the name Bond007.01, the attacker can then take full control of the servers to exfiltrate data, hold it for ransom, use the server to stage further attacks and more.
Active since December 2016, Bondent primarily mines Monero. Bond007.01 is financially motivated, earning around a thousand dollars a day.
The primary targets seem to be Windows 2008 and Windows 2012 servers equipped with MySQL: the creators used a wide variety of exploits to infect a targeted system, exploiting known vulnerabilities in JBoss, Oracle web apps, MSSQL, Apache Tomcat and with a brute force on RDP in order to discover week passwords.
Detection and remediation
GuardiCore has published a VBS script useful for detect if your machine is infected and for clean it.
Furthermore, you can performs this steps manually:
Every compromised Windows machine hosts at least one of the following log files:
- \%windir%\wb2010kb.log — Contains a log of a successful attack
- \%windir%\temp\dfvt.log — Contains the log message from running the WMI trojan.
To check whether the backdoor is currently installed, run the following command:
gwmi -Namespace “root/subscription” -Class __EventConsumer | where name -eq “MYASECdr”
If the results include an instance of the ASEventConsumerdr it means the trojan is currently active.
To remove it, run the following commands:
- Remove the Event callbacks:
gwmi -Namespace “root/subscription” -Class __EventFilter | where name -eq “EF” | Remove-WmiObject
gwmi -Namespace “root/subscription” -Class __EventFilter | where name -eq “EFNMdr” | Remove-WmiObject
- Remove the WMI provider instance
gwmi -Namespace “root/subscription” -Class ASEventConsumerdr | Remove-WmiObject
- Remove the class object
$query = “SELECT * FROM meta_class where __class = ‘ASEventConsumerdr’”
Get-WmiObject -Query $query -Namespace “rootsubscription” | where Name -eq “ASEventConsumerdr” | Remove-WmiObject
To locate the miner, check for the existence of a scheduled task with a short name, either “gm”, “ngm” or “cell” that runs a batch script. If detected, remove it along with the miner directory.
You can also filter suspicious tasks with the following two commands
SCHTASKS /Query /V /FO LIST /TN gm
SCHTASKS /Query /V /FO LIST /TN ngm
SCHTASKS /Query /V /FO LIST /TN cell
In some cases the batch script that runs the miner is executed directly by the trojan (without a scheduled task). To kill it, look for one of the miner’s possible process names in the process list.
If prior steps have shown your machine is compromised, inspect the following as well:
- Guest account: If you are not using your Guest account reset its password and disable it. If you are using it, reset your password.
- Unknown local users: Make sure there are no unknown local users, particularly users under the Administrators security group, for example we’ve observed parts of the botnet adding a user named “webadmin”.
- RDP connections: To complete the cleanup, make sure that RDP connections are disabled unless required. To determine whether RDP connections are disabled, check the registry key using the following command:
reg query “HKLMSYSTEMCurrentControlSetControlTerminal Server” /v fDenyChildConnections
If the value is 0, RDP connections are enabled.
For more technical informations and a list of files and network IoCs, please refers to the original article on GuardiCore: