Dridex Trojan Gets A Major ‘AtomBombing’ Update

https://threatpost.com/dridex-trojan-gets-a-major-atombombing-update/123972/

This one looks real nasty. Dridex is using its own variant of "atombombing." Plus there is no OS patch available for "atombombing."

 

The applications can't heal the underlying Atoms problem, but they should mitigate it.
AG, MemProtect, ...
I guess a HIPS will mitigate it too.

 

A good read on "AtomBombing" here:http://breakingmalware.com/injection-techniques/atombombing-brand-new-code-injection-for-windows/ . Namely:

Perhaps the HMP-A users can inquire on how it's addressing the issue and reply back.

 

Noteworthy is that security vendors were quick to respond to the original "atombombing" POC in their anti-exploit protection as noted in this Malwarebytes reply: https://forums.malwarebytes.com/top...est-code-injection-technique/#comment-1070121 .

However, this latest version employed by Dridex is a new variant as noted below. So I would say at this point, most people are vulnerable. Thankfully, Dridex is used against banking commercial targets. However, just a matter of time till the new code is reversed engineered and offered in the malware as a service solutions.

Ref.: http://www.articlellc.com/article/dridex-becomes-first-malware-family-to-integrate-atombombing-technique/

​

 

Dridex and other banking Trojans use hVNC from their respective Bots to take control of bank endpoint devices. Good article here describes this: https://securityintelligence.com/anatomy-of-an-hvnc-attack/ . This article is for the Gozi banking Trojan, but the same technique used by Dridex.

 

Ref.: http://www.securityweek.com/new-malware-will-soon-start-atombombing-us-banks​

 

Would be cool if someone could test it, because this is a total new code injection technique. I'm guessing that Comodo and SpyShelter will fail to alert about this, but tools like AG should be able to prevent it by simply blocking access to memory.

Apparently MBAE and HMPA will also alert about it because it's using the ROP technique. Also, the end-goal of code injection is to perform API hooking of the browser, this should normally be caught by HMPA and SpyShelter, at least in theory.

 

Yes, a volunteer is needed to test it
If we protect the (memory-)access to the target process (Atombombing = code injection technique), then all stages should fail:

If not, then the ROP techniques can be detected from MBAE and HMP.A:

 

Someone posted the code at Malwaretips:

Ref.: https://malwaretips.com/threads/update-of-dridex-trojan-gets-an-atombombing.69073/#post-604101
​

It's hijacking a thread in kernel32.dll. Could be any process where kernel32.dll is not totally locked down.

As with any Trojan, it has needs a dropper and it has to be downloaded to the target PC somehow.

-EDIT-

Also this description contradicts the malwaretips posting. He might have found any older ver. of Dridex:

Ref.: http://thehackernews.com/2017/03/dridex-atombombing-malware.html​

 

Per Virustotal:

The following AVs have sigs for this: AVG, Avast, Eset, F-Prot, McAfee, Symantec

The following AVs do not have sigs for this: Bitdefender, Emsisoft, Kaspersky, Spohos, Panda, Microsoft

Interestingly, the AI scanners detected it first. Most impressive was Endgame which found it ........ get this - on 2/22; a week before anyone else!

 

Also noteworthy is that Dridex v4 modified how it is loaded at system startup time. It now exploits the Win .dll loading default mechanism which looks for .dlls first in the directory where the process resides as noted below:

Ref.: https://securityintelligence.com/dridexs-cold-war-enter-atombombing/​

 

As far as the droppers Dridex employs, here's an interesting read: https://blog.fortinet.com/2016/03/23/what-s-cooking-dridex-s-new-and-undiscovered-recipes

Dridex looks for vulnerabilities to exploit. However, it appears to be waiting and able to create its own vulnerabilities:

 

https://www.wilderssecurity.com/thr...earning-engine-featured-in-virustotal.392035/

I had the same thing happen to me a while ago. can't remember the file though. but from my post in link above only two caught the file.

 

