COIT20262 – Advanced Network Security

COIT20262 – Advanced Network Security, Term1, 2026

Assignment 1 Submission

Student Name:                        enter your name

Student ID:                 id

Campus:                      campus

Tutor:                          tutor

• HTTP Interception

Part (a)

The HTTP packet capture file has been saved and submitted as:

12271720-http.pcap

This file contains the HTTP traffic captured while the student user logged into the MyUni grading website, accessed the grades section, and viewed the grade query page.

Part (b)

Part (c)

Wireshark was used to analyse the packet capture to determine the user’s actions on the web application. The analysis shows that a user from IP address 192.168.1.11 accessed a web server at 192.168.2.21 hosting the domain www.12271720.edu. The user made a login attempt via an HTTP POST to /grades/login.php, where the username and password were sent in plain text. The user name 12271720 and password manichandukeetha were transmitted in clear text in the packet capture.

The web server replied with an HTTP 302 redirection, which showed a successful login. A cookie was created, which contained the user name and a session ID. This cookie was then used again to confirm that the session had not expired. The user requested /grades/index.php, which contained a welcome message and links.

It is then shown that the user visited /grades/query.php, the grades page. The session cookie was sent with the request, so the user was logged in. The returned page contained a form with the value of the student ID set to 12271720, which shows that it was ready to display the grades.

This examination shows that critical data such as login data and session cookies were sent in clear text over HTTP. This poses a security vulnerability as a network sniffer could intercept this information and gain unauthorised access to the system.

• Vulnerability analysis using Nessus

Part (a)

Nessus was installed on Kali and a Basic Network Scan was run on the Metasploitable2 machine at 172.16.1.35. A number of critical vulnerabilities were found on the ms2 machine. The main critical issues were UnrealIRCd Backdoor Detection, Canonical Ubuntu Linux SEoL 8.04.x, VNC Server “password” Password, SSL Version 2 and 3 Protocol Detection, and Bind Shell Backdoor Detection.

The highest priority vulnerability was UnrealIRCd Backdoor Detection, with a CVSS score of 10. This is serious because it could allow an attacker to run commands remotely via the IRC service. There was also a bind shell backdoor detected by Nessus, which is critical because it may allow an attacker to gain shell access to the system. The VNC password detection indicates poor password selection, so an attacker could potentially access the machine remotely, if the password is guessed or reused. SSLv2 and SSLv3 also indicates that the server is using older encryption protocols.

Part (b)

The Nessus scan was also performed on two private devices. One scan was done on a laptop and the other on a router. The results of the scans were documented through screenshots of the Nessus results pages.

The laptop scan showed a variety of informational and service-based findings. These findings include HTTP Multiple Issues, Service Detection, Nessus SYN Scanner, OS Identification, and Ethernet MAC Address detection. This analysis demonstrates that Nessus detected services and system information, but that the results didn’t reveal the same critical vulnerabilities as the ms2 scan.

The router scan returned several issues including mDNS Detection, SSL Multiple Issues, TLS Multiple Issues, HTTP Multiple Issues, Embedded Web Server Detection and nginx HTTP Server Detection. These results suggest that it is likely to have web services or management. While the results were mostly informational or medium priority, they remain important as web services can be a security risk if the firmware is not current or if there are insecure configurations in place.

Part (c)

First key vulnerability is HTTP Multiple Issues. It is key as HTTP can provide cleartext management pages or data. This can be prevented by ensuring HTTPS only is used, avoid any unnecessary HTTP connections and only allow management pages from trusted sources.

The second vulnerability is SSL/TLS Multiple Issues. This means that the device may be using weak or old encryption. This should be addressed by turning off weak SSL and TLS, switching on recent TLS and updating the firmware (if device) or server.

The next critical vulnerability is mDNS Detection. This can be used to detect device names and services. We recommend turning off mDNS where possible, particularly on the router, and only allow service detection on local networks.

• Cryptography

Part (a)

All generated files were included in the submission ZIP. The files created include:

