Stealthy malware uses Gmail drafts to steal data

http://www.welivesecurity.com/2014/10/30/stealthy-malware-uses-gmail-drafts-steal-data/

 

OK, so how to stop this.

1 Block IE from running.
2 Block apps from automatically starting the browser.

 

How do you do either?!

 

By controlling which programs can execute. You can use Software Restriction Policies, Applocker or any Anti-executable.

 

Yes exactly, with anti-exe you can block IE from running at all, of course you will have to switch to another browser. Other HIPS (for example Outpost) also monitor for apps who automatically launch the browser (or other network enabled process), no matter if it's hidden or not.

 

Don't let the malware get into your system.

http://bgr.com/2014/10/29/google-gmail-drafts-malware/

----
rich

 

I'm talking about a scenario where you run a malicious tool by mistake. Not all malware gets installed via exploits, there's always a chance that you run a malicious tool, since AV's can not spot every virus out there, so you need pro-active protection like HIPS/firewall.

A bit OT, but remember this attack?

http://blog.codinghorror.com/a-question-of-programming-ethics/

 

Regrettably, I have to retain IE for dev purposes. Do apps launch the default browser in any case, or do they get a choice? I'm not sure what options I have in HIPS, I'm using Eset 7.

 

OK, but you didn't say that in your post I referenced.


----
rich

 

They can use default browser or run a specific browser and navigate to desired web page.
You can use ESET's HIPS and create rule that will always ask you for permission when Internet explorer is launched.

 

I don't think that was necessary, because it's quite obvious that when you do not run malware, apps can not trigger suspicious behavior. That's why I'm a huge supporter of HIPS, because they can give you a "second opinion". When you run some app, you already trust it in a way (at least partially), but if HIPS notifies you about unusual behavior you can still block it.

 

Like Simplicity said, if you don't want to dump IE, you can perhaps make a rule, so that IE can not be launched automatically.

 

IE remains the biggest piece of lame crap DISASTER MAGNET browser EVER DEVISED OR DISTRIBUTED. And I used it when I got CryptoLocked 2 weeks ago.

 

How you get infected in the first place has nothing to do with modern IE. I don't see the need for all the boycotting.

 

OK, you are preventing/blocking the installed malware from carrying out any action.

I suggested preventing it from installing in the first place. (see Post #6).

-rich

 

Well most of the long time members here on Wilders remember my absolute devotion and thrill when SSM, Malware Defender, and my most favorite of all, EQS was all the rage. You could actually create pinpoint rulesets and build in a short amount of days a proactively impenetratable defensive screen that literally scrutinized all sorts of cross path and entry vectors and set the desired strength = Alert, Deny, allow etc.

Many of those HIPS IIRC failed to move up their programs to x64 bit compatibility and allowed to die on the 32bit vine so AV's integrated their own form of HIPS.

 

Hello Easter,

Yes, I remember your security favorites! I never knew how they worked, but wonder if they could catch this malware today as it does its work -- it is a variant of an earlier data-stealing malware, remote access trojan (RAT) called IcoScript first found by the German security firm G-Data in August.

Note also that this exploit had been hidden from view for two years. This comment from virusbtn.com (article below):

Here is the virusbtn.com analysis of IcoScript. Take a look and see at what point your security would have intervened. Note that IE has to be your default browser for this to work. Otherwise, any HIPS would stop IE from launching.

So, pretend IE is your default browser: Would those programs stop IE from launching behind the scenes?

IcoScript: using webmail to control malware
2014-08-05
https://www.virusbtn.com/virusbulletin/archive/2014/08/vb201408-IcoScript

Now, of course, a person of your wisdom and caution would not have let this RAT intrude in the first place, judging from the suggested targeted attack methods:

IcoScript
http://www.easyremovevirus.com/how-to-remove-icoscript-easy-remove-icoscript-from-pc/

regards,

-rich

 

Yes I know, but I'm saying that it does not make any sense to say "prevent the install in the first place", because not all malware gets installed via exploits, malware can also get on the system via "direct user install". And since AV will never offer a 100% detection rate, you have to think about pro-active ways how to stop certain attacks.

EDIT: I agree with Rmus that it's not likely that a tech savvy user will install a malicious tool by mistake.

Like it already has been said, HIPS with "execution control" would stop this. I do wonder about if HIPS can also stop the "inter-process communication" that's being used by this trojan. If it works by sending "window messages", then HIPS can probably block this too.

 

Seems like you will need a HIPS with "COM object control" to stop this attack. AFAIK, only Comodo offers this at the moment. Or perhaps you can also stop it by protecting the registry? The only problem is, that it's quite hard to know if a COM object is malicious or not, if new ones are added.

https://blog.gdatasoftware.com/blog...ijacking-the-discreet-way-of-persistence.html

 

I believe that Malware Defender can protect against this also. But it's 32 bit only

 

Hello Rasheed!

If the victim's default browser is IE, I wonder if Comodo would protect. Only testing the exploit would determine that. The virusbtn.com analysis from August cited earlier notes that the IcoScript exploit had been installed for two years without being detected by Intrusion detection systems (IDS).

That analysis also has this interesting observation:

An example of malware itself communicating out is the old PDF exploit. A firewall that monitors outgoing communication easily alerts to unauthorized applications (Acrobat Reader in this case) attempting such connection:



The reference to "HTTP communication is performed by the user's iexplore.exe process" suggests to me that this current exploit can be filed in the "Is anything really new" department.

Some years ago, Browser Helper Objects (BHO) were used in malware attacks. Here is what Microsoft has to say about BHO:

http://msdn.microsoft.com/en-us/library/bb250436(v=vs.85).aspx

Here is one such exploit from 7 years ago. It starts with a downloaded malicious file, Ipv6mons.dll, a spoof of the legitimate Ipv6mon.dll. Note that it registers its own CLSID, as the current exploit does (see the virusbtn.com analysis).

http://www.f-secure.com/v-descs/bzub_bs.shtml

I was able to find and test this type of exploit, and I thought it was very clever.

Assuming the infection takes place and the malicious files are downloaded...



...If IE is the default browser, the victim sees the browser crash. Immediately, a hidden instance of IE is launched and the outbound communication is established.

However, if IE is not the default browser, and the victim has a firewall that monitors outbound communication where IE is not an authorized application, the exploit is caught at that moment:



Microsoft soon fixed the BHO vulnerabilities, and BHO is no longer used. The current exploit is certainly much more sophisticated and persistent.

But I wonder if, in the current exploit, the user's default browser is not IE, that a firewall would alert to IE's attempted outbound connection?

By the way, how did the above BHO attack get on to the victim's computer? By means of a fake WinAntivirus Scanner Page that popped up which tricked the user into clicking "Yes" to install the malicious product.

And how does the recent exploit make its way on to the victim's computer? As suggested in a previous post:

regards,

-rich

 

Very interesting and educational.
Thanks Simplicity, Rasheed and Rmus!

 

http://www.theregister.co.uk/2014/1...drafts_as_dead_drops_to_control_malware_bots/

 

Yes correct, I see it has an "Access to COM object" feature. But if I'm correct, COM objects are stored in the registry, so a registry monitor must also be able to stop COM objects from being modified?

 

That's the thing, even if you're an expert user, you can not know if a newly registered COM object is used maliciously or not. So it does not make a lot of sense to monitor that. However, this new attack, tries to replace known Windows COM objects, and that can be stopped with the "Protected COM Interfaces" feature in Comodo, but probably also with a registry monitor.

http://help.comodo.com/topic-72-1-451-4766-.html