MIS 5211.001

Wade T Mackey


Wade.mackey@temple.com
717-682-2925
1 (8/27)
2 (9/3)
3 (9/10)
4 (9/17)
5 (9/24)
6 (10/1)
7 (10/8)
8 (10/15)
9 (10/22)
10 (10/29)
11 (11/5)
12 (11/12)
13 (11/19)
14 (12/3)
Philosophy of Ethical Hacking and Penetration Testing, and the hacking
process.
TCP/IP and Network Architecture and its impact on the process of hacking.
Google Hacking
Reconnaissance
Vulnerability scanning and analysis of results
Assignment presentation
System and User enumeration
Assignment presentation
Sniffers
Midterm
NetCat
Social Engineering, Encoding, and Encryption
Malware including Trojans, Backdoors, Zero-days, Virus, Worms, and
Polymorphic malware
Web application hacking, Intercepting Proxies, and URL Editing
SQL injection
Assignment presentation
Web Services
Evasion Techniques
Final

Our focus will be to provide you with an
understanding of the process involved in
penetration test and the primary tools sets used


Organized around the workflow of a professional
tester
Tips for avoiding common pitfalls


The tools and techniques discussed and used in
this course should only be used on systems you
personally own, or have written permission to
use.
Some of the tools used have the potential to
disrupt or break computer systems.

Successful penetration testers look at the world
through a different lens
They think outside the box
 They do things differently
 They don’t look at the glass as half full or half
empty, instead they look at the glass and think “If I
hit the glass just right, I can crack it and drain out
just what I want.


Successful penetration tester also need to have
the following work habits
Methodical
 Thorough
 Careful
 Ethical


habitual note taker and documentation fiend

If you can’t duplicate a finding, you didn’t find it!




Threat: Any circumstance or event with the potential to
adversely impact organizational operations.
Vulnerability: Weakness in an information system,
system security procedures, internal controls, or
implementation that could be exploited by a threat
source.
Risk: A measure of the extent to which an entity is
threatened by a potential circumstance or event
A risk exist when a threat actor (or agent) targets a
vulnerability
Source: NIST SP 800-30 r1

A penetration tester:




identifies vulnerabilities
Evaluates likely threats
Recommends corrective actions
In other words, you don’t just say you found
something bad. You also have to suggest how
to fix it.


