New Worm, Old Worm, Someone wants me??????

[Tiger Shark]

OK..... I need some thoughts......

I came in this morning to significantly more Snort alerts than I would usually expect overnight and it rapidly became clear that they comprised basically 2 alerts and there was potential pattern. The alerts are WebDAV Search Access heavily indispersed with Evasive RST detection by the stream4 preprocessor.

Looking at the WhoIs of the various sources they are generating from the US, France but by far the most are from the Pacific Rim, (why is that not too surprising).

My problem is that I don't recognize this activity as an existing worm/skiddie tool, (and if it is someone please slap me...... )

Questions:

1. Is anyone else experiencing this type of traffic?
2. While there is something of a pattern to the events and it appears automated do you think it's worm or human initiated?


Attached is the logfiles of pertinent traffic. There is a probable unrelated event in there but I left it just in case and out of interest - It purports to be from the UN mission in Bosnia

[ratman3]

Could be a new worm. Can you perhaps set up a sniffer and capture some of the offending packets?

[DjM]

Hi Tiger, good chance what your looking at is fallout from the new W32.Welchia.B.Worm. At least the WebDAV stuff.

Have a read.

Cheers:

[Tiger Shark]

DjM: Yep, you could be right. Checking my p0f logs they all appear to be Win2k or WinXP boxes. Interestingly enough they are all reported at the most recent SP level for the OS which implies that someone is applying the patches but apparently not enough of them.....

I really want to know why there are so many Evasive RST detections and that those events seem to often trigger a detection of same from the dest host.

Having Googled up the ying-yang I cannot find a definitive write-up regarding the mechanism an evasive RST uses to do what exactly.... Is it a RST scan or is it seeing if it can crash or exploit something..... Anyone got a concise definition of this?

[Edit]

Oh.... having dug through logs I first started seeing a small amount of these on Tuesday then last night the traffic went up tremendously, (just like the log I posted), and now they have dropped off to almost nothing already....... That's odd IMO.... A new variant usually lasts longer than overnight.......

[/Edit]

[TheTempest]

i'm pretty sure that the RST is a scan technique...

i dont really rember TCP protocol right now, but i think that if a port that is listening recv's a RST flag it will send back some RST/ACK flag or something...and if the port isn't listing then it doesn't send back anything...

as i said, i'm pretty sure thats what it is, however i could be wrong

[Tiger Shark]

Tempest: I can buy that..... But them why would the terminology be different. I mean we have a SYN scan, a Fin Scan, an Xmas scan..... so shouldn't this be termed a RST scan?

Since I can't find a definitive explanaition of an "Evasive RST" anywhere this is beginning to bother me. Interestingly enough I can find lots of places where people have asked exactly the question I am..... and no bugger answered any of them.... I'm beginning to think this is all a hoax......

Can anyone point me to, or even write a tut for extra greenies, the definition of an Evasive RST...... please....

[DjM]

Originally posted here by Tiger Shark
Interestingly enough I can find lots of places where people have asked exactly the question I am..... and no bugger answered any of them.... I'm beginning to think this is all a hoax......

I must have got the same search results Tiger , a lot of questions but pretty thin answers. One thing that did seem to be constant was everyone was told how to disable the alert. This kind of makes me think it's just normal network noise that needs to be filtered, or it's a false positive.

Sorry could help more.

Cheers:

[Tiger Shark]

DjM: Yeah.... I know how to disable.... I've had a few before but they never seemed significant.... But I left the preproccessor alerting on them simply because it didn't make too much "noise"... One of those "someone else is smarter than me" things.... Now it's making "noise" I got interested and no-one seems to know why the preprocessor even bothers with it....

I thought it was a stateful thing.... You and me, (being computers), are chatting away and all of a sudden, for no reason, I throw in a RST..... OK.... Maybe you are trying to mess with my stack..... But with no information it's all getting a tad worrying since I don't know what is going on... The "attacked" machines "seem" fine, (they all run HIDS too), and nothing has changed with the attacks.....

There has to be a reason for the preprocessor even "thinking" about Evasive RST.... But there isn't a single piece of documentation out there that even gives a clue as to why Snort bothers with it..... just that it does and it can be turned off..... Marty had to have a reason.... What might it have been...... I dunno.....

And... as a followup to previous.... I said it all stopped after a night..... I haven't checked since 4:00 EST but it started again about then..... about the time the PACRIM would be waking up? I think so.... So your original post was right, it's the new Welchia probably..... You just got my little Terrier mind going on something else....

[Tiger Shark]

Ok..... I've been digging..... through tech docs, RFC's and stack implementation docs for Windows and I have come up with the following info regarding RST packets and their use.

The quick and easy description is found on Microsoft's site here. While it actually is discussing unused ports and performance issues in the implementation it's puts the salient points right there.

In short it says that an RST should only be sent if:-

1. It is _clear_ that the incoming packet was not intended for the current connection
2. If the destination port is closed an RST should be sent if any packet _other_ than an RST is received, (if it reacted to an RST it would begin and endless loop).

It further states that an RST _alone_ is not acceptable when a it is received in response to a SYN packet - it _must_ acknowledge , (ACK), the original SYN.

So, the only time an RST packet with _no_ other flags set is acceptable only when it is clear that the incoming packet did not belong to the connection. Otherwise, in the case of a closed port it should acknowledge the inital connection.

That implies that a "bare" RST sent during an ongoing connection is "improper".... (Could we read "evasive").? The only thing it would be trying to do would be a quick close of the connection, (rather than go through the entire FIN, FIN/ACK..... closure of a connection that would conform to the RFC).

How could that be used to someone's advantage and therefore be considered evasive? Well, the first thing that springs to mind is a scan. Make the connection, see the response, kill the connection rather than leave it open..... (I'm guessing here), but I would guess that the half open scan came first, (send SYN, see reaction, move on with no further transmission), and that systems to detect the half open scan followed soon after it's inception. So the next generation of scanners needed to avoid the half open scan. If this is the case a SYN, listen for reaction, RST should close the connection and therefore may avoid the half open connection sensor. Even if the connection was improperly closed the the sensor would be looking for a SYN, SYN/ACK ..... nothing...... and it wouldn't get it, it may not understand that the RST is "illegal" but it would see further traffic thus not conclude a half open scan. I think that could be considered evasive......

That's my best guess at the moment seeing as there is so little definitive information out there regarding the "why's and wherefore's" of an Evasive RST.

This would explain the WebDAV alerts coupled with the Evasive RST's that appear to be being utilized by the Welchia.B too. We all know that Welchia.A was very active and flooded networks with connection attempts. I think B is doing the same but it is using a simple RST to close the connection rather than leave the connection open when it finds a pre-patched machine, (nice of the author..... )