Ah, who can forget the BeeGees? I try and try. No, there is a point to the title of this blog entry. If you work with computers (a fairly safe assumption if you read this blog) then you will doubtless be familiar with the casual “You know, my computer has been acting weird. Would you mind having a look at it?”. There is a song by Tom Smith called “Doing tech support for Dad” about it. Guess what I did at the weekend? Sometimes I am lucky and the person has some interesting malware. In this case, it was interesting greyware.
Now, is greyware a class of malware? Back at Microsoft, the lawyer approved phrase was “Potentially unwanted software” because it was often software which had been installed after the user agreed to some Eula that said on page seven that it might just send your details of your web usage to a server somewhere and might show you ads for products of dubious authenticity. The lawyer’s position is that you can’t call it malware if the user agreed to install it.
So, what did we have here? A typical family system running XP Home edition, not too much memory and an older specification with all members of the family being admins on the system. Under the circumstances, the machine was remarkably clean. It was running a free AV product that had picked up that one of the DLLs loaded into every process was dodgy but every time it tried to fix it, it failed.
I spent a good few hours looking at this particular greyware (and for legal reasons, no names will be given here) and it was a resilient little devil. I would like to talk about some of the tactics that it used. However, before I do that, I would like to talk about coding styles in malware.
There are some fairly distinct styles in malware writing. The Script Kiddie and those just up from there typically lash components from different sources together into a crude botch and you can’t tell much about the kiddie. Eastern Europeans black hats are quite workman-like and the code quality is generally pretty good. They have clearly had formal training. They often borrow ideas off other malware writers, possibly those working for the same stable but I suspect that they pinch ideas off rival gangs just as often. They keep up with modern trends or set them. They generally write stealthy code with some excellent use of rootkits. Conversely, they do relatively little to hide their infrastructure and looking at the network activity generally takes you to Russia or the Ukraine in fairly short order. That could well represent a difference between the developers and the money men who coordinate gang activities. I am told that military malware from Eastern Europe follows the same patterns but it is better engineered and doesn’t lead as directly back to Eastern Europe. I have only seen a fairly limited range of military malware from the Middle East but the quality was excellent and the stealth features were even better than the Eastern European code. They clearly worked in teams with subject matter experts writing different bits of the code. A lot of money had been spent on those projects. Chinese malware uses a very different approach. It rarely has much stealth capacity. Instead, it overwhelms by sheer weight of numbers. If two variants of the code are good, then ten are better. If one protection mechanism is good, then five are better. I am told by friends who move in places where true names are rarely given and all the players work for organisations known only by 3 letter acronyms that Chinese espionage works in very much the same way. Ten agents watching are better than two.
Anyway, I digress. This greyware proved to be Chinese and I had guessed as much from the approach. The directory where it lived was visible which made life easy… well, actually, not so much. Any attempt to delete the directory failed with a sharing violation if it was a code component – oh, I may just call any such files “PE files” which stands for Portable Executable. This covers any sort of file that can be loaded as run as native code. So, something was locking the files. A quick search showed a process that was loaded from the directory that the other known files were from so I tried to kill it with task manager but it wouldn’t die. Ok, time for the toolbox to come out. Although Sysinternals is wholly owned by Microsoft, the tools are still free and wonderful. I downloaded them and Process Explorer killed the process just fine. It was offline for less than 5 seconds before it popped up again. A check of the parent process showed it to be an instance of SVCHOST. Right, it was time to look at the services.
There were a couple of services that seemed to be stopped… how could a stopped service be doing this? I downloaded WinDbg and had a look at the service host for that service and clearly it was not stopped. I am going to look into this technique some more when I have time but it is clear that the SCM was sending service control messages which the service claimed to be processing but the status codes that it returned were out and out lies. However, that was not a problem. I could force terminate the containing service. It popped back up again, spawned by another instance of SVCHOST. Ah, ok, I had seen that trick before. Two processes each have a thread that waits on the death of its brother process. If you kill one then the thread unblocks, restarts its brother process and blocks again. The brother does the same. I knew how to deal with that thanks to Mark Russinovich, a very clever and helpful chap who it was my pleasure to meet once or twice. You can suspend all the threads in a process and that doesn’t trigger the brother process – after all, the monitored process is only sleeping, not dead. You suspend the other process and you have two frozen malicious processes. I went into the registry and killed the startup for those services and rebooted.
What the heck? Everything was back as it had been. Some investigation showed that there was a process that “repaired” the installation of the malware on each boot and then terminated. Ok, not a problem. I froze everything and used Autoruns to disable the loading of the process. Reboot – and everything is back as it had been. Resilient little sucker, isn’t it? Some ferreting around showed that this greyware registered as a shell extension and may well have had some shell functionality but the first thing that it tried to do was repair the install. It was at this point that I realised that this was more interesting than average. I started to dig deeper.
COM classes were registered with multiple different class IDs. Whichever you asked for, you got the same VTABLE. Cute. There were multiple self repair mechanisms and hooks into the system which seemed to exist solely to give the greyware a chance to self repair. Nice idea. The one that made me laugh was the protection for non-PE files. Something was waiting on each file in the directory and as the file was deleted, it just copied the file from the complete backup directory that was right there in plain sight. What happened if you tried to kill the backup directory? It was restored from the live copy.
So, the approach was clearly Chinese but the modules were compiled in Visual Studio with US settings. I was able to fish out some function names and other text and the writer clearly had a very good grasp of English. The servers that sourced the ads were in mainland China and some of the reporting went to Taiwan. All in all, this was pretty good work and much more resilient than most. There was no way that an average admin would have been able to remove this software.
In the end, I cleaned the system by booting to a WinPE image and manually cleared out the registry and deleted the directories that contained the greyware. Even the best self defence mechanisms don’t work when they are not loaded.
Had it been a commercial system, it would probably have made more sense to salvage the data and rebuild the box.
Oh, in other news, Arbor Networks say that there have been more and heavier distributed denial of service attacks this year than ever before with a peak intensity 67% above the previous high. The source? That would be Botnets… generally compromised home systems just like the one that I worked on this weekend.
So, until next time…
Mark Long, Digital Looking Glass