7COSC001W Advanced Computer Forensics Assignment

7COSC001W Advanced Computer Forensics Assignment Specification

University of Westminster

School of Electronics and Computer Science

7COSC001W       –       Advanced       Computer       Forensics Assignment Specification (2021/22)
Module lecturer	Umar Mukhtar Ismail
Unit	Coursework 2
Weighting:	50%
Qualifying mark	40%
Description	Lab-based Portfolio
Learning              Outcomes Covered in this Assignment:	LO1, LO2 and LO3
Handed Out:	Thursday 16th March 2023
Due Date	Thursday 27th April 2023 at 13:00
Expected deliverables	Single Report
Method of Submission:	Electronic submission on tunrnitin (in PDF format) name your file with your student number and the module code. i.e.: W000000000_7COSC001W
Type of Feedback and Due Date:	Written feedback and marks will be given 15 working day (3 Weeks) after the submission deadline. All marks will remain provisional until formally agreed by an Assessment Board.

Assessment regulations

Refer to section 4 of the “How you study” guide for undergraduate students for a clarification of how you are assessed, penalties and late submissions, what constitutes plagiarism etc.

Penalty for Late Submission

If you submit your coursework late but within 24 hours or one working day of the specified deadline, 10 marks will be deducted from the final mark, as a penalty for late submission, except for work which obtains a mark in the range 40 – 49%, in which case the mark will be capped at the pass mark (50%). If you submit your coursework more than 24 hours or more than one working day after the specified deadline you will be given a mark of zero for the work in question unless a claim of Mitigating Circumstances has been submitted and accepted as valid.

It is recognised that on occasion, illness or a personal crisis can mean that you fail to submit a piece of work on time. In such cases you must inform the Campus Office in writing on a mitigating circumstances form, giving the reason for your late or non- submission. You must provide relevant documentary evidence with the form. This information will be reported to the relevant Assessment Board that will decide whether the mark of zero shall stand. For more detailed information regarding University Assessment Regulations, please refer to the following website:http://www.westminster.ac.uk/study/current- students/resources/academic- regulations

Assignment 2 Compromised Device Investigation

Scenario:

The IT manager of ABC of a company new start-up SME based in London with an E-commerce model has recently noticed anomalies and reported suspicious digital activities in their accounting and product records. As per the incident report, it is said that suspicious intrusion attempts have been detected. The IT team has undertaken an initial check of system log files and there are several suspicious entries that are generated by various types of security tools such as firewalls, IPS devices, routers switches and servers.

As there is increased competition in the hi-tech domain, the company is anxious to ensure that their systems are not being compromised, and they have employed a digital forensic investigator to determine whether any malicious activity has taken place, and to ensure that there is no malware within their systems.

ABC has engaged XYZ Forensic Solutions as a company that specializes in a broad range of digital forensic capabilities to provide an extensive investigation of the incident. As part of the team member of XYZ Forensic Solutions, your manager wants you to carry out a preliminary analysis of log files generated by certain security tools to have to establish whether you can trace the cause of the problems, and if necessary, to prepare a case against the perpetrators. To support your investigation, your manager has provided all the required resources (such as VM and log files) including a detailed set of activities and steps. Specifically, you are asked to:

1. Activity 1: Conduct a Snort and Firewall Rules analysis (55 Marks)
2. Activity 2: Analyze pre-captured logs and traffic captures (25 Marks)
3. Activity 3: Identify and evaluate any limitations related to log analysis, and provide a personal reflection of how forensic examination can improve the overall cyber security efforts of the company (20 Marks)

Each activity consists of one or more parts with multiple exercises. You are required to complete all the parts in each activity.

Section 1 – Conduct Snort and Firewall Rules

Objectives

Part 1: Preparing the Virtual Environment

Part 2: Firewall and IDS Logs

Part 3: Terminate and Clear Mininet Process

Required Resources

• CyberOps Workstation VM
• Internet connection

Part 1: Preparing the Virtual Environment

