The latest Electronic Arts (EA) Hack is nothing new. Source code and proprietary software got stolen… just another day in cybersecurity.

However, what was interesting was how the attackers gained access to systems. Even more intriguing was the marketplace of where they obtained those credentials. This post will not go into the details of the hack, but more importantly discuss ways you can prevent or minimize the impact of such an attack.

This post was supposed to be brief, but I ended up going down some rabbit holes. Part of security is educating and informing others so they can make the best decision.

What exactly happened in the EA Hack?

Here is the TL;DR of what happened:

• 780 GB of Data was stolen

• Source code to Fifa 21 was obtained

• Frostbite Engine - Software to make other games such as Fifa and Battlefield

• Multiple API Keys and other software obtained

For additional narratives of the attack written by professional journalists, you can go here, here, and here.

How Did The EA Hack Happen?

Ok, so we’ve talked about the what happened, let’s dig a little into the how1.

Let’s try to quickly go over some of what we know happened:

Access To Slack Workspace

Attackers gained access to EA’s internal Slack workspace, an internal chat and messaging tool2. From there a lot of context can be gleaned and searched for from various channels, including links and hostnames to systems, or even API Keys and secrets if engineers and admins practice poor hygiene. It can be a treasure trove.

This access was obtained via the Genesis Market, an underground market of valid cookies from across many platforms. This is a full service marketplace, with their own ticketing and support systems, and plugins/software designed to make it easy for you to masquerade as a user. It’s mind blowing, but a reflection of many underground marketplaces, where they seem and are run like regular businesses. Details on the market from F5 are here.

Note: Although most article point to access to Slack systems, it seems that access to valid corporate identity tokens (like Okta, Google, or Onelogin) were obtained. Reason is how the next step executed and how the articles are worded. This is just a hypothetical assumption at this point. If anyone knows more, plmk.

Password Reset Flow Attack

With credentials in hand, the next step the attackers needed to execute was bypassing MFA. Well, since you can’t really “bypass” MFA requirements, the next best thing is to social engineer. So the attackers social engineered IT Support admins and managed to reset the MFA token. In fact, it happened two times.

This is not new. Many of the steps executed above remind me of the Twitter Hack where attackers social engineered employees.

How To Prevent An EA Style Hack?

Any good security person will tell you that nothing is 100% preventable.

However you can definitely implement all types of measures to prevent at least reduce the impact/likelihood of successful attacks. That’s the name of the game.

If you look at all the items listed above, was there anything there really sophisticated?

No.

Only exception is Genesis Market and the turnkey ease of obtaining credentials.

However, as you can see the attacker had to go through a series of steps before obtaining their objective. Anything we can do to stop them or slow them down, is helpful and part of a defense in depth approach. No silver bullets.

For the more part of this piece, I’d like to detail all the steps one could take to prevent such an issue.

Context Aware Identity / Zero Trust

Context is everything. So when you login to a system, the metadata around your login matter. Some things a context aware identity system would consider are:

• IP History (current vs previous)

• User-agent

• Location changes (Did you suddenly now login from 2000 miles away??)

Having strong context awareness for logins is important in this day and age.

MFA was so 2020.

Depending on your provider, you can even have different controls per application.

Need access email? Ok, maybe not so strict. Accessing Slack?.. ok, let’s up the ante. Accessing AWS? Well, no you need to really prove you are who are.

Least Privilege - Reducing Scope Of Access

Least privilege is probably one of the most, if not THE most, important tenant in Information Security.

When accessing a system, does everyone need the same level of access?

Do 10 admins to a system really need to exist in a 30 person company? Hmm.

Too many chefs in the kitchen.

I know, it’s hard. It takes work. It super easy to just give admin access or *.* IAM credentials, but investing a little extra time up front will pay 10x later.

Note: One critical example for SaaS companies is Admin Panel Access (aka God Mode). Ensure you have multiple access levels and roles and that everyone has only the access they need to do their job.

Session Expirations

This is pretty straightforward and extremely important if you don’t have context awareness enabled. Having lifetime access to critical systems is not recommended.

Not only is this mechanism a protection again malicious access, but also common forgetful scenarios such as failing to offboard an employee or contractor. Or even where the failure of an offboarding mechanism has occurred.

I have witnessed all this.

Pick session expiration based on your identity strength, robustness, and sensitivity level of data access. Basic threat modeling.

Password Reset Verification

An OFTEN overlooked avenue is password reset. Come up with a playbook and strong verification procedures for the following actions:

• Password reset

• MFA token reset

• Password Safe reset

• Admin access bypass

• Session reset

This can be for their self or another user. Imagine conducting a password reset attack just to DOS an admin from gaining access to their system?

Prevent information disclosure

Ever been told TMI? (Too Much Information). That’s information disclosure. Posting unnecessary information about a system.

For example, unrelated, a list of internal EA Slack channels was posted publicly online.

More severe instances of information disclosure exist such as API Keys or secrets in code, slack, email, confluence, wikis, etc.

Ensuring this doesn’t happen takes some work.

It can be a simple regex looking for the above material, to pre-commit checks in your CI/CD pipeline, or a full-blown DLP solution (YMMV).

If you don’t have anything, I recommend searching for password, API_KEY, or secret in your Slack and Wiki.

Limit Slack retention

One way companies try to reduce their legal disclosure risk is limiting retention of email, slack, and other systems. Well, this can be used to reduce the likelihood of an attacker, employee, or contractor finding key material in slack for example.

I remember finding a slack channel a former employee used to store their secrets. 🤦🏽‍♂️ Yes, it was a public channel.

If I could find it, anyone else can.

Develop A Healthy Cybersecurity Culture

(I was going to say “Reduce Bad Code Practices”, but that’s really just a symptom.

Ever hear a company in the news multiple times for cybersecurity issues? Well, that could be a symptom of an unhealthy or unsupportive security culture.

I have heard from sources of Database Credentials in config.xml files in EA’s Battlefield 1! Not only that but these databases were publicly available on the internet!

Here is another instance of a game developer security mishap.

In addition, enabling your employees to detect phishing attacks and safe browsing practices could reduce the likelihood of these cookies making it to the marketplace in the first place.

Conclusion

This must all seem daunting to you and discouraging to you, but taking incremental steps is better than nothing. Mastering the art of threat modeling is your friend.

Someone asked me once, what was the biggest threat to security… I said “complacency”.

Take care,

Ayman

ps. If you found this useful or informative, it mean so much to me if you shared it with someone. Thank you!

ps.