Incident triage: Identifying the source of a malware infection
Part of my time at the SANS Cyber Retraining Academy covered the incident response methodology and how to identify what’s wrong and how to fix it. But theory is quite different to the real thing, so I thought it would be useful to make a cheat sheet with a few of the pointers I’ve picked up when it comes to investigating malware activity.
In many cases you’ll be responding to an alert from an anti-virus solution or an intrusion detection system. It might tell you the infected hostname, the name and directory of the suspicious file, and what kind of malware it thinks it’s found. But where do you go from there? How do you find out how it got there in the first place?
Finding the original malicious file
Where did the malware come from? Often, the file that a security product detects won’t be the first malicious file that landed on the endpoint. But if you know the time of the first detection you can work back from this point to find the original offender.
With limited information available about the user’s prior actions (depending on your level of logging), I’ve found the following two directories to be a goldmine when it comes to identifying what the user was doing immediately before the malware alert.
[USER DIRECTORY]\AppData\Roaming\Microsoft\Windows\Recent[FILE NAME].lnk
[USER DIRECTORY]\AppData\Roaming\Microsoft\Office\Recent[FILE NAME].lnk
These folders contain shortcuts to recently opened files, so finding links that were added just before the detection can be hugely valuable. A Word document opened just before an executable was found, for example, could point to a phishing attack.
Finding the source of the infection
Now you’ve located the original file, it’s time to work out where it came from. Even more than the last step, this depends on the kinds of logs you have available to work with.
The most useful logs here are often web proxy or DNS logs, which can show the domains and/or URLs that the infected user accessed before the file was downloaded. The most obvious indicator of compromise here is a request to a suspicious-looking URL, which can be checked out via a service like urlscan.io or IBM X-Force Exchange.
The other potential clue – albeit a less reliable one – is a request to an email service prior to the malware detection. This could be a sign that the user was tricked into downloading and opening a malicious email attachment and was infected that way.
The next most common attack vector is probably infection via USB stick or portable hard drive, which you may be able to identify based on the directory of the executables that were run if you have access to application activity logs.
These techniques won’t work every time – the variety of malware and delivery methods out there is simply too wide – but I’ve found them to be a useful starting point in tracking down what’s going wrong. I’ve also recently identified a few places to look to determine if the malware has established persistence, but that’s a story for another blog post…