Infection with tenga.a virus

[Multibooter]

I don't know how much extra hardware you have.

Hi herbalist,

This Tenga infection has hit me just at the wrong time: I am travelling in Europe, away from my desktop in the US, until about June. I don't have all my resources, they are back in the US. What I miss most is my fast dual-core desktop. Using a 10-year-old 700-Mhz laptop for virus-scanning, burning DVDs, raring up stuff, creating and restoring backups is really slow.

On the positive side, my computer stuff back in the US is most likely not Tenga-infected (yet).

[Multibooter]

tracking down how you're getting infected is the key, but I'm not sure what I'd do in your situation.

Before doing anything else I have backed up most of the infected HDD into .rar files, in contrast to my 1st Tenga infection. I have also backed up the infected E: partition, which contained the infected Win98, as a .gho image. Maybe these snapshots of the infected HDD help me later identify how the 2nd infection started.

In my posting #24 I quoted Panda "Tenga.A shows a very a complex infection routine" http://www.pandasecurity.com/homeusers/security-info/about-malware/encyclopedia/overview.aspx?idvirus=82383&sind=0&sitepanda=particulares Usually things look quite simple once you fully understand them.

This 2nd infection with Tenga.a is different from the 1st infection: .exe files in \Windows\ and \Program Files\ of the infected Win98 WERE infected, in contrast to the 1st infection. Also, the FAT32-based WinXP and the NTFS-based WinXP were not infected, maybe because I was fast enough to detect an ongoing re-infection. All .exe files in the test-Win98, which I had not used for a while, were infected, as during my 1st infection.

There is a slight possibility that I may have triggered the 2nd Tenga-infection inadvertently myself, when I was dragging Tenga-infected .exes to separate folders, maybe I double-clicked on one instead of selecting it.

On the internal HDD there was no file "C:\DL.exe" after the 2nd infection with Tenga, in contrast to the 1st infection.

Edited March 28, 2010 by Multibooter

[Multibooter]

given that your AV isn't detecting the malicious process, I don't see you defeating it until you work from an environment in which the infection process can't run.

Hi herbalist,

I guess I was lucky. I am making this posting now from the formerly Tenga-infected laptop, after having restored my system from a backup of 25-Jan-2010.

I most likely have identified the cause of the system-wide infection with Tenga, without using a default-deny tool. When I re-checked the system restored from the backup of 25-Jan-2010, Kaspersky detected 2 infected files on it:

- H:\MSOffice\Office\Binder.exe, infected with Tenga.a, modification date 21-Jul-2009 8:43AM

- H:\MSOffice\Office\Findfast.exe, infected with "new threat type_Win32 (modification)", Kaspersky didn't have a name for it, modification date also 21-Jul-2009 8:43AM

No other .exe file besides Binder.exe was infected with Tenga.a in the backup of 25-Jan-2010.

So the original infection with Tenga started on 21-Jul-2009, not on 28-Feb-2010, with the infection of 2 files of MS Office 2000, installed under Win98. Tenga apparently was just sleeping for a while because I had previously de-activated Findfast.exe from startup, I don't like unneeded startup processes.

Restoring from an already infected backup is not a smart thing to do.

The blazing speed with which Tenga can infect .exe files is probably explained by its use of Microsoft's Findfast.exe

I have restored clean versions of Binder.exe and Findfast.exe from an uninfected backup of 5-Jun-2009. To reduce the risk of re-infection with Tenga (I have on my 1TB USB HDD still 10.000+ Tenga-infected .exe files to be dealt with), I have disabled the clean Binder.exe and Findfast.exe by renaming them. MS Office/Word 2000 seem to run fine without Binder.exe and Fastfind.exe.

