1

Here's a problem I've been banging my head against for months: Every night at a specific time (probably not significant, but it's 23:03 CET) the Guest account on my Windows 2008 R2 server gets reenabled by the SYSTEM user.

The server is running Windows 2008 R2 Standard SP1 (64bit). Its primary function is that it runs SQL Server 2012. It's recently had a large number of malware infections (Bitcoins miners mostly, but also attacks using EternalBlue that triggered reboots on the server for unclear purposes, so the scope isn't entirely clear). Through Windows updates, manual cleaning, nailing down firewall settings and running some anti-malware tools I've been able to get these off the system and prevent them from reappearing, but the Guest account problem persists. I'm fairly certain they're related, as previously the malware used to appear at the same time through the same mechanic, and the Guest account seemed to have a part in all of it.

Every night this shows up in the Event Log (under Microsoft-Windows-WMI-Activity/Operational):

ActiveScriptEventConsumer provider started with result code 0x0. HostProcess = wmiprvse.exe; ProcessID = 188; ProviderPath = %SystemRoot%\system32\wbem\scrcons.exe

And a few seconds later (under the Security log):

A user account was enabled.

Subject:
    Security ID:        SYSTEM
    Account Name:       MYSERVERNAME$
    Account Domain:     MYADDOMAINNAME
    Logon ID:       0x3e7

Target Account:
    Security ID:        MYSERVERNAME\Guest
    Account Name:       Guest
    Account Domain:     MYSERVERNAME

What I know:

  • The effective Guest account policy on the server (determined by using rsop.msc), Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Guest account status, is set to Disabled.
  • scrcons.exe then launches cmd.exe, which in turn launches powershell which executes some code (in a file-less manner) the end result of which is the Guest account gets enabled. I've determined this (or at least think I have) by using Process Monitor.
  • How, through various methods, to limit and mitigate the effects of all this.

What I don't know:

  • Why this is happening. I have no idea what is actually triggering WMI to do all this, and that's what I need to find out. There's something malicious left on my server, be it a backdoor or whatever, and I don't know how to find it. This is the part I'm looking for help with (while trying to remain aware that my focus might be completely wrong and I could be barking up the wrong tree).

Obviously, the safest and simplest option would be to just wipe the server and reinstall Windows. Equally obviously, at least to me, the safest option would be to use a more modern version of Windows than 2008 R2. However, this is a production server and the reality of the situation is that these options are unviable in the short term (in the long term, the entire solution the server is part of is to be phased out, but right now it's absolutely business critical). And either way I feel highly uncomfortable not knowing what's hitting me.

I should also mention that my downtime windows for this server are extremely limited, and the average reboot time for the server is obscenely long. Troubleshooting that involves rebooting is not impossible, but highly impractical.

EDIT: With regards to this being labeled a duplicate, I understand on a conceptual level that wiping the server is an advisable option, and I agree, but I still think the question of how to find what the WMI provider server is doing is worth looking at. It has implications beyond this specific server, and probably beyond just forensics.

peterh
  • 4,914
  • 13
  • 29
  • 44
  • 1
    `Obviously, the safest and simplest option would be to just wipe the server and reinstall Windows.` As a matter of fact, that is your **only** solution after a malware infection. You will never be certain that you got rid of everything (and in your case, you can already be certain that parts of what hit you still exists). I understand the "critical" part, but can't you just create the server on new hardware (or VM) in parallel and switch over in a maintenance window? – Sven Aug 29 '17 at 09:47
  • Yes, I can recreate the server on a different machine, and eventually I probably have to. The reluctance stems from the fact that the projected losses for our customers as a result of the expected downtime are prohibitively high. This is a design flaw, I know, but it's the reality I inherited. – Magnus Lagerstedt Aug 29 '17 at 10:57
  • Based on what you've told us, how can you trust that this server is malware/hack/exploit free, which it more than likely isn't, and how can you trust that your company/customer data is safe? You can't. You have a responsibility (probably a legal one) to your customers to do the best/right thing and migrate their data to a new server and to wipe this one and start fresh. – joeqwerty Aug 29 '17 at 11:07
  • Doing forensics on a compromised computer is outside the scope of this site. You might have better luck at [security.se]; as always, you should read [their help center](https://security.stackexchange.com/help/on-topic) first. – Jenny D Aug 29 '17 at 13:20
  • Your chance is higher for a reopen, if you put your explanation in the top. Also it may be useful, if you re-edit the text of your question, according to its focus, what differs from the original question. If your question won't be reopened, then you can simply re-ask on the https://security.stackexchange.com (note, it is a site about software security, not about business sysadms). – peterh Aug 29 '17 at 15:57
  • Just thought I'd update this with the solution, since we actually found it: Turns out there was WMI Event in the ActiveScriptEventConsumer class under the "root\DEFAULT" name space that contained some malicious VBScript code. Probably came in by means of an EternalBlue attack. It could be observed using WMI Explorer, but was most readily found under WMI Database Entries in Autoruns (SysInternals). Thanks everyone for your input, and you are of course correct that the server still needs to be wiped and reinstalled. It's something I intend to get done over the coming weeks. – Magnus Lagerstedt Sep 04 '17 at 07:54

0 Answers0