Obtaining Code Execution via Windows Library Files
In this section, we’ll leverage a two-stage client-side attack.
In the first stage, we’ll use Windows library files to gain a foothold
on the target system and set up the second stage.
In the second stage, we’ll use the foothold to provide an executable file
that will start a reverse shell when double-clicked.
To demonstrate this, we’ll first set up a WebDAV share on our Kali system.
First, we’ll create the directory to use as the WebDAV share that will contain
our .lnk file.
For now, let’s place a test.txt file in this directory.
Next, we’ll launch the webdav server.
The first parameter we’ll provide is host, which specifies the host to serve from.
We’ll listen on all interfaces.
Next, we’ll specify the listening port,
and disable authentication to our share.
Finally, we’ll set the root of the directory of our WebDAV share.
The output indicates that the WebDAV server is now running on port 80.
Let’s confirm this.
We can successfully browse to the WebDAV share.
Next, let’s create the Windows library file.
Once connected to the client,
we’ll find the Visual Studio Code application on the desktop,
which we’ll use to create our library file.
In the menu bar, we’ll click on File then New Text File.
We’ll then save the empty file as config.Library-ms
on the offsec user’s desktop.
As soon as we save the file with this file extension,
it is displayed with an icon.
While the icon doesn’t look dangerous, it is not commonly used by Windows
and therefore may raise suspicions.
To increase the chances that our victim will execute our file,
let’s change its appearance.
Library files consist of three major parts and are written in XML
to specify the parameters for accessing remote locations.
We’ll begin by adding the XML and library file’s format version.
Our code contains the namespace for the library file.
This is the namespace for the version of the library file format
starting from Windows 7.
Next, we’ll add two tags providing information about the library.
The name tag specifies the name of this library.
We must not confuse this with an arbitrary name that we could set randomly.
We need to specify the name of the library by providing a DLL name and index.
The version tag can be set to a numerical value of our choice, for example, 6.
Next, we’ll add the isLibraryPinned tag.
This element specifies if the library is pinned to the navigation pane
in Windows Explorer.
For our targets, this may be another small detail to make the whole process
feel more genuine and therefore, we’ll set it to true.
The next tag we’ll add is iconReference,
which determines what icon is used to display the library file.
We must specify the value in the same format as the name element.
We’ll use the Pictures folder icon from the default Windows icons.
Now, let’s add the templateInfo tags, which contain the folderType tags.
These tags determine the columns and details that appear in Windows Explorer
by default after opening the library.
For this example,
we’ll use the Documents GUID to appear as convincing as possible for the victim.
The next tag marks the beginning of the library locations section.
In this section,
we specify the storage location where our library file should point to.
We’ll begin by creating the searchConnectorDescriptionList tag,
which contains a list of search connectors defined by searchConnectorDescription.
Search connectors are used by library files to specify the connection settings
to a remote location.
Inside the description of the search connector,
we’ll specify information and parameters for our WebDAV share.
The first tag we’ll add is the isDefaultSaveLocation tag
with the value set to true.
This tag determines the behavior of Windows Explorer when a user chooses
to save an item.
To use the default behavior and location, we’ll set it to true.
Next, we have the isSupported tag, which is not documented in the
Microsoft Documentation webpage, and is used for compatibility.
We can set it to false.
The most important tag is url, which we need to point to our previously-created
WebDAV share over HTTP.
It is contained within the simpleLocation tags,
which we can use to specify the remote location in a more user-friendly way.
We have just reviewed the XML code for all of the sections of our library File.
We now have a basic understanding of the inner workings of library files
and can customize them to fit our needs.
Let’s save and close the file in Visual Studio Code.
We’ll then double-click the Library file on the Desktop.
When we open the directory in Explorer,
we find the previously-created test.txt file we placed in the WebDAV share.
Therefore, the library file works and embeds the connection to the WebDAV share.
Very nice!
As an added bonus, the path in the navigation bar only shows config
without any indication that this is actually a remote location.
This makes it a perfect first stage for our client-side attack.
When we re-open our file in Visual Studio Code,
we find that a new tag named serialized appeared.
The tag contains base64-encoded information about the location
of the url tag.
Additionally, the content inside the url tags has changed.
Windows tries to optimize the WebDAV connection information for the
Windows WebDAV client and therefore modifies it.
The library file still works when we double-click it,
but due to the encoded information in the serialized tag,
it may not be working on other machines or after a restart.
This could result in a situation where our client-side attack fails,
because Windows Explorer shows an empty WebDAV share.
However, this is not a big deal since in most assessments,
we only need the victim to double-click the file once.
Now that we have a working Windows library file,
we’ll need to create the shortcut file.
The goal is to start a reverse shell by putting the .lnk shortcut file
on the WebDAV share for the victim to execute.
Let’s create the shortcut on the desktop for the offsec user.
For this, we’ll right-click on the desktop and click on New, then on Shortcut.
In the Create Shortcut window,
we can enter a path to a program along with arguments,
which will be pointed to by the shortcut.
We’ll point the shortcut to PowerShell and use another download cradle
to load PowerCat from our Kali machine and start a reverse shell.
We’ll use the command we leveraged previously:
We’ll enter this command into the input field and click Next.
In the next window, let’s enter automatic_configuration as the name
for the shortcut file and click Finish to create the file.
On our Kali machine, let’s start a web server and Netcat listener.
To confirm that the download cradle and the PowerCat reverse shell works,
let’s double-click the shortcut file on the desktop.
The Netcat listener should receive a reverse shell.
To conclude this section, let’s obtain a reverse shell from another machine.
For this example, we’ll provide the Windows library file we created
to a simulated victim with a pretext.
Our goal is convince the victim to double-click the shortcut
after embedding the WebDAV share via the prepared Windows library file.
The pretext is an important aspect of this client-side attack.
In this case we could tell the target that we are a new member of the IT team
and we need to configure all client systems for the new management platform.
We’ll also tell them that we’ve included a user-friendly configuration program.
Now, let’s copy the shortcut file to our WebDAV directory on our Kali machine.
For convenience, we can use the Config library file to copy the shortcut file
into the directory.
In a normal assessment, we would most likely send the library file via email,
but for this example, we’ll use an SMB share to simulate the delivery step.
To upload the library file to the SMB share,
we’ll use smbclient with the -c parameter to specify the put command.
After we put the library file on the target’s machine via smbclient,
a simulated user on the system opens it and starts the reverse shell
by executing the shortcut file.
We successfully received a reverse shell with our Library and shortcut files.
Excellent.
We could also have combined this technique with our previous Office macro attack,
or any other type of client-side attacks.
In this section, we learned about Windows Library files and how to
weaponize them as an effective first stage to deliver an executable file
in client-side attacks.
As second stage, we used a shortcut file to download PowerCat
and start a reverse shell.
Windows Library files are a great way to deliver our second stage payloads
without exposing them to security technologies such as spam filters.