Sakula - an adventure in DLL planting

This is a local mirror of a blog written by me and originally published by NCC Group.

You can also read the related publication: Sakula DLL planting analysis.

Introduction

In April this year a file was uploaded to VirusTotal which NCC Group’s technical intelligence flagged as the Sakula malware. Two interesting things stood out: firstly, the implant itself is never stored on disk. Secondly, a legitimate executable from Kaspersky is used to load part of the malware by planting a malicious DLL in the same directory, presumably to bypass some endpoint protection or avoid suspicious prompts from User Account Control (UAC). Signing details are valid, as shown in the image below.

It quickly became apparent that somebody had uploaded an older malware sample to VirusTotal; similar files were found from 2014 and 2015. However, it provided an excellent opportunity for the author to brush off WinDbg and learn some new skills with a real-world example.

During analysis we identified the same vulnerable Kaspersky file used to deploy both PlugX and Maudi malware. Use of signed anti-virus executables is a common theme, especially where they are vulnerable to DLL planting, privilege escalation, or other issues.

A full technical note explaining the analysis process has been uploaded to our Cyber Defence GitHub repository. We’ve also shared the IDA databases and scripts produced during analysis for anybody interested in how to analyse each component and extract the implant from memory.

Potential Mitigations

It’s important to understand how to mitigate this whole class of vulnerabilities to protect your entire IT estate.

Like many pieces of malware, this sample used the %APPDATA% directory to store the executable. Application whitelisting and Software Restriction Policies can be used to lock this down, preventing unauthorised software from running (see this Microsoft article). It’s also important to ensure that standard users cannot write to any file or directory they don’t need to, which will prevent any software from replacing system binaries or planting additional DLLs.

Organisations with a SIEM or endpoint protection solution should review event logs and audit what executables are present, especially those set to autorun. Identifying audit failures or SRP violations, or understanding why one machine of thousands has a unique executable present, can be an invaluable technique for your blue team.

To protect against DLL planting using specific DLL names it is possible to adjust the default search order or add names to the KnownDLLs list (note that the linked Microsoft article is from 2004!). However, any change to these settings requires careful testing to ensure they don’t affect legitimate software which is installed.

Finally, for those developing applications the SetDllDirectory API can be used to adjust or limit the directories Windows will search when loading DLLs. This technique can ensure that code is only loaded from valid Windows libraries or from specifically-chosen directories (e.g. for bespoke code such as vendor libraries or plugins).

Conclusion

Although the Sakula sample analysed was not new, it highlights a growing trend of adversaries attempting to use legitimate software to disguise malware. Stealing a code-signing certificate is appealing for an attacker, but using a trusted executable offers a greater chance of blending in with genuine software.