Google spoofed via DKIM replay attack: A technical breakdown
95 comments
·July 25, 2025brongondwana
btown
How would this work with mailing lists/groups? A common pattern is to have emails from third parties to e.g. accounts-payable@example.com be auto-forwarded to members of the relevant team.
Would the end recipient team member's receiving system need to be set to "trust" the mailing list forwarder, or internally track what lists it is on to be able to understand that the original recipient accounts-payable is a valid recipient?
brongondwana
Glad you asked! In a similar way to ARC (but better). The mailing list/group would add its own signature, and potentially a Delta-Body or Delta-Headers describing what changes it made (so that the verifier could undo the changes and verify the original signature, plus determine which changes were made by which hop).
So you'd have something like:
DKIM2: i=1; mf=sender@trusted.com; rt=accounts-payable@example.com; d=trusted.com
DKIM2: i=2; mf=bounce@example.com; rt=me@mydomain.com; d=example.com
So I could tell that the message came through example.com, and verify their signature on the message, as well as verify that trusted.com had intended the message to go to example.com in the previous hop.
latchkey
This is amazing and I really appreciate you commenting here, but wow, my gut feeling is that this just feels like a yearly car registration sticker on top of the previous year and then a razor blade cut through it to prevent someone from stealing it.
At what point do we rip it all off and restart?
brongondwana
Bah, the datatracker doesn't list the candidate documents. Here's some direct links:
https://datatracker.ietf.org/doc/draft-chuang-dkim2-dns/
https://datatracker.ietf.org/doc/draft-gondwana-dkim2-header...
https://datatracker.ietf.org/doc/draft-gondwana-dkim2-modifi...
https://datatracker.ietf.org/doc/draft-robinson-dkim2-bounce...
https://datatracker.ietf.org/doc/draft-robinson-dkim2-messag...
ddtaylor
I actually have had the FBI seize all of my Google account materials before when I was convicted of computer hacking. The search took place in 2016 and 2018 as they came back and took everything a second time.
Anyhow, they don't do it at all like this. I would have to check my discovery for some details and it's in cold storage, but they basically just send an e-mail to a specific department at Google and have that communication. They go through a decent amount of trouble to try to NOT tip you off.
ianhawes
I'll fill in the details for the curious. You receive an email from `usernotice@google.com` with this body:
Dear Google user,
Google received and responded to legal process issued by the United States Department of Justice (<FEDERAL DISTRICT>) compelling the release of information related to your Google account. A court order previously prohibited Google from notifying you of the legal process. We are now permitted to disclose the receipt of the legal process to you. The agency reference number or case number on the legal process is <DISTRICT COURT CASE NUMBER>.
For more information about how Google handles legal process, view our transparency report at http://www.google.com/transparencyreport/userdatarequests/legalprocess/.
Google is not in a position to provide you with legal advice or discuss the substance of the legal process. If you have other questions regarding this matter, you may wish to contact an attorney.
Please reply to this email and/or include the case identification number located in the subject line in any further communications regarding this matter.
Regards,
Legal Investigations Support
Google LLC
In the case of a Federal Grand Jury subpoena, the Government will request a delayed notification of 1 or 2 years to prevent the service provider (i.e. Google) from notifying you. A subpoena only provides generalized records and not content. So things like billing information, login records, etc.. are fair game. The government is required to obtain a search warrant for actual data (i.e. your emails). Typically, Google will not notify you about executed search warrants against your account.
zOneLetter
It's a Friday and your comment is the first thing that got me 10% awake. Please, do spill the tea. There must be a story there...
NitpickLawyer
Interesting. Would that request somehow get logged / tagged at some point and make its way into "your" account full data in say a GDPR "give me all the data you have related to my account" type of a request?
edm0nd
Let me guess, the raid warrant got signed for either CFAA violations, wire fraud, or a conspiracy charge.
Hope you lawyered up and came out okay.
arianvanp
I've seen a similar attack in my inbox recently where people do the same trick by sending an email to yourgoogleaccount@google.com instead of Gmail.com and then forwarding the bounce from Google's mail servers to yourgoogleaccount@gmail.com with a spam message smuggled at the end.
Passes all checks. Just kinda weird that a postmaster error is intertwined with a phishing campaign. But easy to gloss over as a non-technical user.
In my case the phishing campaign told me I won some construction tools or something.
slig
I've been getting those for weeks, makes me think Google has given up email.
btown
IMO the real vulnerability here is that you can put a URL in the App Name for a Google OAuth app, and Google will render that in no-reply emails to arbitrary addresses from its root domain. (And even if that render is not clickable, if you make the surrounding text scary enough, the victim will navigate there.)
The fact that any number of keep-DKIM-intact forwarding services can be stacked on top is almost secondary - though educational.
There should be no legitimate reason for the App Name of an OAuth app to contain a URL, and especially one containing google.com. That is where this should be fixed.
oefrha
This is a very confusing read. It gives the impression that the attacker managed to manipulate the email body to insert their phishing link, by talking at length about how the sites.google.com link is suspicious (of course it is, no doubt about that). But at the same time, they don’t say or show evidence that the body was manipulated; in fact quite the opposite.
My understanding is that the DKIM signature contains a bh= field with a hash of the email body. While you can technically also include an optional I= field to limit the body length for hashing, so that an attacker can append to the body, which is a pretty big security hole, it’s probably never used by Google for such short emails (I checked some of my own emails from no-reply@accounts.google.com and they certainly don’t have I=). Therefore to pass DKIM and DMARC the body had to be intact, so the “phishing link” was actually from Google, just intended for a different recipient.
If my analysis is correct then TFA really is a lot of words to say a scary email was forwarded to wrong people to scare them. Scary of course, but much less scary than the “DKIM replay attack” title implies to technical people who are not deep into this subject.
Edit: Oh, I thought “The Takeaway?” was the end of TFA since it had CTA for their product. Apparently there’s an update below explaining the link was actually part of a Google OAuth app name which was then inserted into Google’s email template. Terrible writing and structuring of the article, burying arguably the most important part of the attack that made it somewhat convincing, and misleading readers to believe the attack can be used to send arbitrary content.
Edit 2: Other commenters pointed out that the screenshot of the email is conveniently cut off so the fixed part of the Google email template isn't shown. The attack is probably even more clumsy then it seems from the quite deceptive crop.
monospacegames
I agree, the article is intentionally deceptive. It's written to make people think the part of the mail shown in the image is the whole email when in reality it's definitely followed by some text that would raise suspicion in any person.
dylnuge
And from what they do show, it doesn't look like the sites.google.com link was actually clickable, which will reduce the success rate of the attack substantially. I'm not sure if it's not clickable because the OAuth App Title field that the phishing contents is put in won't produce clickable URLs, because the email itself has been flagged by Gmail as suspicious and disabled links, or possibly both.
From what we do see we can also clearly see the "forwarded message" details are present at the top of the email. Then the author writes that the email has "no typos" while ignoring that it has very suspicious formatting. It's still likely people will fall for it, but the article author clearly is being deceptive about how sophisticated this attack actually appears.
notepad0x90
Most people, even those looking out for something suspicious will let their guard down once they are convinced it is from a trusted and known source.
atoav
> some text that would raise suspicion in any person
As someone who worked in IT-support I have to say this sentence is doing a lot of heavy lifting. I have seen people click on shadier things that looked much less credible. In fact I have seen the same people do it multiple times, even after it has been explained to them, multiple times and they have experienced consequences in the form of locked accounrs and the likes.
Real world users can be magnitudes dumber than you think they would be, even if they otherwise simulate the appearance of functional adults.
I have seen people who have a problem click away error dialogues with the explaination of the problem without reading the text. When asking what they clicked and why, they couldn't tell you if their life depended on it.
monospacegames
Yes, but my point is that the article is constructed in a way that deliberately obfuscates that there is unrelated text following the phishing message (quoting my initial comment: The full email is definitely in the format "scary text here" "actual google message", so something like "Give us all your money or die has been created as a google app")
This led to the initial response here being quite frantic (some people even claiming that DKIM is now pointless) because presumably not everyone read the article to its very end where the actual explanation is, and then went back to the first image to realize that the author has been intentionally misleading to sell their cybersecurity services.
bootsmann
Yeah from what I understand the DKIM is checking out because they are literally forwarding an actual email they got from Google. The real attack vector is being able to coerce Google to send you an email whose text you control.
sandos
Oooooh, finally!!!
I received almost exactly this email a couple of months ago, but targeted at a google domains admin! I was, of course, also spooked by it. I did wait out and avoided clicking links in it, but I could not really find any references to this scam.
What gave it away was that all email-addresses were masked, and those masks did not match up with any emails that I administer as a workspace admin. But yes, the email itself was legit, I googled that and the text passage matched. In my case it was an email for a deceased persons email, which ofc also did not match reality. But I was almost 100% at some point that someone had actually convinced Google I was deceased, and was going to access my entire Google account, talk about scary!
userbinator
Step 3: Attacker sends the email from Outlook
AFAIK you can't spoof the path listed in the Received: headers as all the servers on the path will add their own. That's always been my way of verifying where emails come from, and it's reassuring to know that I would've caught this one too. Emails coming from Google aren't going to take a detour through Microsoft servers.
KevinMS
You cant spoof the header of the last trusted server, that's it.
emsixteen
I'm going to go out on a limb and guess you don't manually check the headers for every single email, or even only every one from Google and co, so are you doing something to flag or visualise this in some way?
tharkun__
I'm with the person you are replying to here.
Whenever I get an email that seems like it's a scam or scary like this I will open headers and the Received headers (sometimes even a From et. al. are enough) will give it away.
In zero cases did I care about SPF, DMARC or DKIM.
I recognize that this is not something non technical people or even technical people that don't know how email works and that don't have a broader technical ability/knowledge can usually use/do but it has worked 100% for me so far. knocks on wood.
I literally only skimmed the article looking for any place they might show all headers and finally when they had the list of Received I was like: duuuh, that's the first you should have looked at and this would be a non blog.
So of course it's still bad this happens as most folks, even technical ones, couldn't read email headers to save their lives and rely on little badges and filters based on things like DKIM to keep them safe.
userbinator
The sibling comment basically answered for me; I don't check the headers unless I'm feeling suspicious, and such an immediate urgent call-to-action definitely counts as suspicious.
It helps that I'm using a client which shows all the headers by default, and I normally just scroll past them if I don't have doubts; all the mainstream consumerist ones seem to make that very difficult or even impossible.
If anything, it seems hiding these details is a way to increase blind trust in things like DKIM and promote learned helplessness, so they have the incentive to make clients opaque.
asimpletune
This is terrifying. Imagine trying to explain to a relative the lesson of this post: always be suspicious, even if the email is from a trusted domain and dkim/dmarc/spf all pass… it doesn’t feel good to imagine their reaction.
This is still limited in what you can do though. For example you can’t use this to forge messages from other people’s Gmail accounts.
> When the message is forwarded, the original DKIM signature usually remains untouched as long as the email content and headers covered by the signature are not modified
It does seem surprising the To: header isn’t one of the headers that is covered by the dkim signature. They should just change how their signing is configured, and email clients should warn when the email is legit but the intended recipient could have been changed.
bawolff
> Imagine trying to explain to a relative the lesson of this post: always be suspicious, even if the email is from a trusted domain and dkim/dmarc/spf all pass
Imagine explaining to a relative what dkim/dmarc/spf is!
These are all behind the scenes technology that users should not be aware of.
Honestly this attack is not as scary as it sounds. The article is being misleading to sell their product.
> It does seem surprising the To: header isn’t one of the headers that is covered by the dkim signature.
I dont think that would really matter. How often do you read the To header. Keep in mind that in email the To header does not have to include the intended recipient.
fc417fc802
> How often do you read the To header. Keep in mind that in email the To header does not have to include the intended recipient.
Perhaps if the address at which you received the email does not match any which are covered by the DKIM signature then your client could warn you about the potential for foul play?
bawolff
I don't think that would be a good idea. The false positive rate would be too high and i don't think forging the to header is useful enough to phishing to make it worth it.
null
salawat
>These are all behind the scenes technology that users should not be aware of.
Every time I hear this statement, alarm bells ring in my head. We aren't immortal. None of us is omniscient, and unfortunately the bad actors we're trying to protect against obviously don't give two shits about getting their hands dirty. We can't just hide all implementation details from users, especially when today's users may of necessity become tomorrow's admins.
JoshTriplett
> always be suspicious, even if the email is from a trusted domain and dkim/dmarc/spf all pass
This was the default state of email for a long time, and is still the level of caution some people apply to email: never trust `From`.
globular-toast
I've blown people's minds by spoofing "From" before. It's amazing the completely unwarranted level of trust people have in things. I tell people it's no different from me typing up a letter and putting "love from Mum" at the bottom.
I blame shiny email clients like Outhouse etc. It's really dangerous to make something look like a better system than it is. If email were still viewed as plain text I don't think it would be seen the same.
bawolff
Note, you can't forge the from header if DMARC is turned on. The From header was not forged in the article afaict.
It doesnt really matter because email clients usually dont even show the email part of the from header.
aaronmdjones
> It does seem surprising the To: header isn’t one of the headers that is covered by the dkim signature
It is, which is why they had to preserve it. The screenshot of delivery under the reproduction section shows the original To: address. This isn't the address that it is delivered to; you can deliver an email to any address with any other To: field in it.
tmdetect
My advice here is pretty standard: If you get an email that requires an action, go to the website directly. Don't click any links.
It adds friction, but does solve the problem. For banking/systems, I'd much rather have the friction.
logifail
The author writes:
> "Here is the URL from that email [..] https://sites.google.com[...]"
THAT link is the first red flag, and I think the author should say so right there, not three paragraphs later.
seszett
No, you can't expect everyone to know about every subdomain of google.com.
I think the real failure here (besides the unlimited field in the SSO) is Google allowing user content under a subdomain of their main domain (and there might be others, like Drive).
michaelmior
> I think the real failure here (besides the unlimited field in the SSO) is Google allowing user content under a subdomain of their main domain (and there might be others, like Drive).
IIRC, this is the main reason GitHub moved Pages to github.io
michaelt
The other reason is: If a user figures out a way to upload javascript and have it work, you don't want them to steal other users' login cookies.
This is why your gmail attachments should show up on googleusercontent.com instead of google.com
Many years ago, some naive websites would let users upload images, but wouldn't validate their content; and some browsers would ignore file content type headers if they had a better guess. So an attacker could rename a .html to a .jpg, upload it as your user profile image, then direct people to www.example.com/avatars/eviluser.jpg and they'd get a HTML page and run its javascript.
That's why, to this day, you sometimes see websites sending the header "X-Content-Type-Options: nosniff" which tells Internet Explorer 8 not to guess the content type.
asimpletune
The main failure is that dkim still passed even though the email was modified in important ways.
seszett
Well there are a few different big failures, from not signing the To: to allowing long arbitrary content in an email sent from a legitimate Google address...
But I think Google sites is the most important one because it makes sites look like they are actually Google wherever one comes from, it could be a pop-under loaded by another site or whatever, I think it's a more universal avenue for phishing than just exploiting DKIM.
aaronmdjones
The body of the e-mail was not modified whatsoever. Nor were any of the signed headers of the e-mail, including the Subject, From, and To headers.
pbhjpbhj
There have been a few exploits over the years relying on sites.google.com because of the need to use a subdomain to make things work for the exploiters.
I don't think I've ever seen Google advertise Sites either? Why not GoogleSites.com?
iwontberude
This criticism is not for everyone, it’s for us, the audience on HN that want novel stuff that is more hard than this. This is boring.
tmdetect
A red flag for you yes, but your parents?
rkerno
This to me just appears to demonstrate what a house of cards email security really is....surely with the collective brains on this forum we can come up with an alternative that solves all of this. And surely Google needs to serve these sites under a different domain name....why aren't these sites published under something like 'hostedbygoogle.com'?
jerf
All of the alternatives that can actually happen involve handing over full control of the system to one company, and thereby eliminating email's major remaining value, which is that it is a thing not controlled by one company.
The technical problems are challenging but solvable. The human problems are not. Nobody with the resources to truly solve the problem is willing to do it to create an open platform where they don't get effectively all the money and control, but then, the rest of the world is not terribly willing to let them have all the money.
Hence the impasse we are at.
This is the problem you have to solve, not a technical one.
(See also "why the metaverse where we do things like share avatars across all services is a stupid idea that will effectively never happen". It writes well in a novel, but in practice it requires World of Warcraft to accept that someone can run around in it as Mickey Mouse while wielding a Call-of-Duty-branded sniper rifle, and none of the relevant rights holders will ever agree to that, for all kinds of reasons. The technical problems are also formidable but they are nothing next to the fact nobody will ever agree to this.)
monospacegames
Announcing new Thiel-backed startup: Shadowfax
Our secure, centralized and proprietary offering with native AI and blockchain layers will replace the obsolete cruft that is email. Already secured several DoD contracts and expect to fully replace email for all internal and external communications of the federal government by 2027.
anxman
The wildest part about this? The phishing URL is still live on Google Sites! This article came out 3 months ago!
I'm working on the solution to this (co-authors from Google and Yahoo, it's legit):
https://datatracker.ietf.org/doc/draft-gondwana-dkim2-motiva...
Note that it doesn't help avoid Google actually sending out a message with user-provided text in it, but it does stop it being replayed to you without Google intending it, because the SMTP FROM/TO are protected.
The motivation draft doesn't include technical detail, see early drafts of the technical detail in the various related docs at:
https://datatracker.ietf.org/wg/dkim/documents/