What does puzzle me is that after the 2nd infection with Tenga the file binder.exe, already Tenga-infected on 21-Jul-2009, had a changed modification date of 27-Mar-2010; Tenga supposedly doesn't modify already Tenga-infected files, that's what the "V" marker (=virus) in byte 51 is for. Maybe the virus writer allowed this exception, to make the search for the source of the infection more difficult. After the 2nd infection with Tenga, binder.exe has a later modification date (27-Mar-2010 11:18) than the first newly-infected .exe file BC2.exe (27-Mar-2010 11:13).

It looks like the infection with tenga.a on my system has been solved. I will eventually post here what I have done to improve the security of my system.

Edited March 29, 2010 by Multibooter

[Multibooter]

I guess I was lucky... I most likely have identified the cause of the system-wide infection with Tenga

No, I wasn't lucky and I probably didn't identify the cause. Ten minutes after I posted the previous posting (5 days ago), Tenga was back. This was my 3rd infection with Tenga.

Since then I have restored the HDD from a .gho forensic backup, and taken all safety precautions I could think of. Tenga hasn't come back since. I cannot exclude the possibility that the 3rd infection was caused by a handling error while I had the 2 HDDs with still-Tenga-infected stuff connected to my laptop. It's still an unresolved puzzle how binder.exe and findfast.exe were infected in July 2009, and why Tenga was sleeping for half a year. The clean findfast.exe cannot have contributed to this infection #3 because I had it renamed on the restored .gho image, just in case.

But I think that the most likely cause of the 3rd infection was unidentified malware on the supposedly clean .gho backup. I have the feeling that there is an invisible tank somewhere doing target practice at my laptop, with Tenga being the shell.

I have installed a 2nd virus checker, Avast, on another operating system, but no major findings, probably all false positives. When I searched the Internet for experiences with Tenga, I didn't find any useful recipe for recovering from a Tenga infection, except for formating the HDD and re-installing everything from original installation CDs. I assume the anti-virus people don't know yet how the infection really starts, because people having a Tenga infection reformat their HDDs, thereby wiping its origin.

I am not posting all the measures I have taken, it would take just too long, I have probably been just barking up the wrong tree in most cases. I am only posting measures where I have open questions.

Question 1: Does nusb install a more vulnerable version of explorer.exe?

The software and setup of my dedicated eMule computer is very similar to that of my main laptop; both laptops are identical models, Inspiron 7500. The dedicated eMule computer, however, contains an earlier version of the stuff on my main laptop and uses manufacturer-provided USB drivers, while my main laptop contains nusb v3.3.

I had installed nusb3e on my main laptop on 20-Jun-2010. The unnoticed infection of binder.exe and findfast.exe on my main laptop occurred on 21-Jul-2010. Again, binder.exe and findfast.exe on my non-nusb laptop were not infected. BTW the dedicated eMule laptop is used only very rarely for browsing the Internet, it is used nearly exclusively for eMule, as a print server and for transferring downloaded files in a peer-to-peer network. The reason for using a dedicated computer for eMule is to obtain a long uptime (e.g. 7+ days under full load), without system hangs caused by other applications. Given that the dedicated eMule computer was not Tenga-infected, I would exclude the possibility that the Tenga-infection is related to a vulnerability of the eMule software.

When I checked the files installed by nusb3e, I noticed 2 puzzling things:

a) 2 bytes of explorer.exe installed by nusb3e differ from explorer.exe in the digitally signed ie4shl95.cab in MS Internet Explorer v5.5 SP1 and SP2. Why?

b ) Why does nusb3e replace Explorer.exe v4.72.3110.1 of 4/23/99, which came with Win98SE, with an older and smaller Explorer.exe v4.72.3612.1700 of 1/29/99?

There is an apparent inconsistency between the build numbers and the modification dates of explorer.exe. I suspect (please correct me if I am wrong) that the more current version in this case is indicated by the later modification date, NOT by the higher build number. Explorer.exe of Win98FE [version of 24-Nov-1998], for example, has the same size and build number as that of Win98SE, but is different, only the modification date of 5/11/98 indicates that it is an earlier version.

