Original subtitles

This is part 2 of our malware development series, go ahead and watch part 1 first, if you haven’t

already to get the most out of this video. Leet cipher: hey sed, what the hell you

doin'? NOOOOOOO!!! Leet cipher: why,

why did you do that??? Sed: I didn't know it's

going to work the first time. Leet cipher: It did, and now

all of my projects are gone. Sed: I'm sorry, man!

Leet cipher: You know what, that's it, I had enough of

your s**t...

Hey there passwiper77, I read a comment of yours

on a YouTube video claiming that the saturnians have the most advanced

quantum forensics tools, do you know a way with which I can reach out to them?

Regards, Leet cipher

Hi eet cipher,

Please, do not email me in English, I only understand Japanese.

Regards, Passwiper77

Hey there a**wiper77,

I don't care if you understand English or not just use Google translate you stupid motherf@$k3#

Leet cipher:

Hey sed, wake up, we're going to space. Sed: what is it?

Leet cipher: we're going to space Sed: what for?

Leet cipher: To fix your f**k up Sed: Alright, let's go!

Hahaha, didn't know that saturnian jokes are that funny. Alright guys thanks a

lot for everything. Safe travels. Goodbye. Anyways, let’s start this video up and talk about

DLLs, but before that, I just want to mention that some of you told me that I work for the FBI or I’m

an undercover FBI agent and all of that, well... Sed: hey leet I found your badge

Hey, wtf...I believe, we didn’t get the FBI’s attention so far,

but I’m pretty sure by the end of this series, we will be on their watchlist,

so watch your backs. FBI OPEN UP!!! Anyways, Alright, now, first things first,

let’s talk about DLLs, DLL is an abbreviation for “Dynamic link library”, A DLL is like a special

file that contains code and data that programs can use. If you happen to work on big coding projects,

most of the time, you’ll find yourself writing a function or a block of code repeatedly in your

app, and since we have to follow the “dry” or “don’t repeat yourself” principle in programming,

we take these functions and put them in a separate file so whenever we need them we

can just include them and that’s all. DLLs work the same way, you can think of it as

a collection of mini-programs or functions that can be shared among larger programs.

Also keep in mind that a DLL is also considered a portable executable, we can confirm that by

examining the “DOS” header in a hex editor for both an executable such as “calc.exe”

and a DLL file like “kernel32.dll”. We can see that they both share the same exact

“DOS” header. But still if we run the file command on “calc.exe” and “kernel32.dll”,

we can see that “clalc.exe” is identified as “GUI” executable and “kernel32.dll” is identified as a

DLL, but if that’s the case then how does the operating system differentiate between the two?

Knowing that they both share the same dos header. Well, if we load those two files in a “pe” parser

tool like “pe bear”, we can see in the “File Header” section, the “characteristics” member has

an additional flag set for “kernel32.dll” which is “File is a DLL”, so whenever the operating system

loads a portable executable, it first checks the “characteristics” member to determine whether

this file is a “DLL” or a normal “executable”. This is just a quick explanation so that you

don’t get confused when you see a DLL file has the same header as a portable executable file.

From here, we will be talking about stuff such as the windows api and the structure

of the memory space inside running processes, so I highly recommend that you first watch the

previous video in which I explained these concepts in detail and then come back here.

Now, to understand how DLL injection works, we first need to understand how an executable

loads DLLs at runtime. When a process is run or executed, the operating system dynamically links

all the necessary DLLs that the process will need at runtime. These DLLs contain the windows APIs

that the process needs for its functionality. We can use a tool such as process hacker to

confirm that by inspecting the loaded DLLs in the memory space of a running process.

Everything so far until here is legit and nothing is suspicious with it. Now,

if we want to abuse this behavior, we will have to first create a malicious DLL and inject it

into the memory space of the target process. But we still have a problem though, you see,

all of these loaded DLLs, the process uses them for its functionality and if that's the case,

how are we supposed to execute our malicious code that is inside this DLL, if the target

process is not using any code at all from it? Well, there are 4 DLL callbacks that we can

abuse to execute code. “DLL_PROCESS_ATTACH”, “DLL_PROCESS_DETACH”, “DLL_THREAD_ATTACH” and

