The State of Google Workspace Misconfigurations

At its core, cloud misconfiguration is a gap between how a cloud service should be secured and how it is actually set up. In an era where Infrastructure as Code allows entire data centers to be deployed with a single process, a minor typo or a misunderstood setting can instantly expose an entire organization to the public internet.

It’s a common misconception that cloud breaches are always the result of sophisticated zero-day exploits. In reality, most incidents occur because a door was left unlocked rather than a lock being picked.

The primary driver of misconfiguration is a misunderstanding of the Shared Responsibility Model. While providers such as Microsoft 365 and Google Workspace secure the underlying physical infrastructure, the customer is responsible for configuring the security of their data and applications.

With that being said, Google Workspace is not an insecure platform, and the configuration surface Google exposes gives security teams everything they need to run a defensible posture. The challenge for an MSP is that configuration debt accumulates silently across tenants, quietly converting sensible defaults into an exploitable attack surface before any detection fires.

The pattern repeats consistently across the tenants I work in: MFA is enforced, public Drive sharing is locked down, and the Super Admin count survives a Friday afternoon review. One layer below that surface, a service account holds a domain-wide delegation grant that predates the current admin team’s tenure, two years’ worth of inbox-forwarding filters route mail to external addresses, and a Chrome extension installed on 400 endpoints enumerates every page the user loads. The baseline controls are in place, but the material risk lies one configuration-click deeper than any compliance checklist is designed to reach.

If you are an MSP managing 50 tenants and this triage is not yet part of your validation cadence, it is worth building that automation now rather than waiting until the first incident that traces back to one of these gaps.

This article is part of the Google Workspace Hardening for MSP series.

Google Workspace Misconfigurations

The Legacy Backdoor

As we move toward adopting strong authentication, we should remember that legacy systems can still take us down.

Legacy authentication in Google Workspace is the same structural flaw it represents in Microsoft 365, simply wearing a different label. IMAP, POP3, and ASP-bearing flows route around the SSO and 2SV controls that took an entire quarter to roll out, which means an attacker holding valid credentials and a static ASP token never encounters your context-aware policy, never sees a security-key prompt, and authenticates over a protocol stack older than the TLS version your reverse proxy enforces.

Why does this matter?

• Bypassing Modern Auth: Adversaries love IMAP/POP3 because they often support legacy authentication. If these are off, you’ve successfully blocked a major vector for password spraying and credential stuffing that bypasses MFA.
  
• Data Exfiltration: Disabling these prevents easy bulk mail downloading via external tools.
  
• Shadow IT: Users might try to find “creative” (insecure) ways to sync their mail if they can’t use their preferred clients.

How to check?

Apps > Google Workspace > Gmail > End user access – Disable POP and IMAP at the OU level. If a legacy integration genuinely requires IMAP, scope it to a dedicated OU with a Context-Aware Access policy applied, not a tenant-wide carve-out.

The single check that catches the most exposure is the intersection of the suspicious login filter and the set of accounts holding active ASPs. In tenants past two hundred seats, that intersection is rarely empty, and the accounts that surface are almost always either a forgotten integration account or a recently compromised identity whose attacker has already pivoted to a more durable access mechanism.

The “Open Door” Guest Invitation

In the drive toward collaboration, the “Guest Invitation” feature is often the first point where security intent and operational reality collide. This configuration represents a fundamental shift from a closed, managed environment to one in which the perimeter is defined by individual users’ discretion rather than by centralized policy.

Why does this matter?

• Persistent Shadow Access: An attacker doesn’t need to maintain a risky session on a compromised corporate device. By sending a guest invitation to an attacker’s external account, they establish a “clean” way to access documents from any device, anywhere.
  
• Bypassing Context-Aware Access: Because guest accounts often lack the same compliance device requirements as internal members, they frequently act as a “get out of jail free” card for CAA. If your policies aren’t explicitly applied to “All Users” (including guests), you’ve left a massive blind spot.
  
• Fragmented License Security: The console indicates that this applies specifically to Business Starter licenses. In environments with mixed licensing, this creates an uneven security posture in which the weakest link, the Starter license users, can cause the most data leakage.

Closing the Loop

1. Restrict the Guest List: Navigate to Security > External sharing and disable the ability to send invitations to external contacts for high-risk OUs such as “Sample OU.”
   
2. Whitelist Domains: If external collaboration is a business requirement, move from “Allow All” to a strictly managed Trusted Domains list. This forces collaboration into known-good ecosystems rather than personal, unmanaged accounts.
   
3. Audit Guest Activity: Regularly review the “User” list in the Admin Console, specifically for the Workspace Guests label seen in your sidebar. If you don’t recognize the domain of a guest, they shouldn’t have access to your research.