Did MS release different versions of IE5.5 for different operating systems, with Explorer.exe v4.72.3612.1900 possibly intended for Win95 systems, not for Win98 systems? One version of IE5.5 in my archive, apparently for WinME, does not include ie4shl95.cab.

See also http://www.msfn.org/board/maximus-decim-native-drivers-t43605-pid-787828.html/page__view__findpost__p__787828

Could it be that MS has removed vulnerabilities from the Explorer.exe of Win98SE, which still exist in the Explorer.exe released with IE4 and which is used by nusb, assuming the 2-byte-difference is not important? Could this explain why the nusb-system was infected, but not the non-nusb system?

BTW, the name "ie4shl95.cab" of the archive containing explorer.exe used by nusb, implies that this version of explorer.exe was originally made for Win95.

I have currently replaced on my main laptop the 3 instances of nusb-explorer.exe with Win98SE-explorer.exe in the locations \Windows\Explorer.exe, \Windows\\Options\Cabs\explorer.exe and \Windows\Explorer.sav. But I am not sure whether this precautionary measures is useful, or whether I am barking up the wrong tree.

My main laptop has been running nusb with the Win98SE-explorer.exe for the past 24 hours, the Safely-remove icon in the system tray is of a slightly darker green, and Windows Explorer seems to be slightly slower. I have not encountered any problems yet with Win98SE-explorer.exe under nusb3 when connecting and re-connecting USB devices.

ADDENDUM: I have just tried out mdgx's modification of Explorer.exe http://www.mdgx.com/files/EXPLORER.EXE (displays "Windows 98 Second Edition" when pressing the Start button, also the My Computer icon looks different, more info at http://www.mdgx.com/files/explor9x.php, installer at http://www.mdgx.com/files/EXPLOR98.EXE ). On the first look it seems to work fine with nusb, also with WinBoost v4.60. BTW, after I had replaced the nusb-explorer.exe with the Win98SE-explorer.exe, WinBoost wouldn't come up anymore, it gave an error msg when loading, strange, but no major problem, I haven't used it for a long time and might uninstall it.

Edited April 3, 2010 by Multibooter

[dencorso]

b ) Why does nusb3e replace Explorer.exe v4.72.3110.1 of 4/23/99, which came with Win98SE, with an older and smaller Explorer.exe v4.72.3612.1700 of 1/29/99?

Except in very unusual situations (for more about those, read this, this and this), you should trust the file version, not the file date/time (since an older build might have been recompiled later, or the file date/time simply changed to conform a given release). And, BTW, the EXPLORER.EXE you've got from MDGx is v. 4.72.3612.1710 (the latest known to exist for 98FE/SE), which is the one I also use for a long time now.

[Queue]

a) 2 bytes of explorer.exe installed by nusb3e differ from explorer.exe in the digitally signed ie4shl95.cab in MS Internet Explorer v5.5 SP1 and SP2. Why?

The 2 byte difference is the system tray bit-depth fix. That's also why the safely remove hardware tray icon is darker for you since you reverted.

You're barking up the wrong tree here; rely on build number in this case, and you should really be using the newer version. You're losing functionality and bug fixes, and grasping at straws that it's the source of your infection.

Queue

[Multibooter]

Read this

I've tried the MiTeC EXE Explorer http://www.mitec.cz/Downloads/EXE.zip you mentioned there, it is an excellent tool for finding header time stamps.

the EXPLORER.EXE you've got from MDGx is v. 4.72.3612.1710 (the latest known to exist for 98FE/SE), which is the one I also use for a long time now.

I have tried to find where the explorer.exe build 1710 of mdgx comes from, it has a header time stamp of 2/8/99, in contrast to explorer.exe in IE55SP2 and nusb, which have a header time stamp 1/30/99. i found some info here http://www.msfn.org/board/beta-t61749-pid-686070.html/page__view__findpost__p__686070

