*MS06-040 exploit in the wild

Published: 2006-08-13
Last Updated: 2006-08-13 17:57:47 UTC
by Swa Frantzen (Version: 7)
0 comment(s)
We have caught a live exploit against a Windows 2000 Server. The pcap packets of the exploit fire the signatures in snort for the vulnerability described in MS06-040.

We have multiple independent sources of reports at this time.

It looks like it's building a botnet (as we expected).
Signs defenders should look for:
  • Filename: wgareg.exe, MD5: 9928a1e6601cf00d0b7826d13fb556f0 (this is the bot)
  • Incoming traffic on 445/TCP but there is a lot of background noise on that port.
  • Snort signatures firing on:
    • BLEEDING-EDGE EXPLOIT NETBIOS SMB-DS DCERPC NetrpPathCanonicalize request (possible MS06-040)  [Bleedingsnort]
    • NETBIOS SMB-DS srvsvc NetrPathCanonicalize little endian overflow attempt [Sourcefire VRT]
  • Outgoing traffic to bniu.househot.com:18067 (Command and Control center, multiple IPs, IRC)
  • Outgoing traffic to ypgw.wallloan.com:18067 [we haven't seen those ourselves but do have multiple independent sources confirming it]
  • Outgoing traffic to port 445/TCP (scanning for victims and exploiting them)
Since this is a botnet, these bots might do much more depending on what the controller has in store for them. So unfortunately you basically only have the choice to clean them by wiping the disk if you ever want to trust the machines again.

Please do not ask for samples at this point.
We have shared it with the usual anti-virus vendors already.

Should you find other activity of these bots or differing MD5, we would very much appreciate a copy at the contact page.

We ran the bot through virustotal:
Scan results
File: wgareg.exe
Date: 08/13/2006 03:03:43 (CET)
AntiVir found [HEUR/Crypted.Layered]
Authentium 4.93.8/20060812 found [Possibly a new variant of W32/Threat-HLLIM-based!Maximus]
Avast 4.7.844.0/20060810 found nothing
AVG 386/20060811 found nothing
BitDefender 7.2/20060813 found [Generic.Malware.IXdld.658BDD6B]
CAT-QuickHeal 8.00/20060812 found [(Suspicious) - DNAScan]
ClamAV devel-20060426/20060813 found nothing
DrWeb 4.33/20060812 found nothing
eTrust-InoculateIT 23.72.94/20060812 found nothing
eTrust-Vet 30.3.3012/20060811 found nothing
Ewido 4.0/20060812 found nothing
Fortinet found nothing
F-Prot 3.16f/20060811 found [Possibly a new variant of W32/Threat-HLLIM-based!Maximus]
F-Prot4 found [W32/Threat-HLLIM-based!Maximus]
Ikarus found nothing
Kaspersky found nothing
McAfee 4827/20060811 found nothing
Microsoft 1.1508/20060804 found nothing
NOD32v2 1.1704/20060811 found [a variant of Win32/IRCBot.OO]
Norman 5.90.23/20060811 found [W32/Suspicious_M.gen]
Panda found [Suspicious file]
Sophos 4.08.0/20060812 found nothing
Symantec 8.0/20060813 found nothing
TheHacker found nothing
UNA 1.83/20060811 found nothing
VBA32 3.11.0/20060811 found nothing
VirusBuster 4.3.7:9/20060812 found nothing
wgareg.exe messes in the windows registry. One of the things it adds is a description of itself: "Ensures that your copy of Microsoft Windows is genuine and registered. Stopping or disabling this service will result in system instability.". Right ... It also appears to change settings related to firewalls and sharing.

LURHQ has also a story on the same by Joe Stewart and they also found a variant of the binary with a different MD5 and slightly different behaviour.

Thanks to all involved: William, Jim, Scott, Dan and all those I forgot.

Swa Frantzen -- Section 66
0 comment(s)

Information to Help Track Down Infections From WGAREG.EXE

Published: 2006-08-13
Last Updated: 2006-08-13 16:03:56 UTC
by Deborah Hale (Version: 1)
0 comment(s)
Many thanks to Andreas, one of our readers from Germany.  He has provided us with the results of his research and where he found tracks left by the install.  He has agreed to allow us to share the information with our readers.

From Andreas analysis:

[1] The exploit might also have entered using some java "hole", since I found a trace in ..\Application Data\Sun\Java\Deployment\cache\javapi\v1.0\ext\ with a handful of highly suspicious .jar and .zip files.

[2] C:\WINNT\NT contained a file named NRCS.EXE, 25,185 bytes in length.

[3] C:\WINNT\Debug contained a file named dcpromo.log.

[4] Found malicious registry keys in:



See information below for a method to remove these keys.

[5] NOD32v2.......1.1704/20060811....found [a variant of Win32/IRCBot.OO]

[6] The malicious program disguised as a .jpg in C:\Documents and Settings\Default User\Temporary Internet Files\Content.IE5\<some random folder>.

According to Andreas it has behavior very close to CUEBOT-K.

Sophos Cuebot-K

Cuebot-K is believed to be spreading through AIM or AOL neither of which he has installed. 

We hope this will give you some places to look for the tracks of this new malicious program.


Again Andreas has provided us with some terrific information. He has figured out how to remove the registry keys. Here is his information.

1. Use REGEDT32, *not* regedit!

2. Check current real time. Supposed it's 16:30.

3. In DOS prompt:
at 16:31 /interactive regedt32.exe

This will - after 1 minute - open regedt32.exe with SYSTEM rights!!! (yes there is something _more_ powerful than an Administrator in Windows). And automagically - the keys can be violently deleted.

As an alternate, you can open the registry editor with "administrator" rights and then give yourself "full control" on the registry key in question. By default, the keys under CurrentControlSet\Enum are accessible only to the all-powerful SYSTEM user, but this is for good reason. Delete or change the wrong key under \Enum, and your Windows installation will turn into an inert heap of bytes. So tread carefully!

0 comment(s)

Tip Of The Day

Published: 2006-08-13
Last Updated: 2006-08-13 14:37:35 UTC
by Deborah Hale (Version: 1)
0 comment(s)
Do you know where your backup tape software is?

We have been talking about backups the last couple of days.  I am a big advocate of backups, having had one computer crash and burn a few years ago and left me high and dry with no backups.  I suddenly became obsessed with backups. 

I went to work for a large corporation who also was adament about backups. They expected them to be done on all systems containing any company information period.  We installed a server (Novell at that time) and set a policy that all company data was to be stored on the file server. Anyone caught with company data on a local hard drive could be written up or penalized.  The backups were done everyday. Tapes were stored in a fireproof/bomb proof vault. This was a reinforced room in the center of the office building that was tightly controlled for access. In this room were additional fire proof cabinets.  The tapes were kept in these cabinets in fire proof tape cases.  We had a 12 month rotation. We did daily backups Monday thru Thursday, weekly backups Friday 1 through 4, and monthly backups Month 1 through 12.  At the end of the fiscal year a backup was done that was kept forever (theoretically).  The year end tape was sent to the corporate IT department and was clearly marked for location and dates covered.

I thought we had a more than adequate backup plan.  And we did. However, here are a couple of things that I/we overlooked. 

1) We had a system failure and had to reload from scratch.  We had to replace the hard drives in the servers (this was more than15 years ago by the way, pre raid stuff).  After the drive was replaced, I had to reinstall the Novell OS from scratch.  After the install was done then I had to reload the tape software before I could restore the tapes.  Oh No, where did the tape software go, let's see where did we put it.  Software cabinet, hmmm, not there. desk drawer, nope. Vault, not there either.  Started asking guestions about where the software may have been stored.  My supervisor wasn't sure, the guy that I replaced had initially installed the system. He probably would know where it was at but we couldn't call him. He had left the company not of his own free will.  I didn't think he would be very quick to answer my questions. So now what do we do. I called the software vendor and explained the dilemma to them. They said that it was not a problem. I just needed to fax them a copy of the paperwork showing we owned a legal copy of the software with my license number on it.  No problem right.  Purchasing would have that.

