Who are u.exe?

Since mid-November, I’ve wiped all remnants of AVG Free 8 from my systems and have been diligently trial-testing a new (to me) AV/AM program.

I’m not yet at the point of dropping a review of Sunbelt Software’s VIPRE, but in a vague and general statement as to my feelings toward it at this stage of usage I will say this: it rocks.

I have it loaded on a XP Home desktop, a XP Home laptop, as well as a Vista laptop.  All come with various degrees of hardware/CPU/memory configurations.  So I hope to be able to provide a good and fair overview when ready.

But for now, let’s meet my specific u.exe friend.

U.exe’ve been snake-bit!

I had set up a staggered schedule of scans on the systems and scan results have indicated either potentially unwanted programs (PUPS) which are my sysadmin tools, or the occasional tracking cookies.

So I was a bit disturbed a number of weeks back when a new occupant on my desktop system’s hard-drive was located by the scanner and reported back as a trojan.

The alert was tagged as a Trojan.SVcHost threat under a “severe” risk level.  The threat-description sounded fairly menacing.

When I was able, I checked out the local scan “risk details” and found that the file named “u.exe” had been located in the C:\Documents and Settings\profile-name\Local Settings\Temp folder.  On Vista systems it shows up in the C:\users\profile-name\AppData\Local\Temp\ folder.

Hmmm. 

File names themselves are no indication of the maliciousness or friendliness of a file.  But the name did sound familiar. 

A quick search on my blog turned up the filename as being one I had run across at work in association with a particularly bad malicious worm package.  Not necessarily a match but the location and name certainly now how my full attention.

A u.exe - Google Search turned up all kinds of horrible indicators.  Looked like this really was a baddie!

Feeling pretty bummed and wondering what extent of compromise may have occurred I set to work.  Because this was my home system, I did pursue the “assessment” a bit more loosely in method and manner than I follow at work.

The detected file had been quarantined (and I was not fully familiar with the scanner features), so I was unable to view the properties information.

Looked like I had to go ahead and restore it.  Dangerous but necessary to do due to a possible short-coming in the VIPRE interface.

First, though, I was offered the chance to send it to the mother-ship labs for additional review (of a false positive).  What to do?  The A/V program said it was a threat. It could be. I had no info to say otherwise. Darn!  Feeling bad but fishing for more info I sent in anyway. 

More on this “feature” and related implications in the post-mortem report at this post’s end.

First Contact

With Spidey-Sense tingling due the loaded weapon now hot and armed on my desktop I started work.

First thing was to fire-up CurrPorts so I could see if it started jabbering away on the net if it executed.

I also had to disable the AV programs “active protection” so it wouldn’t keep alerting/removing the file as I worked with it.

I noted the file date, and then ran a scan with additional Nirsoft tools on all the system’s browsers looking for possible correspondence between the file name/time and surfing habits.  Sure that can be faked, but it was a starting point.  Unfortunately, no corresponding leads were found.

A check on the general file-properties found some more information.  Although it also can be faked, it did provide quite a lot of leads to follow.

• File Version: 2.0.0.0
• Description: PC Decrapifier
• Copyright: Jason York, 2008
• Comments: Free for personal use, other users see http://www.pcderaptifier.com

I went ahead and tossed Strings as well as FileAlyzer at it but though some interesting bits came up, nothing out of the ordinary at first-review.

It has a MD5 of 7eb9d42285d699e0c4b7b1ae9ba7f0f3

I uploaded the file to both jotti and VirusTotal.

The Virus Total report overall came back clean with only eSafe reporting it as a suspicious file and Symantec reporting it as the W32.Harakit.

Curious.

The Jotti report came back clean with only Dr.Web reporting it as the Trojan.Siggen.586 file. 

Hmmm.

Back to those file-property leads then.

Teasing out the PC Decrapifier connection

The PC Decrapifier is an outstanding and beloved freeware utility crafted by Jason York that removes a ton of OEM crapware that comes pre-installed on pre-built Windows systems.  These are the ones you bring home from the store or on-line and once booted, provide an onslaught of unwanted or trial-ware applications.  Most folks leave them on, many of us remove them, but a one-by-one removal process can be a drag. This applications wipe a high percentage of them off the system automatically. How cool is that!  I even host a link-back to this program under my “Claus’s PC Toolbox” sidebar which is something I rarely do for a program, free or paid.

