Red Teaming from outside: Identifying and exploiting SaaS systems for access

Red Teaming from outside: Identifying and exploiting SaaS systems for access

Speakers: Rojan Rijal, Co-founder, Orphan Security Incorporated

Conference: BSides SF

YouTube: https://www.youtube.com/watch?v=OF20oFJ_I1c

Overview

In this insightful talk, Rojan Rijal of Orphan Security delves into novel methods for red teaming organizations from an external perspective, specifically by identifying and exploiting common SaaS systems. The core premise challenges the conventional defensive posture of email security vendors, aiming to reverse their intended function – preventing fishing attacks – to instead facilitate them and gain internal access. Rijal demonstrates how misconfigurations or inherent design patterns in these systems, coupled with a deep understanding of email flow and SaaS identity verification mechanisms, can be weaponized by attackers to bypass security controls and infiltrate internal organizational resources.

The presentation outlines two primary attack vectors: first, leveraging email security gateways and domain capture features in SaaS applications, and second, exploiting various facets of Google Groups. Rijal provides concrete examples, including real-world scenarios with Netflix (conducted with prior permission), and walks through a live (though ultimately recorded) demonstration of gaining access to internal Google Groups. This talk is crucial for security professionals, red teamers, and system administrators seeking to understand sophisticated external attack paths and shore up defenses against often-overlooked vulnerabilities in widely used enterprise solutions.

Background

▶ Watch: Talk introduction and red teaming SaaS objectives (0:00)

The foundational context for Rojan Rijal's research stems from the ubiquitous presence of email security vendors and SaaS applications in modern enterprise environments. These vendors are primarily designed to protect organizations from malicious emails, particularly fishing attacks, by scanning incoming messages for suspicious content, URLs, and sender authenticity. This protective function manifests in two main forms: external reporting systems (where users report suspected fishing emails to companies like Apple or Facebook for investigation) and email security gateways (like Mimecast, Proofpoint, Barracuda, and Sophos, which act as intermediaries for an organization's email, filtering threats before they reach employee inboxes).

Crucially, both external and internal systems often employ a similar analysis process. After initial intake, emails undergo checks for grammatical errors, spelling, domain history, and most importantly, URL analysis. This URL analysis involves the security vendor sending unauthenticated GET requests to any links within the email, often mimicking various user agents (e.g., iOS, Android, Windows devices) to determine if a URL leads to a fishing page. This mechanism, intended for defense, becomes the primary target for Rijal's offensive strategy.

The talk also provides essential background on Google Groups, differentiating between public groups and the enterprise Google Groups prevalent in Google Workspace environments. Rijal highlights the nuanced permission layers within Google Groups, noting that while organizational-level settings define overarching security boundaries, individual group owners often have considerable control. A common misconfiguration or misunderstanding Rijal points out is the "private" setting for Google Groups. Many organizations believe this setting prevents external users from identifying or joining a group, even if other permissions might suggest otherwise. This misunderstanding forms the basis for a significant part of the presented exploits, demonstrating how an attacker can bypass perceived privacy controls to gain access to internal communications.

Key Findings

▶ Watch: Understanding email security vendors' URL analysis process (3:22)

Rojan Rijal's research uncovered several critical vulnerabilities and attack vectors across email security systems and Google Groups, demonstrating how external attackers can gain internal access:

1. Abusing Email Security Gateways for Valid Phishing Email Delivery:

• Initial Challenge: Directly sending phishing emails often fails due to robust SPF, DKIM, and DMARC checks.
• Exploit: Leveraging Amazon SES (Simple Email Service) and its email identity verification process. While initial attempts to verify an arbitrary email address (via a link click that security vendors might unfurl) failed SPF/DKIM, Rijal discovered a critical bypass.
• Bypass: Configuring a custom Mail From domain in SES. By identifying target organizations already using SES and possessing a verified subdomain (e.g., email.example.com or amazonses.example.com) with appropriate MX record and TXT record configurations, attackers can send emails that successfully pass SPF/DKIM/DMARC checks. This allows for highly convincing and legitimate-looking phishing emails to land in employee inboxes without being flagged.

