In parts 1 and 2 of this series we examined the artifacts from live system by looking at the processes and network connections. We also looked at artifacts left behind after a system was powered down by examining the AppCompatCache, Amcache and the Srum database. In part 3, we will take a look at some common artifacts related to malware inside the windows registry.
When an attacker compromises a system it is very common for them to set a means of persistence. They do this so that when a machine is rebooted, they have a way to reconnect. One of the easier ways to establish persistence is via the Windows Registry and writing to one of the many keys that will execute a script or program and startup.
The creators of ForensicsWiki.org have a handy cheat sheet of some of the common persistence keys found inside the Windows Registry – https://www.forensicswiki.org/wiki/Windows_Registry#Persistence_keys
Starting out I will be examining a machine that was compromised by an attacker using a malicious binary that called back to their system and established a meterpreter backdoor. A few years ago I had the opportunity to work with one of the leading experts on the Windows Registry, Harlan Carvey and will be using his free tool RegRipper to parse the hive file.
I’ll first start by looking at the Software registry as this hive file contains most of the Windows run keys.
The CurrentVersion\Run key has a very good indicator that this machine is compromised. We can see that the LastWrite Time for the key was on Jun 28 at 21:26 UTC time and that an entry titled K0adic is set to spawn a Windows command shell and execute the mshta query to the IP address. Whenever you run across entries like this, you have a smoking gun that the machine is compromised and an attacker has attempted to establish persistence.
Looking at the users ntuser.dat file we also find this persistence method
As you can see, within just a few minutes of work, we have clear signs of compromise for our host and have additional data to pivot off of.