When discussing scams and social engineering attacks, it’s easy for security researchers and experts to present information in a way that implies the victims of these attacks should have known better. It’s an attitude borne of biases that many engineers have – myself included – but it’s unhelpful and counter-productive. And, as much as we may like to think we’d handle these situations so much better, that’s just not true. Security experts – even those with professional experience in social engineering – are not immune to scams. As an example of this, I’d like to share the story of a scam I fell for recently.
The Call
In the early afternoon, after starting my day with an extremely tiring 2-hour meeting, I kicked back for a much-needed break before digging into some writing projects. However, my meditation was interrupted by my phone ringing. Which, in and of itself, was noteworthy – I use a complex web of forwarding numbers and obfuscation to avoid giving out a real phone number as much as possible, and the only people who have my real phone number rarely call me, especially during the day. I checked the caller ID, and it was my bank, Wells Fargo (I know, I know; trust me, they were not my first choice).
I answered, the guy said he was calling from Wells Fargo’s Fraud Prevention Department, calling to verify some transactions. He verified my name, he had the last four digits of my debit card number, and everything generally seemed to follow the normal script of a transaction verification call. He rattled off three separate transactions, totalling close to a thousand US dollars, all of which were things I didn’t recognize, in a city I’ve never been to, 1300 miles (2100km) from where I live. So, yeah, definitely fraudulent transactions. He said they’d cancel my debit card and send a new one, and verified the address on file – which he also already had, without me needing to provide it. I’ve had a bunch of these calls over the years, so nothing weird so far. I figured we were about finished with a very routine and normal fraud call, but it turned out we were just getting started.
Apple Pay, and the Perils of Third-Party Services
After the caller (who later gave me his name as Daniel, so that’s how I’ll be referring to him even though I didn’t have that information at this point in the call) reviewed what we had discussed up to that point, he asked if I was familiar with “digital pay”. At first I thought he was talking about some sort of specific Wells Fargo service, but then he clarified that he was talking about mobile app payment systems, like Apple Pay and Google Pay. Which, yes, I’m very familiar with, but I don’t use and have no interest in using. Well, it turns out these fraudulent charges were made via Apple Pay. Something I’ve never used and will never use because I don’t have an iPhone and don’t plan on getting one. So, yeah, that needs to get turned off.
Daniel said that was no problem, and that he was starting the process of disconnecting my account from Apple Pay. In order to do that, I needed to relay a confirmation code that would be texted to me. Well, that’s a bit of a problem, since the phone numbers where I actually check and receive text messages aren’t phone numbers that Wells Fargo recognizes as valid mobile numbers (one of many things I despise about this bank). No problem, though, I could just receive it via email. Which I did; specifically, this email.
This was the first point of concern I’d had during this entire call: I didn’t read the full email in detail until much later, I only skimmed it at this point, but this is clearly a two-factor authentication code, meant to be entered directly into an authentication page. Which is normally not something that would be relayed over a phone call to a customer service rep. A concern that I raised to Daniel. However, he said that it was part of Apple’s system, which they only had limited access to. An explanation that, as someone who works with computers, data security, and API integration professionally, I completely bought; even though I understand the technical intricacies of two-factor authentication systems better than most, I also find it entirely plausible that Apple (or Google) would require a bank to jump through these kinds of hoops in order to remove a fraudulently-added payment method from someone’s account, and that Wells Fargo’s system would be so janky and sloppily-built that this is the least awful way they could figure out how to do it. Plus, I was still pretty tired, and the connection was glitchy, so I was having to really focus on the call to pay attention, and didn’t have a lot of mental bandwidth to think about other things.
So, I faithfully relayed the Apple Pay verification code, as requested.
Panic Ensues
While “Daniel” was rattling off some information about the process of removing my card from Apple Pay – clearly reading a script – I noticed a few more suspicious things happening. The first being that, right before this call came in, I received a text message about one of the fraudulent transactions Daniel mentioned at the beginning, asking me to reply with a yes or no to indicate whether it was authorized. Which, in and of itself, normally wouldn’t be weird to most people, but because of the aforementioned quirk with Wells Fargo not recognizing my primary phone number as a “real” mobile number, I don’t receive those text messages, and they definitely wouldn’t come to that particular phone number.
As that realization was starting to sink in, another email from Apple Pay came in, this time confirming that my card had been added to an Apple Pay account. Which was the big red flag, so I asked Daniel about it. He said it was an older message that must’ve been stuck in the server queue all this time, and that they’ve been having system issues like that all day, which, again, sounded completely plausible: Email is a notoriously fickle protocol, delayed messages happen to large-scale senders all the time, and major platforms are always in a constant state of “having system issues”. But the order of operations wasn’t lining up; I could believe the confirmation email being delayed by an hour or so after a malicious user added my card to their Apple Pay account, but having it finally clear that delay and arrive immediately after relaying an authentication code to someone over the phone was too much of a coincidence to ignore. Especially since the timestamps seemed to show the authentication code was sent first (not unheard of, there are a dozen different standards for email timestamps and none of them agree with each other, but suspicious).
Once I put those puzzle pieces together in my head, I realized the guy I was talking to had never actually given me his name (or if he did, I missed it), so I took the first opportunity I had to ask. This was where I learned his name was “Daniel Coffmane” (I confirmed the spelling later), and he also gave me his employee ID number – 1687979 – then gave a scripted bit about ensuring the safety of all customers, and offered to transfer me to his supervisor if I had additional concerns. It all sounded very professional, and I was still distracted by sifting through the headers on those Apple Pay emails, so I declined the offer of talking to his supervisor; if it was a scam, then this was clearly a bluff to try to reassure me, b
