Planning
It is a process of creating one or more detailed plans to achieve optimum balance of demands with the available resources. The planning process involves following actions in sequence –
- Identifies the goals or objectives to be achieved
- Formulates strategies to achieve them
- Arranges or creates the means required
- Implements, directs, and monitors all steps in their proper sequence.
Planning an hacking attack evaluates existing business processes, how they relate to a new business endeavor, and to make choices on which characteristics are worth doing and those in which you’re not willing to accept risk.
Existing security policies, culture, laws and regulations, best practices, and industry requirements will drive many of the inputs needed to make decisions on the scope and scale of a test. Arguably, the planning phase of a penetration test will have a profound influence on how the test is performed and the information shared and collected, and will directly influence the deliverable and integration of the results into the security program.
Planning describes many of the details and their role in formulating a controlled attack. Security policies, program, posture, and ultimately risk all play a part in guiding the outcome of a test. What drives a company’s focus on security, its core business needs, challenges, and expectations will set the stage for the entire engagement.
Maintain Anonymity
Anonymity is the quality or state of being unknown or unacknowledged.
Various techniques are used for being anonymous which usually includes
- Hacking and using open or unsecured wireless networks usually in residential buildings
- Making use of anonymous or disposable e-mail accounts from free e-mail services
- Using infected computers or zombies or bots (at other organizations)
- Using borrowed or stolen remote desktop and VPN accounts
- Using public computers at libraries, schools, etc.
- Using internet proxy servers or anonymizer services
- Workstations or servers on the victim’s own network
Goal setting
- Define more specific goals. Align these goals with your business objectives. What are you and the management trying to get from this process? What performance criteria will you use to ensure you’re getting the most out of your testing?
- Create a specific schedule with start and end dates as well as the times your testing is to take place. These dates and times are critical components of your overall plan.
Target System Identification
You might decide which systems to test based on a high-level risk analysis, answering questions such as
- What are your most critical systems? Which systems, if accessed without authorization, would cause the most trouble or suffer the greatest losses?
- Which systems appear most vulnerable to attack?
- Which systems crash the most?
- Which systems are not documented, are rarely administered, or are the ones you know the least about?
After you’ve established your overall goals, decide which systems to test. This step helps you define a scope for your ethical hacking so that you establish everyone’s expectations up front and better estimate the time and resources for the job. The following list includes devices, systems, and applications that you may consider performing your hacking tests on
- Routers and switches
- Firewalls
- Wireless access points
- Web, application, and database servers
- E-mail and file servers
- Mobile devices (such as phones and tablets) that store confidential information
- Workstation and server operating systems
Attack Tree Analysis
Attack tree provides a way for modeling goals of an attack and alternative ways to achieve that goal. This helps us to study the system from the attackers’ point of view, which may lead us to determine possible ways that the system can be compromised. By assigning cost or probability measures to the nods of attack tree, one can analyze if the attackers efforts worth the value that can be achieved or not, and as a result, this helps analyzing if the system is at risk and vulnerable.
Attack trees are multi-leveled diagrams consisting of one root, leaves, and children. From the bottom up, child nodes are conditions which must be satisfied to make the direct parent node true; when the root is satisfied, the attack is complete. Each node may be satisfied only by its direct child nodes.
A node may be the child of another node; in such a case, it becomes logical that multiple steps must be taken to carry out an attack. For example, consider classroom computers which are secured to the desks. To steal one, the securing cable must be cut or the lock unlocked. The lock may be unlocked by picking or by obtaining the key. The key may be obtained by threatening a key holder, bribing a keyholder, or taking it from where it is stored (e.g. under a mousemat). Thus a four level attack tree can be drawn, of which one path is (Bribe Keyholder,Obtain Key,Unlock Lock,Steal Computer).
Note also that an attack described in a node may require one or more of many attacks described in child nodes to be satisfied. Our above condition shows only OR conditions; however, an AND condition can be created, for example, by assuming an electronic alarm which must be disabled if and only if the cable will be cut. Rather than making this task a child node of cutting the lock, both tasks can simply reach a summing junction. Thus the path ((Disable Alarm,Cut Cable),Steal Computer) is created.
Attack trees can become largely complex, especially when dealing with specific attacks. A full attack tree may contain hundreds or thousands of different paths all leading to completion of the attack. Even so, these trees are very useful for determining what threats exist and how to deal with them.
Attack trees can lend themselves to defining an information assurance strategy. It is important to consider, however, that implementing policy to execute this strategy changes the attack tree. For example, computer viruses may be protected against by refusing the system administrator access to directly modify existing programs and program folders, instead requiring a package manager be used. This adds to the attack tree the possibility of design flaws or exploits in the package manager.
Attack tree for computer viruses. Here we assume a system such as Windows NT, where not all users have full system access. All child nodes operate on OR conditions.
Structuring, Executing and Reporting Penetration Test
Creating Testing Standards
One miscommunication or slip-up can send the systems crashing during your ethical hacking tests. No one wants that to happen. To prevent mishaps, develop and document testing standards. These standards should include
✓ When the tests are performed, along with the overall timeline
✓ Which tests are performed
✓ How much knowledge of the systems you acquire in advance
✓ How the tests are performed and from what source IP addresses (if performed across the Internet)
✓ What you do when a major vulnerability is discovered
Timing
Make sure that the tests you perform minimize disruption to business processes, information systems, and people. You want to avoid harmful situations such as mis-communicating the timing of tests and causing a DoS attack against a high-traffic e-commerce site in the middle of the day or performing password-cracking tests in the middle of the night. It’s amazing what a 12-hour time difference (2 p.m. during major production versus 2 a.m. during down time) can make when testing your systems! Even having people in different time zones can create issues. Everyone on the project needs to agree on a detailed timeline before you begin. Having the team members’ agreement puts everyone on the same page and sets correct expectations.
If possible and practical, notify your Internet service providers (ISPs) or hosting collocation providers. These providers have firewalls or intrusion detection systems (IDS) or intrusion prevention systems (IPS) in place to detect malicious behavior. If your provider knows you’re conducting tests, it’s less likely to block your traffic.
Running specific tests
You might have been charged with performing a general penetration test, or you may want to perform specific tests, such as cracking passwords or trying to gain access to a web application. Or you might be performing a social engineering test or assessing Windows on the network. However you test, you might not want to reveal the specifics of the testing. Even when your manager or client doesn’t require detailed records of your tests, document what you’re doing at a high level. Documenting your testing can help eliminate any potential miscommunication and keep you out of hot water.
Enabling logging on the systems you test along with the tools you use provides evidence of what and when you test and more. It may be overkill, but you could even record screen actions using a tool such as TechSmith’s Camtasia Studio ( www.techsmith.com/camtasia.html). Sometimes, you might know the general tests that you perform, but if you use automated tools, it may be next to impossible to understand every test you perform completely. This is especially true when the software you’re using receives real-time vulnerability updates and patches from the vendor each time you run it. The potential for frequent updates underscores the importance of reading the documentation and readme files that come with the tools you use.
An updated program once bit me. I was performing an automated assessment on a client’s website — the same test I performed the previous week. The client and I had scheduled the test date and time in advance. But I didn’t know that the software vendor made some changes to its web form submission tests, and I accidentally flooded the client’s web application, creating a DoS condition.
Blind versus knowledge assessments
Having some knowledge of the systems you’re testing might be a good idea, but it’s not required. But, a basic understanding of the systems you hack can protect you and others. Obtaining this knowledge shouldn’t be difficult if you’re hacking your own in-house systems. If you hack a client’s systems, you might have to dig a little deeper into how the systems work so you’re familiar with them. Doing so has always been my practice and I’ve only had a small number of clients ask for a full blind assessment because most people are scared of them. This doesn’t mean that blind assessments aren’t valuable, but the type of assessment you carry out depends on your specific needs.
The best approach is to plan on unlimited attacks, wherein any test is possible, possibly even including DoS testing. The bad guys aren’t poking around on your systems within a limited scope, so why should you?
Picking your location
The tests you perform dictate where you must run them from. Your goal is to test your systems from locations accessible by malicious hackers or employees. You can’t predict whether you’ll be attacked by someone inside or outside your network, so cover all your bases. Combine external (public Internet) tests and internal (private network) tests.
You can perform some tests, such as password cracking and network-infrastructure assessments, from your office. For external hacks that require net-work connectivity, you might have to go off-site (a good excuse to work from home) or use an external proxy server. Some security vendors’ vulnerability scanners (such as QualysGuard) are run from the cloud, so that would work as well. Better yet, if you can assign an available public IP address to your computer, simply plug in to the network on the outside of the firewall for a hacker’s-eye view of your systems. Internal tests are easy because you need only physical access to the building and the network. You might be able to use a DSL line or cable modem already in place for visitors and similar users.Responding to vulnerabilities you find
Determine ahead of time whether you’ll stop or keep going when you find a critical security hole. You don’t need to keep hacking forever or until you crash all the systems. Just follow the path you’re on until you just can’t hack it any longer (pardon the pun). When in doubt, the best thing to do is to have a specific goal in mind and then stop when that goal has been met.
Selecting Security Assessment Tools
Which security assessment tools you need depend on the tests you’re going to run. You can perform some ethical hacking tests with a pair of sneakers, a telephone, and a basic workstation on the network, but comprehensive testing is easier with hacking tools.
It’s important to know what each tool can and can’t do and how to use each one. I suggest reading the manual and other Help files. Unfortunately, some tools have limited documentation, which can be frustrating. You can search forums and post a message if you’re having trouble with a tool.
Hacking tools can be hazardous to your network’s health. Be careful when you use them. Always make sure that you understand what every option does before you use it. Try your tools on test systems if you’re not sure how to use them. These precautions help prevent DoS conditions and loss of data on your production systems.
Setting the Stage for Testing
In the past, a lot of ethical hacking involved manual processes. Now, certain vulnerability scanners can automate various tasks, from testing to reporting to remediation validation (the process of determining whether a vulnerability was fixed). These tools allow you to focus on performing the tests and less on the specific steps involved. However, following a general methodology and understanding what’s going on behind the scenes will help you.
Ethical hacking is similar to beta testing software. Think logically — like a programmer, a radiologist, or a home inspector — to dissect and interact with all the system components to see how they work. You gather information, often in many small pieces, and assemble the pieces of the puzzle. You start at point A with several goals in mind, run your tests (repeating many steps along the way), and move closer until you discover security vulnerabilities at point B.
The process used for ethical hacking is basically the same as the one a malicious attacker would use. The primary differences lie in the goals and how you achieve them. Today’s attacks can come from any angle against any system, not just from the perimeter of your network and the Internet as you might have been taught in the past. Test every possible entry point, including partner, vendor, and customer networks, as well as home users, wireless LANs, and mobile devices. Any human being, computer system, or physical component that protects your computer systems — both inside and outside your buildings — is fair game for attack.
When you start rolling with your ethical hacking, keep a log of the tests you perform, the tools you use, the systems you test, and your results. This information can help you do the following – track what worked in previous tests and why.
Help prove what you did.
Correlate your testing with intrusion detection systems (IDSs) and other log files if trouble or questions arise.
Document your findings.
In addition to taking general notes, taking screen captures (using Snagit or a similar tool) of your results whenever possible is very helpful. These shots come in handy later should you need to show proof of what occurred, and they also will be useful as you generate your final report. Also, depending on the tools you use, these screen captures might be your only evidence of vulnerabilities or exploits when it comes time to write your final report.
