This week is longer than I thought, so time to catch up… 🙂

This one is a mess, but sometimes a bit of a mess is not a bad thing. Useful for at least cherry-picking breadcrumbs in a vast amount of sandbox or EDR logs…

Yes… file names… we can love them, we can hate them, but many of them are so characteristic that it really would be a mistake to ignore them. Whether they are accessed for reading, writing, locking, or whatever else – we can pick up a lot of behavioral patterns from a simple fact these files are somehow targeted by a program that touches them…

On that note… I am not aware of any EDRs collecting attempts to open non-existing files, or other objects – this would be a nice detective feature to have available (I actually bet it’s in place just not available to customers). The ability to see what programs are attempting to use what objects, load non-existing libraries, create/open mutexes, semaphores, pipes, as well as ‘find’ and ‘search’ operations etc is something we all want to see more.

Here’s a relatively long list of file-related artifacts of any sort, sometimes with some loose ‘attribution’.

Writing your own sandbox has many advantages – the most important is an ability to collect data only large companies have. Analysing many samples gives us an unique insight into coding patterns and one of them is a simple laziness of coders who are often leveraging OS programs/commands to achieve their goals. Today, with the EDR all over the place, many sandboxing services available online, and a admirable tendency of everyone to finally share this data openly it only makes sense to make my obsolete data public.

Here’s a snapshot of some of the malicious commands I ‘logged’ in the past.