FLOSS[Fireeye Labs Obfuscated String Solver]: tool to retrieve stack strings.

 

Lets admit, stack strings sometimes could be a lot of pain. They are one of the favorite method of malware authors to hide static strings without going. The stack strings allows them to hide strings in plain sight[so to say] and avoids use of complicated obfuscation techniques. While authors can use packers instead but analysts can these days easily identify the packed malware based on entropy level. Indeed the knowledge that sample is packed itself can help analysts to take different approach instead of wasting time in reading packed code.

But stack strings leave no hints behind[mostly]. Thus analysts may loose critical source of information to create good Host or Network signatures of malware for early detection.

Let us take following piece of malicious file:

Unknwown.exe

If we use Strings utility from Sysinternals suite we get following output:

These are utter nonsensical strings that carry no information for us. This is not defect of Strings utility really. It is designed to look for contiguous blocks of memory that contain printable ASCII characters terminated with null. The important word here is contiguous. 

The malware authors exploit this, by storing parts of string separately. Then they construct the relevant string at run time by pushing these individual parts on stack and retrieving full string by pop. Look at the following code:

The code belongs to same file we ran Strings utility on. The parts of strings are separately stored and pushed on stack. Later a single pop would retrieve a pointer to whole string.

It is not that Strings utility entirely missed these strings. We may miss these due to one of following two reasons:

1. the length of individual string part is smaller than -n option set in Strings utility
2. the individual parts were nonsensical in themselves thus we may not be able to recognize them as part of larger sensible string

So, what is the solution:

For one, we can proceed with IDA or Ollydbg to go through code/execution to catch similar code snippet as shown above. Although not challenging, manually recovering stack strings in IDA Pro can be a cumbersome process. Besides at Static analysis phase, we really are in hurry to get some concrete evidences out of sample.

Second option is to use Floss tool, which is what topic of our post today.

FLOSS: Fireeye Labs Obfuscated String Solver

This tool by Fireeye has really reduced the usability of stack strings obfuscation technique considerably.

What sets FLOSS from Strings apart is that it utilizes heuristics and code path emulation to arrive at runtime construction of strings. We will not go into detail about how FLOSS works. You can read more here.

Lets dive right into use of FLOSS.

You can run FLOSS in similar way as you did Strings.exe. If we run FLOSS on earlier Unknown.exe malware we get following output:

The last string was is stack string extracted from file. You can cross check its content with individual parts shown in code snippet earlier.Such strings can be great malware signatures.

So there you go. Next time you come across a sample that seem to have no sensible strings whatsoever, be sure to run FLOSS.

Till next time, Cheers!

Credential Stealing Malware [GINA]

 Hey guys!

Today we have a new sample that we need to analyse. Unlike the previous, here I will not be explaining each step one by one. We shall proceed with analysis real quick. So, lets get going.

Sample: .exe file

It is always helpful to start with knowing static content about binary before diving into it. So our first task would be to extract as much static info about binary as possible.

Static Analysis:

Following are the hints I found interesting about file when opened in PEStudio.

Static strings:

SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

msutil32.sys

msgina32.dll

MSGina.dll

UN %s DM %s PW %s OLD %s

ErrorCode:%d ErrorMessage:%s. 

%s %s - %s

The last three strings seem to be format strings based on presence of format specifier %S.

The first string is no doubt a registry key related to Windows login.

The third string is GINA dll which is used for custom login procedure. You can look into Google for further info.

API calls:

LoadResource

RegCreateKeyExA

WriteFile

CreateFileA

ReadFile

GetProcAddress

LoadLibraryA

SetStdHandle

Presence of LoadResource and WriteFile function indicates that the file loads a certain resource[presumably binary file] and writes it to a file. This is indeed is true since PE Studio shows a resource in resource section. A quick glance at its content reveals that it is a PE file.

Now we will have include this new PE file located as resource into out static analysis.

Strings:

    Most of the strings found in this sample also can be found in original PE file since this file was part of resource section of original file.

APIs:

GetSystemDirectoryW : tinkers with /Windows/System32

RegSetValueExW : updates/sets registry key

RegCreateKeyW : create new key

malloc : allocates memory

LoadLibraryW : dynamic loading of dll

GetProcAddress 

