We've been seeing large numbers of inbound "MS Windows RDP Server Abnormal Termination" alerts on a particular interface, originating from many countries, but we're nervous of setting it to block in case of affecting legitmate RDP use on the network (perhaps that isn't the case but testing this even out of hours isn't really possible).
I had been sticking the common sources in firewall rule objects for dropping, but by this point there's so many it's impractical. The majority were blacklisted in spam databases etc, so that would seem to rule out false positives. I could use attack filters although it would need a large number of entries, is there a more effective way to deal with these alerts?
Are you allowing inbound RDP traffic from the internet? You may consider white-listing. Otherwise, yes you will see a ton of brute force attempts on RDP.
The best way to detect a successful attempt is to use the Windows logs on the server - X failed attempts from the same IP Address followed by 1 or more successful attempts from that IP. Most SEM's have the ability to create that kind of logic and generate an alert. Then you know you really have something to worry about.
One thing I have also done before is generate a list of accounts I know I should never see login - guest, admin, administrator, root, etc. Alert on any of those logins, again using the windows event logs and your SEM.
RDP events are generally easier to manage using Windows logs because it will tell you source ip, and the username they tried to login with. This makes it MUCH easier to tell if this is valid activity or not.
I notice this problem as well, but am unable to determine the root cause. If you read the signature details, this particular signature is "supposed" to only be triggering when an RDP session is active and is terminated "abnormally" where a specific sequence of bits is seen in the packet that represented an older DoS condition that would crash the RDP host machine.
I have seen this signature also fire during Qualys vulnerability scanning during the initial reconnaissance phase, so am highly curious if anyone finds a root cause for this traffic. I am an outsider without access to the systems generating the behavior, making it very difficult to see any local logs or simulations.
I personally don't find this "attack" to be that interesting and have debated creating an attack filter for it, if detected between trusted internal networks. from what i can tell, this event happens through the course of normal IT operations. now if this event was detected inbound from an external network or was detected in a connection across security boundaries, that would be a differnt story. but this event is not really useful IMO when detected across internal trusted networks.