Discussion in 'other security issues & news' started by Zyrtec, Dec 3, 2011.
Figures. The cert system is so fundamentally broken.
ESET has a tool available, ESET users are also urged to read this associated article
Where does the user get this Flash Player installer that launches the malware? The blog doesn't say.
Not from the Adobe site, I would imagine.
I would imagine you're right
The Flash installer is legit. The malware DLL isn't.
OK, I'm evidently not understanding something.
According to the blog,
So, It appears the user has to already be compromised with a malware DLL, for the Flash installer to do its work.
Is this a correct assumption?
Include flash's installer in the payload, inject into it, execute flash? I assume that's all it is.
From the article:
Somehow the malicious dll installs the rootkit by the looks of it? The dll seems to be included with the legitimate Flash installer, as MrBrian alludes to.
So, how does the user get this Flash Installer packaged with a malware DLL?
That is not addressed in the blog, unless I've missed something.
Good question Rich
the rootkit is disguised as the dll, which is named as msimg32.dll that the legitimate Flash installer sees as a legitimate associated dll. The installer won't look in the normal directory for it, wherever that directory normally is, because the installer and the malicious dll are together in the same directory.
I sent a comment to mcafee asking how a user gets this "ZeroAccess package" (legitimate installer + malware DLL) onto the computer in the first place, to then execute the installer.
See this screenshot in the blog, prefaced by this comment:
"Below we see how the ZeroAccess package may look in a designated folder on a test machine."
I hope they will respond.
I would think social engineering.
Maybe you get an infection without admin rights, it downloads the adobe, injects into adobe, and launches/ bypasses UAC?
Would it not be a simple drive by download to the Download directory, the Temp dir in Appdata\Local and C:\Windows\Temp be sufficient. Even a standard user has write (and execute) access to these directories.
This downloaded DLL would be the Egg which will be Hunted by the auto-updater of adobe. The Adobe Flash auto-updater becomes the auto-breeder of the planted egg (the dll containing the malware).
Java updater or Silverlight updater would also be possible auto-breeding candidates (some of them even use task scheduler to elevate quietly to High Rights).
See http://support.microsoft.com/kb/2389418 for an explanation of this intrusion due to lousy programming standards.
Chrome is using its own PDF and Flash versions (which are sandboxed), combine it with for instance Foxit Reader and stay away from popular plug-ins from big companies with lacking programming standards.
I don't think anything is autoupdated; the signed Adobe Installer has to be manually executed. Since the malicious dll the installer sees as a dependency is in the same directory the installer resides in, it gets launched and the following happens:
...so the rootkit injects svchost.exe to get the ball rolling.
It looks like it probably is social engineering as MrBrian states, tricking the user into downloading the Flash installer from somewhere unofficial, which might be zipped with the malicious dll, so that the Flash installer and malicious dll unzip to the same directory.
It seems easy enough to avoid this; just download Flash from the official website to a known directory, preferrably empty, then install it from there.
Anyways, hopefully Rich has his querry answered.
It still comes down to one thing only - uneducated user. From what I understood so far, the malware needs to come packaged with Adobe Flash Player, right?
Security vendors always fail to provide good practices, such as getting Adobe Flash Player from the official website. This would solve it, no?
The method may change a bit... the rest is... FUD... IMHO
m00nbl00d, you've just stated it best
BTW, here's a very detailed analysis on the zeroaccess rootkit with some main points posted:
It essentially comes down to the user, not surprisingly, but unfortunately, as m00nbl00d has correctly stated, these reports always fail to mention this and how easily these malware can be avoided.
Here are a few other attack methods of ZeroAccess in the past year or so, similar to how any malware trojan infects:
Remove ZeroAccess (Removal Guide),
Malicious Ads on Bing Lead to ZeroAccess Trojan
http://184.108.40.206/en_us/blogs/m...t Sidebar Topics&utm_campaign=Malware Attacks
Sponsored Results of Bing and Yahoo are too difficult to remove have rootkit
But this current attack is different: somehow, two files have to get onto the computer and then the trusted one has to execute. If it's a drive by download of some type, well, that's easy enough to block. But if some type of social engineering attack, what has been speculated here so far is as good a guess as any, I suppose!
Right, how the fake dll gets onto the user's machine (although the article states it's packaged together with the installer), is speculation on my part, but there's little doubt as to how the fake dll is launched; it's done so by the legitimate Flash installer, because MSIMG32.DLL is one of its dependencies, so in a normal installation, the Microsoft MSIMG32.DLL, located in %SYSTEM32%\ is launched, but in this case the fake dll is located in the same directory as the Flash installer, so it will get loaded because as stated in the article:
The defined path is, of course, %System32%.
Just out of curiosity sake, I tried PE explorer in the vm to check for that particular dependency of the Flash installer, and sure enough it's there.
I understand that; it's how the "package" gets onto the computer in the first place that remains a mystery.
Sorry for reiterating things, but until my previous post, I couldn't be certain that was how the infection worked until I ran the PE Explorer to check for the MSIMG32.DLL dependency for the Flash installer.
As for how it gets onto one’s computer, I think a couple of the links you posted might explain it.
A user gets duped into downloading the installer through a rogue ad, as some quotes from those articles would indicate.
Maybe the installer, along with the malicious dll, are packaged together as, for example, a .RAR or .ZIP, so when they’re extracted, they both land together in the chosen directory.
The user installing the Flash executable doesn’t clue in or notice the malicious dll, and it’s game over.
If one is to follow the advice from one of those articles:
...then problems is easily avoided.
I just heard back from one of the authors of the blog, and they "suspect a driveby download" because they have found the two files in a Temp directory, and in a Download directory for Firefox.
He doesn't know the specifics of the attack, which I take to mean they haven't discovered a web site so as to take a peek at the code to see what vulnerability is being exploited.
I've copied the legitimate msimg32.dll to both my user's (admin account in vm) Downloads and Appdata\local\Temp directories, and launching the Flash installer from either place results in the dll being invoked from the %system32% directory. The same thing using the syswow64 dll for the 64 bit installer. This is obviously preferred behaviour, so I wonder why it would launch the fake dll discussed in the article, unless that was an older Flash installer vulnerable to invoking the dependency from the unintended directory?
Separate names with a comma.