Published: 2003-08-29

RealServer Vulnerability, Exploit and Scans

Earlier this week, a vulnerability in RealServer was announce. This vulnerability may be exploitable via port 554, 7070, 8080, 9090 and 22010. After the announcement, we did see a notable increase in scans for port 554 and 7070.

At this point, no patch is available. However, Real published configuration options to avoid the vulnerability.

Real Networks Announcement:


Port 554 Graph:


Port 7070 Graph:


Please send any additional information, like packet captures, to isc@sans.org .


Published: 2003-08-26

Sobig-F and Nachia update


Sobig-F went through two update cycles. Reports are mixed about success / failure. Most updates server where taken down, and the remaining server handed out a benign payload. However, it is possible that individual Sobig installations received an updated server list. At this point, it is highly recommend to rebuild infected machines from scratch.

In addition, administrators of mail servers are asked not to bounce infected messages. Sobig will fake the "From" header and notification messages will flood innocent users.


Nachia continues to flood networks with ICMP messages and port 135 scans. Based on our measurements, the number of hosts infected by Nachia and MSBlaster is not decreasing and stead at around 150,000. Network administrators are strongly adviced to track down infected machines.

Many ISPs are now blocking ICMP traffic with a payload lengh of 92 Bytes. This payload length is used by Nachia. However, at least one network diagnosis tool is using the same payload length, but with different payload.

Sample snort rule to identify Nachia:

alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP PING Nachia Worm"; content:"|aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa|";itype:8;dsize:64;)

Most Snort installations already have a similar rule installed:

alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP PING CyberKit 2.2 Windows"; content:"|aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa|";itype:8;depth:32; reference:arachnids,154; sid:483; classtype:misc-activity; rev:2;)

While this rule does not check the payload size, it works well enough for most purposes.


Published: 2003-08-22

SoBig Virus Update

Sobig Update Cycle

SoBig-F, the most recent incarnation in the family of Sobig mass mailing viruses, will be entering its update cycle today at 19:00 UTC. Between 19:00 and 22:00 UTC, the virus will attempt to contact a predefined set of hosts to download updates. At this point, it is not know what the update will do.

The list of "master servers" can be updated remotely by using signed UDP packets to port 995-999.


The Sobig virus is a significant threat to any network. It opens backdoors, includes proxy servers, and spreads fast across file shares and via e-mail. Detection and removal of infected machines should be a high priority.


Sobig can be detect in several ways:

e-mail: An infected machine will send large amounts of e-mail. It will not use the usual email server but instead send e-mail directly.<Br>
virus scanners: Currently, all major virus scanners will detect Sobig-F.

NTP traffic: The worm will synchronize with various NTP servers to obtain an accurate time.

Counter Measures:

Block all outbound traffic on port 25 unless it is originating from a known mail server. Require users of your network to use this authorized mail server. Implement virus scanning on this mail server.

Block inbound UDP traffic to ports 995-999.

Block outbound UDP traffic to port 8998.