So, finding possible associated links between it and what a number of AV programs report as a trojan was very disturbing.  Was it related or not?

I set a trap.

I downloaded the latest version of PC Decrapifier directly from Jason’s site.  So far so good.  No alerts.

I fired up Process Explorer as well as Process Monitor.  I set a number of filters on Process Monitor related to the malware file as well as PC Decrapifier.  I also started a Snag It video capture of the Process Explorer screen.  Sometimes some processes fire up/close so fast they can’t be screen-captured.

I also removed the u.exe file from the location and monitored the folder.

I executed the downloaded exe file and waited.  I got the wizard and started walking through the steps, right up to the point of applying the removals.

There was the u.exe file popping into the directory.

What have we here?

PC Decrapifier was without a doubt the source of this particular u.exe file.

From the screen capture as monitored by Process Explorer, you can clearly see that the main pc-decrapifier-2.0.0.exe loads a sub-process called pc-decrapifier.exe which then will (very) briefly create the u.exe process.

Process Monitor’s findings were even better.

A fast review of all those 5,615 events showed that, basically, the host file download unpacked the main pcdecrapifier executable which then performs a whole bunch of file/directory/registry checks.  During this process, the u.exe file is created and it then also executes a whole bunch of file/directory/registry checks.

Everything looked on the up-and-up.

By now I had clearly nailed the source of the file, and was reasonably comfortable that the file was legitimate and, in-fact, a false-positive.  I suspected that the false-positive may be caused by the u.exe packing method within the larger PC Decrapifier executable container.  However, I’m not certain if the alert is being caused by the AV due to a signature or heuristics.

Checking in with Jason

Now breathing much more relaxed, I wondered if the developer might be willing to shed some light on why he is using this particular method to execute the program.

I sent off a request for clarification on u.exe and Jason kindly struck up a correspondence.  He has allowed me to quote the gist of his explanation from one of our emails.

