false findings - need clarification - possible bugs

[chrisdlangton]

As an experiment, i decided to start at top level on my domain and recursively amass enum anything that was found. the results are an infinite www.www.www.www.www. (etc.) and others that are common like www..

for example I found these for the top level;

www.langton.cloud **AlienVault**
phish.langton.cloud **VirusTotal**
log.langton.cloud **SecurityTrails**

They're all real.

the next one found was not "real" log.phish.langton.cloud but as it was SecurityTrails i might understand that they could have a record that is a combination of phish.langton.cloud and log.langton.cloud for whatever reason, and i might also accept someone (like Ask) has seen that domain name in SecurityTrails and now they have in their database a www. prepend to that too (i.e. Amass found www.log.phish.langton.cloud from Ask).

But so far there is no such history of any DNS record for log.phish.langton.cloud or www.log.phish.langton.cloud so they're technically not "real" subdomains that anyone ever used..

It gets a bit crazy when i saw;

www.www.log.phish.langton.cloud **Yahoo**
www.www.www.log.phish.langton.cloud **Ask**
www.www.www.www.log.phish.langton.cloud *Ask*

I had to stop it as it might have gone forever... AND there were many others like this too..

It seems there is some sort of bug here

[caffix]

Can you provide what was executed on the command-line?

[chrisdlangton]

@caffix i can do 1 better;

mode = passive
output_directory = /tmp
maximum_dns_queries = 20000
[scope]
[scope.domains]
domain = langton.cloud
[resolvers]
public_dns_resolvers = true
monitor_resolver_rate = true
resolver = 9.9.9.9
resolver = 1.1.1.1
[scope.blacklisted]
subdomain = localhost
[data_sources]
minimum_ttl = 1440
[data_sources.BufferOver]
ttl = 10080
[data_sources.BuiltWith]
ttl = 10080
[data_sources.DNSTable]
ttl = 4320
[data_sources.HackerOne]
ttl = 4320
[data_sources.HackerTarget]
ttl = 4320
[data_sources.RapidDNS]
ttl = 4320
[data_sources.Riddler]
ttl = 4320
[data_sources.SiteDossier]
ttl = 4320
[data_sources.AlienVault]
ttl = 10080
[data_sources.AlienVault.Credentials]
apikey = REDACTED
[data_sources.BinaryEdge]
ttl = 10080
[data_sources.BinaryEdge.Credentials]
apikey = REDACTED
[data_sources.DNSDB]
ttl = 10080
[data_sources.DNSDB.Credentials]
apikey = REDACTED
[data_sources.GitHub]
ttl = 4320
[data_sources.GitHub.chrisdlangton]
apikey = REDACTED
[data_sources.ReconDev]
[data_sources.ReconDev.free]
apikey = REDACTED
[data_sources.SecurityTrails]
ttl = 1440
[data_sources.SecurityTrails.Credentials]
apikey = REDACTED
[data_sources.Shodan]
ttl = 10080
[data_sources.Shodan.Credentials]
apikey = REDACTED
[data_sources.VirusTotal]
ttl = 10080
[data_sources.VirusTotal.Credentials]
apikey = REDACTED

EDIT: obviously recursively generate a new config for each [scope.domains] domain finding of this execution, so if this resulted in;

[scope.domains]
domain = www.langton.cloud
domain = dev.langton.cloud
domain = log.langton.cloud
domain = phish.langton.cloud
...
...

then there would be another config for these generated.

[scope.domains]
domain = www.www.langton.cloud
domain = www.dev.langton.cloud
domain = www.log.langton.cloud
domain = phish.log.langton.cloud
domain = www.phish.langton.cloud
domain = log.phish.langton.cloud
...
...

That would then generate a new config for those findings, and recursively for each of those.

[scope.domains]
domain = www.www.www.langton.cloud
domain = www.www.dev.langton.cloud
domain = www.www.log.langton.cloud
domain = www.phish.log.langton.cloud
domain = www.www.phish.langton.cloud
domain = www.log.phish.langton.cloud
...
...

[caffix]

Can you test to see if this is still an issue?