Dangling DNS: Amazon EC2
Inspired by Matt Bryant's research on AWS dangling domains in 2015, I was able to revisit the research and apply the technique to bug bounty programs during my bug bounty journey.
Last updated
Was this helpful?
Inspired by Matt Bryant's research on AWS dangling domains in 2015, I was able to revisit the research and apply the technique to bug bounty programs during my bug bounty journey.
Last updated
Was this helpful?
Asset: Private Program [fig.example.com]
Report:
Details:
Response:
Then I decided to look for similar issues affecting other subdomains. Soon after, I found two other subdomains github.example.com and goose.example.com with the same issue. How did I figure it out? Simply it was redirecting to a different site.
Then I checked DNS records for github.example.com maybe it will help me identify other subdomains with the same issue.
I realized what they all have in common, “Amazon Web Service”.
Asset: Private Program [emu.example.com]
Report:
Respond:
Now I know this program has a severe issue with dangling DNS records.
Asset: Private Program [rev.example.com]
Report:
Now I have a list of subdomains with possible dangling DNS records with no way to make sure it really is. What can we do?
Let’s check SSL certificate data for pilot.example.com And this turned out very helpful as I found an SSL certificate issued for a totally different Org.
2. Let’s check Shodan for archived data (SSL certificates - HTML) for henry.example.com, And again SSL certificate was issued for a different Org.
Shodan Query: net:54.161.231.55
3. Let’s use Google or Bing dorks ip:54.161.231.55 And check for crawled data.
4. Maybe all you have to do is ask.
Asset: Private Program [ipa01.example.com]
Report:
Details:
After monitoring subdomains and confirming that every subdomain has a dangling DNS record before reporting, Program asked me to supply every possible dangling record, and they will confirm it all at once.
Turned out they all had dangling DNS records, Yay!!
“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 a company uses EC2 instance public DNS as CNAMEor A record, without using elastic IP. If the EC2 instance is killed or terminated and the DNS is not updated, this will lead to creating a dangling DNS record for the subdomain. Then EC2 IP will be released to the AWS IP pool, which means it’s possible to assign the IP to a new EC2 instance.
Check for compute.amazonaws.com or compute-1.amazonaws.com in CNAME record.
Ensure that subdomain has dangling DNS before reporting to avoid N/A, As mentioned before. Avoid managed bug bounty programs as they require a PoC file.
Asset: Private Programs
Don’t ignore old research; It might be old but not dead.
Building trust with security teams is a two-way street.
I began with enumerating subdomains using when I stumbled upon an 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 showed nothing but a blank page with empty _HTML _code, So I decided to brute force directories using . When I found http://fig.example.com/includes/a directory with directory listing enabled.
At this point, I decided to filter subdomains based on CNAME records. I used this which I have created with Python. Now let’s check for a similar issue; After spending some time, I had no luck. I had to take some time out. Then I realized what I had missed, Port scanning.
It all started on Oct 7, 2015, when Matt Bryant "Fishing the AWS IP Pool for Dangling Domains" about the AWS IP pool.
Asset:
Asset:
Asset: (Ironically, Amazon had a similar issue)
