.

or by reviewing your answers to refresh your memory of this malware’s capabilities.

Static analysis of Lab16-03.exe shows it to be similar to Lab09-02.exe, with few strings visible other than cmd.exe. When we load Lab16-03.exe into IDA Pro, we see that much of the same functionality is present in this malware. shows the malware using gethostbyname to resolve a domain and using port 9999, as with .

, which resolve a domain name and get a port in network byte order

004015DB         call    ds:gethostbyname ... 0040160D         push    9999                    ; hostshort 00401612         call    ds:htons

Since this malware uses DNS and connects out over port 9999, we set up a dynamic environment using ApateDNS and Netcat. However, when we first run the malware, it doesn’t perform DNS or connect on port 9999. Recall from that the name of the malware needed to be ocl.exe. Let’s see if that is the case here.

Two strings appear to be created on the stack at the start of the malware’s main function: 1qbz2wsx3edc and ocl.exe. We rename the malware to ocl.exe to see if it connects out. It doesn’t, which means the name ocl.exe must be modified before the comparison.

shows the string comparison that checks to see if the launched malware has the correct name.

(in bold).

shows the code that starts with a call/pop combination to get the current EIP into the EAX register.

. This manipulation happens from ❸ through ❹. When the div ecx instruction executes, it causes a divide-by-zero exception to occur because ECX is set to 0 earlier in the code, and this, in turn, causes the malware exception handler to execute at ❷. The next two instructions process the divide-by-zero exception before returning execution to just after the division by zero. Execution will eventually lead to ❺, where the SEH chain is restored by removing the malware’s exception handler.

The malware goes through all of this trouble to execute code that has a drastic time difference inside a debugger versus outside a debugger. As we explained in , exceptions are handled differently when running in a debugger and take a little bit longer to process. That small time delta is enough for the malware to determine if it is executing in a debugger.

(in bold).
differs from the decoding method in . In , we find that the `rdtsc` instruction is used twice, and the familiar SEH manipulation code is in between. The `rdtsc` instructions are shown in (in bold), and we have omitted the SEH manipulation code from the listing.
uses three different anti-debugging techniques to thwart analysis of the malware inside a debugger: `QueryPerformanceCounter`, `GetTickCount`, and `rdtsc`. The easiest way to beat this malware at its own game is to NOP-out the jumps or force them to be taken by changing them from conditional to nonconditional jumps. Once we figure out how to rename the malware (to peo.exe) in a debugger, we can exit the debugger, rename the file, and effectively use basic dynamic analysis techniques.

Назад: Lab 16-2 Solutions

Дальше: Lab 17-1 Solutions