CY 2550 - Foundations of Cybersecurity

Project: Forensics

This project is due at 11:59pm on Friday, April 9, 2021.

Description and Deliverables

In this project, you will play the role of digital forensic analyst. You will be given a bootable disk image that was captured from a server that may-or-may-not have been hacked and infected with malware. Your job is to traces the attacker's footsteps from the origin of the breach, all the way to their ultimate payload.

To receive full credit for this project, you will turn in a single file:

  1. A file named project8/answers.txt that contains the answers to the six questions posed below. This file must be signed using your GPG public key when it is committed to Github (described below).
The exact format of this deliverable is described in detail below.

Brief Introduction to Digital Forensics

Digital forensics is the art of investigating computer systems to identify and isolate evidence. Forensics has applications to law enforcement as well as compromise triage more generally. In the former case, law enforcement officers must follow strict protocols governing electronic evidence to maintain the "chain of custody" of any evidence that is obtained so that it is admissable in court. This often involves the use of specialized digital forensics equipment that has been certified for use in law enforcement contexts. In the latter case, the goal of triage is typically to determine how an attacker broke into a system, what they did while they had access, determining whether the attacker still has access (e.g., did they plant a backdoor or rootkit?), and ultimately disinfecting the system so that the attacker no longer poses a threat. You will engage in this latter task, i.e., triaging a compromised system.

Getting Started

In this project, you will play the role of a digital security expert who has been asked to forensically analyze a disk image that was captured from a compromised server. This server, owned and maintained by an employee of Happy Funtime Plastic Co., hosted a simple website that allowed people to upload and view images. However, the owner of the server began to notice strange behavior on the server, so they shut it down, cloned the hard drive to an image file, and sent the image to you for analysis. The disk image can be downloaded here: In most cases, digital forensic analysts would use tools that statically analyze a disk image, i.e., the analyst would analyze the files in the image without actually booting into the image's operating system, as this might disturb evidence. However, in this project you may simply boot into the image using VirtualBox or VMWare Player, then log in and begin your analysis. To do this in VirtualBox, open the VirtualBox software, click Import, and then select the server_image.ova file that you downloaded. You may leave all the import settings to their default values. After VirtualBox has imported the image, you will see a Project VM that is available in the left-hand menu in VirtualBox. Start it and wait for it to boot. The client was kind enough to make a user account for you to use to analyze the system: the username is forensics and the password is sparkbear. Note that the forensics account has sudo privileges, so you will have full access to the system. The sudo password is the same as the account login password. Once you are logged in you can begin your analysis.

Note that while this assignment simulates a server that has been hacked and infected with malware, it is perfectly safe. Booting into this system is not a security risk to you or your host operating system.


Question 1

As noted above, the primary purpose of this server was to host a photo sharing website for employees of HFPC. You can access this website by opening Firefox (or any other browser) in the virtual machine and visiting http://localhost. As you will see, this website allows people to upload pictures, and those pictures then appear on the site. The site is not very well engineered and it often doesn't work.

The HFPC employee who maintained this server believes that the attacker somehow broke into the server through this website, but is unsure how. Thus, you should begin your investigation here.

The web server uses the standard Apache web server software package. The configuration files for the Apache software are located in /etc/apache2/, and the files that compromise the website itself are located in /var/www/html/. Apache logs all incoming HTTP requests in the file /var/log/apache2/access.log; any requests that generate errors are logged in /var/log/apache2/error.log.

There is enough information left in these places to piece together how the attacker was able to initially breach the server. Once you've figured out how the initial breach occurred, move on to the next question.

Question 2

Your answer should be formatted like 17/Nov/2020:05:49:52 -0500.

Question 3

The attacker was able to do something to the server by exploiting the photo sharing website. Once this was accomplished, they were able to gain remote access to the server. There are various system logs in the /var/log/ folder that are useful for determining when the attacker remotely accessed the server, including /var/log/auth.log (the authentication log), /var/log/kern.log (the operating system kernel log), and /var/log/ufw.log (the system firewall log). Your answer should be formatted like Nov 11 09:42:35.

Question 4

In addition to the system logs that are available in /var/log/, most user accounts have a log of all the commands they have run in the past stored in the file ~/.bash_history. The Bash History often contains hints about what a given user account has been up to.

Question 5

