We hear about “cyber attacks” in the news every week! But – what actually happens ‘during’ the attack, what happens in the background, behind the scenes, from the moment the event ‘begins’ until the moment it’s realized something is amiss? Or worse – when it’s not realized something is amiss and things continue on autopilot…
What's In It For Me
In this blog post we’ll lay down the foundations of analyzing and reverse engineering Windows malicious files. We’ll see various mechanisms malware uses to achieve their main objectives, and emphasize main key points to keep in mind for future investigations.
Already a Malware Analyst?
Already dissecting malware as you sleep?
Scroll to the end, there are 5 bullet points you should read before your next analysis.
Should I Read This Article
This article can provide an excellent first impression for those considering a career as a Malware Analyst or in Reverse Engineering in various fields.
What do these roles involve?
What background is required?
Are you genuinely interested in it, beyond the flashy descriptions of ‘high-tech salary’ and ‘catching hackers’.
The second group are professional developers.
Many developers, particularly those at the beginning of their careers or those less engaged in development within security-oriented or driver contexts, do not fully understand:
How different types of malware operate?
What are their objectives?
What are the underlying processes and mechanisms being involved.
Simply gaining knowledge of what happens behind the scenes can make you a ‘complete developer’, providing a more comprehensive vision.
A Bit Of Theory Before We Start
In general, the malware Analysis process is composed of the following 4 stages:
-
Basic Static Analysis – At this stage, we try to extract as much information as possible about the malware without executing it.
We check which strings are embedded in it (if any), which functions and DLL libraries it uses to run, whether it is Packed or not, and any other information that can give us initial clues about what the malware does.
-
Basic Dynamic Analysis – At this stage, we execute the malware to see how it runs “live” and try to extract as much information as possible using the tools at our disposal (mainly using Sysinternals, Wireshark, and others as needed).
-
Advanced Static Analysis – At this stage, we return to static analysis of the malware, but now we dive deeper into its innards.
We use tools that perform the Disassembly process (the popular ones: IDA Pro or Ghidra) to convert the malicious file – converting an exe file to a file containing assembly code that we can then analyze.
-
Advanced Dynamic Analysis – After the previous stage, we should have a relatively clear picture of what the Malware does and how it does it.
At this stage, we can fill in the missing pieces of the puzzle.
We execute the malware using Debuggers (the popular ones: x32Dbg, x64Sbg, OllyDbg, WinDbg) to identify missing parts that we couldn’t detect earlier, or to identify the value of different parameters/functions that are called dynamically, only at the time of the program’s execution.
Malware's Main Objectives
While there are various attacking actors that’s known for using various malware families, there all share the same objectives:
Gaining a foothold/persistence at the endpoint – Aka Persistence
Acquiring elevated privileges for various manipulations at the endpoint – Aka Privilege Escalation
Achieving stealth execution at the endpoint, in order to continue operating in the background without the user’s knowledge – Aka Evasion
Now we are ready to go and see some use cases for each objective, in action.
Let's Start Reversing
Basic Static Analysis
The current article, will mainly focus on the Advanced Static Analysis stage, so we will mention the details gathered in the previous stages in order to get a broad picture of our thought process, why we chose this approach, why we came to such and such hypothesis, etc.
During the Basic Static Analysis, stage, using strings.exe, we saw that the malware contains several strings.
Filtering out the uninteresting ones, we are left with:
We see that the file is somehow related to email sending services due to the use of the strings: OUTLOOK.EXE, MSIMN.EXE, and THEBAT.EXE.
Indicating processes related to Email-Exchange services. Additionally, we have a Registry Key value that might contain interesting information – we’ll check it after running the file.
The cherry on top, we see the use of AppInit_DLLs – a mechanism of Windows that allows a list of DLL files to be dynamically loaded into various processes (in User Space) – primarily implemented to achieve Persistence at the endpoint.
It’s possible that the file name we saw – spoolvxx32.dll is related in some way to achieving Persistence through AppInit_DLLs, but we need to delve deeper into the investigation to know for sure.
Basic Dynamic Analysis
Now, we advance to the Basic Dynamic Analysis stage. We execute the malware and look for:
Created/Modified Processes
Files being created/written to
Any Registry modification
By cross referencing the data we got from running: Procmon, Process Explorer and RegShot, we saw that the malware:
Opens a file called Lab11-02.ini.
Opens the file spoolvxx32.dll located at the path: C:\Windows\System32\spoolvxx32.dll
and performs an Overwrite operation on it.
Additionally, we saw that Windows API call – RegSetValue for changing a value in the Registry at the following path: HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Windows\AppInit_DLLs
which confirms our initial hypothesis about how Persistence is achieved at the endpoint.
IDA Pro, IDA Pro, IDA Pro...
Advanced Static Analysis
Last but not least, we move on to perform Advanced Static Analysis:
We begin to analyze the file after it has undergone a Disassembly process and is presented to us as assembly code.
A few lines after the main function, we see calls to the following functions:
GetModuleFileName
sub_1000105B
CreateFile
Just by analyzing these calls (and a bit of delving into the parameters they receive) we can understand the following:
The Handle to the Module (A module is a Dll or an EXE file) is loaded by the current Process and is being returned.
(A Handle is essentially a reference to a specific object/resource. Many functions return Handles so that other functions can take this Handle as a parameter and continue to access/manipulate this object/resource.)
A call is made to the function sub_1000105B – since it’s not a Windows API function but a function written by the attacker (in the high-level language in which the malware was written) it is not tagged with a string hinting at its functionality.
For convenience, I’ll reveal that it’s a function that returns the path of the system directory of the endpoint.
Then, a call is made to the function strncat which receives Source and Destination strings and performs a concatenate operation on them.
Now, a call is made to the function CreateFile, based on the parameters it receives (and with a bit of Googling on: “MSDN CreateFile” we identify that an opening of the file is performed, not a creation).
Later, a call is also made to ReadFile to read the content of the file (apparently it looks like a random collection of letters and numbers).
In addition, a call is made to another function sub_100010B3 which contains many arithmetic operations such as: XOR, AND, OR, etc… -> hints to us that probably this function performs a decoding operation on the gibberish content we saw earlier in the file -> we’ll return to it later.
Further analysis reveals the following code snippet to us:
This code snippet is another confirmation to our hypothesis about the Persistence Mechanism.
Since the malware installs itself as an AppInit_DLL for achieving Persistence, it means it will load into every User Space process!
In other words, every process that contains some kind of User Interface and uses User32.dll at the endpoint -> Will load this *.dll file to memory!
This functionality makes it difficult to remove the malware (since “all” User Space processes run the malware).
In the code snippet at the beginning of the paragraph, we essentially see that the malware copies itself to the system as spoolvxx32.dll (here comes into play the aspect of Evasion – changing its name to a more generic one, in order to make it harder for the user to identify).
Then it calls the function RegSetValue in order to install itself in the mentioned Registry Key AppInit_DLLs.
Later, we see the following code snippets:
The first three code blocks are in charge of checking whether the current running process is one of the processes we saw earlier:
OUTLOOK.EXE, MSIMN.EXE, THEBAT.EXE
(we can identify this by the string labels that IDA Pro adds for us, in addition to performing backtracking to the values passed to the registers and passed to the memcmp calls).
The last code block appears to be a User Space rootkit.
Beginning with loading the wsocks32.dll library and specifically hooking the send function call.
“Off the cuff, User space is an address space in memory where processes run with limited access permissions, while Kernel-space is an address space in memory where processes run with high permissions responsible for managing the operating system itself, computer's hardware, and among other things, managing the User space.
Rootkit – a malicious file designed to hide the existence of a malware at the endpoint. Here we see a more advanced implementation of the Evasion aspect we talked about rather than just changing the name as we discovered earlier.
(Since this code purpose is only to implement the Evasion aspect, it usually comes with another malicious file/part of a more extensive malware that implements the rest of the functionality).
Analyzing the the code right after passing the following strings: wsock32.dll and send, we see the following:
Analyzing this code snippet we see the malware:
Receives a Handle to wsock32.dll (for communication using sockets).
Calls GetProcAddress to perform Dynamic Linking (resolving and calling functions ‘dynamically’, aka as the software executes).
This loads a function in the DLL library that was previously loaded (wsock32.dll).
Finally, another call is made to the function: sub_10001203 (this function actually implements the User space Rootkit).
User Space Rootkit - We Finally Made It
In the address space between 0x10001209 – 0x10001212 (marked in yellow), we see that a calculation of some address is being made, passed to the eax register -> essentially it’s a calculation of the Jump address to which we’ll jump after the call to the send function.
In the address space between 0x10001218 – 0x10001221 (marked in green), actually a call is made to the function VirtualProtect, based on the parameters (and a search on MSDN) we understand that a change of access settings to this process’s memory is being made, in order to change the content of the code in memory of the send function.
In the address space between 0x10001253 – 0x1000126E (marked in orange), the malware saves the code that appears at the beginning of the send function and then overwrites the beginning of it with the value 0xE9.
Finally, in the address space between 0x10001274 – 0x1000127D (marked in blue) the writing of the Jump address (stored in the variable – var_4) is performed in place of the original code segment that appears at the beginning of the send function.
This, my friends, is a beautiful implementation of a User Space Rootkit, based on Hooking the send function in the dll library: ws2_32.dll.
Hooking – Hooking can be done in two main manners:
IAT Hooking – Changing only the pointer to the function that will be called
Inline Hooking – Changing the function itself, to execute malicious code
We’ll elaborate on both of these in the future
A Bit Of Theory Regarding WSock32.dll And WS2_32.dll
The wsock32.dll library serves as a Wrapper for ws2_32.dll.
A Wrapper program is an additional layer of data added that’s being added on top of the internal program, for proper operation. In other cases, the usage of wrappers may suggest the malware might be Packed and initially needs to be unpacked for analysis -> a process intended to make it harder for researchers to analyze the attacker.
Wrapping Up The Rootkit
As a conclusion from the previous stage, a process of Hooking is actually performed on the send function in the following DLL file: ws2_32.dll.
The hook is done at the Jump to the address stored in var_4.
The malware actually writes to memory the value “RCPT TO” in addition to another value extracted from the *.ini configuration file we saw that apparently contains gibberish data.
Advanced Dynamic Analysis
Performing the Advanced Dynamic Analysis stage, running the malware while monitoring its operation using the known x32Dbg Debugger we discover what is the value of the gibberish data we saw.
We place a breakpoint exactly at the address where the Decode function finishes running, after all the XOR, AND and OR… operations and just before performing the Return and moving on to the next Instruction.
We discover that it’s an email address!
Considering that the call to this function occurred after hooking into the *send* function and modifying memory with the values 'RCPT TO:', we conclude that the malware will append the recently decoded email address to every email if it originates from one of the previously identified processes (OUTLOOK.EXE, MSIMN.EXE, THEBAT.EXE) that are responsible for Email Exchange services.
So What Have We Seen
The malware uses the AppInit_DLL mechanism to achieve Persistence: forcing the malware to load into every User Space process (that loads User32.dll).
The malware uses a User Space Rootkit (the more professional term for the process we saw is called In-line Hooking) to achieve Evasion at the endpoint.
The malware manipulates email exchange related processes
Hooking the send function.
Decoding the email address extracted from the *.ini file.
Adding that address as the recipient to every email sent so that it is also forwarded to the attacker.
This way the attacker achieves access to all emails sent from the endpoint.
Overall, this was an Introduction Blog Post to analyzing Windows malicious files.
We talked about the different types of Analysis: Static and Dynamic from Basic to Advanced, and saw an example scenario showcasing the core objectives malware will try to achieve: Persistence and Evasion.
Before Your Next Analysis
Beware of assumptions without Decisive Proofs
We saw that in many cases, we could guess the purpose of a specific code snippet and in many cases also got decisive proofs that confirm the correctness of our hypothesis.
However, it’s important to note that we must find these decisive proofs!
In future malware samples we’ll review, you’ll see an increasing usage of Anti-Reverse Engineering techniques. The attacker will go to great extent to try and make you think you got it all figured out – Keep that in mind!
Reverse Engineering is a game between High-level and Low-level dissecting
A good malware analyst knows how to analyze a malware from a high-level point of view, and only dives deep down an dissects each and every instruction from a low-level point of view when needed.
Exploited libraries, files or API calls being used will change – methodologies won’t
As Windows enhances its security measures, malware authors will persist in developing increasingly sophisticated malware.
Meaning, the libraries you perceived as being potentially risky, will be replaced by others – But the methodologies will always remain the same:
Performing some sort of hooking: Whether it’s by overwriting the code, or just by altering the pointer to the code.
Performing process injection or replacement by writing malicious code to a process memory in run time.
Taking advantage of Dll files that are frequently loaded or causing them to load.
And much more…
Knowing the methodologies will help you understand the purpose and functionality way better.
Cross-referencing, Pivoting, Grouping together pieces of code
Being a good malware analyst requires a skill of ‘connecting the dots’ and knowing how to cross reference pieces of information altogether to a single chronological line.
Don’t worry, this skill is gained by experience, just keep at it.
Finally, we would say that aspiring malware analysts, should be:
Curious people by nature.
Passionate about understanding how things work behind the scenes.
Being Persistent, and able to delve into assembly code for hours (or even days).
Be eager to understand how Operating Systems work, mechanisms of network communication, Function call mechanisms, Kernel access and much more!
The most important skill in my opinion, is being able to doubt your hypotheses until you’ve found a decisive proof that they are correct -> Only thus can you truly reach a high level of professionalism in reverse engineering
So What's Next
So, from now, we are going to gear up and talk about the realm of Process Injections.
We’ll explain the main types of Process Injection techniques and see a a number of use cases where they are being implemented.
We’ll link the Process Injection techniques to one (and very central) objective malware try to obtain when infecting an endpoint.
Keep Learning and Have Fun Reversing!
References
The Malware Sample is taken from an amazing book called:
Practical Malware Analysis By Michael Sikorski and Andrew Honig
Also, the images of:
Kernel Space VS User Space
Wrapper program
Were also taken from the Practical Malware Analysis Amazing Book!
All other tips and insights come from Reverse Engineering Malware.
Looking to elevate your expertise in Mobile Security?
Offensive Mobile Reversing And Exploitation Training
4-day Live Training | Hands-on | Experienced Instructors
Learn More
</a>
</div>
</div>
</div>
<div>
<div>
<div>
<a href="https://8ksec.io/training/" rel="noreferrer" target="_blank">
All trainings
</a>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div><p>The post <a href="https://8ksec.io/dissecting-windows-malware-series-beginner-to-advanced-part-1/" rel="noreferrer" target="_blank">Dissecting Windows Malware Series – Beginner To Advanced – Part 1</a> first appeared on <a href="https://8ksec.io" rel="noreferrer" target="_blank">8kSec</a>.</p>
Article Link: https://8ksec.io/dissecting-windows-malware-series-beginner-to-advanced-part-1/?utm_source=rss&utm_medium=rss&utm_campaign=dissecting-windows-malware-series-beginner-to-advanced-part-1