PoSeidon Adventures in Memory
Background
As an Incident Responder I get the unique opportunity to see a lot of malware and in most cases that I investigate, the malware is of the card number stealing type. To be more specific, I deal with a lot of Track 2 memory scrapers. These malware families come in all shapes, sizes and names but they are always running in memory and are waiting for Track data to flow through whereby it captures it and exfiltrates it. Exfiltration can vary from dump files on disk encrypted or not or the malware will send it out over port 80 or 443.
In this particular case I have been handed a memory dump and tasked with determining if PoSeidon was running on the system. Should be easy enough, given all that we know about PoSeidon and if you find you need a refresher, there is a great article that our own Eric Merritt has written up on the topic here: https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/poseidon-completionist/
So now that you have read up on it, you did didn't you?...We are ready to go!
Tool Check
Nothing is worse than a blogger that doesn't list out the tool versions they are using in the examples they give. I want to make sure that if you're trying this at home you don't hurt yourself or someone else in frustration. Trustwave would likely make me put a disclaimer on future posts if that were to happen.
In the following examples I'm giving, I will be using a SIFT box with the following:
- Python 2.7
- Rekall 1.5.1
- Volatility 2.4
Last but not least I have a memory image that was acquired using WinPmem v 2.0.1.
Triage
First thing's first! On any new case there is a little bit of triage that has to happen. Every IR person has their own set of ways in which they start out, but the first few steps after acquisition are generally some form of triage. As I said, I have a memory image and nothing else, so the list in my head before I dig deeper is:
- Pslist – This will get a list of running processes
- Pstree – Another list of running processes but in a tree view
- Malfind – Uses VAD (Virtual Address Descriptor) tags and page permissions to detect injected code
- Psxview – Another plugin that can help detect hidden processes
I will typically start with these first and spit them out to a file to grep through later, however I have a very specific piece of malware that I am after and I already read Eric's blog. Yes, I keep plugging him. In this case I will forego the aforementioned steps and instead shoot to kill.
Malfind
Now I know what you're thinking. Why doesn't this guy start with a Pslist and grep for WinHost? You're right, I could totally do that but that is not a PoSeidon Adventure and this would be a very short blog post. Let's first have some fun with Malfind, chock full of false positives and VAD tags. My favorite kind of forensic stew!
In this example, I am using Rekall to quickly run malfind and then piping that to a grep command looking for MZ headers.
Well that looks promising. I can see the obvious WinHost.exe with the 2268 Pid and two separate svchost.exe processes, Pids 1828 and 2284. Also of note is the shared VAD at 0x400000. So at this point, I feel fairly confident that I have what I am looking for given the MZ header, the Vad Tag, and once again everything I already know and love about PoSeidon. Still though, not quite satisfied and I've only just dipped my toes in the water.
Validation
Well I wasn't going to do it but just for completeness, (Thanks Eric) lets do our Pslist anyway and grep for our Winhost.exe pid 2268.
And there you have it. Just what I would have expected to find. The svchost processes are both spawned from our very own WinHost.exe. Well nicely done! Still though, proof is in the pudding I guess. Let's do one last thing to triple check our findings. I happen to have a fuzzy hash of the decoded malware that is injected into WinHost.exe:
1536:zgTGTSQMQBtrdKooXOV2ah3AV0K1XsWjcdmzpLQkb7bakZ68r8Y:ETGJFtdKoTEGaemzpLQkD76Qh, "WS2HELP.exe"
Lets first do a procdump of our interesting pids 1828, 2268, and 2284.
Note the size of both svchost's are the same. Now let's run an ssdeep hash match against them.
As you can see our WinHost.exe has 96% match on our fuzzy hash and both of the svchost.exe are exact duplicates of each other. We have done our triple verification check and we can positively state that PoSeidon is running on this system but, I still have a thirst for more.
Where does the file reside on disk?
Where is it connecting to?
When was this system compromised?
What other interesting artifacts can we gather?
Thirsty for More
There are a few ways you can get the answer for "Where does the file reside on disk?", but for me I like to run dlllist to answer that and potentially find other interesting leads.
From the output above we can see Command Line : C:\Windows\SysWOW64\WinHost.exe. If I had the disk image of this system, I would now be able to export that file and that would potentially lead to other interesting artifacts like creation time, and events surrounding that time leading up to the creation of the file. My eyes tear up just thinking about the onion layers peeling away.
But wait! Can't I get some of these details from memory? The answer is a resounding…..Potentially! Good enough for me.
Now is about the time when I stop using Rekall and start using Volatility. Rekall is great for fast action triage, but now I want to use some of the more stable plugins I can get from using Volatility. To answer the question of Creation Time, there is a great plugin for MFT parsing available called mftparser. Let's use that and see if we can answer the "When was this system compromised?" question. There is a lot of data when you run mftparser and I want to capture all of it in case there are other interesting artifacts outside of WinHost.exe so I will output to a file and grep through it later.
Once I have my file, I will run a grep command for "winhost" and see what comes back.
Well, well isn't that interesting. We have uncovered another artifact. PoSeidon does have an encrypted configuration file full of domains and it looks like its sitting there in the \Windows\SysWOW64\ folder as WinHost.exe.cfg and of course we also have WinHost.exe. Based on the MFT times it appears that our system was compromised with the malware on 10/27/2015 at 07:33:16 UTC and the config file came tumbling after at 07:33:22 UTC. Good stuff right?
We now have confirmation of compromise, location of the malware files and the date/time of the compromise. I know we can get more and because I love typing and taking screenshots, lets do more.
Let's answer the question of "Where is it connecting to?" Typically, on a case where I don't have a specific malware that I'm looking for, I would have run netscan as part of my triage and output that to a file to grep through after I have some other indicators like interesting pids or if I'm trying to generate leads. In this case, I didn't do that so, lets do a netscan now.
Please don't judge my usage of awk here but in a nutshell, I ran netscan and looked only for my interesting pids 1828, 2268, and 2284. The rest of the awk commands are used to clean up the output to only show me the outbound external connections. Basically, I removed any 192 and ipv6 addresses. This left me with an end result of three IP addresses. After doing a WHOIS, the first two IP addresses don't really amount to much. However, the third IP address smells like rotten fish in the bread aisle.
We're looking good here and have some serious juice on this case. Confirmation of malware on the system, date of compromise, outbound connections and location on disk. What else could you possibly want on your PoSeidon adventure in memory? C2 domains? You have to be kidding, right? Sure I'm game.
All In
I think at this point if we are really digging hard and we're deep in the trenches, we're going to find ourselves doing some form of strings analysis. Earlier we did a procdump on WinHost.exe as well as the two svchost.exe files. Let's start there by running strings against the WinHost to start and see what we can find.
There is a ton of good stuff in the output but we were looking for some potential C2 domains right?
Let me know if anything jumps out at you.
Conclusion
I hope you enjoyed this PoSeidon adventure! There are many more tools and plugins for digging even deeper into this memory dump but at this point we have answered the questions asked of us and beyond. I hope this adventure inspires other adventurers and helps to shed some light on how to generate leads using a memory dump and use those to peel back the layers in your disk analysis (if you have one).
Happy Hunting!