A funny little obfuscation technique --- 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 (I'll be speaking automatic unpacking at secure if you like to hear more) 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, A typical runPE scheme[0]. Except the injection process. Windows provides us two API 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[1] from the parent process to us. Of course we have to write a stub shellcode[2] 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 like to play with it first stage: 229a0dbecfb6fb83874bf0d60a9361d8 8a5873dfa1302fa4de5f2ffdf892be20 a92a3e1a2c46a89bb4f622df8970aa73 second stage: 1b454787dbc91584dfbd259a52085540 4b099b8c16e6186bcdd7b532ccca95f1 [0] http://www.cert.pl/wp-content/uploads/main_r.png [1] http://www.cert.pl/wp-content/uploads/update_l.png [2] http://www.cert.pl/wp-content/uploads/read_b.png