The Internet Archive was breached twice by the same threat actor — first when an exposed GitLab configuration file (publicly accessible for nearly two years) enabled theft of 33 million users’ records, then again through a Zendesk support token that was among the leaked GitLab secrets and was never rotated, exposing 800,000 support tickets dating to 2018. A concurrent DDoS by a separate pro-Palestinian group initially obscured attribution for the data breach.
Stories Covered
Internet Archive Breached Twice: Unrotated GitLab Tokens Enabled Back-to-Back Compromises
The Internet Archive’s first breach began when a GitLab configuration file was left exposed on a development server (services-hls.dev.archive.org) for approximately two years — confirmed accessible since at least December 2022. The file contained GitLab authentication tokens that gave the threat actor access to pull the organization’s source code repositories. Source code repositories for web applications routinely contain what developers should never store there: hardcoded secrets, API keys, and access tokens checked in alongside the application code. The stolen credentials and secrets enabled the breach that exposed data for 33 million Internet Archive users. A DDoS attack by a separate pro-Palestinian group called SN_BlackMeta occurred simultaneously, causing initial misattribution and frustrating the actual threat actor, who contacted Bleeping Computer through an intermediary to claim credit and explain the actual access chain.
The second breach followed weeks later and was entirely preventable. Among the secrets obtained from the GitLab repositories was a Zendesk API token providing access to Internet Archive’s support ticketing system. Despite Bleeping Computer repeatedly warning the organization that their secrets had been stolen and not rotated, the Zendesk token was still active. The threat actor used it to access 800,000 support tickets submitted to [email protected] since 2018 — including requests for page removal from the Wayback Machine, which in some cases required users to upload government-issued identification documents. The attacker demonstrated this access by sending emails directly to people who had submitted old support tickets, with the messages passing all DKIM, DMARC, and SPF authentication checks — confirming the emails were sent from a legitimate Zendesk server still under attacker control.
The access token failure here is textbook. When an access token is compromised, the correct response is immediate rotation — invalidating the old token and issuing a new one. Unlike a password, a properly rotated token leaves the previous value useless regardless of who holds it. Token rotation is not optional after a known credential compromise; it is the primary remediation. The Internet Archive’s failure to rotate all exposed tokens after the initial breach is what enabled the second compromise — same actor, same stolen credentials, different service. The threat actor’s stated motive was reputation and credit within hacker communities, not financial gain — 7 terabytes reportedly stolen with no data published at time of recording. The Internet Archive’s handling of the incident — delayed response, incomplete credential rotation, failure to act on Bleeping Computer’s repeated warnings — is a failure of incident response fundamentals, not a sophisticated evasion by the attacker.
Leave a Reply