lstrcatW : string concatenation

lstrcpyW

Another surprise is that this new PE file is actually a DLL file. This can be confirmed by the presence of export table in its PE structure. Another way to confirm this is DLL flagin Optional Header of the file has been set to True. 

From the available information so far we can make following rough assumptions:

1. The original file is a dropper/launcher which unloads the real malware and executes it.    
2. The file also adds a new registry key and value in the Computer. We can presume this key is in  SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
3. The dll that is unloaded into system has something to do with GINA functionality.

VM Sandbox detonation:

  Lets us execute this file in our protected/isolated VM[Windows 10]. Do not forget to keep all tools ready before executing file. Since this file makes changes in registry, we will run this file as an Administrator.

Bread-crums:

• Create and Write file: <current\directory>\msgina32.dll 
• Creates new registry key 
• HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\Winlogon\GinaDLL and sets value to msgina32.dll file location above.

Check out the screen shots below:

   

file dropped in current directory

new Registry entry

Now as far as second file is concerned, we have two options to carry forward our analysis:

1. Execute the dll file using rundll32.exe command
2. Proceed with IDA to look into DLL code.

We shall take second option. Since the DLL file has Export table,the functionality it provides will be used by some other program. That is its function needs to be called to carry out its task.

IDA Pro:

The function DllEntryPoint is the first one that will be called once DLL is loaded into memory. It is also called as DLLMain.

 It's graph seems to be a bit complex so let look into other functions first. We shall come back to DllMain later.

If we scoll through all the functions , we notice most of the functions are very small with few lines of code as shown below:

                

Each of these functions first make a call to sub_10001000 and then jump to the whatever is returned by the function in eax. 

So let us proceed to analyze sub_10001000.

    

As shown above, the functions merely calls GetProcAddress which returns the address of function passed to it as argument. This argument is sent by each exported function of dll. If we notice the functions that call this sub_10001000 have same name as the function name string they pass. This means calls are being redirected to some other dll. So the question is which is this library.

This function requires the handle to the library to which the intended function belongs. The handle is stored in eax which is loaded from memory offset dword_10003324. This means some other function is storing the handle to library at runtime which is afterwards accessed by this function.

If we cross reference the memory address dword_10003324 by pressing X, it is revealed that handle is being stored by sub_10001050

                 

Let us take our analysis there. Notice the call to LoadLibrary in the picture below. It requires the name of the library to be loaded as argument. From the call to GetSystemDirectory and offset "MSGina" it is clear that library being loaded in<Systemroot>\Windows\System32\MSGina.dll

                                                  

If we search MSGina library on Google, we notice that all the exported functions by this library also match with functions exported by library we are analyzing. 

So we can be sure that malware is first intercepting calls may possibly have been doing some malicious activity and then redirecting calls to MSGina library.

But what is the malicious activity being carried out here? And how?

From our earlier analysis we already know that malware has something too do with GINA. The library to implement functionality of GINA is msgina.dll. GINA is related to user login in Windows. This malware is intercepting the calls to GINA. 

So if we connect the dots, its evident that malware is stealing the credentials of the user when he/she logs in. Now the question is where is it being stored? We need this info because it can act as a great Host based or Network based signature to identify malware.As we have not seen any networking APIs being used, this malware must be logging the credentials somewhere.

We noticed static string msutil32.sys in this file. So we can take an informed guess that password might be logged in this file. To know the precise location of file, we need to analyze further.

The fucntion WlxLoggedOutSAS stands apart from the rest of the functions in a sense that it not only redirects call to original dll function but also calls one other function sub_10001570. If we proceed to this function we find following snippets of code:

Open a file:

Write to it :

Close the file:

Since full path is nor being provided the file will be opened in the context in which this dll was loaded. So the question arises who will call this dll? And how will it inject itself before MSGina.dll?

The answer to this question was evident at the start itself. We know that adds its path as a registry value to GINA in Winlogon. The Winlogon is configured in Win XP to call dlls that are registered at this registry location when user logs in. It sends credentials entered by user to these dlls. Since our malware has inserted itself at this location, we can be sure that it will get credentials from Winlogon. But to ensure that normal execution of login is carried out, it passed these credentials further to original MSGina.dll

So we can conclude that this malware sample is a credential stealing malware.