... kernel tampering... You talk about WSA but from what you say you seem not having an idea how WSA works. Did you test what you describe? Have you ever run WSA? Please try it and come back here with some evidence. Unfortunately from time to time some users starts to highlight problems or weird/apocalyptic scenario that then can never show in practice...
No, that you are spreading FUD on WSA with no evidence put forward and little knowledge about how WSA works (and the partial reading of my message seems to confirm it) lol . It was discussed in this forum before ad nauseam, i.e. type and severity of infection lead to different reactions by WSA (before than later). But I have the impression this explanation will not help
Norton 2015 now has a rollback type of feature. As expected, it's getting difficult to test Norton under synthetic environments similar to what I see with Webroot. But I feel these types of methods are the future. Webroot was just ahead of the game in this regard, and others (Trend, Norton, etc) are catching up, and implementing similar things.
That's interesting. When DLL is loaded in browser (and monitored by WSA) how can WSA distinguish actions made by browser itself (or by user) and actions made by loaded DLL? Or does rollback undo all changes made by browser (good and bad) after DLL was loaded?
The funniest thing that I have found in my four years at Wilders is that bunch of people which really believes that the first person to say the word "kernel" wins the discussion.
I guess I should say it's more like Webroot these days with all of the back end changes. I always felt Norton's Rollback was pretty hideous before 2015.
Yeah using the word kernel is like a red flag to your opponent which indicates that you`re about to take discussion to another level. So it`s back off time or you`re getting hit and buried with kernel modification theorums.......you mutha! Regards Eck
Rollback... oh rollback. We don't need up to the minute detection if we have rollback right ? Well there is no such thing as reliable rollback at least the way Webroot is doing it.
If you are suggesting that rollback helps with protection, you are wrong. It helps with clean AFTER the malware has been detected, by which time all your info could be in the hands of your Russian friends.
Webroot also rolls your info back ;-) Beside joking. Rollback contains always some risks, esp. when you can't prevent what malware is doing in the meantime. (stealing data etc.). Malware does more than just sitting on Pc and waiting for rollback, cleaning etc. And not always the other mechanisms jump in Regarding "others start to copy Webroots features". Honestly I don't see any feature, which is so unique and never was there in some products years ago.
Well, I have been following this thread with great interest, although alas much of what has been said goes over my head, my being semi-illiterate in computer technology know-how and such things. All I can say for my part is that until late 2006, I was becoming more and more inured to the reality that I was having to call in a computer man once every 15 months or so because the different AV programmes I had been recommended and tried, each in themselves household names, seemed depressingly unable to keep me clean. It was almost by chance in late 2006 that I discovered Prevx, subsequently acquired by Webroot, and on whose technology Webroot SecureAnywhere is built. Since then I have never knowingly been infected. Never. And so no longer do I need to call in a computer man. Or call the AV support guys to clean my computer. And I'm still waiting for that day to happen. Quite a lot of what is said here did make me worry. But what makes me worry even more is the thought of having to go back to my experiences prior to moving over to Prevx->Webroot. So in the end, the proof of the pudding for me is in the eating. Just my two cents worth ...
I am sorry but I think the engineer is missing the point. As far as I know the .dll in the scenario I've mentioned never hits the disk and thus isn't executed from the disk. Hence there is nothing for WSA to scan and no new process to start journalling. I think this doesn't apply here as well, as there is no third-party process trying to inject code into the browser but rather the browser injecting code into itself. Does the identity shield cover that? I doubt that. In the scenario I mentioned there would be no dropper hitting the disk and executing from it. This is why I was so specific. The browser would be executing malicious code solely in its own memory, hence there is nothing for WSA's real-time shield to scan and no new processes to journal. All the malicious behavior originates solely from the browser. For example the browser could be used to encrypt personal files as well. I know this is theoretical and not happening right now and of course I could be wrong, but I think you could circumvent journalling this way (and I did not use the word "kernel" , no kernel exploit involved).
Well if you think so why don't you come over to the Webroot Community and they can sort you out instead of spreading FUD? TH
There is no reason to make this personal and accuse me of spreading FUD and just because some vendors have decided to withdraw to their own forums doesn't mean we can't discuss their products here at Wilders. I am sorry but there is little interest on my part in discussing such a technical topic in a product support forum with a very small audience, where the chances of a productive discussion may be lower than here, considering even the engineer may have not completely understood the topic, yet was very quick to (possibly) overstate the capabilities of the product. Thank you anyway for communicating this topic with the Webroot personnel. If it's okay with you we can end this right here. I am sorry if there was anything in my way of writing that gave you the impression that it was my intention to spread FUD. I find Webroot's approach at protection very interesting and I salute them for their identity shield because it is so unobtrusive and yet so effective. I am just trying to fully understand the journalling function and if there are current threats with the capability to to circumvent it.
Okay I will say your wrong then and spreading info that you know nothing about I give you Quote's from the Expert's and you still deny so to me it's all FUD. Prove me otherwise? Also they keep updating the Client and some of that could be for the Monitoring and Rollback Feature but they don't say as Roy said: "5) Journalling works on FAT32 file systems are well as NTFS systems. I am not going to talk too much about our actual tech as I don't want to give the malware authors any help." TH
It's a little bit crazy and unfair, how Webroot (marketing) personal and some fans always attack critical minds with words like "FUD" and ask them for prooving... In the last example... you and your quote from the dev shows, that you seem not even to understand the argument of @qakbot. Because the citation from your researcher makes clear when journaling jumps in - at a time most protection mechanisms have failed. And if unknown malware is executed journaling jumps in and can rollback later, wow.. But it does not protect from cases where f.e. malware steals data in the meantime. If f.e. it uses not a browser for sending them then WebShield/Identy Shield doesn't help. All clear from the statement you quoted. Thx.
And you're point being? I have had 2 Quotes from Webroot Experts and there are still questions so like I said come to the Webroot Community and asks your questions to the experts because WSA's Rollback feature works OK. Rakanisheu Webroot Threat Researcher wrote: There are a number of points in relation to malware using another process to run in this case a web browser. 1) Any file that is downloaded by the browser will be checked in our DB. So if an exploit or a drive-by download is used to download a malicious payload this file will be scanned. If the file is bad it wont even get a chance to execute. 2) There are a number of levels of protection before you even get to the journalling stage it must be said. Web Shield ->Website lookup-> File lookup -> (if executed)Heuristics -> Journalling. I have probably missed out on a step here but thats just off the top of my head. There are still a few other realtime shields in there too (Rootkit Shield, Realtime Shield ,Firewall etc). 3) If this file is unknown and is executed it will journalled even if it uses a known good process to launch (browser,explorer.exe). This is a very common attack vendor for malware using DLL's. You can see these quite easily using something like Process Explorer (use the show lower pane view) 4) Browsers like IE/Chrome/FF are protected by the Web Shield/Identity Shield. I.E processes trying to inject code into the browser sessions or any process trying to access the memory space of the browser. The likes of Zeus banking malware likes to do this type of thing. 5) Journalling works on FAT32 file systems are well as NTFS systems. I am not going to talk too much about our actual tech as I don't want to give the malware authors any help. 6) Using a good process to run malicious code is not something new and has been around for quite a while. Cryptolocker originally didn't really do this but the newer variants do as they realized AV vendors were having a high success rate at detecting them. 7) Powerliks it uses a known exploit to drop to the PC so the first step is to catch the dropper. There are a few variants of it that I have tested. Some of them don't null the startup key and can be easy to remove. In the case of this infection the best bet is to catch the dropper. We did see a spike in these cases but they dropped off after a week. On a pre-infected PC you can use WSA process viewer and look at the behavior of the dllhost which will point to the registry key in question. The Dev team are looking more into WSA+Powerliks as its kinda unique. But its nothing that really worries me to be honest.
Thats exactly the same quote as above (which I mean). And even if you post it every 3 posts now, it doesn't fit. It is not a point of open questions or unclear things, the statement and description of Rakanisheu is clear, BUT you can't use it to show that @quabot is wrong with that: "if you are suggesting that rollback helps with protection, you are wrong. It helps with clean AFTER the malware has been detected, by which time all your info could be in the hands of your Russian friends." Point 2 in your citation gives him right, not you.
Ok any unknown file only runs with limited right's sort of a sandbox the Web Shield, Identity Shield and even the Firewall will block any info trying to communicate out of your system so who ever will not get there grubby hands your info from your system. Thanks, TH