Using PE-SIEVE to unpack malware

Just practicing unpacking malware with this sample

http://dreamofareverseengineer.blogspot.com/2017/03/unpacking-malware-in-minutes.html?m=1

md5:dca9106dc8556f9a15d7e18b4fad5d44

What worked was using x64dbg

Attach a breakpoint on CreateProcessInternalW

if I ran a few lines past this I saw a child process spawned (svchost.exe)

And given the context and strings around this call I saw "NtResumeThread" among others

So I set a breakpoint on NtResumeThread (which appears to be ready to launch code in the child process svchost.exe)

Then open a new 2nd instance of x64dbg

"Attach" to svchost.exe , which really isn't doing much right now

Go to the threads tab and you'll see 2 of them!

1 of them is in the "suspended" state

Click into that suspended state and set a breakpoint on the 1st line of code in there

Then click "run" in svchost.exe just to get it so you're not stuck on any breakpoints anymore

Then return to the original x64dbg and click "detach" to allow it to proceed and start the "svchost.exe" process

In the x64dbg on svchost you should now hit it's breakpoint

Now you're inside the 2nd state of the malware but the malicious code hasn't been unpacked so there are still no good strings yet.

Set a breakpoint on VirtualAlloc's ret 10 statement.

Run, then check strings.  If you see nothing, run again, and check strings.

Proceed until you notice the good strings ... (like URLs, etc.)

Then one easy way to get the executable out of memory is to just run 

pe-sieve64.exe /pid ??? 

it will dump the unpacked executable for you

Generic unpacking malware steps

1.) Open malware in IDA

2.) Find the 'ret' of WinMain and look for closes "call" statements above it

3.) Find a VirtualAlloc, follow the EAX result get passed around until you see it in a "call" statement

4.) Find the address of that "call" statement

5.) Flip over to x32dbg, open the same malware, put a breakpoint on the address of the "call"

6.) Also set a breakpoint on VirtualAlloc (bp VirtualAlloc)

7.) Run until breakpoints, Follow in Dump repeatedly on EAX, looking at previous dumps

8.) Find MZ header that does not match original (use Hex Editor to compare)

9.) Follow in memory map, Dump to File, review in PE Studio to see if unpacked

 

FlawedAmmyy unpacking malware example

 FlawedAmmyy unpacking

https://guidedhacking.com/threads/how-to-unpack-flawedammyy-malware-unpacking-tutorial.16637/

7fb83e646cbabc50bec4b33c8130b5ae

https://app.any.run/tasks/97d8c688-a0ed-4602-af79-2409b6d8cd47/

steps

- open ida

- find bottom of "start" (using graph overview window)

- notice all to "WinMain", take it

- find "ret" near bottom of "WinMain" (using graph overview window)

- look just above & around to find any "call" statements, choose "call" closest to the "ret"

- find return of VirtualAlloc

- follow as it's moved from EAX to a "var_**"

- then moved to a register

- then moved to another "var_**"

- until you find a "call var_**" to near the end of the chain

- switch from graph to text view, find the memory address of the "call" statement (0x0040153F)

- open x32dbg

- right-click in CPU tab, "Go To -> Expression", enter that address "0x0040153F"

- cursor should be at same "call" statement as we had in IDA

- set a breakoint in x32dbg on that "call" statement (F2)

- push the play arrow (twice) and run to the breakpoint

- right-click on the "call" statement, choose "Follow in Dump -> Value" (no MX value yet)

- step into the "call" (F7)

- notice code has lots of Stack Strings (API calls like VirtualAlloc, VirtualProtect, etc.)

- when you see "VirtualAlloc", good time to put a breakpoint on all future calls (command: bp VirtualAlloc)

- scroll down until you find either a "call REGISTER", "jmp REGISTER", or "call/jmp DWORD that was a register"

ex: mov dword ptr ss:[ebp-54],eax

call word ptr ss:[ebp-54]

- set a breakpoint (F2) on the registry call

- then run by hitting play arrow

- If "VirtualAlloc" breakpoint is hit, right-click on EAX and "Follow in Dump"

- Keep going until the "Follow in Dump" shows a value at the bottom starting with "MZ" header

- open Hex Editor

- compare original EXE first chars after "MZ" header with what is in "Follow in Dump"

- if same, then hit play arrow again to keep running

- if different, then you may have the unpacked EXE

notes: It may take a while (unpacking can be slow)

When you hit a breakpoint you're looking at the content of "previous" memory regions

- right click "Follow in Memory Map"

- right click "Dump Memory to File"

- how do you know if you did it right?

drop into PE Studio, look at strings, do you see the actual "Ammyy.Service" or "ammy\svn" strings? 

Themida packing

This sample on Hybrid Analysis

https://www.reverse.it/sample/90f22eada562c8d124211faa33337b5f8e8a43235605b8e8f12dab55f5962d3f?environmentId=100

but if you open it in IDA or x32dbg it's very difficult to analyze, it appears packed in some manner.
When viewing the memory strings in Process Hacker while it's running I saw this

It says Themida, which when I googled is
https://www.oreans.com/themida.php
Software protectors where created to keep an attacker from directly inspecting or modifying a compiled application. A software protector is like a shield that keeps an application encrypted and protected against possible attacks

So the attacker is using this legit packing software to hide his code from us malware analysts.

Of course, I'm new at this so if you have any corrections or tips for me, let me know. Thanks!