Cyber Security Awareness Month is over and with it the SQL Slammer Clean-up Exercise. While SQL slammer is still very much present on the Internet, many unstated goals of the exercise were met. There was a bit more going on behind the scenes that I would like to now share.

Why an exercise?

Firstly, why have a CSAM exercise? Quite a bit of effort goes into the CSAM daily topics over and above the daily Incident Handler's tasks. Some thought that this exercise should have been put off until November. I wanted to have something during the month that technical, non-policy-makers could participate in. It was intended to be a Technical Track to supplement the Policy Track. Also, I wanted to experiment with a new Handler Diary format, linking together a number of articles produced while I'm not actually the Handler of the Day.

Games are great way to teach people, it gets them involved, and there are few methods that teach a skill more effectively than actually doing it. The exercise was modeled as a game. It has boundaries, a beginning and end, and a way to keep score. This particular game was co-operative (although I suppose you could consider it as "Us" versus Slammer,) the boundary was the Internet, it started October 1st, 2010 and ended November 1st, 2010. For the purposes of scoring, I'm using my darknet sensors and a single snort rule to determine a Slammer attack from a simple MSSQL scanner (more on scoring below.)

Why slammer?

SQL Slammer was chosen as the exercise target for a number of reasons. Although it is well-understood (http://www.sans.org/security-resources/malwarefaq/ms-sql-exploit.php,) it was chosen largely due to its ubiquity. There are very few networks that don't see these packet on their perimeter-- this meant that everyone could participate. Unlike other bot-nets and malware in recent circulation, there isn't a criminal organization behind it, so there should have been little risk for the participants.

My expectations

When I proposed this idea to the other Handlers, I was cautioned to not set my expectations too high, or make a wild claim or promise to rid the Internet of SQL Slammer in a month.

My expectation was to get perhaps 30 people or so involved and if we were really lucky and/or diligent we might get 4 to 5 of the top-talkers cleaned up.

Skills we developed/exercised

Now, for the insidious ulterior motive of the exercise. The primary intent of the exercise wasn't the eradicate SQL Slammer-- it was to get people looking at their logs again, and manually participating in the abuse reporting process. There's been too much reliance upon automated reporting, and the automated response to reports. It's just too easy to fire-and-forget with an abuse notification. Some organizations even set up XML services like ARF-feeds (Abuse Reporting Format see: http://www.shaftek.org/publications/drafts/abuse-report/) so you can have everything handled automatically. With the right infrastructure, this can be quite effective, but I think we can all agree that if a network has Slammer running loose on it, it probably lacks the infrastructure to support ARF.

I hope that the participants looked at their logs differently than they usually do, or that people who would normally quietly watch and study an event instead picked up the phone and contacted someone to get a system cleaned up.

Also, we learned a bit about what it's like when the shoe is on the other foot, when someone else is trying to contact us. Perhaps you found found something in your own WHOIS or abuse contact information that needed to be cleaned up.

At the very least, participants had to develop or exercise the "contact a third party" part of their incident response process. Did that run smoothly? Did the use of the spreadsheet to track the notification and response help you capture effective metrics for your process?

Finally, the results

If you pull up port 1434 on DShield it looks like the exercise did more damage than good. It started off the month with a low outlier of 165 sources and ended the month with an average or 235. the problem with the DShield data is that TCP and UDP are merged in that particular report. For scoring this exercise I'm relying on my own darknet sensors that monitor a couple of /16 netblocks. It has the advantage that I know that the monitored space and number of sensors hasn't changed in during the course of the exercise and I have full packet captures so that I can create alerts on only Slammer packets and rule out any other UDP/1434 traffic that may be present.

The Snort signature that I was using for the exercise:

alert udp any any -> any 1434 (msg:"W32.SQLEXP.Worm propagation"; content:"|68 2E 64 6C 6C 68 65 6C 33 32 68 6B 65 72 6E|";
content:"|04|"; offset:0; depth:1;) My sensor saw a similar distribution of infected sources.  October 1st saw a low of 54 IP addresses and ended the month with 79.

The question remains: did I see any of my repeat visitors go offline during the exercise?

I filtered the results down to all of the IP addresses that visited more than 10 days in October, which gave me 47 systems to plot out over the month. Nearly 13 look to have gone potentially-silent during the month. I base this on the number of systems that don't have a mark present on the last few days of the month.  On the other hand there appear to be 2 that were potential new-infections. This sent me off on a focused analysis of just those two systems, the first (in Algeria) appears to be new visitor to my sensor, while the second has been a regular visitor for a long time, typically 4 to 7 visits a month.

Things I learned

Like any worthwhile exercise, I too learned a thing or three from the process. I was introduced to NFSen (http://nfsen.sourceforge.net/) and Abusix (http://abusix.org/)

One thing that I would have changed in managing the exercise is that we should have set up a role-base email address to handle the correspondence. This would have made tracking the participants of the exercise much easier and allowed me to organize and prioritize the emails more effectively.

Previous articles

Each entry was tagged for convenience and are available here: http://isc.sans.edu/tag.html?tag=slammercleanup

Cyber Security Awareness Month Activity: SQL Slammer Clean-up (http://isc.sans.edu/diary.html?storyid=9637)
SQL Slammer Clean-up: How to Report (http://isc.sans.edu/diary.html?storyid=9664)
SQL Slammer Clean-up: Reporting Upstream (http://isc.sans.edu/diary.html?storyid=9712)
SQL Slammer Clean-up: Picking up the Phone (http://isc.sans.edu/diary.html?storyid=9778)
SQL Slammer Clean-up: Switching Viewpoints (http://isc.sans.edu/diary.html?storyid=9811)
SQL Slammer Clean-up: Contacting CERTs (http://isc.sans.edu/diary.html?storyid=9841)
SQL Slammer Clean-up: Roundup and Review (http://isc.sans.edu/diary.html?storyid=9871)