1. Launch Oracle VirtualBox and change the CyberOps Workstation for Bridged mode, if necessary. Select Machine > Settings > Network. Under Attached To, select Bridged Adapter (or if you are using WiFi with a proxy, you may need NAT adapter) and click OK.
2. Launch the CyberOps Workstation VM, open a terminal and configure its network by executing the configure_as_dhcp.sh script.

Because the script requires super-user privileges, provide the password for the user analyst.

[analyst@secOps ~]$ sudo ./lab.support.files/scripts/configure_as_dhcp.sh[sudo] password for analyst:

[analyst@secOps ~]$

• Use the ifconfig command to verify CyberOps Workstation VM now has an IP address on your local network. You can also test connectivity to a public webserver by pinging www.cisco.com. Use Ctrl+C to stop the pings.

[analyst@secOps ~]$ ping www.cisco.com

PING e2867.dsca.akamaiedge.net (23.204.15.199) 56(84) bytes of data.

64    bytes    from    a23-204-15-199.deploy.static.akamaitechnologies.com (23.204.15.199): icmp_seq=1 ttl=54 time=28.4 ms

64    bytes    from    a23-204-15-199.deploy.static.akamaitechnologies.com (23.204.15.199): icmp_seq=2 ttl=54 time=35.5 ms

^C

— e2867.dsca.akamaiedge.net ping statistics —

2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 28.446/32.020/35.595/3.578 ms

Part 2: Firewall and IDS Logs

Firewalls and Intrusion Detection Systems (IDS) are often deployed to partially automate the traffic monitoring task. Both firewalls and IDSs match incoming traffic against administrative rules. Firewalls usually compare the packet header against a rule set while IDSs often use the packet payload for rule set comparison. Because firewalls and IDSs apply the pre-defined rules to different portions of the IP packet, IDS and firewall rules have different structures.

While there is a difference in rule structure, some similarities between the components of the rules remain. For example, both firewall and IDS rules contain matching components and action components. Actions are taken after a match is found.

• Matching component – specifies the packet elements of interest, such as: packet source; the packet destination; transport layer protocols and ports; and data included in the packet payload.
• Action component – specifies what should be done with that packet that matches a component, such as: accept and forward the packet; drop the packet; or send the packet to a secondary rule set for further inspection.

A common firewall design is to drop packets by default while manually specifying what traffic should be allowed. Known as dropping-by-default, this design has the advantage protecting the network from unknown protocols and attacks. As part of this design, it is common to log the events of dropped packets since these are packets that were not explicitly allowed and therefore, infringe on the organization’s policies. Such events should be recorded for future analysis.

Step 1: Real-Time IDS Log Monitoring

1. From the CyberOps Workstation VM, run the script to start mininet.

[analyst@secOps ~]$ sudo

./lab.support.files/scripts/cyberops_extended_topo_no_fw.py

[sudo] password for analyst:

*** Adding controller

*** Add switches

*** Add hosts

*** Add links

*** Starting network

*** Configuring hosts

R1 R4 H1 H2 H3 H4 H5 H6 H7 H8 H9 H10 H11

*** Starting controllers

*** Starting switches

*** Add routes

*** Post configure switches and hosts

*** Starting CLI:

mininet>

The mininet prompt should be displayed, indicating mininet is ready for commands.

• From the mininet prompt, open a shell on R1 using the command below:

mininet> xterm R1

mininet>

Step 1: The R1 shell opens in a terminal window with black text and white background. What user is logged into that shell? What is the indicator of this? [5 Marks]

• From R1’s shell, start the Linux-based IDS, Snort.

[root@secOps analyst]# ./lab.support.files/scripts/start_snort.sh

Running in IDS mode

–== Initializing Snort ==– Initializing Output Plugins! Initializing Preprocessors! Initializing Plug-ins!

Parsing Rules file “/etc/snort/snort.conf”

<output omitted>

