Not all that funny (continued)...

A few other sources of information have stated that there isn't much that has changed with these binaries. That may not be completely true.

The packer itself has changed. So much, in fact, that AV detection for these binaries is non-existent. Is the "Tibs" packer not being used? What is so different about this one that is causing problems for signature-based solutions?

First off, let's look at the static characteristics of the newest executables: two sections, .text and .rdata are present. Instead of nonsensical lists of outdated, disjointed and unused api calls in its import directory, this one contains four imports from kernel32.dll, like a number of other packers commonly used by legitimate packers.
Here is a screenshot of the import nonsense that packed Storm executables exhibited in the middle of last year, based on an executable used for our Virus Bulletin 2007 presentation:


















And here is the tight listing of imports for this new Storm variant:











Frank Boldewin provided a great paper on the Storm packer/cryptor algorithms used in previous Storm executables' unpacking stubs. He even provides visual aides to demonstrate the runtime flow:
1. First stage xor decrypter (or decoder)
2. Second stage TEA decrypter
3. TIBS unpacker

But not only has this set of unpacking steps changed, the executable payload doesn't include kernel level components anymore. A dll (testdll_f.dll) is unpacked within the downloaded executable's process space, which then drops a copy of the aromis.exe executable to the windows directory, and adds the executable path to the Windows firewall exception list -- something Storm attacks previously evaded with kernel mode injection into services.exe. There is no file mapping based driver infections, this variant simply adds a value to the current user's run registry key. We'll have to look into this one further, it is a stripped back variant as far as autostart sophistication goes.

This code has changed quite a bit from what we would expect from Storm. More details to follow.

Not all that funny

Another holiday, another round of Storm.

This time, the gang is sending around email attachments associated with an April Fool's Day theme.
If you click on a link in an email with an "All Fool's Day" message, you may arrive at a site with an image like this one. DO NOT download and run the file:



























The sites are offering downloads like "funny.exe", "ecard.exe", "foolsday.exe" and "kickme.exe". One of its first chores is to copy itself to "aromis.exe" in the c:\windows directory. Then, it sets a firewall exception rule and attempts to "phone home" on various outgoing ports. This first set of steps is unusual for Storm, but is consistent in the samples we are observing.

Always exercise caution and do not just click on random links sent to your account via email. Exercise even more caution when that random link is attempting to provide an executable to your system!

Common Hijack Habits Are Hard to Break

You just need to find the right point. Breakpoint, that is.

We've had a couple of recent posts that record the use of an injection technique quite commonly used by ITW malware. It has been used for years to evade personal firewalls. New code utilizing the same technique for a variety of solutions (grey, black, or white hat) continues to be posted. Proper prevention for this injection technique has a heightened longevity because of its popularity, and it underscores the usefulness of behavioral based security products. Let's take a look at some of the low level activity of the subject of yesterday's post.

Using a variety of monitoring tools, we can see that the software creates an Internet Explorer process in a suspended state. Eventually, that process is started and sends yahoo messenger spam off of the system and performs a variety of tasks. Let's use one of our favorite debuggers, Ollydbg, to identify the hijacking activity.

The dropper overwrites the entire code section of iexplore.exe process after it starts the browser in a suspended state. We'll throw the first executable, up.exe, into one of our favorite debuggers, Ollydgb. We search its list of imports, set a breakpoint on CreateProcessA and run the executable. These listings show the unusual command-line parameter and provided to CreateProcess:






The stack shows the CREATE_SUSPENDED state of the new process:







The ProcessInfo structure that is passed back out of this call provides handles to both the process ID (PID) and the main thread ID (TID) of the newly created Internet Explorer process. These handles will be re-used later in the routine. For now, the hijacker will call GetThreadContext to copy out all of the values held in the registers of the currently suspended iexplore main thread. They will be used when the thread's execution is resumed:







