Note: When reading this, it may seem a bit long because it contains my personal emotions, so just enjoy reading it and don't get bored, haha.

I still remember the first time I saw people getting "Congratulations" emails or Hall of Fame mentions from NASA.

Not gonna lie — it looked unreal.

At that time, I was very new in cybersecurity. I didn't come from a fancy background, no elite lab, no secret techniques. Just curiosity, lots of reading, and many late nights scrolling Medium.

I thought to myself:

"Maybe… just maybe… I can try too."

Even if I fail, I knew it would still be a valuable first experience.

How I Found the Door: Bugcrowd

After digging around, I noticed that most people who got acknowledged by NASA didn't just randomly hack things. They reported through Bugcrowd — a platform that acts as a bridge between hackers and companies.

So I signed up, opened the NASA Vulnerability Disclosure Program, and started reading everything:

• Scope
• Rules
• Allowed targets
• What's in scope, what's not
• etc

And then… I froze.

The number of valid reports submitted to NASA was massive.

At that moment I honestly thought:

"Okay, this might be impossible. NASA has been tested by tens of thousands of reports of hackers before me."

But then I remembered something a senior hacker once said:

"There is no such thing as a perfectly secure system."

That sentence stuck with me.

So instead of overthinking, I decided to try.

Learning From Others Before Touching Anything

Before doing any testing, I did something important:

👉 I read a lot of Medium write-ups from great hackers.

I tried to understand:

1. How they think

🎯 Impact-first mindset

"If this is affected, what is the impact on users/business?"

🧠 Assumption breaker

"Developers think this is safe — I prove otherwise."

📉 Effort vs reward

Find bugs that are easy to validate and difficult to reject.

2. How they approach targets

Usually the sequence is like this:

A. Surface mapping

• Login, reset password, upload, API, redirect, export

B. Trust boundary

• Trusted parameters are too large (returnUrl, redirect, callback)

C. State-based logic

• Auth, role, permission, workflow

D. Low-noise testing

• Minimal payload, but clear impact

Not spam payload, but:

"What is this parameter used for in the backend?"

3. Why they choose certain vulnerabilities

IDOR, Access control bypass, Account takeover, Sensitive data exposure (.zip, .bak, Endpoint via API, etc), Business logic flaw

And from all those stories, one topic caught my attention more than anything else:

Information Disclosure

Why?

Because I found it interesting how companies can protect their systems extremely well — firewalls, WAFs, authentication, monitoring — but sometimes forget a small path they don't consider dangerous.

And often, that forgotten path is… 📁 files.

A Different Way of Thinking

At some point, I changed my mindset completely.

Instead of asking:

"How do I hack NASA's system?"

I asked:

"What does NASA do every day?"

The answer was simple.

They manage a LOT of files.

Documents, reports, plans, logs, PDFs — especially for missions, research, and operations.

Then another thought hit me:

"If hacking the system is almost impossible… why not look at what they produce every day?"

Discovering Government File Restrictions

While learning more about how US government agencies handle documents, I found something very interesting:

-LABEL / DOCUMENT CLASSIFICATION-

Here are example labels

Confidential

Strictly Confidential

Highly Confidential

Company Confidential

Private & Confidential

Restricted

For Authorized Personnel Only

Not for Public Distribution

Do Not Distribute

Do Not Share

For Intended Recipient Only

Internal Use Only

Sensitive

Private

Proprietary

Company Use

Internal Document

Draft (Internal)

Draft

Unofficial

Sample

Training Material

For Reference Only

So basically, LABEL / DOCUMENT CLASSIFICATION is categorized into two types, namely for the government and the private sector. Although there are similar categories, such as "internal use only," not all of them are there. For example, "internal use only" is usually only found in the government sector, while it is rarely found in the private sector because it is usually closed. And in the private sector, usually… ahem, find it yourself XD.

Example of Google Dork

ext:csv | ext:xls | ext:xlsx | ext:ini | ext:log | ext:doc | ext:docx | ext:pdf ( "Internal Use Only" ) site:*.domain.gov

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Long story short, I found a file labeled "internal use only" on their main domain. I was shocked and asked if it was sensitive. Then I looked at the contents, most of which were related to costs and money in one of their projects. Without further ado, I immediately made a report and sent it to the Bugcrowd platform.

At first, I was happy because they did triage directly by Bugcrowd staff and they communicated with NASA staff to conduct a more in-depth check. After waiting for a while, they gave an unresolved notification, which essentially said that this information was a valid bug.

After that, I will definitely be happy, then calm down and take a break for a moment and return to normal life while waiting for the letter to arrive, because if the status is unresolved, it will automatically be valid and the letter will arrive.

waiting for the report results and reward, but something undesirable happened

At that time, there was a government shutdown in the USA. I reconfirmed whether there had been any updates, and they said they couldn't update because of the situation. A few days later, they were able to announce something like this.

It came after I woke up (I always check for any updates from them when I wake up). I felt like I had fallen into a deep hole, but someone pushed me. I felt lethargic, weak, and shocked. I didn't expect to receive news like this, because it was impossible for the "unresolved" label to suddenly be canceled and replaced with "not applicable," and that's what they said.

I tried to contact them to ask "why?", but there was still no result. I was deeply disappointed by that.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Although that almost made me not want to do it again, I still believed (no system is safe) that it was real, so I tried to resolve to do it again.

and I won't look for another scope but will still try to use that method again but with a different concept.

I was initially confused about what other labels might be sensitive, because I had already tried nearly 100 labels but none were sensitive. With nearly 1,000 files that I check every day, I was almost desperate when I wanted to try.

