Update 5/6/2017: Close port 445 and apply MS 17-010
I have triaged a handful of Windows servers this week that started out being ticketed as high CPU / performance issues.
Upon investigation, I have found XMR cryptocurrency miners being installed through a Windows OS Vulnerability.
A Service is created with a random name which points to C:\Windows\[RANDOM][name].exe
A folder is created C:Windowswinsxslog (this is unpacked from C:\Windows\win32hlp.tmp using executable un.exe or unx.exe that are in C:\Windows also) and loaded with XMR cryptocurrency miner configuration files.
Here’s a directory listing of C:\Windows\winsxs\log:
- 1493016295_log.txt
- 1493016395_log.txt
- blake256.cl
- cryptonight.cl
- groestl256.cl
- jh.cl
- LICENSE
- msvcr120.dll
- OpenCL.dll
- SystemIIS.exe
- SystemIISSec.exe
- wolf-aes.cl
- wolf-skein.cl
- xmr1.conf
- xmr12.conf
- xmr16.conf
- xmr2.conf
- xmr20.conf
- xmr28.conf
- xmr32.conf
- xmr4.conf
- xmr40.conf
- xmr64.conf
- xmr8.conf
Curious, I checked out xmr1.conf and here is what the contents provided:
{ Algorithms: [ { name: CryptoNight, devices: [ { index: -1, threads: 1, rawintensity: 16, worksize: 16 } ], pools: [ { url: stratum+tcp://xmr.crypto-pool.fr:3333, user: 48okENqW61sXt3cDFYJEZMdnHDdoUY1ymE2wVDPSFM5Z2B6VJodU4kmL24w4vLcNv8ZqgynmJ3gq86MEbNsPkLHnTYh6zGR, pass: x } ] } ] }
Looking at one of the log files, I also see this which gave me more information for researching and removal.
02:44:55:181 700 02:44:55:182 700 ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» 02:44:55:182 700 º Claymore CryptoNote CPU Miner v3.5 Beta º 02:44:55:184 700 ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ 02:44:55:385 700 64-bit version 02:44:55:386 700 CPU does not support AES-NI - slower mining! 02:44:55:386 700 Logical CPU cores: 2 02:44:55:386 700 Number of threads: Autoselection... 02:44:55:387 700 Using 2 threads 02:44:55:389 700 scfg: 1 02:44:55:403 700 1 pool specified. 02:44:55:403 700 Press m key for tune mode. 02:44:55:412 10d8 Stratum - connecting to 'xmr.crypto-pool.fr' port 80 02:44:55:414 e4c Stratum - connecting to 'xmr.crypto-pool.fr' port 80 02:44:55:501 10d8 Stratum - Connected 02:44:55:501 e4c Stratum - Connected
There are files dropped into C:\Windows also, and I identified them by their date of creation.
Listing of files found in C:\Windows:
- 666.exe, fb675e3648e6b676d8372b64007187fb, 204,775
- csrss.exe, 7a41d4310788a69aa9a089550deb08bd, 1,614,848
- g.exe, 6f9514b7cdc612704737c99ff170080d, 1,877,504
- unx.exe, aaafb1eeee552b0b676a5c6297cfc426, 276,480
- winhlp32.tmp, 17854d337e54b47d3c9bec4374f1279c, 3,032,364
<!-- I DO NOT BELIEVE THIS IS PART OF THE CPU MINER 445 EXPLOIT (NOTE: I do not believe this is related to CPU Miner) On one particular system, I found a strange service named 777 which points to C:Windowssystem32svchost.exe -k 777: Inspecting this service, I found that it dumps 777.dll into C:WindowsSysWOW64 as a hidden file at 105MB. I ran it through VirusTotal (scan result) but only came back with two hits. I have yet to further investigate the contents of what this file does and will update this post when I have more info. On the same system I found 777 service / DLL, I also found another service, Driver Registration, and it pointed to C:WindowsRegistration egdrv.exe. There was also what appears to be a configuration file of sorts with that file, named reg.cnf. reg.cnf file contents:
364048 http://93.174.91.3/classes/s.php Ayabot neutron_star 1200000 1(NOTE: Not certain this is related to CPU Miner either) On this same system, I noticed odd Program Files folders, kugou2010 and shengda. No contents inside. Screenshot below: -->
Firewall Rule Added
As noted in the comments by MaxRebo, and I can confirm, there is a deny tcp 445 rule added to the firewall. As MaxRebo suggests, and I do agree, this may have been created to block any other CPU Miner payloads via SMB Exploits from taking and using this machine.
Prevention
Update 5/6/2017: Block port 445 on public facing interfaces
For infected systems:
The best method I’ve found to keep this from re-spawning is to disable the Windows Service and set permissions on C:\Windows\winsxs\log to Everyone > Deny All
I’m not sure what the payload was, as these were fully patched servers with Symantec.Cloud management software. Scanning some of these executables provided 1 or 2 hits on VirusTotal which is very alarming. Luckily these were only CPU-miners; imagine if there were some real damaging malware being spread?
Update 5/6/2017
Seems this may be an SMB exploit. I found this github repo on a forum while doing some searching: https://github.com/fuzzbunch/fuzzbunch
In short, if you open port 445 and does not apply the update MS 17-010, the DoublePulsar
rattles this port, makes interception of system calls and memory injects malicious code.
We closed 445 port and recommend to apply MS 17-010 our customers.
Update 5/9/2017
I was able to review logs yesterday but they didn’t give many answers. Found a handful of unique IP addresses from a few different countries. I’m still trying to identify where the payload is coming from and how it got loaded (outside of SMB RCE exploit).
I have decided to run ProcMon from Sysinternals and watch C:Windowswinsxslog to see what is still trying to access that folder. As pointed out in the comments, it seems that this is re-spawning and we don’t know exactly from where, so for some closure, identifying the source would be great — otherwise, a rollback pre-April might be needed if the system can’t be trusted.
I’ll update again when I have let ProcMon run for the next 24 hours since this seems to be a timed or triggered event.
Update 5/10/2017
So I spent some time digging with a link I shared in a comment after another GOogle search today.
The backdoor used by the botnet is a WMI RAT downloaded from an Amazon S3 bucket (mytest01234), and is installed using a known MOF file method. Set to run every night at 11PM, the backdoor defines a new WMI provider class, which allows the attacker to execute code as a result of a WMI event and to hide the activity behind the WMI service process.
Source: http://www.securityweek.com/botnet-thousands-servers-mines-crypto-currency
So looking into this further, a search for mytest01234 turns up an article at Guardicore which hints at the following things that come from The Bondnet Army:
Detection
One of the log files would exist:
- %windir%wb2010kb.log – Contains a log of a successful attack
- %windir% empdfvt.log – Contains the log message from running the WMI trojan.
So I checked one of my servers and sure enough, %windir% empdfvt.log exists (but not wb2010kb.log).
Here’s the contents of dfvt.log:
3389---Guest---6.1---2cpu---15Hours---nolog
That is what is sent to the C&C server; part of:
- Computer name
- RDP Port
- Guest username
- OS Version
- Number of active processors
- Uptime measured in hours
- The original infection vector
- Whether the victim is running a chinese version of Windows
- OS language
- CPU architecture (x86/x64)
So I had the log file, but when I checked the WMI per the command on Guardicore, I came up empty handed. I do know that I no longer have instances of this being spawned (probably because of the permissions set on c:\windows\winsxs\log); but the Guardicore article indicates that the presence of the logfiles means the Trojan is active. shrug
I’m missing something because I check my Guest user account that I change password on and disable and it is enabled again. So, I’ll continue the hunt. Meanwhile, the system’s network interface is disabled as it’s not mission critical at this point because I moved necessary services to another server, so I have some time to investigate.