Dridex Trojan Gets A Major ‘AtomBombing’ Update

Most incomes of MS comes from corporate customers (same for security softwares) , those customers have the best protection because they pay high, just look at Win10 Enterprise.
MS is a business , not charity...(unfortunately ^^)

 

For our Cylance aficionado, @boredog, appears that Dridex v4 with its modification of atom table calling was able to bypass Cylance's detection of atombombing noted here: https://www.cylance.com/cylanceprotect-vs-atombombing-exploit since I see no propaganda spewing of detection of Dridex v4 on the Cylance blog.

 

itman

Thanks for the link. on that page Cylance is saying it was able to stop the bugger.

 

The link I posted was for the "theoretical" atom bombing bypass posted last Oct..

 

ah ok

 

In regards to how MS will attempt to block malicious atombombing use is noted below. This protection will be available in the Win 10 Creators update using Windows Defender ATP which means only paid subscription versions of Win 10.

Appears WD ATP will be monitoring use of QueueUserAPC which was used in this Dridex v4 attack to call the atom table injection commands. I assume by now most third party security products have updated their anti-exploit protections to do the same. Whether this will stop future atombombing attacks is debatable since QueueUserAPC is only one method to employ atom table updating.

Ref.: https://www.wilderssecurity.com/thr...s-injection-with-windows-defender-atp.392583/

​

 

I'm not sure what you mean. It's just another code injection method, so a HIPS should monitor the used API calls, as described in the IBM article. But I'm not sure if recognizing such an attack is as easy as monitoring API calls.

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

 

As noted above:

I don't believe that HIPS's consider "creation of a new thread" process memory modification activity since it is something done normally by every process. Nor up to this time did exploit detection directly monitor APIs SetThreadContext and QueueUserAPC in regards to atom table access. Remember in this attack the memory injection did not occur in previously allocated process memory space. Dridex used previously unused memory to load its payload and "linked" to that memory space via atom table usage to execute the payload.

Note that there are thousands of Win APIs. HIPS's only monitor a limited subset of those.

 

The point most interesting to me about this recent Dridex v4 attack is that I would expect to see "Next Gen" machine learning solutions flocking to it as proof their respective product could detect misuse of atom tables. That is not happening. Indicates to me that atom table misuse is extremely difficult to reliably detect.

 

Here's a good reference for detecting atom table malware: https://books.google.com/books?id=U...epage&q=malware that uses atom tables&f=false . Note that the book was published in 2014.

Sections to pay attention to are:

• Detecting window class names
• Detecting windows message names
• Identify injected DLLs
• System presence marking

 

Just use SRP softs , Dridex is not big deal.

 

I came across a 2012 paper on atom tables vulnerabilities, exploits, and mitigations: http://mista.nu/research/smashing_the_atom.pdf .

First, this paper was directed toward developers. What caught my eye was the Win 8 section on the use of AppContainer as an effective mitigation against atom table exploiting. So I fired up my Word 2010 app only to see it is running as a non-AppContainer process on Win 10.

Seems to me that the first thing Microsoft needs to do is to correct deficiencies in their own apps starting with updating Word to run in AppContainer. Hum ........ let me guess. If I spend more $$$ and upgrade my ver. of Word, the newer vers. run in AppContainer?

 

I guess at least Word 2013 is needed:

 

I just ran a test with Word 2010. Send myself a .docx file and opened it in Thunderbird. By default, it will open in protected mode. Word spawns a second process running in Low integrity but not in AppContainer. So it does have the correct token set but w/o AppContainer sandboxing.

In any case, I am a bit mystified as to how Dridex v4 could evade Word's AppContainer protection in these recent attacks. I assume the banks involved were using a version of Word later than 2010. The IBM malware sample indicated it was running on a Win 7 box. So the question that needs to be determined is if a Dridex v4 Word post 2010 based attack would succeed on Win 8.1+ OS? Also, if opening a .doc/x file outside of protected mode removes the AppContainer protection? -EDIT- Based on what I read in the TechNet article, I believe this might be the case.

 

at the moment only Metro Apps (and tweaked chrome) "really" runs in Appcontainer.

full flegde Appcontainer is only on Win8/10 , on previous OSes it is only "experiments" , Protected Mode is like the "precursor/prototype/basis" of Appcontainer.

 

