When Trust Becomes the Attack Vector

Most ransomware stories start with malware, exploits, or brute force attacks. This one didn’t. This incident started with trust. Not broken systems. Not weak encryption. Trust in a legitimate platform, a familiar login screen, and a single user action.

The Initial Entry Point

The attacker did not compromise Google Workspace itself. Instead, they abused how modern identity and application access is designed to work. A user received a phishing email that looked legitimate. The link did not download malware. It redirected the user to an OAuth consent flow that appeared normal and trustworthy. The user approved it. That single approval granted the attacker OAuth access to the user’s Google Workspace account. No passwords were stolen. No MFA was cracked. Nothing was brute-forced.

Why MFA Didn’t Save the Day

Multi-factor authentication did its job during the initial login. The problem is what happens after. Once OAuth consent is granted, access tokens persist. The attacker could authenticate via Google APIs indefinitely, without re-triggering MFA, until the token or app consent was revoked. From Google’s perspective, this was legitimate activity by an approved application.

Google Workspace Became the Launch Platform

With OAuth access in place, the attacker now had:

• Access to Gmail
• Visibility into internal conversations
• Access to Drive and shared files (based on granted scopes)

They used Gmail to send trusted internal emails. Messages came from a real employee, inside the tenant, bypassing most email security controls. Those emails delivered malicious files and links that users trusted because the sender was trusted. This is how Google Workspace became the launch point for the next phase.

Ransomware Delivery and Execution

Once a user opened the malicious attachment or link:

• The payload executed locally
• Endpoint compromise occurred
• The attack moved from cloud abuse to workstation control

Still, this alone wouldn’t normally result in full-environment ransomware. The real accelerator came next.

The Local Admin Password Problem

Every workstation in the environment used the same local administrator password.

Once a single machine was compromised:

• The attacker extracted the local admin credentials
• Reused them across every workstation
• Moved laterally without resistance

No domain admin was required. No advanced exploits were needed.

This allowed the attacker to:

• Disable security controls
• Push ransomware broadly
• Execute near-simultaneous encryption across the environment

Why This Attack Was So Effective

Nothing here relied on zero-days or advanced malware. It worked because several common gaps aligned:

• OAuth app consent was not restricted or monitored
• MFA was assumed to be sufficient protection
• Internal email was implicitly trusted
• Local admin passwords were shared across machines

Each issue alone is survivable. Together, they enabled a full ransomware event.

The Takeaway

Modern attacks don’t always break in. They log in.

Defending against this class of attack requires:

• Tight control and monitoring of OAuth app consent
• Regular review and revocation of OAuth tokens
• Unique local admin passwords per device
• Endpoint hardening and application control
• Continuous monitoring, not point-in-time security

If your security strategy assumes that MFA and cloud platforms alone are enough, this incident proves otherwise.

Trust is powerful. Attackers know that.