Anatomy of a Breach

Anatomy of a Breach: The AT&T iPad Leak — 114,000 Email Addresses and the Line Between Research and Crime

> series: anatomy_of_a_breach —— part: 019 —— target: att_ipad_users —— emails_exposed: 114,000 —— method: api_enumeration<span class="cursor-blink">_</span>_

Hedgehog Security 31 July 2010 11 min read

An API that answered every question you asked it.

In June 2010, security researchers from a group called Goatse Security discovered that AT&T's website contained an API endpoint that, when provided with the ICC-ID (Integrated Circuit Card Identifier) of an iPad 3G SIM card, would return the email address associated with that account. Since ICC-IDs followed a sequential numbering scheme, the researchers were able to enumerate approximately 114,000 email addresses of early iPad 3G adopters by iterating through ICC-ID values.

The exposed email addresses included those of White House Chief of Staff Rahm Emanuel, New York Mayor Michael Bloomberg, numerous military officials, media executives, and corporate leaders — essentially the early-adopter elite who had purchased the iPad within weeks of its launch. The incident was disclosed to AT&T, which patched the vulnerability, and to Gawker Media, which published the story. One of the researchers, Andrew Auernheimer (known as 'weev'), was subsequently convicted under the Computer Fraud and Abuse Act — a conviction later overturned on appeal — reigniting the debate about where security research ends and criminal activity begins.


Recommended

Not sure where to start?

We'll scope your test for free and tell you exactly what you need. No obligation, no hard sell.

Free Scoping Call

An insecure API with no authentication.

The technical vulnerability was straightforward: AT&T had deployed an API endpoint that accepted an ICC-ID parameter and returned the associated email address. The API required no authentication — anyone who could guess or enumerate ICC-IDs could retrieve email addresses. Since ICC-IDs are sequential, enumeration was trivial.

This vulnerability class — insecure direct object reference (IDOR) combined with enumeration of sequential identifiers — is one of the most common findings in our API penetration testing engagements. It appears on the OWASP Top 10 and remains prevalent in modern APIs. The AT&T incident demonstrated its potential impact at scale — but the same vulnerability, discovered in a client's API during a penetration test, is remediated quietly without public disclosure.


What this breach teaches about modern API design.

Authentication on Every Endpoint
The AT&T API had no authentication requirement. Every API endpoint that returns user data must require authentication and authorise each request against the requesting user's permissions. Our <a href="/penetration-testing/api">API penetration testing</a> systematically tests for unauthenticated endpoints and missing authorisation checks.
Non-Sequential Identifiers
Sequential ICC-IDs made enumeration trivial. Sensitive resources should use UUIDs or other non-sequential, unpredictable identifiers that prevent enumeration attacks. This is a standard assessment point in our <a href="/penetration-testing/web-application">web application</a> and API testing methodology.
Rate Limiting
Even with authentication, the API should have rate-limited requests to prevent bulk enumeration. The researchers retrieved 114,000 records — a volume of requests that should have triggered throttling or alerting. <a href="https://www.socinabox.co.uk">SOC in a Box</a> monitors API traffic for enumeration patterns and anomalous request volumes.
Responsible Disclosure
The AT&T incident reignited the debate about responsible disclosure — the process by which security researchers report vulnerabilities to vendors before public disclosure. As a <a href="/penetration-testing">CREST-accredited penetration testing provider</a>, we operate within established responsible disclosure frameworks and work with clients to remediate vulnerabilities confidentially.

API security is more critical than ever.

In 2010, the iPad was new and APIs were less pervasive. In 2025, APIs are the backbone of every digital service — mobile apps, web platforms, IoT devices, and cloud services all communicate via APIs. The IDOR and enumeration vulnerabilities that exposed 114,000 AT&T customers now have the potential to expose millions. Our API penetration testing service tests for these vulnerability classes and more — authentication bypass, authorisation flaws, injection, rate limiting, and data exposure.

For organisations building or consuming APIs, our web application and API testing provides the security assurance that prevents your API from becoming the next breach headline. Cyber Essentials establishes baseline security. SOC in a Box monitors API traffic patterns. And UK Cyber Defence provides incident response when an API vulnerability is discovered or exploited.


Your APIs expose your data. Have they been tested?

Our <a href="/penetration-testing/api">API penetration testing</a> identifies IDOR, enumeration, authentication bypass, and data exposure vulnerabilities before attackers — or researchers — find them.

Next Step

Not sure where to start?

We'll scope your test for free and tell you exactly what you need. No obligation, no hard sell.

Free Scoping Call

Related Articles