Lolbins for connoisseurs… Part 3

Posted on by

I love exploring unexplored software paths. And not necessarily on the assembly level – and that’s because often… it’s not even necessary. They often lead me to some really weird places f.ex. discovering a software that reads a memory address from a specific environmental variable to execute code from that location, or learning that some unhappy devs at AMD or Microsoft sometimes get a bit annoyed, or that many people do stackoverflow when they code, and that many ‘secrets’ can be found in binaries, if you know what to look for….

It’s the simple findings like this that led me to coining what I called The law of a threat hunter, which states:

For every two most distant technologies there exist a developer that will bring them together.

Developers out there do lots of very weird stuff, and more often than not – they make some really hard-to-explain choices – in the end producing monsters that we (‘the cyber folk’) need to deal with (aka ‘assess their maliciousness’), on regular basis.

This post is about yet another case like this…

There is a software called DepthAI. When you install it, you will obviously get all the files required for the software to run, plus a bonus – a full blown copy of PortableGit installed in %LOCALAPPDATA%\Programs\DepthAI\PortableGit directory.

The binaries installed include the whoami, yay! And this is where you will find it:

  • %LOCALAPPDATA%\Programs\DepthAI\PortableGit\usr\bin\whoami.exe

plus, there are lots of other useful lolbinish tools, too:

  • %LOCALAPPDATA%\Programs\DepthAI\PortableGit\mingw64\bin\curl.exe
  • %LOCALAPPDATA%\Programs\DepthAI\PortableGit\mingw64\bin\openssl.exe
  • %LOCALAPPDATA%\Programs\DepthAI\PortableGit\mingw64\bin\xz.exe

plus many others…

Dependencies is what matters these days and we have seen their power with log4j vulnerability, as well as in a cases of many other supply chain attacks, backdoored npm packages and python libraries.

Anytime we think that we are installing a trusted, often single-vendor, even single-vendor and monolith application, in reality… we don’t know what we are doing… We actually apply less and less scrutiny to this process. It’s really terrifying. And mind you, this is not an inflammatory post — it’s a sad realization that the control of what is running on our devices has been taken from us away long time ago, same as the notion of ‘owning anything’, let it be hardware or software.

And here’s the thing… Fravia did say one thing before he died:

Two other possible parachutes are knowing how to reverse engineer software (whose role in our societies and their petty censorships and sniffing attempts is bound to increase dramatically), and a sound learning of more than “just that one” foreign language. These “parachutes” could allow many readers to (maybe) fall on their feet.
Good luck anyway. I do wish all the best to anyone with a brain.

Be curious about the software you run. Be curious about the hardware you run that software on. Break it all apart. And share. Remember that trivial things like lolbin discoveries are just a side effect of your actions. You are pursuing not only the knowledge, but even moreso – the knowing…

Who am I? Asking for my file friend: whoami.exe…

Posted on by

There is a lot talk about whoami.exe recently, so here’s one more post about it…

When we talk about whoami.exe we often think of it in ‘atomic’ terms. You run it, and you get the results. But by doing so we assume a lot i.e. we kinda indirectly know that we are talking about the executable located in this place:

  • c:\windows\system32\whoami.exe

Of course, some of us know that there is also a 32-bit version on the 64-bit OS:

  • c:\windows\SysWOW64\whoami.exe

and then a bunch of copies in WinSxS directory (file names are versioned):

  • c:\Windows\WinSxS\amd64_microsoft-windows-whoami_31bf3856ad364e35_10.0.19041.1_none_846d8bda2133af3c\whoami.exe
  • c:\Windows\WinSxS\wow64_microsoft-windows-whoami_31bf3856ad364e35_10.0.19041.1_none_8ec2362c55947137\whoami.exe
  • c:\Windows\WinSxS\amd64_microsoft-windows-whoami_31bf3856ad364e35_10.0.22621.1_none_30124a0a75945900\whoami.exe
  • c:\Windows\WinSxS\wow64_microsoft-windows-whoami_31bf3856ad364e35_10.0.22621.1_none_3a66f45ca9f51afb\whoami.exe

And of course, we can reveal the hard links for each of these tools using fsutil:

  • fsutil.exe hardlink list c:\windows\System32\whoami.exe
  • fsutil.exe hardlink list c:\windows\SysWOW64\whoami.exe

Plus, on Windows Arm, we have:

  • c:\Windows\SysArm32\whoami.exe

and respective WinSxS directory (file names are versioned):

  • c:\Windows\WinSxS\arm64.arm_microsoft-windows-whoami_31bf3856ad364e35_10.0.22598.1_none_d3774312fcf7fb69\whoami.exe
  • c:\Windows\WinSxS\arm64.x86_microsoft-windows-whoami_31bf3856ad364e35_10.0.22598.1_none_d37c245afcf28323\whoami.exe
  • c:\Windows\WinSxS\arm64_microsoft-windows-whoami_31bf3856ad364e35_10.0.22598.1_none_2de72d3c78a075fb\whoami.exe

But there is more…

If you ever installed cygwin, you probably know of:

  • c:\Cygwin\bin\whoami.exe
  • c:\Cygwin64\bin\whoami.exe

There is also GIT for Windows that installs a lot of windows-friendly Unix tools including, yes, you guessed right, whoami.exe:

  • c:\Program Files\Git\usr\bin\whoami.exe

At this stage, you probably are aware that Program Files is a nightmare as it occurs in many architecture-specific forms, and many localized versions.

You must be thinking now – this thing is multiplying quickly and spreading faster than covid!

But this is not THE END. There really is more.

A Pro version of software called System Scheduler installs the following whoami.exe file:

  • c:\Program Files (x86)\SystemScheduler\WhoAmI.exe

It is probably the first ever whoami.exe I have ever seen that shows the user info on GUI – as a message box 🙂

Then comes another contender, a tool called MacroCommanderPro:

  • c:\Program Files (x86)\MacroCommander\Bin\WhoAmI.exe

Yes, it is also GUI-based whoami 🙂

And this is just a tip of an iceberg…

The reason I write about all this is because some people like to say ‘the moment someone runs whoami.exe on one of your systems, this is an indication of early stages of compromise!’. Their confidence is built on ignorance. And yes, they may be right… yeah…but they are often very wrong…

Telemetry we deal with today is rich and useful, but threat hunting – as a discipline – is still in its early, naive stages. It’s healthy to assume that for every rule written, for every assumption, there is an exception that can be found and not only that — you will very often find it by combing telemetry generated by non-malicious sources…