0xreizouko's den

Lab12-01#

I haven’t done dynamic analysis for a while but there’s nothing we can do, hopping on my xp machine I did a quick look to the files’ strings.

Looking at the imports of the exe file in PE Bear we can see some interesting functions indicating process injection, the dll has similar info so it will be confirmed in the advanced static analysis.

So let’s get everything ready to run the malware

• Procmon
• Process Hacker
• Process Explorer
• Procdot
• Regshot

The program started by sending a messageBox that “says press ok to reboot” and then it kept spamming it

I first checked regshot, I found this interesting added value

1
HKU\S-1-5-21-842925246-1715567821-682003330-1003\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\{75048700-EF1F-11D0-9888-006097DEACF9}\Count\HRZR_EHACNGU:P:\Qbphzragf naq Frggvatf\znatn\Qrfxgbc\CenpgvpnyZnyjnerNanylfvf-Ynof-znfgre\CenpgvpnyZnyjnerNanylfvf-Ynof-znfgre\Cenpgvpny Znyjner Nanylfvf Ynof\OvanelPbyyrpgvba\Puncgre_12Y\Yno12-01.rkr:  01 00 00 00 06 00 00 00 50 8E 90 22 81 64 DC 01

It has the path of the file encoded using ROT13, we will see how this is used in our advanced static analysis.

Looking at procmon this is all the events done by the sample

But it looks ugly so I will use procdot to generate a nice graph.

ok, I expected more events but here we are, so we need to do more analysis

The graph didn’t give much info; it injects a thread in Explorer.exe but we don’t know how it happens. so I looked more into procmon logs. the sample dropped a file named psapi.dll in C:/windows/system32, the file had the following exports turns out it’s a system dll, the create function can be also used to read files.

So we can consider this file as an IoC.

Ok, let’s start with Advanced Static Analysis, fire up IDA with Lab12-01.exe and we get jump scared with these indirect calls

After enumProcesses is done, an injection routine is being performed using VirtualAllocEx, WriteProcessMemory, GetModuleHandleA, GetProcAddress and CreateRemoteThread, it writes 260 bytes to the process.

The other branch calls a function named sub_401000

Which searches for the process explorer.exe, that we know from dynamic analysis is the injection target.

it then opens the process gets a handle and the process is repeated

So let’s look at the dll file

It creates a thread with a StartAddress that contains the code we see after running the malware, which gets injected in explorer.exe.

After confirming the analysis from the graph using static analysis, I decided to get back and check the injected code.

First in process explorer as the book explained in the solution(I tend to check the solution to see if I missed anything)

It shows that Lab12-01.dll is injected into the process.

Moving to a more modern solution Process Hacker we can check all the threads of the process by right click -> properties -> threads tab.

With that we can easily terminate the injected threads and stop the malware from spamming pop-ups.

Lab12-02#

For this lab we are provided with an exe file

Looking at the imports it seems to be importing resources-related APIs and performs process injection.

Since it deals with resources, I loaded up Resource Hacker but it wasn’t that helpful a blob of data so probably advanced static analysis will give away some decryption routine

Before I deep dive into Advanced Static Analysis, I took a look using floss.exe

We have host.exe and \svchost.exe as encoded strings, which might be the injection target.

Starting with advanced static analysis, a few functions are called in main

Starting with sub_40149D, the code is simple it calls GetSystemDirectoryA function which usually returns C:\Windows\System32, the function takes \svchost.exe as an argument and _strncat is called which indicates the function is returning the path C:\Windows\System32\svchost.exe.

The next function sub_40132C is responsible for loading data from resources section.

After loading the data, the program checks if it starts with MZ if not; it’s sent a the function sub_401000

Looking at function sub_401000 it looks like a decryption routine judging from the xor operation and the fact it’s a loop.

Looking at the decompilation since it’s easier to understand

So the function takes an argument a3, which is used an XOR decryption key for every bit in a1 which is the payload.

Looking at the function call we find the key is 65 or 41 in hex, now jumping into طباخ الزايبر

The decryption resulted in a PE, will leave it for now and check the last function in our program.