The HFPC employee noticed that their server was compromised because the system firewall service, called Uncomplicated Firewall or UFW, kept shutting down. This is a telltale sign of compromise: attackers often try to disable security software running on their victims' machines. The employee tried to manually restart the firewall service, but to no avail. Restarting the server also did not fix the issue: as soon as the operating system booted, the firewall process immediately shut down. The only logical explanation is that some process that the attacker installed on the server keeps terminating the firewall. But how did this process restart itself after the server was rebooted?

One way to schedule processes to run periodically on Linux systems is the Cron tool. Cron is like an alarm clock: it can be configured to run other programs on a schedule, i.e. once a day, once a week, or once a minute. Cron has various configuration files, all located in /etc/. /etc/crontab is the system-wide Cron configuration file, and there are additional, per-process configuration files in the folders /etc/cron.d/, /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, and /etc/cron.monthly/.

Question 6

Attackers often attempt to hide their presence on compromised systems by installing rootkits or back doors. Rootkits are essentially cloaking devices: depending on their level of sophistication, they try to hide the various programs, processes, and user accounts created by the attacker. Back doors offer the attacker hidden ways to access the system or elevate their privileges, typically using methods that try to evade detection.

One way to achieve these ends is by modifying the system utilities that everyone uses to manage to their systems (e.g. programs like ls and ps). In this case, did the attacker attempt to back door any system utilities? One way to see if system programs have been modified is by running the debsums tool: it checks the cryptographic hash of all system files and compares them to a list of known-good hashes. debsums prints "FAILED" for any file that appears to have been modified.

File Format for answers.txt

To receive full credit on this assignment, you must turn in a single (ASCII formatted with Unix-style line breaks) text file named answers.txt that contains the answers to the six questions given above. Each answer should be on its own line. For example, your answers.txt file might look like the following:
17/Nov/2020:05:49:52 -0500
Jan. 21 15:10:49
Your file should contain exactly six lines. Lines 1 and 5 should name particular files/processes. Lines 4 and 6 should state the full path of a file. Lines 2 and 3 should be a date/time in exactly the format given above.

Signing git Commits

Your GPG signing key is used by others to verify that a file originates from you. In this part, we will learn how to sign our commits to GitHub. In principle, others can have greater assurance about software you have placed on GitHub if it is signed.

The first step is to add your GPG public key to GitHub. Login to your account, goto "Settings", then "SSH and GPG keys", and then click "New GPG Key." Paste your GPG public key into this window.

The second step is to setup your git client to use your GPG key to sign commits. From the list of GPG keys, copy the GPG key ID you'd like to use. In this example, the GPG key ID is D95955E703474D7F0CC01FD0BDE2B89DD18E214A:

$ gpg --list-secret-keys --keyid-format LONG Wilson
gpg: checking the trustdb
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
sec   rsa4096/BDE2B89DD18E214A 2021-01-19 [SC]
uid                 [ultimate] Christo Wilson (Professor at Northeastern) <>
ssb   rsa4096/89C601C710FF744B 2021-01-19 [E]
To set your GPG signing key in Git use the following command, substituting in the GPG key ID you’d like to use. In this example, the GPG key ID is D95955E703474D7F0CC01FD0BDE2B89DD18E214A:
$ git config --global user.signingkey 3AA5C34371567BD2
Now sign your commits by adding the -S option to git commit:
$ git add project5/answers.txt
$ git commit -S -m "your commit message"
$ git push

Submitting Your Project

To submit your project, do the following:
  1. Create a directory ~/cy2550/project8 in the folder corresponding to your git repository.
  2. Copy your answers.txt file to the ~/cy2550/project8 folder.
  3. Add these files to your repository, commit and sign them, and push the committed files to Github.
  4. Submit your repository to Gradescope.


This project is worth 10% of your final grade, broken down as follows (out of 100): Points can be lost for turning in files in incorrect formats (e.g. not UNIX-line break ASCII), failing to follow specified formatting and naming conventions, or encrypting/signing your file using the wrong keys.


If you feel stuck, or like you don't know where to begin, that is okay! Please talk to the professor or the TAs privately, either on Piazza, email, or office hours, and we will be happy to help you get started. We want everyone to enjoy this project, so if you feel like you're not making progress and the project is giving you grief, come talk to us!