Unfortunatly I didn't make the progress I was expecting today. Here is what I've found out so far.
As I mentioned in my previous post, I managed to debug the child process by changing the two bytes after the DOS signature (once the file had been created with CopyFile).
After the child has been created the parent process sleeps for 0xC8 ms and then closes handles. I don't know much about windows scheduling scheme, but since control will transit for the running process when it sleeps to another process, and since this process may be our child process, I will debug the child process until it unpacks itself and reaches 0x4027A5 (the call to loadDLLsAndInitializeWinINetApplicationHandle) and then I will terminate the parent process "cleanly".
The parent process calls CloseHandle on the handle for the child process, calls CloseHandle again on another handle and finally calls WSACleanup before exiting.
Let's have a look at our child process.
The child process behaviour is the same as the parent process until it reaches "main". Once there, the child process checks if the father is running by calling WaitForSingleObject, and checking if the return value is not WAIT_TIMEOUT.
After the call to unknown_sub1 there is a test eax, eax / jnz. I still don't know exactly what this function does, however, the return value when called from the parent process is 0, and the return value when called from the child process is non-zero, so it is probably being used to check if the running process is the child.
The target of the jump instruction starts by checking if the argc is greater than 2 . Since the command line for the child process is created by the parent, this probably checks if the child was launched correctly.
After this, a function is called which returns in EAX the value of the handle (arg[1]) of the parent process, and this value is used, along with INFINITE to call WaitForSingleObject, so if the parent process is still running, and since INFINITE was passed, WaitForSingleObject will not timeout. The handle is then closed, and the original file (in our case\malware.exe) is deleted.
At 0x00402A9C ChangeRegistry function is called, taking as argument the address of "foobar.exe" where foobar is the random name generated by the parent process.
ChangeRegistry function will create/open a key named "Software\Microsoft\Windows\CurrentVersion\Run" subkey to the 0x80000002 predefined key (HKEY_LOCAL_MACHINE). Afterwards, it will create a value name "Windows LoL Layer" and set it's value to "foobar.exe". The function will proceed to create another registry entry, this time under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices named "Windows LoL Layer" with value "foobar.exe". The last change in the registry will be the creation of a value under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run named "Windows LoL Layer" with value "foobar.exe".
After the child has been created the parent process sleeps for 0xC8 ms and then closes handles. I don't know much about windows scheduling scheme, but since control will transit for the running process when it sleeps to another process, and since this process may be our child process, I will debug the child process until it unpacks itself and reaches 0x4027A5 (the call to loadDLLsAndInitializeWinINetApplicationHandle) and then I will terminate the parent process "cleanly".
The parent process calls CloseHandle on the handle for the child process, calls CloseHandle again on another handle and finally calls WSACleanup before exiting.
Let's have a look at our child process.
The child process behaviour is the same as the parent process until it reaches "main". Once there, the child process checks if the father is running by calling WaitForSingleObject, and checking if the return value is not WAIT_TIMEOUT.
After the call to unknown_sub1 there is a test eax, eax / jnz
The target of the jump instruction starts by checking if the argc is greater than 2 . Since the command line for the child process is created by the parent, this probably checks if the child was launched correctly.
After this, a function is called which returns in EAX the value of the handle (arg[1]) of the parent process, and this value is used, along with INFINITE to call WaitForSingleObject, so if the parent process is still running, and since INFINITE was passed, WaitForSingleObject will not timeout. The handle is then closed, and the original file (in our case
At 0x00402A9C ChangeRegistry function is called, taking as argument the address of "foobar.exe" where foobar is the random name generated by the parent process.
ChangeRegistry function will create/open a key named "Software\Microsoft\Windows\CurrentVersion\Run" subkey to the 0x80000002 predefined key (HKEY_LOCAL_MACHINE). Afterwards, it will create a value name "Windows LoL Layer" and set it's value to "foobar.exe". The function will proceed to create another registry entry, this time under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices named "Windows LoL Layer" with value "foobar.exe". The last change in the registry will be the creation of a value under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run named "Windows LoL Layer" with value "foobar.exe".
No comments:
Post a Comment