Dridex Trojan Gets A Major ‘AtomBombing’ Update

Well, the point is that most HIPS will currently fail to alert about it, and HIPS is already implemented in all popular AV's. Not to forget it's also big in corporate environments.

 

Thought I explained this in reply #23. This malware obviously hijacked a system process thread; a process that would not normally be monitored by a HIPS e.g. svchost.exe. Ditto for the ROP manipulation since anti-exploit software such as EMET doesn't by default monitor system processes nor is it recommended to do so. Additionally, Dridex v4 modified previously known methods of atombombing as noted in reply #11 thereby bypassing existing anti-exploit methods that were employed to detect the old method.

Bottom line - malware developers are always one step ahead of the game. That is find a Windows vulnerability and exploit it. Since there is no way to patch any version of Windows against atombombing, I expect to see much more of it utilized in upcoming malware. Especially since this Dridex ver. was roaming in the wild for a month undetected except by CloudStrike and Invincea.

 

Here's a detailed analysis on the loader employed in an older Dridex ver.: https://www.malwaretech.com/2017/02/lets-unpack-dridex-loader.html

In this instance, Word macro runs which fires off a Powershell script and we're off and running. This variant does a process hollowing routine against as I previously suspected, two system processes; either svchost.exe or spoolsv.exe. What makes Dridex in my book unique is its ability to escalate privileges to whatever level it requires.

Warning: the "here" link in this article is a .zip download of the actual malware.

 

you cant post malware links on Wilders.

Once you use Appguard, you never go back

 

Testers may have a bit of difficulty running Dridex 4. It has a fairly heavy anti-VM mechanism in place, so at the first whiff of anything amiss the payload (qqwed.exe in Local/Temp) shuts down and self-deletes. Dridex 3 normally had only the Document check (via Office RecentFiles); ver 4 is more complex and really has to be run on a sacrificial machine to see it in its full glory.

But in spite of all the terror you read, it's really a case of Brand New Same Old Thing- Block the initial payload (like guest's AppGuard will do, as well as a certain Firewall dear to my Heart) and all is well.

 

You meant Lizard FW ?

to seriously test malwares , a dedicated non-networked machine is needed.

 

It really depends- I will admit that one must be aware of any anti-VM functionality and of which type for apparent "duds" (what I hate is the delay to malware drop that has become popular recently), a majority of malware will run quite happily in a VM that is set properly (things like giving enough resources, having a bunch of Documents that have been opened recently, etc).

And stuff like ransomware and worms could care less where they are run because there is always the possibility that an IDIOT HAS FORGOTTEN TO TAKE OUT THE DAMNED USB DRIVE (not mentioning any names) and thus has trashed an entire malware zoo!

 

This atombombing release of Dridex is not the same one you are referring to. The one you noted is the prior UAC bypass one of Dridex detailed here: https://www.flashpoint-intel.com/blog-dridex-banking-trojan-returns/

I did find a site that did have a copy of the current one IBM discovered. I didn't save the link and now having trouble relocating the site. If I find it again I will post it.

-EDIT- You can get the sample IBM detected here: https://otx.alienvault.com/browse/pulses/?q=tag:DRIDEX&sort=-modified

 

lol

I tried a cerber in shadow mode and sure enough it took out the rest of my malware samples. they weren't on a usb drive though they were just in a folder. even if I would have had them on a usb drive, shadow defender would have put them also back on reboot.
and so my next question is, would the new dridex version detect it is running in shadow defender?

Also me thinks if you run this or any other malware on a live machine disconnected from the net, and if you have an image that restores even the mbr, you should be good to go.

I was testing an av and as you can guess didn't do so well.

ps testmyav has a pretty good batch of malware samples that it updates daily.

 

In regards to the UAC bypass ver. of Dridex noted in the reply #34 Flashpoint article, qqwed.exe is actually downloaded to C:\Documents and Settings\Administrator\Desktop\10309e26...... as COMUID.dll. Also at no time does Dridex directly execute anything from the User/Temp directory but only indirectly through a highjacked system process.

Tip: If you monitor the creation of .exe files in the User/Temp directory and just not the execution of processes from same, you could stop this Dridex variant. However, do note that Dridex could store its .exe anywhere it wanted.

 

The newest variant has moved from qqwed to pacae. The payload must activate prior to the registering of the dll. Once again it is even sniffs virtualization it shuts down.

 

Dridex v4 is executing the payload directly from memory as noted previously:

 

Seems it even detect Rollback RX and stay inactive.

 

Dridex v4 payload code is packed and obfuscated as would be for any malware of this caliber. This means that it decrypts once it is loaded into memory. This also means that the AV solution employed must have advanced memory scanning capability to be able to detect it by signature once the decryption is completed.

 

Also the IBM sample was for Win 7 x64 and is the Korean keyboard driver stub which I found interesting. Note the product name; a comment on what it thinks about Windows perhaps?

Per Virustotal:

 

Refs: https://kengilmour.com/?q=aggregator/sources/78

Notes:

1. https://securityintelligence.com/anatomy-of-an-hvnc-attack/

2. https://securityintelligence.com/dr...in-uk-intensifies-focus-on-business-accounts/

 

Good news for Windows 10 Creators Update users regarding atom bombing and more:

Source: https://twitter.com/dwizzzleMSFT/status/838520323083423745

 

I "wouldn't hold my breath on the MS fix." They haven't fixed the ROP bypass of DEP that started the whole process.

 

Might be time MS reread this article: https://www.theregister.co.uk/2016/...t_even_win_7_emet_is_better_than_solo_win_10/

 

Found a good write up on atom tables below and also why they won't be "going way." The last paragraph appears to give remediation to the issue but do not believe MS will do based on their latest tweet. See my next reply on that.

Ref.: http://stackoverflow.com/questions/40553686/so-just-what-are-windows-atom-tables-for
​

 

Gibson Research has an article on why conventional ROP bypass detection would not detect this recent Dridex v4 attack. Appears this is where MS appears to be concentrating based on their latest tweet:

Ref.: https://www.grc.com/sn/sn-585-notes.pdf​

 

I hope so ...

 

i won't believe it much. They want you to shift so in a business perspective, it would be logical not to port it.