— no support group from a big company is going to call you. Ever.
— never give out codes sent to use via sms or push notifications to someone requesting them via phone or email. Never. The messages often even say that!
— Don’t put all your private info behind one password, so don’t use Google Authenticator backed by your Google Account as your password manager. Always use a third party like 1Password or similar.
— Don’t have the same email you use banking and investments be the email that the world knows. Create a new email for that. If you use Chrome, even use a separate profile with that email, and only have your password manager as an extension. No others.
ApolloFortyNine · 22m ago
Google support actually did ask me for that code when I had them disable energy savings on my nest thermostat. (it's insane that this had to be done through support, it's the setting where the power company can essentially control your thermostat in exchange for savings)
To their credit/discredit, when I said no I'm not giving that out it says not to they just moved on. Not sure why they even asked then.
Loughla · 18m ago
Google business support called me to close the loop on an issue I had with a business listing. It was from a very busy and loud call center, and was made by someone with a heavy accent.
It's like they want us to get scammed?
mandeepj · 14m ago
Include SPAM call blocker in that list! Notably, both iOS and Android have that feature. Never pick the first call from an unknown number! If it's urgent and they are genuine, they'd leave either a voicemail or a text.
gpt5 · 45m ago
> never give out codes sent to use via sms or push notifications to someone requesting them via phone
Unfortunately, some call centers DO use that for verification in some cases (i.e. you call them, and they send you a code to your email/phone that you read back).
sroussey · 44m ago
I’ve personally never had that happen. It should go on a name and shame list.
jasode · 16m ago
>I’ve personally never had that happen. It should go on a name and shame list
The key situation for giving out an SMS code that the gp is pointing out is the customer initiates the call to the support center.
For example, suppose somebody wants to add a credit-card to their smartphone digital wallet. They have to call the bank issuing their credit-card to do that. Once the customer support person answers the call, a common security verification (e.g. Chase Bank does this) is for them to send you a 6 digit code to your phone. You then repeat this code back to the support person on the call. They want proof of your identity and also proof that you physically have the smartphone with you. Repeating the SMS code to the customer support person is safe because the customer called the official 1-800 number on the back of their card.
That's a totally different sequence of steps from receiving a random call from somebody pretending they are from Chase Bank. Yes, in those cases, you never give out SMS codes to that untrusted person on the phone.
UncleMeat · 22m ago
Chase did this to me. A million alarm bells but even after hanging up and restarting the conversation from a phone number publicly listed on their website as a support contact they still did it. Wild.
rscrawfo · 20m ago
Fidelity does as well, although the message switches to state only read the code if you've called them directly.
adrr · 23m ago
My bank does it. Chase will send OTP via the bank app to verify you're identity for phone support.
clysm · 23m ago
Chase bank…
troc · 34m ago
- godaddy
octo888 · 22m ago
Who still uses GoDaddy LOL
scrollaway · 35m ago
Stripe Support does it for certain specific cases (email & phone). However, whenever they do it, it's a bilateral code generation: The support agent also gets a code they have to read out to the end user, which is featured prominently to them, saying the agent will have to read it out to get authentified.
ajross · 2m ago
> — never give out codes sent to use via sms or push notifications to someone requesting them via phone or email. Never. The messages often even say that!
I tried making this point downthread but it bears repeating higher up. Per OP, this was account with Authenticator enabled. If you have a working authenticator setup, they aren't going to "ask for a code", since by definition you're already authenticated. And while I'm no expert, I really don't think there is such a thing. Recovery for a lost account never goes back to device-in-hand once you have enabled full 2FA.
Something is being skipped in the description of the phish here. I don't think OP is being completely honest.
barbazoo · 2h ago
> Be skeptical of unknown calls. If something feels off, hang up and restart the conversation by contacting the company directly.
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
arethuza · 1h ago
I usually don't answer calls from numbers I don't recognise - but a couple of days back it was a scammer claiming to be from Amazon - said I had ordered an iPhone for £600 and was it a real order.
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....
unyttigfjelltol · 40m ago
Even when you know it’s fake, the whole thing is very disconcerting. I received a scam call ostensibly from a local utility and filed an identity theft report with local police naming the utility as “victim”. The caller even told me where they (probably really) were. Police do nothing, scams continue until something breaks.
arethuza · 15m ago
A few years back I got a call from a scammer selling a device that would help stop scam phone calls - that actually took me a while to realise it was a scam (this is like 15 years ago).
galaxy_gas · 37m ago
I get this kind of call about 5-15 times a day
I do not answer calls
arethuza · 29m ago
A lot of them phone me and ask for my wife by name "Can I speak to XYZ" - I usually reply "No" and end the call. Actually, for the last few calls I've not even been saying the "No".
Maybe 3 or 4 of these a day <sigh>
zamadatix · 1h ago
Would (the actual) Amazon even agree to provide this kind of information over the phone to someone?
mmmlinux · 1h ago
is talking to amazon on the phone at all even actually possible?
giantrobot · 15m ago
That's the easiest way to spot a scam: "Hello this message is from Google customer service..."
crawftv · 1h ago
The biggest red flag in all these stories is getting a call from a customer support person trying to help you.
When it seems like it’s impossible to get ahold of them in a real emergency.
jfim · 54m ago
I've actually gotten legitimate calls from the bank, although the correct way to handle those is to say that you won't give any information to them but you'll call them back.
kimixa · 49m ago
When my account had a fraud alert they called me just to say I should call them back immediately on the number on the back of my card.
I assumed this was normal.
fkskammerz · 1h ago
It doesnt seem to be a red-flag. The caller was calling as an Attorney from Google General Counsel responding to an estate request. They followed up with a spoofed @google.com email with their name corroborating the call.
ghurtado · 50m ago
You're missing the point.
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.
pc86 · 18m ago
> 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 answer is almost certainly greater than 0.
paleotrope · 1h ago
I have a 1-2 second rule. I pick up I say hello, if someone doesn't respond in 1-2 seconds, I hang up.
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.
zamadatix · 1h ago
I try to avoid picking up and saying anything because it seems like an advertisement "yes, this number is not only active but a real person who answers random calls - try calling back (possibly from a different number) later".
aj7 · 47m ago
I use a variation of this. I answer but do not speak. A legitimate caller will speak immediately.
craftkiller · 32m ago
Not always true. My landlord recently had a contractor call me. I did my usual "pick up and don't say anything" routine for unrecognized numbers, and the contractor silently hung up and never called back. Thankfully my roommate actually answered the call, but pick-up-shut-up prevents legit people from leaving voicemails and sometimes prevents legit people from reaching you entirely.
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.
atm3ga · 1h ago
I've set my phone to not answer unknown callers (those not in my address list) and more importantly, I've done this for my parents as well and further instruct them as often as possible to not believe anything they get in email. With all of this, my mom still will reach out at least once or twice a year in a panic about some scam email she thinks is real.
general1465 · 1h ago
Well easy to say, but if you are working in the real world, then unknown callers may be important - i.e. FedEx trying to push your package through the customs and if they can not contact you, your package goes either back or is destroyed.
atlanta90210 · 1h ago
If you have an iPhone, the latest iOS 26 will answer unknown numbers not in your address book for you and ask what they want and then alert you to see if you want to take the call.
golan · 1h ago
As of late, I have one rule: Any unknown number I'm not expecting I let it go to voicemail, where I have a message along the lines of: leave your message and your number, and if it's important I'll call you back. The only time I pick up is when I am expecting, say, a delivery, or a doctor's call, etc, and in those cases I'm only expecting to hear about a delivery or a doctor's call, etc. Hoping that can filter and help on this front.
throwaway7783 · 1h ago
I didn't quite understand this part. Attacked has access to Google accounts because Google had cloud-synced my codes? What does that mean?
remus · 1h ago
They gained access to the Google account by stealing the verification code over the phone, but then they had easy access to other accounts (e.g. coinbase) because they had access to 2FA codes because Google authenticator was backed up to the users Google account.
throwaway7783 · 1h ago
Ah, makes sense. The victim was social engineered first.
riffraff · 1h ago
The other way around.
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.
AJ007 · 51m ago
If you have to have use a phone, at minimum disable notifications and never answer it. First it removes all of the urgency. Second, the caller has to provide some way for you to contact them, which gives you a second point of contact to validate.
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.
pavel_lishin · 50m ago
> If you have to have use a phone, at minimum disable notifications and never answer it.
Great advice for someone who doesn't have children or family members with health conditions.
gargan · 55m ago
You don't need a spoofed email to steal someone's crypto. Criminals can just hold a gun to your head and demand your keys.
It's happened lots of times and it's why traditional banks are way more secure than crypto.
Well done to the author for talking about it, but I hope the real lesson is learned that crypto isn't a real store of wealth and can be stolen at any time....
ghurtado · 52m ago
> Criminals can just hold a gun to your head and demand your keys.
Sure, but this is Hacker News, not Mugger News.
ajross · 40m ago
You miss the point. You can't mug someone for their Vanguard account. Robbery risk is limited to cash on hand, or arguably whatever the ATM limit is on your bank account.
janalsncm · 30m ago
Actual risk is lower than that since you’ll possibly get your money back from a real bank.
aqme28 · 20m ago
People do get taken hostage until they give up their crypto accounts sometimes. There was a prominent one in NYC recently that was on the news again due to--basically-- the alleged involvement by one of the stars of a popular reality tv show.
hvb2 · 33m ago
Aren't elderly phone scammed out of huge amounts from bank accounts often??
fabbbbb · 25m ago
Not sure about the distribution, often it’s cash or jewelry that’s already home. Bank tellers and even taxi drivers get increasingly educated to stop such suspicious withdrawals/meetings.
pavel_lishin · 51m ago
True - but a phone call scales much easier than driving to someone's house with a gun.
cbdumas · 3m ago
> The attacker already had access to ... my Google Authenticator codes, because Google had cloud-synced my codes.
This was such an obvious mis-feature I can't believe they actually rolled it out. For those using Google Authenticator you can and should disable cloud sync of your TOTP codes.
QuadmasterXLII · 2h ago
The load bearing question is, why didn't the attacker also clear out OP's bank account, retirement savings, and max out his credit cards? Unfortunately, the difference is that banks care literally at all about their customers accounts being emptied.
QuadmasterXLII · 1h ago
What I specifically mean by "care literally at all" : banks have a policy of reimbursing people who had their accounts emptied despite taking reasonable precautions. This creates sane, linear incentives: banks care 1000x more about a $100,000 fraud than a $100 fraud; they care 1000x more about a scam affecting 100 people than a scam affecting one person, etc.
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
This is one of the main reasons I don't like crypto. If you get hacked, even if you did everything right, then you're out of luck. The funds are (generally) unrecoverable.
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.)
thrill · 1h ago
In my actual real world experience of digging my elderly mother out of $25,000+ of scam debt, banks do not care at all unless they can be shown to be at fault, and then they weigh the loss expense vs the likely legal expense.
SpicyLemonZest · 47m ago
What kind of scam debt in particular? I’m not blaming your mom, but there’s a big difference for a bank between “someone stole my identity to falsely authorize this transfer“ and “someone tricked me into authorizing this transfer”.
janalsncm · 21m ago
Never thought about it this way before, but phishing an individual is way higher ROI than identity fraud. So we should be extra vigilant about the former.
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.
petcat · 16m ago
> banks have a policy of reimbursing people who had their accounts emptied despite taking reasonable precautions
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 NO MATTER WHAT. Even if they try to market it as a perk "You're never responsible for unauthorized transactions". Yeah, no shit. It's the law.
ycombinatrix · 48m ago
yubikey is better
calmbell · 1h ago
And transferring money from a bank or brokerage account takes time. Enough time that anyone paying attention should be able to report the transfer as fraudulent before it completes and have the account frozen.
bdangubic · 1h ago
the banks don’t give two shits about it :)
adrr · 18m ago
Banks do care because they are on the hook. If someone commits identity theft and steals money from the bank via your account, its on them.
fn-mote · 1h ago
The difference is that you have leverage to force the banks to care.
There isn't any federal regulation at all covering your Bitcoin.
wmf · 1h ago
Bitcoin exchanges like Coinbase are regulated by the CFTC in the US. This case is more of a Google problem though.
ameliaquining · 35m ago
I don't believe the CFTC has any rules requiring crypto exchanges to reverse fraudulent transactions.
thrill · 1h ago
Fraud is fraud. There’s plenty of laws against it.
ameliaquining · 33m ago
The question is not whether it's legal to defraud someone, but what a financial services provider's obligations are if their customer gets defrauded. The answer here is quite different for banks and brokerages than for crypto exchanges.
janalsncm · 26m ago
Every day Google is trying to foist Gemini on me yet spam like this waltzes right through Gmail. Perhaps once we have finished our Dyson sphere powered AGI we will be able to block emails spoofed from @google.com.
____tom____ · 27m ago
> Note: if you’re a developer and your users have gmail accounts, an authenticator code is NOT a 2nd factor, if that user is using Google Authenticator.
So many people and developers do not understand two factor authentication. If the necessary information is automatically sync'd to another device, you likely don't have two factor auth.
Example: If you log in from a Macbook, and the second auth is sent to your phone, Apple will helpfully forward that code to the Macbook, completely removing the second factor.
PaulHoule · 19m ago
It doesn’t work because people don’t understand it. They understand they are getting harassed all the time and in a state of terror because you might get locked out from your accounts because you lost a device or because something went wrong with your relationship with Apple, Google, Microsoft and other large unaccountable vendors —- something you may or may not get an explanation of.
Since you’re getting harassed all the time and dealing with opaque rules it is no wonder people are fatigued, make mistakes, are inclined to panic when they get a scary call and hand over the keys, etc.
To add to that, having anything to do with crypto is to put a big target on your back and make yourself vulnerable.
No comments yet
UncleMeat · 19m ago
There’s threats and there are threats. Second factors largely exist to prevent password stuffing from password reuse. Even if the second factor is the same device as the device where you are initiating a login this works just fine.
If your goal is to stay safe even after one of your devices is owned then you’ve got a rarer (and way more difficult) threat model.
joshuamorton · 20m ago
Two factor usually means "something you have + something you know". So your MacBook + your password is two factors.
I've seen references to "three factor" auth which is often a push notification to a phone, and then there's more secure second factors, like yubikeys or code-protected passkeys.
Imnimo · 1h ago
I notice none of the pieces of advice are "don't keep a hundred thousand dollars in a Coinbase account".
atm3ga · 1h ago
I split my crypto assets between Coinbase and what is now a corrupted hard-drive I've yet to recover.
hcknwscommenter · 35m ago
The funniest hacker news comment I've read all year. Funny because I'm essentially in the same situation. I'd bet we are legion.
madaxe_again · 20m ago
I keep mine on a broken raid 5 array (seagate flood drives - two failed within hours of each other) in a shoe box. It’s super secure.
chinathrow · 11m ago
> The attacker already had access to my Gmail, Drive, Photos — and my Google Authenticator codes, because Google had cloud-synced my codes.
Don't do that. Don't put your 2FAs somewhere else than in an unsynched app. Not in Bitwarden, not in any online account, nowhere else than "Something you have".
gip · 7m ago
Just wondering what is the plan in case this thing you have gets lost?
And would you say that using something like authy with encryption using a totally unique password is safe?
cbdumas · 51s ago
Typically you print out recovery codes and keep them somewhere safe
oliwarner · 42m ago
We're a bit light on detail here but it's worrying that it's 2025 and Google isn't flagging "looks like" @google.com messages.
I'm assuming this is a dirty unicode hack and not something worse: no DKIM or an actually compromised sender.
The whole thing stinks.
blevinstein · 58m ago
I avoided this exact scam. The most important thing is to never trust an incoming phone number. If they can't give you a publicly posted phone number that you can call inbound, they are a scammer.
Google has dozens of properties and it is easy to generate an email from one of them that seems to confirm the attacker's identity. Never trust any of these to identify a legitimate representative.
vessenes · 40m ago
I too avoided it; I had an interesting interaction with the (American) call center scammer -- he called, said his story; he gave me a callback number when asked; I asked him for a web page I could verify a callback number. He quickly rattled off a legitimate Coinbase webpage URL, I believe their ToS page, which does include a phone number. He then hung up rather quickly.
Sadly for the scammers, that number didn't match. But, I note it was part of his script to sound confident and give a working URL. Pretty strong.
____tom____ · 34m ago
They frequently have nicely done webpages, which have this phone number on them. So you need to find the URL yourself.
bo1024 · 40m ago
It's already hard to verify if a phone number is legitimate, and I think it will get harder. And on the other hand, easier to get a search engine AI to incorrectly spit out the wrong number.
quantified · 1h ago
Mistake cost him 80k. Author is feeling burnt, but the cost is the cost at transaction time.
saaaaaam · 1h ago
Extending this further, based on the stated value it looks like he probably had 40 or 50 ethereum. He might have bought them for a fraction of today's price - say $50 - so might only be out $2500 based on cost at transaction time...
elAhmo · 27m ago
I have a feeling if ETH went down in the meantime, blog post would reflect 80k, not the lower value.
shocks · 1h ago
Incorrect. Author may not have had the required savings to rebuy the position he wanted.
zargon · 24m ago
If you want to keep $100k in a crypto exchange, it doesn’t cost much comparatively to purchase a few yubikeys.
The thought of having all my online services centralized with a single provider for email, SSO, 2FA, and so on is scary. Especially at Google, where you can lose all access at the drop of a hat, with no recourse.
rwmj · 2h ago
Does anyone know how the email from (or appearing to be from) @google.com works? Wouldn't the Apple account reject it because it fails DKIM/etc?
fastest963 · 2h ago
Yeah, I don't understand how it passed DMARC and why it wasn't rejected immediately by his mail server (Apple Mail?).
youngtaff · 1h ago
From the article he uses gmail I think
bradly · 21m ago
Probably not the same attack vector, but I've gotten phising emails from a real googlemail.com addresses by the scammer abusing backscatter spam and the reply-to address.
neuronflux · 1h ago
They probably sent it from gmail which would pass the SPF check (google.com and gmail.com have the same SPF).
They wouldn't have it signed to pass DKIM, but google doesn't use strict alignment checking so to pass DMARC either SPF or DKIM are acceptable.
Can't practically require both SPF and DKIM with DMARC anyways. Doing so would also be dumb as it would break forwarding (even when DKIM would otherwise remain intact).
Deprecating SPF would do everyone a favour though. Especially for reasons like these.
neuronflux · 46m ago
SPF alignment ensures the MAIL FROM domain matches the From header.
DKIM alignment ensures the From header matches the domain in the DKIM signature header.
In the DMARC policy, you can set both adkim=s and aspf=s.
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.
Avamander · 33m ago
DMARC specifies that SPF alignment is checked for the domain in the MIME From. The domains in SMTP and MIME From do not have to be the same (nor both align).
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.
traceroute66 · 1h ago
> Wouldn't the Apple account reject it because it fails DKIM/etc?
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.
Avamander · 52m ago
How would recipients know to expect an S/MIME signature though. It's not like it's enforced by MTAs like DMARC is.
traceroute66 · 2m ago
IIRC, if you're using Apple's Mail client it gets validated against the root cert shipped with MacOS/iOS. You get a little black tick next to the sender.
In theory, third-party places like gmail could (should ?) automagically verify S/MIME sigs where a root cert is readily available.
rolph · 1h ago
How Email Spoofing Exploits SPF and DMARC: A Cybersecurity Deep Dive.
I use gmail and i was attacked almost identically and the email came thru to my gmail with a @google origin account
davsti4 · 54m ago
More details would be great, like the headers.
davidscoville · 1h ago
I’ve heard scammers use Google tools like Google forms or Google cloud to send out fraudulent emails that appear like they come from Google.
thrill · 1h ago
The latest attempted scams I’m getting on my gmail account are fake postmaster bounces “from” google.com.
kerpal · 37m ago
Use a password manager and use a SEPARATE second factor authenticator not tied to the password manager. I personally use Authy (though I think it's been deprecated) and Bitwarden.
I recently got a Google scam call from someone using Google Voice in the bay area (650 number) claiming to be with Google and that an unauthorized device was trying to access my account. Eventually realized they were just trying to get my to unlock my account probably to drain bank accounts.
icedchai · 33m ago
Same. I don't store my 2FA with my passwords. I also use Authy, I'd like to move to something else but as long as it's working. I was annoyed they got rid of the Mac app.
kerpal · 32m ago
Same, the desktop app worked great. Probably for the best though, ideally you want to pull your codes from a phone and password from your desktop device.
icedchai · 23m ago
Yeah, I won't argue that it doesn't make sense security wise. It does.
jp191919 · 15m ago
Absolutely. If you are looking for a new 2FA/TOTP app- Aegis is good, also Proton Authenticator as it's independent of a Proton account.
nzeid · 1h ago
> Google enabled Authenticator cloud sync by default.
Never understood this convenience and never will. This is exactly the wrong way to deal with people losing their authenticator secrets.
UncleMeat · 7m ago
The convenience is that people don’t drop their phone in the toilet and suddenly lose access to all of their accounts.
sega_sai · 57m ago
I always read these stories and worry that I will fall for something like this at some point. With all the complexity around authentication, 2FA, backup codes, text messages, cloud-sync, pass keys etc, I find it impossible to be confident that you won't be phished/spoofed/hacked.
sequin · 1h ago
How did they get the passwords to his Google and Coinbase accounts? He reused passwords? The same one for Google as for Coinbase? Or did they reset his Coinbase password via his Gmail? The post doesn't make this explicit, but it warns against password reuse.
davidscoville · 1h ago
I believe they logged into coinbase with Google SSO. And then they used my Google Authenticator codes which were cloud synced as the second factor auth method.
A warning to auth engineers: if an account is using a Gmail address, then auth codes from Google Authenticator should not be considered a second factor.
avree · 1h ago
This isn't something "auth engineers" can control, there's no magic Google Authenticator flag on a 2fa code - it's all HMAC and numbers, you don't know if the code came from Authy, Google Auth, a homebrew code generator, a dongle, etc.
wmf · 58m ago
It sounds like we're back to physical Yubikeys as the only secure auth.
acdha · 54m ago
Passkeys also solve this even if they’re not hardware backed. He was able to give them a code but wouldn’t have been able to do a passkey handshake for a domain which isn’t Google.com. Plus they’re easier to use and faster.
wmf · 49m ago
I don't know about that. If they can hack your Google/iCloud account they can add a new device, sync all your passkeys to that device, then log into all your other accounts.
acdha · 22m ago
How do they do that if you are incapable of giving them a valid authentication code?
I don’t use Google but at least in the Apple world you also get a fairly different prompt for enrolling a new iCloud Keychain device than simply logging in. Obviously that’s not perfect but there is a good argument for not getting people accustomed to hitting okay for both high and low impact challenges using the same prompt.
ameliaquining · 31m ago
But they can't hack your Google or iCloud account if it's secured with a passkey, unless they have some other non-phishing means of doing so, which the attacker in this story presumably did not.
moduspol · 34m ago
Seems reasonable if you need to secure five figures or more in crypto.
davidscoville · 56m ago
Exactly. Google created vulnerabilities for the whole industry by introducing cloud synced Authenticator codes.
em500 · 1h ago
Google/Chrome Password Manager?
IncreasePosts · 1h ago
But how did they get his Gmail password in the first place?
I'm not sure if I have the same password reset flow as OP, but when I try to reset my password and even provide the 2fa code, it basically doesn't let me get past a certain point without contacting my backup email address or making me use a phone which I'm logged in on to complete the reset
zargon · 15m ago
The article gives advice to change your passwords because of leaks. So as the post above suggests, it really sounds like they reused their google password somewhere. Then had Google sign-on for Coinbase, or had their Coinbase password in Google.
BXLE_1-1-BitIs1 · 41m ago
My favourite Pixel feature is Screen Call.
My primitive security precautions:
1. DO NOT use your Gmail for recovery. Use another email provider.
2. Use a family member's phone number for recovery.
3. DO NOT install your bank's app. Somehow the Royal Bank of Canada's app was used as an attack vector. If the RBC app can get hacked, smaller banks are even more vulnerable.
4. Use incognito mode on your browser for banking so a thief or hacker can't use your browser history to find out your bank.
adrr · 14m ago
> 4. Use incognito mode on your browser for banking so a thief or hacker can't use your browser history to find out your bank.
You can buy that information. Databrokers will sell it. Your bank sells your transactions.
elAhmo · 29m ago
Knowing how impossible is to get a hang of anyone at Google in case things go wrong, it is probably very safe to just assume they will never ever ever call you.
wcoenen · 1h ago
Thanks for sharing. I already had it in the back of my mind that this cloud sync thing in Google Authenticator was not very secure. I'm getting rid of it right now.
I do see why Google did it; it's going to be difficult to educate users to always set up 2FA both on a primary and a backup device. Much easier and convenient to automatically sync different devices. But your story makes it obvious that something isn't quite right here.
jgilias · 1h ago
Authy has solved this though. The cloud sync is opt-in, and encrypted with a password. This makes it immensely more involved to compromise.
wcoenen · 34m ago
Ironically, Authy's cloud sync feature may have been what pressured Google to add cloud sync[1].
And yes, Google could have added an extra encryption password. But users forget/lose passwords, especially if they normally never need them. So I can see why Google didn't go that route.
I have a cell phone with an area code where I no longer have any connections or ties. Almost all the spam calls I receive come from that area code. By simply ignoring or blocking calls from that area code, I can avoid nearly all of the spam.
layman51 · 1h ago
Can someone please explain to me what it means for authenticator codes to be “cloud-synced”? Is that solely dependent on whether you’re using the Google Authenticator app while signed in to your Google Account? Is it possible to not have them “cloud-synced” if you are signed in?
jazzyjackson · 1h ago
Google Authenticator app defaults to backing up the TOTP secrets so if you log in on a new device you have them there. Pretty poor default for security, and you can disable it, but not the first time I've heard of this biting someone.
nipponese · 1h ago
The risk of not syncing — when you lose/reset your phone, so does your OTP app. If you don't have backup codes saved, you're cooked.
themafia · 46m ago
> you're cooked.
I've lost 2FA codes. It's complicated but if you have a financial relationship with the vendor you're going to be able to get everything sorted out. I imagine as this happens more there will be common internal policies which aid customers in this situation.
You have to weigh the amount of potential hassle against the value of potential losses. Why you would have $100,000 of value stored somewhere and only secured by a loose-lipped third party app is beyond me.
traceroute66 · 1h ago
> The risk of not syncing — when you lose/reset your phone, so does your OTP app. If you don't have backup codes saved, you're cooked.
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).
jgilias · 53m ago
You really shouldn’t use SMS 2FA. SIM swapping does happen. This kind of depends on the jurisdiction though. In some countries operators won’t reassign the phone number willy-nilly.
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.
traceroute66 · 5m ago
I agree entirely.
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.
Sayrus · 1h ago
Which is why most apps with sync have two sets of credentials: one to login on the platform and one master password for encryption. That helps in those scenarios.
fortran77 · 1h ago
Yes. There are other ways of syncing (I have images of the setup QR codes save in an encrypted file) but most people wouldn’t be able to manage this.
layman51 · 1h ago
You mean to say that if it were enabled on my Google account, then the TOTP numbers for my other accounts are visible via authenticating into Google Account on some other unknown device? Sounds like it could be convenient if you lose your phone, but still risky if an attacker can sign into your Google Account.
jgilias · 52m ago
Yeah. And this is on by default. Without an additional secret.
Google Authenticator can be local-only or synced to the cloud.
In local-only mode, the authenticator is bound to a specific device. You can manually sync it to additional devices, but if you lose access to all those devices, it's game over, you will get locked out of whatever accounts you secured with authenticator as the second factor.
In cloud-synced mode, it's synced to your google account, so if you lose your phone, you can restore authenticator state. But if your google account gets taken over, it's game over, the attacker has your authentication codes.
RandomBacon · 1h ago
Coinbase STILL doesn't freeze user accounts for a token amount of time, 24 hours or so, after resetting a password‽
Part of the blame should be levied on Coinbase if this is the case.
(I'm assuming this guy at least uses unique passwords...)
Havoc · 55m ago
I believe you can lock it to specific outgoing addresses though & ones not on the list have a long delay - like a week
riffraff · 1h ago
The attacker had the passwords and 2fa codes from the Google account so Coinbase couldn't really distinguish them from the right person (tho presumably for large transfers they may require some extra checks, dunno)
RandomBacon · 1h ago
The article is poorly written and not clear. It sounds like you're suggesting the author let Chrome save his Coinbase password and Google synced that to the attacker as well?
> Google had cloud-synced my codes.
> That was the master key. Within minutes, he was inside my Coinbase account.
The author wrote "codes", not "passwords".
ninalanyon · 1h ago
Always confirm such things by calling the official contact number that you already have and asking about the case. Do this before you discuss the matter further.
Never act based solely on an unsolicited telephone call or email.
blueflow · 1h ago
If someone calls and claims to be from an big tech company, its is always a scam and you are going to loose money.
calmbell · 1h ago
The key takeaway from this imo should be to only use password managers with a secret key like 1Password.
narrator · 1h ago
I got scammed because somebody put a fake bank location into Google Maps and so the Google voice caller ID said it was my bank. Luckily, I realized I got scammed and called the bank up right away and they got the charges reversed, which is why I still use that bank. Moral of the story: never trust inbound calls. They are the easiest vector for scammers to spoof.
themafia · 44m ago
It's insane that telephone service companies aren't getting greater scrutiny in all of this. For marginal profits they're allowed to create giant financial craters in the lives of citizens.
Why do banks have to "know their customers" and telephone providers don't?
fkskammerz · 1h ago
Same exact scam happened to me three weeks ago and I almost fell for it. The guy was very sharp and sounded very authentic.
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?
vkou · 2h ago
As soon as I read the headline, I knew that the problem was...
> 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.
fortran77 · 1h ago
Also if you have crypto you should never mention anywhere that you do. No forums, social media, etc.
RandomBacon · 1h ago
They still attack tech professionals living in California. Saying you have crypto will probably move you to the top of the list, but they'll still get to you eventually.
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).
fkyoureadthedoc · 2h ago
oof that sucks. Luckily I'll never answer the phone
traceroute66 · 1h ago
> Luckily I'll never answer the phone
One of the best features of Apple iOS 26 is the new call-screening feature[1].
Pixel Call Screen has been a godsend for me since its debut, akin to using uBlock Origin for browsing.
throwaway7783 · 1h ago
I never pick up calls from numbers that I don't know. If it's important they leave a message. And if I think it is important, I call them back through official phone numbers
nipponese · 1h ago
I get scam calls with Google in the caller ID everyday.
It kinda sucks that in 2025, voice calls are now near-zero trust.
Is there really no velocity behind any open/consortium replacement to traditional voice calls?
dec0dedab0de · 1h ago
i always tell my mom that no legitimate business would ever call, email, or send a letter about anything.
atallahw · 2h ago
What did the account did the email actually come from? Was it legit from legal and he just submitted the request or was it a real spoofing
fkskammerz · 1h ago
It was not legit from legal, I had the same attack on me two weeks ago. They were pretending to be from Google General Counsel responding to an estate request to my Google account being handed to another party who was supposedly the inheritor.
What clued me in was that he said he couldnt share the estate documents with me until I gave him my popup 2FA code.
sciencesama · 1h ago
i regularly check reddit scams to know about the scams and i recently dodged one which wanted my details !
insane_dreamer · 26m ago
I no longer answer calls from a number not in my contacts. If it's a real call that I need to take care of, I figure they'll leave a voicemail and I can decide whether I want to call back.
like_any_other · 2h ago
> The attacker spoofed the “From” field so it looked like the emails came from @google.com — something Google’s filters should have blocked outright. On iOS, Gmail doesn’t let you view full headers, so I had no way to double-check in the moment.
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.
tryauuum · 1h ago
DMARC does check the from field in the mail, so I don't know how could this happen
matsemann · 1m ago
Yeah, sorry if that wasn't clear in my explanation. Without these in place, you will accept anything from anyone claiming to be @A.com,but with dmarc the whole point is to flag when they're only pretending to be.
goda90 · 2h ago
No clue how it works functionally these days. But it reminds me of tricks we pulled back in high school programming class. Our school was using Novell NetWare, and some students were given email addresses for various purposes. We discovered you could edit the From field, so it would display any text as your name and then your email address after it to the recipient on Novell's email client. If you added enough text, including whitespace, it would push the actual email address off screen(I don't remember if you could scroll to it or not).
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.
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
like_any_other · 1h ago
His phrasing is very confusing - claiming the "from" field was spoofed, but that if he could see the "full header", he could have spotted the spoofing.
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?
Avamander · 40m ago
It could indeed be that some MUAs only display the comment section. In theory you can use a MIME from like '"Google <google@google.com>" foo@example.com'. Though most spam filters heavily frown upon garbage like that. Things like '"Foo (google@google.com)" <foo@example.com>' will likely pass though. (It's commonly done by shit forwarders.)
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.
throw_m239339 · 2h ago
It's my understanding that emails have headers, just like http responses, and the app might have displayed that fake header instead of verifying the provenance of the email and displaying where it actually came from. So it is a UI/UX issue.
alaithea · 1h ago
Why email clients have started hiding/not providing access to headers is beyond me. It seems like an anti-pattern. There have been many times recently where I've wanted to check the headers because an email was suspicious, only to find I couldn't.
ajross · 33m ago
Something isn't adding up here. The author is excruciatingly rigorous with documenting lots of stuff here, including the screenshots. Then glosses over this bit awfully fast:
> So when he asked me to read back a code — supposedly to prove I was still alive — in a moment of panic, I did
This was an account with authenticator enabled. I'm no expert, but I really don't think there's a recovery process that works as simply as "read back a code". Certainly not in the SMS 2FA sense I'm sure we're all expected to interpret.
Honestly it seems like the author is trying to blame Gmail's UI, when some other more involved phishing technique was actually the novel part here.
GioM · 7m ago
I don't get this part either.
if the scammers had spoofed the email, they would already have that code, and if they hadn't spoofed that email... I mean it looks like a case ID, why would they need it?
Maybe the reading back the code was to get buy in, then there's a missing step here like they had him hit "allow" on a 2fa prompt. Or maybe the email was legit, since it references a "temporary code" and the case ID allowed access with that code?
Good chance my reading comprehension is shot and I'm missing something, I suppose, but I don't understand.
ajross · 5m ago
> Good chance my reading comprehension is shot and I'm missing something, I suppose
That's more charitable than me. My UnreliableNarrator sense is tingling really badly here.
nharada · 1h ago
One thing I really hate is that some companies with poorly design customer service flows actually REQUIRE you to read a code they text you over the phone to a rep.
At least now more companies include a "never read this over the phone" note in their authentication texts.
OP said the coin base account was drained within “minutes”. Server thief bait can take up to 24h to notify you when someone takes the bait.
> We'll put a tiny amount of cryptocurrency in a wallet, but probably still enough to attract the attention of automated scripts. We notify you when it's taken within 24 hours.
latchkey · 2h ago
Zak just posted this eye opening behind the scenes look at what these scammers are doing...
Sorry but it’s stupid to blame Google when it’s 100% your fault. This is a scam that is 10+ years old and you fell for it in 2025. It’s not googles fault at all.
acdha · 55m ago
This is like saying it’s not Ford’s fault that they didn’t put in seatbelts and safety glass because people knew driving was unsafe. When bad outcomes happen at scale, you need a system-level fix.
EDIT: to be clear, the fix has arrived: had he used passkeys, this attack would have been impossible and every login would’ve been faster and easier. There are edge cases but this is literally the reason why U2F was created a decade ago.
blindriver · 32m ago
The author knew that the scam existed and he even was skeptical. Then chose to rely on it being true despite all the red flags. That’s his fault.
At some point people have to accept responsibility for their own stupid actions.
acdha · 15m ago
Yes, they made a mistake. They were honest about that.
A little secret which will help you in life: everyone makes mistakes, even people who don’t think they will, even you. Looking all the way back to last week and 2 major NPM hacks ago, you can get access to a lot of systems simply by hitting someone when they’re busy and distracted.
blindriver · 3m ago
There's a difference between making a mistake and then blaming other people for your mistake. Blaming others when you are clearly in the wrong is reprehensible.
ycombinatrix · 55m ago
It isn't Google's fault that an attacker was able to spoof mail from "legal@google.com"?
Avamander · 38m ago
Proof of that remains to be seen.
That being said, there are a few approaches that might leave such an impression to people unfamiliar with their email client.
blindriver · 35m ago
Spoofing email addresses has been around since the 90s.
ShrimpHawk · 1h ago
One wrong point in this. Google Authenticator does not cloud sync by default. You specifically have to accept the cloud sync option that you are prompted with.
— no support group from a big company is going to call you. Ever.
— never give out codes sent to use via sms or push notifications to someone requesting them via phone or email. Never. The messages often even say that!
— Don’t put all your private info behind one password, so don’t use Google Authenticator backed by your Google Account as your password manager. Always use a third party like 1Password or similar.
— Don’t have the same email you use banking and investments be the email that the world knows. Create a new email for that. If you use Chrome, even use a separate profile with that email, and only have your password manager as an extension. No others.
To their credit/discredit, when I said no I'm not giving that out it says not to they just moved on. Not sure why they even asked then.
It's like they want us to get scammed?
Unfortunately, some call centers DO use that for verification in some cases (i.e. you call them, and they send you a code to your email/phone that you read back).
The key situation for giving out an SMS code that the gp is pointing out is the customer initiates the call to the support center.
For example, suppose somebody wants to add a credit-card to their smartphone digital wallet. They have to call the bank issuing their credit-card to do that. Once the customer support person answers the call, a common security verification (e.g. Chase Bank does this) is for them to send you a 6 digit code to your phone. You then repeat this code back to the support person on the call. They want proof of your identity and also proof that you physically have the smartphone with you. Repeating the SMS code to the customer support person is safe because the customer called the official 1-800 number on the back of their card.
That's a totally different sequence of steps from receiving a random call from somebody pretending they are from Chase Bank. Yes, in those cases, you never give out SMS codes to that untrusted person on the phone.
I tried making this point downthread but it bears repeating higher up. Per OP, this was account with Authenticator enabled. If you have a working authenticator setup, they aren't going to "ask for a code", since by definition you're already authenticated. And while I'm no expert, I really don't think there is such a thing. Recovery for a lost account never goes back to device-in-hand once you have enabled full 2FA.
Something is being skipped in the description of the phish here. I don't think OP is being completely honest.
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>
I assumed this was normal.
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.
The answer is almost certainly greater than 0.
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.
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.
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.
It's happened lots of times and it's why traditional banks are way more secure than crypto.
Well done to the author for talking about it, but I hope the real lesson is learned that crypto isn't a real store of wealth and can be stolen at any time....
Sure, but this is Hacker News, not Mugger News.
This was such an obvious mis-feature I can't believe they actually rolled it out. For those using Google Authenticator you can and should disable cloud sync of your TOTP codes.
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 NO MATTER WHAT. Even if they try to market it as a perk "You're never responsible for unauthorized transactions". Yeah, no shit. It's the law.
There isn't any federal regulation at all covering your Bitcoin.
So many people and developers do not understand two factor authentication. If the necessary information is automatically sync'd to another device, you likely don't have two factor auth.
Example: If you log in from a Macbook, and the second auth is sent to your phone, Apple will helpfully forward that code to the Macbook, completely removing the second factor.
Since you’re getting harassed all the time and dealing with opaque rules it is no wonder people are fatigued, make mistakes, are inclined to panic when they get a scary call and hand over the keys, etc.
To add to that, having anything to do with crypto is to put a big target on your back and make yourself vulnerable.
No comments yet
If your goal is to stay safe even after one of your devices is owned then you’ve got a rarer (and way more difficult) threat model.
I've seen references to "three factor" auth which is often a push notification to a phone, and then there's more secure second factors, like yubikeys or code-protected passkeys.
Don't do that. Don't put your 2FAs somewhere else than in an unsynched app. Not in Bitwarden, not in any online account, nowhere else than "Something you have".
And would you say that using something like authy with encryption using a totally unique password is safe?
I'm assuming this is a dirty unicode hack and not something worse: no DKIM or an actually compromised sender.
The whole thing stinks.
Google has dozens of properties and it is easy to generate an email from one of them that seems to confirm the attacker's identity. Never trust any of these to identify a legitimate representative.
Sadly for the scammers, that number didn't match. But, I note it was part of his script to sound confident and give a working URL. Pretty strong.
The thought of having all my online services centralized with a single provider for email, SSO, 2FA, and so on is scary. Especially at Google, where you can lose all access at the drop of a hat, with no recourse.
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.
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.
https://undercodetesting.com/how-email-spoofing-exploits-spf...
I recently got a Google scam call from someone using Google Voice in the bay area (650 number) claiming to be with Google and that an unauthorized device was trying to access my account. Eventually realized they were just trying to get my to unlock my account probably to drain bank accounts.
Never understood this convenience and never will. This is exactly the wrong way to deal with people losing their authenticator secrets.
A warning to auth engineers: if an account is using a Gmail address, then auth codes from Google Authenticator should not be considered a second factor.
I don’t use Google but at least in the Apple world you also get a fairly different prompt for enrolling a new iCloud Keychain device than simply logging in. Obviously that’s not perfect but there is a good argument for not getting people accustomed to hitting okay for both high and low impact challenges using the same prompt.
I'm not sure if I have the same password reset flow as OP, but when I try to reset my password and even provide the 2fa code, it basically doesn't let me get past a certain point without contacting my backup email address or making me use a phone which I'm logged in on to complete the reset
My primitive security precautions:
1. DO NOT use your Gmail for recovery. Use another email provider.
2. Use a family member's phone number for recovery.
3. DO NOT install your bank's app. Somehow the Royal Bank of Canada's app was used as an attack vector. If the RBC app can get hacked, smaller banks are even more vulnerable.
4. Use incognito mode on your browser for banking so a thief or hacker can't use your browser history to find out your bank.
You can buy that information. Databrokers will sell it. Your bank sells your transactions.
I do see why Google did it; it's going to be difficult to educate users to always set up 2FA both on a primary and a backup device. Much easier and convenient to automatically sync different devices. But your story makes it obvious that something isn't quite right here.
And yes, Google could have added an extra encryption password. But users forget/lose passwords, especially if they normally never need them. So I can see why Google didn't go that route.
[1] https://www.reddit.com/r/2fa/comments/pmow4k/switching_from_...
I've lost 2FA codes. It's complicated but if you have a financial relationship with the vendor you're going to be able to get everything sorted out. I imagine as this happens more there will be common internal policies which aid customers in this situation.
You have to weigh the amount of potential hassle against the value of potential losses. Why you would have $100,000 of value stored somewhere and only secured by a loose-lipped third party app is beyond me.
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.
Google Authenticator can be local-only or synced to the cloud.
In local-only mode, the authenticator is bound to a specific device. You can manually sync it to additional devices, but if you lose access to all those devices, it's game over, you will get locked out of whatever accounts you secured with authenticator as the second factor.
In cloud-synced mode, it's synced to your google account, so if you lose your phone, you can restore authenticator state. But if your google account gets taken over, it's game over, the attacker has your authentication codes.
Part of the blame should be levied on Coinbase if this is the case.
(I'm assuming this guy at least uses unique passwords...)
> Google had cloud-synced my codes.
> That was the master key. Within minutes, he was inside my Coinbase account.
The author wrote "codes", not "passwords".
Never act based solely on an unsolicited telephone call or email.
Why do banks have to "know their customers" and telephone providers don't?
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?
> 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).
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...
It kinda sucks that in 2025, voice calls are now near-zero trust.
Is there really no velocity behind any open/consortium replacement to traditional voice calls?
What clued me in was that he said he couldnt share the estate documents with me until I gave him my popup 2FA code.
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.
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.
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.
> So when he asked me to read back a code — supposedly to prove I was still alive — in a moment of panic, I did
This was an account with authenticator enabled. I'm no expert, but I really don't think there's a recovery process that works as simply as "read back a code". Certainly not in the SMS 2FA sense I'm sure we're all expected to interpret.
Honestly it seems like the author is trying to blame Gmail's UI, when some other more involved phishing technique was actually the novel part here.
if the scammers had spoofed the email, they would already have that code, and if they hadn't spoofed that email... I mean it looks like a case ID, why would they need it?
Maybe the reading back the code was to get buy in, then there's a missing step here like they had him hit "allow" on a 2fa prompt. Or maybe the email was legit, since it references a "temporary code" and the case ID allowed access with that code?
Good chance my reading comprehension is shot and I'm missing something, I suppose, but I don't understand.
That's more charitable than me. My UnreliableNarrator sense is tingling really badly here.
At least now more companies include a "never read this over the phone" note in their authentication texts.
https://serverthiefbait.com/
OP said the coin base account was drained within “minutes”. Server thief bait can take up to 24h to notify you when someone takes the bait.
> We'll put a tiny amount of cryptocurrency in a wallet, but probably still enough to attract the attention of automated scripts. We notify you when it's taken within 24 hours.
https://x.com/0xzak/status/1967592307714379934
A Horrific threat.
EDIT: to be clear, the fix has arrived: had he used passkeys, this attack would have been impossible and every login would’ve been faster and easier. There are edge cases but this is literally the reason why U2F was created a decade ago.
At some point people have to accept responsibility for their own stupid actions.
A little secret which will help you in life: everyone makes mistakes, even people who don’t think they will, even you. Looking all the way back to last week and 2 major NPM hacks ago, you can get access to a lot of systems simply by hitting someone when they’re busy and distracted.
That being said, there are a few approaches that might leave such an impression to people unfamiliar with their email client.