Vault7: CIA Hacking Tools Revealed
Navigation: » Latest version
CLSIDs and Junction Folders (Persistence and then some)
SECRET//NOFORN
('toc' missing)
Junction Folders
A junction folder in Windows is a method in which the user can cause a redirection to another folder, usually another known folder. A Junction Folder is considered a hard link. There are a couple of different ways to create junction folders. Registry modification can cause a folder junction point. Another is a desktop.ini entry inside the folder. The third, and probably most useful to us is the method that is a naming convention only. The method is simply to create the folder as such. MyFolder.{CLSID of folder you want to junction to}. Once you have named the folder as such, double clicking the folder will navigate you to the known folder represented to by the CLSID. Microsoft gives you many examples. This way you can easily create a folder that junctions to "Control Panel (All Tasks)" and call it My Control Panel. You can also junction to Pictures, Documents, Internet Explorer, My Computer. All of these special folders have been assigned unique clsids. See CLSIDs (Class IDs) for availble clsids that come default on Windows. Below is example of a junction folder to Control Panel (All Tasks).
Name the folder My Control Panel.{ED7BA470-8E54-465E-825C-99712043E01C} for a junction to Control Panel (All Tasks).
Windows is nice enough to hide the CLSID for you.
The junction works!
So what.
Well, what happens when the CLSID isn't of the expected folders? What if it's not a folder at all? That's where it gets a little interesting.
CLSIDs and COM Objects
So, using CreateGuid I generated a new guid (highly unlikey to have already been used - {24138469-5DDA-479D-A150-3695B9365DC0}).
add the CLSID and we get this.
The CLSID doesn't become hidden if there is nothing to correlate it to. When you nvigate into the folder it appears as a normal folder. However, if you watch Procmon you see this:
From watching Procmon, you can see that navigating inside the folder causes explorer to look for this CLSID in HKEY_CURRENT_USER. By default, the large majority of CLSIIDs are stored under HKEY_LOCAL_MACHINE, yet CLSIDs under HKEY_CURRENT_USER can stll be used. So, now let's set up our key.
Before: 
After: 
Entries Added:
Default of the {24138469-5DDA-479D-A150-3695B9365DC0} key is the name of the COM object: 
Values of the InProcServer32 key: 
Now when we navigate inside of our junction folder, we see:
Execution is gained as verclsid.exe calls process attach on our dll. Nice.
User-level Persistence
Unfortunately, this is probably a better persistence mechanism than execution vector. Mostly, because it would require both a registry write and navigation into the junction folder. When looking at it as a persistence mechanism, all we have to do is set the registry keys, and create the junction folder in a location that explorer (or some other user process) will navigate into/under on startup. Preferrably we would like explorer to navigate into the junction folder. We could do this with Library Files on Windows 7+ (see Windows Library Files (.library-ms) ). For wider coverage using the same technique, I ended up looking into folders navigated for the "start menu". They get loaded at the start, they already exist, they exist in AppData, and they are most often viewed through the start menu.
So, navigate into %appdata%\Microsoft\Windows\Start Menu and you should see directories under the start menu, all should get navigated on login. However, you have to be careful when modifying any of these folders as they are often combined with folders in another location for the start menu and it could be alerting if there are two folders named Accessories in the targets start menu. If desired, you can also create a new folder vs using an already existing one. Anyways, so now takes something like Accessories.
Run a command like below to change the folder to a junction folder (use windows api if coding).
and note that on reboot, we are once again kicked off by verclsid.exe.
Persisting a Dll like an Exe - Windows Run
This is not yet a flushed out technique and is currently in proof-of-concept stage.
Currently, there are a select set of CLSIDs (yet to be determined what makes them different - current assumption is that there are additional registry entries needed), that can be accesssed through cmds Windows->run. The syntax looks something like:
or
These examples open up the "My Documents" folder in windows explorer. However, if the right entries are made, these could help us reuse exe persistence techniques for dlls.
Shortcut Folders + Junction Folders + Libraries + Link Files = Exploitation
Let's combine some of these finds and put them to use. For background on libraries, see Windows Library Files (.library-ms) . For background on link files, see Windows Shortcut Files (Link Files) .
So, if we have a link file exploit, we would like to hide it. Or at least bury it. We also know from playing around with CLSIDs and Junction folders that we can force navigation of a junction folder (enough rendering to get it to load a dll if the clsid is in the registry). Another nice thing about libraries is that they can look pretty similar to a directory and they continue rendering even if the explorer view was changed while rendering was still in process. We'll combine some of these things with a technique used by TAOTailored Access Operation in which a desktop.ini version of the junction folder is used to kick off the rendering of the link file. This brought up a very unique CLSID ({0AFACED1-E828-11D1-9187-B532F1E9575D}) which is the CLSID for a "Shortcut Folder". So what happens when you create the junction, MyFolder.{0AFACED1-E828-11D1-9187-B532F1E9575D}? Well, Microsoft designed Shortcut Folders to store its target in a target.lnk file directly below the junction folder. When the junction folder is navigated, the link file is rendered and execution is gained. The combination means that only the library file is visible in the directory the target navigates to, and all the other folders/file can be system, hidden. Do not use the technique without the library files unless permission is granted. We don't want to appear too close to TAO's technique.
SECRET//NOFORN