until finally I found this valuable information

So basically, the US government has a way of labeling their documents to distinguish between non-sensitive (Distribution Statement of A) and sensitive (B, C, D, E, F, etc.) information.

With this information, I tried to search their domain once again.

Long story short, I used Google Dork + that information to find out if NASA also had information labeled that way.

ext:csv | ext:xls | ext:xlsx | ext:ini | ext:log | ext:doc | ext:docx | ext:pdf ( "Distribution Statement of B/C/D/E/F" ) site:*.domain.gov

And to my surprise, I found the document on one of their subdomains

It didn't require valid authentication, no login, no fuss, anyone could open it.

What happen?

This issue occurs due to improper document handling and access control at the system level. The sensitive files were hosted on a publicly accessible government web server without any authentication, authorization checks, or network restrictions in place. Because the server allowed unrestricted public access and did not prevent search engine indexing (such as through robots.txt or no-index headers), search engines were able to crawl and index the documents. As a result, unauthorized external users who are not part of the intended distribution group were able to discover and download restricted documents through standard search queries, without bypassing any security controls or exploiting the system.

So. this is Information Disclosure, because The document is publicly accessible without authentication and indexed by search engines, leading to sensitive information disclosure. (Not BAC, IDOR, etc)

Reference: https://portswigger.net/web-security/information-disclosure

My heart was racing like a roller coaster, and without thinking twice, I reported the document to them.

And I didn't have to wait long. They then triaged my report, and I waited for further notification. Less than a day later, they verified it and changed the notification to unresolved.

I was happy, but I couldn't be 100% happy, because remembering what had happened before, I couldn't be happy until they gave me the letter.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

No need to wait 1 month later, I finally got this comment.

My heart rate immediately increased again. I finally received this letter, and they declared this bug to be completely valid :D

A few days later, they closed the URL.

That's all, thank you for your guys attention :D

My advice:

1. Always look for information that you think is valuable to find more vulnerabilities.

2. Don't always trust "unresolved" notifications for file discovery cases. XD :D

3. Learn the differences between sensitive and non-sensitive files.

4. If you find a response after they report "not applicable" but you believe it is sensitive, request a reassessment because it is usually their bot.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

How to create a report?

Actually, creating a report is easy, as long as you explain your findings in detail and describe the real impact. I understand that many of our reports are rated "not applicable" by them, and that's definitely because of the bot. I'm sure it's because they are rated based on the username and the time they give notifications (because it's definitely outside their working hours).

Check the "Technical Severity — The Vulnerability Rating Taxonomy" section when you try to report it. Once you've determined the scope name, you'll automatically receive a sample report format from them. If you're still unsure about the appropriate scope in "Technical Severity — The Vulnerability Rating Taxonomy," you can ask ChatGPT to determine the suitable scope name.

For my case (Information Disclosure), you can name it Sensitive Data Exposure > Disclosure of Secrets > For Internal Asset with P3

If you are unsure how to write the description, you can use this format.

1. Overview of Exposure (Example Format)

During testing, a document classified as internal-only was discovered to be publicly accessible on a government-owned domain. The file was hosted on a publicly reachable web server and could be accessed directly without any form of authentication or authorization.

The document itself was clearly labeled with a restricted distribution notice, indicating that it was not intended for public release. However, despite this restriction, the file was indexed and accessible through normal web requests.

This situation represents a common form of information disclosure, where sensitive internal assets are unintentionally exposed due to misconfiguration or lack of access control.

2. Evidence of Restricted Distribution (Generic Example)

The document contained an explicit distribution notice on its first page, specifying that access is limited to authorized government entities and approved contractors only.

Such distribution statements are commonly used by government organizations to control the circulation of internal or operational documents. The presence of this notice confirms that the document should not be publicly accessible, even if the content is not classified.

Type of Information Involved (High-Level, Non-Sensitive)

Without discussing specific details, the exposed document contained operational and internal information, such as:

• System or data-flow descriptions
• Internal processing or handling procedures
• Infrastructure or component roles
• Operational workflows
• Backup or redundancy concepts

Information like this is typically intended for internal reference only and should not be available to the general public.

Impact Assessment (Educational Version)

Public exposure of internally restricted documents can lead to several risks, including:

• Unintended disclosure of internal system design
• Increased attack surface due to revealed architecture patterns
• Insight into operational workflows that were not meant to be public
• Potential misuse of internal knowledge for targeted attacks

Even when a document is not classified, distribution restrictions still matter, and public access violates standard information-handling policies.

Proof of Concept (Methodology Only)

The issue was identified using passive discovery techniques, without exploiting any system or bypassing security controls.

A common approach includes:

• Searching for publicly indexed files
• Filtering by document types
• Looking for keywords associated with restricted or internal usage
• Verifying whether access is possible without authentication

Once a restricted document is found, simply opening it in a browser is sufficient to confirm the exposure.

No authentication, no exploitation — just publicly available access.

then upload the evidence like record how you find it, image or something else.

Key Takeaway for New Researchers

This type of report demonstrates that:

• Not all vulnerabilities involve complex exploitation
• Information disclosure can exist even in highly secured environments
• Public files and forgotten endpoints are often overlooked
• Proper reporting focuses on impact and policy violation, not just technical flaws

For beginners, this is a great example of how careful observation and understanding policy can be just as powerful as advanced technical skills.

#HallofFrame #CyberSecurity #Nasa #Vulnerability Disclosure Program

#BugBounty