Hi, Most of the exploits are based on the browser based exploits or via email attachments. If you secure (restrict) any browser or an email clients attachments that automatically opens a restricted pdf viewer. Im not advertising Spyshelter Premium, but it is really powerfull HIPS. For example, you can make rules that on which folders are access to and block .js(teslacrypt) files for example easily. How ever, it is a the best HIPS for x64 so far. -moredhel
Yes I agree, for example Comodo annoyed the hell out of me, with dumb alerts about system apps. The problem is, in order to solve it, you end up white-listing way too much, at least according to my feeling. That's why I didn't like Comodo. But I'm not into auto allowing digitally signed apps.
It's not perfect, but it's indeed the best HIPS for Win 64 bit systems, at the moment. It sounds like it's intrusion detection, so they don't actually block anything, they simply look for malicious modification inside the memory, no matter if the malware is delivered via some exploit or not. This is something that HIPS don't do. The approach that Trusteer Apex takes, is also interesting: http://www-03.ibm.com/software/products/nl/trusteer-apex-adv-malware
Most HIPS's monitor Win API calls for those associated with memory modification. Most exploits use this method but there are other memory modification methods. It is questionable whether the HIPS would catch these other methods.
As i far know, ring 1-2-3 needs a driver(dll) installed on the system. And on a goverment side of things, one can think an backdoor for Agnitum products.
Drivers are for ring 0, and are typically given the .sys extension on Windows. And I doubt that Agnitum itself is a backdoor (though there are probably certain things it won't detect). How many of them bother modifying a program's .text segment though? Edit: Yeah, what I'm saying here is that stack and heap space will already be modified (quite a lot) during the normal course of program execution. And those, not static code, are where most exploits work (e.g. the famous stack-smashing buffer overflow attack). I'd assume that the product in question looks for other things besides changes in the static code segment, otherwise it would basically be useless. But then I'm not sure how much usefulness the comparison with the stored executable image would add, anyway. And now you might be asking, "wait a minute, couldn't they figure out on the fly how the application will change in memory, just from the EXE image?" But unfortunately the answer is no, that cannot be done accurately, because it is a manifestation of the Halting Problem: https://en.wikipedia.org/wiki/Halting_problem Attempts to derive the runtime nature of a program from its EXE image, without running it, are going to be limited to something like AV heuristics, i.e. an educated guess. One could maybe analyze the behavior of the program at runtime, in isolation, and thereby get a good idea of what the program's memory would normally look like; and kill it if it deviates from that model. A kind of inverted version of AV heuristics, I guess. But in that case you could get false positives (and false negatives!) from outlier behavior. Short version: I'm pretty sure that data sheet is full of marketing drivel.
a .dll and and a .sys are runtimes as far i know. So if i make an notepad text with an MZ headear of if, like "mz test" and saving it as a txt, the famous av/what went crazy. Emsisoft style is, that it injects their own prosesses to all running prosesses, so it kinda behaves like a trojans do.
im using CFW, set on paranoid, then set training mode only for every legit apps i install, deleted the Trusted Vendor List, added only the vendors running on my system, set some vulnerable processes as "unrecognized" , whitelisted those i know. results: popups only if something want to install or if a process not yet whitelisted is starting. After a few days, i barely had more than 10 popups a day (and those are processes i didn't ran earlier. it is like teaching a young child to do or don't , longer the time pass, less monitoring you will need.
Of course it's also marketing, but I don't see why they wouldn't be able to spot malicious behavior in memory. It's not exactly the same but Trusteer Apex makes use of what they call Stateful Application Control: "By analyzing what he application is doing (operation) and why it is doing it (state), Trusteer Apex can automatically and accurately determine if an application action is legitimate or malicious."
I didn't go so far with Comodo deleting TVL. Good trick in training HIPS (not only Comodo's) is to restart in learning mode, of course you must be sure that your system is clean.
Anything from a .dll, .exe, or .sys (among others) can be used as a kernel component, eg Ring 0. NVT's Kernel Mode Drivers Manger or LoadOrder by SysInternals are a decent way to see what's on your system. I'm tempted (oh so tempted) to argue on the Agnitum backdoor comment but seeing as the injected wl_hook dll method [while archaic and needing a new solution; no arguments there!] is basically just a 'user space' component which results in the original comment being nothing but amusing IMHO I'll try not to. I could be wrong, but it doesn't show up in either of the above mentioned programs. I'd certainly hate to be wrong and guilty of actually using that software if even if the wl hook was a kernel mode component (even if I'm wrong on that count that doesn't mean it has a backdoor) with a backdoor. (I do use Agnitum products and would hate to see proof that I'm wrong! ~ maybe not hate, guess I'd be happier to know but I'd feel betrayed and that would be a bad situation for them and me!)
