Recently we ran across a quite an interesting sample, which used an interesting obfuscation technique that was beautiful in its simplicity.

But before we dive in, let us provide some background for it.

One of the easier and most common techniques for automatic unpacking is to hook kernel32!WriteProcessMemory and look for injected binaries or any big blobs. It’s simple to implement and quite effective against most packers used in the wild.

In the case of our sample, after the first stage dropper, which can be unpacked by hooking kernel32!WriteProcessMemory as mentioned above, we are presented with a second stage dropper. It does not do anything particularly fancy or new, just standard things.

• dynamically resolves API, with api names encoded via ZeuS-style string-encoding.
• decrypts (rc4) and unpacks its payload
• injects it into a newly created svchost.exe,

This is a typical runPE scheme. The exception is the injection process.

Windows provides us two APIs to deal with other processes memory, kernel32!WriteProcessMemory and kernel32!ReadProcessMemory. As one can expected, the first is used to write to other process’s memory while the second is used to read it.

In every injection tutorial or paper we are aware of, one always writes to foreign processes, which is reasonable. We either write a huge chunk of memory or we write it section by section, this doesn’t matter – we write at least PAGE_SIZE bytes.

What we have here is the exact opposite, we *read* our payload from the parent process to us.

Of course we have to write a stub shellcode to infected process first but our shellcode is only a couple bytes, and that will go under the radar of almost every automatic unpacker we are aware of.

Here are some hashes if you would like to play with them