A guided tour to someone else's network
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).
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).
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 .
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
Buy this article as PDF
MSBuild is now just another GitHub project as Redmond continues its path to the light.
Malware could pass data and commands between disconnected computers without leaving a trace on the network.
New rules emphasize collegiality in coding.
Upstart lands in the dust bin as a new era begins for Linux.
HP's annual Cyber Risk report offers a bleak look at the state of IT.
But what do the big numbers really mean?
.NET Core execution engine is the basis for cross-platform .NET implementations.
The Xnote trojan hides itself on the target system and will launch a variety of attacks on command.
Spammers go low-volume, and 90% of IE browsers are unpatched.
Adobe scrambles to release patches for vulnerable Flash Player.