1. Exploiting SaaS Domain Capture via Email Security Gateways:

• Mechanism: Many SaaS applications (like Atlassian, Slack, Dropbox) offer a domain capture feature, allowing users with a company email address to join existing workspaces. Verification often involves a link sent to the provided email.
• Exploit Chain: If a SaaS service verifies email ownership via an unauthenticated GET request (i.e., merely clicking a link, without requiring an active session or further interaction), and the target organization uses an email security gateway that automatically unfurls and analyzes URLs, the gateway will inadvertently "click" the verification link.
• Real-world Example (Netflix): Rijal demonstrated this by signing up for Atlassian with [email protected]. Netflix's third-party email security vendor, responsible for analyzing phishing reports, automatically unfurled the Atlassian verification link. This action inadvertently verified the attacker's Atlassian account, granting them access to Netflix's internal Jira and Confluence instances through the domain capture feature. (This vulnerability has since been fixed by Atlassian).

1. Google Groups Enumeration and Public Joinability (Despite "Private" Setting):

• Challenge: "Private" Google Groups are not visible to external users, making enumeration difficult.
• Enumeration Technique: Rijal discovered a two-step process:
• Utilizing the Google Group API (users.get) to confirm if a given email address is valid within a target's Google Workspace.
• Creating a public Google Group and attempting to "ban" the identified email address. If the email corresponds to a Google Group, the ban response will reveal the group's name and a hyperlink, confirming its existence and exact email address.
• Exploitation (Bypassing Privacy): Even if a group is set to "private," if its permissions allow "anyone on the web can join" or "anyone in the organization can join" (due to misconfiguration or misunderstanding), an external attacker can use the +subscribe email command. Sending an email to [email protected] will trigger a validation process. If successful, Google Groups will send a confirmation code. Replying with the +subconfirm email command (e.g., [email protected] with the code in the subject) adds the attacker's email to the group's mailing list, allowing them to receive all subsequent internal communications.
• Real-world Example (Netflix): An internal Netflix Google Group ([email protected]), though private, was found to be publicly joinable. After joining, the attacker used this newfound "Netflix.com" email identity to again leverage SaaS domain capture, joining other Netflix workspaces like Atlassian.

1. Google Groups Internal Posting/Joining via Managed Domains (HR/Support Platforms):

• Insight: Building on a discovery by Tanner (Edge Cache Money), Rijal investigated how Google Groups handle emails from managed domains. Tanner's finding showed that if a Google Group has "anyone in the organization can post" enabled, any email from a domain managed by that Google Workspace (even if the sender is not a defined user) can post to the group, provided SPF/DKIM/DMARC pass.
• Rijal's Hypothesis & Exploit: Rijal extended this to "anyone in the organization can join." He theorized that if an attacker could control an outbound email from the target's domain and receive inbound replies to that same domain, they could exploit this.
• Attack Vector: Targeting HR platforms and support platforms. These platforms often send emails on behalf of the organization (e.g., interview invites) and provide a unique inbound email for replies (e.g., [email protected]). Crucially, Google Groups prioritize the From header over the Reply-To header for validation.
• Exploit Chain:

1. Attacker signs up on a recruiting platform, creates a job, and adds themselves as a "candidate" with a +subscribe email address (e.g., [email protected]).
2. The platform sends an interview invite from [email protected] (a valid domain for the target).
3. Google Group sees the valid From header and sends a confirmation code to [email protected].
4. Since the attacker controls the "candidate" email, they receive this confirmation code through the recruiting platform's inbound email system.
5. The attacker then changes the candidate's email to [email protected] and replies with the confirmation code.
6. Result: The inbound email address ([email protected]) is added to the internal Google Group's mailing list, allowing the attacker to exfiltrate all emails sent to that group.

These findings collectively highlight significant blind spots in enterprise security, where the interplay of legitimate SaaS features and email processing logic can be subverted for malicious purposes.

Technical Deep Dive

▶ Watch: First attack vector: Abusing email security gateways (4:02)

