Basic Recon Using A Domain Name
Let’s say all you have is a company name/domain (presumably the company you work for or the company you are running a test against as a consultant). What are some steps you can take just starting with the company domain to pull back meaningful information?
This post includes some basic steps that I have used simply starting with a target domain. I believe these steps should be proactively and regularly performed by blue team members to understand exposure and what attack paths may be more relevant for your organization.
- Enumerating ASN Number information
- Why? If you can find the ASN number for the domain you have, you can then easily enumerate all of the publicly facing IP blocks belonging to that organization and can then start to search for publicly exposed services. This is a useful practice in general, since a lot of organizations do not have an automated mechanism that monitors additions or changes to its publicly facing infrastructure.
- How? Below are some easy steps you can take:
— Can download ASN lists directory from internet registry
There are a total of 5 regional internet registries: ARIN (American Registry for Internet Numbers), APNIC (Asia-Pacific Network Information Center), RIPE (Reseaux IP Europeans Network Coordination Centre), AFRINIC (African Network Information Center), and LACNIC (Latin America and Caribbean Network Information Centre). So you could search a registry and download the current ASN listing and then manually search those listings for your company/organization name or domain. A challenge with this approach is that the domain name or company name might be listed in a different format than what you are searching for. However, this is the approach that goes “closest to the source”. Below are some asn direct download links for a couple registries:
- ARIN: ftp://ftp.arin.net/info/asn.txt
- APNIC: https://ftp.apnic.net/transfers/apnic/transfer-apnic-latest
Once you have the ASNs, you could then search for them via the command line with this command: “whois -h whois.radb.net --‘-i origin AS[Number]’ | grep -Eo “([0–9.]+){4}/[0–9]+” | head”. You could also search via this site to get a list of IP blocks tied to an ASN: https://ipinfo.io/[ASNUMBER]
Next, you could run whois searches on an IP in each IP block tied to each ASN (from your results above) and you could also search for organization email addresses in the whois record. Though this is not always the case, sometimes an organization uses a group email (ex: networkops@[org].com) in whois records. If you find an organization email address in whois records, you can take that email and search here to find domains this account has registered in the past: https://viewdns.info/reversewhois/?q=[email_from_whois_records]. You could then start to enumerate domains set up by the target organization (even if they are hosted by a cloud provider) and seeing what is hosted on those sites. This can be valuable as sometimes people in an organization set up domains and forget to take them down, exposing vulnerable and unmonitored infrastructure that an attacker can leverage.
There are other ways but the above are two simple approaches that i have used to go about finding publicly assigned IP blocks for a company/org starting only with a domain name. Below are some other pieces of info you could check for just only starting with a domain name.
2. Basic Enumeration of DNS records
- Why? DNS records (ex: NS, TXT, MX) can be pretty useful from a reconnaissance perspective. You can learn things such as whether or not the organization has SPF enforced (i.e., will spoofed emails purporting to be from the target organization still get delivered to the target organization’s inboxes?). If SPF is enabled, you can see some useful information by seeing if there are any other company/product names identified in the SPF records (DNS TXT records). For example if you see zendesk referenced in the SPF records, then that would indicate that zendesk is likely used in that target organization and therefore a phishing email under that context may have a chance of being successful in that org.
- Sometimes you can also find useful data in an organization’s MX records. For example, if an organization is using a third party for email hosting then that third party may show up in the MX record query. An attacker could then research techniques to bypass mail preventions enforced by the vendor and prepare a phish using those methods.
- How? You can run these simple Linux shell commands to search for this data: host -t TXT [domain], host -t MX [domain]
3. Finding an organization’s Github users
- Why? Enumerating an organization’s github users can be valuable in terms of identifying key developers and engineers in the organization (for social engineering) and also could yield company email addresses (depending on what email address they are using for their Github account).
- How? Query https://github.com/orgs/[orgname]/people. This will return a list of an organization’s employees with organizational github accounts. Then for each employee found with a github site, you can navigate to the following github open API and see what data is available on that user: https://api.github.com/users/[username]/events/public. For example, let’s say your org name is widgits123 and you navigate to https://github.com/orgs/widgits123/people. This page lists all of widgits123’s github users and you find user jakedoe. Next you would navigate to https://api.github.com/users/jakedoe/events/public to see what public information is available on that user. Next you could search for email addresses (“email”: “[value]”) and possibly get their organizational email address (assuming the employee registered this github account using their organizational email). If so, that would be a phishing vector and could also give you insight into how the organization structures their employee email addresses (ex: [lastname][firstinitial]@domain).
- You could also search the organization’s github page (https://github.com/orgs/[orgname]) for exposed secrets using tools such as trufflehog (https://github.com/dxa4481/truffleHog).
4. Can search for publicly facing login portals
- Why? Knowing where the login portals are gives insight into how employees are remotely logging in and accessing company data and may expose a path that an attacker can leverage via social engineering (i.e., credential harvesting phishing emails).
- How? You can do some quick checks for some common login portals: login.microsoftonline.com (and enter a fake email such as test@[domain] and see if you get redirected to the org’s login page), [org].zoom.us (credit to Brady Donovon on Target’s Red Team for the zoom enumeration info), [org].my.centrify.com, webmail.[org].com, [org].slack.com, [org].okta.com, etc.
5. Finding email addresses for the target domain
- Why? Enumerating user email addresses for the target organization provides an initial attack surface for phishing, which is still widely used for initial access.
- How? There are several email marketing sites out (ex: hunter.io) where you can create a free account and then search for and download a list of your target organization’s email addresses. Some of those sites may require a valid company email address, so you may have to register a domain, create an email address, and create a free account using that address to be able to search for your target organization’s email addresses using that site. You can also using specific searches for email addresses in duckduckgo (ex: site:linkedin.com email @ ”[domain_name]”) or you can use theHarvester tool (https://github.com/laramies/theHarvester), but in my experience I usually do not find many email addresses using these methods (marketing site seems to work best for me personally).
6. Can do a ton of other searches in Shodan (ex: org:[org name]). Lots of great blogs have been written on enumeration using Shodan (ex: https://danielmiessler.com/study/shodan/).
References:
