Webroot Rollback Feature?

I thought I'd register and give my thoughts on this. I am finished work for the day so I don't have access to my data or samples so I`ll post more data tomorrow. This specific infection (Powerliks) is very unique so its a special case. But there are a few things to mention here.

1) It uses a exploit to download its payload. We cant do anything about exploits in programs that's up the dev teams of said programs to fix that issue
2) If its XP it will download Powershell (as its not bundled with XP by default)
3) It downloads a dropper -It does trust me! I'll post the evidence tomorrow
4) The powershell the runs the vbs file
5) This creates the registry key (so it can load on reboot -persistant)
6) On reboot you will see that DLLhost has been injected with a PE file (which causes most of the fun)

WSA can see it no problem (a number of other well known malware programs couldnt)



This gives you the PID and will point you in the direction of the registry Key that needs to be nuked.We can also see the PE file that is injected into the DLLhost too:



Taking a dump of that we can check it out on VT:



Webroot as far as I can see would have no problem journalling if there was no dropper, but you have to get the malicious code to run somehow. A DLL requires a host process to run,so you will have to get a browser exploit that allows a PE file to run in the memory space without saving it locally. I am sure somebody will be along shortly with a sample or example of this that I can test! If so let me know and I`ll throw it at WSA tomorrow.

The identity shield protects the browser if something did try to inject code it would be blocked. Clipboard data in and/out of the browser sessions is watched/monitored. As are keyboard inputs (to stop keyloggers). It's all about layers of protection, no one component is the holy grail. But since the large percentage of malware that arrives on people's PC's comes from Browsers the client really takes a close look at them to make sure they aren't tampered with.

I remember that BIOS malware scam that went around a few months ago that got everybody worried. It was basically saying that there is nothing you can do its done outside the OS and no AV solution would work. I cant find the link now I was from a European website (I'd like to say Dutch)

In the powerliks cases there are few things to remember:

1) You can always block the C&C servers. Once the infections realises that it cant connect it deletes itself (to stop it from being reverse engineered)
2) Powerliks causes such a system slowdown the even the most computer illiterate person notices
3) It relies on an exploit and thus is bypasses the most common method of malware propagation (social engineering)

Now I am not saying that our journalling is 100% or fool-proof nothing except death and taxes are 100%. That said we have some cool things in the pipeline that when they get released I can explain more.I'd also take offence to people saying our detection rates aren't great. If I had a penny for every time we detected some apparent "Zero Day" infection weeks before other Vendors I could have probably retired a while ago.

Remember that all the journalled data about what an infection does means that the Webroot client is in affect a mini-threat researcher. If you do any malware testing (I am new here and do you if you do) you know that getting the behaviours of an potential infection is extremely useful. Seeing what files are moved/created, IP address contacted, registry entries moved/deleted, system changes made all the behaviours you would expect. Take the output from Sandboxie/Total Uninstall/Process Monitor etc its invaluable when looking at a new threat.That's one of extremely useful components of WSA journalling that people sometimes forget.

We always welcome feedback with our product. And if you find something that breaks WSA or something exciting we have missed please drop me a PM or drop us an email.

Roy

 

Thanks Roy for coming by and explaining!

Cheers,

Daniel

 

@Rakanisheu Thanks for joining in and giving detailed information

To insert an image just use More options and then use upload a file option.

 

Welcome Roy! Great to have you here.

Dermot

 

Absolutely correct...whilst a file is being monitored, because it is unknown or its intentions are unclear...then the file can continue to run but in extremely constrained condition/restricted to a small set of actions that are not dangerous...again, what those restrictions are have not been specifically advised because doing so would give malware authors a heads up, etc., in terms of getting around them.

And by the way...the person who suggested that the audience was small and therefore there would be no point discussing in front of it...has really no idea as to how many people frequent the Webroot Community...it is a lot more than they might expect. Always pay to check before pontificating.

 

Nice to see Roy here and very true we don't want to give "malware authors a heads up, etc., in terms of getting around them."

Thanks,

Daniel

 

Roy, thank you very much for taking the time to register and explain and thank you Triple Helix for initiating the communication with Roy.

 

Welcome and thx Roy!

@Triple Helix

Now it becomes some sort of an argument that fits!
But: As far as I read the descriptions Web&Identity Shield only protect browsers, so they fail in some scenarios. I assume that the sandbox-like restrictions belong to all unknown processes?? Than those CAN help.

But nevertheless the core argument stays: Journaling has some nice features and can be very helpflull for rollbacks. But it has not much to do with protection in sence of prevention. For that other mechanismns had to work and had to get better.

 

If you read what I posted any unknown process will not be able to communicate to it's source there are a number of shields that block that and the Main one would be WSA's smart Firewall even when you don't see the settings on Win 8.1 or even the new Win 10 preview WSA`s firewall will stop any unknown malware from calling out. Now you can still do your banking and all even if infected as the ID Shield will protect the Browsers session when you see the little yellow Padlock on the WSA Tray Icon. Also read what Roy posted above.

TH

 

No you can add process to the Identity Shield if you so wish. I dont have the list of native apps that automatically handy at the moment. Any executed process that is unknown in our database will be journalled. If its determined that its bad its changes will be rolled back. This as I said earlier is only one component of our program.

For instance on my PC here, a new version of this application was released recently and its a new .EXE

Monitoring process E:\games\Steam\steamapps\common\War Thunder\aces.exe [B2771208D7A3ABD19ADF7F1A7E797AB7]

