another failed attempt at trickbot analysis in IDA

2nd attempt at trickbot analysis

Trickbot
https://app.any.run/tasks/229b1b03-c04b-4826-a9f4-1a0c60f87d9a/
md5 09CF5ED5EDF9532A802526B663277739
6/26/2020

Breakpoints at
 VirtualAlloc ret 10
 VirtualProtect start

1st breakpoint at VirtualAlloc
 EAX = debug043:00290000

2nd breakspoint at VirtualProtect
 top stack = debug043:00291000
  has something in it ... but does not start with MZ

3rd breakpoint at VirtualAlloc
 EAX = debug045:00200000

4th breakpoint at VirtualAlloc
 EAX = 10000000 (i missed what this was?)

 BUT previous EAX (debug045:00200000) now has MZ header!!!

so lets try to dump debug045
 start = 00200000
 end   = 00203000
 size  = 00003000

 so hit SHIFT-F2, choose python, type

filename = AskFile(1, "*.bin", "Output file name")
address = 0x00200000
size = 0x3000
dbgr = False
with open(filename, "wb") as out:
  data = GetManyBytes(address, size, use_dbg=dbgr)
  out.write(data)

 Open with PE Bear
  does not look right, no Imports or Exports, only 1 section (.text)
  seems like invalid dos header text "!This is a 64-bit PE executable"

5th breakpoint is at VirtualAlloc
 EAX = debug047:10001000
 No new MZ headers, just some random looking data in the monitored sections

6th breakpoint is at VirtualAlloc
 EAX = debug049:002D0000
 No new MZ headers, just some random looking data in the monitored sections

7th breakpoint is at VirtualAlloc
 EAX = debug050:002E0000
 No new MZ headers, just some random looking data in the monitored sections

8th breakpoint is at VirtualAlloc
 EAX = debug051:01D30000

then process in IDA terminated

My Notes on using IDA to unpack Redaman following the OALabs / Live Overflow blog step by step

My Notes on using IDA to unpack Redaman following the OALabs / Live Overflow blog step by step

https://www.malware-traffic-analysis.net/2018/10/02/index.html
https://www.virustotal.com/gui/file/ceb8efb3a3eb1085c61bba4b0a77d1aca1f7b10511497e1521135f18bf67647c/detection
df725667733410f1a023a76d36fcbd31
https://www.youtube.com/watch?v=YXnNO3TipvM

redaman

add breakpoint to "ret 10" of virtualalloc
 must find it, click through jumps to get to kernelbase and find return statement

add breakpoint to "1st line" in virtualprotect
 to see the parameters coming in

breakpoint on virtualalloc "ret 10"
 look at EAX register, that is memory just allocated
debug044:00320000 , so in "Hex View-1" synchronize with EAX ... then "unsynchronize" to ensure it stays viewing, hit F9 to continue
at next breakpoint, go to view -> open subviews -> segments ... should take you to our debug044, see how it's X (execute) & W (write)
    this appears to be the "Loader Stub", a small piece of code that will unpack the malware and setup the real payload

2nd breakpoint on virtuallloc "ret 10" hit
 look at EAX, debug047:00350000, sync w/ "Hex View-2" then unsynch

3rd breakpoint on virtualprotect
 NOTICE our "Hex View-2" now has MZ header, it's an executable at debug047:00350000 !!!
 view in view -> open subviews -> segments