After loading and decrypting the resource the return value is passed to the function sub_4010EA so let’s inspect it

The function starts by creating a suspended process of svchost.exe

Then memory of size 716 bytes is allocated with MEM_COMMIT Allocation type and PAGE_READWRITE protect.

Then a thread is fetched using GetThreadContext

It loads the Ebx register in the context obtained by GetThreadContext and adds 8 to it, then the malware reads process’s memory and unmap the memory using an NT function NtUnmapViewOfSection, EBX of a suspended fresh process always contains a pointer to PEB so we have a pointer to EBX+8 I looked into the PEB structure and I found that the offset EBX+8 contains mutant which didn’t make sense why would you access a Mutex handle(or that’s what GPT told me) so I checked the PEB32 structure and it made more sense that it refers to ImageBaseAddress, just to make sure I checked the app again using PE Studio and I found it’s a 32bit app.

This routine was done to remove the suspended process from memory.

The next routine is allocating memory in the process which we read its memory using VirtualAllocEx. The function starts by allocating 50h size of memory with the protection READ_EXECUTE_READWRITE which allows read, write, and execution operation on the allocated space.
Then the function takes lpAddress which is the start of IMAGE_BASE of the IMAGE_OPTIONAL_HEADER located in the offset 34h from IMAGE_OPTIONAL_HEADER defined by the value in lpBuffer + 3C which is e_lfanew so if the value in e_lfanew is 80h then lpBuffer + 80h is the start of IMAGE_OPTIONAL_HEADER.

Finally the data is written in the process we created earlier as suspended

hope I’m not overanalysing

NOTE

I noticed later that there’s a call for [ebp+var_64] which contains NtUnmapViewOfSection returned by GetProcAddress from the previous routine, I should’ve renamed it in the screenshot but I was too lazy to redraw the annotation.

Next the data is written using WriteProcessMemory function, the size of the written data matches the size of the following:

• e_lfanew member of IMAGE_DOS_HEADER
• 4 byte signature
• size of IMAGE_FILE_HEADER
• size of optional header
• size of all section headers

which is contained in the SizeOfHeaders property in IMAGE_OPTIONAL_HEADER.

The function starts writing in lpBaseAddress of the allocated data returned from the previous routine, and it writes the MZ file we obtained from the decryption stored in [ebp+lpBuffer].

IMAGE_OPTIONAL_HEADER Sections

Looking at the structure of IMAGE_OPTIONAL_HEADER we can see it’s a bit different from our code, that’s because the COFF file header ends at the offset 18, so given that ImageBase is at 0x1C we have 0x1C + 0x18 = 0x34 and the offset of SizeOfHeaders is 0x3C so we have 0x3C + 0x18 = 0x54.

The next routine is a loop that starts by reading IMAGE_NT_HEADER + 6 which is NumberOfSections property, it iterates over the PE sections which we can deduce from the imul edx, 28h instruction as each section is 28h sized, it rewrites all sections(in our case: ) with data from the loaded resource using WriteProcessMemory. At the final iteration(edx == numberOfSections) the sample writes the loaded PE’s ImageBase into PEB.ImageBaseADdress of the hallowed process then it resumes the thread.

Verifying calculation

As the code starts by going to offset 0x3C we can see it’s the offset of e_lfanew

So we have e_lfanew contains the value E0 which is the start of NT_IMAGE_HEADER e.g: real code of the program.

As the file header ends at F6 and it has the size of WORD or 2-bytes we conclude it ends at F8

To recreate the operation we add the value of e_lfanew which is E0 to F8 which lands on offset 1D8 the start of text section.

Then the function returns 1 on success indicating the hallowing routine was done successfully.

Phew what a journey, this sample was a loader that’s sole purpose is creating a process svchost.exe and hallow it, I tried recreating the procedure in this small project, give project’s references a read and watch the last playlist(especially this it’s a must).

Checking the injected code which I won’t spend much time in.

From basic analysis we can tell it’s a keylogger

Lab12-03#

For this lab we are provided with an .exe file, let’s start by looking at strings using floss

