Infostealers Find a Google Zombie Token

Spotlight
Infostealers Revive Dead Google Tokens

Background: Infostealer developers upped their game. As you may know, infostealers are designed to steal…sensitive information. Shocker. While that includes passwords, it also includes session cookies. Session cookies allow you to access a website again without logging in, like for your email. It’s convenient for the user, but there’s a downside.

Attackers can still use that session cookie, insert it into their browser, and viola, they’re impersonating you. Oh, and this also bypasses our favorite defense, MFA.

I first learned of this from Alon Gal (he’s a great follow on LinkedIn) after he published a blog post on this issue and a YouTube video showing the attack in progress.

The Nerdy Stuff: CloudSEK researchers did an awesome job digging into this and posted about it. They found that the attackers used an undocumented Google feature called “MultiLogin.”

This is a Google feature that allows for syncing the login experience between different Google services, like Gmail and YouTube. One login for the user unlocks access to multiple Google services. A great experience for a user and a great target for an attacker.

The Core Issue: The attackers have the ability to regenerate expired tokens to access Google services, hence why I love to refer to this as a zombie token (I’m determined to make this a thing).

This works even after a user changes their password, though the attacker can only regenerate the token once after that. More reason to call this a zombie token…just saying.

This is great for the infostealer game because it extends the shelf life for compromised accounts. It’s great for business.

Infostealer Grabbag: Malware developers sprinted to this new feature faster than people trying to scoop up a Stanley Cup 40-oz Quencher. According to CloudSEK, six infostealers adopted the technique between November 14, 2023, and December 26, 2023 (thanks for nothing, Santa).

Remediation Steps: Not all is lost if you’ve been compromised. CloudSEK found that you can reset your sign-in cookies to kill this functionality. Note that it will be different for personal accounts vs Google Workspace accounts.

Here are links to Google’s guidance:

Personal Gmail Accounts
Google Workspace Accounts

Deep Dive
23BlameMe - Is It Over Yet? Nope.

Three months out, and we’re still talking about 23andMe. They continue to make…let’s call it “interesting”…moves in their response to a cyber attack that impacted their customers. Coincidentally, the attack was a topic in the first WeekendByte newsletter, where I covered the credential-stuffing attack that led to user accounts being hacked.

…please give me a moment while I reminisce about how far this newsletter has come since then 🥹.

But I digress. The issue this time is that 23andMe (more specifically, their lawyers) took a hard line in their response to claims made in a class action lawsuit against them. More specifically, they went straight for the jugular to disavow themselves of any responsibility…at least from a legal standpoint.

Before we take up pitchforks, remember that we’re in the stage of lawyers posturing and going full force on the rhetoric. So, let’s hear their arguments with an open mind…

Argument #1: 23andMe did not fail to maintain reasonable security standards. The key argument here is that the initial 14K hacked 23andMe user accounts resulted from poor password hygiene practices for the users themselves. Impacted users had reused passwords across multiple websites, including websites that had their own security breaches that compromised user passwords. The attackers took those passwords from other data breaches and then logged into 23andMe.

Argument #2: 23andMe customers had MFA available to them. Going back to the initial compromised accounts, the users reused passwords on websites and they didn’t enable MFA on their account. 23andMe calls this out as another failure where the users did not secure their account (control your blood pressure, we’ll double click on this).

Argument #3: Impacted 23andMe customers opted in to share their data via the DNA Relatives feature. This is how the number of impacted users grew to millions from the initial 14K hacked accounts. Users who voluntarily enabled the DNA features shared their information with other 23andMe users.

Argument #4: No financial harm occurred to impacted users. They specifically state that the information that was impacted during the data breach could not be used to cause financial harm to those users. So, no harm, no foul?

Who’s Responsible, 23andMe or the users?

Just one simple man’s opinion here, but the blame lies on both parties. And of course, let’s not forget the attacker here who ultimately carried out the crime.

In the day of daily data breaches, we forget that there are two victims. The users whose data was impacted and the companies who were hacked into. If you still believe that a company can stop 100% of cyber attacks, I encourage you to reevaluate that position. Mistakes will happen regardless of the maturity or strength of an organization’s security posture.

I believe we live in a time where there is a shared responsibility for users and companies.

Users Responsibility

Users must take action to secure their online identities. But let’s face it, most people have no idea what that means. They’re not techy nerds or even in a position to receive second-hand security best practices.

Regardless, there are a few things that everyone should do:

1. Use a password manager for unique passwords on every online application.

2. Enable MFA wherever possible, preferably phishing-resistant when it’s supported by the application.

3. Be smart about what data you willingly share. Realize that the data you share could be leaked in the future. Admittedly, this is much easier said than done because for many online applications, if you just want to use the app you have to share your info.

Organization Responsibilities

For 23andMe, it’s not unreasonable for a company storing sensitive information to prioritize key security controls that provide air cover for their users. This includes:

1. Check if users are using compromised passwords. This is something that can automated and implemented with minimal effort.

2. Mandate the use of MFA. This sounds scary for many SaaS companies, but big players like Google and Microsoft have taken steps in this direction.

3. Monitor for and block account brute-forcing attempts. This can limit the impact of credentials stuffing attacks and alert security teams of issues sooner.

And for everyone, let’s face it. Your data is out there. While we like to get outraged over these issues, accept that fact and recognize we don’t live in a world where your data won’t be at risk at some point. Take the measures you have the ability to control and take action.

And for organizations, I get the legal game you have to play, but messaging is important in these types of communications. There’s always room for improvement and an open dialogue of shared responsibility.

News
What Else is Happening?

🇨🇳 Cyber attackers in China were arrested for using ChatGPT as part of their attacks. As I read about this, I couldn’t help but get the urge to start a “dumb cyber criminals” TV show. Who is with me?

🐣 Mandiant’s Twitter account was hacked (I can’t bring myself to call it X). The attacker wasted no time in dropping a fresh crypto scam. Ironically, X users (messed up already) took to the platform to complain about all the ads they see being crypto scams.

🇪🇸 An attacker took a huge chunk of Spain’s Internet traffic offline. They used stolen RIPE administrator credentials (these manage how network traffic flows) for Orange Spain (a major telecom provider). The credentials were collected via an infostealer.