We see the entire .text section of iexplore mercilessly overwritten and extended with a loop that calls WriteProcessMemory and VirtualProtect on ten separate occasions. It's a lot of work to hijack IE successfully!
In effect, this work completely overwrites Microsoft's code, making Internet Explorer just a shell for the injection code to work within:








Now that the executable code has been tediously copied into IE, the context of the suspended thread is set back to its original environment (actually, a small trick is used and just the context defaults are used) and the newly overwritten thread's execution is resumed:








What looks like a familiar browser process is not a browser at all.

If your security solution doesn't already stop an old habit like this one, you might want to find out why not.

What's in a picture?

Sometimes, nothing that you can look at.
We are analyzing what appears to be a spike in PornClicker activity. The keenly named updater, up.exe, for this software downloads a jpg from smart-browser.com, a "sex browser" software distributor.
Jpeg files normally are a special format of image files commonly used for displaying pictures on the web. But this updater renames the downloaded jpegs to .dll and .exe extensions. They most likely are using the jpg extension on its downloaded executables to evade the simplest firewall and Url filtering schemes.

The delphi-written executable surprises us with a few camouflaging techniques. We are seeing it use multiple plays on Adobe's trademarked name. For example, when up.exe is run and deletes itself, it uses the unusual suspended process/setthreadcontext technique mentioned in a previous post to start and inject Internet Explorer with its own code. Then, the code running within the IE process creates an "Adobe" directory within the user's %Application Data% directory. This zombie Internet Explorer process downloads the udpi2.jpg file served from hxxp://smart- browser.com/ updatex/ udpi2.jpg, and renames the phony image file to rundtl.exe. Their code then creates a run registry key so that the app starts every time the machine is booted:
"HKCU\Software
\Microsoft\Windows\CurrentVersion\Run\AdobeManager"
"C:\Documents and Settings\p\Application Data\Adobe\rundtl.exe" -sys
Hmm. Is it a pdf reader or Adobe's download manager? No.

Instead, once running alongside another downloaded .jpg file renamed to an executable component (mdb.dll), the PornClicker connects to Yahoo!Messenger over http and starts spamming out messages like
"I know it's been a while but check out my webpage and let me know if you wanna talk more"
hxxp://sexmecrazyy .com
It also begins to click on and pull down garbled urls.

Nothing to look at here:






















ThreatFire's name for it is "PuA.SmartBrowser.PornClicker".
Note- It has been updated to Trojan.Injector.

I like apple and blueberry

But happy Pi day -- 3.14

Pi. It's transcendental, irrational, or even savory or sweet.
It's also the number that you magically arrive at when you divide a circle's circumference by its diameter.

My favorite piku example so far is by a nice brainiac here.
And cheers to the story of Akira Haraguchi's 16.5 hour recitation of 100,000 digits of Pi.

How is that today is Einstein's birthday as well?

Aowch

A painfully high number of incidents have been occuring over the past couple of days in India, Thailand and Greece involving a bot/mailer that is installed by a "aow4.tmp", "aowc.tmp", "aow28.tmp"...you get the idea. The bot is downloaded from 66. 29 . 53. 125/supply/pack (a server hosted by a provider in New Jersey) and then injected into a suspended svchost.exe process. This process then spews mail containing nasty Russian slang and attempts to phone home. Most of the servers that it tries to connect with do not accept its mailing at this time.

AV detection is surprisingly low -- there is some generic detection, but the variants continue to morph.

Rootkit components are not delivered with this one, and the downloader utilizes an unusual thread injection technique while deleting its own presence. The tmp file creates a suspended process with the svchost.exe executable, calls GetThreadContext to get the registers of the suspended process, writes its own code to the memory space of the svchost process, and then calls SetThreadContext and ResumeThread on the suspended process to resume execution on its injected code within the remote process. ThreatFire will prompt users about this injection.

Snaps, Crackle, Pops or Get Your Wheatys