We can see some functions that are used in user-space keyloggers.

Another indications of user-space keyloggers.

I gave the sample a quick look on PE Bear didn’t find more info so we can skip this part, let’s jump straight into IDA.

The sample starts by creating a console for its own process using AllocConsole, then it retrieves the window using FindWindow with ConsoleWindowClass parameter and hides the window using ShowWindow.

Then a handle to the current process is obtained using GetModuleHandle and a hook with WH_KEYBOARD_LL is set, the hook uses a function named fn to receive hook’s events.

In fn the function sub_4010C7 is called with a buffer parameter then the next hook is called using CallNextHookEx.

Looking at sub_4010C7 we can see it’s has keylogging logic as it creates a file named practicalmalwareanalysis.log and calls GetForegroundWindow and then GetWindowText then it calls WriteFile to write the obtained info. The function ends with a jump table that handles many inputs such as [DEL] and [CAPSLOCK].

Lab12-04#

For this lab we are provided with an .exe file, let’s start by looking at the sample’s strings using floss, I got no encoded strings however the static strings are interesting and give some clues

We can conclude from (1) that the sample is loading something from its resources, and recalling from Chapter 11 the combination of OpenProcessToken and LookupPrivilegeValue and AdjustTokenPrivileges is used to set SeDebugPrivilege for privilege escalation by giving the infected account a LocalSystem access(2).

Looking at this group of strings we can see a few IoCs \system32\wupdmgr.exe and \winup.exe. With URLDownoadToFile and the link at (3) we can tell the it does download an executable called updater.exe, we will learn the usage of all of these elements when we start advanced static analysis.

Now, let’s give it a look on PE Bear.

Looking at the imports, we don’t see anything new other than the ones floss gave out. However, I didn’t notice WinExec among the strings which is used along with URLDownloadFile to install a payload.

Looking at the resources we can see it has a PE file in the resources; will extract it using Resource Hacker and check it later.

Now let’s examine the sample in IDA.

Firstly, the program loads three functions from psapi.dll namely: EnumProcessModules, GetModulesBaseName, EnumProcesses.

Then EnumProcesses is called to grab the PIDs of all the running process in system, then a loop(1, 2) is preformed on the array of processes and each process id is passed to the function sub_401000.

Looking at sub_401000 it starts by opening the passed process and enumerate all modules, then getting the basename of a specific module that’s stored in String1.

Both String1 and String2 are defined in the function prologue, after defining the bytes as a string(by pressing A) we can see String1 is <not real> and String2 is winlogon.exe.

After renaming the two variables we can see the <not real> strings gets replaced with the value of GetModuleBaseName so the code looks if GetModuleBaseName returns winlogon.exe in other words, it looks for winlogon.exe process.

The selected process id is passed to sub_401174

The subroutine starts with sub_4010FC

Which performs privilege escalation by allowing the infected process to read data and perform operations that can be done by LocalSystem account; for more details refer to chapter 11.

The sample then loads sfc_os.dll, and gets the ordinal number 2 function which is SfcTerminateWatcherThread and it’s used to disable windows file protection.

NOTE

I got this part from the books’ answers as the ordinal in the dll was different for me

Then it opens winlogon.exe and crates a thread in it.

NOTE

If the caller has enabled the SeDebugPrivilege privilege, the requested access is granted regardless of the contents of the security descriptor.

The last part fetches the system directory C:\windows\ and then concatenate it with \system32\wupdmgr windows update manager program, it’s collected in a stack element named ExistingFileName, the same is done with a file in $TEMP\winup.exe by using GetTempPath. So it moves the file C:\windows\system\wupdmgr.exe to $TEMP\winup.exe.

The the sample continues into sub_4011FC

The subroutine loads the resource of type BIN named #101 and writes its content in-place of C:\windows\system32\wupdmgr.exe, then runs it using WinExec.

The dropped file does two things: first, it runs the file in $TEMP\winup.exe.

Then it downloads a file from http://www.practicalmalwareanalysis.com/updater.exe and places it in C:\windows\system32\wupdmgrd.exe then run it with WinExec.