The technical underpinnings of Rojan Rijal's attacks exploit specific behaviors of email security vendors and Google Groups. The first set of attacks hinges on the URL analysis performed by email security gateways. When an email containing a URL is processed, these gateways make unauthenticated GET requests to the embedded link. This is done to pre-scan for malicious content without associating any user session data. Crucially, these requests often cycle through various user agents (e.g., simulating iOS, Android, Windows browsers) to check for different rendering or redirection behaviors that might indicate a fishing page. The vulnerability arises when a SaaS application's email verification process is similarly simple: a single unauthenticated GET request to a unique URL is enough to confirm email ownership. When a security gateway performs its analysis, it inadvertently "clicks" this verification link, completing the attacker's registration without any human interaction.

To deliver the initial, legitimate-looking fishing email, Rijal leveraged Amazon SES (Simple Email Service). While SES allows verification of email identities, initial attempts to send emails from a spoofed domain failed SPF/DKIM/DMARC checks. The technical bypass involved configuring a custom Mail From domain. By default, SES uses mailfrom.amazon.com, which would likely fail authentication if the target organization doesn't use SES. However, if an organization has configured a subdomain (e.g., email.example.com or amazonses.example.com) with the necessary MX record and TXT record entries pointing to Amazon SES, an attacker can use this pre-verified subdomain as their Mail From header. This allows them to send emails that appear to originate from a legitimate part of the target's domain, effectively bypassing standard email authentication and landing directly in employee inboxes.

For the Google Groups exploits, the technical deep dive reveals several critical aspects. First, identifying the existence of private Google Groups, which are not visible through the standard UI, required a clever workaround. Rijal utilized the Google Group API, specifically a call that checks if an email address is valid within a Google Workspace. While this confirms an email's existence, it doesn't confirm it's a group. To do this, Rijal demonstrated creating a public Google Group and attempting to "ban" the suspected group's email address. The API response for banning a valid Google Group's email includes the group's actual name and a direct hyperlink to its (private) UI, confirming its existence and exact email address.

The core exploitation of Google Groups then relies on two specific email commands: +subscribe and +subconfirm. Sending an email to [email protected] directly interacts with Google Group's internal logic, bypassing the UI. If the group's permissions are set to "anyone on the web can join" or "anyone in the organization can join" (even if the group is marked "private"), Google will process the request. If successful, it sends a confirmation email containing a unique code. The attacker then replies to the group with [email protected] and includes the confirmation code in the subject line. This final step adds the attacker's email address to the group's mailing list, granting them full access to all incoming internal emails. This bypasses the visual privacy setting entirely.

The second Google Groups exploit, leveraging HR platforms and support platforms, exploits Google's strict reliance on the From header for email validation when processing group join requests. Google Groups does not respect the Reply-To header for permission checks. This means if a SaaS platform sends an email on behalf of an organization, and the From header contains an email address from the target's managed Google Workspace domain (e.g., [email protected]), Google Groups will treat that sender as part of the organization. Even if the actual sender is the SaaS platform, and replies go to a different Reply-To address, the From header's domain is what matters. By controlling the "candidate" email in a recruiting platform, an attacker can trick the platform into sending a +subscribe request from the target's domain, receive the confirmation code via the platform's inbound email system, and then use +subconfirm to join the internal group. This effectively turns a legitimate business process into an email exfiltration mechanism.

Finally, Rijal's testing of organizational units (OUs) within Google Workspace confirmed that users in different OUs or even subdomains (e.g., contractor.org.com) within the same Google Workspace are still considered "in the organization" for Google Groups permission purposes. This broad definition expands the potential attack surface for internal-only groups if the From header can be spoofed from any managed domain.

Demo / Proof of Concept

▶ Watch: Exploiting Amazon SES email verification vulnerability (5:14)

Rojan Rijal presented several real-world examples and a live demonstration (which transitioned to a recorded video due to technical issues) to illustrate the efficacy of his attack vectors.

1. Netflix Email Security Gateway & Atlassian Domain Capture:

