How to Use the Vulnerability and Penetration Testing Process to Hack Your Own Systems

To ensure the success of your ethical hacking efforts, spend time planning for any amount of testing, from a simple OS password-cracking test against a few servers to a penetration test of a complex web environment.

If you choose to hire a “reformed” hacker to work with you during your testing or to obtain an independent perspective, be careful.

Formulating your ethical hacking plan

The authorization can be as simple as an internal memo or an email from your boss when you perform these tests on your own systems. If you’re testing for a client, have a signed contract stating the client’s support and authorization. Get written approval of this sponsorship as soon as possible to ensure that none of your time or effort is wasted. This documentation is your “Get Out of Jail Free” card if anyone — such as your internet service provider (ISP), cloud service provider, or a related vendor —questions what you’re doing or if the authorities come calling. Don’t laugh — it wouldn’t be the first time it has happened.

One slip can crash your systems, which isn’t necessarily what anyone wants. You need a detailed plan, but you don’t need volumes of testing procedures that make the plan overly complex. A well-defined scope for an ethical hack includes the following information:

• Specific systems to be tested: When selecting systems to test, start with the most critical systems and processes or the ones that you suspect are the most vulnerable. You could test server OS passwords, test an internet-facing web application, or attempt social engineering via email phishing before drilling down into all of your systems.
• Risks involved: Have a contingency plan for your security testing process in case something goes awry. Suppose that you’re assessing your firewall or web application, and you take it down. This situation can cause system unavailability, which can reduce system performance or employee productivity. Worse, it might cause loss of data integrity, loss of data itself, and even bad publicity. It’ll most certainly tick off a person or two and make you look bad. All of these can create business risks. Handle social engineering and DoS attacks carefully. Determine how they might affect the people and systems you test.
• Dates when the tests will be performed and overall timeline: Determining when the tests are to be performed is something you must think long and hard about. Decide whether to perform tests during normal business hours, or late at night or early in the morning so that production systems aren’t affected. Involve others to make sure that they approve of your timing. You may get pushback and suffer DoS-related consequences, but the best approach is an unlimited attack, in which any type of test is possible at any time of day. The bad guys aren’t breaking into your systems within a limited scope, so why should you? Some exceptions to this approach are performing all-out DoS attacks, social engineering, and physical security tests.
• Whether you intend to be detected: One of your goals may be to perform the tests without being detected. You might perform your tests on remote systems or on a remote office and don’t want the users to be aware of what you’re doing. Otherwise, the users or IT staff may catch on to you and be on their best behavior instead of their normal behavior.
• Whether to leave security controls enabled: An important, yet often-overlooked, issue is whether to leave enabled security controls such as firewalls, intrusion prevention systems (IPSes), and web application firewalls (WAFs) so that they block scans and exploit attempts. Leaving these controls enabled provides a real-world picture of where things stand. But there is much more value in disabling these controls (or allowlisting your IP address) so that you can pull back the curtains and find the greatest number of vulnerabilities. Many people want to leave their security controls enabled. After all, that approach can make them look better, because many security checks will likely be blocked. However, this defense-in-depth approach is great, but it can create a serious false sense of security and doesn’t paint the entire picture of an organization’s overall security posture.
• Knowledge of the systems before testing: You don’t need extensive knowledge of the systems you’re testing — just basic understanding, which protects both you and the tested systems. Understanding the systems you’re testing shouldn’t be difficult if you’re testing your own in-house systems. If you’re testing a client’s systems, you may have to dig deeper. In fact, only one or two clients have asked for a fully blind assessment. Most IT managers and others who are responsible for security are scared of blind assessments, which can take more time, cost more, and be less effective. Base the type of test you perform on the organization’s or client’s needs.
• Actions to take when a major vulnerability is discovered: Don’t stop after you find one or two security holes; keep going to see what else you can discover. This doesn’t mean that you should keep testing until the end of time or until you crash all your systems; ain’t nobody got time for that! Instead, simply pursue the path you’re going down until you can’t hack it any longer (pun intended).If you haven’t found any vulnerabilities, you haven’t looked hard enough. Vulnerabilities are there. If you uncover something big, you need to share that information with the key players (developers, database administrators, IT managers, and so on) as soon as possible to plug the hole before it’s exploited.
• The specific deliverables: Deliverables include vulnerability scanner reports and your own distilled report outlining important vulnerabilities to address, along with recommendations and countermeasures to implement.

Selecting your ethical hacking tools

Know the limitations of your tools. Many vulnerability scanners generate false positives and negatives (incorrectly identifying vulnerabilities). Others skip vulnerabilities. In certain situations, such as testing web applications, you have to run multiple vulnerability scanners to find all the vulnerabilities.

Make sure that you’re using tools like these for your ethical hacking tasks:

• To crack passwords, you need cracking tools such as Ophcrack and Proactive Password Auditor.
• For an in-depth analysis of a web application, a web vulnerability scanner (such as Netsparker or Acunetix web Vulnerability Scanner) is more appropriate than a network analyzer (such as Wireshark or Omnipeek).

Whichever tools you use, familiarize yourself with them before you start using them. That way, you’re prepared to use the ethical hacking tools in the ways that they’re intended to be used. Here are ways to do that:

• Read the "Readme" and/or online help files and FAQs (frequently asked questions).
• Study the user guides.
• Use the tools in a lab or test environment.
• Watch tutorial videos on YouTube (if you can bear the poor production of most of them).
• Consider formal classroom training from the security-tool vendor or another third-party training provider, if available.

• Adequate documentation.
• Detailed reports on discovered vulnerabilities, including how they might be exploited and fixed.
• General industry acceptance.
• Availability of updates and responsiveness of technical support.
• High-level reports that can be presented to managers or nontechnical types (especially important in today’s audit- and compliance-driven world).

Executing your ethical hacking plan

Making sure that no hackers are on your systems before you start isn’t practical. Just be sure to keep everything as quiet and private as possible, especially when you’re transmitting and storing test results. If possible, encrypt any emails and files that contain sensitive test information or share them via a cloud-based file sharing service.

You’re on a reconnaissance mission. Harness as much information as possible about your organization and systems, much as malicious hackers do. Start with a broad view and narrow your focus. Follow these steps to begin your ethical hack:

1. Search the internet for your organization’s name, its computer and network system names, and its IP addresses. Google is a great place to start.
2. Narrow your scope, targeting the specific systems you’re testing. Whether you’re assessing physical security structures or web applications, a casual assessment can turn up a lot of information about your systems.
3. Further narrow your focus by performing scans and other detailed tests to uncover vulnerabilities on your systems.
4. Perform the attacks and exploit any vulnerabilities you find (if that’s what you choose to do).

Evaluating the results of your ethical hack

Submit a formal report to management or to your client, outlining your results and any recommendations you need to share. Keep these parties in the loop to show that your efforts and their money are well spent.

Implementing the results of your ethical hack

New security vulnerabilities continually appear. Information systems change and become more complex. New security vulnerabilities and exploits are uncovered. Vulnerability scanners get better. Security tests provide a snapshot of the security posture of your systems.

At any time, everything can change, especially after you upgrade software, add computer systems, or apply patches. This situation underscores the need to update your tools often — before each use, if possible. Plan to test regularly and consistently (such as once a month, once a quarter, or biannually).