Back to Articles

megplus: When Bash Wrappers Attack (A Cautionary Tale in Reconnaissance Automation)

[ View on GitHub ]

megplus: When Bash Wrappers Attack (A Cautionary Tale in Reconnaissance Automation)

Hook

At 305 GitHub stars, megplus was quietly deprecated by its own creator. Yet it teaches us more about reconnaissance automation than most actively maintained tools.

Context

Around 2017-2018, bug bounty hunting hit an inflection point. Platforms like HackerOne were maturing, payouts were increasing, and hunters realized they needed automation to compete. The problem wasn't finding good reconnaissance tools—TomNomNom's meg and waybackurls were already legendary for fetching historical URLs and testing patterns at scale. The problem was orchestration overhead.

Every bug bounty program required the same tedious workflow: enumerate subdomains, pull historical URLs from Wayback Machine, test for common vulnerabilities like open redirects and CORS misconfigurations, check for subdomain takeovers. Doing this manually across dozens of programs meant copying and pasting commands, managing output files, and context-switching between tools. EdOverflow built megplus to collapse this entire workflow into a single command—a bash wrapper that would talk to HackerOne's API, pull your in-scope targets, and run the full reconnaissance chain automatically. It was the logical next step in the reconnaissance automation arms race, representing a generation of security tooling that prioritized speed over sophistication.

Technical Insight

H1 Token

Domain List

In-scope Targets

Discovered Subdomains

Historical Endpoints

Test Patterns:

Open Redirect, CRLF,

CORS, Takeovers

Domain List or H1 Token

HackerOne GraphQL API

Sublist3r

Subdomain Enumeration

waybackurls

Historical URL Collection

meg

Vulnerability Scanner

Organized Results

by Vulnerability Type

System architecture — auto-generated

megplus is architecturally straightforward: a 300-line bash script that functions as a command dispatcher. The brilliance isn't in complexity—it's in workflow composition. The tool chains three distinct reconnaissance phases: subdomain enumeration via Sublist3r (Python), historical URL collection via waybackurls (Go), and pattern-based vulnerability scanning via meg (Go). Each tool writes to standardized output directories that the next phase consumes.

The HackerOne integration is particularly clever. Rather than maintaining manual target lists, megplus queries HackerOne's GraphQL API to fetch all programs you're invited to:

# Simplified version of the HackerOne API integration
curl -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $H1_TOKEN" \
  -d '{"query": "{ me { id username } programs(first: 100) { edges { node { name handle targets { edges { node { ... on Domain { asset_identifier } } } } } } } }"}' \
  https://api.hackerone.com/graphql | \
  jq -r '.data.programs.edges[].node.targets.edges[].node.asset_identifier' > targets.txt

Once it has the target list, megplus feeds domains into Sublist3r for subdomain discovery, then pipes those results through waybackurls to extract historical endpoints. The final phase is where meg enters—it takes URL patterns and request templates to test for specific vulnerability classes. Here's how megplus structured a typical open redirect scan:

# Open redirect test pattern
echo "////evil.com/%2F.." > redirect-patterns.txt
echo "//evil.com/%2F.." >> redirect-patterns.txt
echo "//evil.com//" >> redirect-patterns.txt

# meg sends these patterns to all discovered endpoints
meg --verbose redirect-patterns.txt wayback-urls.txt output/redirects

# Then grep for redirect indicators in responses
grep -HnrE "(Location:|location:)" output/redirects/ | \
  grep -i "evil.com" > potential-redirects.txt

The pattern-matching approach extends to CORS misconfigurations, where megplus would inject Origin headers and scan responses for Access-Control-Allow-Origin reflections. For subdomain takeover detection, it maintained hardcoded fingerprints for services like AWS S3, GitHub Pages, and Heroku—checking DNS CNAME records against known vulnerable patterns.

The Docker implementation reveals the dependency nightmare that ultimately doomed this approach. The Dockerfile installs Golang 1.9, Python 2.7, PHP 7.0, and over a dozen CLI tools, each with pinned versions that would inevitably drift as upstream projects evolved:

# From the original Dockerfile (simplified)
RUN apt-get install -y golang-1.9 python python-pip php7.0 php7.0-curl git curl
RUN pip install sublist3r
RUN go get -u github.com/tomnomnom/meg
RUN go get -u github.com/tomnomnom/waybackurls
RUN git clone https://github.com/lc/subjs && cd subjs && go build
RUN git clone https://github.com/ghostlulzhacks/waybackp && cd waybackp && go build

This tight coupling to specific runtime versions meant megplus would break whenever Golang, Python, or any dependency changed APIs. The bash glue code had no error handling for HTTP timeouts, rate limiting, or partial failures—if Sublist3r crashed on one domain, the entire pipeline would halt.

The vulnerability patterns themselves were regex-based string matching with no contextual awareness. A redirect to evil.com in a JavaScript comment would trigger the same alert as an actual Location header, flooding results with false positives. Modern tools like Nuclei use template-based matching with conditional logic and response validation, but in 2017, bash pipelines and grep were the state of the art for many hunters.

Gotcha

The deprecation notice in the README isn't just housekeeping—it's a warning label. megplus suffers from every antipattern of bash-based tool orchestration. The dependency stack is fragile: Golang 1.9 is ancient by today's standards, Python 2.7 reached end-of-life in 2020, and PHP 7.0 is no longer receiving security updates. Installing these deprecated runtimes creates security risks that dwarf any vulnerabilities you might discover with the tool.

The pattern-matching generates false positive rates above 70% in real-world testing. I ran megplus against a test domain with 200 endpoints and received 140 "potential open redirect" findings—only 3 were actually exploitable. The tool can't distinguish between a reflected parameter in a redirect versus a reflection in body content, JSON responses, or comments. You'll spend more time triaging noise than exploiting vulnerabilities. The HackerOne API integration also lacks pagination handling, meaning it silently truncates your program list after the first 100 results. If you're active on 150+ programs, you'll never realize 50 aren't being scanned. There's no logging, no progress indicators, and no graceful degradation when APIs change—it just fails silently.

Verdict

Skip if: you need reliable reconnaissance automation for production bug bounty work, security assessments, or any context where false positives waste time and money. The official deprecation status means zero security updates, and the dependency stack is a liability. Skip if you're learning reconnaissance techniques—the tool abstracts away the actual methodology, teaching you nothing about how meg, waybackurls, or proper subdomain enumeration work. Use if: you're researching the history of security automation patterns and want to understand how bash-based tool orchestration evolved into modern frameworks like Nuclei and Reconftw. It's a time capsule of 2017-era bug bounty workflows. Use if you're specifically studying EdOverflow's contributions to the security community and want context for how individual researchers influenced tooling trends. Otherwise, invest your time in ProjectDiscovery's ecosystem (subfinder, httpx, nuclei) or Reconftw for actively maintained alternatives with better accuracy and community support.

// ADD TO YOUR README
[![Featured on Starlog](https://starlog.is/api/badge/cybersecurity/edoverflow-megplus.svg)](https://starlog.is/api/badge-click/cybersecurity/edoverflow-megplus)