A few weeks ago Fraser wrote about malware that injects code into other processes in order to evade firewalls and hide what’s going on. One particular Trojan, which Sophos detects generically as Mal/DownLdr-N, attempts to inject into iexplore.exe using a rather unorthodox technique. Clever as it is, the new HIPS features of Sophos’ endpoint software have no problem detecting the injection as it happens.
Mal/DownLdr-N arrives as an executable file called regscan.exe and pretends to be a component of Microsoft Windows — a legitimate Microsoft tool called scanreg actually exists, so this is not hard to believe. A quick look at it in a disassembler reveals that it’s not something you’d expect to see from Microsoft; it’s packed with a hacked version of UPX and when unpacked is still highly obfuscated, so it’s not easy for an analyst to see what it does at a glance.
One of the first things we see is a call to CreateProcess specifying iexplore.exe as the program to launch. Nothing too unusual there, and a lot of malware samples do exactly that in order to deliver popups or bypass firewall restrictions. What’s odd in this case, though, is the command line parameters that regscan.exe is passing to Internet Explorer:
This obviously isn’t a parameter that has any meaning to Internet Explorer, so what is it? You could perhaps write off the few non-roman characters at the start as garbage resulting from some bug in the Trojan, but the fairly regular sequence of upper case letters afterwards suggests another explanation: the string is some kind of shellcode. To see if that was in fact the case, I copied the string of characters to a new file and opened it up in a disassembler:
That certainly looks like the kind of self-decoding loop you’d expect to find at the start of some shellcode! So, what’s it for? Decoded, part of it looks like this:
Now it’s clear what the shellcode is doing; it’s there to allow regscan.exe to map its own code and data into the iexplore.exe process. But, even though passing this shellcode as a command-line parameter means it exists somewhere in the iexplore.exe address space, what’s going to cause it to execute? Logging a few more API calls from regscan.exe provides the answer:
A thread is being created in iexplore.exe using whatever is at 0x77e7c938 as the thread function. A quick check of kernel32.dll exports reveals this to be the address of GetCommandLineA. This is how regscan.exe intends to find its shellcode — it will just ask Windows to give it the address of the command line arguments!
Once found, regscan.exe uses CreateRemoteThread again and again to execute the shellcode and have it map pages into the iexplore.exe process. The shellcode generates random strings of characters to identify each mapped page and puts them in a predictable location within the shellcode so that regscan.exe can then use ReadProcessMemory to get them and open a handle to the page itself.
This is all quite a bit of effort to achieve something as common as process injection, and you have to wonder why the authors of Mal/DownLdr-N put in all that extra work. The most likely explanation is that some intrusion detection systems will monitor the use of API functions like VirtualAllocEx and WriteProcessMemory and will set alarm bells ringing if they think something is trying to inject code into another process on the computer. By using the command line in this way, Mal/DownLdr-N avoids the need to use either of these APIs to allocate and write to space within Internet Explorer and the authors probably hope that this will prevent it being detected by runtime protection systems. Does it work? We executed the Trojan on a computer running Sophos Anti-Virus 7 to find out:
These malware authors seem to have wasted their time 😉