How I Found a $5,500 Bug Using Just Reconnaissance
嗯,用户让我帮忙总结一篇文章,控制在一百个字以内。首先,我需要仔细阅读文章内容,抓住主要信息。 文章讲的是一个安全研究人员通过被动侦察和子域名枚举发现了内部仪表盘的配置文件,从而获得了5500美元的漏洞赏金。他强调了侦察的重要性,而不是直接攻击。 用户的要求是用中文总结,不需要特定的开头,直接描述内容。所以我要确保在100字以内涵盖关键点:被动侦察、发现内部仪表盘、配置文件暴露、赏金数额以及侦察的重要性。 接下来,我需要组织语言,确保简洁明了。可能的结构是:研究人员通过被动侦察发现漏洞,获取赏金,并强调侦察的重要性。 最后检查字数,确保不超过限制。这样就能满足用户的需求了。 </think> 一位安全研究人员通过被动侦察和子域名枚举发现某公司内部仪表盘的配置文件暴露了生产凭证、数据库访问权限及AWS密钥,最终获得$5,500漏洞赏金。 2025-12-25 14:39:8 Author: infosecwriteups.com(查看原文) 阅读量:4 收藏

Codi

Most bug hunters rush straight to exploitation techniques.
Flashy payloads, complex attacks, advanced tools.
But my biggest bug bounty payout came from something much simpler: patient observation.

Press enter or click to view image in full size

Photo by Fotis Fotopoulos on Unsplash

Let me show you how reconnaissance — often seen as the boring first step — became the entire game.

Defining the Battlefield

The program was for a large tech company (let’s call them “TechFlow Inc.”).
Their scope was clear: *.techflow-example.com.
Bounties ranged from $500 to $10,000.

My goal wasn’t to attack anything.
It was to understand their digital footprint completely.
This is where passive recon and subdomain enumeration always begin.

My Reconnaissance Methodology Walkthrough

Phase 1 — Discovery: Mapping the Territory

My toolkit for this phase is straightforward:

  • Amass and Subfinder for subdomain discovery
  • crt.sh for certificate transparency logs
  • waybackurls for historical data

One command to start:

subfinder -d techflow-example.com -silent | httpx -silent > subs.txt

Over 800 subdomains were gathered.
Most were typical: www, blog, api, staging.

But one stood out like a quiet signal in the noise:

internal-dashboard.techflow-example.com

Why would an “internal” dashboard be publicly accessible?
Curiosity was officially piqued.

Phase 2 — Probing & Validation:

First, life check:

echo "internal-dashboard.techflow-example.com" | httpx -title -status-code

Result: 200 OK with title “TechFlow Internal Panel”.

Next, DNS check:

dig A internal-dashboard.techflow-example.com

No CDN detected.
This was hitting their origin server directly — already a questionable find.

Phase 3 — Content Discovery

Time for light directory checking with ffuf:

ffuf -u https://internal-dashboard.techflow-example.com/FUZZ -w ~/wordlists/common.txt -t 50

Within seconds:

/admin-config.json          [Status: 200, Size: 512]

My heartbeat might have skipped.
Configuration files in an admin Directives are rarely good news.

A Critical Configuration Exposure

Navigating to that URL revealed a JSON file left wide open:

{
"database": {
"host": "prod-db.techflow-internal.net",
"username": "admin_prod",
"password": "T3chFl0w2023!Secure?"
},
"aws_keys": {
"access_key": "AKIAEXAMPLEKEY",
"secret": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
},
"environment": "production"
}

This wasn’t just information disclosure — this was exposed secrets in their most dangerous form.

Get Codi’s stories in your inbox

Join Medium for free to get updates from this writer.

Why was a critical vulnerability:

  1. Production credentials were publicly accessible
  2. Database root access was potentially compromised
  3. AWS keys could lead to cloud resource takeover
  4. Compliance violation for data protection standards

The impact was immediate and severe.
And I hadn’t run a single exploit — just observation.

The Reporting & Reward

I stopped all testing immediately.
Ethical disclosure means finding, not exploiting.

My report structure:

  1. Clear title: “Public Exposure of Production Credentials via Internal Dashboard.”
  2. Affected asset: https://internal-dashboard.techflow-example.com/admin-config.json
  3. Evidence: Masked screenshots and code blocks
  4. Impact analysis: Business risk assessment
  5. Recommendation: Rotate all exposed secrets immediately

48 hours later, the triage team responded:

Confirmed as a critical security misconfiguration. The file has been removed, and all affected credentials have been rotated. Thank you for your responsible disclosure.

Award: $5,500.

The earnings were substantial, but the validation was better:
Methodical reconnaissance works.

Lessons Learned (The Real Treasure)

  1. Reconnaissance > Exploitation for early-stage bug hunting
    The quiet phase often reveals the loudest findings.
  2. Forgotten assets are low-hanging fruit
    Old subdomains, backup files, and “internal” systems are routinely overlooked.
  3. You don’t need to exploit to earn
    Finding and responsibly reporting is enough — and it’s safer for everyone.
  4. Documentation is part of the methodology
    Clear reports with business impact get faster triage and better rewards.

My Go-To Reconnaissance Toolkit

  • Subfinder/Amass — Subdomain discovery
  • httpx — HTTP probing and validation
  • ffuf — Directory and content discovery
  • crt.sh — Certificate transparency searches
  • waybackurls — Historical endpoint gathering

Each tool has one job.
Together, they build a complete picture.

The Quiet Truth About Bug Hunting

Reconnaissance is often skipped because it feels passive.
No immediate gratification.
No complex techniques.

But here’s the secret:
The most valuable findings are often just waiting to be discovered.

That “boring” first step?
It’s where the real bug bounty gems are hidden.


文章来源: https://infosecwriteups.com/how-i-found-a-5-500-bug-using-just-reconnaissance-2768fdba5ff2?source=rss----7b722bfd1b8d--bug_bounty
如有侵权请联系:admin#unsafe.sh