Some things about windbg are just great. But often, they come with a little bit of work.
For one, dll load analysis can be performed with ease, even on unusually crafted files. Like the kinds of files you would see from hackers and eventually malware authors. Want to review the entire flow of process creation on a malformed PE? No problem.
You can do it in a snap with windbg. Or rather, you can use windbg to observe and understand how the process loader performs its work, including "loader snaps" (which doesn't get mention in Russinovich's Internals books). Unfortunately, I couldn't get the provided Gflag utility to help enable "Show loader snaps" as Matt Pietrek at wheaty.net informed us way back, when he showed off snappy output from his debugger. But his article is an inspiration to understanding loader internals. It detailed enabling loader snaps using the gflag utility and its results -- "captures detailed information about the loading and unloading of executable images and their supporting library modules....For per-process (image file): Whenever a DLL is loaded, this flag writes the loader contents (and data related to DLL loading) to the program debugger console". This article is a great source of information for trying to analyze these sorts of very unusual binaries.

Windbg can break extremely early in the load process, so we can choose a breakpoint within the dll loaded first into any process, even before kernel32.dll loads -- ntdll!LdrpInitialize. When the debugger breaks, we can set ntdll's ShowSnaps global flag to "1" early enough to see all the modules loading and their corresponding user-mode debug Snap messages:
0:000> dw ShowSnaps L1
7c97c121 0000
0:000> ew ShowSnaps 1
0:000> dw ShowSnaps L1
7c97c121 0001

Now we run our harmless sample and wait for the loader data we are looking for:
0:000> g
LDR: PID: 0xe38 started - 'C:\vx\tiny.exe'
LDR: NEW PROCESS
Image Path: C:\vx\tiny.exe (tiny.exe)
Current Directory: C:\Program Files\Debugging Tools for Windows\
Search Path: C:\vx;C:\WINDOWS\system32;C:\WINDOWS\system;C:\WINDOWS;.;C:\Program Files\Debugging Tools for Windows\winext\arcade;
LDR: LdrLoadDll, loading kernel32.dll from
ModLoad: 7c800000 7c8f5000 C:\WINDOWS\system32\kernel32.dll
LDR: ntdll.dll used by kernel32.dll
LDR: Snapping imports for kernel32.dll from ntdll.dll
LDR: LdrGetProcedureAddress by NAME - BaseProcessInitPostImport
[e38,74c] LDR: Real INIT LIST for process C:\vx\tiny.exe pid 3640 0xe38
[e38,74c] C:\WINDOWS\system32\ntdll.dll init routine 7C913156
[e38,74c] C:\WINDOWS\system32\kernel32.dll init routine 7C80B5AE
[e38,74c] LDR: ntdll.dll loaded - Calling init routine at 7C913156
[e38,74c] LDR: kernel32.dll loaded - Calling init routine at 7C80B5AE
LDR: LdrGetProcedureAddress by NAME - BaseQueryModuleData
LDR: \\66.93.68.6\z used by tiny.exe
LDR: Loading (STATIC, NON_REDIRECTED) \\66.93.68.6\z
ModLoad: 10000000 10000370 \\66.93.68.6\z
LDR: USER32.dll used by z
ModLoad: 7e410000 7e4a0000 C:\WINDOWS\system32\USER32.dll
LDR: GDI32.dll used by USER32.dll
ModLoad: 77f10000 77f57000 C:\WINDOWS\system32\GDI32.dll
LDR: KERNEL32.dll used by GDI32.dll
LDR: Snapping imports for GDI32.dll from KERNEL32.dll
LDR: LdrGetProcedureAddress by NAME - RtlDeleteCriticalSection
LDR: LdrGetProcedureAddress by NAME - RtlLeaveCriticalSection
LDR: LdrGetProcedureAddress by NAME - RtlEnterCriticalSection
LDR: LdrGetProcedureAddress by NAME - RtlSetLastWin32Error
LDR: LdrGetProcedureAddress by NAME - RtlGetLastWin32Error
LDR: ntdll.dll used by GDI32.dll
LDR: Snapping imports for GDI32.dll from ntdll.dll
LDR: USER32.dll used by GDI32.dll
LDR: Snapping imports for GDI32.dll from USER32.dll
LDR: Snapping imports for USER32.dll from GDI32.dll
LDR: KERNEL32.dll used by USER32.dll
LDR: Snapping imports for USER32.dll from KERNEL32.dll
LDR: LdrGetProcedureAddress by NAME - RtlReAllocateHeap
LDR: LdrGetProcedureAddress by NAME - RtlSizeHeap
LDR: LdrGetProcedureAddress by NAME - RtlSetLastWin32Error
LDR: LdrGetProcedureAddress by NAME - RtlGetLastWin32Error
LDR: LdrGetProcedureAddress by NAME - RtlAllocateHeap
LDR: LdrGetProcedureAddress by NAME - RtlFreeHeap
LDR: ntdll.dll used by USER32.dll
LDR: Snapping imports for USER32.dll from ntdll.dll
LDR: Snapping imports for z from USER32.dll
LDR: Snapping imports for tiny.exe from \\66.93.68.6\z

