You are browsing the archive for LOLBins.

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…

Rundll32 with a vbscript: protocol

October 29, 2019 in Anti-Forensics, Living off the land, LOLBins

Inspired by a question posted on Twitter by Tim, I tried to modify a well-known rundll32 javascript: trick (introduced by poweliks around July 2014 if I am not wrong) to use vbscript. I felt we should be able to make the code work the very same way as the JavaScript.

It turned out to be a bit tricky, because vbscript doesn’t seem to like any whitespace characters in the payload, including encoded spaces, new lines and carriage returns.

I eventually decided to follow a different path and focused on a fact that a first argument passed from this sneaky payload to VBScript interpreter is a string. And since strings can be not only commands, but also actual data bits that can be added together I tried doing so. Using a String function I encapsulated / casted the result of my calculator-launcher code to a string… and the trick worked like a charm:

Here’s a snippet:

rundll32 vbscript:”\..\mshtml,RunHTMLApplication “+String(CreateObject(“Wscript.Shell”).Run(“calc.exe”),0)