In this chapter, we'll cover several different tools to uncover various artifacts that may be very useful to our forensic investigations. Most of the tools used in this chapter focus specifically on memory and swap analysis, while Network Mapper (Nmap) and p0f focus more on the network and device.
In this chapter, we'll cover the following topics:
If you're using the VirtualBox version of Kali 2019.3 (kali-linux-2019.3a-vbox-amd64.ova), you may have to install p0f by typing in apt-install get p0f. If you're using the Kali 2019.3 Large.iso image, it should come preinstalled.
You may also use the help option within p0f to verify that it is installed on your system by typing p0f –h. This displays the network interface options, operating mode, output settings, and performance-related options:
Once verified, we can run the p0f command without additional switches or options by typing in p0f, which runs the tool against our machine. In this scenario, my IP address is 172.16.77.159:
The output shows that I have two interfaces, with eth0 being my Ethernet/LAN interface, with an IP of 172.16.77.159 and a loopback address of the default 127.0.0.1. I'll be using the eth0 interface with p0f.
The output of the whois command can be seen in the following screenshot:
In this whois output, we can see that the IP points to wix.com, which is the host for the www.cfsi.co website.
Scrolling through the p0f output, we can see several other pieces of information, including the uptime of the server and other IP addresses and hops along the way:
Now that we've found some very useful information on our target network IPs, let's have a look at another tool, Nmap, which can also be used to fingerprint and discover devices, services, and more.
Let's now use the Nmap tool to gather information about resources and devices on the network and discover any open, filtered (monitored or firewalled), or closed ports and also fingerprint their operating systems:
nmap –v –O –sV 172.16.0.0/24 –Pn
The following list details the options used in the previous command:
The following screenshot shows some of the output of the Nmap version scan:
This scan can take some time to run due to the service version scanning in particular. Here's the output of one host (172.16.0.1):
In this Nmap result, we can see that six ports are open and running various services, such as SSH 1.25, SIP Proxy, and SSL, inclusive of service version information as specified when using the –sV option. We can also see that Nmap has fingerprinted the OS to be a Cisco router.
We've discovered some very interesting information using Nmap and p0f. Let's move on to our next topic, which covers Linux forensics.
When performing live forensics on Linux machines, Linux Explorer can be used to gather information and artifacts.
Linux Explorer can be used to find the following artifacts:
The WannaCry cryptoworm became well-known around May 2017, when several large organizations started reporting ransomware infections that spread via EternalBlue exploits on vulnerable Windows systems. A splash screen appeared on users' machines, which then instructed users to pay $300.00 in Bitcoin to have their infected/encrypted file decrypted.
More on the WannaCry ransomware can be found at https://en.wikipedia.org/wiki/WannaCry_ransomware_attack.
Further reading on the WannaCry ransomware can be found by visiting the following links:
For this lab, we'll be using Volatility to analyze the ransomware and attempt to trace and view the originating sources of infection by analyzing a memory dump taken from an infected machine.
Important note
We will not be downloading the actual ransomware but merely a memory dump file of an infected machine.
For additional safety, you may switch your network adapter settings to NAT (if on bridged mode) in VirtualBox or your platform of choice, before downloading the file and then disable your network adapter after downloading the file to ensure that you are working in an isolated VM.
The memory dump of the machine infected with the WannaCry ransomware can be downloaded from here: https://mega.nz/#!Au5xlCAS!KX5ZJKYzQgDHSa72lPFwqKL6CsZS7oQGbyyQrMTH9XY.
Thanks to Donny at https://www.null0x4d5a.com/ for providing the mega link and password to the file in his blog.
I've saved the downloaded file to my Downloads folder. In the Terminal, I'll switch to the Downloads folder and view the contents by typing in cd Downloads and then issuing the ls command. There I can see the wannacry.7z file, as in the following screenshot:
For integrity purposes, I've run the sha1sum and sha256sum tools against the downloaded file. To extract the file, I've opened my Downloads folder, double-clicked on the file, right-clicked on wcry.raw, and then clicked on the Extract option. The password for the file is the word infected, as in the following screenshot:
Click on OK to start the extraction and then click on Show the Files when completed:
The extracted memory dump file is named wcry.raw and shows a file size of 536.9 MB:
Once the file has been downloaded and extracted, let's begin analyzing the ransomware.
Open a new Terminal and navigate to the Downloads folder. Let's start by running the image info plugin to determine the profile to use, just as we did in the earlier Volatility exercise in the previous chapter:
The suggested profiles for our wcry.raw image are WinXPSP2x86 and WinXPSP3x86, but we'll use WinXPSP2x86 from here on.
We'll start with the pslist plugin. Type the following command into the Terminal:
volatility –profile=WinXPSP2x86 -f wcry.raw pslist
The following screenshot displays the output of the pslist command:
In the preceding screenshot, we can see that there is an entry (third from last) for a process named @WanaDecryptor@ with a PID of 740 and a PPID of 1940. This is a good indicator that an instance of the WannaCry ramsomware may exist within an infected process or file.
volatility –profile=WinXPSP2x86 -f wcry.raw pstree
The following screenshot displays the output of the pstree command:
Using the pslist, psscan, and pstree plugins, we saw the @WanaDecryptor@ process (with a PID of 740 and a PPID of 1940) spawned by the Windows task scheduler (tasksch.exe, PID: 1940) under Windows Explorer (explorer.exe).
volatility –profile=WinXPSP2x86 -f wcry.raw psscan
The following screenshot displays the output of the psscan command:
In this output, we can see four instances of processes that have a PPID of 1940:
Taskdl.exe: PID of 860
Taskse.exe: PID of 536
@WanaDecryptor@: PID of 424
@WanaDecryptor@: PID of 576
Let's first run pslist again with the grep option by running the following command:
volatility –profile=WinXPSP2x86 -f wcry.raw pslist | grep 1940
The following screenshot displays the output of the pslist command:
Let's also run the psscan plugin with the grep option to view the processes by running the following command:
volatility –profile=WinXPSP2x86 -f wcry.raw psscan | grep 1940
The following screenshot displays the output of the psscan command:
Run the dlllist plugin by typing the following into the new tab Terminal:
volatility –profile=WinXPSP2x86 -f wcry.raw dlllist –p 1940
The following screenshot displays the output of the dllist command. The dlllist plugin, when specified with the –p 1940 process number, displays the directories and libraries used by the process:
Scrolling down through the output, we can see the output for tasksche.exe, with a PID of 1940 and all the associated DLLs:
A closeup of the output shows us the command line entry for tasksche.exe as C:Intelivecuqmanpnirkt615 asksche.exe:
The path, specifically the ivecuqmanpnirkt615 folder, is a bit suspicious here but let's have a look at some more dlllist outputs before we go further. Here's the output for @WanaDecryptor@, with a PID of 740:
A closer look at the output shows that the path for @[email protected] is also the same as tasksche.exe, listed as C:Intelivecuqmanpnirkt615@[email protected].
The path for @[email protected] can be seen in the following screenshot:
To confirm this, we can use the dlllist plugin with | grep ivecuqmanpnirkt615 to search for the folder path and the associated .exe files:
Type in the following command to run this plugin:
volatility –profile=WinXPSP2x86 -f wcry.raw handles -p 1940 -t mutant
The following screenshot displays the output of the handles plugin used with the mutant option:
This was a lengthy exercise but I hope you've enjoyed finding artifacts, including the processes, IDs, and paths that have all helped us to identify the ransomware, along with verification from VirusTotal. We'll now move on to Linux swap file analysis using swap_digger.
swap_digger performs an automated analysis of the Linux swap file and can retrieve artifacts such as system passwords, usernames, form credentials, and even Wi-Fi information, such as the SSID and perhaps even passwords if they are stored in the swap file.
Let's now clone and install swap_digger in Kali Linux:
The preceding gitclone command clones and installs swap_digger:
chmod +x swap_digger.sh
sudo ./swap_digger.sh –vx
swap_digger will run after typing in the preceding commands, as in the following output:
As mentioned in the last line of the preceding screenshot, the dictionary attack can take anywhere from five minutes to several hours:
This may take a while but it will at least show your default password once complete.
If left to run, swap_digger will also search for web and email passwords, XML data, and Wi-Fi passwords. I haven't entered any of those on my Kali machine but here's a screenshot of the process:
As the preceding screenshot shows, swap_digger is a very useful tool for live analysis on Linux machines, which can be used to discover artifacts running in the swap file, including passwords. Let's now move on to another password-dumping file in the next section.
Mimipenguin is based on the very popular password-cracking tool mimikatz. Much like swap_digger, mimipenguin can also retrieve artifacts running in memory by dumping memory processes that may contain unencrypted passwords in plaintext:
In the previous screenshot, we can see that the username and password for the Kali machine was discovered (root : toor).
In this section, we'll use pdgmail, which also performs memory analysis but specifically looks for web artifacts, such as emails, contacts, IP addresses, and even inbox or sent items, by analyzing the memory dump process.
For this lab, I'll be using the Kali Linux Large ISO, which I have installed as a virtual machine in VirtualBox:
I've also opened a Firefox browser and logged into a Gmail account, then clicked on my inbox and sent items box so that this process can be run in memory. I've also visited some other sites, such as www.20minutemail.com, where I signed up for a temporary email address, and www.netcraft.com, where I looked up certifiedhacker.com.
ps –ef | grep fire
The following screenshot displays the output of the previous command:
gcore –o firegmail.dmp 19622
The following screenshot displays the output of the previous command:
Once the process dump is completed, the last line should read as Saved corefile firegmail 19622.
We can see the last line of the output of the gcore command in the following screenshot:
strings –el firegmail.dmp.19622
The command is shown in the following image:
Scrolling through the output, you will be able to see the email you logged into, along with the number of unread emails in the inbox:
I can also see a link from one of the emails I just clicked on from www.academia.eu:
Here's a screen shot of the actual email subject in Gmail:
I can also see that the mail compartments/categories were also found:
Pdgmail has also found artifacts relating to www.20minutemail.com where I signed up for a temporary email account earlier:
It also showed the search entry on www.netcraft.com, where I previously did a DNS search for the www.certifiedhacker.com:
This concludes our usage of pdgmail, which we used to explore Gmail artifacts on a live Linux system, which would be stored within the browser cash within memory. Although the examples and screenshots were based on a sample email that I used, feel free to try this using your own email within Kali Linux.
This was quite an exciting chapter. We discovered communications services, devices, ports, and protocols using Nmap and p0f and then jumped into ransomware analysis using Volatility to discover the origin of the WannaCry cryptoworm on an infected system's memory dump. Finally, we did an analysis of the swap file using swap_digger, mimipenguin, and pdgmail.
In the next chapter, we'll use Autopsy and The Sleuth Kit to analyze an imaged drive and also compare Autopsy for Linux and Windows.
18.222.115.120