AT&T / SnowFlake Breach - Who's to blame?

Call records for 110 million user have been breached from AT&T. AT&T is pointing the finger at SnowFlake - who’s at fault?! What exactly is going on and how should you protect your organization?

You’ve heard the headlines about the AT&T data breach. Here’s what we know and what this means for you as a Executive responsible for protecting critical data.

First the facts

• The attack occurred between April 14, 2024 and Apr 25, 2024.

• Attackers stole customer records for the time period of May 1 through October 31, 2022, and also for the day January 2, 2023

• Approximately 110 Million AT&T customers are impacted. In addition, the receiving phone number of calls/texts on non-AT&T carriers would also be exposed

• The stolen data includes:

  • calling and texting records 

  • (in limited cases) cell site identification numbers associated with phone calls and text messages 

• From the AT&T 8-K  “The data does not contain the content of calls or texts, personal information such as Social Security numbers, dates of birth, or other personally identifiable information.”

How did the breach occur?

AT&T has stated that the breach of AT&T data is due to a breach of the vendor data solution, Snowflake.

So it’s Snowflake’s vault? Not so fast, that’s what the sound bite from AT&T may want you to believe, but let’s dive into it.

According to the Mandiant incident analysis of the Snowflake breach, 

“a financially motivated threat actor suspected to have stolen a significant volume of records from Snowflake customer environments. UNC5537 is systematically compromising Snowflake customer instances using stolen customer credentials, advertising victim data for sale on cybercrime forums, and attempting to extort many of the victims.”

The key item here is the use of “stolen customer credentials” meaning the attackers have obtained the target victims username and password and are using this information to just log into snowflake as the victim user. The mandiant report goes on to make this clear and eliminate any confusion that Snowflake themselves have a security vulnerability.

“Mandiant's investigation has not found any evidence to suggest that unauthorized access to Snowflake customer accounts stemmed from a breach of Snowflake's enterprise environment. Instead, every incident Mandiant responded to associated with this campaign was traced back to compromised customer credentials.”

But how is the attacker getting the user login credentials in the first place?

From another Mandiant investigation of a compromised company where Snowflake data was stolen, Mandiant determined the attacker was “using credentials previously stolen via infostealer malware.” So, the attack path to the credentials was good ‘ole fashion malware on the vicitm’s machines (to be clear, not Snowflakes machines, rather the various customers of Snowflake)

“These credentials were primarily obtained from multiple infostealer malware campaigns that infected non-Snowflake owned systems.”

Mandiant worked with Snowflake and notified approximately 165 impacted and potentially exposed organizations where usernames and passwords were at risk.

Pulling this together - who’s to blame?

From what we know so far, malware was used on victim’s computers to steal passwords. These computers were owned and operated by customers of Snowflake, not Snowflake themselves. In addition, Mandiant reached out and notified numerous organizations of the potential exposure and vulnerability. In addition, we’ve already had major news stories about other organizations’ SnowFlake accounts being breached through this exact method.

It seems the blame falls squarely on AT&T and their lack of response to proactively rotate their own Snowflake credentials.

But wait, there’s more

You may be wondering, how could you log into the main data store of a major telco and access over 110 million customer records with just a username and password? You’re exactly right. This shouldn’t even be possible! Multiple other security controls could have been present to stop this. Here are just a few:

• The use of multi-factor authentication!

• IP whitelisting of access to the Snowflake portal to prevent account usage from other IPs

• Data shielding to prevent extensive data record access by the account

• Not storing all of this data in a live server - just store it in locked down back ups if it has to be kept at all.

As an executive, what should you do now to protect your organization and use of SnowFlake?

Operate under an “assumed breach” scenario for your SnowFlake credentials and follow the SnowFlake incident page for any updates

This means you need to invoke incident response and perform a few crucial activities

1. Identify any Snowflake accounts that don’t have MFA enabled.

2. For these accounts review all login and activity logs to determine if the accounts had any suspicious behavior indicating they were breached. If so, invoke your data breach protocols.

3. Rotate the passwords for all of your snowflake accounts - whether or not MFA was enabled

4. Enforce MFA for all SnowFlake accounts - this is crucial

5. Enable IP restrictions to ensure service accounts can only be used from specific IP ranges

Bigger than just SnowFlake

As an executive thinking about information systems and security, it’s crucial to have a holistic approach to third party applications. The key tenets of cyber security are important here.

1. Reduce complexity - avoid having unique login credentials and operate with single sign on wherever possible.
   

2. FIDO 2 or bust - Multi-factor authentication is a must. There’s just no getting around it. You have to require it everywhere. And while you’re doing this, don’t pick a weak approach that is vulnerable to phishing. The gold standard is FIDOv2 which may know as security keys (such as Yubikey) or passkeys.
   

3. Organizational policies for cloud service sprawl - Technology will get you most of the way, but only if you know where to apply those technology controls. It’s crucial to have an approach for managing the hundreds of third party services and ensuring that standard processes configure these properly and don’t miss any crucial security configurations.

Make sure not to miss the next post. Subscribe to the newsletter!