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
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"'
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