Octo Tempest is Taking Things too Far

Microsoft dropped hot goss on a financially motivated threat actor known as Octo Tempest. This group deploys a wide variety of tactics to take over user accounts, including:

• Adversary-in-the-middle attacks

• Social engineering

• SMS phishing

• SIM swapping

• Purchasing stolen credentials/session cookies

These techniques can bypass weaker forms of MFA, which you can learn more about in my video.

The most concerning part of these tactics is the SMS threats they use.

To obtain user credentials or “influence” them to do something like remove MFA, members of Octo Tempest send threatening text messages to employees of their target organization. In some instances, they threaten the safety of the employee and their families.

This is terrifying and disgusting.

Some extortion groups have tried similar threats as negotiation tactics after they steal data or encrypt systems. Octo Temptest doesn’t waste time, bringing this tactic to the initial access phase.

It’s an escalation that’s just not cool. Let’s hope that others don’t try to mimic this terrible tactic.

Additional reading:

Microsoft’s blog post

1Password Incident Response Review

The fallout from the Okta breach continued this week. One of the scarier downstream impacted victims was 1Password.

On October 23rd, 1Password posted a blog stating they detected attacker activity in their environment. Initial access tied back to the Okta breach after a 1Password user uploaded a HAR file containing their session cookie to Okta.

As part of a transparent response effort, 1Password released their internal incident report.

Buckle up, we’re breaking that report down to see how they responded. We’ll cover what they did well and nitpick one area.

Initial Discovery (A+)

On September 29, 2023, a member of 1Password’s IT team received an email notification informing them they initiated an Okta report containing a list of Okta admins.

One problem. That user never initiated that report.

And this is where they get the A+. Although they missed detecting it through automated measures, the user reported this to the security team!

This allowed the security team to react quickly and start their investigation!

While you ultimately want to design your detection strategy not to rely solely on a user report, there will always be gaps in detection. Employees are in a great position to identify something odd and report that to the security team, where they can quickly respond and contain the event.

Investigation - Okta (A-)

1Password jumped into the Okta logs to understand the scope of unauthorized activity. They found that the attacker did the following:

• Attempted to access the IT member’s Okta user dashboard (Okta blocked this)

• Updated and activated an existing IDP associated with 1Password’s Google environment (this would potentially allow logins to Okta with valid Google credentials)

• Requested a report of administrative users (which ultimately tipped off the IT member)

As part of their testing, the IT team confirmed that the HAR file uploaded to Okta contained the IT member’s Okta session cookie. This was confirmed by taking the session cookie and using a third-party tool to confirm they could access Okta from another system/browser without authenticating.

1Password reached out to Okta to collect information related to the HAR file. Okta’s initial analysis led 1Password to believe the threat actor did not access 1Password’s HAR file. This was inaccurate and led 1Password on a goose chase, which we will now follow.

Scope of Activity - Endpoint (B-)

The 1Password team took the IT member’s MacOS laptop offline until they could figure out what was happening. Then, they scanned it with a free version of Malwarebytes.

Here’s my nitpick.

I often find that organizations rely on an AV scan to rule out malware or deem a system safe. It’s an unreliable way to rule anything out. Attackers routinely use malware that AV does not flag.

In 1Password’s defense, they highlighted that if an attacker did not access the HAR file at Okta, compromising the user’s device was the most likely scenario.

Tie goes to the runner for 1Password. I’m sure they would continue analysis on that Mac laptop beyond just a malware scan with a free tool.

Containment / Remediation (A+)

To contain the incident, 1Password took the following steps:

• Secured the IT member’s account

  • Rotated all credentials

  • Required a Yubikey for MFA

  • Implemented additional restrictions (details not known)

• Okta configuration updates

  • Deny logins from non-Okta IDPs (this addressed the Google IDP change the attacker made)

  • Reduced session times for administrators (this helps limit the impact of session cookies living in HAR files)

  • Reduced the number of super admins (reduces footprint)

  • Reset all admin credentials and cleared sessions for Okta administrators

• Updated detection and alerting capabilities

  • Created new detections to identify similar future attack techniques

These steps were tested on October 2, 2023, when the attacker returned and attempted to log into 1Password through the Google IDP configuration they previously set up. This failed because of the containment steps, and 1Password was alerted of this through their detection improvements.

Solid win.

Overall Response (A)

1Password’s quick response kept the attacker contained and away from customer data.

That IT member deserves a facecake in honor of their quick escalation and reporting.

Additional Reading

1Password’s incident report

Is Your Google Account Locked Down?

When did you last review your security and privacy settings on Google? Don’t lie…

No shame. It’s one of those things we never think about, and why would we?

Here’s your quick reminder to confirm your settings and lock down your security and privacy in Google. Check the video below on the key settings.