You have been called to analyze a machine of an employee, the employee is suspected to misuse the firm machine by violating the firm policies. You are requested to investigate the employee machine to find any misuse artifacts. Examples of such artifacts are browsing illegal websites, downloading illegal images and illegal music files.

Tools Used

ewf-tools (ewfverify, ewfmount)
The Sleuth Kit (mmls)

Skills Learned

Some linux forensics
Verifying and reading E01 file formats with ewf-tools

Setup

Verify E01 forensic disk image

First we have to verify both images that we downloaded. Note that E01 are Expert Witness Format images. They are likely using compression, and meta-data, such as the hash value, is stored inside the image footer. That means if we hash the E01 file directly, we get the wrong hash value. Example:

$ sha1sum mate-MUS22.E01 
f7c71d4d301bc80592798f2c5b4221263894fb49  mate-MUS22.E01

We have to use a tool that understands expert witness format. Basically, a tool will read the hash from the footer, decompress all the original data, and calculate the hash from the decompressed data. If you’re on Windows, you can use something like FTK Imager. I use Linux as my forensic workstation, so I will use ewf-tools utility called ewfverify. ewfverify will only calculate the MD5 sum by default, so we have to tell it to also calculate the SHA1 sum with the -d sha1 option.

Mate image:

$ sudo ewfverify -d sha1 mate-MUS22.E01

Read: 80 GiB (85899345920 bytes) in 35 minute(s) and 31 second(s) with 38 MiB/s (40309406 bytes/second)

MD5 hash stored in file:		1a39206fd89b591f06d42c9850db8375
MD5 hash calculated over data:		1a39206fd89b591f06d42c9850db8375
SHA1 hash stored in file:		1167890df7d0acdae1efe97ae352035fa4ed1eeb
SHA1 hash calculated over data:		1167890df7d0acdae1efe97ae352035fa4ed1eeb

ewfverify: SUCCESS

Kubuntu image:

$ sudo ewfverify kubuntu-MUS22.E01

Read: 119 GiB (128035676160 bytes) in 50 minute(s) and 32 second(s) with 40 MiB/s (42228125 bytes/second)

MD5 hash stored in file:		0cd689fe5771a89a12b0760c3cf11aa7
MD5 hash calculated over data:		0cd689fe5771a89a12b0760c3cf11aa7
SHA1 hash stored in file:		2a575d461d041e941bd4707afe9e8bb5e75548e2
SHA1 hash calculated over data:		2a575d461d041e941bd4707afe9e8bb5e75548e2

Accessing the data inside an E01 forensic disk image

First, create two mount points on your local system. One for the “physical device” and one for the “logical device.” Then we use ewfmount from ewf-tools to mount the EWF image to the “physical” mount point. Once mounted, ewfmount creates an ewf1 “device” containing our raw image data.

$ mkdir phy1
$ mkdir log1
$ sudo ewfmount kubuntu-MUS22.E01 ./phy1
$ sudo file ./phy1/ewf1
./phy1/ewf1: DOS/MBR boot sector

The “MBR boot sector” strongly hints that this is a physical disk image. Now we have the “physical” image mount, and we can access it directly. Let’s check if there is partition information, and if so, let’s mount the main partition to the “logical” mount point. We will use mmls from The Sleuth Kit (TSK) to check partition information.

mmls displays the layout of the media management systems, which include partition tables and disk labels.

$ sudo apt install sleuthkit
$ sudo mmls ./phy1/ewf1
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

      Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