1700 is from IE6.0SP1. But I am not sure about 1710. What is its source ? Maybe MDGx modified the version.

I modded this one, Gape. explorer.exe build 1710 is no different from 1700 except for very minor tweaks that I'll keep quiet about.

but when I looked into the installation source of IE6 SP1, I couldn't find an explorer.exe in it. The MyComputer icon in mdgx-explorer.exe looks like from Win2k. Any idea where erpdude8 got this version of build 1700 from, with the later header time stamp 2/8/99?

BTW, finding a full installation source of IE6 SP1 isn't that easy, I found one on my Tenga-infected 1TB USB HDD, as a backup iso image of the original Norton SystemWorks 2005 CD. I have on my main laptop IE6 6.00.2600.0000 of 20-Aug-2001, and have test-installed IE6 SP1. msfn.org seems to load under SP1 substantially slower than under the initial release of IE6.

a) 2 bytes of explorer.exe installed by nusb3e differ from explorer.exe in the digitally signed ie4shl95.cab in MS Internet Explorer v5.5 SP1 and SP2. Why?

The 2 byte difference is the system tray bit-depth fix. That's also why the safely remove hardware tray icon is darker for you since you reverted.

Thanks Queue. BTW, I was only checking on explorer.exe because StartUp Organizer had identified a vulnerability on my system: I had in the startup info just "explorer.exe", without a path to its location in \Windows\. As one of the many precautionary measures I have taken against Tenga was to have StartUp Organizer check every 10 seconds for modifications to my startup entries. This nagged me a little during the test-installation of IE6 SP1, but that's Ok. Edited April 4, 2010 by Multibooter

[submix8c]