Off to the purchasing office.  The Purchasing Manager had been with the company just a little longer than I had so he was not sure when the software was purchased or where it was purchased from.  We looked through the files and couldn't find anything. Luckily the previous purchasing manager had been transferred to another location within the company so we contacted him.  He had a "great little sponge in his head" and was able to tell us where it was purchased from, when, approximately it was purchase and which box in the fireproof vault we would fine the information in.  Thankfully we thought we were back on track.

We dug up the paperwork and faxed it to the company to get replacement for the software.  Thinking we were going to be ok we anxiously awaited word that the software was in route.  Umm - no the story does not end here.  I received a call back from the software company - umm that is a really old version of the software. We don't have that anymore. We will have to send you the new version and you will have to pay us I think it was $2500 for the new version.  I said ok - we have no choice - I will get a PO and fax to them.  Then they dropped the bomb on me. By the way - this is not a clean restore.  There is a process that needs to be done to restore the old format and convert for the new. No guarantee that all fo the files will restore. Oh my goodness, this just keeps getting worse.

We did get the new software, and we did go through the reinstall, and we did go through the conversion. I had to apply some updates to my Novell server that I hadn't planned on as a result of the software update, I had to do some heavy breathing and sweating. But 3 days (and nights) later we were back on line and had lost a minimal amount of information.  I had to reinstall my users manually, I could not restore the permissions from tape. That was a bit of a challenge and took a while to get everyone back to "normal". 