Note: You will not see a prompt as Snort is now running in this window. If for any reason, Snort stops running and the [root@secOps analysts]# prompt is displayed, rerun the script to launch Snort. Snort must be running in order to capture alerts later in the lab.

• From the CyberOps Workstation VM mininet prompt, open shells for hosts H5 and H10.

mininet> xterm H5 mininet> xterm H10 mininet>

• H10 will simulate a server on the Internet that is hosting malware. On H10, run the

mal_server_start.sh script to start the server.

[root@secOps analyst]# ./lab.support.files/scripts/mal_server_start.sh [root@secOps analyst]#

• On H10, use netstat with the -tunpa options to verify that the web server is running. When used as shown below, netstat lists all ports currently assigned to services:

[root@secOps analyst]# netstat -tunpa

Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address            Foreign Address          State PID/Program name

tcp        0      0 0.0.0.0:6666             0.0.0.0:*                LISTEN

1839/nginx: master

[root@secOps analyst]#

As seen by the output above, the lightweight webserver nginx is running and listening to connections on port TCP 6666.

• In the R1 terminal window, an instance of Snort is running. To enter more commands on R1, open another R1 terminal by entering the xterm R1 again in the CyberOps Workstation VM terminal window, as shown below. You may also want to arrange the terminal windows so that you can see

and interact with each device. The figure below shows an effective arrangement for the rest of this lab.

• In the new R1 terminal tab, run the tail command with the -f option to monitor the /var/log/snort/alert

file in real-time. This file is where snort is configured to record alerts.

[root@sec0ps analyst]# tail -f /var/log/snort/alert

Because no alerts were yet recorded, the log should be empty. However, if you have run this lab before, old alert entries may be shown. In either case, you will not receive a prompt after typing this command. This window will display alerts as they happen.

1. From H5, use the wget command to download a file named W32.Nimda.Amm.exe. Designed to download content via HTTP, wget is a great tool for downloading files from web servers directly from the command line.

[root@secOps analyst]# wget 209.165.202.133:6666/W32.Nimda.Amm.exe

–2017-04-28 17:00:04– http://209.165.202.133:6666/W32.Nimda.Amm.exe

Connecting to 209.165.202.133:6666… connected. HTTP request sent, awaiting response… 200 OK Length: 345088 (337K) [application/octet-stream] Saving to: ‘W32.Nimda.Amm.exe’

W32.Nimda.Amm.exe            100%[==========================================>] 337.00K –.-KB/s     in 0.02s

2017-04-28 17:00:04 (16.4 MB/s) – ‘W32.Nimda.Amm.exe’ saved [345088/345088]

[root@secOps analyst]#

Step 2: What port is used when communicating with the malware web server? What is the indicator? [5 Marks]

Step 3: Was the file completely downloaded? [2 Marks]                                                              Step 4: Did the IDS generate any alerts related to the file download? [3 Marks]                           

• As the malicious file was transiting R1, the IDS, Snort, was able to inspect its payload. The payload matched at least one of the signatures configured in Snort and triggered an alert on the second R1 terminal window (the tab where tail -f is running). The alert entry is show below. Your timestamp will be different:

04/28-17:00:04.092153 [**] [1:1000003:0] Malicious Server Hit! [**] [Priority: 0]

{TCP} 209.165.200.235:34484 -> 209.165.202.133:6666

Step 5: Based on the alert shown above, what was the source and destination IPv4 addresses used in the transaction? [5 Marks]

Step 6: Based on the alert shown above, what was the source and destination ports used in the transaction? [5 Marks]

Step 7: Based on the alert shown above, when did the download take place? [5 Marks]

Step8: Based on the alert shown above, what was the message recorded by the IDS signature?

[5 Marks]

On H5, use the tcpdump command to capture the event and download the malware file again so you can capture the transaction. Issue the following command below start the packet capture:

[root@secOps analyst]# tcpdump –i H5-eth0 –w nimda.download.pcap &

[1] 5633

[root@secOps analyst]# tcpdump: listening on H5-eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

