On the most recent phishing attacks, PowerShell is usually employed to load and execute position-independant shellcode via a macro-enabled Office document.

So, in order to know what actions are being carried away the truly interesting part here is the shellcode being executed. However, to slow down analysis or lower detection, shellcode is usually encoded, being shikata ga nai the most used encoder (for the samples I have observed at least).

Shikata ga nai

Shikata ga nai is a polymorphic encoder based on a decoder stub. The decoder stub XORs the encoded bytes with an incremental key. Having an incremental key means that for each decrypted byte the XOR key is modified (with an add instruction). For more information about shikata ga nai you may read this blogpost about the matter.

Generic decoding

A (shikata) encoded shellcode will have the following structure

Where the stub will modify the encoded bytes at runtime. So the main idea is to detect modification on the encoded bytes block at runtime (via emulation or sandboxing) and dump those modified bytes.

Using unicorn emulator for decoding

To do this we can hook memory write in Unicorn to detect self-modifying code.

Note: Code is partly based on a public decoder on GitHub which I could no longer find to give proper credit

They are the same with the exception of the first instruction. This is due to shikata ga nai also encoding the last (or last bytes) stub instruction (usually the loop instruction). This intruction needs to be the first one to be decoded for the stub to work properly, so it will make it into the dump as well.