EA Games Vulnerability

June 26, 2019


In the last few weeks, Check Point Research has combined forces with CyberInt to identify a chain of vulnerabilities that, once exploited, could have led to the takeover of millions of player accounts within the world’s second largest gaming company, EA Games. The potential damage could have involved an attacker gaining access to a user’s credit card information and the ability to fraudulently purchase in game currency on behalf of the user.

CyberInt and Check Point immediately notified EA Games of these security gaps and together leveraged their expertise to support EA in fixing them to protect their gaming customers.


Origin: The EA Games Platform

With over 300 million users and revenues of around $5 billion, EA Games is the world’s second largest gaming company market capitalization and boasts household gaming titles such as FIFA, Maden NFL, NBA Live, UFC, The Sims, Battlefield, Command and Conquer and Medal of Honor in its portfolio. All these games and more rest on its self-developed Origin gaming platform that allows users to purchase and play EA’s games across PC and mobile.

Origin also contains social features such as profile management, networking with friends with chat and direct game joining along with community integration with networking sites such as FacebookXbox LivePlayStation Network, and Nintendo Network.


Origin and the Vulnerabilities Found

In a similar manner to Check Point Research’s previous discoveries into another hugely popular online game, Fortnite, the vulnerabilities found in EA’s platform similarly did not require the user to hand over any login details whatsoever. Instead, it took advantage of EA Games’ use of authentication tokens in conjunction with the oAuth Single Sign-On (SSO) and TRUST mechanism that is built into EA Game’s user login process.

In this case, EA Games is a cloud-based company that uses Microsoft Azure to host several domain names such as and in order to provide global access to various services for their players, including creating new game accounts, connecting to the Origin social network and purchasing more games in EA’s online store.


Technical Details Subdomain Hijacking

EA games operates several domain names such as and in order to provide global access to various services for their players, including creating new Apex Legend accounts, connecting to the Origin social network, as well as purchasing new EA games in the company’s online store.

Generally, each service offered by a cloud-based company such as EA Games is registered on a unique subdomain address, for example,, and has a DNS pointer (A or CNAME record) to a specific cloud supplier host,, which runs the desired service in the background, in this case a web application server.


Fig 1: The DNS pointer for points to the CNAME record,


Azure is a cloud services provider solution powered by Microsoft and allows for a company to register new services (e.g. web applications, REST APIs, Virtual Machines, databases and more) in order to provide them to online customers around the world.

Each Azure user account can request to register a specific service name ( which will be connected to a specific domain or subdomain of the organization after successfully validating it’s CNAME records during Azure subdomain validation process.

During CyberInt’s research, though, they found that the service was not in-use anymore within Azure cloud services, however the unique subdomain still redirect to it using the CNAME configuration.

The CNAME redirection of allows us to create a new successful registration request at our own Azure account and register as our new web application service. This allowed us to essentially hijack the subdomain of and monitor the requests made by EA valid users 🙂


Fig 2: Changing the CNAME redirection of ‘’ to our own ‘’ hosted in our own Azure account.


As seen from the below, the DNS Record status after the hijacking process now shows that the redirects to our new Azure cloud web service:

Fig 3: The DNS Record status after the hijacking process. ‘ now redirects to our new Azure cloud web service


oAuth Invalid Redirection to Account Take-Over

Having control over the subdomain led our research team to a new goal of figuring out how we can abuse the TRUST mechanism. The TRUST mechanism exists between and domains and their subdomains. Successfully abusing the mechanism enabled our research team to manipulate the oAuth protocol implementation for full account take-over exploitation.

We began by identifying how EA games had configured the oAuth protocol and provides its users a Single Sign-on (SSO) mechanism. The SSO mechanism exchanges the user credentials (user & password) by unique SSO Token and then uses the token to authenticate with any platform (for ex. of EA networks without having to enter their credentials again.

Analyzing the EA games oAuth SSO implementation within several EA services such as, and helped us to review the EA authentication process and learn more about the TRUST mechanism that had been implemented.

As part of a successful authentication process with EA global services via, an oAauth HTTP request is sent to in order to get a new user SSO token, then the application should redirect it through to the final EA service called to identify the user.


Fig 4: An oAuth SSO request for authenticating with



Fig 5: The oAuth authentication SSO token is redirected through to EA server


We found, however, that it was actually possible to determine the EA service address which the oAuth token is generated for  by modifying the returnURI parameter within the HTTP request to our hijacked sub-domain of EA,


Fig 6: oAuth requests to generate a new user token for


Fig 7: The server generates valid token without validation of the fake EA service


However, generating the above-mentioned request to redirect the generated SSO token into our hands was not sufficient since several limitations took place on EA’s side.

The following items represent the limitations introduced by EA and how we successfully bypassed them in order to weaponize our attack:


Limitation 1 – A Missing Valid Referer

In order to compromise EA accounts, the research teams needed to send the previously mentioned request to including the modified parameters on behalf of the victim.

However, the backend server of validates if the request originally came from a trusted Origin domain by checking the HTTP Referer header.



To overcome this limitation we needed to start the request on behalf of our victim from an EA trusted domain or subdomain. So we coded a new Iframe onto the index page of our hijacked subdomain so the request would be initiated from the Iframe and bypass the server validation.


Fig 8: malicious index page


Fig 9: Attacker’s generates iframe on to bypass http Referer validation


Limitation 2 – The Origin Problem

After sending the request to to complete our malicious authentication process and get the victim’s token to our hijacked subdomain at, a new jQuery function is generated and returned to the client for redirecting the token.


However, the jQuery $.postMessage function will fail from executing this time since the destination server ( is not part of the current Origin ( Therefore the function will send an error to the browser console and stop itself from sending the token to us.


To overcome this issue, we had to look for a new token redirection method on since the jQuery function stopped them from getting the victim’s token as part of the malicious flow.

After several attempts, we captured one different request to that contained the redirectback parameter. This parameter guided the server to use the returnuri value and redirect the page to it directly, without attaching to it the victim’s access token.

Fig 10: Sending redirectback parameter to bypass jQuery origin issue


Fig 11: The server responded with a simple redirection to the target server


At this point we managed to redirect an authenticated EA player to our servers. We were able to do this after they visited the oAuth SSO authentication iframe and so were then able to log the incoming request within our servers.



The token was sent to our servers within the HTTP Referer header since the player was redirected through severaloAuth SSO URLs using our malicious Iframes. The last redirection on redirected the player to our server using window.location JavaScript function. It contained the SSO token of the player and allowed us to take control over it.


Fig 12: Logging the incoming Referer value and searching for the victim’s Access-Token


Fig 12: The victim oAuth SSO token logged on the attacker’s PC



  • Check Point Research Publications
  • Global Cyber Attack Reports
  • Threat Research
February 17, 2020

“The Turkish Rat” Evolved Adwind in a Massive Ongoing Phishing Campaign

  • Check Point Research Publications
August 11, 2017

“The Next WannaCry” Vulnerability is Here

  • Check Point Research Publications
January 11, 2018

‘RubyMiner’ Cryptominer Affects 30% of WW Networks