The moral of this story and my tip first tip for the day is:

Keep your tape software in a safe, secure location. Make sure you stay up to date and install new versions as they come out. Document your user's and security settings, document your system configuration so that if you have to reinstall and have problems restoring your settings you will know what they are.

Now for tip number 2:

What about your archival tapes?

Another issue with backups that I have dealt with happened about 5 years ago.  A customer that I was working with had been doing backups and had been doing archival backups at year due to government reporting requirements that they have to deal with.  They can for 10 years be mandated to produce information on demand.  They do backups that will allow them to recover the information that is required.  They had an adequate backup plan.  They stored the backups off site at the local bank.

They did overlook one thing.  They had replaced there backup drive.  The old drive was disposed of, it was obsolete and didn't work very well anymore.  They received a request for reproducing a report for a court case that was evolving.  They sent some one to the bank to get the tape to do the restore. No problem, except that the tape was for a drive they no longer had. How do they restore now?  Can we buy a tape drive? Do we know anyone that can restore it for us? How do we get to the data? 

Luckily I had the same type of tape drive that they needed to do the restore. I was able to recover the data for them and then it was backed up to the new tape device.  All of the other tapes were brought to me and I was able to recover the data from all of them and we moved them to the new media.

The moral to this story and second tip of the day is:

If you are replacing your current tape drives you need to restore any information in the old format and backup to the new format. Or you need to keep the old drive around as long as possible for retrieval purposes. 

Keywords: ToD
0 comment(s)

MS06-040 wgareg / wgavm update

Published: 2006-08-13
Last Updated: 2006-08-13 13:37:49 UTC
by Daniel Wesemann (Version: 1)
0 comment(s)
We have received samples and infection reports from several sources. It looks like there are so far two different binaries involved:

9928a1e6601cf00d0b7826d13fb556f0  wgareg.exe
2bf2a4f0bdac42f4d6f8a062a7206797  wgavm.exe

The former, wgareg.exe, apparently shows up simply as ".exe" (blank-dot-exe) on infected systems and only later gets renamed or copied to wgareg.exe.  AV protection is slowly coming online, here's a few of the names chosen:
Symantec - W32.Wargbot - not yet in the current pattern
TrendMicro - Worm.IRCBOT.JK and JL - protection available
McAfee - IRC.Mocbot - protection as extra.dat available
F-Secure - IRCBOT-ST - protection available

We'll update this post as more information becomes available.

0 comment(s)

Programs That Request A Lot Of Contiguous Memory May Fail After Security Update Is Applied

Published: 2006-08-13
Last Updated: 2006-08-13 13:28:24 UTC
by Deborah Hale (Version: 1)
0 comment(s)
Programs that request lots of contiguous memory may fail after you install security update 921883 (MS06-040) on a Windows Server 2003 SP1-based computer. It appears that the problem occurs if you use programs that require one gigabyte or more contiguous memory the programmay fail with an unexpected error after you install security update 921883 on a 32-bit Microsoft Windows Server 2003 Service Pack 1 (SP1)-based computer. For example, programs such as Microsoft Business Solutions - Navision 3.7 may fail.

Microsoft has a temporary hotfix available but recommend that it only be installed if you have a severe problem.  Otherwise they recommend waiting until service pack 3 when the additional testing has been completed.

Hotfix available for contiguous memory problem.

0 comment(s)


Diary Archives