Specific tests

Specific tests
You may have been charged with performing a general penetration test, or you
may want to perform specific tests, such as cracking passwords or war-dialing
into a network. Or you might be performing a social-engineering test or assessing
the Windows operating systems on the network. However you’re testing,
you may want to conceal the specifics of the testing to keep what you’re doing
covert or to protect your methodologies. In fact, your manager or customer
may not want the details. Either way, document and make known at a high level
what you’re doing. This can help eliminate any potential miscommunication
and keep you out of hot water.
A good way to provide evidence of what was tested, when it was tested, and
more is to enable logging on the systems you’re testing.
34 Part I: Building the Foundation for Ethical Hacking
Sometimes, you may know the general tests that you’re performing, but if you’re
using automated tools, it may be next to impossible to understand completely
every test you’re performing. This is especially true if the software you’re using
receives real-time vulnerability-testing updates from the vendor every 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’re using.
I have experienced surprising vulnerability updates in the past. I was performing
an automated assessment on a customer’s Web site — the same test I had
just performed the previous week. The customer and I had scheduled the test
date and time in advance. What I didn’t know is that the software vendor made
some changes to its Web form submission tests, and I flooded the customer’s
Web application, creating a DoS condition.
Luckily, this DoS condition occurred after business hours and didn’t affect
the customer’s operations. However, the customer’s Web application was
coded to generate an alert e-mail for every form submission. The application
developer and company’s president received 4,000 e-mails in their inboxes
within about 10 minutes — ouch! I was lucky that the president was techsavvy
and understood the situation. It’s important to have a contingency plan
in case a situation like this occurs.
Blind versus knowledge assessments
It may be good to have some knowledge of the systems you’re testing, but it’s
not required. However, a basic understanding of the systems you’re hacking
can protect you and others. Obtaining this knowledge shouldn’t be difficult if
you’re hacking your own in-house systems. If you’re hacking a customer’s
systems, you may have to dig a little deeper into how the systems work so
you know what’s what. That’s how I’ve always done it. In fact, I’ve never had
a customer ask for a fully blind assessment. Most people are scared of these
assessments. This doesn’t mean that blind assessments aren’t valuable. 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.
The bad guys aren’t hacking your systems within a limited scope, so why
should you?
Consider whether the tests should be undetected. This isn’t required but
should be considered, especially for social-engineering and physical security
tests. I outline specific tests for those subjects in Chapter 5 and Chapter 6.
A false sense of vigilance can be created if too many insiders know about your
testing which can end up negating the hard work you’re putting into this.
This doesn’t mean you shouldn’t tell anyone. Always have a main point of
contact within the organization — preferably someone with decision-making
authority — that both you and all employees can contact if and when something
goes wrong.