A funny little obfuscation technique

Date of publication: 09/09/2015, mak

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.

main routine

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.

update_l

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.

read_b

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

first stage:
229a0dbecfb6fb83874bf0d60a9361d8
8a5873dfa1302fa4de5f2ffdf892be20
a92a3e1a2c46a89bb4f622df8970aa73

second stage:
1b454787dbc91584dfbd259a52085540
4b099b8c16e6186bcdd7b532ccca95f1