DNS Records

Domain Name System (DNS) records can provide a wealth of information regarding services that may be exposed to the Internet, but here there be dragons.

The "target" we're going to attack in the lab is an organisation called Cyberbotic. Their domain name is cyberbotic.io. We can start off by performing a simple lookup of any A records for this domain.

$ dig cyberbotic.io

;; QUESTION SECTION:
;cyberbotic.io.                 IN      A

;; ANSWER SECTION:
cyberbotic.io.          0       IN      A       172.67.205.143
cyberbotic.io.          0       IN      A       104.21.90.222

\

Performing a whois on each public IP address can show who it belongs to. We can see that it resolves to a 3rd party provider, Cloudflare.

$ whois 172.67.205.143

OrgName:        Cloudflare, Inc.
OrgId:          CLOUD14
Address:        101 Townsend Street
City:           San Francisco
StateProv:      CA
PostalCode:     94107
Country:        US
RegDate:        2010-07-09
Updated:        2021-01-11
Ref:            https://rdap.arin.net/registry/entity/CLOUD14

\

When we browse to https://cyberbotic.io, we are actually being sent to Cloudflare, which proxies the traffic between us and a back-end webserver. The issue being that we don't know if the web server is hosted on premise of the target organisation, or in another 3rd party cloud service. This information you must confirm with the client - providers such as Amazon and Azure have specific rules and/or require explicit permission before you are able to carry out any security assessments hosted on, or performed from, their infrastructure. You may also come across IP addresses that belong to Internet Service Providers (ISPs), as some organisations rent their public address space.

Some Software as a Service (SaaS) offerings require DNS records on the target domain, in order to point towards those services. A notable example includes Microsoft's Office 365 which can be found at autodiscover.target-domain. If the target uses these SaaS services for email and/or document storage etc, it may be possible to gain access to your objective without ever needing to compromise their network.

Subdomains can also provide insight to other publicly available services, which could include webmail, remote access solutions such as Citrix, or a VPN. Tools such as dnscan come with lists of popular subdomains.

~/dnscan$ ./dnscan.py -d cyberbotic.io -w subdomains-100.txt
[*] Processing domain cyberbotic.io
[*] Using system resolvers: 172.19.80.1
[+] Getting nameservers
172.64.32.56 - adi.ns.cloudflare.com
173.245.58.56 - adi.ns.cloudflare.com
108.162.192.56 - adi.ns.cloudflare.com
cyberbotic.io
172.64.33.220 - pablo.ns.cloudflare.com
173.245.59.220 - pablo.ns.cloudflare.com
108.162.193.220 - pablo.ns.cloudflare.com
cyberbotic.io
[-] Zone transfer failed

[+] IPv6 (AAAA) records found. Try running dnscan with the -6 option.
2606:4700:3037::ac43:cd8f

2606:4700:3033::6815:5ade

[-] DNSSEC not supported

[+] MX records found, added to target list
10 mail.cyberbotic.io.

[*] Scanning cyberbotic.io for A records
172.67.205.143 - cyberbotic.io
104.21.90.222 - cyberbotic.io
172.67.205.143 - www.cyberbotic.io
104.21.90.222 - www.cyberbotic.io
10.10.15.100 - mail.cyberbotic.io

\

From the output above, we've discovered www and mail subdomains.

The astute will notice that mail resolves to an internal address rather than a public address. This is the IP address of the Exchange server in the RTO lab.

\

Weak email security (SPF, DMARC and DKIM) may allow us to spoof emails to appear as though they’re coming from their own domain. Spoofy is a Python tool that can verify the email security of a given domain.

~/Spoofy$ pip3 install -r requirements.txt
~/Spoofy$ python3 spoofy.py -d cyberbotic.io -o stdout
[*] Domain: cyberbotic.io
[*] Is subdomain: False
[*] DNS Server: 1.1.1.1
[?] No SPF record found.
[?] No DMARC record found.
[+] Spoofing possible for cyberbotic.io

Last updated