Recon Methods Part 1 – OSINT Host Discovery

By Red Siege | February 4, 2020

During an external assessment (be it a penetration test or red team), we here at Red Siege begin by investigating the target as completely as possible before accessing the target’s external assets. During this series of articles, we will demonstrate different methods of gathering actionable intelligence on a target focused first on infrastructure and then on employees. We will further break this down into completely open-source intelligence sources and ramp up to light interactions with the target’s external assets. As an example, we will take a look at a company that recently restructured.

UPDATE 2/6: The company we selected for this recon is apparently not 100% dead. While all the information in this post is public, we have chosen to redact the company name from the remainder of the post.

Links to posts in this series: 

Recon Methods Part 2 – OSINT Host Discovery Continued

Recon Methods Part 3 – OSINT Employee Discovery

Recon Methods Part 4 – Automated OSINT

Recon Methods Part 5 – Traffic on the Target


The first stop for gathering information about a company is Wikipedia. Entries on Wikipedia will often have a biography of the company including associated domains and can also contain histories of mergers, acquisitions, and subsidiary companies. Using this list of affiliated companies, an attacker can potentially find additional domains associated with the target. In the case of the selected company, Wikipedia indicates a history of acquisitions. We would typically track down each of these companies to check for additional external attack surface.

On a recent unrelated red team engagement, we were able to find a list of subsidiary companies that had been acquired by our target. After independently verifying the acquisitions, we had gained a list of additional target domains that ultimately led to the first foothold inside the target’s network. Once inside their networks, we were able to track down each of the subsidiary company’s internal domains that had been incorporated over the years leading to further access and alternate paths for lateral movement. The affiliations were not immediately apparent externally without first investigating the history of the company and mergers.


Once we have the domains for our target company and any
associated company domains, DNSDumpster
is usually our next stop. This site provides a wealth of information about a
target domain such as MX records, TXT records, ASN identification, and a list
of subdomains.

Starting with MX records, an attacker can often determine
spam filters in use by the IP address and ASN associated with the mail exchange
hosts. Commonly, we see Cisco IronPort, Barracuda, or ProofPoint records in the
MX section. This gives us a good idea of what we’re up against if and when we
have to phish the target.

Next, we look at the TXT records for the target domain which will often contain domain verification service records such as Sender Policy Framework (SPF). Cloud email services like Microsoft’s Office365 and Google’s G-Suite can usually be determined from TXT records set in the target’s domain entries. While the cloud email services can be determined from an MX record, it is more common to find them through the SPF records in the TXT section.

Another useful set of information from DNSDumpster are the
associated autonomous system numbers (ASN). ASNs are groups of IP addresses
under control of a single administrative entity or domain. This information can
be helpful in discovering additional IP addresses and domain names through
looking up the netblocks of IP addresses (as shown in the next section). ASN
names containing the target’s name are usually a positive identifier for hosts
owned by the target. The research on Wikipedia also comes into play when you
find ASNs with subsidiary or merged company names included in the DNSDumpster results.

Finally, DNSDumpster provides a list of subdomains, IP addresses, and ASNs associated with the target’s domain. The list of hosts gives an attacker a large jumping-off point during an external assessment. Additionally, opportunities for password guessing attacks and internal access can often be identified through the host names. Subdomains containing ‘vpn’, ‘owa’, ‘adfs’, ‘autodiscover’, variations of ‘citrix’, ‘admin’, and ‘remote’ are usually moved to the top of the priority list during further recon. A sample of the DNS records for the target can be seen below.

Electric BGP Toolkit

Using the data found with DNSDumpster, we can continue host
and IP address discovery by searching the Hurricane
Electric BGP Toolkit
 for company
name, IP address/CIDR range, and ASNs. Searching for the company name will
return a list of ASNs and CIDR IP address ranges. While not all of the results
will be relevant to our target, additional ASNs can be found in the results.

Once all of the associated ASNs have been found, we can
start going through the CIDR IP address ranges. Hurricane Electric’s (HE)
search engine also records registered DNS entries for each of the IP addresses
in a range.

During the same unrelated red team mentioned before, we found that the target company had rebranded after acquiring subsidiary companies. Their main domain had also changed during the rebranding. HE’s search engine showed that the new domain and a previous domain shared the same IP address and contained indicators of being associated with the target before the rebrand. Although their DNSDumpster results indicated that the target used Office365, we were unable to identify any active accounts using the domain we found on Wikipedia. We generated a new list of email addresses using the old domain discovered with HE’s search engine and found that the target was using the old pre-rebrand domain for their Office365 usernames! We were also able to identify additional ASNs and external infrastructure using the newly discovered domain that were eventually incorporated into successful phishing pretexts.


Using Wikipedia, DNSDumpster, and Hurricane Electric’s BGP
Toolkit, we were able to research a large portion of a target’s online attack
surface without ever touching the target’s external hosts or services. In the
next post, we will continue the external host recon using Shodan, SSL
Certificate Searching, SpyOnWeb,, and look for information about
security or software suites in use through job postings.

Obfuscating Shellcode Using Jargon

By Red Siege | July 31, 2023

by Mike Saunders, Principal Security Consultant In a recent blog , we discussed how encrypting shellcode leads to increased entropy, which may result in your shellcode loader being blocked and/or […]

Learn More
Obfuscating Shellcode Using Jargon

Browser Only Web Application Testing

By Red Siege | July 24, 2023

By: Ian Briley, Security Consultant Spoiler Alert: Burp is the number one tool most people use while testing web applications. If you want to be an open-source champion, ZAP from […]

Learn More
Browser Only Web Application Testing

Introduction to Mythic C2

By Red Siege | June 28, 2023

By: Justin Palk, Senior Security Consultant Continuing along with my occasional series looking at how to set up and use various C2 frameworks, this is a guide to Mythic C2. Developed […]

Learn More
Introduction to Mythic C2

Find Out What’s Next

Stay in the loop with our upcoming events.