The download file uses NSIS (http://nsis.sourceforge.net/Main_Page) which really just unzips the necessary files into the temp folder as you have found.

The u.exe file is a AutoIt script (http://www.autoitscript.com/autoit3/index.shtml) which does use a  UPX packer. With version 2.0, I did convert the main program  completely over to a C++ application, but there were still some custom AutoIT uninstall scripts that I didn't want to rewrite.  So I kept some of them in as a helper application (u.exe)  The C++ application will make numerous calls to this to have it detect if there are applications it can remove.

There you go. Now the whole picture makes perfect sense to me.

Post Mortem

So, in regards specifically to this u.exe file with MD5 of 7eb9d42285d699e0c4b7b1ae9ba7f0f3, the file is harmless (to everything but OEM software crap at least) and is not, in fact malware as best I can determine but an integral part/function of the very awesome The PC Decrapifier utility.

Special appreciation to Jason for being so transparent with his program’s operation and structure.

For a few days, VIPRE had indeed stopped alerting on u.exe and my systems were nice and quiet again.  However the signature/heuristics are once again biting on this particular u.exe file.

I have resent the file to Sunbelt’s team as a false-positive report and also gained some more perspectives on how VIPRE works with quarantined files, as well as have a few kind suggestions for improvement.

First. in my initial encounter with the “trojan” and VIPRE, turns out the file had been created on my system prior to installation of VIPRE.  I hadn’t run The PC Decrapifier application post installation.  Thus it wasn’t found until a “full/deep” system scan kicked off.

When found, the file was alerted on in the (in progress) scan progress page.  Fair enough. However, I had to wait until the entire scan had been completed to get any additional details on the file in particular. Not good.  I would like the ability to get (at least) basic information about file location, properties, etc. mid-scan.

Secondly, once the scan had been completed, I was able to go into the Quarantine area of the program and then click the “Risk Details” button which then only provided me with a summary of the threat facts from Sunbelt as well as the location the file was found in.  I couldn’t get any other information about the file.  To do so I had to restore the file.

Thirdly, once I had wrapped up my “investigation” on my original XP system I ran the PC Decrapifier again on our Vista system.  Since this was a “fresh-run” VIPRE’s “Active Protection” system caught the u.exe “threat” immediately.  And tossed up a notification window.

Ahh!

In the window alert was a link to “show details”.  Clicking that shows a much more detailed report on the file specifics full of great information. (Text-selectable report is shown below underneath the alert window.)

(observation: an MD5 hash in addition to the CRC8 would be nice for cross report checking from other sources.)

versus….

Which would you prefer?

I’d personally like to have access to both reports/details from both locations.

I can’t figure out why this same detail report option isn’t available during the scan on items found mid-scan nor why it isn’t offered (and differs) from the “Risk Details” displayed via the quarantine page. Maybe the file is rendered inaccessible to the “advanced” report detail API once in quarantine?  If so, it would be very nice to be generated/logged during the pre-quarantine process.

While average home-users of the product probably could care less, advanced users and researchers could clearly find value in access to the advanced report details while the file is still in quarantine as well as having it accessible mid-scan instead of only during “Active Protection” hits.

Fourthly, for some reason, I had recalled that when I sent the initial false-positive report in, I had the option to add additional comments to the transmission.  However, when I resent, I found that was not the case.  Having the ability to add comments or details to the virus report transmission might allow the reporter to provide great information to the labs allowing them context and information regarding the discovered threat and why/or why not the submitter feels it is in fact a false-positive alert.

Lastly, I would really, really, really like to see just a bit more feedback, even if automated, from files sent by the user to Sunbelt Software for additional analysis out of the quarantine jail.

At a basic level, just a simple return acknowledgement via email (if requested) would be nice to show the file was received.  Kicking it up a notch, a tracking number for the submission would be nice on a return email confirmation.  By providing that I could at least attempt to tie my updated research on the false-positive findings to an early case-file number to cut down on duplicate work in the Sunbelt Labs. Goodness knows we all have to be more productive now-days in IT.

I’m sure I’m not the only one out here who would gratefully provide more of my investigative work directly to Sunbelt lab analysts as we amateur and semi-pro sleuths have time on the side and tease out more details of a suspect file.  Corresponding via a submission case # would be great if more information panned out, or if the Labs requested more details/information themselves.

Finally, I have no idea if Sunbelt labs provides any direct (private) acknowledgment to a reporter it they do independently prove a file was a false-positive.  Instead I seem to have to re-test and see if the new definitions cause a re-alert or not.  Time-consuming at the least, dangerous at the worst if it was in fact a malicious file after-all.

That could be critical information to the end-user/investigator!

Suppose for instance, that in my case, this u.exe had been a false positive to a critical program or system file.  As a “noobie” or unsophisticated user, I may have reported the file anyway, and then allowed VIPRE settings to either permanently delete the file or delete it after a certain number of days.

I might never know that was in fact a false-positive and thus continue on with a critical file now missing from my system.

If I get feedback, I might be able to restore the file once notified it was a false positive, thereby mitigating the long-term damage from removing the file.

These are not intended to be seen as negative criticisms on VIPRE. And I have no idea if they toyed with these "feature” implementations or not, and if so, why they may have been excluded.  Maybe they are in there as advanced settings and I haven’t RTFM deeply enough yet.

However, if I know Alex Eckelberry, I’m sure he will graciously provide some level of feedback on these questions and observations.

That said, so far I’m very pleased with VIPRE overall and this “investigation" was quite fun.

I hope this helps some panicked or confused folks and clears up any questions regarding this particular u.exe’s association with The PC Decrapifier.

--Cheers!

Claus V.

 

Additional Reading:

Antivirus programs unreliable during critical coverage gap – ARS Technical report

Windows Incident Response: Issues with AV – Wonderfully appropriate post by Windows forensics expert and author Harlan Carvey on AV report technical details and consistency.  You can never have enough info on threats discovered via a AV application.

Off the AVG bandwagan. [sic] - Nicholson Security.

More On Why I Think Free Microsoft AV Will Be Good For Consumers - securosis.com’s analysis on the Microsoft “Morro” project’s impact on the AV industry.  Fast but tight read.