The message file had my full name and ID. A new RSA key pair was generated and the message was signed, using SHA256. The message was encrypted using AES-256-CBC and the AES key and IV were encrypted using the partner’s public key.

The partner’s public key was used to successfully verify the message. The OpenSSL command line returned Verified OK, which means that the message is authentic and has not been modified. The decrypted message also matches the original, with the student’s ID, name and the course code. This confirms the integrity and authenticity of the message.

Part (b)

The only challenging part was realizing how keys are used in each step. The private key is needed to sign, and the partner’s public key to encrypt the AES key and IV. This was a bit confusing at first as RSA and AES were used as a hybrid.

The other issue was dealing with file formats. The AES key and IV need to be in hexadecimal format. One time, an invalid IV error was encountered due to a non-hex IV file. This halted decryption until it was fixed.

File naming also caused issues. Given all files were named according to the student ID, any mistake caused OpenSSL errors including file not found or invalid input. Proper naming and formatting was important to successfully complete this task.

Part (c)

The main weakness in this protocol is the exchange of public keys. AES key and IV are encrypted with partner’s public key. Using the incorrect public key, or having the key replaced by an intruder, could allow the encrypted information to be intercepted. This leaves open the possibility of a man-in-the-middle attack.

Another risk is with sensitive files. The private key, AES key and IV must be kept secret. If these keys are compromised, an attacker can decrypt a message or sign messages. To mitigate this risk, keys should be kept secure, and public keys should be verified by their fingerprints.

coit20262-T1 2026-A1

• Ransomware Research

Part (a)

The assigned article defines ransomware as a cyber security risk that can shut down an organisation’s ability to access its data and systems. The theme of the article is that ransomware is no longer just a technical issue. It is also a commercial risk because it can disrupt operations, leak confidential data, result in loss of trust and generate costs to recover from attacks. The article is interesting because it demonstrates that companies can be hurt more if their ransomware protection is not considered as part of a business strategy. So, it is not just that the bad guys are good, but that some organisations are not good enough.

The article also emphasises the need to plan before the attack. Preparation in the form of backups, access control, training, incident response and data loss prevention can all mitigate against the impact of ransomware. One of the key messages in the article is that you need to plan to recover. Without a tested backup and recovery process, or a plan to respond to an attack, an organisation may be forced to pay a ransom.

In general, the article suggests ransomware protection is an organisational responsibility. This should not be left in the hands of IT professionals after a breach. The most valuable part of the article is that it’s better to be prepared than forced to react under pressure when ransomware strikes.

Part (b)

The addational resource chosen is an article by the Center for Internet Security, which explains how to calculate ransomware risk. It notes that risk from ransomware should be measured in terms of both the threat of attack and its potential consequences. The resource supplements the required article by adding practicality to the notion of ransomware planning. Rather than just stating that organisations need to prepare, it notes that organisations need to assess risk and then consider how to enhance security.

This resource adds to the prescribed article by emphasising decision-making. It explains ransomware can cause costs beyond system restoration, such as fines, lost revenue and damage to reputation. This reinforces the prescribed article’s claim that ransomware is an organisational risk. The source also helps to demonstrate that organisations should deploy security controls according to risk, rather than according to a “one size fits all” approach.

Harvard reference

Center for Internet Security (n.d.) ‘How to Calculate Your Organization’s Ransomware Risk’. Available at: https://www.cisecurity.org/insights/blog/how-to-calculate-your-organizations-ransomware-risk

Part (c)

The two resources reveal ransomware will keep impacting organisations as services increasingly rely on digital systems, shared data and online access. Ransomware attacks in the future may lead to greater downtime, recovery costs, and the need for privacy protection. This is particularly critical for universities, hospitals, businesses and government services because downtime can impact multiple users. The bottom line is that the fight against ransomware needs to start before the event. Organisations must prepare backups, enhance access controls, train staff to recognise and avoid ransomware, keep software up-to-date, and have a response plan. Ransomware will also increase the importance of cyber risk management to organisations because poor planning can affect the operation, cost, compliance and reputation of a business.