If you have ever dismissed a search order binary plant attack because the folder from where it takes place doesn’t allow for writes without elevation?

Controlling where the search order takes place

If you have ever dismissed a search-order binary plant style attack because the folder from where it takes place doesn’t allow for writes without elevation, such as Program files, Program Files (x86) ?, I have in the past, and I have also had the risk score lowered due to the requirement of elevation, and the old ‘if you have admin rights it’s game over’ … fair (ish) point.

Sometimes if you make a folder in your low privilege (user controlled) directory  and launch the executable from your folder, you’re actually bringing the search order issue into a folder you control - Nice!

Those bin-plants that are useless without elevation can come back to life under new context, the elevation to write barrier is removed by doing it this way

To repeat this, you'll need Procmon and Windows 10/11 (if you want to get deeper, you can use Nirsoft's AdvancedRun tool (keeping in the theme of GUI driven exploration and discovery)

  • Create a folder on your desktop named something slightly random (I prefer ‘m00’probably something to do with IRC or metasploit )
  • Have your procmon to NAME_NOT_FOUND and path contains ‘m00’ (or your random word)
  • Open a command prompt in that location C:\Users\John\Desktop\m00\
  • Launch your executables from here and see what procmon tells you

That’s it. it's upto you now to see how this can assist you

If we look at this Lolbas I'd found while exploring this new approach it's a good example for all to use, now, there are detections for it now (in enterprise security tooling) , but that's the point, altho you probably wont see thsoe detections at play if you're following along on your home computer, so, with the settings we discussed above, in your command prompt with m00 as the current working directory tyle and execute 'workfolders' and you should see procmon present control.exe NAME_NOT_FOUND, the first thing that's happening is because WorkFolders.exe resides in C:\Windows\System32\ it can be called from anywhere and we dont need to add exe, so while we could wrap the exe's path in doublequotes, as you would for exe's outside of System32 we dont need to because it's inside System32

  • Stuff in System32 call it without the exe from anywhere
  • Stuff not in System32 call it in double quotes, full path to exe  
Launching 'workfolders' in the m00 folder you can see control.exe wants to run here now

So that's workfolders, let's get some more ...

Example   'expLoads' witnessed's at the time of republishing (I'm not sure if anyone has documented these so I'll leave attribution as pending)

iediagcmd.exe will look for ipconfig.exe,route.exe,netsh.exe and makecab.exe iediagcmd when called from your own location you will need to declare its full path, on Windows10 that is C:\Program Files\Internet Explorer\iediagcmd.exe (needs to work it's way into LolBas)

Some other examples, GatherNetworkInfo.vbs resides in C:\Windows\System32\ so we can just call 'GatherNetworkInfo' from anywhere, and we can see that it wants to call cmd.exe, powershell.exe, powercfg.exe,sc.exe,reg.exe,netsh.exe,

Another example outside of System32 is '"C:\Windows\SysWOW64\main.cpl"'

I wonder what happens If I put MOUSE.DLL in the user controlled folder

That's right, you guessed it, if you place a dll file called MOUSE.DLL in the user controlled folder (m00) it will execute, this is handy for bad guys and those of us ironing out defects.

And "C:\Windows\SysWOW64\sysdm.cpl" will want SystemPropertiesComputerName.exe, if you provide your own executable .exe wiht this name in a location of your choice, you can have sysdm.cpl run it for you.

Company Executable Wanting Fixed
Microsoft iediagcmd.exe ipconfig,route.exe,netsh.exe,makecab.exe No
Microsoft Workfolders.exe control.exe No
Microsoft wsl.exe wslhost.exe No
Microsoft GatherNetworkInfo.vbs powershell.exe,cmd.exe,powercfg.exe,reg.exe,netsh.exe No
Microsoft main.cpl MOUSE.DLL No
Microsoft system.cpl SystemPropertiesComputerName.exe No
Microsoft PhoneExperienceHost.exe YourPhone.AppCore.WinRT.Utilities.dll No

Back to 'living off the land' something you may have notices is that GatherNetworkInfo is actually a VBS file what this is telling us is that there are many filetypes that arent .exe, .dll that will want to join the party and pull in other executables in to help them get the information they need for thier task, look at your environment variables, specifically the Pathtext contents it should resemble something like this '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' - all these extensions will execute, there may be more, if there are others than these listed, start with those first ;) but many 3rd party's will used other files to get what they need, third party .bat files and powershell script files are fruitful

If you're a visual learner (like me sometimes) I've put together a screen recording that touches on a few if the things listed above

There is a lot of this with 3rd party applications, get stuck in!