001:  -------   0000000000   0000002047   0000002048   Unallocated
002:  000:000   0000002048   0001050623   0001048576   Win95 FAT32 (0x0b)
003:  -------   0001050624   0001052671   0000002048   Unallocated
004:  Meta      0001052670   0250068991   0249016322   DOS Extended (0x05)
005:  Meta      0001052670   0001052670   0000000001   Extended Table (#1)
006:  001:000   0001052672   0250068991   0249016320   Linux (0x83)
007:  -------   0250068992   0250069679   0000000688   Unallocated

We are looking for the largest storage area that is not Meta. This is often where the user data is located. Here we have a Linux partition (006) that looks interesting. To mount, we need the starting offset of the partition. The starting offset is reported in sectors by mmls, but we will need the byte offset. Luckily, mmls also tells us that “units are in 512-byte sectors”, so in this case we do the following calculation:

$ echo 1052672 \* 512 | bc

538968064

The result is the byte offset for the 006 partition from the beginning of the physical disk. Now we can use standard Linux mount to mount the partition:

$ sudo mount -o ro,loop,offset=538968064 ./phy1/ewf1 ./log1
$ cd log1/
/log1$ ls
bin   cdrom  etc   lib    lib64   lost+found  mnt  proc  run   snap  swapfile  tmp  var
boot  dev    home  lib32  libx32  media       opt  root  sbin  srv   sys       usr

We can use chroot to change “into” the suspect system and run commands just like they would. The Linux system name stays the same, but the user changes from my local user to “root.” Also, the “/” is the root directory of the suspect:

$ sudo chroot ./log1
root@ruben-virtual-machine:/#

Once we are finished with our analysis, we can unmount with umount. Unmount the logical device first.

$ sudo umount ./log1
$ sudo umount ./phy1

After unmounting, re-verify your suspect disk images. But for now lets give this challenge a try!

Mate Case

Q#1 What is the ID of the last boot?

Journalctl can be used to display a lot of system log information. In our case, we are looking for the ID of the most recent boot. The most recent boot will be item 0 in the list, and the ID is in the second column. We can also see the boot date and time:

$ journalctl --list-boots
-4 40b3be84085e4f44ae801545e3e84e85 Mon 2022-01-17 12:56:14 EST—Mon 2022-01-17 13:28:31 EST
-3 17c3c5a208d140aead4b123c83fc408b Mon 2022-01-17 13:28:40 EST—Mon 2022-01-17 13:30:46 EST
-2 208f8d8a8feb432e8898063fd8788f66 Thu 2022-02-24 14:02:45 EST—Thu 2022-02-24 14:12:23 EST
-1 e6e32d0dd19c407a92a23e79e6f58912 Thu 2022-02-24 14:12:34 EST—Thu 2022-02-24 15:24:21 EST
 0 2a83e81d41694410928dd3c539a17f7d Thu 2022-02-24 16:00:24 EST—Wed 2022-04-06 13:05:20 EDT

Answer: 2a83e81d41694410928dd3c539a17f7d

Q#2 How did the user install Google chrome on MATE?

In Debian-based systems, applications are usually installed with the apt package manager. The apt history log can be found in /var/log/apt/history.log. Here we use grep to filter the results for “chrome”:

$ cat /var/log/apt/history.log | grep -i chrome
..SNIP..
Start-Date: 2022-04-06  02:39:17
Commandline: apt install -y google-chrome-stable
Requested-By: user1 (1000)
Install: google-chrome-stable:amd64 (100.0.4896.75-1)
End-Date: 2022-04-06  02:39:33
..SNIP..

Answer: apt

Q#3 What date and time did the user install it?

Same as Q2 we can see the “Start-Date” value to see date and time of installation.

Answer: 06-04-2022 02:39:17

Q#4 The name of a repository from which more than one extra application was installed from?

First place to look is the sources list of apt to see which repo’s have been added:

$ ls /etc/apt/sources.list.d

..SNIP..
brave-browser-release.list	    savoury1-ubuntu-graphics-focal.list       savoury1-ubuntu-multimedia-focal.list.save
google-chrome.list		    savoury1-ubuntu-graphics-focal.list.save  savoury1-ubuntu-vlc3-focal.list
savoury1-ubuntu-ffmpeg4-focal.list  savoury1-ubuntu-multimedia-focal.list     savoury1-ubuntu-vlc3-focal.list.save
..SNIP..

A quick google search about savoury was not sufficient to find a repo. So instead we can look at the bash history of the user to see what repo’s were added:

$ cat /home/user1/.bash_history | more
..SNIP..
sudo add-apt-repository ppa:savoury1/vlc3
sudo add-apt-repository ppa:savoury1/multimedia
sudo add-apt-repository ppa:savoury1/graphics
sudo add-apt-repository ppa:savoury1/ffmpeg4
..SNIP..

Answer: ppa:savoury1

Q#5 What is the name of the desktop session?

Desktop sessions are usually related to authentication. So we can check the system authentication log from /var/log/auth.log: cat /var/log/auth.log

Answer: mate

Q#6 What was the name of the suspicious domain the user visited from MATE?

Even though the users bash history doesn’t have any suspicious domain lookups or anything like that, we can see that the user has edited the hosts file:

$ cat .bash_history
..SNIP..
sudo vi /etc/hosts
..SNIP..

If we read the hosts file we get the following:

$ cat /etc/hosts
..SNIP..
192.168.8.185	livefreedrugs.store
..SNIP..

Answer: livefreedrugs.store

Kubuntu Case

Q#1 How did the user install Google chrome, date, time?

Lets check the bash history first to see what terminal commands the user has executed.

..SNIP..
wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
sudo dpkg -i google-chrome-stable_current_amd64.deb
sudo apt-get install -f
google-chrome
..SNIP..

Here can see that the user downloaded a .deb package and installed the package “manually” with dpkg. If we check the dpkg logs we van also see the date and time of installation:

$ cat dpkg.log* | grep -i chrome

2022-03-09 22:09:20 install google-chrome-stable:amd64 <none> 99.0.4844.51-1
2022-03-09 22:09:20 status half-installed google-chrome-stable:amd64 99.0.4844.51-1
2022-03-09 22:09:28 status unpacked google-chrome-stable:amd64 99.0.4844.51-1
2022-03-09 22:09:28 configure google-chrome-stable:amd64 99.0.4844.51-1 99.0.4844.51-1
2022-03-09 22:09:28 status half-configured google-chrome-stable:amd64 99.0.4844.51-1
2022-03-09 22:09:28 status installed google-chrome-stable:amd64 99.0.4844.51-1

We can conlude the user used dpkg to install chrome.

Answer: dpkg

Q#2 How did the device go to sleep?

System state such as boot, reboot, sleep are also associated with authentication. So check the authentication logs and search for “sleep”. We also add 3 lines before a match to see the context what causes the sleep event:

$ cat /var/log/auth.log* | grep -B3 sleep
..SNIP..
Feb 22 14:30:49 kubuntu20 systemd-logind[598]: Lid closed.
Feb 24 07:23:44 kubuntu20 systemd-logind[598]: Lid opened.
Feb 24 07:23:45 kubuntu20 systemd-logind[598]: Operation 'sleep' finished.
Feb 24 07:23:55 kubuntu20 systemd-logind[598]: Lid closed.
Feb 24 09:56:35 kubuntu20 systemd-logind[598]: Lid opened.
Feb 24 09:56:36 kubuntu20 systemd-logind[598]: Operation 'sleep' finished.
..SNIP..

The device went to sleep by closing the lid

Answer: Lid

Q#3 How many privileged commands did the user run?

For privileged commands the user must authenticate. We can check the system authentication log, and search for “command”:

$ cat /var/log/auth.log* | grep -i command
Apr  4 14:30:01 kubuntu20 sudo:     user : TTY=pts/1 ; PWD=/home/user ; USER=root ; COMMAND=/usr/sbin/fdisk -l /dev/sdb
Mar  8 19:32:40 kubuntu20 sudo:     user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/bin/bash
Mar  8 19:34:04 kubuntu20 sudo:     root : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/usr/bin/apt update
Mar  8 19:34:13 kubuntu20 sudo:     root : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/usr/bin/apt upgrade
Mar  9 22:09:19 kubuntu20 sudo:     user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/usr/bin/dpkg -i google-chrome-stable_current_amd64.deb
Mar  9 22:09:38 kubuntu20 sudo:     user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/usr/bin/apt-get install -f

$ cat /var/log/auth.log* | grep -i command | wc -l
6

Answer: 6

Q#4 What application was used to open the Top devices file?

We can run the following command in the /home/user/.local/share/ directory to see that Kate was used to open the Top Devices file:

$ cd /home/user/.local/share/
$ grep -ri "top devices" *
Binary file kactivitymanagerd/resources/database matches
kate/anonymous.katesession:URL=file:///home/user/Random/Top devices
kate/anonymous.katesession:Active View=file:///home/user/Random/Top devices
kate/anonymous.katesession:Documents=file:///home/user/Random/Top devices
kate/anonymous.katesession:View 0=file:///home/user/Random/Top devices
kate/anonymous.katesession:[MainWindow0-ViewSpace 0 file:///home/user/Random/Top devices]
kate/anonymous.katesession:File3[$e]=$HOME/Random/Top devices
kate/anonymous.katesession:Name3[$e]=Top devices

Answer: kate

Q#5 What was the UUID of the main root volume?

When the system boots it looks for the main hard drive based on the UUID. These so called “boot-time messages” can be found in the dmesg logs inside /var/log:

$ cat /var/log/dmesg* | grep -i uuid
[    0.000000] kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.13.0-39-generic root=UUID=b8eaa59a-4744-48e1-9953-c4a72dad131c ro quiet splash vt.handoff=7
[    0.029637] kernel: Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.13.0-39-generic root=UUID=b8eaa59a-4744-48e1-9953-c4a72dad131c ro quiet splash vt.handoff=7
[    0.000000] kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.13.0-35-generic root=UUID=b8eaa59a-4744-48e1-9953-c4a72dad131c ro quiet splash vt.handoff=7

Answer: b8eaa59a-4744-48e1-9953-c4a72dad131c

Tools Used#

Skills Learned#

Setup#

Verify E01 forensic disk image#

Accessing the data inside an E01 forensic disk image#

Mate Case#

Q#1 What is the ID of the last boot?#

Q#2 How did the user install Google chrome on MATE?#

Q#3 What date and time did the user install it?#

Q#4 The name of a repository from which more than one extra application was installed from?#

Q#5 What is the name of the desktop session?#

Q#6 What was the name of the suspicious domain the user visited from MATE?#

Kubuntu Case#

Q#1 How did the user install Google chrome, date, time?#

Q#2 How did the device go to sleep?#

Q#3 How many privileged commands did the user run?#

Q#4 What application was used to open the Top devices file?#

Q#5 What was the UUID of the main root volume?#