A Student Account Weaponized Google's Own Script Engine

A phishing email hit a public school district's inboxes with a subject line engineered to make people click before they think: STAFF BULLYING VIOLATION. It sailed through authentication with a clean SPF, DKIM, and DMARC pass. There was no spoofed domain to blocklist and no lookalike address to flag. The sender was a real Google Workspace account that had existed since 2015, and the only link in the message pointed to Google's own servers. This is what an attack looks like when there is nothing obviously fake to catch.

Four mailboxes were quarantined before this one stopped moving. Here is how it worked, and why the usual defenses had nothing to grab onto.

The Pretext: Fear and Authority Packed Into a Single Line

The attacker did not need a clever technical lure. The subject line did the work. In a school district, a message flagged as a bullying violation carries the weight of policy, liability, and reputation. Staff are trained to take those reports seriously and act fast. That instinct is exactly what the attacker rented.

The body was minimal. One call to action, "CLICK HERE TO VIEW," and nothing else worth reading. The email went out as a bulk BCC to district staff, so no single recipient saw the distribution list or realized dozens of colleagues had received the identical alarming notice. Fear plus authority plus a single obvious button is a well-worn recipe, and it works because it collapses the gap between reading and clicking.

The 2024 Verizon Data Breach Investigations Report puts the human element in 68% of breaches, and it clocks the median time to click a phishing link at roughly 21 seconds. A subject line built to alarm is designed to shorten that window even further.

Why Every Authentication Check Passed

The sending identity was the interesting part. The message came from a high school student's mailbox on an affiliated school-network domain that had been registered back in 2015. This was not a spoof and not a fresh throwaway. It was a legitimate, aged, Google-hosted account that had been compromised or was being abused directly.

Because Google actually sent the mail, every authentication signal lined up:

• SPF passed, because the message left Google's authorized sending servers.
• DKIM passed, signed with the school domain's key using the standard google selector.
• DMARC passed, with the domain publishing a p=none policy.

DMARC and its companion checks confirm that a sender is who they claim to be. They say nothing about whether that authenticated sender means you harm. A hijacked but genuine account is the blind spot for credential harvesting, and the p=none policy meant there was no enforcement layer to add friction even if alignment had wobbled.

For a legacy Secure Email Gateway leaning on domain reputation and authentication verdicts, this message reads as trustworthy. There is no bad domain in the headers, no failed check, no reputation hit. The verdict is clean.

Google Apps Script as a Credential-Capture Host

The single link did not resolve to some newly registered attacker domain. It pointed to a Google Apps Script exec endpoint, a URL under script.google.com that runs code on Google's own cloud platform. A published Google Apps Script produces a public /exec address that can render whatever HTML the attacker wants, including a pixel-accurate credential-capture form.

This is the part that defeats blocklists. The destination is a google.com address. URL reputation services trust it, link scanners see a legitimate Google service, and a human hovering over the link sees a familiar brand. Microsoft's Digital Defense Report 2024 documents how attackers increasingly abuse trusted cloud services precisely to launder their infrastructure through reputation they did not have to earn.

So the attacker had zero owned infrastructure to defend. No domain to register, no server to stand up, nothing that could be taken down or added to a feed. Google supplied the sending identity and the hosting, and the SEG had nothing to block.

MITRE ATT&CK Mapping

The tradecraft maps cleanly to the MITRE ATT&CK framework:

• T1566 Phishing: the delivery of a socially engineered message to elicit action from district staff.
• T1566.002 Spearphishing Link: the single embedded CTA routing to a credential-capture page rather than an attachment or reply.

The distinguishing feature is that both the sending identity and the payload host were legitimate services, which is why signature and reputation controls came up empty.

Indicators of Compromise

All indicators are defanged. Do not click or resolve.

How Behavioral Detection Catches What Authentication Cannot

If every technical signal is clean, detection has to look at behavior instead. That is where an education-focused email security approach built on relationship and anomaly modeling changes the outcome.

A student mailbox has no history of emailing district administrative staff. When that account suddenly fans out a bulk BCC with an alarming subject line and a single external link to a script host, the pattern is anomalous no matter how perfect the authentication looks. Themis, the Adaptive AI at the core of IRONSCALES, scores sender-recipient relationships, message intent, and link behavior together rather than trusting an SPF pass in isolation. A first-contact sender pushing urgency toward a credential form is the exact signature it is tuned to flag.

CISA's guidance on stopping the phishing attack cycle makes the same point from the defender's side: reducing the attack surface means catching the behavioral tells, not just the technical ones.

The Takeaway

Authentication tells you a message is genuine. It does not tell you it is safe. When attackers borrow a real account and host their payload on Google's own platform, the entire model of blocking bad domains and trusting good ones falls apart. Fear does the social work, legitimate infrastructure does the technical work, and your gateway waves it through.

The only durable answer is detection that reasons about behavior and intent, because that is the one thing the attacker could not fake.

See Your Risk: Calculate how many threats your SEG is missing