The command above instructs tcpdump to capture packets on interface H5-eth0 and save the capture to a file named nimda.download.pcap.

The & symbol at the end tells the shell to execute tcpdump in the background. Without this symbol, tcpdump would make the terminal unusable while it was running. Notice the [1] 5633; it indicates one process was sent to background and its process ID (PID) is 5366. Your PID will most likely be different.

• Press ENTER a few times to regain control of the shell while tcpdump runs in background.
• Now that tcpdump is capturing packets, download the malware again. On H5, re-run the command or use the up arrow to recall it from the command history facility.

[root@secOps analyst]# wget 209.165.202.133:6666/W32.Nimda.Amm.exe

–2017-05-02 10:26:50– http://209.165.202.133:6666/W32.Nimda.Amm.exe

Connecting to 209.165.202.133:6666… connected. HTTP request sent, awaiting response… 200 OK Length: 345088 (337K) [application/octet-stream] Saving to: ‘W32.Nimda.Amm.exe’

W32.Nimda.Amm.exe    100%[===================>] 337.00K –.-KB/s      in 0.003s

2017-05-02 10:26:50 (105 MB/s) – ‘W32.Nimda.Amm.exe’ saved [345088/345088]

• Stop the capture by bringing tcpdump to foreground with the fg command. Because tcpdump was the only process sent to background, there is no need to specify the PID. Stop the tcpdump process with Ctrl+C. The tcpdump process stops and displays a summary of the capture. The number of packets may be different for your capture.

[root@secOps analyst]# fg

tcpdump -i h5-eth0 -w nimda.download.pcap

^C316 packets captured

316 packets received by filter

0 packets dropped by kernel [root@secOps analyst]#

• On H5, Use the ls command to verify the pcap file was in fact saved to disk and has size greater than zero:

[root@secOps analyst]# ls -l

total 1400

drwxr-xr-x 2 analyst analyst    4096 Sep 26 2014 Desktop

drwx—— 3 analyst analyst    4096 Jul 14 11:28 Downloads

drwxr-xr-x 8 analyst analyst    4096 Jul 25 16:27 lab.support.files

-rw-r–r– 1 root     root    371784 Aug 17 14:48 nimda.download.pcap drwxr-xr-x 2 analyst analyst    4096 Mar 3 15:56 second_drive

-rw-r–r– 1 root     root    345088 Apr 14 15:17 W32.Nimda.Amm.exe

-rw-r–r– 1 root     root    345088 Apr 14 15:17 W32.Nimda.Amm.exe.1 [root@secOps analyst]#

Note: Your directory list may have a different mix of files, but you should still see the

nimda.download.pcap file.

Step 9: How can be this PCAP file be useful to the security analyst? [5 Marks]

Note: The analysis of the PCAP file will be performed in another lab.

Step 2: Tuning Firewall Rules Based on IDS Alerts

In Step 1, you started an Internet-based malicious server. To keep other users from reaching that server, it is recommended to block it in the edge firewall.

In this lab’s topology, R1 is not only running an IDS but also a very popular Linux-based firewall called iptables. In this step, you will block traffic to the malicious server identified in Step 1 by editing the firewall rules currently present in R1.

Note: While a comprehensive study of iptables is beyond the scope of this course, iptables basic logic and rule structure is fairly straight-forward.

The firewall iptables uses the concepts of chains and rules to filter traffic.

Traffic entering the firewall and destined to the firewall device itself is handled by the INPUT chain. Examples of this traffic are ping packets coming from any other device on any networks and sent to any one of the firewall’s interfaces.

Traffic originated in the firewall device itself and destined to somewhere else, is handled by the OUTPUT

chain. Examples of this traffic are ping responses generated by the firewall device itself.

Traffic originated somewhere else and passing through the firewall device is handled by the FORWARD

chain. Examples of this traffic are packets being routed by the firewall.

Each chain can have its own set of independent rules specifying how traffic is to be filtered for that chain. A chain can have practically any number of rules, including no rule at all.

