Welcome to Offensive Security Tooling Development
You’re about to embark on a journey that will transform you from a security practitioner into a tooling developer - someone who doesn’t just use existing tools, but builds new ones. This course teaches you to create sophisticated post-exploitation frameworks, evasive implants, and custom security tools using Go.
But before we write a single line of code, you need to understand the landscape you’re entering. This lesson answers critical questions:
- What types of offensive tooling exist, and why?
- How do red team and penetration testing tools differ?
- What career paths exist for offensive tooling developers?
- What legal and ethical boundaries must you respect?
- How have post-exploitation frameworks evolved?
- What industry trends are shaping the future?
By the end of this lesson, you’ll understand:
- The offensive security tooling ecosystem and market landscape
- Career opportunities and specializations available to you
- Legal frameworks governing offensive security work
- Evolution from Metasploit to modern C2 frameworks
- Current industry trends and emerging techniques
- How existing tools work and why they’re designed as they are
This foundational knowledge informs every technical decision you’ll make throughout this course. Let’s begin.
PART 1: THE OFFENSIVE TOOLING LANDSCAPE
Understanding the Ecosystem
The offensive security tooling ecosystem is vast, diverse, and constantly evolving. Tools exist along multiple axes: commercial vs open-source, general-purpose vs specialized, stealthy vs noisy, and more.
┌──────────────────────────────────────────────────────────────┐
│ OFFENSIVE SECURITY TOOLING TAXONOMY │
├──────────────────────────────────────────────────────────────┤
│ │
│ BY PURPOSE │
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ │
│ • Reconnaissance (nmap, masscan, shodan) │
│ • Initial Access (phishing frameworks, exploit kits) │
│ • Exploitation (Metasploit, Exploit-DB PoCs) │
│ • C2/Post-Exploitation (Empire, Mythic, Cobalt Strike) │
│ • Lateral Movement (Impacket, CrackMapExec, BloodHound) │
│ • Persistence (SharPersist, custom backdoors) │
│ • Exfiltration (DNSExfiltrator, custom tools) │
│ │
│ BY LICENSE MODEL │
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ │
│ • Commercial ($$$): Cobalt Strike, Core Impact, Canvas │
│ • Freemium: Burp Suite (free/pro), OWASP ZAP │
│ • Open Source: Metasploit, Empire, Sliver, Mythic │
│ • Internal/Custom: Bespoke tools for specific engagements │
│ │
│ BY DETECTION PROFILE │
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ │
│ • Noisy: Metasploit (well-signatured, widely detected) │
│ • Moderate: Empire, Covenant (some signatures) │
│ • Stealthy: Custom tools, heavily obfuscated payloads │
│ • Living-off-the-Land: PowerShell, WMI, native binaries │
│ │
│ BY IMPLEMENTATION LANGUAGE │
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ │
│ • C/C++: Low-level control, maximum evasion potential │
│ • C#: .NET ecosystem, in-memory execution, CLR abuse │
│ • PowerShell: Native on Windows, scriptable, LOLBin │
│ • Python: Rapid development, large ecosystem, interpreted │
│ • Go: Cross-compilation, single binary │
│ • Rust: Memory safety, performance, growing adoption │
│ │
└──────────────────────────────────────────────────────────────┘
Red Team vs Penetration Testing Tooling
The tools you build depend on your mission. Red team and penetration testing operations have fundamentally different requirements:
Penetration Testing Tools
CHARACTERISTICS
- Time-boxed engagements (1-4 weeks typically)
- Goal: Find as many vulnerabilities as possible
- Detection is acceptable (client knows you’re testing)
- Speed and coverage matter more than stealth (in general, not always true)
- Comprehensive reporting required
- Breadth over depth
TOOL REQUIREMENTS
- Fast scanning and enumeration
- Wide vulnerability coverage
- Automated exploitation when possible
- Clear, detailed logging for reports
- Multiple protocol support
- Integration with reporting tools
Red Team Tools
CHARACTERISTICS
- Long-duration operations (weeks to months)
- Goal: Achieve specific objectives (data access, persistence)
- Must remain undetected (simulating real adversaries)
- Stealth and operational security critical
- Mimics APT tactics, techniques, and procedures
- Depth over breadth
TOOL REQUIREMENTS
- Low detection profile (AV/EDR evasion)
- Operational security features (encrypted C2, fail-safes)
- Long-term persistence mechanisms
- Flexible, modular capabilities
- Realistic adversary simulation
- Minimal forensic footprint
Comparison Matrix
| Aspect | Penetration Testing | Red Teaming |
|---|---|---|
| Duration | Days to weeks | Weeks to months |
| Detection | Acceptable | Must avoid |
| Scope | Defined targets | Entire organization |
| Approach | Systematic, comprehensive | Targeted, stealthy |
| Tools | Off-the-shelf, automated | Custom, manual |
| Success Metric | Vulnerabilities found | Objectives achieved |
| Reporting | Detailed technical findings | Strategic insights |
Why This Matters for Tool Development
When you build a tool, you must ask: “Is this for pentesting or red teaming?”
- Pentesting tool: Optimize for speed, coverage, reporting.
- Red team tool: Optimize for stealth, OpSec, flexibility. Detection = failure.
This course focuses on red team tooling, which is in general technically harder and teaches more foundational concepts.