LulzSec: The 50 Days of Hacking in 2011 and the SQL Injection Lesson

In the summer of 2011, a small group calling itself LulzSec seized the attention of the internet. Over a period of about fifty days, it broke into or disrupted a string of high-profile websites, published stolen data and mocked its victims on social media. Its attacks were not technically brilliant. That is exactly why the story still matters: much of what it exposed was basic, avoidable and still common today.

Who they were and what they did

LulzSec emerged in May 2011, with the name combining "lulz", slang for laughs, and "security". Its first notable targets included the television network Fox and, later, PBS, for which the group posted a fake story claiming a dead rapper was alive in New Zealand. It also targeted the game company Bethesda and the United States Senate website, from which it published files.

The group's biggest haul came from Sony Pictures. LulzSec said it took personal details of around a million users using a simple SQL injection attack, and noted that many of the passwords were stored as plain, readable text. It also posted information from other targets, claimed responsibility for knocking the CIA's public website offline and attacked the Arizona Department of Public Safety.

SQL injection in plain terms

SQL injection happens when a website passes input from a visitor, such as a form field or a URL parameter, straight into a database query without checking it. A visitor can then add database commands of their own, and the site obeys them. The result can be reading, changing or deleting data that should be private.

The cause is almost always the same, and so is the cure:

• Use parameterised queries, also called prepared statements, so that user input is never treated as part of the command.
• Validate input and limit what the database account used by the website is allowed to do.
• Keep your CMS, plugins and frameworks updated, since most of them fix injection flaws when found.

Plaintext passwords

The Sony Pictures leak also showed another basic failure. Passwords were stored without hashing, meaning anyone who obtained the database could read them. Because people reuse passwords, a leak at one site becomes a risk for the same users on many others. A properly hashed and salted password, using a slow algorithm designed for the purpose, forces an attacker to spend far more effort for each one.

How it ended

On 25 June 2011, after roughly 50 days, the group announced that it was disbanding. By then law enforcement agencies in several countries were investigating. In the following months, arrests were made in the United Kingdom and the United States. Hector Monsegur, known online as Sabu, was identified by the FBI and arrested in June 2011, and he then cooperated with investigators. Several other members were later convicted in the UK and the US.

A year of attention to security

LulzSec belonged to a wider wave of activity in 2011 that included Anonymous and attacks on security firms. Together these incidents showed that companies of any size could be embarrassed by relatively simple techniques. Many organisations began to review their web applications for common flaws and to adopt guidance such as the OWASP list of the most critical web application risks.

Why the group got away with so much, for a while

LulzSec did not rely on rare zero-day flaws. Its claims suggested that it simply tested many sites for well-known weaknesses and picked those that gave in. This is an important point for anyone who thinks their site is too small to matter. Automated scanning tools do not care about the size of a business. They look for a vulnerable form, an unpatched plugin or a weak login, and they try it everywhere.

The group also made use of public embarrassment. It posted stolen data openly and boasted about each success, which drew media attention and encouraged copycats. For the victims, the damage came in several forms: the leak itself, the loss of customer trust and the cost of investigating and fixing the problem afterwards. Several affected companies had to notify users and reset passwords.

The episode is also a reminder to review old, forgotten sites. Promotional microsites and legacy databases were among the weaker targets in many incidents of this period, because nobody was maintaining them. If a site is no longer needed, take it offline instead of leaving it running unattended.

The practical lesson for site owners

Most small sites run on a CMS such as WordPress, which means the key actions are to keep it updated, delete plugins and themes you do not use, and choose well-maintained ones. If you or your developer write custom code, insist on prepared statements for every database query and never store passwords in readable form. Give the database user only the permissions the site needs.

Consider a layer in front of your site that can filter malicious requests; our Cloudflare CDN option is available on hosted sites, and our security page has more on the protections available.