While often viewed as a productivity booster, allowing users to invite external entities into the tenant is a structural bypass. It enables data to move from a managed corporate ecosystem into unmanaged personal accounts, often without the same Context-Aware Access or MFA enforcement you spent months hardening for your internal staff. For a researcher or a red teamer, this is not just a feature; it is a native mechanism for establishing persistent, low-noise access to an organization’s most sensitive resources.

The OAuth Wild West

The most dangerous way to lose control of your tenant isn’t through a direct login, but through the “consent-driven” exfiltration provided by unconfigured third-party applications. This setting determines what happens when a user attempts to grant a random application access to their Workspace data via OAuth.

Why does this matter?

• Persistent Data Scoping: An attacker doesn’t need to steal a password if they can trick a user into authorizing a malicious app. These scopes provide long-term, API-based access that survives password resets and MFA changes.
  
• Stealthy Exfiltration: Data moving through an authorized API connection looks like legitimate business traffic. Without strict app controls, a “productivity tool” could be silently vacuuming the contents of the GWS Drive in the background.
  
• The “Basic Info” Fallacy: Even the “Allow access only for basic info” option is a risk; it provides the identity footprint needed for more sophisticated social engineering or identity hijacking later in the attack chain.

Locking Down the API

1. Enforce Explicit Consent: Set the setting to “Don’t allow users to access any third-party apps.” This enforces a “Block by Default” stance, ensuring that no app can access user data until it has been vetted and trusted by an administrator.
   
2. Audit the “App Access Control” List: High-risk OUs, especially those like No-MFA-Users those seen in the sidebar, should have their current authorized apps audited immediately. Any app with high-risk scopes that isn’t a known business requirement must be revoked.
   
3. Scope the Trust: Use the Security > API Controls > Manage Third-Party App Access menu to whitelist only specific, verified Client IDs.

The OAuth “Yes-Man” Misconfiguration

When this is set to the default, Allow users to access any third-party apps you are essentially delegating your security perimeter to the judgment of your least-suspicious user. A single “Accept” click on a malicious or poorly secured app can grant that application unrestricted access to a user’s Drive, Gmail, or Calendar. Because this occurs within a legitimate OAuth flow, it often generates no “suspicious login” alerts and completely bypasses your Context-Aware Access architecture.

The False Sense of “OFF”

When you look at the sharing settings for a high-value unit, seeing the radio button set to OFF usually brings a sigh of relief. It implies that files owned by users in this unit cannot be shared outside the organization. However, this configuration often contains a subtle but significant “inbound” risk.

The Inbound Payload Vector

While outbound sharing is disabled, the checkbox “Allow users to receive files from users or shared drives outside the organization” is often left enabled. This creates a one-way valve that an attacker can easily exploit. Allowing internal users to receive external files opens the door to sophisticated phishing and malware delivery directly into the primary collaboration workspace.

Why does this matter?

• Trust Injection: An attacker doesn’t need to bypass a firewall if they can drop a malicious document directly into a researcher’s “Shared with me” folder.
  
• Payload Delivery: Because the file originates from a Google-authenticated account, it often bypasses standard email security filters and appears to be a legitimate collaborative request.
  
• Social Engineering Context: This setting is particularly dangerous for accounts without strong authentication. These users become the path of least resistance for an attacker seeking an initial foothold in the tenant.

Remediation: Tightening the Valve

• Block Inbound by Default: For highly sensitive units, uncheck the box allowing users to receive files from outside the organization to force data through inspectable channels.
  
• Use Trust Rules: Implement granular policies based on file type and specific external domains rather than using blanket allow settings.
  
• Audit “Shared with Me”: Regularly scan files shared with internal users for high-volume sharing from non-business domains.

Disabling outbound sharing is only half the battle. If the world is allowed to drop files into your researchers’ laps, a potential data leak has simply been replaced with a persistent infection vector.

The “No-MFA” Shelter

The most dangerous delusion in a Workspace environment is believing that a global “On” switch for 2-Step Verification (2SV) equals a secured identity perimeter. This configuration often hides a structural vulnerability: the “Permanent Exception”. By maintaining sub-units like the No-MFA-Users group, you aren’t just managing legacy friction; you are maintaining a designated landing zone for attackers.

Why does this matter?

• The Protected Haven: Attackers ignore your security keys and target the OUs where enforcement is set to Off or has a generous New user enrollment period.
  
• Persistence via Trust: The Allow user to trust the device setting is a gift for session hijacking; once a “trusted” cookie is stolen, the attacker remains invisible to your MFA prompts.
  
• The MFA-Type Trap: Relying on any method except Only security key or passkey leaves the door open to AitM attacks that easily intercept push notifications or TOTP codes.