Attacks violate CIA (Confidentiality, Integrity,
or Availability.
Active Attack
Manipulates or changes systems or information
 Examples – Malware, Spear Phishing, Man-in-theMiddle


Passive Attack



No manipulation or Change
Monitoring only
Example – Sniffing wireless traffic

Internal




Launched from within an organization
Typically considered insider threat
Could also be a trespasser
External



From the internet
From partners on leased lines
From exposed WiFi


Hacking traditionally means manipulating
technology to do something it was not
originally intended to do
Ethical Hacking: Hack into a computer
network in order to test or evaluate its security,
rather than with malicious or criminal intent.
Source: Oxford Dictionaries

Focused on finding vulnerabilities
Uses many of the same tools and techniques as
criminals
 Penetration Testing is a subset of Ethical Hacking
 Penetration Testing and Ethical Hacking are often
used interchangeably
 Penetration Testing usually means going a bit
further then Ethical Hacking in order to prove a
system can be breached and data obtained


Generally focused on identifying
vulnerabilities without actually compromising
systems
Vulnerability Scanning
 Architectural Reviews
 Configuration Reviews
 Code Reviews
 Audits




Unlikely to crash systems
Staff performing these evaluations often bring
different and unique skill sets to the table
Different perspectives on the organization



Find vulnerabilities before the “Bad” guys do
Ensure management understands the risks in
their systems
Informs Security Operations as to what to look
for in their monitoring systems

Security Operations is often not informed of work to
test if appropriate monitoring is in place


Document the findings
From the client perspective:
Document issues
 Develop action plans
 Mitigate
OR
 Risk Acceptance








Infrastructure (Network)
Web
Dial-Up (War Driving)
Wireless
Social Engineering
Physical
Application

Reconnaissance


Scanning


What technology is in use in the target environment
What vulnerabilities exist within the target
environment
Exploitation

Can the vulnerabilities be used

Malicious attackers go further
Maintaining access
 Covert Channels
 Infiltrating Data
 Covering Tracks




Phases are not usually this clean
Some jumping around is to be expected
Skilled testers often get a feel for where
vulnerabilities may exist based on their
experience in similar systems

Penetration Testing can’t find everything





Limited time
Limited scope
Some vulnerabilities are only exposed in specific
conditions that may not exist at the time of testing
Testers have different strengths and weaknesses
Some techniques will be off-limits due to potential
negative impacts on a target environment


Tool sets only find known vulnerabilities
Few tester have the skill set to find unknown
vulnerabilities and develop custom attacks


Even fewer organizations want to fund this level of
investigation
May violate terms and conditions of software or
hardware licensing



A number of groups publish methodologies for testing
systems for vulnerabilities
Can be useful as guidelines for establishing how you pursue
testing
Examples:

Open Source Security Testing Methodology Manual (OSSTMM)
 http://www.pen-tests.com/goto/link/125/1

OWASP Testing Framework
 https://www.owasp.org/index.php/The_OWASP_Testing_Framewor
k

NIST SP800-115
 http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf

Penetration Testing Framework
 http://www.pen-tests.com/penetration-testing-framework.html

Penetration Testing Framework 0.59
 http://www.vulnerabilityassessment.co.uk/Penetration%20Test.html

Software Tools
Hardware
Network Infrastructure

We will cover some basics




Adjust as needed to suite need
Dependent on type of targets and tests




Penetration Testers need to shift between
multiple operating systems
Some tools are only available on one platform
Some tools may be available on multiple
platforms, but work better (or worse) on
specific platforms
At a minimum, some Linux and Windows
proficiency is needed

Kali
BackTrack Reborn according to Offensive Security, the
providers of Kali
 Available at:

 http://www.kali.org/downloads/


Kali is large (2.9G), so give yourself some time
VMWare Player
Free for personal use, scroll down
 Available at:

 http://www.vmware.com/products/player/

If you already have VMWare Workstation that will
work as well



Many other tools are available
You will not need them in this class
If you go on to do penetration testing, you will
likely collect a number of tools



Be careful
Research tool before downloading
Run them in a test environment first

Exploit Database


Packet Storm


http://packetstormsecurity.com/
Pentest-Tools


http://www.exploit-db.com/
https://pentest-tools.com/home
Security Audit Systems

http://www.security-audit.com/blog/penetrationtesting-tools/
I am not endorsing these sites, just making you aware
of them.

US-CERT


National Vulnerability Database


http://cve.mitre.org/
Exploit Database


http://nvd.nist.gov/home.cfm
Mitre CVE


https://www.us-cert.gov/
http://www.exploit-db.com/
CVE Details

http://www.cvedetails.com/






Many commercial tools are available, for a
price
Tenable - Commercial version of Nessus
Qualys – Vulnerability Scanner (alternative to
Nessus)
Rapid7 – Commercial Metasploit
Core Security – Core Impact
HP – Fortify Code Scanner

Talk to your developers


May have already built scripts and tools
May already own some commercial tools that can be
leveraged


Not needed for this course
Consider building out a hardware lab
Free tools should be tested in a lab before using them
in testing
 Mimic what you expect to test
 Mix up OSs
 Does not need to be new equipment, recycle
 Good environment to continue learning


Dedicated machines for conducting tests




Not used for normal activity
Do not keep any sensitive information
May be tied up for long periods of time doing
scanning
If you expect to do a great deal of scanning,
consider a separate server dedicated to
scanning

Host Machines






Guest machines may be ideal for testing





VMWare Player
VMWare Workstation
ESX
ZEN
Microsoft Virtual PC
Can be built for test
Can be reset if corrupted
Can be deleted after testing
Can be duplicated if additional guests are need
We will go over setting up VMWare for testing in week
three




Many ISPs monitor traffic for malicious activity
Inform your ISP prior to starting Pen Testing
May need to move to a business account
May need to “negotiate” with the ISP




Cloud can be very effective for replicating
Distributed Denial of Service attacks
Will require permission form cloud provider or
your account may be closed
Cloud providers are reluctant to host
Penetration Testing activities
May be possible after some negotiations




Firewalls may block or minimize the
capabilities of penetration testing.
Pen testing activity, especially scanning, can
cause performance issues in firewalls
HTTP Proxies may alter encoding
Next Generation firewalls (Like PaloAlto) may
perform analysis and drop packets that are not
well formed.

Avoid using firewalls on your test network and
attack machines



May block activity before it ever leaves your systems
Since this exposes test machines to attack, use a
separate, off-network machine to take notes.
Utilize USB drives to transfer information





Machines in you testing network should be
baselined and locked down as much as possible
Keep patching up to date
Turn off all unnecessary ports and services
Increase security settings where possible
Center for Internet Security provides some
guidelines


http://www.cisecurity.org/
Microsoft Baseline Security Analyzer also helps

http://www.microsoft.com/enus/download/details.aspx?id=7558


Consider encrypting test findings as they
accumulate
Example

PGP
 http://buy.symantec.com/estore/clp/smb_d4v2_9p9s_pgpe
ncryption1_default

BitLocker
 http://windows.microsoft.com/en-
US/windows7/products/features/bitlocker

Encryption technologies are changing, stay up to
date on what works, and what has been broken

When an engagement ends


Move test results off of systems
Scrub systems thoroughly
Secure Deletion
 Reimage
 Revert to baseline

Note: Consider using Solid State Drive w/ Trim
turned on, faster and deleted data auto zero’s

Preparation






Testing


NDAs if applicable
Client concerns
Rules of Engagement
Scope
Written Permission and Acknowledgement of Testing
Risks
Perform Test
Conclusion
Analyze results and retest as needed
 Develop report and presentation if needed


Vital that written permission be obtained



Without this you could be held criminally
responsible
Good intentions are no defense
Ensure individual granting permission has the
authority to do so



Corporate Officer
Director
P&L Responsibility


Permission alone is not sufficient
If you are not working “In-House”

Contract language needs Limitation of Liability
language
 Time to call in the lawyers

You, or the company you work for will also need
liability insurance

At a minimum



Contact Information
Periodic Debriefing (Daily?)
Dates and Times for Testing
 When to start
 When to stop
 Hours when testing is acceptable

Announced or Unannounced

What if Sys Admins detect testing and attempt to
block.
Is this good, or bad?
 Stop test, or remove blocks and keep testing?


Verify if client IDS,
IPS,
orCreep
WAF may block attacks
and
Scope
This may be OK if test was focused on effectiveness of
these systems
 However:

 Could cause Denial of Service
 Resource consumption

May need to get you traffic excluded from protections to
test systems behind these controls

Black Box:




No data provided to tester other then target IP
Address or URL
Mimics malicious attackers vantage point
Time and resource consuming
Crystal Box:



Tester provided detailed data on systems and
architecture
Allows tester to quickly move to value added work
May not uncover data leaked into public space that
would have been found during reconnaissance
phase

How far should test team go?






Configuration Data
User Info
PII
Should likely stop at configuration data
Testers do have a responsibility to not go past
agreed to boundaries
Also applies to sniffer data

Is a client representative going to observe all
testing



Ensure client data is protected
Inform testers that some area may be off limits
Is client staff going to work with testing team

Client may want their staff to become familiar with
tolls and methodology



Establish agreement on issues prior to starting
Document the agreement and get sign-off from
all parties
Congratulations – You now have your Rules of
Engagement, remember that from slide 46

Identify Client Security Concerns
Disclosure?
 Availability?
 Reputation?
 Financial Loss?
 Other?


Only the client can tell you what they are really
worried about

Identify known issues


Do you need to verify them?
Identify likely threats
State Actors
 Disgruntled Employees


Determine what to focus on


Determine clear and explicit scope
What to test
Which systems?
 Which address space?
 Individual hosts?


What to stay away from
Known “brittle” systems
 Critical systems



If third parties are to be tested, they need to
provide written permission
If out of scope, need to know who and what
they are to avoid them

This is a particular concern in web application
testing as sites routinely link or have content hosted
form third parties

Test environments offer lower risk of impact



May not match production
May respond slower, impacting test efficiency
May not be possible, as only a production system
exists

How hard are you going to try










Ping Sweeps
Port Scanning
Vulnerability Scanning
Penetration into Target
Application Level Attacks
Client Side Attacks
Business Logic
Physical
Social Engineering
Denial of Service


What about insider threats
Possibilities
Official site visit and granted access
 Onsite and breaks in
 WiFi
 Dial-In
 VPN
 Citrix
 Public Kiosk





Old process focused on servers and
infrastructure
More and more focus on client side testing
Can I pivot through a compromised client
browser (Think Target)
Can I target vulnerable staff? Or does the client
organizing want to provide a willing target to
accept the attack (and avoid embarrassing
employees)



Very powerful
Manipulating employees may impact morale,
but also may serve an awareness function
Client needs to think through and consider
pros and cons




Explicit written permissions
Defined goal, what are you after?
Develop several scripts and get them vetted by
client
Select the right tester
People person
 Someone others want to help
 Sympathetic





Dangerous to test
Often not done because it is already known
that systems can be knocked down
If in scope, ensure specifically documented as
“in scope”
Consider carving out a subsystem to test so as
not to take down entire client




Some tests are known to be dangerous
Nessus has separate category of vulnerabilities
it can scan for that are known to knock targets
of line
Some Metasploit attacks will either succeed or
crash the target system
Access testing can lock out users inadvertently

Always create a report


It may be the only evidence you where there
Will likely be around a long time
 Therefore, make sure it is clean, correct, and reflects
well on the effort you put in


Report may make the difference between repeat
engagement or no more engagements
Even if “In-House” create the report

Brands your team and their effort



Scanning reports may be included in an
appendix, but they should not constitute the
body of the report
Description of findings, with impact and
recommended mitigation go in the body of a
report
Don’t accept scanning result ratings at face
value.

May need to adjust based on other information
developed during test



Executive Summary
Introduction
Methodology


Findings



Ranked by severity
Recommendations
Conclusion


How did you do the testing
Clients often want to know how they stack up against
their vertical
Appendices (if needed)

Most important part of test


Keep it short



Management representatives may never read
beyond the summary
1 page, 1.5 at most
Briefly acknowledge test team and client
employees who participated
Summarize overall risk posture

Include bulleted list of most significant
findings


Three to six at most
Framed in terms of business impact
 Why does the line of business care about the risks
identified

Describe mitigation paths
 People
 Processes
 Technology




Screenshots or illustrations help capture
audience attention and make findings more
“real”
Only include “useful” screenshots
Focus on important area, zoom in
Mask are exclude sensitive information
Passwords
 User Names
 Employee or Customer Data
