You are browsing the archive for Living off the land.

The curious case of svcpack1.dll

November 22, 2019 in Living off the land, LOLBins

When you disassemble/decompile code produced by popular vendors you usually (blindly) assume that they got it right. I know of typical vulnerabilities, I know of business logic bugs, but somehow… I always feel that all the actions of programmers are either justified, or at least, reasonable within a scope of a particular operation…

This is why the case of svcpack1.dll is puzzling me.

Imagine a signed .exe from Microsoft literally injecting a remote thread into winlogon.exe. Imagine this thread doing nothing, but loading a library called `svcpack1.dll`. Okay. It’s a legacy code. It’s from a Service Pack Update executable, but still….

This is an interesting opportunity.

As I have said may times before… re-usigned binaries are probably a future of malicious activities. Signed, with a great reputation score, yet… given specific circumstances… possibly… really bad….

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.).


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…