Tips for DFIR Analysts, pt III

This article has been indexed from Windows Incident Response

Learn to think critically. Don’t take what someone says as gospel, just because they say it. Support findings with data, and clearly communicate the value or significance of something.
Be sure to validate your findings, and never rest your findings on a single artifact. Find an entry for a file in the AmCache? Great. But does that mean it was executed on the system? No, it does not…you need to validate execution with other artifacts in the constellation (EDR telemetry, host-based effects such as an application prefetch file, Registry modifications, etc.).
Have a thorough process, one that you can add to and extend. Why? Because things are always changing, and there’s always something new. If you can automate your process, then so much the better…you’re not loosing time and enabling crushing inefficiencies. So what do you need to look for? Well, the Windows Subsystem for Linux has been around for some time, and has even been updated (to WSL2). There are a number of versions of Linux you can install via WSL2, including Parrot OS. As one would expect, there’s now malware targeting WSL2 (Lumen Black Lotus LabsTomsHardware, The Register).
Learn to communicate clearly and concisely. This includes both the written and spoken form. Consider using the written form to make the spoken form easier to communicate, by first writing out what you want to communicate.
Things are not always what they seem. Just because someone says something is a certain way doesn’t make it the case. It’s not that they’re lying; more often than not, it’s that they have a different perspective. Look at it this way…a user will have an issue, and you’ll ask them to walk through what they did, to see if you can replicate the issue. You’ll see data that indicates that they took a specific acti

[…]
Content was cut in order to protect the source.Please visit the source for the rest of the article.

Read the original article: Tips for DFIR Analysts, pt III