The first practical demonstration involved Netflix. Rijal explained how they identified that Netflix uses a public email address, [email protected], for users to report suspected phishing attempts. They then signed up for Atlassian Cloud using this email address. Atlassian, like many SaaS providers, has a domain capture feature and sends an email verification link. A third-party security vendor, tasked with processing emails sent to [email protected], automatically performed URL analysis by unfurling the verification link. This unauthenticated GET request from the security vendor effectively "clicked" the verification link, verifying the attacker's [email protected] Atlassian account. Since Atlassian Cloud supports domain capture, the attacker was then presented with options to join existing internal Netflix Jira and Confluence workspaces, gaining access to internal information.

2. Netflix Google Group +subscribe Exploit:

Following the email security gateway abuse, Rijal identified multiple Google Groups within Netflix. One such group, [email protected], was found to be publicly joinable despite being marked "private." By sending an email to [email protected], the attacker received a confirmation code. Subsequently, replying with [email protected] (with the code in the subject) successfully added the attacker's email to the [email protected] mailing list. This granted the attacker the ability to receive all emails sent to this internal Netflix group. This "Netflix.com" email identity was then further leveraged to sign up for other SaaS applications that use domain capture, similar to the Atlassian example, expanding internal access.

3. Recruiting Platform & Google Group +subscribe Exploit (Work IQ.AI Demo):

The most detailed demonstration involved a simulated attack on a fictitious company using a recruiting platform similar to an ATS platform (Applicant Tracking System). The target domain was workiq.ai.

• Setup: Rijal first created a fake company account on workiq.ai, set up a job posting, and then added a "candidate" (which was actually the attacker's controlled email address).
• Inbound Email Flow Confirmation: An interview was scheduled for the candidate. The system sent an email from an address like [email protected]. The candidate (attacker) replied to this email to confirm that the inbound email flow was working and that replies were visible within the recruiting platform's interface.
• Google Group Enumeration: Using Burp Intruder, Rijal demonstrated how to enumerate potential Google Groups for workiq.ai by sending requests to the Google Group API and looking for specific responses (e.g., false values indicating an existing email ID).
• Group Existence Confirmation: To confirm that [email protected] was indeed a Google Group, Rijal used the "ban" trick. From a public Google Group, he attempted to ban [email protected]. The response included the group's name and a hyperlink, confirming its existence as a Google Group.
• +subscribe Request: The candidate's email address within the workiq.ai platform was changed to [email protected]. When an interview was scheduled, the recruiting platform sent an email from [email protected] (a valid domain managed by the target's Google Workspace) with the +subscribe command.
• Confirmation Code: Google Groups, seeing the legitimate From header from mail.workiq.ai, processed the request and sent a confirmation code back to [email protected]. This confirmation was received by the attacker through the recruiting platform's inbound email system.
• +subconfirm to Join: The candidate's email was then changed to [email protected], and a reply was sent with the confirmation code in the subject.
• Result: The [email protected] email address was successfully added to the internal [email protected] Google Group's mailing list. This meant all future emails sent to this internal group would also be forwarded to the attacker's controlled inbound email, allowing for complete exfiltration of internal communications.

Although the live portion of the workiq.ai demo faced an email workflow issue, Rijal seamlessly transitioned to a recorded video, which clearly depicted each step and the successful exfiltration of emails, proving the exploit's viability.

Defensive Implications

▶ Watch: Bypassing SPF/DKIM with custom Mail From domain (7:02)

The vulnerabilities highlighted by Rojan Rijal necessitate a multi-faceted defensive strategy for organizations. Addressing these issues requires a combination of configuration reviews, policy enforcement, and a deeper understanding of how SaaS applications interact with email systems.

For Email Security Gateway Abuse and SaaS Domain Capture:

