Sudden increase in MSRPC, UPnP alarms

greymanZIP · ‎10-31-2008

As of Wednesday, our SSM IPS system starting picking up a large amount of hits against rules 3327/8, 5799/6, and 6131/6 (sig set 364). These rules are related to the MS Server Serivce, MS RPC, and UPnP services. All of these came from our VPN users in to our internal DC's, file, and print servers. At first, we immediately blocked these users from the network and began incident investigation procedures as it seemed as if these machines were attempting to compromised internal hosts using the MS08-067 vulnerability released last week. Our initial investigation of some of the machines involved and of the network traffic between these machines and the internal hosts showed no signs of malicious activity. Also, the timing of the alerts - all alerts started right around 2pm EST on Wednesday and continue till today for the majority of VPNed Windows hosts - suggest that this is not malicious activity, but rather a false positive condition in the signature.

Our question is: What could have caused a system to arbitrarily start throwing alerts for this type of traffic? We are trying to determine whether this is a "problem" with our IPS in that it just happens to have started flagging this traffic as malicious or if there is something on our internal systems that may have changed to cause a behavioral change that is now seen by the IPS signatures as malicious while truly not being such. I'm not an SMB or RPC protocol expert, so some of this is beyond by realm of knowledge. It does appear from the packet captures, though, that the connections to named pipes, which is what seems to be triggering most of these alerts, comes arbitrarily in the middle of normal SMB activity such as file reads and searches.

If any one has any light they can shed on this or any other similar experiences it would be greatly appreciated.

wsulym · ‎10-31-2008

When did you apply s364? And were there any config changes recently?

The sigs you mention haven't been touched since (most recent of all three) s303. All three are components to meta signatures and by default are set at "informational" and carry an sfr=60, AND, since they are components to a meta signature, they do not by default produce any external alert. In general, meta-components by themselves don't necessarily indicate malicious activity.

Just kinda thinking here that maybe its not some odd traffic pattern or worm or something changing on your network, but could there be a chance that there was a change made to your sensor and the signatures themselves that would have turned "produce-alert" on for the sigs you mention?

greymanZIP · ‎10-31-2008

The 364 sig update was applied on Monday soon after it was posted, so we went about a day and a half or so without seeing anything. We have not changed the state of these signatures beyond the default which they ship. MARS is rating each of these alerts as RED severity despite the fact that it is the meta signature that is being tripped.

I'm 100% certain that we didn't change anything else in regards to these signatures, since I am the only person with access to these units :) The only changes made were done after the alerts began and that was to change the default action over to Deny Attacker Inline when our initial assumption was that the traffic was malicious.

What was the signature added or modified for MS08-067?

wsulym · ‎10-31-2008

7280-0, 7280-1 are the ms08-067 sigs.

Check them on the sensor itself, make sure that they are still set @ informational, sfr=60. Produce-alert should *not* be set (which is the default) - MARS shouldn't have seen those alerts if they were running at defaults.