I don’t think the content was modified. If it had been then the signature would have been invalidated. The attacker found a way to send themself an email from Google that the author later replicated using Google workspace + a Google OAuth app. Then they replayed that because Google isn’t signing the “to” field.

> Then they replayed that because Google isn’t signing the “to” field.

Google is signing the To field (at least on all email they send me). The attacker didn't change that either, as displayed in the screenshots in the article. The attacker took an email legitimately sent from Google to them, then redirected it to the victim.

An equivalent real-world mail scenario would be me taking a letter from my bank to me, putting it in a new envelope, then sending it to you. Then your assistant takes it out of the envelope and puts it into your inbox. The letter in your inbox is a completely valid letter from said bank, intended for me.

There's two things in this article Google does badly: Allowing free input of an app name and putting it directly at the top of an email they send without preceding it with an indication what the email is about, and hosting user-managed websites on a subdomain of google.com.