Actually, I have Office Pro 2014 installed. So the MS Word ver. is 2014. However, I forgot my Office Pro ver. is 32 bit, so it won't open in AppContainer on a Win 10 x64. That alone is an issue.

I need someone with Word 2013+ x64 to perform the following test. Create a document with an imbedded script in it i.e. .bat, etc.. You can do this by:

Insert -> Object -> Create From File -> Display As Icon ->
​

Email yourself the .docx file as an attachment. Fire up Process Explorer/Hacker. Using an e-mail client preferably, open the attachment. Word will open with the document displayed. Exit Word protected mode by selecting the "Editing" option. At this point, verify the mode the spawned Word process is running in. I believe it is no longer in AppContainer mode but running at Medium Integrity mode; if so this is an issue. Execute the script in the document by double clicking on the icon. You should receive a prompt popup about invalid publisher, etc.. Double click on the "Run" button in the prompt. Observe in Process Explorer/Hacker using a .bat script for example that both command.com and conhost.exe opened in a non-AppContainer instance.

My contention is this. A lot of Word based malware could be contained if Word was modified to force any script execution from a document to run in an AppContainer instance.

​

 

I agree entirely. I would love to see Microsoft Office and many more programs run within AppContainer sandboxed processes. Speaking of which, it's great to see Adobe Reader having an option now for running the content process within AppContainer as well.

I believe that there is a strengthened, lower privileged AppContainer specification coming out with Creators Update but unfortunately there are no official details as of yet.

 

You all know MS work, they never fully introduce a feature at once , they spread it bit by bit on every updgrade/versions. smartscreen started on Win7 and finally arrived on win8...so i guess it will be the same with Appcontainer.

 

In reality, this would have to be application based.

Most scripts will not run properly in AppContainer due to privilege restrictions. Any script contained within an e-mailed Word document has "The Mark of the Web" in it. So an option could be provided in Word to always run such scripts in AppContainer. On the other hand, a script inserted in a Word document created locally does not have "The Mark of the Web" and therefore would be allowed to execute outside of AppContainer. Note that this solution is not foolproof since there are ways to strip the "The Mark of the Web" but better than anything that currently exists.

-EDIT- Or alternatively and far simpler, just add an option to Word that would automatically block any script which has "The Mark of the Web" execution.

Additionally, this feature should be included in all Word versions currently supported by Microsoft.

 

OK. I found a way to block all script execution from a Word document. Obviously this is the "nuclear" option. Appears either corps feel this is too extreme or in my opinion, they just don't know that it exists In any case, this will not only stop Dridex but ransomware as well.

I have copied below, the Microsoft recommendation noted above. Recommend anyone that does not need to employ scripts in Word implement it. I say this because even through you will receive a prompt as shown below on any unsigned script, it is just to damn easy these days to steal a code signing cert.. Additionally, the OLE target does not need to be a script but could be anything executable.

 

Goof find
Set it to one seems to be the wiser choice.

 

No. A value of "1" is the default and OLE content will be allow to run after warning prompt. A value of "2" totally disables all OLE content from running.

See my following posting.

 

I believe I have found the "smoking gun" in these Word based attacks.

Up to this time, I like many others assumed that U.K. bank employees were "asleep at their keyboards" when reading Word based e-mail and subsequently ignoring any OLE content based prompts as shown in reply #71. Or, they were duped into ignoring them by spear phishing methods described in the Blue Coat article. Appears that always might not be the case.

In the Microsoft solution recommendation given in reply #71 to disable all OLE content, there is a link reference to details on registry modification. That is for adding the value key of PackagerPrompt and setting that to a value of "2" to disable all OLE content in any Word document. From that link reference is the following:

By default, PackagerPrompt is internally set to a value of "1" for post Office 2007 versions. The MS article is for Office 2007 which noted the default value was "0." If you go into the registry, you will see that the value doesn't exist. Note what I underlined above. When I checked my default Trusted Locations in Word, the one that stood out was: %APPDATA%\Microsoft\Word\Startup. Bottom line - all malware had to do is load its OLE content into this directory and it will run totally hidden, no OLE content prompt displayed, at Word startup time with default Word settings .

Unbelievable, Microsoft

 

happy clickers?

​

cannot find it on win10 with Office 2016. maybe i missed it.