Resource Section | Malware Analysis From Malware Development Part2a

“I’m Here”, Joanap said. Joanap Malware is a remote access tool and a two-stage malware the first stage is a dropper. Based on our Part 2 we will analyze the resource section APIs only.

This is my first write-up in 2020 for this malware:

My first write up for Joanap malware

But Now, We want to focus only on the resource APIs and how the real world uses them.

NOTE: This part is based on Part 1 from series one and Part 1, Part 2 from series two, So You should learn Malware Analysis before reading this.

If we open IDA Pro, then go to the imports tab to get FindResourceA API then XREF it to get the place where called.

figure(1)

The Joanap Malware searches for a resource called 101 with type RT_RCDATA and we explain in detail in part 2 why they use numbers.

Let’s use Resource Hacker Tool to find what exists in the resource section:

figure(2)

So the resource name 101 with type RT_RCDATA is an executable file [ we explain in detail PE Headers in Part 1 ].

Ok, let’s see Hex-Rays Decompiler:

figure(3)

Joanap Malware takes the Return Value of LockResource API which is a pointer to the resource in memory [ in our case is 101 as an executable ] and then passes it as a 2nd argument to WriteFile API.

So, it takes the executable from its resource to make another file. [ We will explain the details In Sha’ Allah below don’t worry ].

Let’s take the address of the WriteFile API and go to the x32 Debugger to breakpoint it:

figure(4)

Here, take the return value from LockResource API and saved it to EBP register.

figure(5)

Then, pass EBP as a buffer to WriteFile API after creating it [ we won’t analyze others ], Let’s a breakpoint in x32 Debugger before calling WriteFile API what can we see:

figure(6)

Click run

[ Be careful to take a snapshot before running any malware but in our case, it is safe because we didn’t run any malicious code ].

— — | DON’T DO IT | — —

— — | DON’T RUN ANY MALWARE BEFORE— —

— — REACHING THE MAIN FUNCTION | — —

— — | THIS IS MY ADVICE TO YOU |— —

First, You should check where the main function is called. I called The function which has Resource APIs [ MainMalware ].

figure(7)

figure(8)

Second: Xref Again the callee To know places of called function :

figure(9)

Yes, It’s the main function of the malware, and As you can see it’s GUI Malware.

figure(10)

And here is what we can see if we runed the malware in the right situation:

figure(11)

And with our friend MDSN:

DialogBoxParamA function (winuser.h) - Win32 apps

Also with Hex-Rays Decompiler:

figure(12)

With x32 Debugger:

figure(13)

we can now write the main function as in the source code:

// copied from MDSN
INT_PTR DialogBoxParamA(
  [in, optional] HINSTANCE hInstance,
  [in]           LPCSTR    lpTemplateName,
  [in, optional] HWND      hWndParent,
  [in, optional] DLGPROC   lpDialogFunc,
  [in]           LPARAM    dwInitParam
);
// our code here will be based on Hes-Rays Decompiler and x32 Debugger
int WinMain(){
  DialogBoxParam(NULL, "MAIN", 0, DialogFunc, 0);
  return 0;
}

Don’t run this code in x32 Debugger because you will run the DialogFunc function which is the executable subroutine for the Dialog.

That means when the dialog is created the DialogFunc will execute. [ We saw what is the GUI of the dialog in the resource hacker tool ].

Let’s see the DialogFunc in MDSN:

DLGPROC (winuser.h) - Win32 apps

And with Hex-Rays Decompiler:

figure(14)

X32 Debugger, go the DialogFunc and click new origin here or just click a breakpoint because the Malware runs this code anyway:

figure(15)

That’s a good action for analyzing the mainMalware function:

Let’s write this code as a malware writer:

// Copied from MDSN
DLGPROC Dlgproc;

INT_PTR Dlgproc(
  HWND unnamedParam1,
  UINT unnamedParam2,
  WPARAM unnamedParam3,
  LPARAM unnamedParam4
)
{...}

// Here is our code based on Hex-Rays Decompiler and x32 Debugger
INT_PTR DialogFunc(){
  mainMalware(); // Don't get into details

}

Let’s again set a new origin on mainMalware() function or just click breakpoint:

figure(16)

Finally, we can now run the code to get to WriteFile API.

[ Pleeeeeeeeeeeeease analyze the whole function and write a comment if you want Full Code Analysis for this function and how to get the source code ].

figure(17)

Here, for searching the resource:

figure(18)

And here after locking the resource in memory and you can dump it or save the resource from Resource Hacker Tool.

Let’s Continue:

figure(19)

The Malware creates a file called: “C:\\Windows\\system32\\scardprv.dll”

so our first IOC is: “scardprv.dll”, then

figure(20)

Then here take the buffer of the resource to this file.

Ok Ok, All of that to know what’s the file name.

Let’s back to our Code Static Analysis:

figure(21)

The Malware passes FileA as a 1st argument to WriteFile API, and FileA which created from CreateFileA API under the name PathName, Let’s see the PathName:

figure(22)

The Buffer contains the return value from GetWindowsDirectoryA API which will include %windows% Path.

Then appended to GetSystemDirectoryA API which will include %system32% Path.

so the returned Buffer will be C:\\Windows\\System32.

Then Take the Buffer the concatenated with “scardprv.dll” value with format %s\\%s and the output will be in the PathName and that means PathName will be: C:\\Windows\\System32\\scardprv.dll.

And the content of this file takes from the resource section called 101.

You can see my 2020 write-up for details and if you need a more detailed analysis, write a comment.

What Can Malware Do Now?

1. Take the resource called 101 under RT_RCDATA type.
2. Create a file called “ C:\\Windows\\System32\\scardprv.dll”.
3. Write the content of the resource to that file.
4. Create a Service included that dll. [ write a comment if you need another detailed write-up for this malware ].

We saw What can Malware Write do with the Resource Section.

Wait for Part 3 In Sha’Allah.

To Be Continued ..يتبع