Rules are created to check specific characteristics of packets, allowing administrators to create very comprehensive filters. If a packet doesn’t match a rule, the firewall moves on to the next rule and checks again. If a match is found, the firewall takes the action defined in the matching rule. If all rules in a chain have been checked and yet no match was found, the firewall takes the action specified in the chain’s policy, usually allow the packet to flow through or deny it.

1. In the CyberOps Workstation VM, start a third R1 terminal window.

mininet > xterm R1

• In the new R1 terminal window, use the iptables command to list the chains and their rules currently in use:

[root@secOps ~]# iptables -L -v

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)

pkts bytes target      prot opt in     out     source                destination

Chain FORWARD (policy ACCEPT 6 packets, 504 bytes)

pkts bytes target      prot opt in     out     source                destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)

pkts bytes target      prot opt in     out     source                destination

[root@secOps ~]#

Step 10: What chains are currently in use by R1? [5 Marks]

• Connections to the malicious server generate packets that must transverse the iptables firewall on R1. Packets traversing the firewall are handled by the FORWARD rule and therefore, that is the chain that will receive the blocking rule. To keep user computers from connecting to the malicious server identified in Step 1, add the following rule to the FORWARD chain on R1:

[root@secOps ~]# iptables -I FORWARD -p tcp -d 209.165.202.133 –dport 6666

-j DROP

[root@secOps ~]#

Where:

• -I FORWARD: inserts a new rule in the FORWARD chain.
• -p tcp: specifies the TCP protocol.
• -d 209.165.202.133: specifies the packet’s destination
• –dport 6666: specifies the destination port
• -j DROP: set the action to drop.
• Use the iptables command again to ensure the rule was added to the FORWARD chain. The CyberOps Workstation VM may take a few seconds to generate the output:

[root@secOps analyst]# iptables -L -v

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)

pkts bytes target      prot opt in     out     source                destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)

pkts bytes target      prot opt in     out     source                destination

tcp dpt:6666

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)

pkts bytes target      prot opt in     out     source                destination

[root@secOps analyst]#

• On H5, try to download the file again:

[root@secOps analyst]# wget 209.165.202.133:6666/W32.Nimda.Amm.exe

–2017-05-01 14:42:37– http://209.165.202.133:6666/W32.Nimda.Amm.exe

Connecting to 209.165.202.133:6666… failed: Connection timed out. Retrying.

–2017-05-01 14:44:47– (try: 2) http://209.165.202.133:6666/W32.Nimda.Amm.exe

Connecting to 209.165.202.133:6666… failed: Connection timed out. Retrying.

Step 11: Enter Ctrl+C to cancel the download, if necessary. Was the download successful this time? Explain. [5 Marks]

Step 12: What would be a more aggressive but also valid approach when blocking the offending server?

[5 Marks]

Part 3: Terminate and Clear Mininet Process

1. Navigate to the terminal used to start Mininet. Terminate the Mininet by entering quit in the main CyberOps VM terminal window.
2. After quitting Mininet, clean up the processes started by Mininet. Enter the password cyberops when prompted.

[analyst@secOps scripts]$ sudo mn –c

[sudo] password for analyst:

Activity 2 – Extract an Executable from a PCAP

Objectives

Part 1: Prepare the Virtual Environment

Part 2: Analyze Pre-Captured Logs and Traffic Captures

Background / Scenario

In this activity, you will analyze the traffic in a previously captured pcap file and extract an executable from the file.

Part 1: Prepare the Virtual Environment

1. Launch Oracle VirtualBox. Right-click CyberOps Workstion > Settings > Network. Besides Attached To, select Bridged Adapter, if necessary, and click OK.
2. Log in to the CyberOps Workstation VM (username: analyst / password: cyberops), open a terminal, and run the configure_as_dhcp.sh script.

[analyst@secOps ~]$ sudo ./lab.support.files/scripts/configure_as_dhcp.sh