Snap and dll load data of all sorts is provided for further exploration and analysis. We can investigate exactly when and how each dll is loaded from within this malformed PE file with windbg's help.

An exhaustive source of information on the process of dll loading can be found on the Win2k loader here by Russ Osterlund.

Another round of rogueware

Today, we are seeing a surge in the level of ridiculous and badly written delphi malware. It's not a part of the zlob family that we wrote about last week, but there certainly is a fakealert somewhere in there. Can you find it?:

If you haven't heard, and apparently some of our readers haven't, in the course of trying to run videos on your system, you may be prompted to install what is really a phony video codec. One seems to be all the rage today and was at the very end of February, prompting the user to download and run "setup_axplugin.exe".

This setup file may have a cute avi file icon once it is downloaded, as though it is going to install an appropriate piece of software to display that wholesome video you're trying to view:

Setup_axplugin.exe drops and runs "sysockeu.exe" and a handful other files, which copies out "mywallpaper.bmp" and reconfigures your system and desktop to display the bitmap file, along with its bad grammar and mispellings that you saw in the first screenshot above:

"WARNING! YOU'RE IN DANGER! YOUR COMPUTER IN INFECTED WITH SPYWARE!"

In turn, these guys are attempting to convince the user to install and pay for what we have been calling Vundo, another piece of "Rogueware". It's a trojan that doesn't really clean up much of anything. From what we could tell, our clean lab systems that displayed this stuff weren't really putting us in much danger at all.

Readability

And here I was trying to make an effort to make our research readable and entertaining for just about anyone interested in computer security...
























I'll add more pictures.

How do they get my credit card info?

Proper security can only go so far when you use public computers. Keeping your own system up to date is important and exercising caution when using public systems is important as well.

From the L.A. Fbi branch:
"Tandiwidjojo admitted that he hacked into approximately 60 computers inside business kiosks...After hacking into the computers, Tandiwidjojo installed malicious software that allowed him to intercept data, such as credit card information from customers who used the business kiosks. The malicious software transferred the stolen customer data to a website Tandiwidjojo controlled. Tandiwidjojo then used this information to fraudulently make charges to the stolen credit card accounts."

Developing Malware and Rogueware on the Same System

Sometimes people with bad intentions do really dumb things. Is it something to laugh at? Is it something that provokes empathy for the subject?

Well, as we research further into the so-called MonaRonaDona virus, Registry Cleaner 2008, and Unigray Antivirus, we find characteristics common to each executable binary, leading us to believe with a high level of confidence that not only are the binaries from the same group, but they were developed on the same machine.

We performed a forensic investigation of the binaries, and in the Sherlock Holmes style we can say that the author of these masterpieces is a male (possibly Pakistani), who lives in Netherlands and speaks Dutch, in his mid 30-ies, who is a freelance programmer in C++ (MFC/ATL), who is also a soccer fan, wants to study in the U.S. or Pakistan as a Fulbright scholar and likes looking at Maria Ford and Jordon Ladd. Our Mr. X has no permanent job, so he takes the projects from his bosses to build these rogue antivirus solutions and pay his rent. He wants better projects and wants to run his own business. It is his bosses who are the real masterminds behind Unigray Antivirus and MonaRonaDona - not this man himself.

