Many published security vulnerabilities and attacks are over-hyped; however, dynamic-link library (DLL) sideloading, also known as DLL hijacking, often fails to receive the recognition it deserves. These flaws are unappreciated gems for digital adversaries due to their widespread nature and ease of exploit development. In fact, many Windows services are vulnerable to these attacks today.

A recent malware analysis report by the Federal Bureau of Investigation, the Cybersecurity and Infrastructure Security Agency, the U.S. Cyber Command Cyber National Mission Force, the United Kingdom’s National Cyber Security Center and the National Security Agency, which provided a detailed analysis of 23 files identified as MuddyWater tools, detected a DLL file renamed as a legitimate filename to enable the DLL sideloading technique.

Very few organizations can completely prevent account compromises. The attack vectors are endless: Incidents of phishing, browser drive-bys, watering hole attacks and malicious apps on employees’ personal devices are all significant risks. Even medium-sized organizations battle at least a few incidents each year. What separates strong security programs from the rest is how long it takes an attacker to penetrate further into the infrastructure and how quickly the security team can detect the initial attack, neutralize it and recover.

Understanding a DLL Sideloading Attack

To put it simply, an attacker finds a way to place a malicious DLL file in the same directory as a trusted EXE. If the EXE tries to load a system DLL with the same name, then the attacker’s DLL is loaded instead. And in many cases, an attacker doesn’t even need to know what methods the EXE is planning on calling in the DLL because it is possible to build a DLL that runs code as soon as it is loaded. This is by design, which puts any user account (service account or otherwise) at risk of compromise, provided those users will at some point launch the application.

It’s important to note that this is a particularly acute problem with Windows services. This is because service configurations give attackers an easy way to force the issue immediately by simply adding a malicious DLL and then restarting the service (perhaps through a simple reboot). For an attacker, this is really a no-brainer. The level of sophistication required is low and a single DLL sideloading exploit kit can be used against nearly any software that has unsafe permissions in the installation folder.

Staying Two Steps Ahead of an Attack

To understand what a digital intruder might do once they gain a foothold in your environment, look at the playbook of a typical network pentesting team. With very limited time frames to conduct an assessment, penetration testers will often gravitate to the easiest and most reliable way to gain complete control of an infrastructure. If it is low-hanging fruit for a pentester, then it will be for an adversary (or their automated malware).

In the case of deploying new software in your Windows infrastructure, it’s strongly advised to have a short security validation step that checks the permissions of all executables, DLLs, scripts, and configuration files. It’s then beneficial to automate this. A combination of Powershell scripts and off-the-shelf security tools can greatly help you ensure your new software deployments are safe without a lot of ongoing effort.

Once a process for new software deployments is established, users will have a backlog of software and services that are deployed with questionable permissions. This is where a good security scanning tool can help identify and prioritize legacy deployments. Once service deployment permissions have been located, consider the following: Is this a result of unsafe third-party installers or is this something our team caused by deploying the software in a custom way?

In the case of unsafe third-party installers, it can be wise to have a software vendor address and resolve the issue. This can take time and effort, but can also be safer than having your own team attempt to fix the permissions. For errors resulting from team activity, consider automating the fix by updating permissions on the installation folder with some simple scripting.

If an attack doesn’t appear to be technically sophisticated, it will often be overlooked. Help your team better understand how a DLL sideloading attack works and what steps they can take to lower risk or recover from being exploited today.