1

i am analyzing a piece of malware in which first the address to "KiUserExceptionDispatcher" is obtained(using the Export Name Table, going to Export Ordinal Table and then finally to Export Address Table). Once the address(7773A408) is received, the malware overwrites the first 6 bytes with the following lines :

      (here is the finding part)
                ...
   mov BYTE PTR DS:[EDX], 68             -> EDX contains ntdll.KiUserExceptionDispatcher
   mov DWORD PTR DS:[EDX+1], malware.004035C2
   mov BYTE PTR DS:[EDX+5], 0C3
   ....

So, the hex window at 7773A408 (address of KiUserExceptionDispatcher) changes in the following way:

  7773A408   FC 8B 4C 24 | 04 8B .... (and so on)    <- original

  7773A408   68 C2 35 40 | 00 C3 .....(and so on)    <- after overwriting

So, what happens then is that the malware reaches a "UD2" instruction. I looked it up: it raises an invalid opcode exception. Then the malware jumps to 

 7773A40D   RETN

which then leads me to:

004035C2  DB 8B     <- clear, because 004035C2 starts at 7773A40D (hex window)

and then finally to another place where a whole new function begins. So, my question would be: Is it right to assume that the malware tries to change exception handler by overwriting it with 004035C2 to redirect the excetion flow? Why is the exception handler of UD2 the first 6 bytes of KiUserExceptionDispatcher?

best regards,

Improve this question
2

The malware overwrites the usermode exception dispatcher (KiUserExceptionDispatcher()) with the following:

PUSH malware.004035C2
RETN

The code above is equivalent to JMP malware.004035C2.

Now whenever any usermode exception occurs in the process, the function at malware.004035C2 will be executed instead of (or at least before) the registered SEH functions.

The malware likely uses this "trick" in combination with the UD2 instruction in order to confuse disassemblers, since most disassemblers won't automatically figure out that the UD2 instruction now effectively jumps to malware.004035C2. This type of obfuscation trick is often used to make automated static analysis of code-flow more difficult.

Improve this answer
  • aaah, ok. Now I also understand the values. 68 for PUSH and C3 for RETN...ok. Thanks – user3097712 May 4 '15 at 18:10
  • I wonder if this technique still applied? Any alteration of any system library(even in-memory) would cause AV activation and malicious process would be terminated isn't it? – see ya May 4 '15 at 21:35
  • @seeya - No, that's not how Windows works. – Jason Geffner May 4 '15 at 21:39
  • Maybe I'm wrong to put the AV(could be interpreted as Access Violation) but I meant the Anti-virus proactive detection. In other words, Anti-virus detects hook and terminates the process that initiated it. That's why I've asked if this still used in the wild because if there is no detection for this kind of trick it would be extremely strange. Correct if wrong, but they set the interception of this type of API using ObRegisterCallback. – see ya May 4 '15 at 22:04
  • Detection based solely on this specific hook would likely result in countless false-positives, which is why it's very unlikely for AV software to base a detection on this. And ObRegisterCallback() cannot be used to receive notifications of patches made to memory. – Jason Geffner May 4 '15 at 23:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.