Cisco Support Community
Community Member

Detecting breakins as opposed to mere hacking

What I would really like to see are signatures that report a successful SMB login after a number of failed logins from the same source. I see for example large numbers (1000's) of 6255 SMB Authorization Failure alerts. If someone from one of those source addresses successfully logs on, then it is almost certainly a breakin. At the very least, it would be much more useful to know "successful SMB login after nnn failures" than "login denied". The first case is a probable security failure, while the second is merely security operating successfully.

/Chris Thomas, UCLA

Community Member

Re: Detecting breakins as opposed to mere hacking

Just wondering WHat is the workaround? Any update on this?

Would like to know how to manage situations like this...

Cisco Employee

Re: Detecting breakins as opposed to mere hacking

Chris, I've been looking into your suggestion. Currently, 6255 fires when HitCount events failures occur withing ScanInterval seconds between a unique pair of IP's. HitCount and ScanInterval being the two configurable parameters for 6255.

The problem I see with your request is that if the "attacking" box is actually legitimate (is a multi-user box with a bad actor logged in besides good guys, a compromised box with a bad process amongst a legit users's normal ones, etc...) then there is a false positive potential as the bad actor causes 6255 to fire and the legit user(s) successfully login/connect.

This is based on the assumption of IP A -> IP B traffic where the source ports are changing. In your experience with known bad actors, do the source ports cycle between bad access attempts?

Scott Cothrell

Cisco Austin

Community Member

Re: Detecting breakins as opposed to mere hacking


sorry for the delay. I'd been trying to gather some data. However, due to Blaster and all the follow-on excitement of the last couple of weeks, we've firewalled all the windows ports (135-139) outboard of where my IDS is, so as a result, I'm not seeing login hacking any longer.

My recollection is that the attempts were coming from the same port, but I wouldn't place too much emphasis on this, as I wasn't really paying attention.

It seems to me that many of the non-basic alerts have false positive potential, and can't just be enabled for all customers out of the box. However, there is also the potential to detect significant intrustions in some environments, and that to me makes these types of alerts useful. In my case, I am thinking of a single user (ie, server) machine that is being beaten on for days at a time by a bad uy trying to guess passwords. As far as I can tell, he is the only user on the attacking machine. I would really like to know if after tens of thousands of failed attempts, anyone from that address ever successfully logs on.



Re: Detecting breakins as opposed to mere hacking

The big problem from an IDS perspective, for your request, is how to track login events and for how long. IDS platforms typically operate under tight memory and processing ceilings, so we have to be careful about how much stateful information we are tracking. From a security standpoint, it would definitely be desirable to know when a brute forcing attempt succeeds, but given real world constraints this may not be practical for an IDS or adminstrator. A compromise could be to tune signature 6255 to an acceptable level for your environment and enforce a password locking scheme for your hosts. You get tipped off to the brute forcing activity two ways and keep the bad guy out.

CreatePlease to create content