Sluter

\[Editor's Note: Share your security discoveries, comments, problems, solutions, and experiences with products. Email your contributions (500 words or less) to [email protected]. We edit submissions for style, grammar, and length. If we print your submission, you'll get $100.\]

Some months ago, the Sluter worm hit my company. Sluter is best known for exploiting weak administrator passwords on servers; the variation that hit us launched a brute force password attack against our logon domain. But our problem was more extensive than a few guessed passwords. Our domain policy is that after five unsuccessful password attempts, the user account is locked until a Help desk operator unlocks it. Within an hour, we had thousands of locked accounts.

A quick look at the domain controllers' (DCs') Security logs showed us the attack's point of origin, and we immediately took the affected machine (a contractor's laptop) off the network. To prevent having to manually unlock every user account, we wrote the script that Listing 1 shows. This script unlocks every account in the domain. The script doesn't check to see whether an account is locked, because unlocking an already unlocked account doesn't cause problems. We promptly had all the accounts unlocked.

A few weeks later, we experienced the same type of attack. We immediately launched the script and quickly had all the accounts unlocked—or so we thought. Users started calling the IT department complaining that their accounts were still locked. We soon realized that we had launched the script before removing the offending device from the network and the script had outpaced the worm. Oops.