DLL only Drivebys?

Hi ssj, since you test alot of malware I wanted to ask if you ever came by a driveby that only consists of a lone DLL file. If so then what can a DLL file accomplish on its own? can it execute simultaneously without any user intervention?

Hi Rico, yes I do test malware from time to time (only interesting ones mind you), but unfortunately I don't have much knowledge in terms of exact programming mechanisms.

As far as I understand it, a DLL file needs to have some other process to direct it to run/load. I suspect that eg. the web browser can be used as the "other process". So yes, I think in the right circumstances and in this context, a malicious DLL file can be used to cause significant damage without any user intervention.

I'm not aware of any drive-by that ONLY used a DLL file, but then as I said, I've never known much about the mechanisms of malware propagation.

Hopefully p2u can clarify it for us.

Rico wrote:If so then what can a DLL file accomplish on its own? can it execute simultaneously without any user intervention?

A DLL is a module that contains functions and data that can be used by a program or by another DLL. It cannot launch itself (the system can, at startup, for example) and the user cannot launch it by double-clicking it. All it takes for a DLL to be used is: open any file and the (usually vulnerable) program which is linked to the file type will launch, load the DLL and follow the instructions therein. The "trigger" can be a .gif image on a remote server, for example. Sometimes, it is not even necessary for the user to click on anything (e.g. with Adobe PDF exploits); just opening the directory where the "trigger" file (in this case a PDF file) is located will be enough to launch the dll loading mechanism. What happens next is up to the creator of the exploit, but usually it will be something like a command to the program that opened the "trigger" file to download and launch some executable from somewhere. Since the vulnerable program will most likely be "Trusted" (whitelisted by your security vendor), this will work in most cases unless you have 1) a good anti-executable or 2) a good sandbox or 3) some super-paranoid HIPS program with maximum settings (not workable for the average user).
P.S.: I basically excluded this type of on-line exploits by:
1) Removing ALL plugins from my browser (Firefox itself is not vulnerable to binary planting)
2) Disabling lots of Windows services (especially the Web Client service plays a not-so-nice role in binary planting)
3) Using Firefox with NoScript (default whitelist removed; no exceptions configured) and extreme DefaultDeny Adblock Plus settings (sites that are not in the white list can load only text)
4) Setting extremely tight firewall rules - on the application level, only Firefox has Internet access, so any attempt to download something with anything else but Firefox will fail. My default browser (surprise, surprise) = IE8, but it can't get out.

Paul

Excellent post p2u! Thank you for your insight.

I wonder if Sandboxie covers DLL execution, if not then it would be a great suggestion for the developer to bulkup the execution control setting.

Sandboxie does not block DLL execution. As far as I know, Sandboxie's start/run restrictions only block ".exe" execution. But then Sandboxie was never made to be an anti-executable. The way I see it, the start/run restrictions are simply a bonus. Still, I guess there's no harm in putting DLL blocking as a Feature Request.