> 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?
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.
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.
What clued me in was that he said he couldnt share the estate documents with me until I gave him my popup 2FA code.
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.
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...
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...
~ dig _dmarc.google.com txt +short
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"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.
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.
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>
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.
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.
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.
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.
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.
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.
Never understood this convenience and never will. This is exactly the wrong way to deal with people losing their authenticator secrets.
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
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.
At least now more companies include a "never read this over the phone" note in their authentication texts.
Why do banks have to "know their customers" and telephone providers don't?
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".
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?
Never act based solely on an unsolicited telephone call or email.
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_...
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.
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.
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.
Like crypto, wire transfers are difficult to track and irreversible.
It's a tiny, infinitesimal chance: but it's a heck of a lot greater of a chance than the same thing happening with a bank account, especially the "no recourse" part.
On the plus side, iOS and Android now have features for auto-answering and filtering so thankfully I have that.
— 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.
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).
- godaddyThe 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.
Note, however, that those are two "totally different sequences of steps" to you and I, and "completely analogous / equivalent sequences of steps" to my father in law :-/
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 is a setting that let your power company to change your temperature settings when grid is under load. We wouldn’t mind it but they turned our heat way down during one freezing night while we were sleeping. Everyone woke up with cold next day.
It's like they want us to get scammed?
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.
Or even better, don't rely on a third-party hosted service.
I've been a Codebook[1] user since the old-days when they used to call it Strip.
They are old-school, local-system storage. With sync/backup done how you like it (all three encrypted before it leaves your computer):
- Dropbox
- Google Drive
- Local folder (which you can then sync with using your own mechanism)
- Recently (only this year) they introduced a totally optional hosted subscription cloud-sync option for those who want it
I'm assuming this is a dirty unicode hack and not something worse: no DKIM or an actually compromised sender.
The whole thing stinks.
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 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.
> 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.
> In the Gmail app on iOS, it looked completely legitimate — the branding, the case number, everything. Even the drop-down still showed “@google.com.”
> So when he asked me to read back a code — supposedly to prove I was still alive — in a moment of panic, I did.
The sentences do not refer to the same thing.
The code was not in the email... The narrator was asked to read back "a code" not the case ID in the email. "A code" here referes to a 2fa push notification code. The email was used to rattle the narrator / build trust to get them to comply.
Did they send the fake legal email and at same time trigger a recovery code to be sent?
Is this like the same thing in discord where they ask you for your email to join a server then ask you for a code sent to verify you own that email but really they submitted the email for password reset. The victim doesn't realize it's a real recovery code sent by Microsoft, etc instead in the moment thinking it is a "discord code". Once you submit the code in discord they have your account stolen in seconds.
Is this what the article is attempting to describe?
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.
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.
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.
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.
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.
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?
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.
I am not clear how the account access occurred. What code did he read? He voluntarily read his own 2FA code from his Authenticator?
Its not a GREAT carrier, but I have a legacy plan for unlimited everything at $20 a line.
But if I have to call in, they do send a 2fa SMS code, and require to tell them over the call. Its absolutely ridiculous. But, Ive only had to call in 4 times in the last 9 years, so, yeah.
Your story is humbling, and a good reminder that anyone can get “got”. We shouldn’t think ourselves above such incidents.
latchkey•2h ago
https://x.com/0xzak/status/1967592307714379934
ncr100•2h ago
A Horrific threat.
clgeoio•1h ago
wmf•1h ago
junto•1h ago
ycombinatrix•1h ago