Hi everyone,
Previous article: Malware Analysis #4 - Lots of information, maybe more than you need
What you will learn in this thread and should be aware of by the end:
- What DLL/Code injection is, how it works, and how it can cause issues
- How malware can do DLL injection
- How rootkits or malware in general would protect their process from termination
- What a kernel mode callback is
- How the browser can be attacked
- What MBR stands for
Part 1 - What DLL/Code injection is, how it works, and how it can cause issues
Covering DLL information:
Covering Code injection:
Part 2 - How malware can do DLL injection:
Part 3 - How rootkits/malware would protect their processes from termination (protected process):
While there are quite a bit of techniques going around on how you would protect a process, I will note down 2 from the top of my head.
Kernel-mode method:
User-mode method:
Part 4 - Understanding what a kernel-mode call back is
I don't want to go too in-depth with this as we are not developing a driver... Or for now, maybe one day I'll make a series on driver development for security tool development...
But, think of it like a notification. Register a callback routine and you get notified about it in the driver.
When you want to do kernel mode hooking in x64, an alternative to SSDT hooking which is not available on x64 would be using kernel mode callbacks. And you would use it with a function like NtTerminateProcess. Then, once the driver has been notified of this you would compare the process being called to be terminated in the API call to your process and then if it is your process you would prevent the action with e.g. STATUS_ACCESS_DENIED being returned back to the original requester.
That is a pure, plain and very simple explanation of mine for it. I used the example from a malware writer's perspective, as they may want to "protect" their process on x64.
Part 5 - How the browser can be attacked
Glad I'm on Part 5 now, I have wanted to explain this for awhile now, as some people may be unsure and not know how it works, however I do know for a fact many people on ths forum most likely know how a browser is attacked and the behind-the-scenes of how it's done.
What I will mention in this topic:
- How malware changes the homepage of browsers
- How malware changes the search provider of browsers
How does malware change the homepage of browsers:
This action may change depending on the browser. I will include Internet Explorer and Google Chrome for this part of #5.
I will quickly note that if malware injects into the browser, it can steal information such as: usernames and passwords, banking information, browser history and bookmarks, settings, etc.
Part 6 - What MBR stands for
MBR stands for the Master Boot Record. The Master Boot Record is a boot sector and it's location is the first sector on a hard disk. It's responsible for locating the Operating System for it to be loaded.
The boot sector must be 512 bytes.
Soon I will make a thread within the next few days with analysis on the MBR, showing you what a "modified MBR" looks like once malware/viruses have attacked it, how to fix those issues, also.
--
As usual, anything which is incorrect, let me know so I can fix it. I always say this say on case I do make a mistake. It's better than me pretending everything is 100% accurate, because if someone then found a issue or something incorrect that would be silly of me.
More threads on using analysis tools are on the way with the upcoming week, and more threads in general... Share the knowledge.
Next guide in series: Malware Analysis #6 - Understanding packers and detecting a packed file
Cheers.
Previous article: Malware Analysis #4 - Lots of information, maybe more than you need
What you will learn in this thread and should be aware of by the end:
- What DLL/Code injection is, how it works, and how it can cause issues
- How malware can do DLL injection
- How rootkits or malware in general would protect their process from termination
- What a kernel mode callback is
- How the browser can be attacked
- What MBR stands for
Part 1 - What DLL/Code injection is, how it works, and how it can cause issues
Covering DLL information:
What DLL injection is:
When a process injects a DLL into another process (attaches to address space), it will alter it's behaviour by executing the code in that DLL. (basically forces the process to execute the code in the DLL).
How it works:
So you have a process and you want it to do something, so you inject the DLL in which it will execute the code you wrote in the DLL.
How it can cause issues:
You have a program which is holding sensetive information. Malware injects a DLL into this program and retrives the information. It then transfers this information to the hacker. The hacker now has the sensetive information that you did not want him to have.
That was one example, I will write some more below:
- The injected DLL could prevent certain aspects of the program to function correctly
- The injected DLL, hence executing code, can cause unexpected actions. For example, unwanted events being executed on the users PC.
Malware writers usually achieve DLL injection with the following method, however I won't be showing you how to actually code this (because then a malware writer can just use it as a base line, this is information to help you understand malware and how it works, not make malware altogether with every part) - well maybe in the future I will make code public on the forum which will inject a DLL into the target process and report back some actions it does (for good use, malware analysis):
- Use OpenProcess() API on the target process.
- Use VirtualAllocEx which will allow you to allocate the memory for the DLL to be inserted into.
- WriteProcessMemory() which will allow you to transfer (copy) the DLL over. - LoadLibraryA.
- Cause the process to execute the code in this DLL through the use of creating a Remote Thread. I will include NtCreateThreadEx() and RtlCreateUserThread here.
Of course there are other ways it could inject a DLL into a process. Like, the malware writer might have taken advantage of App_Init registry key, also.
The above is all you really need to know. Maybe it's even more than what you need to know... Unless you are a programmer learning Malware Analysis to make tools also, the above information is optional. However, you should still know how it all works so you know when you are analysing malware.
When a process injects a DLL into another process (attaches to address space), it will alter it's behaviour by executing the code in that DLL. (basically forces the process to execute the code in the DLL).
How it works:
So you have a process and you want it to do something, so you inject the DLL in which it will execute the code you wrote in the DLL.
How it can cause issues:
You have a program which is holding sensetive information. Malware injects a DLL into this program and retrives the information. It then transfers this information to the hacker. The hacker now has the sensetive information that you did not want him to have.
That was one example, I will write some more below:
- The injected DLL could prevent certain aspects of the program to function correctly
- The injected DLL, hence executing code, can cause unexpected actions. For example, unwanted events being executed on the users PC.
Malware writers usually achieve DLL injection with the following method, however I won't be showing you how to actually code this (because then a malware writer can just use it as a base line, this is information to help you understand malware and how it works, not make malware altogether with every part) - well maybe in the future I will make code public on the forum which will inject a DLL into the target process and report back some actions it does (for good use, malware analysis):
- Use OpenProcess() API on the target process.
- Use VirtualAllocEx which will allow you to allocate the memory for the DLL to be inserted into.
- WriteProcessMemory() which will allow you to transfer (copy) the DLL over. - LoadLibraryA.
- Cause the process to execute the code in this DLL through the use of creating a Remote Thread. I will include NtCreateThreadEx() and RtlCreateUserThread here.
Of course there are other ways it could inject a DLL into a process. Like, the malware writer might have taken advantage of App_Init registry key, also.
The above is all you really need to know. Maybe it's even more than what you need to know... Unless you are a programmer learning Malware Analysis to make tools also, the above information is optional. However, you should still know how it all works so you know when you are analysing malware.
Covering Code injection:
What Code injection is:
Think of it a bit like DLL injection, just without the DLL. It basically injects code into the process, meaning the process will execute the injected code.
How it can cause issues:
So you are on a program which has sensetive information: could be banking, account information... The attacker injects code, and once you filled in the information you click OK not being aware code had been injected. Instead of what was meant to happen, this information was stolen by the attacker. But, you don't know. Then it creates a fake error message to trick you and shuts down the program.
Sounds like a pain, right? Truth is, it is a pain, and can leave a horrible mess.
Think of it a bit like DLL injection, just without the DLL. It basically injects code into the process, meaning the process will execute the injected code.
How it can cause issues:
So you are on a program which has sensetive information: could be banking, account information... The attacker injects code, and once you filled in the information you click OK not being aware code had been injected. Instead of what was meant to happen, this information was stolen by the attacker. But, you don't know. Then it creates a fake error message to trick you and shuts down the program.
Sounds like a pain, right? Truth is, it is a pain, and can leave a horrible mess.
Part 2 - How malware can do DLL injection:
Part 3 - How rootkits/malware would protect their processes from termination (protected process):
While there are quite a bit of techniques going around on how you would protect a process, I will note down 2 from the top of my head.
Kernel-mode method:
Kernel-mode driver is loaded (of course, ring 0/kernel-mode since it's a kernel mode driver...). The driver will hook functions like NtTerminateProcess and return what I will say as ACCESS DENIED. This is more complicated than it seems, quite simple for people with so much experience at making drivers to do this.
On 64-bit systems, the malware writer would need to make use of kernel-mode call backs, considering SSDT hooking isn't available on 64-bits.
Therefore, if they took this approach, if you attempted to Terminate the process on Process Hacker, Task Manager,... You will have a returned error message, telling you "Access Denied". This is where this error evolves from. It is returned from a driver back to the process which called the API to terminate the process, and the API call it cancelled from continuing to exit the process it originally wanted to terminate.
Not only malware uses this approach. Antivirus software can also take this approach. In fact, some do. However, it won't make the process "unkillable" from everything. Just from NtTerminateProcess, so if the malware writer wanted to go even more advanced, they would need to do more and cover more options for the process to be ended. They usually also hide the process, which helps prevent it being caught out in task managers in the first place (can be achieved through hooking on NtQuerySystemInformation, which I previously mentioned in one of these threads whilst mentioning Rootkits).
On 64-bit systems, the malware writer would need to make use of kernel-mode call backs, considering SSDT hooking isn't available on 64-bits.
Therefore, if they took this approach, if you attempted to Terminate the process on Process Hacker, Task Manager,... You will have a returned error message, telling you "Access Denied". This is where this error evolves from. It is returned from a driver back to the process which called the API to terminate the process, and the API call it cancelled from continuing to exit the process it originally wanted to terminate.
Not only malware uses this approach. Antivirus software can also take this approach. In fact, some do. However, it won't make the process "unkillable" from everything. Just from NtTerminateProcess, so if the malware writer wanted to go even more advanced, they would need to do more and cover more options for the process to be ended. They usually also hide the process, which helps prevent it being caught out in task managers in the first place (can be achieved through hooking on NtQuerySystemInformation, which I previously mentioned in one of these threads whilst mentioning Rootkits).
User-mode method:
The malware loops through each process running on the system and injects the DLL into the targetted process. The DLL they had developed will hook functions and basically prevent it from ever being able to terminate their process.
Part 4 - Understanding what a kernel-mode call back is
I don't want to go too in-depth with this as we are not developing a driver... Or for now, maybe one day I'll make a series on driver development for security tool development...
But, think of it like a notification. Register a callback routine and you get notified about it in the driver.When you want to do kernel mode hooking in x64, an alternative to SSDT hooking which is not available on x64 would be using kernel mode callbacks. And you would use it with a function like NtTerminateProcess. Then, once the driver has been notified of this you would compare the process being called to be terminated in the API call to your process and then if it is your process you would prevent the action with e.g. STATUS_ACCESS_DENIED being returned back to the original requester.
That is a pure, plain and very simple explanation of mine for it. I used the example from a malware writer's perspective, as they may want to "protect" their process on x64.
Part 5 - How the browser can be attacked
Glad I'm on Part 5 now, I have wanted to explain this for awhile now, as some people may be unsure and not know how it works, however I do know for a fact many people on ths forum most likely know how a browser is attacked and the behind-the-scenes of how it's done.
What I will mention in this topic:
- How malware changes the homepage of browsers
- How malware changes the search provider of browsers
How does malware change the homepage of browsers:
This action may change depending on the browser. I will include Internet Explorer and Google Chrome for this part of #5.
Internet Explorer stores it's setings in the registry. Let's take a quick peek and I can explain how malware will change the homepage of IE.
Of course you don't have to browse the registry, you can just continue reading and learn... (DON'T CHANGE ANY VALUES and mess SOMETHING UP!)
Open up regedit: WinKey + R (When the RUN dialog appears, type in regedit and hit enter). - you may be prompted by UAC. Allow it.
Navigate too > HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main
You should see a key there called "Start page" as the name, and the value will be your homepage. (it's near the bottom). My value is set to the google search engine, meaning when I open up Internet Explorer, I will be prompted with Google.
If the malware sample has the correct priveleges (if UAC is enabled, it should be required for registry access), it can change the value in the Start Page, changing the IE homepage.
They can also change other values there, like Local Page, Search Page, FullScreen, Show_StatusBar, Play_Animatons, UseClearType and so on.
Of course you don't have to browse the registry, you can just continue reading and learn... (DON'T CHANGE ANY VALUES and mess SOMETHING UP!)
Open up regedit: WinKey + R (When the RUN dialog appears, type in regedit and hit enter). - you may be prompted by UAC. Allow it.
Navigate too > HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main
You should see a key there called "Start page" as the name, and the value will be your homepage. (it's near the bottom). My value is set to the google search engine, meaning when I open up Internet Explorer, I will be prompted with Google.
If the malware sample has the correct priveleges (if UAC is enabled, it should be required for registry access), it can change the value in the Start Page, changing the IE homepage.
They can also change other values there, like Local Page, Search Page, FullScreen, Show_StatusBar, Play_Animatons, UseClearType and so on.
Google Chrome stores it's settings in a file. Malware can attack this file by changing information in it. I will look more into this and provide more detail in the future. I will be going in-depth about Google chrome protection and extensions, so I will mention this when the time comes.
I will quickly note that if malware injects into the browser, it can steal information such as: usernames and passwords, banking information, browser history and bookmarks, settings, etc.
Part 6 - What MBR stands for
MBR stands for the Master Boot Record. The Master Boot Record is a boot sector and it's location is the first sector on a hard disk. It's responsible for locating the Operating System for it to be loaded.
The boot sector must be 512 bytes.
Soon I will make a thread within the next few days with analysis on the MBR, showing you what a "modified MBR" looks like once malware/viruses have attacked it, how to fix those issues, also.
--
As usual, anything which is incorrect, let me know so I can fix it. I always say this say on case I do make a mistake. It's better than me pretending everything is 100% accurate, because if someone then found a issue or something incorrect that would be silly of me.
More threads on using analysis tools are on the way with the upcoming week, and more threads in general...
Share the knowledge. Next guide in series: Malware Analysis #6 - Understanding packers and detecting a packed file
Cheers.
Last edited by a moderator:
