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
  • 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:

            name: CryptoNight,
                    index: -1,
                    threads: 1,
                    rawintensity: 16,
                    worksize: 16
                    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 º            Claymore CryptoNote CPU Miner  v3.5 Beta            º
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

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.


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:


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:


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.