Learning of malware analysis. Solving labs from the "Analyzing malicious Windows programs" chapter from the "Practical Malware Anlysis" book
I have to tell you that this chapter was the best that I've read since the beginning of the book. The information and tricks presented in this part of the amazing lecture made me happy. I'm sure that the labs will be as exciting as the whole chapter and I'm looking forward to solving them. As the title suggests, "Analyzing malicious Windows programs" chapter is all about the Windows OS internals useful primarily for the malware writers and thus for malware analysts too. Without further ado, I bring to you my solutions for the labs. Enjoy!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Lab 7-1
Analyze the malware found in the file Lab07-01.exe.
Questions:
1. How does this program ensure that it continues running (achieves persistence) when the computer is restarted?
2. Why does this program use a mutex?
3. What is a good host-based signature to use for detecting this program?
4. What is a good network-based signature for detecting this malware?
5. What is the purpose of this program?
6. When will this program finish executing?
My answers:
1) How does this program ensure that it continues running (achieves persistence) when the computer is restarted?
The above question isn't just about loading the malicious program into IDA and reading the code. Due to this fact, I'm going to analyze this malware "from scratch" without jumping directly into "Advanced Static Analysis". Firstly, let's open the file in Pestudio and check for useful information such as strings and imports. (since the malicious file is in the PE format this time)
The very first interesting information is the subsystem of this executable which is "console" so we now know that we have to use cmd to run this file properly.
Within the "indicators" section there is a hint about the URL saved inside the executable. This URL is "malwareanalysisbook.com" and can be treated as the network-based indicator of this malware.
From the list of the imports table I've decided to take these as the most attractive:
These imported functions tell us that this malicious program is probably a service:
- CreateServiceA
- OpenSCMangerA
- StartServiceCtrlDispatcherA
And these, in turn, give us information that this malware communicates with some host over the network:
- InternetOpenUrlA
- InternetOpenA
We have also some imports that do the job with threads, mutexes, and the heap. This program also probably loads some library in runtime due to these imported functions -> GetModuleFileNameA, GetProcAddress, LoadLibraryA. From the basic static analysis process, we can suppose that this malicious software also tries to get some information from the PEB memory section using these imports -> GetEnvironmentStrings, GetEnvironmentStringsW. In the further analysis process, we have to look for some command line indicators since the program imports GetCommandLineA function.
There is nothing hidden inside the resource section so we can jump directly into strings.
Obviously, there is the "malwareanalysisbook.com" URL in the strings section, although I mentioned it earlier. If the executable is a service indeed, then it should be the service name in the strings section and here it is -> MalService - this name is a well host-based indicator.
After basic static analysis, it's time for the basic static analysis process to check for the new processes created by the malware as well as called WinAPI functions. Obviously, I will be using Process Explorer, Process Monitor, Regshot, and fake network set between Windows XP and Linux machine.
First, I've taken the first snapshot using the Regshot tool to compare registry entries before the malware launch and after it. Wireshark's listening for the malware network actions.
As the subsystem suggests let's run this malicious program using the console.
After launching the malware it doesn't terminate but waits for something. To be able to answer the questions "What this file is waiting for?" we need to analyze the malware's code in IDA later on. The malware is running so let's take a second snapshot using Regshot and see if something has changed within the registry.
Now we can be sure that this malware is the service indeed with the name of "Malservice". When some file is a service then there are some useful information about it within the registry. To be able to query services we can use a builtin tool called sc. This is the console program responsible for querying and manipulating services on the Windows system. Let's use this tool to query the Malservice using the qc option.
Querying the service gives us the answer to the first question in this lab. This program ensures that it continues running when the computer is restarted by setting its START_TYPE to AUTO_START so this program starts at the boot time. It can set this value since the program is the service.
2) Why does this program use a mutex?
We have the question about the mutex of this program so let's see if it really sets some mutex using Process Explorer.
Unfortunately, there are many mutexes created by the malware so another way to investigate the correct mutex is to set the filter in the Process Monitor to Operation is OpenMutexA and another filter should be Operation is CreateMutexA.
Process Monitor didn't show anything related to the creation of the mutex. This behavior is suspicious, but we have one more option to make things right -> IDA. Let's get deep into the code of the malware and check for the function calls related to the mutexes.
This how the main function looks like. We already know from the basic static and dynamic analysis processes that the Lab07_01.exe creates service with the name of "MalService" which is started at the boot time of the system to achieve the persistence so we can safely jump into sub_401040.
The OpenMutexA function is called as the first WinAPI method inside our sub_401040 subroutine. If the function fails to open the "HGL345" mutex then the process executes this code primarily:
In other words -> if the mutex doesn't exist on the victim's machine then the program creates this "HGL345" mutex and achieving persistence as the service. Thus, this program uses a mutex to ensure that only one copy of the program is running at the time.
3) What is a good host-based signature to use for detecting this program?
In the answer to the first question, I mentioned that the Lab07_01.exe achieves persistence by creating the "MalService" service with the START_TYPE: AUTO_START. Due to this fact, a good host-based signature to use for detecting this program is the MalService service running on the system started at the boot time. Obviously, another good host-based signature to use for detecting this program is the mutex named HGL345.
4) What is a good network-based signature for detecting this malware?
To gather some information about the network activity of the malware it's good to use some network sniffer. I've used Wireshark after setting everything up inside the fake network. I've also launched the ApateDNS to redirected every DNS response to the fake HTTP service running on my Linux machine. Let's see if ApateDNS and Wireshark caught something interesting.
ApateDNS gave us information about the domain requested by the malware. This domain is the "malwareanalysisbook.com" as we could expect based on the indicators gathered from the earlier analysis. Now let's see at the output of the Wireshark network sniffer. A couple of TCP requests and responses appear so to get a better view of the situation let's click Follow TCP Stream.
Now we know that the malware communicates with the "malwareanalysisbook.com" domain through the HTTP protocol. This communication, as well as the domain name, is a good network-based signature for detecting this malware. In the earlier process of the analysis, there was an "Internet Explorer 8.0" in the strings section of the executable. This exact string is used as the User-Agent for the malware connections and thus it's the next strong network-based indicator.
The above screenshots from IDA are the confirmation that the malware uses "Internet Explorer 8.0" User-Agent each time it connects to the specified domain.
5) What is the purpose of this program?
This program runs as a service called "MalService" to achieve persistence on the victim's system. Before installing as a service the malware opens a mutex called "HGL345" and checks if this exact mutex already exists on the OS. If "HGL345" exists the malware exits with 0 as error code. This means that the malware creates mutex to ensure that only one malware's executable is running at the time. After connecting with the Service Control Manager and the services database the binary installs itself as a service with the AUTO_START type. Thus, "MalService" starts each time the system boots. It appears that the next part of the execution measures the time it takes to create and execute threads inside the service:
SystemTimeToFileTime WinAPI function is called with the SystemTime structure as the first argument. The first element of the structure wYear is set to 2100 and the rest of the members are 0. This function converts the time saved inside the SystemTime structure to the FileTime which is the 64-bit value representing the number of 100-nanosecond intervals since January 1, 1601 (UTC). SetWaitableTimer activates our timer which is signaled after DueTime milliseconds elapsed. Then there is a call to WaitForSingleObject method with INFINITE value as the second argument and our timer as the first argument. This function checks for the object (in our case the timer) state and if it's not signaled the calling thread enters the wait state.
When the 2100 year will begin the malware will create exactly 20 threads. Threads are responsible for executing the code at the address passed to the CreateThread method as the third argument. Let's see what code each of the threads executes.
Each thread connects to the malwareanalysisbook.com using the Internet Explorer 8.0 User-Agent. It's worth to point that each thread establishes a connection with the domain inside the infinite loop. This action is called a DDoS.
When the OS scheduler decides to switch the context of the last thread created in the loop to the main thread, the malware sleeps for the 4294967295 milliseconds which is about 49 days.
Answer: The purpose of this malware is to do a DDoS attack on the malwareanalysisbook.com server.
6) When will this program finish executing?
This program will finish executing after about 49 days from the 1 January 2100. The whole analysis that leads to this answer is mentioned in the earlier question.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Lab 7-2
Analyze the malware found in the file Lab07-02.exe.
Questions:
1. How does this program achieve persistence?
2. What is the purpose of this program?
3. When will this program finish executing?
My answers:
1) How does this program achieve persistence?
Let's start the analysis process with basic static analysis using PeStudio tool.
The malware is a 32-bit PE file. To run this executable we need to use console since its subsystem is "console". The Imports Table is small because there are only 19 imported functions to this executable and therefore the further static analysis using IDA might be easy. The only useful string for us inside this malware is http://www.malwareanalysisbook.com/ad.html. ad.html file seems to be some kind of advertisement and thus we can assume that we are dealing with adware but to be 100% sure we have to analyze the code of the binary. Before this, let's analyze this file by using basic dynamic analysis techniques. (there aren't any resources in the binary so Resource Hacker tool will be useless this time) After launching the malware inside the console, the Internet Explorer appears with malwareanalysis.com/ad.html file displayed.
Obviously, the real ad.html doesn't look like the file displayed inside the browser from the screenshot since I'm using a fake network and also a fake HTTP server. Process Explorer tool has told us that the malware had exited immediately after the ad had appeared. Thus the malware doesn't achieve any persistence since it simply exits and the OS terminates this process.
Wireshark has confirmed that the malware had requested malwareanalysis.com/ad.html with the GET request. Regshot didn't show anything useful to us as well as Process Monitor - there were many WinAPI calls done by the malware but in my opinion, the best way to continue analysis and to find the answer to the question is to load the binary into IDA and see what is happening in more depth. First of all, it's worth looking at the Imports. The malware uses two meaningful functions from the analyst point of view - OleInitalize and CoCreateInstance. These two methods are here for COM object initialization and thus we can be sure that this suspicious file uses Component Object Model.
And this is the IWebBrowser2 interface structure:
typedef struct IWebBrowser2Vtbl | |
{ | |
BEGIN_INTERFACE | |
HRESULT ( STDMETHODCALLTYPE *QueryInterface )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ __RPC__in REFIID riid, | |
/* [annotation][iid_is][out] */ | |
_COM_Outptr_ void **ppvObject); | |
ULONG ( STDMETHODCALLTYPE *AddRef )( | |
__RPC__in IWebBrowser2 * This); | |
ULONG ( STDMETHODCALLTYPE *Release )( | |
__RPC__in IWebBrowser2 * This); | |
HRESULT ( STDMETHODCALLTYPE *GetTypeInfoCount )( | |
__RPC__in IWebBrowser2 * This, | |
/* [out] */ __RPC__out UINT *pctinfo); | |
HRESULT ( STDMETHODCALLTYPE *GetTypeInfo )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ UINT iTInfo, | |
/* [in] */ LCID lcid, | |
/* [out] */ __RPC__deref_out_opt ITypeInfo **ppTInfo); | |
HRESULT ( STDMETHODCALLTYPE *GetIDsOfNames )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ __RPC__in REFIID riid, | |
/* [size_is][in] */ __RPC__in_ecount_full(cNames) LPOLESTR *rgszNames, | |
/* [range][in] */ __RPC__in_range(0,16384) UINT cNames, | |
/* [in] */ LCID lcid, | |
/* [size_is][out] */ __RPC__out_ecount_full(cNames) DISPID *rgDispId); | |
/* [local] */ HRESULT ( STDMETHODCALLTYPE *Invoke )( | |
IWebBrowser2 * This, | |
/* [annotation][in] */ | |
_In_ DISPID dispIdMember, | |
/* [annotation][in] */ | |
_In_ REFIID riid, | |
/* [annotation][in] */ | |
_In_ LCID lcid, | |
/* [annotation][in] */ | |
_In_ WORD wFlags, | |
/* [annotation][out][in] */ | |
_In_ DISPPARAMS *pDispParams, | |
/* [annotation][out] */ | |
_Out_opt_ VARIANT *pVarResult, | |
/* [annotation][out] */ | |
_Out_opt_ EXCEPINFO *pExcepInfo, | |
/* [annotation][out] */ | |
_Out_opt_ UINT *puArgErr); | |
/* [helpcontext][helpstring][id] */ HRESULT ( STDMETHODCALLTYPE *GoBack )( | |
__RPC__in IWebBrowser2 * This); | |
/* [helpcontext][helpstring][id] */ HRESULT ( STDMETHODCALLTYPE *GoForward )( | |
__RPC__in IWebBrowser2 * This); | |
/* [helpcontext][helpstring][id] */ HRESULT ( STDMETHODCALLTYPE *GoHome )( | |
__RPC__in IWebBrowser2 * This); | |
/* [helpcontext][helpstring][id] */ HRESULT ( STDMETHODCALLTYPE *GoSearch )( | |
__RPC__in IWebBrowser2 * This); | |
/* [helpcontext][helpstring][id] */ HRESULT ( STDMETHODCALLTYPE *Navigate )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ __RPC__in BSTR URL, | |
/* [unique][optional][in] */ __RPC__in_opt VARIANT *Flags, | |
/* [unique][optional][in] */ __RPC__in_opt VARIANT *TargetFrameName, | |
/* [unique][optional][in] */ __RPC__in_opt VARIANT *PostData, | |
/* [unique][optional][in] */ __RPC__in_opt VARIANT *Headers); | |
/* [helpcontext][helpstring][id] */ HRESULT ( STDMETHODCALLTYPE *Refresh )( | |
__RPC__in IWebBrowser2 * This); | |
/* [helpcontext][helpstring][id] */ HRESULT ( STDMETHODCALLTYPE *Refresh2 )( | |
__RPC__in IWebBrowser2 * This, | |
/* [unique][optional][in] */ __RPC__in_opt VARIANT *Level); | |
/* [helpcontext][helpstring][id] */ HRESULT ( STDMETHODCALLTYPE *Stop )( | |
__RPC__in IWebBrowser2 * This); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_Application )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__deref_out_opt IDispatch **ppDisp); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_Parent )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__deref_out_opt IDispatch **ppDisp); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_Container )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__deref_out_opt IDispatch **ppDisp); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_Document )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__deref_out_opt IDispatch **ppDisp); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_TopLevelContainer )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__out VARIANT_BOOL *pBool); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_Type )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__deref_out_opt BSTR *Type); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_Left )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__out long *pl); | |
/* [propput][id] */ HRESULT ( STDMETHODCALLTYPE *put_Left )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ long Left); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_Top )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__out long *pl); | |
/* [propput][id] */ HRESULT ( STDMETHODCALLTYPE *put_Top )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ long Top); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_Width )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__out long *pl); | |
/* [propput][id] */ HRESULT ( STDMETHODCALLTYPE *put_Width )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ long Width); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_Height )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__out long *pl); | |
/* [propput][id] */ HRESULT ( STDMETHODCALLTYPE *put_Height )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ long Height); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_LocationName )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__deref_out_opt BSTR *LocationName); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_LocationURL )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__deref_out_opt BSTR *LocationURL); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_Busy )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__out VARIANT_BOOL *pBool); | |
/* [helpcontext][helpstring][id] */ HRESULT ( STDMETHODCALLTYPE *Quit )( | |
__RPC__in IWebBrowser2 * This); | |
/* [helpcontext][helpstring][id] */ HRESULT ( STDMETHODCALLTYPE *ClientToWindow )( | |
__RPC__in IWebBrowser2 * This, | |
/* [out][in] */ __RPC__inout int *pcx, | |
/* [out][in] */ __RPC__inout int *pcy); | |
/* [helpcontext][helpstring][id] */ HRESULT ( STDMETHODCALLTYPE *PutProperty )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ __RPC__in BSTR Property, | |
/* [in] */ VARIANT vtValue); | |
/* [helpcontext][helpstring][id] */ HRESULT ( STDMETHODCALLTYPE *GetProperty )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ __RPC__in BSTR Property, | |
/* [retval][out] */ __RPC__out VARIANT *pvtValue); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_Name )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__deref_out_opt BSTR *Name); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_HWND )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__out SHANDLE_PTR *pHWND); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_FullName )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__deref_out_opt BSTR *FullName); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_Path )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__deref_out_opt BSTR *Path); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_Visible )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__out VARIANT_BOOL *pBool); | |
/* [helpcontext][helpstring][propput][id] */ HRESULT ( STDMETHODCALLTYPE *put_Visible )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ VARIANT_BOOL Value); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_StatusBar )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__out VARIANT_BOOL *pBool); | |
/* [helpcontext][helpstring][propput][id] */ HRESULT ( STDMETHODCALLTYPE *put_StatusBar )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ VARIANT_BOOL Value); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_StatusText )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__deref_out_opt BSTR *StatusText); | |
/* [helpcontext][helpstring][propput][id] */ HRESULT ( STDMETHODCALLTYPE *put_StatusText )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ __RPC__in BSTR StatusText); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_ToolBar )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__out int *Value); | |
/* [helpcontext][helpstring][propput][id] */ HRESULT ( STDMETHODCALLTYPE *put_ToolBar )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ int Value); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_MenuBar )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__out VARIANT_BOOL *Value); | |
/* [helpcontext][helpstring][propput][id] */ HRESULT ( STDMETHODCALLTYPE *put_MenuBar )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ VARIANT_BOOL Value); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_FullScreen )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__out VARIANT_BOOL *pbFullScreen); | |
/* [helpcontext][helpstring][propput][id] */ HRESULT ( STDMETHODCALLTYPE *put_FullScreen )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ VARIANT_BOOL bFullScreen); | |
/* [helpcontext][helpstring][id] */ HRESULT ( STDMETHODCALLTYPE *Navigate2 )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ __RPC__in VARIANT *URL, | |
/* [unique][optional][in] */ __RPC__in_opt VARIANT *Flags, | |
/* [unique][optional][in] */ __RPC__in_opt VARIANT *TargetFrameName, | |
/* [unique][optional][in] */ __RPC__in_opt VARIANT *PostData, | |
/* [unique][optional][in] */ __RPC__in_opt VARIANT *Headers); | |
/* [helpcontext][helpstring][id] */ HRESULT ( STDMETHODCALLTYPE *QueryStatusWB )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ OLECMDID cmdID, | |
/* [retval][out] */ __RPC__out OLECMDF *pcmdf); | |
/* [helpcontext][helpstring][id] */ HRESULT ( STDMETHODCALLTYPE *ExecWB )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ OLECMDID cmdID, | |
/* [in] */ OLECMDEXECOPT cmdexecopt, | |
/* [unique][optional][in] */ __RPC__in_opt VARIANT *pvaIn, | |
/* [unique][optional][out][in] */ __RPC__inout_opt VARIANT *pvaOut); | |
/* [helpcontext][helpstring][id] */ HRESULT ( STDMETHODCALLTYPE *ShowBrowserBar )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ __RPC__in VARIANT *pvaClsid, | |
/* [unique][optional][in] */ __RPC__in_opt VARIANT *pvarShow, | |
/* [unique][optional][in] */ __RPC__in_opt VARIANT *pvarSize); | |
/* [bindable][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_ReadyState )( | |
__RPC__in IWebBrowser2 * This, | |
/* [out][retval] */ __RPC__out READYSTATE *plReadyState); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_Offline )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__out VARIANT_BOOL *pbOffline); | |
/* [helpcontext][helpstring][propput][id] */ HRESULT ( STDMETHODCALLTYPE *put_Offline )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ VARIANT_BOOL bOffline); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_Silent )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__out VARIANT_BOOL *pbSilent); | |
/* [helpcontext][helpstring][propput][id] */ HRESULT ( STDMETHODCALLTYPE *put_Silent )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ VARIANT_BOOL bSilent); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_RegisterAsBrowser )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__out VARIANT_BOOL *pbRegister); | |
/* [helpcontext][helpstring][propput][id] */ HRESULT ( STDMETHODCALLTYPE *put_RegisterAsBrowser )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ VARIANT_BOOL bRegister); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_RegisterAsDropTarget )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__out VARIANT_BOOL *pbRegister); | |
/* [helpcontext][helpstring][propput][id] */ HRESULT ( STDMETHODCALLTYPE *put_RegisterAsDropTarget )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ VARIANT_BOOL bRegister); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_TheaterMode )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__out VARIANT_BOOL *pbRegister); | |
/* [helpcontext][helpstring][propput][id] */ HRESULT ( STDMETHODCALLTYPE *put_TheaterMode )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ VARIANT_BOOL bRegister); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_AddressBar )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__out VARIANT_BOOL *Value); | |
/* [helpcontext][helpstring][propput][id] */ HRESULT ( STDMETHODCALLTYPE *put_AddressBar )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ VARIANT_BOOL Value); | |
/* [helpcontext][helpstring][propget][id] */ HRESULT ( STDMETHODCALLTYPE *get_Resizable )( | |
__RPC__in IWebBrowser2 * This, | |
/* [retval][out] */ __RPC__out VARIANT_BOOL *Value); | |
/* [helpcontext][helpstring][propput][id] */ HRESULT ( STDMETHODCALLTYPE *put_Resizable )( | |
__RPC__in IWebBrowser2 * This, | |
/* [in] */ VARIANT_BOOL Value); | |
END_INTERFACE | |
} IWebBrowser2Vtbl; |
Having offset, the position of the function can be calculated in this way: offset / 4 + 1. One has to be added since the first function in the structure has the offset 0. The position of the function used by the malware is 44 / 4 + 1 == 12. The twelfth function inside the IWebBrowser2 interface structure is Navigate. The purpose of this program is to display advertisement in the Internet Explorer window.
Lab 7-3
Lab07-03.exe is the executable file with the console subsystem, obviously, it is also for x86 architecture.
Basic dynamic analysis
This part of the analysis didn't tell us anything. The malware exits immediately after launching without leaving any footprint.
Advanced static analysis of Lab07-03.exe
A quick looking at the code is enough to point out why the malware exits immediately after launching.
This part of malware's code is actually a loop where the first argument from the console is compared with the hard-coded string which is "WARNING_THIS_WILL_DESTROY_YOUR_MACHINE" in our case. Obviously, the real malware would have a simple command/switch like "-a" instead of warning, but authors of the book have changed this command to protect us from running this malware. If the argument is correct then eax stores 0 inside and serious malware's code finally starts. Before doing the below screenshot I used Symbolic constant option to simplify the analysis.
Starting from the top we have a call to the CreateFileA function. The malware opens the Kernel32.dll with GENERIC_READ access. The file handler resides inside the eax register after the function returns. The next WinAPI method used by the malware is CreateFileMappingA. This function creates a file mapping object in the current process memory space. A file mapping object can store any binary file. By calling the MapViewOfFile function the malware's behavior can be compared to the OS loader. As a result of these two careless calls, the malware loaded kernel32.dll file into its own address space. Next, Lab07-03.exe uses CreateFileA function again, but this time to read Lab07-03.dll which is used as the backdoor to ensure communication with the attacker's server.
The registry state after execution of the above malware's code:
eax -> handle to "Lab07-03.dll" file
esi -> handle to the file mapping object with "kernel32.dll" content written inside (with FILE_MAP_READ and PAGE_READONLY privileges)
I've cut the beginning of the if statement but you can believe me that this malware exits when the above CreateFileA function fails. Otherwise - if the malware owns the correct handle to the "Lab07-03.dll" file then another CreateFileMappingA is called along with MapViewOfFile. These WinAPI methods are responsible for writing the content of the "Lab07-03.dll" into malware's memory space with PAGE_READWRITE and FILE_MAP_ALL_ACCESS privileges. If one of these functions fails the malware exits.
The registry state after mapping DLLs into malware's memory space:
esi -> handle to the file mapping object with "kernel32.dll" content written inside (with FILE_MAP_READ and PAGE_READONLY privileges)
ebp -> handle to the file mapping object with "Lab07-03.dll" content written inside (with PAGE_READWRITE and FILE_MAP_ALL_ACCESS privileges)
[esp+<offset>+argv] -> handle to the file mapping object with "Lab07-03.dll" content written inside (with PAGE_READWRITE and FILE_MAP_ALL_ACCESS privileges)
Now we have to deal with quite a lot of code that modifies probably the content of the "Lab07-03.dll" with the help from "kernel32.dll" since file mapping object of the "kernel32.dll" file has FILE_MAP_READ and PAGE_READONLY privileges. What I learned from this book is that the very long and complicated functions might be writing by malware authors to confuse malware analysts. That being said I'm not going to analyze the code that affects file mappings line by line. Instead, I will look at this piece of code roughly.
The first lines of code are clear enough to tell that the malware uses kernel32.dll file mapping as well as Lab07-03.dll file mapping. To deal with the contents of these two the malware calls sub_401040 function with 3 arguments. These arguments are the addresses of some locations within the PE format. Let's jump to this function and see what is going on inside with these addresses.
These addresses are passed to the next function named sub_401000 by the IDA. After the function has done its job the malware does some arithmetic without writing anything into memory. We now know that the sub_401040 returns something - it might be the pointer to some structure inside the PE file format but this is only an assumption. sub_401000 also does some operations on the file mapping object but it's not important for us at this moment.
These marked instructions are called to scan the part of file mapping objects memory (in case of scasb) and for writing bytes or words inside file mapping objects memory. (in case of movsb and moved respectively) As we already know from earlier analysis process, kernel32.dll file mapping object has only PAGE_READONLY and FILE_MAP_READ privileges, therefore, I'm pretty sure that the malware tries to modify Lab07-03.dll (with writing privileges) with some data gathered from kernel32.dll and this is done by "rep movsb" or "rep movsd" instructions. Memory modifications are made inside the loop. Let's say that the malware has done everything related to DLLs modifications. Here is the code that will be executed:
At first glance, you can see that this code loads Lab07-03.dll as kerne132.dll inside every process on the disk C. I guess that the kerne132.dll is run in place of the kernel32.dll. Let's try to confirm my assumption and jump right into sub_4011E0 subroutine since earlier calls are clean and simple.
The last subroutine called inside the main function consists of calls to "Find Files" functions from WinAPI. The argument passed to this subroutine is "C:\\*", therefore, the malware probably tries to access some files inside the whole C drive. My assumption is based on the above-mentioned calls and the loop which ends when FindNextFileA fails.
At the beginning of the loop, we have a call to malloc which obviously allocates some memory on the heap. I don't know how many bytes this exact call to malloc allocates but I would check this with the debugger, unfortunately, I can't do this for now on.
Along with the mentioned call, the malware uses some repne scasb and rep movs instructions which are basically strlen and memcpy respectively. The important fact is that the ".exe" string is pushed on the stack thus we can suppose that this malware does kernel32.dll to kerne132.dll swap only for executable files.
After some memory operations with arithmetic tricks on the found file, there is a call to the _stricmp function. This method is the alias for the POSIX stricmp function and does the same thing. That being said according to stricmp_wiki this function should have exactly two arguments passed to it using a stack.
The marked instructions are used for pass the arguments to the later _stricmp call. Arithmetic operation done on the ebx register is a little bit complicated and IDA didn't give us any hint what the first argument really is. Again, I would use a debugger to investigate ebx register value before pushing it on the stack, but I can't use a debugger in this Lab. My next guess is that we have the extension of the found file inside the ebx. So the _stricmp call probably looks like this -> _stricmp(found_file_extension, ".exe");.
Next, we have an if statement which gives us a meaningful hint on how the _stricmp is called.
If the extension of the found file is ".exe" then _stricmp returns 0 and the malware calls sub_4010A0 subroutine. Otherwise, the malware tries to find the next file on the specified drive. Therefore, I'm almost sure now that this malicious program searches for the executable files with ".exe" extension and deals only with them. Let's check the internals of sub_4010A0.
Learning Of Malware Analysis. Solving Labs From The "Analyzing Malicious Windows Programs" Chapter From The "Practical Malware Anlysis" Book >>>>> Download Now
ReplyDelete>>>>> Download Full
Learning Of Malware Analysis. Solving Labs From The "Analyzing Malicious Windows Programs" Chapter From The "Practical Malware Anlysis" Book >>>>> Download LINK
>>>>> Download Now
Learning Of Malware Analysis. Solving Labs From The "Analyzing Malicious Windows Programs" Chapter From The "Practical Malware Anlysis" Book >>>>> Download Full
>>>>> Download LINK Gp