Below is the initial judgment when checking on a file.
OEP TLS
0 0 - possible corrupt file; needs further checking of file behavior
0 1 - suspicious
1 0 - needs further checking of file behavior
1 1 - suspicious
0 – Do not exist
1 – Exist
These past few days I noticed a few malicious files without OEP, though the presence of a TLS makes it a dead giveaway. Below is a sample case, there are different case scenarios however I will just focus on this one.
In Figure 1 it shows the address of entry point and the image base, adding these two fields will give us the virtual address (VA) of the file's entry point.
[Figure 1 – Shows the file OEP offset is out of range]
Debugging the file I started my way in TLS, see Figure 2. Why? Check this out.
The explanation from that blog entry of Ero Carrera covers it, also with the reference from Ilfak.
[Figure 2 – Start of TLS Callback]
It did not take long when I saw what I am searching for, just after 2 decryption routines.
The TLS code is alreading checking for the PE Header of the file, looking for the entry point offset.
Start of PE Header +0x28 = Address of entry point.
In Figure 3 the malware is currently writing a JMP instruction (0xE9 mnemonic) in the entry point.
Then the precomputed destination address of the JMP instruction, is to be placed in entrypoint + 1.
[Figure 3 – TLS Code used to modify the Entry point Instruction]
The file on disk may not have an entry point however when it is loaded in memory the TLS code decrypts the malware code and allocates the instructions needed to make a jump in the critical instructions.
Utilizing the PE file structure can definitely give an advantage to malware authors and malware researchers, well it depends on how those advantage were used.
Related readings
How Malware Defends Itself Using TLS Callback Functions
No comments:
Post a Comment