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…