Quo Vadis, Lolbin

November 1, 2019 in Living off the land, LOLBins

I am sometimes wondering what Lolbin really means. Most of us assume that a binary or script listed in this context is always ‘trusted’. And the trust ‘bit’ typically comes from a very reputable source – the binary/script is signed and it means that it will run unchallenged in most of the ‘negative’ scenarios (EDR, AppLocker, etc.).

However…

Over last 30 years there were many reputable software releases out there that were not signed, and they still rely on on/build upon this silly concept of ‘trust’. And the ‘trust’ is not only built around the concept of a authenticode signature, but often also a side-effect of a simple act of ‘belonging’.

What do I mean by this?

If it is a binary with a hash that belongs to a ‘clean’ category (nowadays it’s typically checked via NIST, MSDN and other ‘clean’ hash sets) then it’s most likely good….

This opens a lot of opportunities that could have been overlooked otherwise: i.e. unsigned, good files that are NOT detected by any AV/AI/ML engine, but remain at large could be dropped/re-purposed to deliver a ‘bypass <insert the engine>’ blow. There are actually many of them.

Time for an example…

While installing an old version of MS Access 2003 on my VM Guest test system I noticed that one of binaries used by the setup program is called SHELEXEC.EXE. The only function of this small program is to execute a command passed to it via a command line – and the command is executed via a call to a ShellExecutA API:

This is a Lolbin functionality in statu nascendi.

And while this may look like a non-issue, there are at least two items we should highlight:

  • Any binary (whether signed or unsigned) can be a LolBin
  • Even if program execution is limited to ‘signed only’, or ‘reputation=good’ binaries, there is a high chance that some of the old-school binaries deemed to be ‘good’ for many years can be abused to run something bad; i.e. reputation is a double-edged sword; just because most of 1000000 systems have shown this binary to be used for good purposes over last 20 years doesn’t mean that it cannot be used for nefarious purposes; aka the ‘maliciousness’ of a file has a completely different meaning today as opposed to say 20 years ago (aka context matters)

The bottom line is: many ‘clean’, ‘well-known-for-years’ executables can help to run other executables and code whether some of them are signed or not. This is still a very under explored area…

Share this :)

Comments are closed.