Dridex Trojan Gets A Major ‘AtomBombing’ Update

On Windows 7 with Office 2010 there's also no such reg key.

 

Hum ............... Thought I mentioned previously you have to add it. See the below screen shot:

 

OK, that makes sense.

 

Hi cruelsister! please give us a favour. Can you test to see if Comodo HIPS gives an alert for Dridexv 4, esp a dll injection alert. I am so curious to know but can't test it myself due to obvious reasons.

Thanks

 

Hi! The dll will be dropped, but it will be contained in the sandbox so will not be initiated in any way on the actual system. Pretty much a yawner.

 

Good to know

 

Dridex is sandbox aware. Assuming your sandbox performs activities against recently opened Word documents noted in this article: https://www.proofpoint.com/us/threa...x-evasion-techniques-to-distribute-new-dridex , Dridex will shut itself down.

Alternatively, if you use a security solution with botnet protection, some of which are also noted in the article, Dridex will not run.

However, we are talking about dropper execution here in a Word document. Banking Trojans like Dridex can also be delivered via exploit, etc.:

https://www.scmagazine.com/dridex-re-mastered/article/529794/

https://www.infosecurity-magazine.com/news/cybercriminal-tactics-get/​

Therefore I say you're better protected using a security solution with botnet protection.

 

Just use any SRP, no need complicated sandbox stuff

 

Thanks.

 

I'm relieved I use COMODO's Sandbox (for everything in the disk) and HIPS on Safe Mode.

 

Same here.

 

Then you shouldn't be Infected

 

Here is one of the best detail analysis I have seen for an older Dridex variant: https://reaqta.com/2016/07/dridex-tries-sandbox-evasion/ . Note that this variant does not employ sandbox evasion by terminating the payload execution but actually attempts to bypass the sandbox:

 

I should change my name to disinfected lol...

 

Actually, HIPS do monitor this, but the problem is that advanced malware are using tricky methods that will easily bypass a lot of HIPS. So it's probably best to protect vulnerable processes against memory reading/access. HIPS should also monitor API's inside memory of vulnerable processes (like the browser) against modification, because the goal of code injection is to hijack certain API's.

So security tools most identify the API's that are most targeted. For example, Zemana, SpyShelter and HMPA all monitor API's that are being modified inside browser memory by banking trojans. Some interesting articles:

https://www.codeproject.com/Articles/4610/Three-Ways-to-Inject-Your-Code-into-Another-Proces
http://thehackernews.com/2016/10/code-injection-attack.html
https://www.cert.pl/en/news/single/more-human-than-human-flames-code-injection-techniques/