ida bokbot / iced ida python upx

Bokbot/Iced

my notes on following OALabs tutorial, i'm going to try using IDA

https://www.youtube.com/watch?v=wObF9n2UIAM
https://app.any.run/tasks/5fb451b5-a3d6-451c-9ce1-76897bf53f2d/
0ca2971ffedf0704ac5a2b6584f462ce27bac60f17888557dc8cd414558b479e

because it appears like process injection in hybrid analysis, try these breakpoints
CreateProcessInternalW
WriteProcessMemory
ResumeThread

bp1 [CreateProcessInternalW]
string on stack is this EXEs full path

bp2 [WriteProcessMemory] <-- looking for a PE file in memory that is getting written
on the stack, 1st parameter is handle of process
2nd parameter is the "destination" memory location
3rd parameter is the "source" memory location, or WHAT DATA THEY ARE WRITING
debug041:002C0000, end 0x002E0000, size = 0x20000
starts with MZ so definitely an EXE
hit SHIFT-F2, select python, type in this code
filename = AskFile(1, "*.bin", "Output file name")
address = 0x002C0000
size = 0x20000
dbgr = False
with open(filename, "wb") as out:
  data = GetManyBytes(address, size, use_dbg=dbgr)
  out.write(data)
save the dumped file to your desktop

Open newly saved dump file in PE BEAR
notice sections are named UPX0, UPX1, UPX2

Open in Hex Editor, notice how "code" starts at the Virtual Addres (6000) (null bytes before) instead of the Raw (400)
this means it's mapped, so we need to change it to unmapped
1) change the addresses so Raw = Virtual Address in PE BEAR
2.) change the sizes to match also
3.) SAVE AS "dumped file unmapped.bin" to your desktop

Unfortunately UPX tools likely won't worked now that we changed it from mapped to unmapped addresses

Close IDA, re-open the new "dumped file unmapped.bin" from the desktop

start debugger, breakpoint at entry
look in graph view for a "jmp" statement following by oddness (this is common with UPX)
in this case it was
UPX1:0041E083
jmp near ptr byte_4015C3
and it has a red error message "start endp ; sp-analysis failed"

note: he says that VirtualAlloc, VirtualProtect trick should also work

so its about to jump to UPX0:004015C3, end 0x00406000, size = 0x4A3D
so i'm going to try in IDA hit SHIFT-F2, select python, type in this code
filename = AskFile(1, "*.bin", "Output file name")
address = 0x004015C3
size = 0x4A3D
dbgr = False
with open(filename, "wb") as out:
  data = GetManyBytes(address, size, use_dbg=dbgr)
  out.write(data)
but that doesn't seem to give me anything useful, no strings
If I open in IDA as a "binary file" i can see some code though, stack strings, etc. but not what APIs are called

try opening the "dump file unmapped.bin" in x32dbg, start and wait for initial breakpoint
change to graph view
search for the ugly jump in this case
jmp iceid_dumped_unmapped.4015C3
add byte ptr ds:[eax], al ; eax:BaseThreadInitThunk
add byte ptr ds:[eax], al ; eax:BaseThreadInitThunk
add byte ptr ds:[eax], al ; eax:BaseThreadInitThunk
......
breakpoint it and run to it

the value it points to is the new OEP (Original Entry Point)
0x4015C3
if i go in there, the APIs have been mapped so I can see calls to ExitProcess, GetCommandLineA, etc.

Click Scylla
Change OEP to 4015C3
Click dump to save to desktop
click IAT Autosearch
Click Get Imports
Click "Fix Dump"
Terminate in x32dbg

Open IDA, open the fixed dump

generate psuedocode

hover over integer ASCII , click 'r' and it turns it into characters

there are stack strings

this is unpacked but still more work to do

failed attempt at ursnif in ida

ursnif
https://www.malware-traffic-analysis.net/2020/06/10/index2.html
- SHA256 hash: 0329d89a1160ecf8259c9f3064f7435291c6ea0403b26428f172033c934b4a0e
- File location: C:\Users\[username]\AppData\Local\Temp\93296.exe

1st use CFF Explorer to disable ASLR

set 2 breakpoints
 virtualalloc ret 10
 virtualprotect start

1st breakpoint on VirtualProtect
 top stack = .data:unk_13AF568

2nd breakpoint VirtualAlloc
 EAX = debug045:00230000

3rd breakpoint VirtualAlloc
 EAX = debug046:005D0000

4th breakpoint VirtualAlloc
 EAX = debug047:00860000

5th breakpoint VirtualProtect
 top stack = debug045:002307B8

6th breakpoint VirtualProtect
 top stack = debug045:002304D4

7th breakpoint VirtualProtect (same thing repeats over and over)
 top stack = debug045:00230909

breakpoints VirtualProtect on sub functions already mapped

exception thrown

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

my weak attempt at Trickbot analysis in IDA

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

WinMain
varSomeKeyValue = "random chars"
call subLoadMshtaAndKernel32Dll()
LoadLibrary("mshta")
LoadLibrary("kernel32")
ret1 = call subReturnAddressToNextCall
call subNoNestingCalculatAddress
LoadResource(35893)
ret2 = call ret1(CurrentProcessHandle)
loop [ move data ]
call subNoNestingPrintError
printf("Error %d: %s.\n")
call ret2 (segment that originally was not in "text/code" segment, debug042)
repeated calls [ call subNoNestingDecodeString ] (LoadLibraryA, GetProcAddress, VirtualAlloc, VirtualProtect, ZwFlushInstructionCache)
call GetNativeSystemInfo (check vm/sandbox cores?)
call VirtualAlloc
returned EAX 0x00480000
call ZwFlushInstructionCache (ensures cpu sees the malicious "memory change")
call esi (another segment that originally was not in "text/code" segment)
threw exception invalid instruction (debug044:004AFC40)
Load String Resources
Load Bitmap Resource 138
call subNoNestingLoadResourcesAndRegisterWindow()
call subNoNestingGetWidthHeightScreenCreateWindowSetWindowPosition()
Load Accelerators (keyword shortcuts) , get messages , and dispatch messages

IDA db is clearly an address

db D8h
db 5ah
db 65h
db 0

it's clearly an address

0x00655ad8

press "D" multiple times to convert to the write data type

suddenly it'll change from db to a string for example

dd offeset aString ; "c:\\users\\bla.exe"

IDA Code listed as "db"

Options -> General -> Analysis -> Reanalyze program may work