The client is keeping an eye on what its doing. If it starts doing things that the client determines is bad (behaviour based) it can locally block it too in which case you may see:

Blocked process from accessing protected data C:\roymalwarevault\webinstallerjd1.exe [Type: 11]

 

@Triple Helix @Baldrick

I had no intention to belittle the WSA community, I am just more comfortable discussing different products in communities with a wider spectrum of coverage, such as Wilders or MalwareTips. I hope you understand.

 

Welcome to Wilders Roy. Nice to see you here.

 

Understood and good to go and it's nice that Roy joined here as he can explain more on the technical side as well emerging malware.

Thanks,

Daniel

 

@ Roy
How about legal processes that are journalled/monitored, some "less" known apps takes forever (months) to become "legit" if you do not allow them yourself?
I have had apps that did not install properly because they were monitored.
As an example I think SlimJet browser is one app that have problems, another one is Universal Media Server to name a few.
Is there anything in the pipes for this kind of problem, as they can be just as problematic as malware if the user are unaware of monitored files.

/E

 

Could you give some more info about the way the "identity shield" works? Does it inject code into monitored apps, and does it try to protect against modification to the browser memory (like IAT/inline hooks)? And what if it's already infected, does it alert you about that?

 

You use the word FUD a lot. There is no Uncertainty in the fact that malware can and does phone home and steal info A LOT. If you still need proof about that, you should not be on this forum. But I think you are just playing ignorant. Rollback does not prevent your information from being stolen... PERIOD!

 

It was never said that's what the feature of the Rollback, it's all of WSA's Shield's that protect your system. http://www.webroot.com/En_US/SecureAnywhere/PC/WSA_PC_Help.htm#C3_Shielding/CH3a_WhatShieldsDo.htm and as Roy posted above:

So why don't you go Troll somewhere else please.

TH

 

Generally speaking an app shouldn't have any issue being monitored unless its gets to the very later stages of monitoring (there are a number of stages)and even then it shouldn't affect the program.

If it does then a simple request to support can fix this, either myself or one of my colleagues can white-list it on the back-end. We can create some rules so even if the app is updated it should stay white listed. I have white listed lots of SlimJet files in our Database which should help.

*EDIT: I have done a ton of whitelisting with Slimjet you should be good to go if you are using it

 

It seems some members don't fully understand how WSA is designed.
Yes, info sent by malware never come back, but WSA developer are aware of it from the beginning and this is where Identity shield comes in.
I suspect monitored program still can sent some info to a (non-blacklisted) server, but at least in theory they can't send vital info.
So if undetected malware can't make actual damage to the system or user data (thanks to rollback) and can't send vital info, then it's almost same as protection in effect.
You have to change your point of view a little bit.
Prevent malware from the very early stage is the best of course, but problem is there's no complete blacklist or 100% proactive protection while whitelisting bothers many novices.
Thus Webroot chooses graylisting. It's not a novel or unique anymore, but Webroot is a pioneer in this field.
Of course there might be a way to circumvent those protection as all product can have hole and this is the topic here, but you first have to understand the vision WSA have as this is different from old-school idea.

 

Unfortunately, you still have no clue on how WSA works otherwise you would not come up with this sort of statements. Why you don't use WSA for sometime to get familiar with it? Then peraphs you can come back with questions. Otherwise don't get surprised if you get near your user name the tag "troll" .. no offense intended.

 

Sorry Rasheed I wont be answering this as I don't give out too much details on the specifics about certain components of WSA. If the client detects an in-memory infection it will let you know via a pop-up. I`ll send you a PM.

 

@ Rakanisheu

I understand what you're saying, but I'm not asking for full details.

The technique that I'm talking about is used by Trusteer Rapport and HitmanPro.Alert, for example. Trusteer blocks modification to IAT/inline hooks and HMPA scans for modifications to these hooks. In order to do so, they both inject code into the browser.

Other apps like SpyShelter and Zemana also claim to protect against banking trojans (SSL-loggers). So I was just wondering which method Webroot is using, that's all. AFAIK there are only a couple of methods to detect this stuff.

 

Thanks Roy, a simple request to support is fine if you understand what is happening on your computer.
The majority of user do not, they only experience things like what I said before and like what I saw yesterday, a costumer installed the new Intel HD Graphics driver, after 40 minutes he stopped the process and called me. (Using WSA Business Endpoint Protection).

When I got there and I saw WSA making a big (290MB and growing) database file in the WRData folder. I killed the install and opened up the Web console and started to whitelist files from the install.
This is a lengthy process for a very well known driver install that should not even been monitored in the first place, right?
My point here is that maybe it is time for a more sophisticated solution when it comes to monitored files? Monitored files needs to be resolved faster then they are today, I know it is a big thing to ask, but it would make a great product that much better in my book anyway.

I do not know what triggers you use for the monitored files before they get elevated to a point were they are considered important enough to be reviewed?
But one of them could be the size of the file/files in WRData folder maybe?

/E

 

As part of our hourly routine we look at a commonly monitored files here in work. The issue is when a monitored file that is unique to that PC or isn't well known so it may not hit our radar. However generally a monitored application performance shouldn't drop. It's worth mentioning that monitoring isn't a on/off switch, there are a number of levels of monitoring from a very low level to a near full on sandbox level.

 

Yes that is a good one to point out many levels monitoring, meaning limited access to the system as well.

Thanks Roy!

Daniel