DLL hijacking is not a new attack vector. It’s been around for 20 years or more. It’s not easy, but it’s very effective. Once achieved it provides stealth and persistence — precisely those attributes sought by advanced and state actors.
Forrest Williams, senior security researcher at Cybereason, spotted an incidence of DLL hijacking on a customer’s network; and decided to tackle the problem. His solution was to develop a new scanner, a tool he calls Siofra, that will both detect a hijacking vulnerability and also provide an automated method of exploiting the vulnerability.
It is a drastic solution, and one that leaves him and his company open to criticism in the same way that Metasploit is criticized: it can help bad guys attack good guys. Williams first approached Microsoft and was told, this attack “is predicated on the attacker having written a malicious binary to the directory where the application is launched from. As described in the Windows library search order process, loading binaries from the application directory is by design. This does not meet the bar for security servicing.”
The story behind Siofra, pronounced ‘sheefra’ (a ‘changeling’ in Celtic mythology) is told in a new blog post from Cybereason. The developer, Forrest Williams, discussed the problem with SecurityWeek. He tells the full story in an associated paper (PDF). His hope is that Siofra will eventually force Microsoft to address the DLL hijacking vulnerability in the same way that Mimikatz forced it to address the underlying problem with credentials in the latest release of Windows 10.
DLL hijacking occurs when a modified and weaponized DLL is called by an application instead of the original DLL. It is neither an easy nor a common attack; but a hijacked DLL can be left behind after a network compromise, allowing the attacker to withdraw while leaving a stealthy, persistent and dangerous malware behind. Because of the inherent difficulties, it is primarily used by advanced or state actors.
And it does happen. It happened with the recent CCleaner compromise, now thought to have been conducted by a Chinese state actor. “M.E.DOC is possibly a better example,” said Williams. Here, the .net code in ZvitPublishedObjects.dll had been modified on multiple occasions to allow a malicious actor to gather data and download and execute arbitrary code. “It is even speculated”, said Williams, “that the whole purpose of the M.E.DOC company was really to deliver a malicious payload [the NotPetya wiper] on behalf of the Russian government against Ukraine.”
In both of these cases, it is thought that advanced state actors compromised the supply chain with DLL hijacking. So although the threat isn’t common, it can be devastating; and as nation states continue to increase their cyber activity, so the threat and danger is likely to grow. The growing interaction between geopolitics and cybersecurity makes this inevitable.
For the moment, it appears that Microsoft is unwilling to address the problem. “The only real solution from Microsoft would be whitelisting or code signing so that no DLL is ever loaded into a Microsoft process unless it is digitally signed,” explained Williams. “Thing is, they don’t do this; and I think the reason they don’t do this is because they won’t be able to do backwards compatibility. Also,” he added, “some Microsoft code is designed with ‘just-in-time-compiling’. It’s compiled as the code is run — and there’s no way to sign it. So there’s no real way to create a whitelist. Windows simply wasn’t designed with this issue in mind — so it is design flaws that have prevented them fixing the issue to this day.”
The design flaws will need to be designed out of Windows — but it will take a lot of development effort from Microsoft. “It wouldn’t be an easy fix,” said Williams. “If attacks become more prevalent — and right now they’re not very common — I think that Microsoft would definitely do something. After the release of the Mimikatz tool to steal credentials, making credential stealing much easier, Microsoft has now changed their design. They’ve fixed the issue in the latest Windows 10 release. But it took them a long time to do, and it needed someone to make it easy for the attackers with the release of Mimikatz, before they actually felt the pain and started to solve the problem. I don’t think Microsoft would have fixed the underlying vulnerability that Mimikatz weaponized without it being released. So unless DLL hijacking becomes well-known and used, I don’t think it will ever be fixed.”
Williams hopes that Siofra will change the status quo; that is, force Microsoft to address the issue. Siofra is not the first DLL scanner. “But it has one unique addition,” explains Williams. First it will find vulnerable DLLs; “but then it is able to create an almost identical copy of the DLL that it targets; so that when you exploit one of these vulnerabilities Siofra creates a DLL that is almost a perfect clone except that it’s got a tiny modification that allows the attacker to add their own payload into the DLL. It’s not just a scanner. There have been scanners before; but this scanner is much more powerful. It has the ability to create these attacks and exploit the vulnerability; and that’s unique.”
Williams has little doubt that DLL hijacking will continue and become a growing problem from advanced attackers. The problem is that the vulnerability is everywhere. “When I tested Siofra,” he told SecurityWeek, “I did not find a single application that did not include at least one vulnerable DLL.” This isn’t limited to Microsoft applications, although it includes Windows Defender, Internet Explorer and WMI — none of which were previously known to be vulnerable. But it also includes applications like Adobe Reader and Firefox. “No defensive software wants to delete high-trust applications like these.” As a result, a hijacked DLL simply flies under the radar of anti-malware software.
“DLL hijacking,” suggests Williams, “is the new rootkit.”