The case of the Phantom Hacker
It’s another quiet day in the Secret Underground NSM Bunker. The lights on the enormous world map at the far end of the cavern are blinking green, my army of orange-boiler-suit-clad underlings are hard at work on my next diabolical scheme, and the persian cat on my lap is purring contentedly. Martini-drinking spies are nowhere to be seen.
Out of the blue, the cat’s ears prick up and she starts to hiss. Seconds later, a security alert is raised (why have an IDS when you can have a cat?). Because we’re collecting logs as well as traffic data, we can tell pretty quickly when an account is locked out due to too many failed logins. It’s usually a fat-fingered user who will shortly be calling the helpdesk, but today it’s not. Today it’s one of the domain admins. Now admins can have a fit of fat-fingeredness too, but equally someone could have tried to brute force a login into a privileged account. We need to find out which it is.
A quick call to the admin’s desk reveals that he’s not there – he’s been out of the office for the last hour, and his computer appears to be off. Furthermore, one of the admin’s colleagues has had sight of the admin’s machine for the entire time, and nobody has been near it.
So, how has a powered-down computer managed to attempt a login without anyone actually physically being near it? I can’t ask the cat, because she’s run off and is hiding behind my latest prototype doomsday device. It’s time to mine all of that information we’ve been collecting, and as logs were the trigger we’ll start with these:
- The “account locked out” message came from a domain controller, and was preceded by the proper number of “login failure” messages.
- All of these messages cite the admin’s machine as the computer that was used for these login attempts. We hope these messages are trustworthy, otherwise we’ve got much bigger problems (i.e., someone is messing with machine accounts and server event logs).
- The login failed messages all say that an interactive login was attempted locally – it wasn’t a remote desktop session or other network login (SMB, etc.).
There are two ways in which a local interactive login can be attempted. You can either sit at the machine and try it, or you can use some remote-access software like VNC that only does screen-scraping rather than interacting with the foul guts of Windows. We can rule out the former, assuming we can trust what the admin’s colleague has told us. We’ve got an NSM sensor at the network’s border, so we can see if the admin’s machine is being contacted over the Internet.
A few quick queries later, we can see that there has been absolutely no Internet-bound traffic either to or from the admin’s machine since they logged out and left for lunch. This isn’t the most favourable outcome, since the alternatives are:
- There’s a physical backdoor to our network somewhere that someone is using. A modem or a 3G phone or a rogue AP or something (wireless is not permitted at all at this location so if wireless is involved it’s not an authorised device)
- It’s an inside job – the attacker is either inside the building right now, or has just made their getaway. This would be irritating, not least since our NSM capability only covers the network’s borders – if it’s an inside job, NSM won’t have caught it at all.
The cat is now trying to force open the covers of the doomsday device in order to set it off… Bad kitty!
The orange-clad goons are busy mobilising to secure the admin’s machine for imaging and forensic examination when we get wind of an interesting new helpdesk ticket. Apparently, someone is having trouble with their new keyboard. Their new wireless keyboard.
A penny rolls towards a precipice and gets ready to drop, and the cat heads off to her dish of cream – always a good omen.
It turns out that a few people had taken delivery of wireless keyboards that morning. The admin was one of the recipients, and had set his up, logged out of his machine, and gone to lunch. A little later, someone else had unpacked theirs. They turned on their machine, and waited for it to boot. Not being a touch typist, they dropped their head to their new toy and hit control-alt-delete, and then hit tab to skip from the pre-populated username field to the password field (bad policy! naughty policymaker!). Still with head down, they typed their password and hit return.
Looking up at the screen they saw that it was still prompting for control-alt-delete, so they repeated the process. Several times. They finally hit the keyboard’s “sleep” key to no effect before getting the old keyboard back and raising a support ticket.
Now I’m sure you’ve all worked out what was going on here (the cat certainly had). The user’s new wireless keyboard was on the same channel as the admin’s, and all his keystrokes were driving the admin’s machine, eventually switching it off. Cue much debate about the merits of wireless keyboards…
Case closed, the cat returns to my lap, the orange-clad goons get back to their diabolical tasks, and all is well in the Secret Underground NSM Bunker….
Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters(at)dataline.co.uk