It is a form of DLL-Hijacking by-proxy.
DLL-Hijacking is when a application loads a dll-file from a location where an attacker can write. Replacing that DLL with a DLL containing a payload of their choice, will compromise the account running the application. This could be a ordinary user, a administrator or even "NT System", if the application is a service. You cannot replace just any DLL-file. It has to be a file not really needed for the application to function properly. That means it isn't possible in just any application either.
In DLL-sideloading, we also look for dll-files located in locations where we could write. But here, we use a dll-proxy file containing our payload and proxying the applications requests to the original file or a local copy of the original file. This way, we don't break the application and it will continue to work normally.
Even if the application doesn't have DLL-files in its application directory, it could be vulnerable for this kind of attack if it doesn't call the DLL-file(s) using absolute path. What happens then, is that it will look in its current location first and then look in %PATH% to find it.
Like in the screenshot below: Microsoft Teams, trying to load dbghelp.dll from current folder first, fails and continues looking for it in PATH, finding the requested file in c:\windows\system32
A lot of the modern applications, installed in the users %appdata% appears to be vulnerable to DLL-Sideloading. As the user have full control over that folder an attacker could use this to gain access and persistance through e.g. a phishing attack.
In this video, I have shown how a DLL-Sideloading attack works and also that enabling AppLocker without enforcing DLL-rules, is of no use at all.
I made a little POC video back in April, showing the dangers of leaving LLMNR enabled on your Windows computers.
In this video, we can see there is a "feature" in Windows, making the computer sending LLMNR broadcast on every character, if you start typing a UNC path. If you place a computer running Responder on the local network, it will response to every single one of that characters, pretending to be a computer asking for authentication.
Your Windows computer gladly hands out the netNTLM-hash of the logged on user. Those hashes could easily ble cracked by an attacker if the password is easy or/and short, but it can also be relayed to other services on your network, giving the attacker access to them, without even bothering trying to crack the hash.
There have been written tons about this on blogs/articles around on the Internet. If you're not familiar with it, you can read more about Responder and relaying in this excellent article.
The same problem exists if your computer har NBT-NS (Netbios Name-Service) enabled. So, one should absolutely disable those two protocols, as they are really not needed in a corporate network.
This great article, will tell you how to go around to get that task done.
That sounded really scary and was news for me.
I had to see this for myself, so I put up Responder on a computer in my lab network. I first had to verify everything was locked down as it should, and did a testrun from a freshly installed Windows 11 with LLMNR and NBT-NS disabled.
I was in for a surprise...
I didn't even get around to start mitm6! The hashes just started to furiously hit my Responder. Something had clearly changed since the last time I visited the topic. This was really strange and unexpected behaviour.
This time, it looked like mDNS was the culprit!? I wasn't even aware Microsoft had implemented native mDNS support, but apparently they did at some point in Windows 10 and of course Windows 11 and Windows server 2022 has it enabled by default too!
I testet it out on a Windows 2022 Domain controller and a Windows 10 computer too. Hashes all over! mDNS had no qualms about help telling anyone interested, what my netNTLM-hash looked like...
Trying to get to the core of the problem, I inspected services running on the computer and figured out mDNS is a part of the DNSCache service, now.
Disabling DNSCache is not an option. (tried it) It stops mDNS, but it also breaks a lot of other stuff.
Checking the registry, it turns out there is only a key named mDNS under the DNSCache service, nothing else. No parameters to be set/changed.
Spent a whole day and evening Googling for parameters, but couldn't find anything documented anywhere about the "new" mDNS feature.
Using Procmon from Sysinternals, I saw the DNSCache process queriyng the registry for some nonexisting entries.
EnableMDNS sounded exactly like what i was looking for. I added the entry, with a value of 0.
Confirming it being found by the DNSCaching service
Then testing again from my Windows 11 computer.
mDNS stopped its promiscous behaviour and everything was again good in the LANd.
My two cents: mDNS doesn't serve any purpose at all in a corporate network and should be disabled the instance you join the domain.
Don't think Microsoft have implemented control over the feature in an GPO yet.
set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\" -Name EnableMDNS -Value 0 -Type DWord
REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" /v " EnableMDNS" /t REG_DWORD /d "0" /f
It is worth to mention; This mDNS behaviour is seen only in Windows domain environments. Not if you are running it in a Workgroup. This is really strange and I don't know why. If anyone does, I would be happy to be enlightened.