Beating up on poor antivirus...

I've been reversing malware a lot lately (surprise) and I finally found something novel in a piece I can share.  Usually all the cool stuff is in non-releasable pieces and clients don't want their malware (even descriptions of its internals) shared with anyone).  To that end, I rarely if ever get a chance to blog about my malware adventures.  While this isn't super advanced, it is worth looking at if you've never seen it before.

So here's the code.

I don't do a lot of work in mainland China (or for companies hit by malware targetted at China) so this one took me for a loop.  After doing some research, I found out that kmon.dll belongs to a company called Rising Antivirus (http://www.rising-global.com/). Now other than the fact that their site looks like it was built on the old GeoCities platform (remember them?), I still didn't know the first thing about them.  Okay, I did know that they offer "Lion-Strong Security" and they are still selling the 2011 version of their antivirus software. Sounds "Lion-Strong" to me...

After a little more research (and lots of Google Translate), I found out that kmon.dll implements hooking routines and is injected into every user process that starts on the system.  Lots of security products do this for intrusion detection/prevention, it isn't just a Chinese thing.  Now that isn't to say I'll be installing Rising on any of my machines anytime soon, just pointing out what the product supposedly does is fairly mainstream.

So this malware has no interest in having an IDS/IPS DLL loaded in its address space (and I can't say that I blame it).  So before the malware does anything truly nasty, it attempts to locate "kmon.dll" as a loaded module.  Per MSDN (http://msdn.microsoft.com/en-us/library/windows/desktop/ms683199%28v=vs.85%29.aspx) GetModuleHandle either returns a module handle or a NULL if the module isn't loaded in the process' address space (e.g. the target isn't running Rising Antivirus).

Once the malware has a handle to the process it attempts to free the library using the FreeLibrary API (http://msdn.microsoft.com/en-us/library/ms683152%28v=vs.85%29.aspx).  The FreeLibrary call is used internally by DLLs as they are unloading so the process can unload their dependencies.  But some DLLs (such as kernel32.dll) are used by many other DLLs and shouldn't usually be unloaded.  To prevent premature unloading, Windows implements a reference counter.  FreeLibrary only frees the library when the reference count reaches zero.  Ordinarily this could be a problem for our malware code as it doesn't check the reference count.

Windows offers a sort of backdoor for unloading modules.  When GetModuleHandle is used to get a handle to the loaded library, the the reference count isn't updated.  By contrast, the normal method for obtaining a module handle is to use the return from LoadLibrary (which does increment the reference count).  MSDN even warns of this behavior as it can normally trigger some nasty bugs.  In fact, it may here too, but I doubt the malware author cares if she crashes the antivirus software.

So is the code broken?  Maybe.  If the reference count on kmon.dll was greater than one, then it's likely that kmon.dll would stay loaded.  Still, this code is neat and it gave me the chance to discover an AV vendor I've never heard of that's been around since at least 2011.