How the EA hack happened: a $10 stolen cookie and a lost-phone story

The break-in at Electronic Arts reportedly started with a $10 purchase: a stolen login cookie that let intruders into the company's internal Slack chat.^[1][2] This case file covers how a friendly message to IT support turned that foothold into about 780 gigabytes of game source code, how the extortion attempt played out, and the one control that would have stopped it at the help desk.

What happened

How they got in

A cookie is a small file your browser keeps so a website remembers you are already logged in. If someone copies it off an infected computer, they can sometimes use it to appear as that person without knowing the password. Stolen cookies are traded in bulk on criminal marketplaces, and the hackers said the one they bought opened a Slack workspace used by EA staff.^[1][5]

Slack access alone did not reach EA's code servers. For that, the network required a second login factor, the kind of one-time code or token normally tied to an employee's phone. So the intruders, posing as an employee, messaged IT support and said they had lost their phone at a party. Support issued a multifactor token. By the hackers' account it worked twice, and the tokens let them onto EA's corporate network and to the systems that held source code.^[1][2][3]

Note what was not needed: no clever break-in of EA's servers. A believable story in a trusted chat channel did the heavy lifting, and a help desk trying to be helpful did the rest.

What it cost

EA said the incident would not affect its games or its business, and no customer records were taken.^[2] The damage was to its intellectual property. Source code for a best-selling game and its engine was dumped publicly, which security writers warned could help people build cheats or probe EA's games and servers for weaknesses.^[3][5]

The hackers failed to get the $28 million they asked for, and EA did not pay the later extortion demand.^[5] No arrests have been publicly reported in the sources reviewed for this case file, and the people behind it have not been named by authorities.

The missing control

The missing control: verifying identity before resetting or issuing multifactor credentials. The help desk accepted a lost-phone story from a chat account and handed over a new second factor, without confirming the requester through a separate, trusted channel.

Multifactor login exists to stop exactly this kind of intruder, who has one piece of an employee's identity but not the rest. A reset process that trusts the chat message defeats the whole point. If support had called the employee back on a phone number already on file, checked with their manager, or required a live video check with ID before issuing a token, the story would likely have fallen apart. Security experts commenting on the case recommended the same thing: confirm the request through a second communication channel before granting access.^[4]

What to do in your business

• Write a lost-device rule. Decide in advance what someone must prove before IT resets a password or multifactor device, and make it the same for everyone, including the boss.
• Call back on a known number. Never verify a request using contact details supplied in the request itself. Use the phone number in your staff records or confirm in person.
• Treat chat as untrusted for access requests. A message from a colleague's account is not proof it is the colleague. Require a second channel for resets, payments and new access.
• Tell staff when their access changes. Set systems to alert the employee by email or text when a new device or token is added, so the real person can raise the alarm.
• Keep sessions short. Ask your IT provider to shorten how long logins stay active and to sign everyone out after a reset, which makes a stolen cookie go stale sooner.

Facts are drawn from court records, government reports, company statements and reputable reporting, listed below. People are named only where they were convicted, pleaded guilty or spoke publicly in an official role.