Answer (re: the "date discrepancy) - IE4.01 SP1 SP2 is the first release. All that followed are exactly the same except the external date. The "modification" in NUSB could have come from any of them and the only difference is as was already stated. Just to give you some more confusion (if you really want to be confused) is that the IE5 supplied with OfficeXP (2002) Publisher is exactly the same.

Don't worry about it. It's part of the "shell integration" (in IE4SHL95.CAB) for Windows 95 (all the way up to IE5.5 SP2).

HTH

edit - correction above (SP1 was in Win95 OSR2.5 by some OEM's and in Win98FE/SE; at least the EXPLORER.EXE 4.72.3110.1)

Edited April 4, 2010 by submix8c

[dencorso]

I've tried the MiTeC EXE Explorer http://www.mitec.cz/Downloads/EXE.zip you mentioned there, it is an excellent tool for finding header time stamps.

Glad you liked it. I find it quite useful, too.

the EXPLORER.EXE you've got from MDGx is v. 4.72.3612.1710 (the latest known to exist for 98FE/SE), which is the one I also use for a long time now.

I have tried to find where the explorer.exe build 1710 of mdgx comes from, it has a header time stamp of 2/8/99, in contrast to explorer.exe in IE55SP2 and nusb, which have a header time stamp 1/30/99. i found some info here.

<snip>

But when I looked into the installation source of IE6 SP1, I couldn't find an explorer.exe in it. The MyComputer icon in mdgx-explorer.exe looks like from Win2k. Any idea where erpdude8 got this version of build 1700 from, with the later header time stamp 2/8/99?

It's not from the IE6 SP1 at all, but from IE4.01 SP2!

More info about it here.

[Multibooter]

It's not from the IE6 SP1 at all, but from IE4.01 SP2!

IE4.01 SP2 can be downloaded here http://browsers.evolt.org/download.php?/ie/win32/4.01-sp2/ie401sp2.exe

The explorer.exe in it is has the same time header stamp as mdgx-explorer.exe, 2/8/1999.

I made a little test with this special build of explorer.exe for IE4, and as I had suspected, it has a perceptibly less severe sluggish-file-delete problem than the other versions of explorer.exe for Win98SE. This is a very interesting finding.

Edited April 4, 2010 by Multibooter

[dencorso]

Besides NUSB, LLXX's patched ESDI_506.PDR v. 4.10.0.2225 and that EXPLORER.EXE, I think these are the most fundamental updates to add to any 98SE installation:

Unofficial SHELL32.DLL 4.72.3812.634 (Explorer Lockups Fix) [link] (do read also: PATCHED SHELL32.DLL BUG + FIX).

Unnofficial KERNEL32.DLL 4.10.0.2226 (2-4 GB Files Errors Fix) [link] (this I think you already use).

Unnofficial KRNL386.EXE 4.10.0.2000 (Stack Corruption Fix) [link].

[submix8c]

Huh!! re The Original Topic - Found this

Note the Small.Gen one... I had found references relating to this in searching for Tenga. Starting to sound like you'd been getting drive-by's maybe?

Hope you finally get everything sorted out.

[Monroe]

dencorso ... My version of ESDI_506.PDR on my Windows 98SE machine is showing as v4.10.2230 ... you mention the version 4.10.0.2225 with that extra "0" after the "10" ... is that correct? I'm a little confused on these versions.

I found this list of versions by LLXX from 2006:

---------------------------------------------------------------------------

I am not responsible for any damage caused by the use of these drivers.

Attached File(s)

* Attached File 4102226F.ZIP (14.1K)

Number of downloads: 1882

* Attached File 4102222F.ZIP (13.87K)

Number of downloads: 987

* Attached File 4903000F.ZIP (15.23K)

Number of downloads: 708

* Attached File 4102225F.ZIP (13.98K)

Number of downloads: 1062

* Attached File 4102001F.ZIP (13.85K)

Number of downloads: 487

* Attached File 4102186F.ZIP (13.97K)

Number of downloads: 529

* Attached File 4001111F.ZIP (13.53K)

Number of downloads: 428

* Attached File 4001119F.ZIP (13.65K)

Number of downloads: 594

This post has been edited by LLXX: 04 August 2006 - 04:29 AM

---------------------------------------------------------------------------

Besides NUSB, LLXX's patched ESDI_506.PDR v. 4.10.0.2225 and that EXPLORER.EXE, I think these are the most fundamental updates to add to any 98SE installation:

Unofficial SHELL32.DLL 4.72.3812.634 (Explorer Lockups Fix) [link] (do read also: PATCHED SHELL32.DLL BUG + FIX).

Unnofficial KERNEL32.DLL 4.10.0.2226 (2-4 GB Files Errors Fix) [link] (this I think you already use).

Unnofficial KRNL386.EXE 4.10.0.2000 (Stack Corruption Fix) [link].

Thanks ...

[Prozactive]

@duffy98:

Versions 4.10.2230 and 4.10.2225 (updated) of ESDI_506.PDR are identical. This was recently discussed in this thread.

@dencorso:

Thank you for the info on the updated versions of KERNEL32.DLL and KRNL386.EXE. I didn't have those updates installed on my systems.

Edited April 8, 2010 by Prozactive

[dencorso]

@Prozactive: You're very welcome!

@duffy98: Well, Prozactive already answered your main question. Let me answer the minor one: Microsoft's (and many others') version numbers are always in the format xxxx.xxxx.xxxx.xxxx (for more about it see this post, by Petr) However, when you look at them through the right-click -> Properties menu -> File version, in many cases, when one of the nuber groups is "0" it is omitted, for some reason... Thus 4.10.0.2225 is, in fact, the same as 4.10.2225. In the fileset from Win ME this is more visible, because most of the files are 4.90.0.3000, but there are some which are 4.90.3000.0, and either show simply as 4.90.3000, when you use properties. But when you use other programs to establish the file version, (like microsoft's filever.exe [KB913111, newer version inside this package] or getver.exe [link] by L. Brisar, or the MiTeC EXE Explorer), then you get to see those zeroes.