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
.