[sudo] password for analyst:

[analyst@secOps ~]$

Part 2: Analyze Pre-Captured Logs and Traffic Captures

In Part 2, you will work with the nimda.download.pcap file. Captured in a previous lab, nimda.download.pcap contains the packets related to the download of the Nimda malware. Your version of the file, if you created it in the previous lab and did not reimport your CyberOps Workstation VM, is stored in the /home/analyst directory. However, a copy of that file is also stored in the CyberOps Workstation VM, under the /home/analyst/lab.support.files/pcaps directory so that you can complete this lab regardless of whether you completed the previous lab or not. For consistency of output, the lab will use the stored version in the pcaps directory.

While tcpdump can be used to analyze captured files, Wireshark’s graphical interface makes the task much easier. It is also important to note that tcpdump and Wireshark share the same file format for packet captures; therefore, PCAP files created by one tool can be opened by the other.

1. Change directory to the lab.support.files/pcaps folder, and get a listing of files using the ls –l

command.

[analyst@secOps ~]$ cd lab.support.files/pcaps

[analyst@secOps pcaps]$ ls -l

total 7460

-rw-r–r– 1 analyst analyst 3510551 Aug 7 15:25 lab_prep.pcap

-rw-r–r– 1 analyst analyst 371462 Jun 22 10:47 nimda.download.pcap

-rw-r–r– 1 analyst analyst 3750153 May 25 11:10 wannacry_download_pcap.pcap

[analyst@secOps pcaps]$

• Issue the command below to open the nimda.download.pcap file in Wireshark.

[analyst@secOps pcaps]$ wireshark-gtk nimda.download.pcap

• The nimda.download.pcap file contains the packet capture related to the malware download performed in a previous lab. The pcap contains all the packets sent and received while tcpdump was running. Select the fourth packet in the capture and expand the Hypertext Transfer Protocol to display as shown below.

• Packets one through three are the TCP handshake. The fourth packet shows the request for the malware file. Confirming what was already known, the request was done over HTTP, sent as a GET request.

• Because HTTP runs over TCP, it is possible to use Wireshark’s Follow TCP Stream feature to rebuild the TCP transaction. Select the first TCP packet in the capture, a SYN packet. Right-click it and choose Follow TCP Stream.

• Wireshark displays another window containing the details for the entire selected TCP flow.

Step 13: What are all those symbols shown in the Follow TCP Stream window? Are they connection noise? Data? Explain. [10 Marks]

There are a few readable words spread among the symbols. Why are they there? [5 Marks]

Step 14: Challenge Question: Despite the W32.Nimda.Amm.exe name, this executable is not the famous worm. For security reasons, this is another executable file that was renamed as W32.Nimda.Amm.exe. Using the word fragments displayed by Wireshark’s Follow TCP Stream window, can you tell what executable this really is? [5 Marks]

• Click Close in the Follow TCP Stream window to return to the Wireshark nimda.download.pcap file.

Part 3: Extract Downloaded Files From PCAPS

Because capture files contain all packets related to traffic, a PCAP of a download can be used to retrieve a previously downloaded file. Follow the steps below to use Wireshark to retrieve the Nimda malware.

1. In that fourth packet in the nimda.download.pcap file, notice that the HTTP GET request was generated from 209.165.200.235 to 209.165.202.133. The Info column also shows this is in fact the GET request for the file.

• With the GET request packet selected, navigate to File > Export Objects > HTTP, from Wireshark’s menu.

• Wireshark will display all HTTP objects present in the TCP flow that contains the GET request. In this case, only the W32.Nimda.Amm.exe file is present in the capture. It will take a few seconds before the file is displayed.

Step 15: Why is W32.Nimda.Amm.exe the only file in the capture? [5 Marks]

• In the HTTP object list window, select the W32.Nimda.Amm.exe file and click Save As at the bottom of the screen.
• Click the left arrow until you see the Home button. Click Home and then click the analyst folder (not the analyst tab). Save the file there.
• Return to your terminal window and ensure the file was saved. Change directory to the /home/analyst

