We’ve decided to write an “incident of the month” feature to highlight the unseen work that Janet CSIRT does. These articles won’t feature in depth technical or forensic analysis of the latest threats, but we do hope to provide an insight into how a Incident Response team operates. The recent STRATFOR hack was mentioned in the latest edition of Janet News, and that provides as good a starting point as any.

On Christmas Eve the hacker collective ‘Anonymous’ accessed the web servers of STRATFOR, a Global Intelligence think tank based in Austin Texas, and copied 200 gigabytes of data. The account details of approximately 860,000 subscribers have been compromised following this attack including passwords used by 1,500 Janet users at 200 sites. The account details were quickly uploaded to pastebin.com and other distribution sites. The timing was unfortunate and occurred over Christmas during our reduced working hours. By the time we were able to investigate the original source of data had disappeared.

In early January the data had reappeared in an easier to digest form where anyone could quickly search through the large volume of data to pull out only relevant account details. We were able to extract over 1,500 accounts with e-mail addresses in .ac.uk domains, and began to process them.

Dealing with large incidents that affect hundreds of customers presents a dilemma. Should the entire event be considered as a single incident in our incident handling system, or should each customer be allocated their own incident? Handling the incident per customer allows us to better triage our workload according to the needs and requirements of each customer and so this is the approach we usually opt for. Considering the event to be a single incident is perhaps conceptually tidier and more “correct”, but can quickly become cumbersome.

Automated scripts match the e-mail addresses in the data to specific customers which is not a simple task. Institutions can have long and short form domains, as well as a large number of domains belonging to departments and projects. The script created tickets in our incident handling system and dispatched e-mails containing details of the incident to each customer. As soon as replies started arriving from customers, these incidents are manually handled just like any other. The number of incidents we were handling more than doubled during this period.

By the time the information had reached us, some of the compromised data had already been abused. Since many people reuse passwords across many systems, e-mail accounts were easily accessed. These accounts were quickly secured when we alerted institutions to this risk. Some of the data also contained credit card details. These had been quickly abused and most people had already been notified by their banks of fraudulent transactions. Thankfully most in the majority of cases people just had to have a long hard think about how they chose and use passwords.