By tradition, we’ll upload the sample to DiE and see what it shows us.
DiE believes that the file is not packed in any way. Although wait a minute, let's switch to the section entropy reading.
Judging by the names of the sections, the file is packed by UPX, but their entropy looks very strange. Why then did DiE not recognize the packer? Well, for example, a UPX signature can be intentionally distorted to confuse disassemblers. One way or another, we have a packed file, so we load into the x64dbg debugger. Let's put a breakpoint on the function
VirtualAlloc, which flickers in our vicinity of the entry point, and launch the trojan.
There are several WinAPI functions that need to be broken by default when unpacking an unknown packer, because the unpacking mechanisms are fairly standard:
- VirtualAlloc – used when allocating memory for payload;
- VirtualProtect – used to set memory access attributes;
- CreateProcessInternalW – when creating a new process, control is ultimately transferred to this function;
- ResumeThread – used to continue execution with injections.
We break down on a function and exit it in our code. As a result, we see the following picture:
008F9552 | FF55 B4 | call dword ptr ss:(ebp-4C) | VirtualAlloc008F9555 | 8945 F0 | mov dword ptr ss:(ebp-10),eax | <---- мы находимся здесь008F9558 | 8365 DC 00 | and dword ptr ss:(ebp-24),0 |008F955C | 8B85 58FFFFFF | mov eax,dword ptr ss:(ebp-A8) |008F9562 | 0FB640 01 | movzx eax,byte ptr ds:(eax+1) |
We look further, we see an interesting piece of code at the end of the function in which we find ourselves:
00569C10 | 8985 5CFFFFFF | mov dword ptr ss:(ebp-A4),eax |00569C16 | 8B85 5CFFFFFF | mov eax,dword ptr ss:(ebp-A4) |00569C1C | 0385 68FFFFFF | add eax,dword ptr ss:(ebp-98) |00569C22 | C9 | leave |00569C23 | FFE0 | jmp eax | Интересный переход!
Do not forget: when working out the function
VirtualAlloc the address of the allocated memory is in
eax. We put a breakpoint on this transition, along the way, go to the dump (the address in
eax) and see what happens in the allocated memory. To do this, we put at the beginning of this memory a single breakpoint for writing, and the debugger stops at the cycle of writing data to memory. This is what the part of the loop looks like:
Continuation is available only to participants
Materials from the latest issues become available separately only two months after publication. To continue reading, you must become a member of the Xakep.ru community.
Join the Xakep.ru Community!
Membership in the community during the specified period will open you access to ALL Hacker materials, increase your personal cumulative discount and allow you to accumulate a professional Xakep Score!
I am already a member of Xakep.ru