Oct 3rd, 2019

• Asset: Private Program #1 (*.example.com)
• Report:

• Details:

I began with enumerating subdomains using Sublist3r when i stumbled upon interesting subdomain “fig.example.com”. (I have no idea why it was interesting but it was )

I opened “http;//fig.example.com/” on the browser it show nothing but a blank page with empty HTML code, So i decided to brute force directories using Dirsearch. when I found ‘http://fig.example.com/includes/’ directory with directory listing enabled.

I reported it and got the following respond.

So I decided to look for similar issue with the reset of subdomains, Soon after i found two other subdomains “github.example.com” and “goose.example.com” with the same issue. How did i know it was? It’s simple it was redirecting to a totally different site.

Then checked the DNS records maybe it will help me identify other subdomains with same issue.

When i realized what they have in common “Amazon Web Service”.

Then I decided to filter the subdomains based on there CNAMEs record, I used this tool which i have created. Now let’s check for similar issue, After spending 1h no luck. now we need to let go for now.

What i have missed? it’s simple check for open ports Dah!

Nov 24th, 2019

• Asset: Private Program #1 (*.example.com)
• Report:

• Respond:

Now i know that this program has serious issue with dangling DNS records.

Nov 26th, 2019

• Asset: Private Program #1 (*.example.com)
• Report:

Dec 26th, 2019

Now we have a list of possible subdomain with dangling DNS with no way to make sure it’s really is.

what can we do?

• Let’s check SSL Certificate.

• Let’s check Shodan for archived SSL Certificate

• Let’s use google dorks or Bing “ip: 54.161.231.55”
• Maybe all you have to do is asking :D

Jun 16th, 2020

• Asset: Private Program #1 (*.example.com)
• Report:

• Details:

After Monitor subdomains and confirming that every subdomain has a dangling DNS record before reporting, The program asked me to supply every possible Dangling record and they will confirm it all at once.

Turned out they all had a dangling DNS records!!

Jul 10th, 2020

It’s all started on Oct 7, 2015 when Matt Bryant blogged (Fishing the AWS IP Pool for Dangling Domains) about AWS IP pool.

“What happened to that IP tied to that EC2 instance that you just killed? Well, when you terminate an instance, that IP address isn’t put to waste. Instead, it’s reused by other AWS customers. There is a massive pool of IP addresses that are constantly being recycled and trusted by various organizations and people.”

The issue happens when company use EC2 instance without using elastic IP.

If the EC2 instance is killed or terminated and the DNS not updated this will lead to creating a dangling DNS record for the subdomain.

The EC2 IP will be released to AWS IPs pool, This mean it’s possible to assign the IP to new EC2 instance.

How to find this kind of issues?

• Check for compute.amazonaws.com or compute-1.amazonaws.com in CNAME .

• Confirm that it’s a dangling DNS before reporting to avoid (N/A), As mentioned before.

Case Studies

• Asset: Transloadit

• Asset: Avast

• Asset: Amazon

As funny as it is Amazon itself had a similar issue.

• Asset: Private Programs

A piece of advice

• Don’t ignore old researches, It might be old but not dead.
• Building trust with security teams is great and it’s a two-way street.

Contacts

• Facebook
• Twitter
• LinkedIn