How to become/continue to be a security researcher?

In my post from 2018 I listed a number of strategies one can use to ‘find interesting stuff’ – that post was heavily focused on Windows’ persistence mechanisms…

Today Dominik posted this twit:

eliminate your self defeatist attitudes

to which I replied:

this is the exact reason why I recently looked at a number of known lolbins only to discover a lot more in my ‘little known’ series, culminating with the regsvr32.exe bomb

Security research discipline is a funny thing.

Anytime we find something interesting we immediately want to tell the whole world about it. These findings are sometimes amazing and mesmerizing, but they also put many other researchers off.

Why?

Seeing all these cool discoveries many security researchers immediately assume that that particular area of research (the one that brought us these cool and flashy discoveries!) is now kinda done and dusted, even saturated… and what follows is that ‘ok, we are done here’ feel that often leads many researchers to make an assumption that anyone trying to explore that particular area further is actually wasting their time…

WRONG!

For every vulnerability, quirk, anomaly found by others you should definitely focus your attention on areas of their research that are often assumed to be ‘fully explored’. That’s because software we look at is complex and it takes forever to understand all its inner workings… Yes, we barely understand the command line arguments of many built-in OS programs, let alone many undiscovered yet vulnerabilities.

Let me give you a few examples…

  • I have mentioned the regsvr32.exe bomb earlier and it’s one of my favorites. So many people looked at regsvr32.exe before but no one has ever mentioned this particular ‘feature’
  • I love discovering unusual logic paths in the software designed to do a specific thing. Take curl.exe as an example. The Windows’ obsession with protocol handlers allows us to use Windows’ curl to copy files… locally
  • rundll32.exe can be used to run JavaScript code, but I wanted it to work with vbscript too, hence this post
  • the difference between 32- and 64- bit environments can be exploited as demonstrated in this post
  • rundll32.exe accepts both API names and their ordinal numbers; this is why we can play around with the ordinal numbers that can be represented in many different ways
  • many tools migrated from Linux world to Windows can do a lot more than expected f.ex. tar.exe can be quite naughty
  • Grzegorz discovered this beauty: If you provide /FS:FILESYSTEM parameter to the format.com utility, the resulting process will try to load (“U”+FILESYSTEM).DLL using the default search path…

There is no such thing as ‘fully explored target’. Check programs’ command line arguments. Look how they deal with environmental variables. See what happens to hardcoded assumptions if you move the program’s binary to a different path we control. Look for undocumented features. Look for documented novelties. Look at DLL’ export functions and see how they analyze the command line arguments (may sound weird, but many DLLs do check command line arguments, as well as hosting process name!). Look at calls to LoadLibrary, LoadLibraryEx. Look at invocations of CreateProcess, Shellexecute, WinExec APIs. Investigate access rights. Take that code outside of its comfort zone. Share what you find out…

Lolbins for connoisseurs… Part 3

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…