“DLL_THREAD_DETACH”. These are called callbacks or I would rather say event listeners. If you happen

to work with an awesome programming language such as javascript, you’re probably familiar

with event listeners such as “onclick, onhover, ondrag, ondrop…etc”. These event listeners listen

for the event to occur and then execute code accordingly. For example, we can add an “onclick”

event listener on a certain button in a web page which when clicked the code here is executed.

The same thing goes for these 4 callbacks or event listeners. The “DLL_PROCESS_ATTACH” event

is triggered when the DLL is loaded or injected into the memory space of a certain process, The

“DLL_PROCESS_DETACH” event is triggered when the DLL is unloaded or freed from the memory space of

a certain process, The “DLL_THREAD_ATTACH” event is triggered when a thread is created after the

DLL is loaded. And lastly the “DLL_THREAD_DETACH” event is triggered when a thread is terminated.

Will go through each callback in detail and how to execute it with code, just in

case you didn’t understand the process here, but before that let’s first create our DLL.

Our quote and quote malicious DLL here is fairly simple,

in the “DLLMain” function which is similar to the main function in a standard C program,

we check which callback was invoked, and in each of the four callbacks or event listeners

we discussed, we call the “MessageBox” Windows API with a different message to

indicate which callback was triggered. Make sure to set the compile mode to

release and the architecture to x64, same as our DLL injector which we will create next.

Alright, now, similar to the previous video, we will first inject this DLL into the memory space

of our local process and after that, we’ll get nerdier and inject it into the memory space of

any running process of our choosing, sounds good? Sounds great, alright, good, let’s do

this. Alright, sed, bring out the code, not this one, the other one, the other other one, the other

other other one, there you go, well done, you can go now, I’ll take it from here, still can see you,

anyways, this code is fairly simple to understand, we first include the windows header to be able to

use WinAPI functions in our code. Again, we talked about the windows API in detail in the

previous video, so, please, go and watch that one first so that you can see the bigger picture here.

next the “stdio” header for input and output operations. Here we have four windows APIs that

make this local injection happen, first, we use the “LoadLibrary” API to load our malicious DLL

into the memory space of our process from disk. If the call succeeds, it will trigger the

“DLL_PROCESS_ATTACH” callback which executes our malicious code or the “MessageBox” API in

this case. Now, to trigger the next callback which is the “DLL_THREAD_ATTACH” we use the

“CreateThread” API. Basically, the idea here is that in order to trigger this callback,

we need to create a thread that does absolutely anything, and for that we use the “CreateThread”

API and we pass to it a dummy function such as this one, if this API runs successfully,

the second “MessageBox” API will be executed. The last two callbacks are fairly simple,

we just need to wait till the thread terminates and then we unload or free our malicious DLL.

So to trigger the “DLL_THREAD_DETACH” callback, we use the “WaitForSingleObject” API, this API

halts the execution flow of the program until the specified thread returns or terminates, once the

thread terminates, the callback will be triggered and its “MessageBox” API will run. Finally, we use

the “FreeLibrary” API to unload our malicious DLL and trigger the last callback. We can even

comment out this API since the process will free all loaded modules or DLLs when it’s about to

terminate which will trigger this callback for us. Now, before you run this program, make sure

the architecture is the same as the malicious DLL then build the solution in release mode. After the

build is complete, run the program and give it the full path to the malicious DLL. We can see here

our malicious DLL is loaded and the first callback is triggered, and we can even confirm that our

malicious DLL is residing in the memory of our process by inspecting the loaded modules inside

its memory space using process hacker. Moving on, we can see the rest of the callbacks are

executed successfully without any issues, just, you know, legit stuff as usual. NEXT! COME ON!

Alright, cool, now, before we proceed to create our DLL Injector, we need to understand the

difference between two Windows APIs, “LoadLibrary” and “GetModuleHandle”, both of these APIs return a

handle to a specified module or DLL, you might be asking now, if that’s the case that means,

I can replace this “LoadLibrary” API with “GetModuleHandle” and the code will still

work just fine, right? Well, no, it’s not going to work. What “LoadLibrary” does is that it loads a

DLL from Disk and takes care of some stuff behind the scenes such as resolving the Import Address

