Windows RPC DCOM Overflow events

[rsumidacisco]

New IDSM2 installation here. Just got them to work last week so no real tuning done yet. They are running in promiscuous mode with software version 5.0(5sp2). We are using CN-MARS 4.1 to collect events.

I'm seeing a lot of RPC DCOM overflow events sourcing from systems that are likely not compromised. The interesting thing is that the destination of most of these RPC DCOM overflows are all going to the same system that I am very suspicious of. Am I reading these events incorrectly? Is the destination address for this event actually the attacker? I've already had one instance where the IDSM2s reported a SMB auth failure with the source and destination reversed.

Has anyone else run into these types of issues before?

Lastly, what type of “normal” traffic, if any, would trigger the Windows RPC DCOM Overflow signature?

Thank you,

Ryan Sumida

[craiwill]

Which sub-signature id is firing?

[rsumidacisco]

Hi Craiwill,

How do I find the subsig? The MARS raw event message shows

TCP Windows RPC DCOM Overflow,NR-3327/6,Port List:139,Risk Rating:65,VLAN:256,Context:AAAAeP9TTUIyAAAAABgHyAAAAAAAAAAAAAAAAAc40AQAMESyDzQAAAACAEAA AAAAAAAAAAAAADQARAAAAAAAAQAFADcAAAAA7QMAAAAA:

I'll do some searching around on the IDSM2s but where do I look to find which one is being firing?

Thanks,

Ryan

[rsumidacisco]

The subsig ID is 6

Windows RPC DCOM Overflow 3327.6

Thanks,

Ryan

[craiwill]

This may be a false positive. You can either filter out trusted hosts or create a metasignature using this signature as a component to reduce the chance of false positives.

For example:

Tune signature 3327-6 and remove the produce alert action.

Create a custom signature as follows:

Engine Meta

Component list:

3327-6

3328-0

Meta-reset-interval = 2

Severity high

Summarize

Met-key = Axxx – 1 unique victim

Component-list-in order = false

Event action: produce alert

This signature will only fire when signatures 3327-6 and 3328-0 fire. Since 3327-6 would have no event action of its own you would not see alerts from it.

Note that this signature does not have as high fidelity as the original 3327-6, that being said signature 3327-0 detects almost all public exploits for this vulnerability.

[jcosgrove]

I get a lot of what I think are false but it is not subsig 6. Looks like mine is subsig 0

Any thoughts?

Details

Sig Name: Windows RPC DCOM Overflow

Sig ID: 3327

Severity: High

Risk Rating: 100

Sig Version: S188

Attack Type: Code Execution

OS Family: Windows

OS: General Windows

Protocol: tcp

Protocol Details:

Service: MSRPC

Attacker Address: xxx.xxx.xxx.xxx

Attacker Port: 1438

Attacker Loc: PubIN

Attacker Unreliable: False

Victim Address: 172.16.8.10

Victim Port: 445

Victim Loc: PrivIN

Local Date: Thu, Jan 26, 2006

Local Time: 02:57:22 PM

Time Offset: -300

Time Zone: EST

Response

IP Logs: False

Trig Pkt Created: False

Connection Block Requested: False

Host Block Requested: False

Deny Packet: False

Deny Flow: False

Deny Attacker: False

Would've Denied Packet: False

Would've Denied Flow: False

Would've Denied Attacker: False

TCP Reset: False

Resolved: False

Reporting Chain

Sensor Name: IDS-C5829

Orig App Name: sensorApp

Orig App Addr: 172.17.201.2

Orig SecMon Addr:

Original SecMon ID: 0

Downstream SecMon ID: 0

Context

Attacker Context: )SMBC9 h&@)SMBe| h)@)SMB{!fdj i'@)SMBOF.w Si(@SMB% ^S ihThT&*@y

Victim Context: ]D

> g#SMBi>

h#SMBB'H Sh#SMBd%

,t h#SMB}c`g h#SMB1C i#SMBot

Si

[craiwill]

There is not enough data from the alert context buffer to determine if this is a false positive. That being said, it would be very hard to imagine a situation that could cause this signature to false positive. I would suspect that this is a real attack.

[rsumidacisco]

Thanks craiwill. This looks like it will cut down on a lot of the "noise" for the RPC DCOM overflows. I created the custom sig and will deploy it later tonight. Thank you for your assistance. Much appreciated.

Ryan Sumida