Hi everyone,
Previous article: Malware Analysis #3 - Reverse engineering .NET malware
This thread just has some basic information in it that you shouldr be aware of. You may be thinking by the time you've read this thread, "that was easy" and "that was very basic" or even "I learnt nothing". However, this is the point. If you already know this information, there is no need to re-learn it. This is for very beginners for information about files etc. In the future threads, a lot more information will be unveiled. I want this thread specifically for the absolute basics, hence what I post in this thread is all I want to mention for the time being.
What you will learn in this thread and should be aware of by the end:
- What a PE file is and what PE stands for
- What a DLL stands for and what it is used for
- What a driver is
- More driver information
- What the registry is and some information about it
- How malware disables certain programs like Task Manager through the use of the registry
- How rootkits take advantage of Windows through drivers
- What Patchguard is on x64 systems
- Why 32-bit systems are more vulnerable to malware infections than people with x64 bit systems (ransomware and/or rootkit generally speaking)
- What a hook is and the different types of hooks
Is that enough for you? Let's get started!
Part 1 - What a PE file is, and what it stands for:
PE stands for Portable Executable. Portable Executable files (for example, *.exe, *.dll, *.sys, *.scr, *......) are what Windows will execute.
Part 2 - What a DLL is, and what it is used for:
DLL stands for "Dynamic Link Library". Inside of a DLL file, contains executable code. When a process uses a DLL, the DLL will be loaded into memory. It has many good uses, as listed below:
+ Multiple programs can use this DLL. This can be good if you want your code used by other applications, or if a developer wanted to use part code from another program (with permission of course).
+ Better memory usage
+ Easier project management and bug fixing - If there is a bug with code in a DLL file, you could set an update in your program to update it. This also means you won't be required to update the whole program for one bug, but just the dll file. This also makes product management easier, because it means that one part of the team can work on the GUI and the other part on the DLL/s.
Part 3 - Information about the PE file structure and obtaining PE file information
The structure in a PE file goes as the following:
1).DOS header (this will be "MZ" for example) - executable format (MZ header)
2). DOS Stub - DOS check
3). PE File Header with PE signature
4). IMAGE_OPTIONAL_HEADER
5). Section table.
If you wish to obtain information from a PE file like:
- Header information
- Characteristics information
- Magic (HDR, MajorLinkerVersion, BaseOfData, AddressOfEntryPoint, SizeOfHeaders, ...)
- Imported DLLs
- Resource information
...
You could try using pefile.net application. Tested it myself, it works. If you need instructions on using it (cannot get it to work), let me know and I'll post a thread to help you.
Part 4 - What a driver is
So you are aware, there are different types of drivers:
- Kernel-mode drivers
- User-mode drivers
The above 2 is what we will speak about in the rest of this thread and now.
Part 5 - More driver information
A driver is a (.sys) file. They can be loaded through a SERVICE as an example.
A kernel-mode driver will be loaded in ring0 (kernel mode). Having the power of what you can have in ring0 is phenomenal compared to user-mode (ring3), which is why malware writers who have drivers with their malware (rootkits for example) love it so much. They can set kernel mode hooks to do things like protect their process.
A user-mode driver will be loaded in ring3 (user mode). User mode is where all your default applications will be loaded. When a user-mode program crashes (for example, Google Chrome or Photoshop), only that program will crash and the rest of your system should work (other programs).
However, if there is a issue in a driver, since it is running in kernel mode, you will receive a BSOD crash. This is a downside of kernel mode, but it is what happens when you try and mess with that stuff.
Antivirus software especially like kernel mode drivers as it allows them to add additional protect to their processes. Since they are in kernel mode, they could set a hook to prevent termination of their process through a certain API call.
Part 6 - What is the Registry?
The Windows Registry is pretty much a massive storage which holds keys and values. Each different area in the registry and keys are for different things.
For example, let's take a look at the following key:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
This area of the registry is used by applications to have their applications started once the user logs in. Whereas, if we replace HKEY_CURRENT_USER with HKEY_LOCAL_MACHINE with the rest of the path and set it with an application, the application will be launched when any user signs in.
For additional information, I have quoted below from a Microsoft URL: What is the registry?
Part 6 - How malware disables certain programs like Task Manager through the use of the registry
Since I mentioned the Windows Registry, I thought I should mention this.
There is a key in Windows Registry (if you are running Windows 10 it may be different, you'd have to check) called DisableTaskMgr.
Now, before I can continue, I want to give you a little number explanation. In computer science/programming:
The key is located at let's say:
HKEY_CURRENT_USER\Software\Microsoft\ Windows\ Current Version\Policies\System
If the malware sample wants to disable Task Manager, all it would need is the priveleges to access the registry and the code to disable it through the value. Since the value would be 0 by default, meaning it isn't disabled (DisableTaskMgr = false), they would need to make it true.
First off, correct me if I am wrong, they would require UAC elevation unless UAC is disabled on the user account. This is one reason why you will want UAC enabled on your system.
In C++ malware sample:
There is a lot malware can do with the registry. They can mess up file permissions, disable User Account Control with the EnableLUA key, and more.
Part 7 - How rootkits take advantage with kernel mode drivers
There is A LOT rootkits, or malware can do in general, once they have successfully loaded a driver into kernel mode (AKA, ring 0). This can include preventing their process from displaying in process viewers, process protection, termination of a process (more advanced), a long with all the exclusive driver functions they have access too. Not only this, but they are trying to do something malicious... And they have most control over the system than any user-mode application will have. This means if you have a Antivirus or Antimalware product with no driver, it now has advantages over it. Even Antivirus and Antimalware products making use of ring 0 can be caught out. I've seen Emsisoft Anti-Malware be killed off by malware before, on my own Virtual Machine. It was during the Emsisoft Anti-Malware 9 beta, though. The point is, it can do a lot. I will explain some things about hiding a process below (how it would accomplish this) and more:
It could accomplish a "hidden" process with their kernel mode driver through hooking NtQuerySystemInformation. SSDT hooking, for example. I will explain what SSDT hooking is later on.
A driver mode function to terminate a process could be ZwTerminateProcess. You can actually call it from user-mode with the correct API, however best stick with NtTerminateProcess if you are calling it from user-mode.
Part 8 - Explanation on PatchGuard
PatchGuard is a exclusive feature only included on 64-bit systems. This means it is not included in 32-bit systems. The way it works is preventing a driver to be loaded (patching the kernel) (Kernel Patch Protection). Without... Being digitally signed.
Part 9 - Why 32-bit systems are more vulnerable than 64-bit systems
It is true, yes. 32-bit (x86) systems are more vulnerable than x64 systems to rootkits or malware in general which wants to load a driver. The reason being is like mentioned above, on x64 systems there is Kernel Patch Protection. Unless the driver is digitally signed, Windows will prevent the loading of the driver. If you are running a 64-bit system and doing driver development (maybe in the future, I will consider setting up threads on getting started with developing drivers (kernel and user-mode, but it will be for good use, as in security-related)), you could use a test-signature and enable Test Mode. With this, disable enforcement for drivers on boot with boot options).
Part 10 - what is a hook and some different types of hooks
I will talk about the following hooks only for now:
API hooking:
SSDT hooking:
IAT hooking:
I cut off a lot of information about Part 10, I will include more detail in the next information thread coming either tonight or SOON. Sorry, it was because this thread was already too long.
This thread is now massive and contains a huge amount of information. I wanted to add a lot more, and there are MANY other topics I wanted to cover, but so this doesn't get even bigger I will have another thread for people who want it, who have read this one, posted later or tomorrow morning. It will cover many other things, mostly about how malware works and different things it may do.
You may be wondering why I have introduced hooks. It is because in future threads soon, I will be showing you about rootkit analysis, and since rootkits use drivers to hide processes, protect processes, hide registry keys and files and also protect them, prevent things from working etc in kernel mode (and user mode info for user mode rootkits coming soon too), I thought I should teach you it. Of course, I do NOT expect you to pick up even 10% of what I said. Don't wory if that was the case for you, but everything will unveil in the future and you will then understanding.
If you read this far, congratulations. You could become the worlds best English reader, because this was a massive thread. I'm starting to wonder which one of the current Malware Analysis threads I have created are the longest threads I've ever made on this forum before. Even though this one didn't really "cover" malware analysis, some of the information people could say is fundamental, and besides, why not just learn it? To analyse and/or clean malware, you need understanding on how a malware writer thinks and how they work!
As usual, any mistakes I left, correct me to fix them. I always put this here, say on case I have made a mistake. I think I have since I got distracted a few times writing this and I was multitasking, but let me know if any!
Next tutorial in the series: Malware Analysis #5 - Covering just a tad more information
Cheers, I really hope I helped.
Previous article: Malware Analysis #3 - Reverse engineering .NET malware
This thread just has some basic information in it that you shouldr be aware of. You may be thinking by the time you've read this thread, "that was easy" and "that was very basic" or even "I learnt nothing". However, this is the point. If you already know this information, there is no need to re-learn it. This is for very beginners for information about files etc. In the future threads, a lot more information will be unveiled. I want this thread specifically for the absolute basics, hence what I post in this thread is all I want to mention for the time being.
What you will learn in this thread and should be aware of by the end:
- What a PE file is and what PE stands for
- What a DLL stands for and what it is used for
- What a driver is
- More driver information
- What the registry is and some information about it
- How malware disables certain programs like Task Manager through the use of the registry
- How rootkits take advantage of Windows through drivers
- What Patchguard is on x64 systems
- Why 32-bit systems are more vulnerable to malware infections than people with x64 bit systems (ransomware and/or rootkit generally speaking)
- What a hook is and the different types of hooks
Is that enough for you? Let's get started!
Part 1 - What a PE file is, and what it stands for:
PE stands for Portable Executable. Portable Executable files (for example, *.exe, *.dll, *.sys, *.scr, *......) are what Windows will execute.
Part 2 - What a DLL is, and what it is used for:
DLL stands for "Dynamic Link Library". Inside of a DLL file, contains executable code. When a process uses a DLL, the DLL will be loaded into memory. It has many good uses, as listed below:
+ Multiple programs can use this DLL. This can be good if you want your code used by other applications, or if a developer wanted to use part code from another program (with permission of course).
+ Better memory usage
+ Easier project management and bug fixing - If there is a bug with code in a DLL file, you could set an update in your program to update it. This also means you won't be required to update the whole program for one bug, but just the dll file. This also makes product management easier, because it means that one part of the team can work on the GUI and the other part on the DLL/s.
Part 3 - Information about the PE file structure and obtaining PE file information
The structure in a PE file goes as the following:
1).DOS header (this will be "MZ" for example) - executable format (MZ header)
2). DOS Stub - DOS check
3). PE File Header with PE signature
4). IMAGE_OPTIONAL_HEADER
5). Section table.
Additional information about DOS header:
I will open up a hex editor with a .exe file and I will show you what the DOS header is ("MZ").
Check the below screenshot:
As we can see in the above screenshot, I specifically highlighted "4D 5A". This stands for "MZ".
Additional information about DOS Stub:
Have you ever tried to open a program and been told by Windows that the file cannot be ran on DOS? This is what the DOS Stub is for. Crash management in a sense for this.
Additional information about the Section table:
In the Section table there are 5 sections. They are listed in order below:
1). .idata
2). .rsrc
3). .data
4). .text
5). .src
(lets not forget other sections like .bss, there are more).
There is also a .debug section header. After this, .text, .bss and .rdata sections in this.
I will open up a hex editor with a .exe file and I will show you what the DOS header is ("MZ").
Check the below screenshot:
As we can see in the above screenshot, I specifically highlighted "4D 5A". This stands for "MZ".
Additional information about DOS Stub:
Have you ever tried to open a program and been told by Windows that the file cannot be ran on DOS? This is what the DOS Stub is for. Crash management in a sense for this.
Additional information about the Section table:
In the Section table there are 5 sections. They are listed in order below:
1). .idata
2). .rsrc
3). .data
4). .text
5). .src
(lets not forget other sections like .bss, there are more).
There is also a .debug section header. After this, .text, .bss and .rdata sections in this.
If you wish to obtain information from a PE file like:
- Header information
- Characteristics information
- Magic (HDR, MajorLinkerVersion, BaseOfData, AddressOfEntryPoint, SizeOfHeaders, ...)
- Imported DLLs
- Resource information
...
You could try using pefile.net application. Tested it myself, it works. If you need instructions on using it (cannot get it to work), let me know and I'll post a thread to help you.
Part 4 - What a driver is
So you are aware, there are different types of drivers:
- Kernel-mode drivers
- User-mode drivers
The above 2 is what we will speak about in the rest of this thread and now.
Part 5 - More driver information
A driver is a (.sys) file. They can be loaded through a SERVICE as an example.
A kernel-mode driver will be loaded in ring0 (kernel mode). Having the power of what you can have in ring0 is phenomenal compared to user-mode (ring3), which is why malware writers who have drivers with their malware (rootkits for example) love it so much. They can set kernel mode hooks to do things like protect their process.
A user-mode driver will be loaded in ring3 (user mode). User mode is where all your default applications will be loaded. When a user-mode program crashes (for example, Google Chrome or Photoshop), only that program will crash and the rest of your system should work (other programs).
However, if there is a issue in a driver, since it is running in kernel mode, you will receive a BSOD crash. This is a downside of kernel mode, but it is what happens when you try and mess with that stuff.
Antivirus software especially like kernel mode drivers as it allows them to add additional protect to their processes. Since they are in kernel mode, they could set a hook to prevent termination of their process through a certain API call.
Part 6 - What is the Registry?
The Windows Registry is pretty much a massive storage which holds keys and values. Each different area in the registry and keys are for different things.
For example, let's take a look at the following key:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
This area of the registry is used by applications to have their applications started once the user logs in. Whereas, if we replace HKEY_CURRENT_USER with HKEY_LOCAL_MACHINE with the rest of the path and set it with an application, the application will be launched when any user signs in.
For additional information, I have quoted below from a Microsoft URL: What is the registry?
Part 6 - How malware disables certain programs like Task Manager through the use of the registry
Since I mentioned the Windows Registry, I thought I should mention this.
There is a key in Windows Registry (if you are running Windows 10 it may be different, you'd have to check) called DisableTaskMgr.
Now, before I can continue, I want to give you a little number explanation. In computer science/programming:
0 = False
1 = True
True (1) and False (0) is used in boolean values in programming.
1 = True
True (1) and False (0) is used in boolean values in programming.
The key is located at let's say:
HKEY_CURRENT_USER\Software\Microsoft\ Windows\ Current Version\Policies\System
If the malware sample wants to disable Task Manager, all it would need is the priveleges to access the registry and the code to disable it through the value. Since the value would be 0 by default, meaning it isn't disabled (DisableTaskMgr = false), they would need to make it true.
First off, correct me if I am wrong, they would require UAC elevation unless UAC is disabled on the user account. This is one reason why you will want UAC enabled on your system.
In C++ malware sample:
+ Create a variable for HKEY
+ Use RegOpenKeyEx to the registry area
+ RegSetValueEx to set the value
+ close the reg
Same really applies to any language, but that example was for C++. I was going to provide code, but then I thought: What if someone bad came along, copy pasted it and changed the value to 1 to disable it? As easy as disabling and enabling task manager is anyway, I won't do it here.
+ Use RegOpenKeyEx to the registry area
+ RegSetValueEx to set the value
+ close the reg
Same really applies to any language, but that example was for C++. I was going to provide code, but then I thought: What if someone bad came along, copy pasted it and changed the value to 1 to disable it? As easy as disabling and enabling task manager is anyway, I won't do it here.
There is a lot malware can do with the registry. They can mess up file permissions, disable User Account Control with the EnableLUA key, and more.
Part 7 - How rootkits take advantage with kernel mode drivers
There is A LOT rootkits, or malware can do in general, once they have successfully loaded a driver into kernel mode (AKA, ring 0). This can include preventing their process from displaying in process viewers, process protection, termination of a process (more advanced), a long with all the exclusive driver functions they have access too. Not only this, but they are trying to do something malicious... And they have most control over the system than any user-mode application will have. This means if you have a Antivirus or Antimalware product with no driver, it now has advantages over it. Even Antivirus and Antimalware products making use of ring 0 can be caught out. I've seen Emsisoft Anti-Malware be killed off by malware before, on my own Virtual Machine. It was during the Emsisoft Anti-Malware 9 beta, though. The point is, it can do a lot. I will explain some things about hiding a process below (how it would accomplish this) and more:
It could accomplish a "hidden" process with their kernel mode driver through hooking NtQuerySystemInformation. SSDT hooking, for example. I will explain what SSDT hooking is later on.
A driver mode function to terminate a process could be ZwTerminateProcess. You can actually call it from user-mode with the correct API, however best stick with NtTerminateProcess if you are calling it from user-mode.
Part 8 - Explanation on PatchGuard
PatchGuard is a exclusive feature only included on 64-bit systems. This means it is not included in 32-bit systems. The way it works is preventing a driver to be loaded (patching the kernel) (Kernel Patch Protection). Without... Being digitally signed.
Part 9 - Why 32-bit systems are more vulnerable than 64-bit systems
It is true, yes. 32-bit (x86) systems are more vulnerable than x64 systems to rootkits or malware in general which wants to load a driver. The reason being is like mentioned above, on x64 systems there is Kernel Patch Protection. Unless the driver is digitally signed, Windows will prevent the loading of the driver. If you are running a 64-bit system and doing driver development (maybe in the future, I will consider setting up threads on getting started with developing drivers (kernel and user-mode, but it will be for good use, as in security-related)), you could use a test-signature and enable Test Mode. With this, disable enforcement for drivers on boot with boot options).
Part 10 - what is a hook and some different types of hooks
I will talk about the following hooks only for now:
API hooking:
API hooking can be accomplished by e.g. DLL injection. To do this you will require to get the address of the function you wish to hook, overwrite the function you wish to hook, inject the DLL into the process address space... You may at one point wish to modify the IAT table...
Of course you can accomplish API hooking from kernel mode, too. I actually prefer Kernel Mode hooking. Especially, if you wanted to accomplish things like process protection from hooking NtTerminateProcess.
Of course you can accomplish API hooking from kernel mode, too. I actually prefer Kernel Mode hooking. Especially, if you wanted to accomplish things like process protection from hooking NtTerminateProcess.
SSDT hooking:
SSDT stands for System Service Descriptor Table.
SSDT hooking is not available on 64-bit systems.
SSDT hooking is not available on 64-bit systems.
IAT hooking:
IAT hooking stands for Import Address Table (IAT) hooking. You can use it to intercept calls to APIs imported and this would be done through the use of injection, which will be explained in the next thread I mentioned about at the end of here.
I cut off a lot of information about Part 10, I will include more detail in the next information thread coming either tonight or SOON. Sorry, it was because this thread was already too long.
This thread is now massive and contains a huge amount of information. I wanted to add a lot more, and there are MANY other topics I wanted to cover, but so this doesn't get even bigger I will have another thread for people who want it, who have read this one, posted later or tomorrow morning. It will cover many other things, mostly about how malware works and different things it may do.
You may be wondering why I have introduced hooks. It is because in future threads soon, I will be showing you about rootkit analysis, and since rootkits use drivers to hide processes, protect processes, hide registry keys and files and also protect them, prevent things from working etc in kernel mode (and user mode info for user mode rootkits coming soon too), I thought I should teach you it. Of course, I do NOT expect you to pick up even 10% of what I said. Don't wory if that was the case for you, but everything will unveil in the future and you will then understanding.
If you read this far, congratulations. You could become the worlds best English reader, because this was a massive thread. I'm starting to wonder which one of the current Malware Analysis threads I have created are the longest threads I've ever made on this forum before. Even though this one didn't really "cover" malware analysis, some of the information people could say is fundamental, and besides, why not just learn it? To analyse and/or clean malware, you need understanding on how a malware writer thinks and how they work!
As usual, any mistakes I left, correct me to fix them. I always put this here, say on case I have made a mistake. I think I have since I got distracted a few times writing this and I was multitasking, but let me know if any!
Next tutorial in the series: Malware Analysis #5 - Covering just a tad more information
Cheers, I really hope I helped.
Last edited by a moderator:
