Google y Phishing: Cuando el Gigante se Hace Cómplice - Irina Puebla // Southax

### Overview During a Friday shift at a Security Operations Center (SOC), an analyst investigated what initially appeared to be a typical phishing incident and uncovered a broader email security flaw involving Google Workspace (G Suite). A manager (anonymized as "Messi") received a suspicious email redirected from a former employee's account (anonymized as "Fideo"). The email carried classic phishing indicators—attempting to induce fear and urgency around confidentiality under the subject "salaries attached" with an HTML file attachment. However, the technical underpinnings revealed an unexpected behavior: an internal Google IP was delivering spoofed email using the company's own domain despite SPF and DMARC configurations.

### Key Topics - **Incident Discovery:** Handling an urgent phishing report regarding confidential salary information forwarded via an offboarded employee's email forwarding setup. - **Authentication Anomalies:** Observing SPF and DMARC failures where normal enforcement did not drop the email due to complex routing mechanisms. - **Inbound Gateway & Routing Rule Interaction:** Analyzing how incoming spoofed emails sent to a Google Workspace account bypass checks when routed through both an inbound gateway and an internal routing rule. - **Historical Precedent & Vendor Response:** Tracing the vulnerability back to a report originally published by a researcher named Alison in 2020, and addressing vendor delays in remediating email routing bypasses.

### Technical Details Under standard SPF (Sender Policy Framework) and DMARC verification, a mail server validates sending IPs against DNS records authorized for a domain. In this incident, an attacker sent a spoofed email to a G Suite / Google Workspace account configured with two specific features: an inbound gateway (a frontend gateway handling inbound emails prior to delivery) and an email routing rule (set up to automatically forward emails addressed to a departed team member to the manager). When combined, neither mechanism validated the true origin of the message, resulting in a "Spider-Man meme" scenario where each check deferred to the other. Authentication logs showed that while SPF and DMARC failures were detected, no enforcement action occurred because the forwarded request evaluated against the internal hop/GET request rather than the original external source IP.

### Takeaways Despite the issue being identified as far back as 2020 by external research, it remained exploitable years later, with vendor communications offering little immediate remediation beyond general mentions of future security measures. The speaker emphasized that organizations cannot place blind trust in major tech platforms to handle email security by default. Organizations must audit their email infrastructure—specifically examining who has active routing and forwarding rules, how long those rules persist, and how inbound gateways interact with authentication policies—while relying on qualified human analysts to detect and mitigate underlying configuration blind spots.