DEV Community

Cover image for Architecting a Custom Purple Team Infrastructure Scanner in Go.
Mohamed
Mohamed

Posted on

Architecting a Custom Purple Team Infrastructure Scanner in Go.

#go #security #devsecops #purpleteam

By Mohamed Medjahdi — Security Engineer & DevSecOps Specialist

As a Security Engineer, one of the most frustrating bottlenecks in Purple Teaming is the sheer noise and lack of orchestration when simulating attacks. You find yourself gluing together subfinder, nuclei, httpx, and a dozen other tools using fragile bash scripts.

When I needed a way to automate misconfiguration detection and simulate real threat actor reconnaissance across complex cloud infrastructures, I realized bash wasn't going to cut it. I needed concurrency, state management, and real TLS interception.

So, I built OmniScan—an advanced offensive security suite written entirely in Go.

(Note: I am actively preparing the OmniScan repository to be open-sourced on my GitHub account very soon!)

🏗️ Why Go? The Architecture of OmniScan

When building a scanner that needs to handle thousands of endpoints, parse DOMs via headless browsers, and intercept HTTPS traffic simultaneously, performance is non-negotiable.

I chose Go (Golang) for OmniScan primarily for its elegant concurrency model (goroutines/channels) and its ability to compile into a single static binary.

OmniScan is not just a wrapper; it's split into two core engines:

  1. The Crawler Engine: An asynchronous web crawler (built on colly) with JavaScript endpoint extraction and Cloudflare bypass capabilities.
  2. The Pipeline Orchestrator: A DAG (Directed Acyclic Graph) execution engine that orchestrates external tools via YAML configurations.

The Pipeline Engine (DAG Orchestration)

Instead of piping tools in bash, OmniScan users define attack chains in YAML.

name: "Smart Recon + CVE Hunt"
steps:
  - name: subdomain_scan
    type: subfinder
    config:
      threads: 50
    output_as: subdomains

  - name: live_filter
    type: simple_probe
    depends_on: [subdomain_scan] # Waits for subdomains
    config:
      targets_from: subdomains
    output_as: live_hosts
Enter fullscreen mode Exit fullscreen mode

Under the hood, OmniScan parses this YAML, validates dependencies, and builds topological batches. Steps that don't depend on each other run concurrently using Go's sync.WaitGroup.

graph TD
    A[Target: example.com] --> B(subfinder)
    B --> C(httpx / simple_probe)
    C --> D(techFinder - Headless Chrome)
    C --> E(nuclei - Smart CVE Scan)
    D --> F(Results JSON/HTML)
    E --> F
Enter fullscreen mode Exit fullscreen mode

🕵️‍♂️ Deep Tech Detection with techFinder

One of the standout features I engineered for OmniScan is the techFinder module. Standard fingerprinting relies on HTTP headers and simple regexes, which modern applications easily obscure.

To solve this, I wrote a separate Go module (techFinder/) that spins up a headless Chrome browser. It inspects the actual DOM, evaluates JavaScript variables, and intercepts network requests to identify WAFs, JavaScript frameworks (like React/Vue), and backend services.

Because launching headless browsers is resource-intensive, techFinder runs in a controlled Process Group, ensuring that when the main context times out or is cancelled, all orphaned Chrome instances are cleanly killed via syscall.SIGKILL.

🛡️ True MITM: The authscan Intercepting Proxy

Automating Privilege Escalation (PrivEsc) and Insecure Direct Object Reference (IDOR) testing is notoriously difficult. OmniScan tackles this by shipping with a real TLS-intercepting MITM proxy.

The authscan package generates a local Certificate Authority (CA) on the fly (omniscan-ca.pem). When you route your browser through OmniScan (./omniscan proxy -l :8888), it issues on-the-fly certificates for target hosts.

Here is a simplified look at how OmniScan handles sessions for automated IDOR checks:

// Simplified snippet from OmniScan's authscan module
func (s *IDORScanner) ScanEndpoint(target string, method string) []core.Result {
    // 1. Fetch resource with High Privileged Session
    highReq := s.buildRequest(target, s.sessions.Get("high"))
    highResp := s.client.Do(highReq)

    // 2. Attempt to fetch same resource with Low Privileged Session
    lowReq := s.buildRequest(target, s.sessions.Get("low"))
    lowResp := s.client.Do(lowReq)

    // 3. Analyze diffs (Status codes, Content-Length, DOM structure)
    if s.isVulnerable(highResp, lowResp) {
        return []core.Result{{Type: "IDOR", Severity: "HIGH", URL: target}}
    }
    return nil
}
Enter fullscreen mode Exit fullscreen mode

[!WARNING]
Destructive method tampering (PUT, DELETE, PATCH) is strictly gated behind an explicit --allow-destructive flag in OmniScan to ensure safe defaults during automated testing.

🤖 Next Steps: Integrating AI & Open Sourcing

Building OmniScan has drastically reduced the time I spend on manual reconnaissance and false-positive filtering during Purple Team engagements.

My next focus is integrating Local LLMs directly into the reporting pipeline to automatically analyze complex DOM structures and generate natural language attack narratives for stakeholders.

I am finalizing the documentation and will be open-sourcing the entire OmniScan v2.0 suite on my GitHub shortly.

If you are a DevSecOps engineer, penetration tester, or just love Go, keep an eye on my GitHub and follow me here for the release!

Follow me on LinkedIn to chat about Cloud Security, GCP, and AI Automation.

Top comments (0)