Clues?

Well, the executable was compiled on a Windows box with the Netherlands regional settings using Microsoft Visual Studio 8 and MFC/ATL settings.
MonaRonaDona is likely a word-play with Maradona - M(on)ar(on)adona, whose fans are likely to be in their mid 30-ies and older.
An ELance trace leads us to the web portal where freelance programmers can be hired.
Multiple others litter the files.

It's Elementary, My Dear Watson!

MonaRonaDona Mystery Solved

Brain Krebs at the Washington Post blogged today about a pretty common, unusually mysterious, and very badly named extortion scam, "MonaRonaDona":
"Nobody seems to know how the thing wiggles into infected PCs in the first place, but the one thing that's clear is that this invader's primary purpose is to call as much attention to itself as possible...This piece of malware disables a number of programs on the victim's PC, changes the title of each Internet Explorer Window to include its name, and pops up the warning shown in the adjacent screenshot."

Our talented friend Roel at Kaspersky blogged about symptoms that they've seen as well, without much to add about its origins:
"How the malware actually reaches the system isn't entirely clear at the moment. When first run, the only thing the program does is register itself to start at Windows boot. As symptoms of infection aren't immediately visible, this makes it harder for victims to pinpoint what they were doing when they actually got infected. "

We were analyzing the same threat earlier this morning, when one of our support team was contacted about the problem. Our ThreatExpert and ThreatFire protected community provided the binaries to find some answers.

Some of these users unfortunately were persuaded over the past week or so to run a version of "RegistryCleaner2008.exe" (afec3d0f13b8f866f2c2eec122024165 for you researchers out there), as can be seen here:




















Along with a particular version of "RegistryCleaner2008.exe", came a little friend by the name of "srvspool.exe" and friends. Some of the infection symptoms are somewhat simple and silly compared to other threats we've been researching -- "MonaRonaDona" appears in the Internet Explorer title bar, the "DisableTaskManager" key in the registry is set so users cannot use Ctl+Alt+Del to kill the threat on their system, and "srvspool.exe" appears in the All Users startup folder.

Interestingly, the release coincided with the shortlived appearance of an antivirus suite at www.unigray.com. Notice the "New Spyware Threats" list in the bottom right corner contains #1 new find "MonaRonaDona". At the moment of posting, googling for this dreadfully named virus family turns up no results from any of the credible AV vendors:


















Meanwhile, a mysterious poster "ParadiseForever" claimed that "The computer virus by the name Monaronadona is causing widespread havoc by infecting computers everywhere" and that "The only solution would be to install a good AntiVirus software package which can detect and kill the virus. There are a lot of free AntiVirus softwares available online. However the normal antivirus such as Norton or McAfee may not work for this Virus.
You can try dowloading the Unigray Antivirus which is considered the best for removing the monaronadona virus compared to the other spyware / antivirus programs", which can be seen here:


























And here is an attempt to lend credibility to this overpriced false positive producing Unigray scanner, by putting it in the same list as established and well known AV vendors:




















Note that it has been reported by other researchers that users' search engine results are modified in some way, but we have not witnessed this activity. Instead, the rogueware authors have posted at Digg and other sites in order to appear as top Yahoo and other search engine hits for the search term "MonaRonaDona", with pages that promote the rogueware Unigray AV scanner.
A clean system shows that the top unsponsored result at the yahoo web site takes you to the phony "ParadiseForever" post at hubpages.com:



















More of the scam can be read about on Krebs' post, where he instructs users "If you're a victim of this extortion scam, please don't pay up."

We'll have more details about the binaries and provide updated information as well. In the meantime, we are pleased to report that the source of this Rogueware is quiet at the moment: