Scammed Out of $130k via Fake Google Call, Spoofed Google Email and Auth Sync
Posted4 months agoActive4 months ago
bewildered.substack.comTechstoryHigh profile
heatednegative
Debate
80/100
ScamsGoogle Authenticator2fa Security
Key topics
Scams
Google Authenticator
2fa Security
A user was scammed out of $130K via a fake Google call and spoofed email, highlighting the risks of cloud-synced 2FA codes and the need for better security practices.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
35m
Peak period
135
0-6h
Avg / period
20
Comment distribution160 data points
Loading chart...
Based on 160 loaded comments
Key moments
- 01Story posted
Sep 16, 2025 at 12:50 PM EDT
4 months ago
Step 01 - 02First comment
Sep 16, 2025 at 1:25 PM EDT
35m after posting
Step 02 - 03Peak activity
135 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 19, 2025 at 11:53 AM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45264726Type: storyLast synced: 11/20/2025, 8:04:59 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
https://x.com/0xzak/status/1967592307714379934
A Horrific threat.
> In just 40 minutes, the attacker shuffled my staked ETH and other tokens through multiple transactions, then drained the account.
One of the many, many benefits of irreversible transactions.
> I made mistakes, yes
His first mistake was keeping six figures worth of 'cash' in a wallet that anyone with less than 40 minutes of access to can swipe.
My brother (a tech professional in California) does not have any crypto or social media, and attackers still stole his phone number, which they used to steal his email account, which they then tried to get into a non-existent Coinbase account. He was only out of the time it took to get his phone number back (a couple of hours later).
Can somebody explain what exactly this means, and how it works?
Basically, the from field on an email can be anything you want. It's like sending physical mail and using a fake letterhead with someone else's info, just type what you want. No verification.
That's sometimes a good feature. Like, a third party provider can send newsletters on behalf of company A. But can also be bad, when used for phishing.
However, the email doesn't just appear in your mailbox. It comes to your email provider by another server connecting to it and sending the email. Spf allows the owner of A.com to specify which IPs/servers are actually acting on their behalf. So if I get an email from something@A.com, I can lookup and verify that the sending server is one to trust. If not, the email client should reject or warn the user somehow.
I'm pretty surprised gmail didn't flag this at least. When I did it for a class in Uni, it always let me know that the FROM header didn't match the sender since that's a clear attack vector
I would also assume something as prominent as the Gmail website/app for iOS, and the google.com domain, would have all possible email security features correctly configured.
So.. is this not the case? Or is it, but due to bad UI, despite all this security, any schmoe can send email appearing to come from google.com, and I have to pore over unspecified details in the "full header" to spot a fake?
Apple Mail does allow you to see the actual sender if you tap on the name though. Outlook has been way worse in that aspect, by not letting you see the full sender. At some point it even saved these fake addresses automatically in your address book if it matched a contact's name or something. (I couldn't find the thread about it right now, but it has been discussed elsewhere.) It's a disservice to everyone except attackers to be honest.
We trolled each other in class with it a bit. But at one point some student not in our class sent out a mass email, which was against the rules. I replied with a From line as "Administrator" and a bunch of whitespace, telling the girl that she broke the rule and would be suspended for it. Our teacher made me apologize, and I was lucky that I didn't get into more trouble beyond that.
What clued me in was that he said he couldnt share the estate documents with me until I gave him my popup 2FA code.
You cannot spoof an email from @google that will inbox
This was not spoofed.
One of the best features of Apple iOS 26 is the new call-screening feature[1].
[1] https://support.apple.com/en-gb/guide/iphone/iphe4b3f7823/io...
This will be great tho to help cut down on iOS users and scams hopefully
Yeah, I would be curious to see the actual email headers of what was received.
As an aside, fun fact, this would not be possible with @apple.com because Apple employees have old-school S/MIME signatures as an additional security layer.
In theory, third-party places like gmail could (should ?) automagically verify S/MIME sigs where a root cert is readily available.
There's no system in place to warn the user when there is no signature and that there should be one.
A few do, but most do not, and certainly Apple's automated-system e-mails do not.
Deprecating SPF would do everyone a favour though. Especially for reasons like these.
Google owns and manages all of this, so they can send emails with a google.com MAIL FROM, a google.com header, and signed with a google.com DKIM key. And they could do likewise with gmail.com emails.
I'm not clear on why this isn't practical, perhaps there is something I'm missing though? I would appreciate your viewpoint.
Edit: I see you added a point about forwarding.
Your MTA can still check alignment for both HELO and SMTP From as specified by SPF's RFC(s) though and spam filters often do for extra information/signal.
DMARC's adkim/aspf aren't basically supported in practice. Nor they should be. For reasons already mentioned, as you already read.
Yes, SPF (the original design) is horribly broken and trivially bypassed. The most prominent design flaw is that the inbound SMTP service uses the SMTP (rfc5321) MailFrom address for SPF validation, which is not the same sender address shown to the recipient, they can only see the the message (rfc5321) 'From' header address. SPF originally didn't require the domains in the MailFrom and From addresses to match, so an attacker would simply use a domain they control in the MailFrom address, and the 'spoofed' domain in the From header.
That was in 10 years ago though. DMARC fixed this by adding the alignment requirement, meaning that the domains in the MailFrom and From address must match. By default the alignment policy is 'relaxed', meaning that the MailFrom and From domains can differ in subdomain, as long as they share the same organizational domain. Setting the SPF alignment to strict (aspf=s) like you mention in your post requires the domains to match exactly, with no subdomain differences allowed.
So, it doesn't matter that Google doesn't use strict SPF alignment in the DMARC policy, the fact that they have DMARC already adds the requirement to SPF validation that the domains must match.
Yes, google.com and gmail.com use the same IP ranges in the respective SPF policies, but Gmail will never allow you to send email addresses from a domain that you do not own. This is why domain validation is required when you set up Gmail with a custom domain.
The only scenario where your explanation would hold up, is if the attacker was able to gain control of the DNS of a subdomain of the google.com domain, and successfully validated it as a custom domain in Gmail, then send emails from that subdomain in rfc5321.MailFrom address and the google.com domain itself as the rfc5322.From domain.
https://undercodetesting.com/how-email-spoofing-exploits-spf...
https://easydmarc.com/blog/google-spoofed-via-dkim-replay-at...
There isn't any federal regulation at all covering your Bitcoin.
Unrelated, but for added spice, here's a thread from ten months where everyone agrees you're a fool unless you secure your coinbase account with google authenticator
https://www.reddit.com/r/CoinBase/comments/1h65zuh/account_h...
With my bank, I've been able to recover several thousand after a thief was able to bypass the 2FA app used to verify large transfers. (I still don't know how they were able to bypass the verification, and after investigating our bank never told us. Not sure that makes me feel all warm and fuzzy, but at least I was made whole with minimal fuss.)
With the former, your recourse is essentially zero. Banks won’t do anything, cops are useless.
With the latter, banks try to prevent it and it’s harder and riskier.
In USA, banks are actually required by law to reimburse fraudulent account activity if reported within 60 days. However, this does not cover cases where the account holder themselves made the transfers even if they were tricked into doing so.
But if someone gets your login and liquidates your bank account, in USA a least, the bank is 100% responsible for that fraud.
Credit card companies are 100% responsible for fraud regardless. Even if they try to market it as a perk "You're never responsible for unauthorized transactions". Yeah, no shit. It's the law.
Doesn't seem like there's a lot of middle ground between being responsible for your mistakes and being treated like you can't be trusted to make your own decisions.
I wonder sometimes how many scams I've avoided simply by pretty much never answering my phone when someone calls unless I'm expecting a call or it's someone I know.
> The attacker already had access to my Gmail, Drive, Photos — and my Google Authenticator codes, because Google had cloud-synced my codes.
Ugh, google
I was pretty suspicious but thought I would get them to authenticate their identity as someone really from Amazon by telling me the last thing I had really ordered was...
I must have stayed on the call for 20 minutes, eventually they ended up swearing at me - all the time I could hear other people in the same room trying the same lines on different people. I have no idea why I stayed on for so long....
I do not answer calls
Maybe 3 or 4 of these a day <sigh>
Then because of the leak side channel effect they can further future target calls such as coming from google about your problem with "your pixel 9 or 10?"
They have the scammers working off phone queues, it takes a little bit of time to get the call to the scammer, who has to start off with a script, so there's a delay.
Remember, the scammer, also likely not a native english speaker, also probably bored out of their mind, has to spin up, they have to read the name, understand how to say it and then say it out loud. Their is a mental startup time that a normal conversation doesn't have.
If someone calls you and isn't ready to immediately respond to "hello" it's a scammer.
Personally, I would utter a confused "hello?" if I was calling somone, the ringing stopped, and no one said anything, but I guess not everyone would.
https://support.google.com/phoneapp/answer/9118387?hl=en
The attacker had access to the Google account which includes passwords from Chrome and also the 2fa codes stored in Google Authenticator, because those were synced to Google without the author noticing it.
So with passwords and 2fa the attacker could login to Coinbase too.
They're saying that the least likely part of the cover story is that Google would proactively reach out to you in order to help you personally with the service you are (most likely) paying zero dollars for, and assign one of their most expensive employees to the case.
I assumed this was normal.
What a shit show.
I certainly don't. Every call I get from the school seems to come from a different number. And the camp she was at when she hurt her leg and had to be taken for immediate medical attention.
I get it, in your world, in your experience, it all works out. But in mine, it just doesn't. From experience, I _know_ this is true.
Never, ever, use a cloud password manager, that's just dumb. Combining these things together in some sort of master account -- be it Google, Apple, Microsoft -- is also terrible. It's like leaving all of your savings accounts, checking, and investments at a single bank.
All of this stuff is going to get way worse because of AI. You'll be talking to real people you know personally who are 100% not AI but were tricked in to asking you to do something by other AI enabled scammers. However aggressive I've suggested people be in the past probably isn't going to be enough for 5 years from now.
These things have always been possible, and have been done, but now they can be done at scale, with advanced testing to figure out what works on who, whereas before it was targeting the guy who kept posting pictures of expensive watches on his public Instagram.
Great advice for someone who doesn't have children or family members with health conditions.
Do people actually downvote this? Seriously???
Friend’s mother got scammed. She’d contacted tech support and they said they’d call back. Then a scammer just happened to call her within that next hour…
Getting a procative call for my benefit would make me very suspicious about the authenticity of that call!
In my experience most authenticators cloud sync automatically, at least on iOS. For most people, this is a benefit. Otherwise, lose your phone and you're stuck, I doubt most people secure recovery codes properly either.
The answer is almost certainly greater than 0.
Ever since then I've been getting hundreds or thousands of Google notifications I've had to decline. Anyone know how people are able to send out hundreds of 2FA gmail notification popups without Google blocking this?
Most clued-up places enable you to register a Yubikey as 2FA.
So then it doesn't matter if you loose your OTP app and your backup codes because you've still got a Yubikey.
(And those that don't allow Yubikey, almost certainly will have SMS as a secondary option).
Still, better to just not do SMS auth. These days Yubikeys are not that expensive. Get three, register them all at the most important places, and put one at a parents’ place or similar.
But the point I was making that IF the website does not allow Yubi THEN SMS is almost certainly available, and you should use that as a backup mechanism.
Why ? Some sort of backup mechanism is better than none at all.
And what happens if you lose your Yubikey or it stops working? You're back to needing backup codes or an additional 2FA device
488 more comments available on Hacker News