We begin by loading the malware into IDA Pro and analyzing DllMain, as shown in .
DllMain first checks the fdwReason argument at ❶. This is an argument passed in to indicate why the DLL entry-point function is being called. The malware checks for DLL_PROCESS_ATTACH, which is called when a process is starting up or when LoadLibrary is used to load the DLL. If this particular DllMain is called during a DLL_PROCESS_ATTACH, the code beginning at ❷ is called. This code gets a handle to msgina.dll in the Windows system directory via the call to LoadLibraryW at ❸.WlxLoggedOnSAS to sub_10001000 and then jumps to the result. The sub_10001000 function uses the hModule handle (to msgina.dll) and the string passed in (in this case, WlxLoggedOnSAS) to use GetProcAddress to resolve a function in msgina.dll. The malware doesn’t call the function; it simply resolves the address of WlxLoggedOnSAS in msgina.dll and jumps to the function, as seen at ❶. By jumping and not calling WlxLoggedOnSAS, this code will not set up a stack frame or push a return address onto the stack. When WlxLoggedOnSAS in msgina.dll is called, it will return execution directly to Winlogon because the return address on the stack is the same as what was on the stack when the code in is called.If we continue analyzing the other exports, we see that most operate like WlxLoggedOnSAS (they are pass-through functions), except for WlxLoggedOutSAS, which contains some extra code. (WlxLoggedOutSAS is called when the user logs out of the system.)
The export begins by resolving WlxLoggedOutSAS within msgina.dll using GetProcAddress and then calling it. The export also contains the code shown in .
sub_10001570, which is called at ❷. shows the logging code contained in sub_10001570.