1. SaaS Application Vetting: Organizations should rigorously vet SaaS applications for their email verification methods. Any service that verifies email ownership solely via an unauthenticated GET request (a simple link click without requiring an active user session or additional authentication) poses a significant risk. Prioritize SaaS providers that implement more robust verification, such as requiring a login after clicking the link, or a confirmation code entered on a secure page.
2. Email Security Gateway Configuration: While email security gateways are designed to protect, their URL analysis feature can be weaponized. Organizations should review if their gateway's URL unfurling mechanism can be configured to avoid inadvertently verifying accounts. If possible, consider features that only unfurl URLs from trusted domains or require explicit user interaction for verification links.
3. Amazon SES and Custom Mail From Domains: Regularly audit Amazon SES (or similar email sending services) configurations. Ensure that no subdomains belonging to your organization's primary domain have been configured with MX records or TXT records that allow external entities to send emails on your behalf without strict controls. Implement tight access controls on who can configure SES identities and domains.

For Google Groups Vulnerabilities:

1. Comprehensive Google Group Audit:

• Manual Review: System administrators must manually review every Google Group for the "anyone on the web can join" permission, even if the group is marked "private." The "private" setting only affects UI visibility, not joinability via email commands.
• API-Based Audit: Leverage the Google Workspace Admin SDK API to automate the audit. Specifically, identify groups where allowExternalMembers is set to true AND allInDomainCanJoin is also set to true. Rijal notes that this combination has a high probability of indicating a vulnerable group that can be joined externally.
• External Testing: Conduct proactive red team exercises or penetration tests by attempting to +subscribe to internal Google Groups from an external email address to confirm their joinability.

1. SaaS Outbound Email Configuration (HR/Support Platforms):

• Crucial From vs. Reply-To Distinction: This is paramount. When using HR platforms, support platforms, or any other SaaS that sends emails on behalf of your domain, ensure that the From header of these emails does not use an email address from your Google Workspace managed domain. Instead, configure these platforms to use a generic, unmanaged From address (e.g., [email protected]) and utilize the Reply-To header for inbound replies. Google Groups will only validate the From header for membership purposes.
• Separate Email Domains for SaaS: For critical SaaS platforms, consider using an entirely separate domain for outbound and inbound email communications (e.g., company-jobs.com instead of company.com). Ideally, this separate domain should not be part of your Google Workspace account, further isolating it from internal Google Groups.

1. Block Google Sign-ups for Your Domain: Proactively work with Google to block users from creating personal Google accounts using your organization's domain (e.g., preventing [email protected] from being used for a personal Google account). This helps prevent attackers from using joined Google Group email addresses to create accounts that can then leverage "sign in with Google" features on other SaaS platforms.

By implementing these defensive measures, organizations can significantly reduce their external attack surface and protect against sophisticated red teaming techniques that exploit the nuances of modern email and SaaS ecosystems.

Key Takeaways

• Email security systems can be weaponized: While designed for defense, features like URL analysis in email security gateways can be exploited to inadvertently verify attacker-controlled accounts on SaaS platforms.
• Unauthenticated GET-based email verification is a critical risk: SaaS applications that verify email ownership through a simple, unauthenticated link click are highly vulnerable, as automated security scanners can trigger these verifications.
• Google Groups' "private" setting is misleading: A Google Group marked "private" is not necessarily secure from external access. Attackers can enumerate and join such groups using specific email commands (+subscribe, +subconfirm) if underlying permissions are misconfigured.
• From header reliance in Google Groups is exploitable: Google Groups prioritize the From header over the Reply-To header for permission checks. This allows attackers to leverage legitimate HR or support platforms that send emails from an organization's domain to join internal Google Groups.
• Proactive auditing is essential: Organizations must regularly audit their SaaS email verification methods, custom email sending configurations (e.g., Amazon SES), and thoroughly review all Google Group permissions, going beyond surface-level settings like "private."
• Domain management matters: Carefully manage subdomains and ensure that outbound email from third-party SaaS platforms does not use From headers from your primary Google Workspace domain.

About the Speaker(s)

Rojan Rijal is the Co-founder of Orphan Security Incorporated. His work focuses on cutting-edge security research, similar to the findings presented in this talk. Beyond research, Rijal and Orphan Security also specialize in offensive attack surface management for red teams and provide comprehensive penetration testing services. He can be reached on Twitter via @Malexis or @OfianSecurity, or through LinkedIn, for further questions about his research or the services his company offers.