Not installing the installers, part 3

Posted on by

With file handlers being yet again a topic du jour it was only natural to try answering a question — how many file protocols are really out there?

I tried to answer this question before, but it was focused on built-in, ‘native’ protocol handlers only. What about we add the ones that are installed by the third parties? While the final list (or two) is far from being complete, it’s definitely a step forward.

So, how do we find these?

If we are lucky, we can parse our EDR logs (ideally, if you are a vendor). If we are not – we don’t have many choices really… we can google around for existing research, we can parse available source code, we can even sandbox files and parse their reports, and so on and so forth. It’s slow, and mundane. I would know, because I was there.

Luckily to us, installers often include list of Registry entries that are being added during the installation process and removed when application is uninstalled. The protocol handlers are easy to spot as installers push the ‘Url protocol’ value to the Registry to indicate the entry of interest, so a few parsed installer scripts later we come up with a short list.

The other avenue we can pursue is to look at a database of HijackThis log reports. This is of far poorer quality, but allows us to nail down a very long list of candidate entries for the ‘O18 – Protocol’ class – you can download it here.

Not installing the installers, part 2

Posted on by

In the last post I described how we can pull some interesting metadata from decompiled installers. Today I want to discuss one practical example of how this data can enrich analysis, both manual and automatic (f.ex. sandbox, EDR).

Many programs cannot be properly analyzed by sandboxes, because they require command line arguments. While command line options for native Windows OS binaries are usually well documented (well, not really, there is a lot of undocumented stuff, but let’s forget about it for a second), command line options used by goodware is a completely different story. And of course, even worse for malware.

The good news about goodware is that they handle command line arguments in a very predictable way. The string comparisons are usually ‘naive’, direct and not optimized, and often, the programs include actual help that can be seen after running the program with the /?, /help, -h, –help arguments. And very often, a search for ‘usage’ keyword inside the binary can help us to find the options that program recognizes. f.ex. this is what we see inside cscript.exe:

Predictable is good, and can serve at least a few purposes:

  • we can generate a list of known parameter strings that goodware typically uses (and even attribute it to specific software vendors)
  • we can create yara signatures for these
  • we can incorporate this set into EDR command line parsing routines to assess invocation’s similarity to known good
  • we can also leverage this to run the sample in a sandbox or manually with these easily discovered command line arguments (kinda like assisted fuzzing)
  • we can include these findings in the report itself to hint analysts they may need to do some manual reversing (it would seem the program accepts the following command line arguments…)

Looking for typical command line arguments is actually quite difficult. There are a lot of ways to implement string comparisons and as I explained long time ago in one of my sandbox series, there are like gazillion different string functions out there. Plus different compilers, different optimizations make the code even harder to comprehend. Naive search for /[a-zA-Z_0-9]_/ could work on a binary level, but this is going to hit a lot of FPs. Decompiled scripts can come to the rescue, as they include actual invocations of programs and specify precisely what parameters will be passed to the program.

The attached list focuses on a basic command line argument extraction (just the /foo part) from around 10K decompiled scripts. More advanced analysis would include options taking parameters (f.ex. /foo bar).

You can download it from here.