Table, and once it’s done, it returns a handle to the loaded DLL. “GetModuleHandle” on the other

hand, just looks for the specified DLL in the list of the loaded DLLs in the process memory, if the

DLL is found, it returns a pointer to the DLL base address, which is what we call a handle. So here,

we used “LoadLibrary” because our malicious DLL is loaded from disk straight to the process memory.

This is yet not the best way to load a malicious DLL into memory, because most of the time, all of

these APIs are hooked and monitored by security solutions. To get around this we would use a

technique called “Reflective DLL” which loads a malicious DLL straight from memory, but that’s

a bit advanced and I don’t want to overwhelm you with any more details. So now, Oh, crab, I forgot

to write the code. You know what, just give me like 5 minutes and I’ll be done, this is jus...

Alright, this is the code that makes the functionality for our DLL Injector.

It takes 2 parameters, the full path to our malicious DLL and the process id into which

this DLL will be injected. Let’s assume that we will inject into mspaint or microsoft paint. We

can obtain its process id by using a tool such as process hacker or any similar tool,

or we can do the same thing we did in the previous video which is to take a snapshot of all running

processes and search for mspaint and retrieve its process id if it’s found. I didn’t implement that

here to reduce the complexity of the code and only focus on the core functionality of this

DLL Injector. But you can do this yourself as homework, but do not copy and paste anything.

Write the whole thing from scratch and implement the processes enumeration functionality and pick

another process to inject into like notepad or something. Anyways, let’s now visualize

what will happen in the memory when this code is executed rather than explaining it line by line.

So, imagine this is the memory map of microsoft paint. First things first, we get a handle

to this process using the “OpenProcess” API, this api takes in three parameters:

the desired access to process object or the access rights we want to have over the process,

Since we want access to all process resources, we use the “PROCESS_ALL_ACCESS” flag.

The second parameter takes in a boolean value, and we set it to “TRUE” if we want

to make the child processes created by our process inherit this handle,

and since we’re not going to create any, we set it to “FALSE”. The third parameter is the process

id which we want to access, which in our case here will be the process id of mspaint. After

this handle is obtained, we use it to allocate memory using “VirtualAllocEx”, this API takes in

5 parameters, the process handle, the base address of the block of memory that we want to allocate,

since we don’t know exactly where should we allocate this block of memory, will let the

operating system do that for us by setting this parameter as “NULL”, the size of the memory that

we want to allocate and it’s set to the size of the DLL path plus one, the extra byte here is

just for the terminating null byte of the string. Next parameter is the allocation type. I explained

this parameter in great detail in the previous video if you want to see the full explanation,

but in a nutshell, all what this parameter does is that it tells the operating system to let us

write to this block of memory. Last parameter is the page permissions, since we only want to read

and write to this block of memory, we set it to “PAGE_READWRITE”. After our memory is allocated,

we use “WriteProcessMemory”, this api takes in five parameters: the handle to the “microsoft

paint” process, a destination to write to, a source to copy or read from, the size of the

copied data and the “number of bytes read” if the function succeeds, will just set that one

to “NULL” since it’s not that important. Alright, now, we have successfully written the full path

of the DLL into the allocated memory inside the “mspaint” process. What we need to do now, is to

load the actual DLL into the memory space of this process, and yes, you guessed right, we can do

that by using the “LoadLibrary” API, but the real question here, how can we force this process to

execute “LoadLibrary” for us? Well, the answer is pretty simple, we just need to obtain the virtual

address of the “LoadLibrary” API inside the memory space of the “mspaint” process. We first need to

figure out which DLL has the “LoadLibrary” API. From Microsoft documentation, we can see that it

resides in the “kernel32” DLL. So now, we get a pointer to the base address of the “kernel32” DLL

using the “GetModuleHandle” API as we demonstrated before, once we have the base address of this DLL,

we need to know the exact virtual address of the “LoadLibrary” API relative to the base address

of the “kernel32” DLL, or in plain english, we need to know how far is the “LoadLibrary” API

from the beginning of the “kernel32” DLL since it has a ton of other APIs in it. So for that,

we use the “GetProcAddress” API, this API takes in 2 parameters, the base address of the DLL and

what API to look for. This API will do some magic and return the virtual address of the specified