start 0x00350000 , end 0x0037B000 ... so size = 0x2B000 or 176128 (per hex calculator https://www.calculator.net/hex-calculator.html?number1=0037B000&c2op=-&number2=00350000&calctype=op&x=83&y=15)

To export/save the EXE that is in memory to your c drive, Hit SHIFT-F2 to execute script
 select Python, type in
filename = AskFile(1, "*.bin", "Output file name")
address = 0x009DD5B8
size = 0x37a0
dbgr = False
with open(filename, "wb") as out:
data = GetManyBytes(address, size, use_dbg=dbgr)
out.write(data)

open dumped file in "PE BEAR"
review sections (make sure it had text, data, looks normal)
review imports (make sure it has some, like kernel32 and a few)
question???
mapped (ready to execute, sections start at virtual address)  <== yes we want this
or
unmapped (format on disk, sections start at raw address)

finishing the 3rd breakpoint (VirtualProtect)
 notice the top parameter on the stack (esp) is 0x00400000
  that is the address of our main executable (redaman.exe) that we loaded into IDA
   when you see this it's possible they are doing a "PE Overwrite" to overwrite the existing PE in memory

terminate process in ida
open newly dumped file instead
notice the analysis bar has "small blue" code section, and "giant yellow" section which appears to be packed data

click in ida on the beginning of the "giant yellow" packed section
look for xrefs / data links ... and go to code where it's used ... might get lucky and find where it's being unpacked

in our case i picked unk_403000, click 'x' for xref, it took me to a lea eax, unk_403000 statement
 below that statement is a loop with xor and rol (rotate left) which may indicate unpacking
  parameters to the loop may be
   "key"
   "size"
   "link to blob of encoded text"
 below loop is static strings, loadlibrary and getprocaddress calls
  one string is rtldecompressbuffer (like unzip in windows)
 followed by GetTempFileName and CreateFile and WriteFile
  that written file is a DLL likely (written to disk so AV could detect it), they use LoadLibrary to open it
  they call an export function called "DllGetClassObject" with arguments "host 000000000"

set breakpoint on that final LoadLibrary
 EAX has address to temp file
  click into it, hold SHIFT and select the entire string, hit ALT-A to change it to a unicode string
    c:\users\xxx\appdata\local\temp\967B.tmp
  (notice it's hidden in windows explorer, but if you use HxD hex editor and open the file it shows up as an MZ)
  or else in cmd.exe use "attrib c:\users\xxx\appdata\local\temp\*.tmp" to see the file also

open newest dumped file (From .tmp) in PE BEAR
 i see exports so its a DLL, I see the "DllGetClassObject" which is the one the malware called

viewing virtualalloc contents

run malware with x64dbg
set breakpoint on Virtualalloc

BPX VirtualAlloc

once hit the break point
look in the call stack for last user code
go there, set breakpoint on next line after virtualalloc user call

Once hit breakspoint, look at EAX value (it will be the newly allocated address)
Follow EAX's value in the dump

Then F8 (step over) 1 line at a time until you see data in the dump

It could be data (like IP addresses) or it could be a full executable (MZ header)

If it's an executable (MZ Header) then right-click, "follow in memory map"
Then right-click in memory map in the address and select "dump memory to file"

open the new dumped EXE in PE Bear
If the text segment is all 0s
Then go to the Section Hdrs tab and change all Raw Addr columns to match Virtual Addr

Then go to Optional Hrd tab and change Image Base column to the address found on Memory Map screen in x64dbg

then open in pestudio and the EXE should look normal now, unpacked!  with urls, ips, iocs, etc.

msvbvm60.DllFunctionCall with kernel32.VirtualAlloc windows api

So I was reviewing an executable in x32dbg and came across this call

Now I'm just learning, so I can't claim to fully understand this, but here is my interpretation.  I think it's possible that all the lines using the floating point registers (xmm , mm, etc.) are just obfuscation and an attempt by the attacker to distract the security analyst.  I think the relevant information are the pushes and the call statement at the end. Now when we get to that call, here is what is in the registers and on the stack.

What this looks like to me is an attempt for a VB6 program to utilize the DllFunctionCall windows api to execute the kernel32.VirtualAlloc windows api, which is used typically by attackers to allocate more memory in the current process in order to inject their malicious code inside.

Deobfuscating a Windows API Call to VirtualAlloc

Looking at a jpg that  @pollo290987 posted on twitter
hxxp://5.196.121[.]163/connection.jpg

https://twitter.com/pollo290987/status/950736382485499904

Remember that extensions can lie.  This connection.jpg is clearly an executable once you load it into PEStudio or even just a text editor and see it starting with MZ.

I opened in x32dbg, identified a windows API call to GetProcAddress coming up in this executable.

mov byte ptr ds:[429268],56
mov byte ptr ds:[42926D],61
mov word ptr ds:[42926A],7472
lea eax,dword ptr ds:[<&GetProcAddress>]
call dword ptr ds:[eax]

So I stepped through it. Initially strings showed you that there was an obfuscated string, that perhaps could be deciphered as VirtualAlloc

Let's see how the assembly code converts it to the readable/usable string VirtualAlloc
It's done in 3 simple move statements
    mov byte ptr ds:[429268],56
    mov byte ptr ds:[42926D],61
    mov word ptr ds:[42926A],7472

If you were to go to ASCII table ( http://www.asciitable.com/ )

you'd see that 

56 = 'V'

61 = 'a'

74 = 't'

72 = 'r'

That original obfuscated string was "liiiu_lAlloc" located on the data segment (ds:) at 00429268

See how it replaces the 'l' with a 'V'

Now we have "Viiiu_lAlloc" 

Then it replaces the '_' with an 'a'

Now we have "ViiiualAlloc" 

Then it replaces the 'ii' with an 'rt'  (remember little endian will make the hex chars show backwards)

Now we have "VirtualAlloc" 

Then it makes the call to the GetProcAddress to find the VirtualAlloc method inside kernel32

    lea eax,dword ptr ds:[<&GetProcAddress>]
    call dword ptr ds:[eax]