Mortar Loader in practice: Stealth attack with Microsoft Office add-ins and OneDrive

In this blog post, we will explore the extended functionalities of Mortar Loader and how it can be weaponized and replicated with different attack profiles such as DLL sideloading and malicious Office add-ins.

Mortar Loader is a tool designed to help security professionals and Red Teams evade detection in operations by loading encrypted shellcode and PE executables and using various evasion tactics.

Its latest version was released last year and received positive feedback from the security community after having been presented publicly. Surprisingly, at the time of writing this blog post, Mortar Loader has not been flagged as malicious by several well-known security solutions. This could be because it uses less common programming languages, particularly Pascal. As indicated by the ‘Any.Run’ security team, using less common programming languages makes it more difficult to detect.

DLL injection is a common attack technique which has been used by hackers for decades. DLL hijacking is an attack technique that injects a malicious dynamic link library file within the search order of an application. By placing or replacing a (required) DLL file, the malicious library file will be loaded and executed upon starting the application.

In July 2020, a security researcher published a DLL hijacking vulnerability affecting the OneDrive Windows application on Packet Storm. This vulnerability enables attackers to substitute missing libraries in the local system path, leading to user level persistence in the system.

From an attacker's perspective, exploiting this vulnerability could grant persistent access to affected systems, given that OneDrive is widely used in business environments.

To confirm the existence of this vulnerability on Windows 11, we observed that during the initial startup of OneDrive, it searches for two specific DLL modules that are reported as not found. These missing libraries, belonging to Microsoft’s graphical interface components, suggest that the application continues to call upon these libraries not only at startup but also when navigating through its graphical dialog boxes.

The following screenshot shows the name of the missing module in Windows 11.

Microsoft has previously acknowledged a similar issue, stating that the Microsoft Security Response Center (MSRC) does not view path DLL hijacking as a vulnerability, even though it is part of the design.

Mortar Loader is distributed and compiled as a dynamic link library (DLL), making it adaptable for use in various attack scenarios that were discussed in a previous article. One of these attack techniques involves leveraging Mortar with a legitimate Windows application that is susceptible to DLL hijacking, such as OneDrive. 

It's worth noting that attackers using DLL hijacking to execute their malicious payloads are often less detected compared to more conventional methods, such as injecting a DLL into a process or running it with rundll32.

Reproducing the attack utilizing the OneDrive vulnerability with Mortar is not complicated and can be done by following the steps below: 

1. We need to make some modifications to the runtime and assure that the shellcode execution logic starts immediately at the main DLL entry point by removing some lines of code as shown in the figure below:

2. Then directly call the early bird injection function with the embedded encoded remote address that hosts the shellcode.

3. Compile and rename the aggressor.dll file into Microsoft.UI.Xaml.XamlTypeinfo.dll and then copy it into the vulnerable path: %AppData%\local\Microsoft\WindowsApps\.

4. Finally, OneDrive will sideload the loader and the shellcode is executed.

Microsoft Office is still the most popular software to serve as an entry point for threat actors in getting their payloads into a targeted environment. The importance of Office makes these applications a consistent avenue for threat actors to set up several attack mechanisms.

Add-ins come in the form of specific office formats that might contain VBA code or precompiled .NET code, such as VSTO plugins. Additionally, it also comes in the form of a dynamic link library (DLL).

For instance, Excel extends its functionality by using XLL file extensions, and if a user would try to open these XLL files in Windows, Excel will launch and attempt to run the loaded add-ins. With this approach, a message about potential security concerns will be displayed, which is very similar to what occurs when opening an Excel file with an embedded VBA macro.

During the in-phase, malicious actors would use multiple functions such as AutoOpen, AutoClose for Excel. Those functions are called by the implemented event handler when a document is opened or closed.

XLL files are just standard dynamic link library files, and with this information, we can use Mortar Loader as an Excel add-in. However, we need to implement a certain type of export function, which will be called by the Excel add-ins manager during the application launch. Below is a list of XLL interface functions that can be used.

• xlAddInManagerInfo
• xlAutoRemove
• xlAutoOpen
• xlAutoClose

To replicate the attack with Mortar Loader, you need to do the following:

1. Create a new function with the xlAutoOpen event and use the same early bird code injection as shown in the picture below:

3. Once Excel is started, the loader will fetch the encrypted shellcode and run it within the memory. 

For a quick demonstration, it is easier to use the published gist code and to replace it in the original project: 

https://gist.github.com/lawrenceamer/a59666765a4a15705c0f80cbe838733e. 

In summary, we first showed how to use Mortar Loader with different attack vectors to gain system persistence, by exploiting OneDrive DLL hijacking, and then how to modify the loader and use it with Microsoft Office add-ins.

• New Redline Version: Uses Lua Bytecode, Propagates Through GitHub - https://any.run/cybersecurity-blog/new-redline-version/.
• https://packetstormsecurity.com/files/158380/Microsoft-OneDrive-19.232.1124.0010-DLL-Hijacking.html
• https://msrc.microsoft.com/blog/2018/04/triaging-a-dll-planting-vulnerability/