API. It’s not really magic, it will just access something called the “export directory” within

the DLL and look up the export table to retrieve the address of the API. But we can call it magic

for now, just for the sake of simplicity. You’re now might be like: wait a second,

the virtual address returned by “GetProcAddress” is the virtual address of the “LoadLibrary” API

but only within the address space of our “dll-injector” process, will this address

(of the “LoadLibrary” API) be the same within the address space of the “microsoft paint” process,

since we will create a thread to run this API within its address space? The answer is yes,

the addresses are identical in both processes. The reason for that is because the windows operating

system knows that this “kernel32” file is a DLL file. So, it just loads it somewhere in memory

and makes it accessible by all processes that might need it, without the need to re-allocate

each DLL for each running process, which in return saves much computing time and increases

performance. We can confirm that a DLL such as “kernel32” is loaded in the same virtual address

by checking the loaded modules for any 2 processes using the “process hacker” tool. So now, since we

are certain that we have the right virtual address of the “LoadLibrary” API, we just need to create

a remote thread to execute this API within the “microsoft paint” process, and for that,

we use the “CreateRemoteThread” API, this API takes in 7 parameters, will set all parameters

to the default values except for 3, the process handle, the address of the function to be run by

the thread and the parameter that will be passed to the function. So essentially, what is actually

happening here is that the thread that will be created, will execute the API in this address

which in this case is the “LoadLibrary” API and we pass to it the allocated memory that stores the

full path to our DLL as a parameter. This typecast as demonstrated before in the previous video,

converts this address to an entry point address or in simple words, tells the created thread

that this address is the start of the code that must be executed. Now, the last thing we

need to do is to wait for the thread to finish execution using the “WaitForSingleObject” API,

this API takes in the handle to the thread and how long to wait for the thread to return, we set that

to “INFINITE” since we want to completely halt the execution flow until the thread returns. After it

returns, we close the handle to the process using “CloseHandle”. After building this solution, you

will find the executable in “x64” then “Release”. I already went ahead and copied our malicious DLL

in the same directory along with our DLL Injector. Now, open a command prompt, make sure microsoft

paint is running to obtain its process id using “process hacker” and then run the DLL Injector and

supply to it, the name of the DLL and the process id. Running this, we can see the DLL callbacks

were triggered. We can even force the program to trigger the “DLL_THREAD_ATTACH and DETACH”

callbacks by using any functionality in the program that would create a thread such as opening

a file or a new window. Finally, once the program is terminated, our malicious DLL will be freed and

the “DLL_PROCESS_DETACH” callback is triggered. You can also find where exactly our DLL is loaded

in memory by checking the modules of the “mspaint” process using process hacker. So yeah, that

concludes our DLL Injector, we did it, everyone. Now, As an exercise or homework for you,

I want you to implement the whole thing from the ground up and add to it the process enumeration

functionality, so that when you run it, you supply the process name instead of the process id,

and if you get stuck, just watch the previous video. You’ll find the code along with the

executables in my github, link in the description below. I also wanted to apologize for my absence

for the past 6 to 7 months. This video should have been up way sooner thatn that, I promise,

there was a lot I mean a lot going on in my life, but hopefully now things are settled,

and I’m already working on the next video which is going to be really on fire, so watch out for

this one. In the previous video, I told you let’s get to 10k and now, we’re over 30, so yeah, that’s

really great, but you still need to subscribe though, especially, when over 95% of you guys

aren’t, so yeah, subscribe really really I mean it like like you need to subscribe now, so please

subscribe. If you made it this far, umm thank you, I really appreciate you,

you’re awesome, you’re my hero. If this content was beneficial to

you in any way and learned a thing or two from it, you can buy me a coffee and keep the show

going. It’s only one man with his computer. Lastly, I want to thank my saturnian friends

for restoring my projects and files. Really don’t know what I would do without you guys. Perhaps,

I’ll start by replacing you, Sed: me?

yeah you, I’m getting a new assistant, maybe someone with a higher IQ level than yours,

or maybe, I can shoot you again now, so that you don…wait, where’s my gun?

sed: you’re looking for this. No, wait, no, NOOOOOOOOOOOOOOOOOOO.