Intro
Persist was the forensics challenge released on day 3, where we’re given a memory dump of Santa’s computer, which reportedly has a “slow boot time and a blue window popping up for a split second during startup”. We’ll take this as a cue to investigate AutoRun Persistence in Windows, and find a Volatility plugin called “winesap” which will show us a number of registry keys, one of which that contains a suspicious PowerShell script that we can decode to get the flag.
Description
Although Santa just updated his infra, problems still occur. He keeps complaining about slow boot time and a blue window popping up for a split second during startup. The IT elves support suggested that he should restart his computer. Ah, classic IT support! Download Link: http://46.101.25.140/forensics_persist.zip
Intro to Volatility
Background
Two of the five forensics challenges during this CTF had to do with memory dumps, which many struggled with since they had never had to do memory forensics before. Since the solution to this challenge is pretty quick with the right tools, I’ll take this time to explain the basics of Volatility, the de facto tool for memory forensics.
According to the developers’ webpage, Volatility “introduced people to the power of analyzing the runtime state of a system using the data found in volatile storage (RAM). It also provided a cross-platform, modular, and extensible platform to encourage further work into this exciting area of research.”
Prior to this research, most forensics involved looking at the hard drive image. However, this method of analysis can only find things on-disk, so the running state of processes were not stored at all. The primary difference between volatile and nonvolatile memory is that volatile memory requires constant electrical current. To keep it simple, if I removed the battery from your device right now, the photos and documents you have on the disk will remain, but the state of your browser probably won’t. The browser was an active process in RAM, but the other files you had on your device weren’t being modified at all.
History and tech lesson over, let’s talk about using the tool.
Basic Usage
I’ve already downloaded the dump on my Remnux VM, as the distro already has Volatility installed. I’ll be working out of Volatility 2, since version 3 is a bit finnicky with installing the symbol libraries and all.
imageinfo
is almost always the first thing you’ll use, so you can find the correct profile to give Volatility to parse the dump correctly. We also get some additional information about the OS.
From here, you’ll be able to specify the profile using the --profile
flag, and then proceed to do pretty much whatever. The framework is plugin-based, so each “command” has its own subset of things to do, but we’ll only cover some basic plugins here. The pslist
and the pstree
plugins can be used to view the current list of processes, one as a list, and the other as a tree, respectively.
I’ve only shown the pslist
output here, but you really should use both in your analysis. The goal of memory forensics is to find anomalies, or occurences that aren’t normal for the operating system. You can ignore the DumpIt.exe
process; this is one of many processes that are used to actually dump the memory in practice.
The final plugin we’ll talk about for now is netscan
, which can be used to basically check netstat
at the time of the dump.
There are many, many other plugins to dig into, and there are many cheat sheets online to aid you while learning how to use the tool. Also note that you can use the -h
flag on any plugin to see what additional options you may have.
Grabbing the Flag
Persistence 101
Now that we have a basic understanding of the tool, let’s look back at the description. Santa is supposedly seeing “slow boot time and a blue window popping up for a split second during startup”. Given the title of the challenge, this is a huge hint. The idea of “persistence” is fairly simple: as an attacker, leave yourself some way to get back in if you lose your shell. Between Linux and Windows, there are many, many ways that this can be achieved, including SSH keys, Golden/Silver tickets, Scheduled Tasks and/or cronjobs, etc. These, by no means, are bad options, but we can go deeper.
We could be dealing with a rootkit, code that is planted at a lower-level in the operating system to maintain persistence. However, a much simpler option that matches the description would be AutoRun.
The MITRE ATT&CK Framework describes this subtechnique like so:
“Adversaries may achieve persistence by adding a program to a startup folder or referencing it with a Registry run key. Adding an entry to the “run keys” in the Registry or startup folder will cause the program referenced to be executed when a user logs in. [1] These programs will be executed under the context of the user and will have the account’s associated permissions level.” — MITRE, Technique 1547.001
Basically, an attacker might have added a registry key that allows them to run a script everytime Santa boots up his computer. This is actually a lot closer to our description than the rootkit, as the Registry key is likely to contain some kind of executable or PowerShell, which might be the source of the “blue screen”.
winesap
During the CTF, I was having a lot of trouble getting the autoruns
plugin to work, which is basically designed to investigate this kind of stuff. After some research into alternatives, I learned about winesap, from this very well done tutorial by 13Cubed. The TL;DW is that this paper dives deeper into the concept of “autorun persistence”, and the “winesap” plugin was developed to find anomalies.
I’ve been unable to locate the original repository for this plugin from the tutorial, but I did find a clone of it on GitHub which you can find here. I’ll clone it on my VM, and run the plugin like so.
There’s supposed to be a --match
flag, but I guessed this bypassed it, somehow. We can take this base64 and decode it to see what’s up.
Well look at that, there’s the flag.