It’s a normal day to us. We receive a new Bamital virus sample report from a customer, and we provide an analysis. Suddenly, something interesting bursts into my eyes:
What’s your thought on this code fragment? At the first glance, this piece of code looks like a non-malicious call to manipulate the Windows Printer SubSystem. But if you’ve analyzed Alureon before, it may look familiar to you. Yes, Alureon also takes advantage of the Windows Print Subsystem to install its payload.
Now let’s recall Alureon’s nasty stuff:
The older Alureon installs its payload by using Windows Print Manager. It drops its malicious payload to the Print Processor directory and then calls a winspool API AddPrintProcessorA() to issue an RPC request to the Printing SubSystem, which is hosted by spoolsv.exe; the spoolsv.exe then loads the Alureon payload from the Print Processor directory:
Since the spoolsv.exe is a trusted system process, it makes Alureon difficult to detect by HIOS/Anti-virus behavior monitoring tools. Today, this nasty AddPrintProcessorA() trick has finally been overcome by lots of anti-virus products. However, Alureon is now employing another Print Subsystem API AddPrintProvidorA() to continue its nasty business:
We often see parallels in the application of ‘new’ techniques by malware authors, seeking to evade detection.
So, a technique pioneered by Alureon is now being used by Bamital – does this mean that can we expect to see more of Alureon’s particular brand of nastiness in other malware families in the wild?
I hope not.
Bamital is a virus family which infects the system files “explorer.exe” and “winlogon.exe”. If you experience slow system response, or find unexpected files such as “hlp.dat” under