Remind users not to click on e-mail attachments ( http://isc.sans.org/antivirus.pdf )

Only Windows can be infected by this virus. Other operating systems like Linux, OS X, and BSD can be used to protect systems.
Note: Sobig will spoof the 'From' address. It uses e-mail addresses found in cached Internet Explorer files and contact lists. Please configure your anti virus scanners to suppress notifications to senders of Sobig infected e-mail. Likely, the email will not reach the actual sender, but instead will end up in some innocent mailbox.

Further Details:




Published: 2003-08-20

Power Outage Impact - Nachia Worm - Sobig F

Power Outage

Renesys published a very interesting paper detailing the impact of the power outage on connectivity in the North East.


Nachia Worm

The Nachia worm is still spreading fast. While this worm is frequently refered to as a 'good worm', it should be noted that the impact of this worm is worse than 'Blaster'. While this worm cleans up blaster infected machines, it causes network disrubtion due to its agressive pinging. Also, note that this virus will install a back door and it will scan for machines that are vulnerable to the WebDav IIS exploit. In so far, this worm may just remove the Blaster virus to protect itself, like many 'auto rooters' do.

Sobig F

Despite the best efforts of system admins world wide, users are still clicking on e-mail attachments. We strongly recommend attachment stripping on mail gateways. Please note, that the 'From' address is spoofed. Do not send auto replies to senders, as this will just worsen the email flood caused by Sobig F. As other Sobig variants, this one includes the ability to update the worm remotely, backdoors and a full set of other evilness.


Published: 2003-08-19


A new variant of the SOBIG worm is spreading fast.

Best practice to do now:

- update anti-virus scanners, both on desktops,
servers and security perimeters

- communicate safe email handling instructions to all users
(do not open unsolicited attachments, no matter
how tempting the instructions or title are)

- block incoming UDP ports 995 - 999

- block outgoing UDP ports 8998

- monitor for outgoing UDP port 123 traffic (used by NTP clients as well)
for signs of infection
This new variant is rather successful at spreading.

Read more at:







Published: 2003-08-18

Increase in ICMP scans

Over the last few hours, sensors detected a remarkable increase in ICMP
traffic. At this point, we assume that the traffic is linked to the
'Nachi' worm: http://vil.nai.com/vil/content/v_100559.htm
The worm is also known as 'Welchia' (
http://securityresponse.symantec.com/avcenter/venc/data/w32.welchia.worm.html )
While the investigation is still in progress, we did identify so far the following characteristics:

- some of the traffic is spoofed

- the data content is all '170' (0xAA)

- ICMP echo requests (type 8, code 0)
Source-Target correlation fingerprints
ICMP Data: http://isc.sans.org/images/icmpfp.png

all Data: http://isc.sans.org/images/allfp.png
port 135: http://isc.sans.org/images/port135fp.png
Sample Packet
(target IP obfuscated)

0x0000 4500 005c 2dc8 0000 7901 66a6 4349 919e E..\-...y.f.CI..
0x0010 xxxx xxxx 0800 3318 0200 6d92 aaaa aaaa ......3...m.....
0x0020 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ................
0x0030 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ................
0x0040 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ................
0x0050 aaaa aaaa aaaa aaaa aaaa aaaa ............

Snort identifies these packets as "ICMP PING CyberKit 2.2 Windows".


Published: 2003-08-16

Blaster Worm Cleanup


The DDOS attack against windowsupdate.com has been avoided so far due to
Microsofts decision to no longer resolve this particular hostname. Other
hosts within this domain are still accessible, so is 'windowsupdate.microsoft.com', the hostname used by Windows Update.

In the wake of this worms, at least one virus has been reported to
masquerade itself as a "Blaster Worm Fix". As always, do not execute any attachments from unknown sources.

One popup ad has been spotted which attempts to mimic the RPC error message in order to trick users into purchasing a software firewall.

Scanner False Positives

Microsoft made a scanner available which can be used by network administrators to verify remotely if machines are patched for MS03-26. We have received reports that this scanner will show Windows 98 machines as vulnerable, even though they are not.

At this point, we do recommend a followup scan with NMAP to verify the vulnerability, if no other means are available to verify if the machine is a running Windows 98.

Sample output from the scanner and nmap against a Windows 98 machines:

(taget IP replaced with

C:\Program Files\KB823980Scan>KB823980Scan.exe

Microsoft (R) KB823980 Scanner Version 1.00.0002 for 80x86
Copyright (c) Microsoft Corporation 2003. All rights reserved.

<+> Starting scan (timeout = 5000 ms)

Checking unpatched

<-> Scan completed


Patched with KB823980 = 0
Unpatched = 1

Needs Investigation = 0
Connection refused = 0
Host unreachable = 0
Errors = 0


NMAP output:

Starting nmap V. 3.00 ( www.insecure.org/nmap )
Host somehost.somedomain ( appears to be up ... good.
Initiating SYN Stealth Scan against somehost.somedomain (
Adding open port 139/tcp
Adding open port 135/tcp
The SYN Stealth Scan took 17 seconds to scan 65535 ports.
For OSScan assuming that port 135 is open and port 1 is closed and neither
are firewalled
Interesting ports on somehost.somedomain (
(The 65533 ports scanned but not shown below are in state: closed)
Port State Service
135/tcp open loc-srv
139/tcp open netbios-ssn
Remote OS guesses: Turtle Beach AudioTron Firmware 3.0, Windows NT4 or
OS Fingerprint:
TCP Sequence Prediction: Class=trivial time dependency
Difficulty=1 (Trivial jo
TCP ISN Seq. Numbers: 19E8C4 19E933 19E9A1 19EA0F 19EA80 19EAEE
IPID Sequence Generation: Broken little-endian incremental
Nmap run completed -- 1 IP address (1 host up) scanned in 17 seconds


Published: 2003-08-15

Blaster Worm Update - Power Outage


Microsoft decided to no longer resolve 'windowsupdate.com'. The Blaster worm
will not start its DDOS attack as a result. 'www.windowsupdate.com' and
'windowsupdate.microsoft.com' continue to be reachable.

As the traffic caused by 'blaster' did start to show a decrease, a wide spread
power outage across the Northeastern US caught everyones attention. From news
coverage, there is no relation between blaster and the power outage. However,
the extend and duration of the power outage caused numerous ISPs across the
northeastern US and Canada to shut down until power was restored.

Based on BGP routing table size, a number of networks are still not reachable as
off this morning ( Aug. 15th).

(see prior 'diaries' for more analysis)

Blaster Popup Ad

One 'popup ad' has been spotted that attempts to look similar to the popup
message shown if the RPC DCOM service shuts down. This popup message attempts
to trick users into buying software to clean and protect their computer.

Blaster DDOS

During the day today, we expect the DDOS against 'windowsupate.com' to start.
However, the 'Windows Update' function should still work, as it uses
'windowsupdate.microsoft.com'. If you are operating a larger network, we
recommend that you monitor traffic to 'windowsupdate.com'. The traffic will use spoofed source IPs. The last two octets of the source IP will be spoofed.

Infected machines will only start the DDOS attack after they have been rebooted. If a machine is scanning right now, it will continue to scan.

Blaster DDOS Mitigation

If traffic to 'windowsupdate.com' exceeds reasonable networks, block the respective IPs. As this host is not used for regular updates, users will still be able to reach the actual update site.

Monitor traffic to port 135 and 4444 to spot infected machines. This traffic will not be spoofed. Block port 135 as close to end users as possible to avoid further spread of the virus. Do not block port 4444 for larger networks with a diverse user base, as it is used for some critical applications. The port 4444 traffic will be of no consequence if port 135 is blocked.

Windowsupdate.com may is no longer resolving in at least some networks. As a result, the worm will not start its DDOS attack.


We expect to reduce the infocon from Yellow to Green later today, as 'Blaster' is currently in steady state. No wide spread infrastructure issues are expected at this point.


Published: 2003-08-14

Blaster Worm Update


At this point, the Internet Storm Center is tracking in excess of 150,000 machines
infected with the Blaster worm. The total number of infected machines is suspected to be significantly higher.

for our earlier analysis of the worm, see



As of yesterday (Aug. 13th), anti virus vendors found two variants of blaster. At this point, neither variant behaves dramatically different and neither variant is as wide spread as the original msblaster version. However, note that these variants use different file names and registry key entries.

Variations that install backdoors have been reported. It is not clear at this point if these are variants of the 'sdbot' based massrooters which had been spotted over the last 2+ weeks

Code Analysis

Chris Ream provided a detailed source analysis of the code

http://isc.sans.org/Analysis_of_MSBLAST.pdf (PDF File)

Cleanup of infected machines is proceeding slowly. We strongly recommend a complete rebuild of infected machines. The RPC DCOM vulnerability has been used by widespread attack tools for over two weeks before blaster was released. Current virus removal tools will only remove the blaster worm and a few versions of the tools used prior to blaster. Even if you remove the exploit code, you may still be left with backdoors installed by one of the massrooter exploits.

Infrastructure Impact

At this point, no wide spread internet connectivity issues are associated to blaster. However, on Saturday, blaster infected machines will launch a DDOS attack against Microsoft update side. As a result, networks with large numbers of infected hosts may experience problems.

Infocon Outlook

We expect to remain at infocon 'yellow' while awaiting the impact of the DDOS.
The DDOS is expected to hit 'windowsupdate.com'. From preliminary testing, it looks like Windows systems should still be able to retrieve updates, as usually
'windowsupdate.microsoft.com' is used by the automated update scripts.


Published: 2003-08-11


This RPC DCOM worm started spreading early afternoon EDT (evening UTC). At this point, it is spreading rapidly.

Increase in port 135 activity:

NOTE: PRELIMINARY. Do not base your incidents response solely on this

Executive Summary:

A worm has started spreading early afternoon EDT (evening UTC Time) and is expected to continue spreading rapidly. This worms exploits the Microsoft Windows DCOM RPC Vulnerability announced July 16, 2003. The SANS Institute, and Incidents.org recommends the following Action Items:

* Close port 135/tcp (and if possible 135-139, 445 and 593)

* Monitor TCP Port 4444 and UDP Port 69 (tftp) which are used by the worm for activity related to this worm.

* Ensure that all available patches have been applied, especially the patches reported in Microsoft Security Bulletin MS03-026.

* This bulletin is available at

* Infected machines are recommended to be pulled from the network pending a complete rebuild of the system.
Technical Details:

Names and Aliases:
W32.Blaster.Worm (symantec),W32/Lovsan.worm (McAfee), WORM_MSBLAST.A (Trend Micro),Win32.Posa.Worm (CA),Lovsan (F-secure), MSBLASTER,Win32.Poza.
The name of the binary is msblast.exe. It is packed with UPX and will self
extract. The size of the binary is about 11kByte unpacked, and 6kBytes packed:

MD5sum packed: 5ae700c1dffb00cef492844a4db6cd69 (6176 Bytes)
Infection sequence:

1. SOURCE sends packets to port 135 tcp with variation
of dcom.c exploit to TARGET

2. this causes a remote shell on port 4444 at the TARGET

3. the SOURCE now sends the tftp get command to the TARGET, using the
shell on port 4444,

4. the target will now connect to the tftp server at the SOURCE.
So far we have found the following properties:

- Scans sequentially for machines with open port 135, starting at a presumably random IP address

- uses multiple TFTP servers to pull the binary

- adds a registry key to start itself after reboot

- infected machines will start a DDOS attack (port 80 synflood) against windowsupdate.com on August 16th.
Name of registry key:

SOFTWARE\Microsoft\Windows\CurrentVersion\Run, name: 'windows auto update'

Strings of interest:

I just want to say LOVE YOU SAN!!
billy gates why do you make this possible ? Stop making money and fix your software!!
start %s
tftp -i %s GET %s
windows auto update

The worm may launch a syn flood against windowsupdate.com on the 16th. It has the ability to infect Windows 2000, XP and potentially 2003.

The worm uses the RPC DCOM vulnerability to propagate. One it finds a vulnerable
system, it will spawn a shell on port 4444 and use it to download the actual worm via tftp. The exploit itself is very close to 'dcom.c' and so far appears to use the "universal Win2k" offset only.
Existing RPC DCOM snort signatures will detect this worm. The worm is based on dcom.c
Removal and Eradication:
Once you are infected, we highly recommend a complete rebuild of the site.
As there have been a number of irc bots using the exploit for a few weeks
now, it is possible that your system was already infected with one of the
prior exploits. Do not connect an unpatched machine to a network.
If you can not do this and/or the computer resides on a protected or non-Internet connected network, then several Anti-Virus Venders have supplied tools to assist in removing the worm. However, these tools can not clean-up damage from other RPC DCOM malware such as the recent sdbot irc bots. This method of cleaning your system is _not_ recommended, but the URLs are presented below for completeness.


Other References:














Published: 2003-08-09

More RPC DCOM - SDBot News

RPC DCOM Update: sdbot variant

If you didn't patch and you're rooted by anything, then Rebuild.

As the information about file hiding in the e-mail post to Unisog below shows, for critical systems, you cannot rely on any vendors "cleaning tools" in a situation like this because;

The tools are not going to find everything from all of the variants and:

You're never going to be able to afford the forensic expense necessary to ensure all hidden files on your system are found.

So byte the bullet, rebuild and patch.

----- Original Message -----
From: "Andy Efting" <aefting@emory.edu>
To: <unisog@sans.org>
Sent: Tuesday, August 05, 2003 6:53 AM
Subject: [unisog] Re:Unintended update

Here is more detail that I promised last night. This was written by our NT team:

After working with HP Services, Microsoft, and several departments on campus - we have found the following regarding the RPC exploitation.

This information is provided as-is, etc, etc...
This may not be exact across the board, but is what we have found.

There are several signs that will indicate the presence of the RPC exploit on a system that has not done a manual installation of the RPC exploit patch (KB823980).

All machines we have found to be exploited are running Windows 2000 &; 2003 Server.

In the root directory of the hacked server you will find the actual extracted files from the Microsoft patch (any MS patch will not leave the files sitting in the root). These files include:
update.exe (self-extracting archive)

There will also be an <drive>:\update directory from which the installer is called and it will contain the following files:

There is also some further proof that the server has been hacked. In the SYSTEM event log the following entry was found:

Event Type: Information
Event Source: NtServicePack
Event Category: None
Event ID: 4377
Date: 08/03/2003
Time: 11:18:02 AM
Windows 2000 Hotfix KB823980 was installed.

This entry in the log is usually followed by a server restart which will complete the hack.

Once the server has restarted it will no longer appear to be vulnerable to the RPC exploit on the common ports (135,139,445, and 593) and this was confirmed by scanning with several of the DCOM utilities available but it will now have a new port that is available for use by the hacker (port 33571). This port will only be found by issuing a NETSTAT -A command from the command prompt and it will reveal that the server is "listening" on this port. This port is only "listening" on the servers that were hacked.
The exploited server will also have two files HIDDEN on the <drive>:\WINNT\system32 directory. The files are CSRSRV.EXE and CSRSU.EXE. These files ARE NOT VISIBLE from the console of the server.

(The CSRSRV.DLL is a valid file and should not be removed from your system)

These two files can only be seen when connected to the server via an admin share across the network (C$, D$, WINNT$, etc.). These files are not detected by any antivirus programs since they contain valid program code.
NOTE: If the workstation you are using has also been hacked you will be unable to see these files on any
remotely connected machines as well as the local machine.

The hacker may also modify at least one registry entry in the HKLM\SYSTEM\ControlSet001\CSR*.

The CSRSRV.EXE (Path to Executable: C:\WINNT\system32\csrsu.exe) and CSRSU.EXE (Path to Executable: C:\WINNT\system32\csrsrv -k csrspx)files are listed in the Services MMC as Clipboard and CSRS Windows NT
services respectively. These services will fail to start once the files have been renamed from a remote computer. NOTE: If the workstation you are using has also been hacked you will be unable to see these files on any remotely connected machines as well as the local machine.

The removal process:
These files (CSRSRV.EXE and CSRSU.EXE) cannot be deleted remotely but they can be renamed. Once they have been renamed the services can be removed using the delsrv.exe resource kit tool (http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/delsrv-o.asp)
and executing the following commands:

C:\TOOLS>delsrv csrspx
C:\TOOLS>delsrv csrswin1

The registry keys should be deleted and the server rebooted.

We have created and attached a self extracting patch that will remove the services and registry entries from your local machine. This was packed using WinRAR, and we cannot guarantee successful execution on every system. The patch should be applied AFTER you rename the two hidden files in the system32 directory and have restarted the machine.

The patch should be run locally from the affected machine.
Andrew P. Efting
Security Analyst
Emory University
E-Mail: aefting@emory.edu
Phone: 404-712-2213
Fax: 404-727-0817



Published: 2003-08-05

RPC DCOM Update: sdbot variant

Honeypots captured a number of attempts to install 'sdbot' variants via the
RPC DCOM vulnerability. In each case, 'dcom.c' was used to break in and issue
a tftp command to download the remainder of sdbot.

Sdbot is a very common 'IRC bot'. It allows remote control of infected machines
via IRC and provides a large set of functions like keystroke loggers, DDOS tools, and tools to scan and break into other machines.

In order to protect your systems against this threat, patch systems against the
RPC vulnerability. Possible firewall rules:

- block inbound port 135

- outbound/inbound port 69 (tftp)

- outbound 6667 (irc)

Note: in particular the IRC port is easily changed to a different port. TFTP should probably only be blocked at the perimeter of a private network (home network / small company), not by an ISP.

please notify isc_AT_sans.org about updates.


Published: 2003-08-04


Over the weekend, scanning for the RPC DCOM vulnerability has increased. At least one 'auto-rooter' has been found in the wild. It will install a number of standard backdoors and an irc bot.

So far, the number of sources scanning is not increasing much. We observe 2000-3000 sources each day. This is an indication that there is currently no self replicating code (=worm).

Some question has been raised with respect to the vulnerability of Windows 9x and ME. According to Microsofts advisory, Windows ME is not vulnerable. Windows 9x does not include DCOM by default, but it is available as a free download. Some software, like Kiwi Syslog, requires the installation of RPC DCOM.


please send updates to isc_AT_sans.org


Published: 2003-08-01

Widespread use of RPC DCOM Exploit

-- UPDATE ---

A trojan horse / irc bot has been found in the wild which uses this
vulnerability to 'recruit' systems:

Ever since the announcement of the RPC DCOM vulnerability, the hacker community
has been busy refining exploits in order to make use of this issue.

Over the last two weeks, a number of exploits have been released. They are very
easy to use and have already been used to attack numerous systems.

Currently, more than 1/4 of the sensors participating in the Internet Storm
Center have detected scans for this vulnerability.

If successful, the exploit will be hard to detect. Only if the exploit failed, you will see a popup alert indicating that the RPC service died. Your machine may reboot by itself as a result.

Essentially all versions of Windows are vulnerable. The only exception is Windows ME. A patch has been made available by Microsoft as of July 16th 2003.


- Patch your systems as fast as possible.

- apply firewall rules to block at least port 135, 139 and 445. RPC may use other ports as well depending on configuration. Do not use these limited rules in lieu of patches.

- if possible, disable DCOM. (this may break some functionality). To do so, use 'dcomcnfg.exe'. For details see: http://support.microsoft.com/default.aspx?scid=kb;en-us;825750

For further details, see the MSFT bulletin (MS03-026):

SNORT Rules:

alert tcp $EXTERNAL_NET any -> $HOME_NET 135 (msg:"NETBIOS DCERPC invalid bind attempt"; flow:to_server,established; content:"|05|"; distance:0; within:1; content:"|0b|"; distance:1; within:1; byte_test:1,&;,,,,1,0,relative; content:"|00|"; distance:21; within:1; classtype:attempted-dos; sid:2190; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET 445 (msg:"NETBIOS SMB DCERPC invalid bind attempt"; flow:to_server,established; content:"|FF|SMB|25|"; nocase; offset:4; depth:5; content:"|26 00|"; distance:56; within:2; content:"|5c 00|P|00|I|00|P|00|E|00 5c 00|"; nocase; distance:5; within:12; content:"|05|"; distance:2; within:1; content:"|0b|"; distance:1; within:1; byte_test:1,&;,,,,1,0,relative; content:"|00|"; distance:21; within:1; classtype:attempted-dos; sid:2191; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET 135 (msg:"NETBIOS DCERPC ISystemActivator bind attempt"; flow:to_server,established; content:"|05|"; distance:0; within:1; content:"|0b|"; distance:1; within:1; byte_test:1,&;,,,,1,0,relative; content:"|A0 01 00 00 00 00 00 00 C0 00 00 00 00 00 00 46|"; distance:29; within:16; reference:cve,CAN-2003-0352; classtype:attempted-admin; sid:2192; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET 445 (msg:"NETBIOS SMB DCERPC ISystemActivator bind attempt"; flow:to_server,established; content:"|FF|SMB|25|"; nocase; offset:4; depth:5; content:"|26 00|"; distance:56; within:2; content:"|5c 00|P|00|I|00|P|00|E|00 5c 00|"; nocase; distance:5; within:12; content:"|05|"; distance:0; within:1; content:"|0b|"; distance:1; within:1; byte_test:1,&;,,,,1,0,relative; content:"|A0 01 00 00 00 00 00 00 C0 00 00 00 00 00 00 46|"; distance:29; within:16; reference:cve,CAN-2003-0352; classtype:attempted-admin; sid:2193; rev:1;)

Please send comments to isc@sans.org