Step 1: Reconnaissance

Strictly speaking, reconnaissance isn't always necessary, but learning about the company's network layout, organizational structure, and personnel can aid in other attacks. Finding the domain name for a company or organization usually just means sticking .com (or a top-level national domain) on the end of the company name, and if that doesn't work, just ask Google. Once you have the domain name, you can learn a lot about the company or organization with tools like whois. Intruders look for technical details, like where the company's domain name servers are located and whether or not the technical management of the company is competent. (If an organization can't set up DNS competently, chances are their security isn't very good.) A perfect example of this is seifried.org, which I host on a VPS server. Unfortunately, the control panel is so brain dead it sets up the DNS server to allow remote zone transfers. Therefore, the dig -t axfr command lets you download entire DNS zones, finding all the hosts in seconds (Figure 1).

Figure 1: Output of dig -t axfr for seifried.org.

If zone transfers aren't allowed, another way to find web hosts is to use the site: search keyword in Google, filtering out http://www.example.org and so on in the search terms. This, of course, can be combined with a variety of interesting search terms such as user name:, login:, password:, reset password, and so on to find login screens. Google (and other search engines) can also provide information such as corporate phone numbers, lists of executives, corporate structure diagrams, and employee listings (Figure 2).

Figure 2: Output of some interesting Google searches.

So the attacker has figured out where you live (metaphorically or literally), now what happens?

Step 2: Load Balancers, IPSs, and Firewalls

One of the first problems attackers will often run into is sites using load balancers, firewalls, intrusion prevention systems (IPSs), and web application firewalls (WAFs). If you try attacking a site behind a load balancer, the first part of your attack might go to server A, and the second part of your attack ends up at server B, resulting in a failed attack. Likewise, if a site is using a firewall, IPS, or WAF, it might detect and block the attacks (assuming it works).

How can you detect these devices and bypass their protective measures? Load balancers are generally not built or deployed with stealth in mind. If a site is using DNS to load balance, tools such as dig will show them easily. If you get more than one IP or the IP changes, they're probably using DNS-based load balancing. Alternatively, tools such as Nmap can identify load balancers by their TCP-IP fingerprints (since almost no two TCP-IP--capable devices behave the exact same way). Detecting Firewalls and WAFs is also simple; just send a well-known attack using a remote host or an anonymous proxy such as Tor and see if the connection is terminated or if future connection attempts are blocked. If you really want to learn how the professionals do this, check out the DojoSec presentation by Joseph McCray [3][4].

Bypassing the devices blocking entry to the network is certainly possible. In the case of a DNS-based load balancer, simply using the IP address rather than the DNS name in an attack will ensure that all the attacks go to the same system. Bypassing firewalls is also relatively trivial because pretty much all firewalls allow incoming email and web traffic. The same goes for IPS and WAF systems; most sites are terrified of blocking legitimate web traffic and email, so they typically reduce the sensitivity of these systems, which reduces their effectiveness.

Web 2.0 and Modern Email

In the past, web pages and email were much the same: static text with minimal formatting and not much in the way of executable content. The pendulum has now swung the other way; most email clients support text and HTML, as well as file attachments. HTML, as you know, supports any number of executable technologies, the most popular being JavaScript. Almost everything now supports JavaScript (web browsers, email clients, even Adobe Reader), which means not only do you have to worry about buffer overflows and integer overflows in images, you often have a fully fledged Turing machine embedded in many applications. Because almost nobody blocks JavaScript or disables it, there is no better way to attack applications reliably.