Targeted Attack, Long Investigation, Dead End

I am currently enrolled in an upper division class on information systems security focusing on the CISSP examination. The class is part of a program certified by the National Security Agency and Department of Homeland Security as a Center of Academic Excellence in Information Assurance. Since cyber crime and electronic security are becoming such everyday topics – especially e-commerce related – I thought many of our readers might find it interesting to read some of my papers from the class.

The first assignment was to describe a security attack that I had experienced or been a part of. I describe a situation I was in as a small hosting provider who was defaced by a targeted attack against one of my clients.

The story goes back almost a year now (and is still being added to every day.) The story goes across 4 states and three nation’s borders. Until you’ve done a cyber investigation, you really have no idea how difficult situations like these can be – I sure didn’t have any grasp of it going in, but I have learned lots from the process.

I own a reseller web hosting account with a company based in Orlando, Florida and this allows me to do design and development services for small business clients across the country with the added advantage of bringing the hosting into a controllable environment. I host around 12-15 clients on the account and have a pretty close relationship with each one.

In October 2008, I had just put a test version of a site up for a client on his brand new website. About a week after posting it, I received a phone call from my client to inform me that a former associate of his had visited the site and he was worried we may get attacked. Wondering how my client knew a former associate had been on his website, I started looking into the stats when I noticed the same thing my client did: the person was on a static IP address that was registered to a company he used to own. This person was my client’s former web developer and they had a very bad disagreement before going their separate ways. This disagreement included the developer suing my client for somewhere around $12,000 and my client counter-suing for the rights to his website.

The judge decided that my client did not owe the $12,000 and that the old developer needed to give my client a disk of his files. Needless to say, the former developer was not happy – he also happened to be the kind of person who likes to get revenge.

Since my client’s new site had not been publicly announced, I was curious how this guy found it – and soon found out. He had come from a referring address of Google, with a search of my customer’s name and the domain name. Red flags went off everywhere, so I set a nice little trap for him the next time he arrived.

A little bit of PHP and JavaScript later, I had a script that would give a red screen with a nice little warning message, two sets of 999 JavaScript alerts, and a notification script to send me both an email and a text message when this IP address visited my customer’s site. The first time the person saw the script, it was obvious (and hilarious) to me that he was not very happy – you could tell by his visiting pattern.

I sent an alert to my hosting company to alert them to watch for the IP address coming in on any port other than 80 and to look for any abnormal activity. They monitored the server for 48 hours and ended up giving up after no unusual activity was discovered. I also took down the red screen and chose to passively monitor him instead, leaving the text and email alerts in place.

Over the next few months, I would get texts off and on, would find a computer to make sure everything on my server was okay. So far, everything was – but that all changed in January during an SGA meeting. My phone buzzed four or five times, indicating activity. 16 minutes later, I had a text from a different customer, who informed me his site had been hacked. Out of instinct, I sent a text to a good friend to check the sites, as I had no computer during the meeting. Pretty soon, my friend replied that it wasn’t isolated to the one customer, but it had affected all customers on my account.

Initially, I didn’t put two and two together. I sat there and wondered what had happened. That was an important lesson – never be complacent or routine with security. After the meeting concluded, I went up to talk to a fellow Senator when it hit me like a brick – it wasn’t an accident that my phone had gone off 16 minutes earlier, that alert was there for a reason.

I rushed home to pour over the logs and notified the client who had alerted me about this guy. After reviewing the logs and speaking with security and abuse at my host, I determined I probably had enough to go on, and I called the Hays Police Department. This was at 9:06PM – and the fun really started here.

This is when I was introduced to what law enforcement calls “jurisdictional issues.” Hays Police Department said “We don’t have jurisdiction, it would be the job of the police in the town where the crime was executed in.” In computer crime, that can get interesting. Just in my case, it appeared the attacker had gained control of a computer in Canada, owned by a California ISP and co-location provider, which was used to attack my server in Orlando, Florida. I – one of thirteen victims – was in Hays, Kansas. The suspect was in Butler County, Kansas. The twelve other victims were scattered across the US.

Over the course of the next 20 hours (yes, I pulled an almost all-nighter, got about two hours of sleep the first night) I spoke to 5 different law enforcement agencies and discovered two major things: 1) 50% of detectives I spoke to did not know what a server was and 2) Of those who did know what a server was, 50% knew where I needed to go. Credit should be given to Brad Rickey at the Ellis County Sheriff’s Office for pointing me – finally – in the right direction in contacting Orlando Police Department and asking for computer crimes/fraud detective. The guy there was absolutely awesome, and actually went onsite later that day to check on things. I mailed him 50-75 pages of documentation, only to discover a day after he got the documents that the servers were housed in a suburb outside of town and he no longer had jurisdiction in the case either. He handed the case over to a detective in the small suburb, who didn’t know what a server was, and the ball was dropped.

Finally, when we had the jurisdiction nailed down to the right place, we were not able to make anything happen. It should have been a slam dunk case – the two endpoints made perfect sense and there was enough documentation to nail the case down, but when it came down to it, the ball was dropped and we were not able to make headway.

Lessons learned:

– More detectives need to be trained to respond to cyber crimes

– Law enforcement relies on you to build as good of case as possible, and they will provide assistance, but only if they think they have jurisdiction in the matter

– Federal law enforcement doesn’t care about you unless it involves credit cards or more than $10,000 physical loss

– It is tough to determine loss on virtual assets

– Cyber Crime, even if you have the two endpoints and just have to connect the dots, can be extremely difficult. This is unnecessarily difficult, in my opinion

– Evidence needs to be collected in accordance with strict handling guidelines that will hold up in court

– Cyber Crime jurisdiction needs major clarification and more openness

– More Federal assistance to state and local agencies is necessary to help relieve some of these issues until more detectives can be trained to handle the crimes