Injecting code to system process is common way malware use to avoid being detected by antivirus engine, but now we found a brand new way of such injection. According to the samples we received, they are based on command lines, so we guess this way still remain in demo stage, but we think it may be popular soon. Now let us take a look of this kind of injection.
In this case, the target process image file is lsass.exe.
First step of this kind of injection is to create a new lsass.exe process instead of open an existing process, and then using the ReadProcessMemory to get the entry point of the process to be injected.
Before that step, the malware already decrypted injected codes to 0xB90000, and set this PE image’s entry point to be the same with the lsass.exe (In my test environment, the EP of lsass.exe is 14BD).
And also it will set the first instruction in the entry point to jmp (jump).
After these changes to the image prepared to be injected to the lsass.exe process, the malware will call following steps to move this PE image to the target process using ZwMapViewOfSection.
Now the process of lsass.exe has only a shell, all the memories are covered by another PE image extracted from the malware’s resources with the same entry point as lsass.exe. So when it call ResumeThread to run the lsass.exe, the injected code will run automatically with no need to set a new thread context.
There is also another interesting part worth to mention and it is way how this malware loads DLL libraries. It does some little tricks with the ZwMapViewOfSection function. Before loadlibrary call, following functions were hooked and the malware’s DLL already mapped to the process memory using the api ZwMapViewOfSection.
And we know, the functions hooked will be also called by LoadLibrary. The call flow just like following: LoabLibrary ->ZwQueryAttributesFile ->ZwOpenFile ->ZwCreateSection ->ZwQuerySection ->ZwClose ->ZwMapViewOfSection ->ZwClose
According to the above hook, the malware can load a DLL successfully without file presence on user’s disk. The following screenshot shows the DLL that malware have already loaded, but we can’t find that file on the disk.
We think this is very tricky way to inject code to the system process and load DLL without dropping any DLL file to disk in ring3. After all these actions, neither exe file nor DLL file exists on user’s disk, so it must be harder to find its trail, and the injection is more obscured.
In this case the malware’s payload is not so complicate, it’s just a key logger, but we must pay attention to the way of injection and DLL load.
Frank Zheng
Leave a reply
