REPTILE MALWARE - ANALYSIS

Open Reptile in OllyDBG and we see an error message. Ignore this message and continue.Press and F8 and have a look at the things happening around OllyDBG. Keep an eye on the registers and memory for interesting strings.

After some presses of F8 the executable is terminated and it is nowhere to be found on the system. Hmmm ... this was noted in behavioral analysis when we saw CaptureBat having the executable in its deleted files. Revert back to the previous snapshot before Reptile was run in OllyDbg.


Again step through the executable by pressing F8. This time, notice some interesting strings in the ESI register:
\\.\TRW
\\.\SCIE
\\.\NTICE
\\.\FILEVXD
\\.\FILEMON
\\.\REGVXD
\\.\REGMON

 

 

Your guess is as good as mine, the executable tries to detect if there are any analysis tools present on the system. If it finds one, poof !! the executable is terminated.

On careful observation we can see that after the CALL at 481046 the value of EAX changes to FFFFFFFF. In reality EAX should change to 00000000 if it detects the presence of such tools. The check for analysis tools is broken in this executable. So lets assume that i was working, in that case EAX would have changed to 00000000.

After the CALL we can see there is a TEST EAX, EAX. if the executable find that an analysis tool exists the test will give  non-zero value and we will get an error message like this

There are a number of ways to overcome this

• Edit the data (string)  used for the check. Example: rename Regmon to Reegmoon
• Edit the EAX value after the CALL, make the value zero
• Patch the Jump with a NOP or change JNZ to JE

To speed up the analysis process we would want to start analysis right from the Original Entry Point (OEP). One way in which we can land at the OEP is Section Hop. This can be done through OllyDump Plugin.
Navigate as Plugins > OllyDump > Find OEP be section Hop.

This technique mainly works by detecting when the executable switches from running code in one memory section to another. This is usually indicative of the executable unpacking itself into memory and starting to run the newly unpacked code. But for this executable this method does not seem to work =(

Another method to do the same is the SFX feature of OllyDbg. Navigate as debugging Options > SFX > Trace real entry blockwise. The other option, bytewise is slower but more accurate.

SFX (Self Extracting Executable) when enabled, OllyDbg will use memory breakpoints hoping to catch the executable code that did not exist before. That is to say, it tries to detect execution outside the original code section. For SFX to work we need to be sure that Exceptions are ignored.

When ran with SFX enabled, OllyDbg eventually pauses at 415E96. Executable is partially unpacked.

Take a snapshot at this point so that we can start the analysis from now starting at the OEP right away. As we move forward we come across another defensive mechanism. For this to activate, disable any plugin which is hiding the presence of OllyDbg.

Yes you guessed it right, it is the infamous IsDebuggerPresent mechanism. To get to this we need to go into a number of CALLS.

Go into the CALL at 412502 and we can observe below the IsDebuggerPresent.

Go through a couple of lines and there will be a number of CALLS after which the value in EAX becomes 00000001 indicating that the executable detected the presence of debugger. After this will be a test condition TEST EAX, EAX. We need to change the value in EAX to zero before this test condition. This way we can overcome the IsDebuggerPresent defensive mechanism. Of course there are plugins which handle this mechanism automatically.




Key Learnings
So in this executable we observed a number of defensive mechanisms and the ways to overcome them

• Strings which had names of analysis tools were observed in registers
• One way to overcome this is by changing the string in the register
• IsDebuggerPresent check
• This can be overcome by changing the value in EAX before the condition is tested

FONTE:   malwarecrypt