From S3 Bucket to entire login infrastructure compromise

TL;DR

I discovered an unclaimed AWS S3 bucket, which was still actively used to load JavaScript across multiple domains belonging to a major Brazilian media group, GJC Corp.

This JavaScript was included even on their Keycloak-based authentication portals. If an attacker had taken over the bucket and served malicious JavaScript, they could have achieved stored XSS, cookie/session theft, and even full account takeover — including possibly admin sessions.

Fortunately, GJC Corp acted and resolved the issue after I reached out.

Discovery

The bucket in question was: https://s3-sa-east-1.amazonaws.com/analytics-gjc. I claimed the bucket to prevent abuse and began monitoring request logs.

What I saw was alarming within 24h:

• Thousands of requests to analytics-gjc-min.js and similar script files
• Referrer headers pointing to live login flows, including:
  • accounts.gjccorp.com.br
  • accounts.opopular.com.br

These domains were running Keycloak, an open-source identity provider (IAM) — and the scripts were loading on the login page itself.

Why This Is Dangerous

Here's what could happen if an attacker served a malicious payload:

1. Stored XSS

The JavaScript was being loaded from a remote, uncontrolled location. An attacker could inject code directly into the authentication portal and any site referencing the bucket.

2. Session Hijacking

On authentication pages, cookies and tokens can be accessed via JavaScript. This includes potentially privileged users or site admins. This would be an easy stepping stone to compromise the whole IT infrastructure.

3. Phishing and Redirect Attacks

Since the bucket was included in authentication flows, a script could:

• Hook into form inputs
• Change redirects
• Forward credentials to attacker-controlled servers

Options such as SRI were not implemented, which would have prevented the impact of this attack.

4. Infrastructure-Wide Risk

Because this was part of GJC's central identity system, the implications spanned multiple brands and properties, including:

• opopular.com.br
• classi.com.br
• jornaldotocantins.com.br
• gjc.meudaqui.com.br
• And several portals like carros.classi.com.br, negocios.classi.com.br, etc.

📈 Visibility & Verification

From the bucket logs and passive analysis, I confirmed:

• Requests came from employees that were logging in using Keycloak.
• Several domains used the same analytics script without SRI (Subresource Integrity).
• Some Keycloak redirect URIs leaked sensitive information in the Referer header.

One such referrer URL looked like:

https://accounts.gjccorp.com.br/auth/realms/accounts/protocol/openid-connect/auth?response_type=code&client_id=opopular&redirect_uri=...&scope=openid

This proves that the authentication process was directly exposing internal flow data to an attacker-controlled bucket.

🛠️ Resolution & Response

After responsibly disclosing this to GJC Corp, I received a response from their security team. Highlights:

• The affected JavaScript reference was removed from production
• The unused analytics feature was fully deprecated
• Plans are in motion to update Keycloak and harden authentication systems. I.e configure Referrer-Policy to prevent leaks via the referrer header.

I’d like to publicly commend GJC security team for their transparency. These types of issues are not rare — what matters is how organizations respond to these kind of issues.

Final Thanks and Transparency

This write-up includes permission to mention GJC Corp by name. The vulnerability is resolved, and no malicious activity occurred during the period in which I controlled the bucket.

If you’re in the cloud, security, or devops space — take this as a reminder to audit all third-party scripts and monitor your cloud infrastructure footprint.

Want to connect or support my work in cloud & app security?
🧑‍💻 linkedin.com/in/maikel-zw