GINA Interceptor(Lab 11-01)

It is a Lab from Chapter 11(Malware Behavior) for practice from the book “Practical Malware Analysis” written by Michael Sikorski and Andrew Honig.

This lab shows a new technique, i.e. GINA Interception.

The GINA (Graphical Identification and Authentication) system was used in earlier versions of Windows, such as Windows XP and Windows Server 2003. The GINA system was replaced by the Credential Provider architecture in newer versions of Windows, such as Windows Vista and later. Since GINA is not present in newer versions of Windows, malware designed to intercept GINA cannot function on those systems.

Tools Used:

• VirusTotal
• Detect-It-Easy
• PEView
• Resource Hacker
• IDA Pro

Beginning with the basic static analysis, upload the binary on VirusTotal and flagged it with threat categories of Trojan and Dropper.

After that upload it in Detect-It-Easy for basic information like File format, Imports, Strings, Resources.

In strings, i saw “GinaDLL”, “msgina32.dll”, “SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon”, and functions names prepended with “WLX”. These are the signs of GINA interception malware.

In PEView, we can see that it contains a PE File named “TGAD” embedded in Resource section.

Now we can open the binary in IDA Pro, to look into the functions of exe. We can see in IDA what its doing. It copies the TGAD section into a file named “msgina32.dll” and inserts its path into the registry key “SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon”, so that it will be loaded by winlogon whenever the system restarts.

To extract the TGAD resource section, we can drop the binary in Resource Hacker, and save the Resource as bin file.

Now, to see basic information of msgina32.dll, load it in Detect-It-Easy.

To begin analyzing the DLL, load it in IDA Pro, we see its DllMain function.

At first, DllMain is trying to check the fdwReason argument and comparing it to 1, which is meant for DLL_PROCESS_ATTACH. Let’s check out the MSDN Documentation for fdwReason.

BOOL WINAPI DllMain(
    HINSTANCE hinstDLL,  // handle to DLL module
    DWORD fdwReason,     // reason for calling function
    LPVOID lpvReserved )  // reserved
{
    // Perform actions based on the reason for calling.
    switch( fdwReason ) 
    { 
        case DLL_PROCESS_ATTACH:    // Initialize once for each new process.
         // Return FALSE to fail DLL load.
            break;

        case DLL_THREAD_ATTACH:     // Do thread-specific initialization.
            break;

        case DLL_THREAD_DETACH:     // Do thread-specific cleanup.
            break;

        case DLL_PROCESS_DETACH:
        
            if (lpvReserved != nullptr)
            {
                break; // do not do cleanup if process termination scenario
            }
            
         // Perform any necessary cleanup.
            break;
    }
    return TRUE;  // Successful DLL_PROCESS_ATTACH.
}

The DllMain function, gets a handle to msgina.dll in the Windows system directory through the call to LoadLibraryW.

Now to analyze exported functions, Lets start with WlxInitialise. It is short and simply passes thorough to the true WlxInitialize contained in msgina.dll. There are two WlxInitialize functions : one in msgina32.dll and the other original one in msgina.dll.

; WlxInitialize function
10001320       push    offset aWlxinitialize_0 ; "WlxInitialize"
10001325       call    sub_10001000
1000132A       jmp     eax
1000132A       endp

One in msgina32.dll passes the string “WlxInitialize” to the function sub_10001000 which just gets the address of the original function thorough GetProcAddress and jumps to it.

All the exported functions operate the same as WlxInitialize did, except for WlxLoggetOutSAS, which contains some extra code. It begins with resolving WlxLoggedOutSAS within msgina.dll using GetProcAddress and then calling it. After calling the original function, it checks if it succeeded or not and passes some arguments along with a format string “UN %s DM %s PW %s OLD %s” to function sub_10001570.

WlxLoggedOutSAS is used by the Windows Logon process to notify the system that the user has logged out.

pNprNotifyInfo : Pointer to an WLX_MPR_NOTIFY_INFO structure that contains domain, user name, and password information for the user.

Let’s analyze the function sub_10001570, i.e.:

At first it calls vsnwprintf to fill in the format string with UserName, Domain, Password, OldPassword. Then, it opens a file named “msutil32.sys” created inside C:\windows\system32\ since that is where Winlogon resides and msgina32.dll is running in the Winlogon process. Next Time and Date are recorded and all the information is being logged in the file.

Questions and Answers

Question 1: What does the malware drop to disk?
Answer: The malware drops a binary named "msgina32.dll" extracted from the resource section named "TGAD".

Question 2: How does the malware achieve persistence?
Answer: The malware adds the binary msgina32.dll into the registry key SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon, which causes the DLL to be loaded after system reboot.

Question 3: How does the malware steal user credentials?
Answer: Through GINA Interception, msgina32.dll is able to intercept the user credentials.

Question 4: What does the malware do with stolen credentials?
Answer: The malware logs all the stolen credentials to the file msutil32.sys. 

Question 5: How can you use this malware to get user credentials from your test environment?
Answer: Reboot the system after installing the malware to begin the GINA Interception, then it will start logging credentials whenever the user will log out. And after login, checkout the msutil32.sys log file.