Remediation: Closing the Gaps

• Kill the Exceptions: Audit the No MFA Users OU immediately moves any account without a documented technical blocker into a strictly enforced group.
  
• Shorten the Leash: Uncheck Allow user to trust the device for high-privilege research roles to ensure identity is verified for every new session.
  
• Upgrade to FIDO2: Transition the core team to Only security key or passkey to eliminate the possibility of credential interception.

If you leave a back door open to the “No-MFA” group, your front-door security is just expensive theater.

In a modern threat landscape, an identity without mandatory hardware-backed authentication is simply a ticking clock. When you allow “temporary” bypasses or long enrollment windows, you provide the exact window of opportunity a Red Teamer needs to establish a foothold that circumvents your entire context-aware architecture.

The Guest Reconnaissance Shield

Another piece of the puzzle isn’t about what people can do, but what they can see. Directory visibility is the cornerstone of internal reconnaissance. If you don’t lock this down, you are effectively providing a verified target list to every external entity you’ve invited into your environment.

The configuration for the Workspace Guests organizational unit should be set to No users. This ensures that anyone added as a guest can see absolutely no one else in the domain, preventing them from mapping your internal hierarchy or identifying high-value targets.

Why does this matter?

• Target Harvesting: If visibility is set to “All users,” a single compromised guest account becomes a goldmine for internal reconnaissance. An attacker can scrape the entire directory to find executives, IT admins, or researchers in the Guardz Research unit.
  
• Social Engineering Foundation: Knowing exactly who works in which department allows an attacker to craft highly convincing internal phishing campaigns. They can impersonate a specific colleague or manager with perfect accuracy.
  
• Discovery of the “Weakest Link”: An attacker will use the directory to cross-reference users against public data, identifying accounts most likely to belong to the No-MFA-Users group.

Remediation: Blacking Out the Directory

• Enforce “No Users” for Guests: Ensure the Workspace Guests OU is strictly limited to seeing “No users” in the domain.
  
• Audit Custom Directories: If guests must see someone for collaboration, use a Custom Directory to whitelist only the specific internal sponsors they are working with.
  
• Verify Inheritance: Check that the No-MFA-Users group hasn’t accidentally inherited a more permissive visibility setting from the parent Guardz Research unit.

In the hands of a hunter, a directory is a map of the fortress. By setting visibility to “No users,” you’ve just turned off the lights for anyone trying to find their way around.

The “Local Rule” Blind Spot

A hardened identity is useless if the communication channel itself allows high-risk content to bypass standard scrutiny. In the Spam, phishing, and malware settings for Guardz Research, we see a dangerous combination of “Enhanced” marketing labels and weak actual enforcement.

The Internal Trust Fallacy

The currently applied spam rule shows a critical misconfiguration: Bypass internal senders: ON. This setting assumes that because a message originates from within the @domain.com domain, it is inherently safe. For a researcher, this is a massive blind spot. If an attacker successfully hijacks a single account, they can use it to launch a domain-wide phishing campaign that will never hit a spam folder or trigger a warning banner for other internal users.

Why does this matter?

• Lateral Movement via Email: Once an initial foothold is gained, the attacker can send malicious payloads or AitM links to high-value targets in the Guardz Research group. Since internal bypass is active, these emails land in the primary inbox with full credibility.
  
• Bypassing Scanning: Even with Enhanced pre-delivery message scanning set to ON, those internal bypasses often take precedence, effectively turning off the very protection you think is keeping you safe.
  
• The Inbound Gateway Gap: With the Inbound gateway disabled, the environment relies entirely on Google’s default filters. While generally strong, the lack of a secondary inspection layer for specific OUs makes it easier for sophisticated, low-volume “hunter” payloads to slip through.

Remediation: Hardening the Filter

• Disable Internal Bypass: For high-security units, never bypass internal senders. A compromised internal account is often more dangerous than an external one because of the inherent trust associated with the domain.
  
• Force Aggressive Filtering: Ensure that Aggressive spam filtering is strictly enforced across all sub-OUs, including Workspace Guests and No-MFA-Users.
  
• Enable Warning Banners: Flip the Bypass approved senders and hide warning banners setting to OFF. If a message looks suspicious, the user should see a banner, even if the sender is on an allowlist.

Relying on internal trust within a research environment invites lateral movement. If you don’t treat internal mail with the same skepticism as external mail, your “Enhanced” scanning is just a decorative layer.

Useful tools and articles

Tools, scripts, and research PoCs for Purple Team, Red Team, AI Security, Forensic, and Cloud security. Authorized use only via this Security Research Lab on GitHub

More Research articles in Guardz Blog

Follow us on Linkedin