Hacking and DFIR Lab [Part 2 – DFIR]

In the last part, we were able to gain SYSTEM access to the Domain Controller giving us full access to the network. Let’s take a look at how the incident response process will go.

The first step is detection. I installed a Logrhythm VM and spanned all network traffic from my PFSense VM to it. We should have a couple of different connections to our attacking VM at 10.10.10.3.

Here we can see that there’s a connection between 10.10.10.4 [Our Domain Controller] and 10.10.10.3 [Our attacker] using port 443. However, unlike the connection between 10.10.10.11 [Logrhythm] and 10.10.10.4 [Domain Controller], it isn’t using the HTTPS protocol over that port. That’s a red flag.

We can also see that our Windows 7 machine is connected to our attacking machine over port 4455 which is a strange port. This is why it’s important to have an understanding of your environment. If an attacker did drop a box onto your physical network or took control of another internal host, this wouldn’t look suspicious unless you knew that those particular hosts do not speak to that specific IP. A remote attack would be a little easier to spot if you have internal servers communicating directly with a public IP address.


So now that we’ve determined something’s up with these machines, let’s grab some evidence. We should grab the memory and take forensic images of these hosts. Having these on VMs makes it easy.

We can grab the current memory in use by using VBoxManage from the command line of our host machines.

.\VBoxManage.exe debugvm "<VM Name>" dumpvmcore --filename C:\<output_folder>\dc_memdump.elf

Later on, we can analyze these dumps using Volatility. Next let’s grab the disk images. We have a couple of options to do this.

  • Boot up with a Linux Live CD and use the DD command
  • Use FTK Imager on the .vdi files
  • Use VBoxManage

I will be using FTK Imager but here’s the VBoxManage command if you want to take that route.

.\VBoxManage.exe clonehd 'H:\VirtualBox VMs\<VM Name>\<VM Name>.vdi' 'H:\<VM Name>.dd' --format RAW

Below is the process of using FTK Imager on the .vdi files. I’ve already done this to save time.

After this is complete, we’re able to open these image files in a forensics suite like FTK, EnCase, or Autopsy.


With something like this, memory forensics might be more useful for painting a picture. If a zero day is used like EternalBlue, it’s affecting the memory of the machine and not necessarily dropping a file.

For the end user machine, let’s use Volatility to check it out.

The first step is to determine what profile to use.

volatility imageinfo -f <path to memdump file>

Volatility wants us to use the Win7SP1x64 profile.

Now let’s take a look at the processes and connections. We know from Logrhythm that something connected via port 4455. Let’s determine which process was doing that.

volatility netscan --profile=Win7SP1x64 -f end_memdump.elf

Looks like the EternalBlue exploit injected itself into spoolsv.exe.

Now I tried extracting this executable and submitting the hash to VirusTotal to see if it would detect EternalBlue. Unfortunately, it didn’t. However, I did find this article.

This basically states that the EternalBlue exploit modifies the SMB buffer and you can see the results using the bigpools plugin with the tag LSbf. Our results match the results this blog had indicating that this machine was exploited via the EternalBlue exploit.


Let’s move onto the Domain Controller we took over.

Just like last time, we’ll determine the profile to use with the imageinfo command. It recommended us the Win8x64 profile but we’re going to use the Win2012R2x64 because we know the OS that’s installed.

Again, we’ll do a netscan.

Remember when we ran that Metasploit module to run persistance on the victim over port 443? That’s what we see here.

However, from the investigator’s perspective, they won’t know what that process is. So let’s extract it and upload it to VirusTotal and see if we get any detections.

volatility procdump -p 1968 -D dump/ --profile=Win2012R2x64 -f dc_memdump.elf

It’ll export that entire process into our specified dump directory and name it executable.1968.exe

VirusTotal really hates this executable and now we know that this process is malicious.

However, can we see where this came from so we can protect this network from an attack like this happening again?

Let’s take a look at autoruns. We’ll extract the SOFTWARE registry hive from the disk image and use the tool RegRipper to extract the info.

It looks like we have a weird VBS file saved on the root of the C:\ drive. Let’s take a look at it.

Seems to be obfuscated in Base64. Let’s try to decode it and maybe get some more info.

I took that long paragraph of Base64 and extracted it to a text file in my Kali box and then ran

base64 -d base64.txt > decodedVBS.txt

This decoded all of it and it turns out to be an executable program which corresponds to our malicious process we saw.

If we look at the rest of the script, we can see that it spawns the process we saw in Volatility.

So what started all of this? We still haven’t found the root cause.

We can take a look at the Web History of Mozilla Firefox by navigating to C:\Users\<user>\AppData\Roaming\Mozilla\Firefox\Profiles\<profile>\places.sqlite.

We can see that the Bit.ly address led to a webserver hosted by the malicious machine we were using and multiple executables were downloaded.

We’ve found the origin of the attack. Through keyword searching, we would also be able to see the link being sent via the email but my lab’s mail server was acting up so I just put the link in manually during the attack stages.


Next step in this would be to make sure the attack doesn’t happen again. The steps are also important to make sure that the attacker doesn’t setup anything else to keep himself in the network.

First we’d want to immediately patch all of our machines starting with the end user machines to protect against the EternalBlue exploit.

Next we’d want to remove the persistent VBS script, then sever the connection. This ensures that upon reboot, the connection isn’t reset.

Finally, we’d educate our users on the importance of not clicking random links sent to them via email.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s