Discussion in 'malware problems & news' started by Minimalist, May 1, 2015.
Looking at the IBM report [PDF], it's evident that with proper security in place, this trojan would never get onto disk in the first place:
More hyperbolic statements, looks like another plain old hiding from sandbox analysis trick to me (that HMP.A takes advantage of).
dyre cant escape out of the sandbox ,instead it uses sandbox aware tech to avoid detection/analysis in the sandbox enviroment thats all.
This is why running with just Sandboxie alone is to me a bad idea. I may have what some would describe as a paranoia set up, it unless I absolutely wanted to let this by it wouldn't make it.
From the article:
I think this article focusing on sandboxes that helps AVs/AMs to detect trojans/viruses , and not on how this trojan break sandboxes and excute on the real system , also this trojan seems to be not working at all while in AV/AM sandboxes ..
Really I don't get the link between this article and its headline !
Finally , I think I remember reading something about this trick in the past "checking the number of cores to DETECT if it is running under sandbox or not" ,
Yes, headline is not in line with article. If you hoover over tab you get other description: "Dyre Banking Trojan Avoids Sandbox Detection", which is IMO more accurate.
Mods can change thread title to make it more accurate.
I agree, it should always be combined with a behavior blocker, because only a BB/HIPS will notify you of suspicious behavior, no matter if malware is running inside or outside the sandbox. On the other hand, from what I've read, most banking trojans aren't even able to run or work correctly inside the sandbox, because of the limited rights inside the virtual container.
New Dyre variant in the wild supports Windows 10 and Microsoft Edge
What does any of this mean ? Does it mean if you are using the registered sandboxie the process will not show up , and allowed to run ?
It says " it jumps out of the sandox "
It's all very vague, no names mentioned.
All this aside, I don't use Sandboxie when doing banking, I use Trusteer Rapport, which apparently will protect against this and other banking trojans https://securityintelligence.com/dyre-banking-trojan-used-in-apt-style-attacks-against-enterprises/
It only means that malware is aware of some sandboxes and won't execute or will change it's behavior if one is detected. This way solutions that use this sandboxes will have more problems detecting malware while using their sandbox to analyze it.
You're question has already been answered in this thread, it can't bypass a sandbox like Sandboxie.
EDIT: I just saw Minimalist's post.
Trusteer Rapport assuming you can live with the performance impact and privacy issues is only at maximum effectiveness if your bank has its corresponding software installed on their servers. In that case, a secure tunnel is established between your PC and the bank server. If the software is not installed on the bank server, Rapport's protection is on par with most of the AV's online banking protection.
Sandboxie isn't going to protect you against a MITM or even a MITB attack.
".......VXers have cooked up Windows 10 and Edge support for the nasty Dyre or Dyreza banking trojan.
The banking bomb has ripped untold fortunes from victims and passed them into the hands of its authors. In at least one instance alone IBM says more than one million dollars was plundered from an organisation.
At present it has infected some 80,000 machines with that number expected to rise. It can also target Mozilla Firefox, Google Chrome, and of course Internet Explorer.........."
I just read that MS Edge will automatically block DLL injection, except for signed modules. But I'm guessing that won't stop banking trojans.
Dyre will inject a .dll into the browser. However, by that time you are infected. What starts off the whole processes is a .dll injection into svchost.exe. So that is the process you want to protect against .dll injection.
Best way to stop Dyre is to prevent it's malicious service creation in this registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\*. Note from the below link I posted how it creates its service as a GoogleUpdate service.
Good technical analysis of Dyre here: http://www.symantec.com/content/en/...response/whitepapers/dyre-emerging-threat.pdf
But I wonder if I understood it correctly, because I didn't even know that it was possible to protect your own process against DLL injection? If it's true then Edge will become immune to a lot of banking trojans, since most if not all use code injection to hijack the browser. I suppose "Module Code Integrity" is a new feature in Win 10? They could easily add this feature to other essential Windows processes.
I wouldn't hold by breath on this ever happening for all Windows processes. It is something that should have been part of Windows OSes from the start. Something that was always part of Unix.
they upgraded the rendering engine that powers the browser to “EdgeHTML 13,” something that brings kernel-level protection against code injection. Going forward, the mechanism should block DLL injections on the browser, unless they’re components signed by Microsoft, or Windows Hardware Quality Lab (WHQL) Cowan claims.
By enforcing code integrity within the kernel, as opposed to in the process, the company claims it will make it so ad injectors can’t turn off the integrity check, something a hacker could disable otherwise.
You can read about mshtml.dll which is the rendering engine IE uses here: https://msdn.microsoft.com/en-us/library/bb508515(v=vs.85).aspx .
Also would not be surprised if a bypass for EdgeHTML doesn't appear in the near future since it is .dll based. From what I can glean from literature on Module Code Integrity, Edge uses WIN 10 to copy the process startup .dlls to the kernel for protection. I haven't seen anything to date that would prevent memory based .dll injection into Edge. -EDIT- If this .dll was signed, I assume it would also be copied to the kernel w/o issue. Remember our "zombie" process discussion. Startup a suspended browser instance, memory inject our signed malicious .dll, and then start the modified browser instance.
Finally, there is the issue what impact MCI will have on existing security software that presently inserts its own hooks into the browser.
I think there is a big thing that is being missed here. The article gave it away. Emails with attachments. Leads to a couple of things.
1. Change the dumb default that blocks extensions. I see many files in email zip files, that are exe's of some form but with a word icon. So they look like a word doc until you see the extension
2. Educate employees about what the extensions are and how to detect these obviously fake emails and attachments.
3. Create a work environment where employees are encouraged to challenge a suspicious email from the boss rather then being afraid to do so.
Yes in theory it does sound good, but nothing is fool proof, I would always still rely on HIPS, to block code injection. I hope they will publicize more info about this new feature, and I can't imagine that only Edge will implement this feature, this is something that all browsers could use.
What can stop this Trojan. Name a few security software, please!
This malware is delivered via e-mail, so start there. Install an e-mail client of your choice. Most will disable all active content by default but double check that setting. Also make sure e-mail attachments are not opened by default. I only allow e-mail to be displayed in text mode.
Next install a security product that will scan all incoming e-mail. Assuming you will receive all incoming e-mail encrypted from your ISP provider, that presents an issue. Your security solution has to have the ability to scan encrypted e-mail. The only way it can do that is by installing its own root cert. to do so. Presently products that can scan encrypted communications are Eset, Kapersky, Avast, and BitDefender. Note that depending on the product selected, you might have to manually activate SSL protocol scanning. Just make sure the product selected supports the e-mail client you use. Many do not support the Thunderbird e-mail client. Eset does but you may have to manually import Eset's root CA cert. into the corresponding root CA in Thunderbird.
Finally, never ever open any type of compressed format e-mail attachment useless you fully trust the origin of the e-mail.
Nice read and explaining about this Trojan! Also thank you for the details!
And if this trojan does manage to run, a tool like HMPA should at least warn you about it. Zemana, SpyShelter are also designed to interfere with it. And don't forget about AV's of course.
Separate names with a comma.