I missed a couple of AI detections:

Cloudstrike Falcon - 1/30/2017 - 100% malicious - Wow!
Invincea - 2/3/2017 - Trojan detection but not for Dridex
​

Also, EndGame's detection was with moderate confidence. So could have been ignored as a FP.

In any case, Cloudstike's and Invincea's detections were one month prior to IBM's discovery. This means this bugger was "in the wild" that long.

 

IBM posted two file hashes for Dridex v4:

VT detections are for 4599fca4b67c9c216c6dea42214fd1ce which I assume is for the resident Trojan .dll. Appears no one can detect 1e6c6123af04d972b61cd3cde5e0658e which I assume is the dropper.

 

As far as APT's like Dridex, they have to be stopped in the initial execution phase. For example in a Word doc. delivery, by blocking macro or/and any resultant packed and obfuscated script execution.

Any dropper .exe download after that point will be designed to avoid conventional whitelisting detection such as the use of .Net based exe's as shown in this write up: https://www.cyberbit.net/wp-content/uploads/2016/09/Analysis-of-Dridex-AnD-for-IT.pdf . I was also reading of another Dridex example where multiple .Net based droppers were used.

I am starting to migrate to the approach some people have used and disable .Net altogether.

Unfortunately, we might never really know how this latest Dridex v4 was deployed.

 

However, it gets much less impressive once you find out that Endgame just blindly flags almost every new version of lesser-known Windows applications. To me AI is just a buzzword that gets marketing departments excited - at least within the AV industry.

One example (among thousands, I believe): http://www.arkanixlabs.com/forum/viewtopic.php?id=979

 

I concluded the same when I saw it flagged it as moderately suspicious.

 

Ahh, Endgame! Trying to put on a legit face after all these years. It's actually a neat company composed primarily of Hackers working out of Arlington, VA (hint). The founding member was Mr Fusion (Chris Rouland) who after breaking into the Pentagon was about to go to Jail until he was put to work instead (hint).

The former public face was selling exploits to Government entities. Why would they want these you may ask? Well just say you wanted to take a peek at a computer of a Department of foreign Government. How would you do that? Easy- just fire up Bonesaw (available from Endgame) and you'll get a Map of the World; pick the city that the target is in, go to the physical address, pick out the IP and Viola!- you'll get a listing of the software running on that computer for which custom coded exploits could be purchased (essentially a Google Maps for CyberWarriors- isn't that cute?). Now just find a lonely male employee and a girl that looks good in a skirt and you're good to go!

Although Mr Fusion has moved on (replaced by Nate Fick, a fellow alumnus), we still have on the Board the CEO of In-Q-Tel (google that one) as well as Ken Minihan (google him too). But one would still hope they would reduce to FP's to gain some credibility with their cover product.

 

In regards to my post #13 about Dridex v4 updated persistence mechanism, has anyone wonder why products which employ a HIPS such as Eset and Kaspersky or a solid behavior blocker such as Emsisoft could not detect this activity? They monitor all the system areas mentioned. Appears Dridex high jacked a thread in a system process that is allowed to perform like activities.

In fact it appears the only way to detect this malware by conventional means is from the only trace of itself it leaves on disk; the .dll it uses.

 

Also worth noting is Microsoft's "dissing" here: https://blogs.technet.microsoft.com...atombombing-is-really-unnecessarily-alarmism/ of Tai Liderman's POC of atombombing on Github here: https://github.com/BreakingMalwareResearch/atom-bombing back in Nov. 2016.

So as always if anyone is full of FUD, it is Microsoft.

 

I have this feeling that most HIPS should be able to easily add detection for this code injection method. What's also worth to note, is that browsers like Edge, Chrome and Firefox will soon block code injection into all of their processes. So just like it will become hard to exploit browsers, it will also become hard for banking trojans to manipulate them.

https://blogs.windows.com/msedgedev/2016/08/04/introducing-edgehtml-14/#1wUlFWPyEZ3yV2br.97