Namely DLLs and drivers and such. Things typically loaded in from some kind of exploit or fileless malware hidden inside of a document that can do their damage without loading any processes at all. It would be great if WLC would notifiy the user of a DLL or driver or installed service that hasn’t been verified as safe, but perhaps that should be something the user would need to turn on after install.
|VPN(paid)|VoodooShield(Paid)|SecureAPlus(Paid,Pro)|
SandboxiePlus, By Xanasoft|
HitManPro.ALERT!(Paid)|
Yeah, people ask about this all of the time. Using your dll example, how are you going to run your dll without an exe or command line? This is how VS blocks it. Same with a driver and service. Both require something to install them, which VS should block. If you have a PoC I would be happy to look at it.
At some point we might start implementing anti-exploit mechanisms that will block the kind of things you are talking about even quicker.
Also, please keep in mind… the type of exploits you are referring to run as System, which for example, easily bypasses other similar tech, such as SRP. VS will parse and block the command lines, so it will at a minimum disrupt the attack chain, rendering the attack useless. We can add other anti-exploit tech, but we need to be careful what to add because doing so tends to break things in the system. And we certainly not add a specific exploit mitigation if the OS already provides a mechanism.
“… so it will at a minimum disrupt the attack chain, rendering the attack useless.”
Absolutely. We saw just that with WannaCry: break the chain, the attack fails. OK, some links are better to break than others, but whatever chain-link stops the payload is arguably the best link.
VS already has the capability without compromising the system, so yes we need to be ultra-careful about adding extra stuff. My own preference — and actions — would be to light up a known performer like EEK or ZAM to have a shufti and do what they do best.
_________________________________
Understanding the scope of the problem is the first step on the path to true panic. [Florence Ambrose, "Freefall"]
Exactly… we do not want to add mechanisms that cause issues with the OS, especially if the OS already has mitigations for those types of attacks. Thank you!
I think what I was requesting may have been misinterpreted.
I’m well aware VS has its users covered against the kind of malware propagated as DLL’s and SYS’s
What I was suggesting is for WLC to scan for those kinds of things in addition to what it already scans for. To help ensure that the machine really doesn’t have anything unknown running.
|VPN(paid)|VoodooShield(Paid)|SecureAPlus(Paid,Pro)|
SandboxiePlus, By Xanasoft|
HitManPro.ALERT!(Paid)|
Oops, sorry about that… now that I read your question again I see what you mean. I have been working on a stand alone real time version of WLC for SMB and enterprise, so that is why it was on my mind. The goal is for admins to know that only Safe files are running on their endpoints / networks at any moment in time, and to only allow known Safe files at the kernel level. Kind of like a stripped down version of VS on AutoPilot.
But to answer your question, the supported file types for WLC are currently: .bat, .cmd, .com, .cpl, .dll, .exe, .jse, .msi, .ocx, .pif, .scr, .tmp, .vbe
Yes, it is funny that you should ask. I started the day with a few simple tests, then one thing kind of led to another, and I ended up testing many different deny-by-default products.
As it turns out, the parent / child process mechanism that I have talked about for years now works better than I ever thought it would. Simple whitelisting by the single executable’s path is no longer an effective mechanism to stop malware. The entire attack chain should be considered (parent, child, etc), and I am finding this to be the exception rather than the rule. So VS might be overkill, but that is only because it actually functions as a true deny-by-default.
I will probably create a video on this, it is quite interesting what I found.
.