folder and list the files in the folder using the ls -l command.

[analyst@secOps pcaps]$ cd /home/analyst

[analyst@secOps ~]$ ls –l

total 364

drwxr-xr-x	2	analyst	analyst	4096	Sep	26	2014	Desktop
drwx——	3	analyst	analyst	4096	May	25	11:16	Downloads
drwxr-xr-x	2	analyst	analyst	4096	May	22	08:39	extra
drwxr-xr-x	8	analyst	analyst	4096	Jun	22	11:38	lab.support.files
drwxr-xr-x	2	analyst	analyst	4096	Mar	3	15:56	second_drive

-rw-r–r– 1 analyst analyst 345088 Jun 22 15:12 W32.Nimda.Amm.exe [analyst@secOps ~]$

Step 16: Was the file saved? [5 Marks]

                                                                                                                                                 –

• The file command gives information on the file type. Use the file command to learn a little more about the malware, as show below:

[analyst@secOps ~]$ file W32.Nimda.Amm.exe

W32.Nimda.Amm.exe: PE32+ executable (console) x86-64, for MS Windows [analyst@secOps ~]$

As seen above, W32.Nimda.Amm.exe is indeed a Windows executable file.

Step 17: In the malware analysis process, what would be a probable next step for a security analyst?

[5 Marks]

Activity 3 – Evaluation and Personal Reflection

Identify and evaluate any limitations related to log analysis, and provide a personal reflection of how forensic examination can improve the overall cyber security efforts of the company

Learning Outcomes

The following Learning outcomes will be addressed in this assignment:

• L01 utilize effectively appropriate tools to gather and analyse forensic data from a variety of sources, including network hardware and software.

• L02 think creatively to develop appropriate computer forensics tools to analyse data from new and developing areas of forensics.

• L03 critically evaluate recent advances in the methods and techniques employed in computer forensics.

Coursework marking Scheme

The coursework will be marked based on the following marking criteria

Step	Parameter	Maximum mark	Comments
1	Review of user logged into shell	5	What user was logged into that shell?
2	Used Port in communicating with malware server	5	What is the indicator
3	File download	5	Was the file downloaded?
4	IDS alerts	5	Did the IDS generate alerts?
5	Source and destination IPv4 addresses	5	What was the source and destination IPv4 addresses used in the transaction?
6	Source and destination ports	5	what was the source and destination ports used in the transaction?
7	Download time	5	When did the download take place?
8	IDS signature message	5	what was the message recorded by the IDS signature
9	PCAP File usefulness	5	How can be this PCAP file be useful to the security analyst?
10	R1 Terminal Window	5	What chains are currently in use by R1?
11	File download	5	Was the download successful this time?
12	Blocking the offending server	5	What would be a more aggressive but also valid approach when blocking the offending server?
13	TCP Stream Window	5	What are all those symbols shown in the Follow TCP Stream window?
14	Wireshark’s      Follow      TCP Stream	5	Can you tell what executable this really is?
15	Nimda.Amm.exe file capture	5	Why is W32.Nimda.Amm.exe the only file in the capture?
16	Nimda.Amm.exe file save	5	Was the file saved?
17	Malware analysis	5	What would be a probable next step for a security analyst?
18	Evaluation      and      personal reflection	20
	Total	100

Assessment Regulations

Refer to section 4 of the How you Study guide for a clarification of how you are assessed, penalised for late submissions and what constitutes plagiarism.

Penalty for late Submission

If you submit your coursework late but within 24 hours or one working day of the specified deadline, 10 marks will be deducted from the final mark, as a penalty for late submission, except for work which obtains a mark in the range of 40-49%, in which case the mark will be capped at the pass mark (50%). if you submit your coursework after more than 24 of the specified deadline, you will be given a mark of zero of the work in question unless a claim of mitigating circumstances has been submitted and accepted as valid.