Dial B for Breach: How Attackers Slurped 110 Million AT&T Customers’ Phone Logs
Remember back in the early eighties when AT&T’s slogan was ‘Reach Out and Touch Someone’? Apparently cyber criminals took that literally in April this year when they reached out and touched the call log data for over a million AT&T customers.
On April 19, AT&T learned that intruders claimed to have access to its data. The intruders then stole AT&T log data related to wireless calls and texts between May 1 and October 31, 2022. The log information was metadata, containing telephone numbers that wireless users called, how many calls they made, and how long calls lasted in aggregate. It also included cell site identification numbers for some of those calls.
The stolen data didn’t include PII such as call or text content, Social Security numbers, or birth dates. However, as AT&T notes in its SEC filing for the incident, “While the data does not include customer names, there are often ways, using publicly available online tools, to find the name associated with a specific telephone number.” The inclusion of cell site IDs also makes it possible for people to use this data set to analyse the location of some of these calls – and, therefore, the numbers’ owners.
Six months of call logs contain a large haul of data. AT&T has stated that it will inform 110 million customers whose call data was implicated in the data breach. In its filing, it said that it didn’t believe the data had been made publicly available.
AT&T submitted the SEC filing for the breach on July 12, far outside the four-day window. It delayed the filing in agreement with the Department of Justice’s request, as the DOJ decided that filing the report within the normal four-day time period requested by the SEC would be potentially dangerous. That makes sense, given that the breach was apparently ongoing after the telco first learned of the threat actors’ intrusion. The call log data was stolen days after AT&T said it heard about the intrusion.
The breach didn’t happen in AT&T’s systems at all. Instead, it happened through a third-party cloud provider that the company identified in the press as cloud-based data warehousing company Snowflake. This wasn’t the only such data theft from Snowflake; according to Mandiant, 165 customers had their data pilfered from the company’s storage systems. However, this didn’t appear to be a coding vulnerability in Snowflake’s software. The customers who were victims of these thefts, which included brands like Ticketmaster, had one thing in common: their account credentials had been stolen via malware, and they were not using multi-factor authentication.
What Can We Learn from The AT&T/Snowflake Breach?
We can all learn from the mistakes of customers affected by the Snowball breach, say experts. “Organisations should have a clear understanding of the shared security responsibility model that comes with supplier relationships and implement robust identity and access management controls on cloud platforms,” says Milda Petraityte, a researcher at cybersecurity consultancy S-RM.
Snowflake took some action of its own, introducing a new capability for customers’ administrators to enforce mandatory MFA on July 9, almost three months after the slew of unauthorised logins to its systems began. That’s a start, but one wonders why this feature wasn’t in place already – or why, in the spirit of true cybersecurity, there would be any other operating model than mandatory MFA.
Companies are still lagging far behind in the use of MFA. According to CompTIA’s 2024 State of Cybersecurity report, just 41% of companies include the use of MFA in their cybersecurity strategies. Only 38% use some form of cloud workload governance.
The other issue that got companies into trouble was failing to detect and mitigate the credential theft. “Several companies were not aware they had been compromised with infostealers, so their credentials were available on the dark web,” points out Stephanie Schneider, a cyber threat intelligence analyst at password manager company LastPass. Detection is a critical step in any incident response plan. Because companies failed to spot the malware infection that led to credential theft and then didn’t implement extra access protection, they left themselves vulnerable.
Companies can learn about secure practices like these in common cybersecurity standards. For example, ISO 270001 explicitly mentions secure authentication methods such as external device authentication in its Annex A 8.5 documentation. It also mentions measures such as checking for and preventing the use of unauthorised software, defence-in-depth malware protections across multiple infrastructural points, and training employees to be aware of social engineering and installing malicious software in Control 8.7—Protection against Malware.
Implementing such measures effectively might have helped to prevent AT&T’s Snowflake disaster, along with many other companies’ breaches via the cloud-based service. However, the telco has had other cybersecurity incidents to contend with.
In March this year, AT&T stated that PII from 73 million customers was floating around on the dark web, and it didn’t know where the information had come from. That data, surfacing from a compromise in 2021, was enough to spark a class-action lawsuit from frustrated customers.
In January 2023, the telco reported that PII from nine million customer accounts had been compromised via one of its third-party marketing partners. This highlights the need for robust vendor assessments and ongoing third-party security audits to help secure not just the company’s own network but its entire data ecosystem.
Managing that kind of ecosystem is a challenge for a company as sprawling as AT&T, especially given that it also sold customers’ geolocation data to third parties without their consent. This is also a sign that we need more regulatory action to force these companies to implement robust security and privacy controls.
