When discussing scams and social engineering attacks, it's common for security researchers and experts to present information in a way that implies the victims of these attacks should have known better, often unintentionally. It's an attitude borne of biases that many engineers have - myself included - but it's ultimately counter-productive, stigmatizing first-hand accounts that are helpful for research, and penalizing early reporting in situations where seconds matter. And, as much as we may like to think we'd handle these situations so much better, reality has a way of humbling us all. Security professionals of any specialty - even those who are experts in social engineering themselves - are not immune to scams, and pretending otherwise doesn't do anyone any favors. As an example of this, and in the hopes of de-stigmatizing talking about social engineering, I'd like to share the story of a scam that tricked me recently.
Defensive Overview
First, a quick mention of some defensive tactics I habitually employ, to help this story make more sense. Due to the prevalence and ease of mass data theft (and, if I'm being honest with myself, just plain paranoia), I started practicing extensive information control many years ago. In addition to my normal, "real" contact information, which I only give out sparingly, I also have honeypot information that goes nowhere, and intermediate information that will actually reach me but that I know not to trust.
This has proven to be a shockingly effective tactic: By carefully controlling what pieces of personal data I give to which companies, services, and even people, and periodically switching things up to reduce the odds of the same data being in the same "bucket" twice, the vast majority of scammers, spammers, and other malicious actors never clear the first hurdle of getting me to answer their call, even though my billing and contact details have been stolen in countless data breaches over the last 15+ years. Because even if a malicious actor finds me in a stolen database, their information about me is almost always either wrong by design, or contains details that don't match what I gave the company they're impersonating, thus making it obvious that they're not who they say they are, and efficiently weeding out most high-volume attackers who are working from a single data source.
This strategy has been so overwhelmingly effective, in fact, that I can count on one hand the number of phone/email scammers I've actually spoken to in the last decade or so, none of whom had the right information to get more than a few seconds of my time. Until now.
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. I checked the caller ID, and it was my bank, Wells Fargo. The call was coming from a known number, from a bank I currently use, and they were calling the correct primary phone number for my account, so I answered.
The guy said he was calling from Wells Fargo's Fraud Prevention Department, and asked if he was speaking to me by using my full legal name. I replied "yes", and he said there was suspicious activity on my debit card (identified by correctly reading me the last 4 digits of my own card number) that needed my review. Thus far, a textbook example of a transaction verification call; I had never received one from Wells Fargo before, but I've received a lot of them from other banks over the years due to overzealous algorithms flagging my legitimate transactions, plus the inevitable results of routine retail data breaches. And I've only been using Wells Fargo for about a year and a half, so it seemed logical to assume that they would handle this situation the same way as every other bank and credit card I've ever had, I just hadn't encountered it yet. But, I also knew the dangers of incoming calls, so I instinctively stuck to only giving "yes" and "no" answers.
The caller rattled off three separate transactions, totaling close to a thousand US dollars, all of which were at stores I don't frequent, in a city I've never been to, 1300 miles (2100km) from where I live. Definitely fraudulent transactions, and when he asked if I recognized each one, I said "no". After the third one, he stated that, because I indicated that there was unauthorized activity on my card, they would cancel my debit card and send a new one, along with reassurance that I wasn't liable for the fraudulent transactions, with the telltale verbosity of someone reading a corporate script. He then said it would be shipped to my address, by reading the correct address to me, and asked if it was correct, to which I replied "yes".
Up to this point, as the caller gave me the estimated delivery time of my new debit card (within three business days, impressive!), nothing even remotely suspicious had happened. He did not ask me to give information or take any actions. He was knowledgeable, polite, and professional. And I literally said nothing at all the whole time except "yes" and "no". Just a bog-standard transaction verification/fraud detection call, and one of the smoother ones I'd had. In fact, had the call ended here, I would've walked away thinking this was, by far, the smoothest, most productive, and least frustrating interaction I'd ever had with Wells Fargo (which, in and of itself, probably should have seemed suspiciously too good to be true).
Unfortunately, we were just getting started.
Apple Pay, and Silicon Valley Cynicism
After the caller (who later introduced himself as "Daniel") started reciting the standard end-of-call review script, he mentioned needing to check one other thing, with the tone of someone suddenly realizing they missed a step while assembling a bookshelf, and 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 aware of, and familiar with on a vague, conceptual level, but which I don't use and have no interest in using. Well, it turned 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" was very reassuring, and said that was no problem, but it required an extra process and additional verification to disconnect my bank account from the thief's Apple Pay account. The first step was to relay a code that was being texted to me. Which posed a bit of an issue: Due to some sort of bizarre corner-case technical issue from the day I opened my account, Wells Fargo does not consider my primary phone number to be a real cellphone number, and therefore their system doesn't consider it possible to send me text messages, usually either failing silently or outright rejecting my number. An issue they seem uninterested in fixing, or even acknowledging (one of their bankers once told me "just go get a burner phone from 7-11 and use that number" when I asked who could help fix this), but it comes up almost every time I have to talk to Wells Fargo, even about completely unrelated matters. But that's ok! "Daniel" said it could go to my email instead.
This was the first suspicious thing that had happened during this entire call. The email promptly arrived, as expected, but the subject line said "Use this code to verify your Wells Fargo card", with "Verify your card in Apple Pay using code [redacted]" being the only thing visible in the body preview in the notification. Which, right off the bat, made my scam-sense tingle, despite being tired, anxious, and a bit frustrated. So I asked for more details about what exactly this process entailed and why it looked like this was an authorization to add me to Apple Pay, as I opened the message. "Daniel" reassured me that this was just part of Apple's system, repeating some of his earlier script, and talking about how he had limited access to Apple's systems and there wasn't much he could do about the weird verification code step.
While he was talking, I tried to read the email, but I could only skim it with someone incessantly talking in my ear, especially since his connection was slightly glitchy, requiring me to devote extra focus toward parsing what he was saying (something that already takes me a lot of effort). And even though it did vaguely resemble a two-factor authentication (2FA) code, nothing tripped the necessary keyword recognition for my mind to strictly interpret it as one at first glance. The most prominent text simply said variations of "Use this code to verify...", and that was one of the only things I absorbed from skimming it, along with the code itself, and a vague awareness that, somewhere in the multiple paragraphs of small text that went on beyond the bottom of the screen on my phone, the last four digits of my debit card appeared, prompting a tiny bit of subconscious "this is legit" recognition. It lined up with what "Daniel" was saying, didn't line up with a 2FA format I recognized, and nothing indicating danger or the potential for damage stood out to me when casually glancing at the message. Plus, upon hearing this guy describe what sounded like a ridiculously convoluted and overly-complicated process for disconnecting linked accounts, and lamenting his lack of access to fix the problem directly, all while seemingly trying to hide his own frustration and just get through this call so we could both go on with our day, all I could think was "Yeah, I get it, I've been there too". Based on every past interaction I'd had with Wells Fargo, and every customer service experience I've had with a major Silicon Valley tech company as an individual user, this situation seemed not only plausible, but normal and mundane.
So, when some guy on the phone told me that both Wells Fargo and Apple have such janky, broken, poorly-integrated systems that this unfamiliar and suspicious-looking process was the only way to unlink my bank account from some random attacker's Apple Pay account, and did so while I was trying and failing to focus long enough to read an email full of dense, small text contradicting him, I completely bought it without question. I faithfully relayed the code to "Daniel", as requested. And never in my life have I so deeply regretted not reading an email.
Panic Ensues
While "Daniel" was reciting a particularly lengthy script about the process of removing my card from Apple Pay, I took the opportunity to clear some of the notifications I missed, since this was the first time I actually looked at my phone in almost four hours, and I had been on the phone with "Daniel" for over 30 minutes. In the process, I noticed something odd: I had received a text message about one of the fraudulent transactions "Daniel" mentioned at the beginning, asking me to reply "yes" or "no" to indicate whether it was authorized, which apparently arrived a few minutes before the call even started. Which might not be odd to most people - I've since been informed that this is the normal way Wells Fargo handles verification of suspicious transactions - but as previously mentioned, Wells Fargo doesn't think my phone number is a "real" cellphone for some reason, so I've never received a text message like that. In fact, I've never received a text message from Wells Fargo at all, ever, and have no idea what a legitimate one would even look like; I didn't recognize the number, but since toll-free numbers generally don't send text messages, and most businesses send their SMS alerts from random pools of numbers owned by inscrutable third-party services, I have no idea what number an authentic Wells Fargo text message would come from, and the most efficient way I could think of to find out would be to just try blindly searching for "Wells Fargo text alert number" and hope the top results are both relevant and accurate. The one thing I knew for certain was that it was odd, but I otherwise didn't quite know what to do with the information in that moment.
I didn't get the chance to follow that train of thought very far or investigate it in any meaningful detail, because almost immediately after I noticed the text message, another email from Apple Pay came in, this time confirming that my card had been successfully added to an Apple Pay account. That was the big red flag, and I immediately asked Daniel what was going on, my anxiety and irritation steadily increasing as I opened it to try to read it. He said it was an older message that got stuck in the send queue, most likely, because they had been having system issues all day, and a lot of people's verification emails were getting delayed or sent out of order. Which, on the surface, sounds plausible - email is often flaky, delivery delays are common (usually when I'm waiting on a time-sensitive message), and most major platforms and services are in a constant state of "having system issues" on any given day. But the order of operations didn't line up: In isolation, I could believe the initial confirmation email from someone signing up for Apple Pay in my name was delayed by an hour, or I could half-believe (without fully reading that email) that the process of disconnecting my bank account from someone else's Apple Pay account looks suspiciously like signing up for Apple Pay in my name. But to have that delayed confirmation email arrive immediately after relaying a mystery-code to someone over the phone was too much of a coincidence.
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 my first instinct was to ask. This was where I learned his name was "Daniel Coffman" (I later confirmed the spelling as "Daniel Coffmane"), and he also gave me his employee ID number - 1687979 - then recited 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 the second Apple Pay email, looking for evidence that it was delayed, 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, but he had WAY more information about me than I would expect an average scammer to have, while I had no direct evidence that anything was amiss, nor had I given him any information he didn't already have, except for that mystery code. Plus, I was tired and busy, having already lost 45 minutes of my day to this, and just wanted to get this wrapped up while I still had time to breathe before my next meeting. So I gave him the benefit of the doubt for the moment - it seemed like he was just doing his best to wrestle with complex and convoluted systems and procedures, doing his job within the strict limitations of a company that trusts neither its employees nor its customers, and wanting this to be over with as much as I did.
After settling the name/ID/supervisor stuff, "Daniel" said that the process was complete. My account had been successfully disconnected from Apple Pay, and he just needed me to do one more confirmation step to wrap up. I didn't fully understand what he was talking about, though - he mentioned that I'd receive some sort of vaguely-defined confirmation email, but then said I needed to reply "yes" to it, which is what you do with a text message, not an email. So I asked a few times whether it was a text message or an email, and he kept saying it was an email, so I kept watching for incoming email messages. Whatever it was never arrived, but I dutifully kept checking, confused about what was happening, unsure whether "Daniel" was reading his script correctly, and assuming that yet another unseen technical issue was at fault for keeping this whole process going much longer than it needed to. And, in the midst of all this, he repeated some scripted end-of-call stuff, which sounded like we were done as soon as this mystery email arrived.
Then, out of the blue, he said he had one other thing to check, and asked if I had logged into my online banking account from the same city as those transactions. No, of course not. But, apparently, in addition to this Apple Pay nonsense, there was also a successful login to my Wells Fargo online account. Awesome.
This is the kind of thing that, after more than 20 years working with computers, evokes an instant, well-trained, well-practiced response. As soon as someone says anything that mentally translates to "unauthorized login", I immediately jump into investigating the potential breach and triaging the damage, so as soon as "Daniel" uttered those words, I immediately logged into my Wells Fargo account - to confirm that no one had changed my password yet - and changed my password, faster than he could even finish his sentence. Immediate danger averted? Of course, he had already "opened a case" about unauthorized online access, so we needed to go through that process now. Which involved him reading back my address again to confirm it was correct, then he asked for some information about the card (expiration date and CVV code, but not the full card number), my current account balance, my birth year, and the last four digits of my Social Security Number (a federal ID number issued in the USA that's considered extremely sensitive and private information, often used as a unique identifier for financial services). He asked all this while I was in full breach-investigation mode, hyper-focused on checking my transaction history, looking for something resembling online activity records in Wells Fargo's system (there aren't any), and checking my IP address to make sure I wasn't accidentally logging in from a VPN in a weird city. So I answered without really paying attention to what he was even asking, still mostly believing that this was a legitimate call, and the parts that looked shady were just due to poor system design and limited employee access to those systems.
Challenge Mode
After "Daniel" finished asking me for information and started doing something on his end, I refreshed my online transaction history, which I was monitoring closely while he was ostensibly opening a case about a fraudulent login to my online account. None of the transactions he initially called me about were there - which makes sense if they were flagged before they could be completed - but a new $150 pending transaction from "Apple Cash" suddenly appeared, while I was on the phone with someone supposedly resolving fraudulent Apple Pay transactions. And this was a new one, nowhere even close to the amounts of any of the transactions he initially called me about.
I immediately asked him about it, and he said that was another fraudulent transaction that snuck in while we were on the phone, before he was able to block my debit card, and it would be removed just like all the others. Another legitimate-sounding explanation at first glance, but it was at this point that I remembered the advice I give others about suspicious situations, and took a step back to slow things down and take inventory of what had happened up to that point:
- I received an unexpected call from my bank, normally a routine matter, which had now taken multiple different curveballs, spiraling a completely ordinary stolen/spoofed card number situation into a convoluted mess that even I, a technically-proficient person, was struggling to keep up with.
- The caller ID showed the correct name and number for my bank - I was not being called from an unknown or unexpected number - but caller ID data is so hilariously easy to spoof that it might as well not even exist.
- The caller seemed to be a very professional and experienced call center operator, sounding indistinguishable from a typical Wells Fargo employee. In fact, he was significantly more helpful and patient than any legitimate Wells Fargo employee I've ever interacted with. But major scam rings run real call centers, hiring people to do this as their real job, they just happen to be working for clients conducting illegal business instead of legal business. And while those fraudulent call centers aren't usually based in the US, there's no significant technical or workflow difference between working remotely for a legal call center or an illegal one, no matter where the operator lives. So I had been trusting this guy in large part due to my own cultural and linguistic biases, without even realizing it.
- He already knew my full debit card number when he called (I never gave it at any point in the call, or even the last four digits), and I haven't had this card for very long, nor have I used it at many different locations, but a year is enough time for my billing information to have been stolen in yet another data breach from yet another major retailer or service playing fast and loose with database security.
- He already knew my full legal name (with middle initial), mailing address (a place I haven't lived very long, and haven't had many things shipped to), and the phone number that's attached to my bank account (as mentioned before, that's an unusually accurate bullseye for me), without any of the information mismatches that someone cold-calling based on a single stolen database would normally run into. Combined with my full debit card number, that's a lot of information to compile, and all of those are datapoints I try to avoid putting together in one place as much as possible, for exactly this reason. But database correlation isn't that hard if someone takes the time to do it, and I can't be absolutely certain that I've never put all of these pieces into the same bucket before.
- He gave me a lot of authentic-sounding information about himself, and even offered to transfer me to his supervisor, which is not something a solo or low-effort scammer would usually be able to do, but I not yet actually challenged or verified the authenticity any of it.
- Prior to this call, no fraudulent transactions appeared in my account history. During this call, after supposedly de-activating my debit card, and while removing it from Apple Pay, a new fraudulent transaction appeared, which we hadn't previously discussed. This was allegedly due to the delay between the start of the call and the actual deactivation of my debit card, but I had no way of verifying that.
- The process of disconnecting my account from Apple Pay, according to this guy on the phone, looked suspiciously like helping him sign up for Apple Pay in my name, in multiple different ways. I could believe any one of those in isolation was a legitimate artifact of a poorly-built system that didn't have a good mechanism for resolving fraud, but all of them at the same time? Major tech companies are usually sloppy when building back-end systems, but rarely that sloppy.
- During all of this, out of nowhere, someone allegedly managed to login to my online account from another city, successfully, without tripping any alarms or alerts, implying they got the username and password right on the first try. And while the username would be pretty easy to figure out, I actually use a unique and complex password for online banking, which I don't use anywhere else, and that can't be extrapolated from variants of passwords that have been leaked in past data breaches. Not an impossible turn of events, but an unlikely and disconcerting incident of its own. And to have this unlikely event happen in parallel with my debit card number getting stolen and added to Apple Pay - two completely unrelated systems that do not affect each other - was too weird to overlook.
- While I was unable to find any sort of security logs or authentication records in Wells Fargo's online banking system to audit my own login history, I also had no direct evidence whatsoever that an unauthorized login had even occurred, except for the word of a voice on the other end of an incoming phone call.
- For most of the call, I spoke only in "yes" or "no" answers, careful to not give any information the caller didn't already have, except for the confirmation code from an email I still hadn't been able to fully read. But upon hearing that my online account had been compromised, I was so focused on investigating and containing the possible security breach that I inadvertently broke the cardinal rule of unauthenticated incoming calls: I gave the caller personal information he hadn't proven he already had, and didn't even realize I had done it until this exact moment when I was taking stock of the situation.
Putting all of this together, this started to seem like a scam call, but I still wasn't certain. It was all circumstantial and conjecture, and a lot of it seemed very legit, plus the difficulty of accurately putting together the information needed to make an attack like this against me without also including strategic disinformation that would tip me off about where they got their data. Additionally, while some of this seemed suspicious, none of it made any sense as a scam; if it was a scam, what was the point? The most sensitive piece of information I had given up was the last four digits of my Social Security Number (SSN), but my full SSN was stolen in the OPM breach in 2015 and the Experian breach in 2017 (and those are just the two I remember most distinctly), so if someone really wanted my SSN, they wouldn't need to pull an elaborate phone scam to get it. I needed to authenticate the identity of the person I was talking to, as fast as possible, and assess how much damage had been done, if any.
Step one, obviously, was to end the call, then call Wells Fargo myself, but I was worried about just hanging up if this was legitimate. So I started by asking how to get back to him from Wells Fargo's main phone tree if I ended the call and then dialed the customer service line myself, using the glitchy connection as a pretense; did he have a direct extension I could dial, or some other magical incantation of phone buttons I could press that would allow me to resume this process? Could I use the ID number he gave me to get transferred to him? With a resigned sigh - the sound of someone who knows they can't provide a good answer to a question everyone asks - he said that Wells Fargo's system had no mechanism to do that. Their customer support workers didn't have the tools to transfer a call to a specific person even if they were allowed to, and nothing resembling direct extensions that customers could dial. Additionally, he said that if we interrupted this unauthorized login claim/case before the process was finished, it would result in a fraud hold being placed on my checking account, freezing my assets for 7-10 business days, and the only way to fix it would be to go to a physical branch.
All of what "Daniel" said was completely consistent with my past experiences with Wells Fargo: A past attempt to reconnect to a specific person to quickly and efficiently resolve a complex problem, following up on a conversation a few days prior, resulted in three exhausting hours of bouncing between departments, eventually ending in one of them sending an internal message to the person I was trying to reach, telling them to call me, because there was no way to directly transfer me to a specific person, and no one else could just pick up where that specific person left off. And when I first opened my account, the letter containing the initial PIN for my new debit card never arrived, so I called to try to find out when it was sent or figure out an alternative way to set my PIN. Instead of helpful information, I was told that my only options were to continue waiting and hope it showed up at some point, or they could report it stolen, cancel my debit card, and put a fraud hold on my account, freezing my assets for 7-10 business days and requiring a trip to a physical branch (this was in the middle of a major COVID surge, so no thank you, I'll just wait forever I guess).
So, the idea that there was no way for me to initiate a call that would reconnect to a specific person or even a specific department, and the assertion that I couldn't just hang up the phone and call back in at this point without triggering an arbitrary and draconian hold on my account, were both completely plausible based on past experience, and not something I could afford to risk. But this was also straight out of Scam 101 - create a high-stakes scenario that induces panic in the target, must be completed with urgency, and which carries dire consequences for failure. In other words, a situation where the expected behavior of my bank and the expected behavior of a scammer were indistinguishable, and therefore not conclusive.
At that point, "Daniel" threw the biggest curveball of the whole call: He said they needed me to verify my full date of birth (not just the year), and my full SSN (not just the last four digits). But, to ensure my safety, and because "Wells Fargo employees cannot ask you for your Social Security Number verbally" (exact quote), I would need to enter both into their "secure automated verification system" using the touch tone keypad on my phone, each one followed by pound (#).
To an untrained listener, this might sound like a genuinely secure way to verify information, and I could imagine a lot of people seeing this as a huge point in favor of the call being legit. It's how this information is entered when you call the bank directly; Wells Fargo's automated system changes frequently (the exact information asked and the order of those requests changed even while researching this article), but two of the possible questions a caller can be asked before being connected to an operator are their full date of birth followed by pound, and their full SSN followed by pound. Which is precisely one of the things an attacker could potentially do with information like this: Record their victim entering the touch tones on their phone, then play it back during their own call to the bank. Because there's nothing special about pressing the buttons on a phone during a call, they just play two sounds simultaneously (one for the row, one for the column, a system called "DTMF"). There's no reason those sounds have to come from the phone itself, they can just as easily come from the microphone. Back in the day, this was called "phone phreaking", using tape recorders or separate keypads to inject DTMF tones into a call, usually to bypass phone company restrictions to make free calls. And, of course, those touch tones are also extremely easy to decode from recorded audio, so anyone listening to the call could simply convert them back into the numbers entered, as if the person had just spoken them verbally.
I was immediately suspicious, with this request pretty instantly pinging as a scam, but I still couldn't shake the fear of the possibility that this was legit, because if that was the case, simply hanging up would have dire and expensive consequences that I couldn't afford. And it wouldn't be the first time a bank randomly pulled an arcane, nonsensical, and ineffective security-theater trick out of nowhere in the middle of a legitimate call. So, I started asking technical questions; was he going to transfer me to another department for this, or to some other automated system? He said no transfer was needed, I could just start entering it at any time, which seemed like another red flag at the time - I was unaware of any call center software that could seamlessly capture and respond to touch tones in the middle of an active voice call, and while I've since been informed that this is relatively common, it still drastically undercuts the idea of this being a "secure" method of data entry, for all the reasons mentioned above.
Finally, after talking in circles about it for a few minutes, and getting lukewarm answers to all of my questions, I was unconvinced that any of this was legit. But I was still afraid to just hang up, and at this point, I felt like I was retaking some control over the call, approaching it the way I would approach a threat intelligence investigation; he caught me off-guard at the beginning, and successfully tricked me into providing information, but I wanted to gather more information of my own, to get a clearer picture of what he was doing so I could contain the damage Because it still wasn't making any sense. He started getting impatient, for the first time, but I had one more trick up my sleeve: When "Daniel" said to go ahead and enter my date of birth and SSN with the phone keypad, each followed by pound (#), I deliberately entered incorrect information for both. The real Wells Fargo would know what the real answers are, and if this step in the process was really doing what "Daniel" claimed it was doing, this should result in an immediate error in the system, which I could pretty easily play off as a mistake.
Instead of telling me that the information I entered was wrong, "Daniel" simply asked me to hold while the system processed my request. He failed my test. So I took advantage of the distraction, and used one of my other phone lines to call Wells Fargo myself.
Busted
Another persistent frustration I've had with Wells Fargo is the difficulty of navigating their phone tree with any sort of efficiency. It takes forever to actually get anywhere, with a whole parade of mismatched voices asking irrelevant nonsense along the way. So much so, in fact, that I didn't even realize I dialed the wrong number at first: In my haste, I mixed up two digits in the phone number, and didn't realize I was connected to the telephone equivalent of a fake company page parking on a misspelled domain until the third "would you like to hear about a special offer after this call?" gate in a row. Oops.
Calling the correct number, I sat on hold for a while, with "Daniel" still checking in periodically to make sure I was still there and reassure me that the system was still processing - I couldn't quite tell what he was doing, but whatever it was, he still needed me for something. Eventually, I connected to someone real at Wells Fargo's actual fraud prevention department. I told him I had someone on the other line claiming he worked at Wells Fargo, and I wanted to verify his identity. But instead of offering to do that, or even letting me finish my sentence, the employee I spoke to gave a very long, prepared speech about how "Wells Fargo will never call you or ask you for your personal information or for your account number" and so on. An entire paragraph of condescending script-reading that did not address the problem I was trying to solve, or answer any questions I needed to ask, and it wasn't even relevant to the situation, it simply wasted time in a time-sensitive situation. Eventually, as he transitioned into his end-of-call script without actually doing anything helpful, I managed to get his attention by saying that the caller never asked for my card number or contact information at all, he already had the whole thing, and a fraudulent transaction appeared in my checking account mid-call. His tone even shifted to intrigue when I reiterated that I still had the caller on the other line; he heard me that time, and was finally willing to listen and help.
He looked at my transactions, confirmed the $150 I saw, and mentioned another one that had just come in, also from Apple Cash, this time for $49. I verified that it wasn't legit, so he immediately blocked my debit card, and started the process of sending me a new one, which was word-for-word identical to the script "Daniel" used when allegedly doing the same thing. In the process, he confirmed that no such request had already been filed, and the transactions "Daniel" initially called me about didn't exist. He couldn't look up the supposed employee ID number I was given (in fact, he said Wells Fargo has no such identifiers they can give to customers for authentication purposes), but he did try looking up the name (I'm not sure how, exactly, but this was the point where I checked in with "Daniel" to verify the spelling of his name), and told me that no one by the name of "Daniel Coffman" or "Daniel Coffmane" works at Wells Fargo. Gotcha, "Daniel".
I was still on the phone with "Daniel" on the other line, who popped back on to reassure me that the "system was still processing", and it was at 35%. I don't know what that's supposed to mean - it makes zero sense in the context of submitting/closing a fraud claim - but the scam was obvious at this point. "Daniel" still wasn't done with me yet, and now that I knew what his game was, I was happy to string him along and keep him busy while fixing the actual fraud behind his back.
The real Wells Fargo rep took notes on the incident, and opened a claim for the fraudulent transaction (frustratingly, there's no immediate reversal of fraudulent transactions with Wells Fargo, and it took almost two full weeks for the extremely obviously fraudulent transaction still hasn't been reversed or refunded). But, while he was working on this, and after he had already blocked my card, more transaction attempts were still coming in. There were at least four of them while we talked, all blocked by the card deactivation, while "Daniel" still had me on hold and was still reassuring me that the "system was still processing". He hadn't mentioned the incorrect touch-tone information I provided, and seemed unaware that I slipped him false information while doing whatever he was doing. In total, on top of the $150 that went through, there were another five transaction attempts totaling $800 or so that were blocked, thanks to the quick action of the real Wells Fargo rep; once we got past the scripted response that primed him to ignore my actual query, he ended up being one of the more helpful employees I've ever spoken to at this bank, and I'm grateful for his assistance in this matter.
As I was wrapping up the call with the real Wells Fargo, I received an email notification that my card had been removed from Apple Pay (nearly an hour after that had supposedly been done), and "Daniel" said my claim had been completed, so we were all finished. I wasn't finished with him, though.
I may not be the most skilled counter-scammer, but wasting someone's time on the phone is something I can do very well when the occasion calls for it. So I strung "Daniel" along as best as I could, using every trick I could think of to force him to either go off-script and improvise, or continue talking to me far longer than he wanted to; I may not be able to get my money back from him directly, but I wanted to at least make that money as costly for him as possible, and delay him from preying on anyone else for as long as I could. I asked for confirmation numbers of everything we had done, asked for clarification on everything he told me, went off on a whole tangent about permanently blocking my account from ever being connected to Apple Pay again, and generally tried to make him repeat himself and waste as much time as possible, without giving him any further information. The funniest part was when I asked about that $150 that still hadn't been reversed, and he assured me multiple times that my account was "FDIC insured", which isn't at all how the FDIC works (it's insurance to reimburse account holders if a bank goes out of business and takes their money), but I couldn't get him to explain how I would go about making an FDIC insurance claim. I guess he didn't have a prepared answer for that one.
Finally, when I was out of cards to play, I decided to retroactively call his bluff from earlier, and asked to speak to his manager, to express my gratitude for all his help and patience in getting this resolved. At this point, he had been on the phone with me for over an hour and a half, nearly 30 minutes past the point where he tried to dump out of the scam and move on to his next victim, but he said he'd be happy to, and transferred me to some extremely generic hold music. Eventually followed by the line going dead. So, I never found out who was supposed to play the role of the "manager" or what their playbook was, but I received a couple more calls that appeared to be from Wells Fargo later in the day. I didn't answer.
What Went Wrong?
This scam went against everything I thought I knew about social engineering attacks. While most of the tricks and tactics used against me in this attack were not particularly novel, the combination of all of them was unexpected and new, and the whole thing was masterfully executed on a level I honestly find impressive. At the same time, I made some critical errors during this call, and those are worth analyzing; failure is sometimes the best teacher, and I try to always study and learn from my mistakes, especially when doing so isn't fun or flattering. So, even though a full tactical analysis isn't the intended primary goal of this article, there are a few notable items I want to examine.
The Email I Should Have Read
The single biggest mistake I made during this process was not reading the entire email containing the Apple Pay verification code before relaying the code to the attacker. In fact, I didn't read the whole thing until long afterward, when I took a screenshot for this article.
Verify your card in Apple Pay using code
[redacted]1: Return to Apple Pay.
2: Select your Wells Fargo card ending in[redacted].
3: Enter this code:[redacted].Important: This code is only valid for 10 minutes after it is sent to you. If it is not entered within 10 minutes, it will expire and you will need to request another code.
Once your card has been verified, you'll receive confirmation that the card is ready for use in Apple Pay.
If you did not request this code, or if you have questions, please call us at the toll-free number on the back of your card. Wells Fargo will not contact you by phone or text to request this code.
In my defense, the most important part of this email that I needed to see - the warning that Wells Fargo would never request this code via phone or text - is so buried at the end that even many readers of the initial draft of this article didn't see it at first, and they had the benefit of looking at it in a large screenshot, perfectly presented, while focused on reading, with the foreknowledge that this was, in fact, a scam. I first saw this on a small phone screen (I took this screenshot much later, from my computer), where that part of the email wasn't even visible without scrolling, while I was tired, anxious, busy, and trying to triage what I thought was a critical incident. With someone incessantly talking directly into my ear the whole time while I was trying to read. Far from ideal circumstances.
To borrow from Doctor Strange: They really should put the warnings before the codes. Not because I needed to be explicitly told not to relay a 2FA code to a stranger over the phone, but because that would've been the signal I needed to realize that this even was a 2FA code. Had I seen that part earlier, this scam would've been over before it began. Of all the points in this call where I could/"should" have hung up, this is, realistically, the signal that would have caught my attention the most, and would have been the most likely to cause me to quickly exit, or at least not give the code to the attacker.
Everything is Broken
I also, admittedly, allowed my cynicism toward my own industry and Wells Fargo to cloud my judgment; I didn't know the first thing about Apple Pay or Google Pay prior to this incident, but I don't have particularly positive experiences or feelings toward either company in general, and it's extremely common for the process of fixing someone else's mistake on large tech platforms to be nightmarishly convoluted.
A perfect example of this would be the constant flood of people who aren't me signing up for accounts on various services that are attached to my Gmail addresses. This happens frequently to people with older Gmail accounts that have short usernames, thanks to a combination of Google's approach to punctuation in email addresses (making it extremely easy for less-savvy users to get confused about what their own email address really is), and a large number of tech companies deciding, en masse, that verifying a user's email address during account registration just isn't important anymore. Trying to remove my email address from any one of these accounts requires spending huge amounts of time on the phone, trying to explain things to customer service reps who don't understand the problem I'm trying to solve, and don't really even understand why I'm calling at all; if they interpret the problem as trying to cancel my own account, they transfer me to a sales person who tries to upsell me on staying signed up for a service I didn't sign up for in the first place. If they interpret the problem as trying to cancel someone else's account, they write me off as a malicious actor and hang up. No one seems to have a script for "someone else created their own account that I don't have access to, using my email address without my permission, and I want my email address removed from their account". And this is for something as trivial and low-stakes as a mistyped email address.
So when some random stranger with a legit-looking cover story said "Apple Pay is so janky that the process of fixing someone else's fraud looks extremely shady and nonsensical", my instinctive first reaction was "yeah, that checks out", which is the exact same gut reaction I would have to someone saying the same thing about Google Pay. And based on all of the interactions I've had with Wells Fargo in the last year and a half - the aforementioned examples are just a few of many nightmare stories I've accumulated with this bank - I was solidly primed to expect the worst at every turn. Thus, when that same random stranger said "If you hang up in the middle of this arbitrary and opaque process we've started, you'll completely lose all access to your account for two weeks, and the only way to fix it is to spend an afternoon at a physical branch, and I have no control over that, I'm as helpless in this situation as you are", my instinctive first reaction was "yeah, that tracks with every other conversation I've ever had with this bank". In fact, that reinforced the realism of the call to me, in the moment, because it was exactly what I expected from Wells Fargo.
I recognize that these are not healthy or productive attitudes - this incident proved it - and I'm working on that. But, that's the mindset I was in at the time, which turned out to be easily exploited. Simply put, setting aside the skillful delivery, this guy was pretty obviously acting like a scammer, but I also would expect a genuine Wells Fargo employee to act like a scammer. They've cultivated a customer service atmosphere where real employees tasked with solving real problems are functionally indistinguishable from scammers pretending to solve fake problems to extract information, and the processes by which they operate are easily exploitable by malicious actors trying to create infinite hurdles to make their targets jump through. This is something they share with a disturbing number of major tech companies; good customer service has been treated as such an afterthought for so long, by so many companies, that a scammer can portray dealing with any major tech company as a frustrating, confusing, and invasive process, and it really doesn't look that different from many people's expectations, especially outside of our industry.
Nerd Sniping
A concept I've always found illuminating, coined by XKCD, is the idea of "Nerd Sniping". It's something most of us in engineering fields - across many disciplines - are very prone to, myself included: When presented with an interesting and novel problem, there's an extremely strong - if not irresistible - urge to drop everything to work on it, potentially to the point of ignoring danger. It happens all the time, and it's easy to do to ourselves. If you've ever played a game or used some other software with one random feature so lovingly-crafted that someone clearly spent way too much time on it, they might have nerd-sniped themselves. It's the reason why my personal website uses LaTeX - a complex typesetting language from the 1980s - to compile written articles into PDFs, instead of just dumping text into PyFPDF like a normal person.
This incident is the first time I've ever directly witnessed malicious usage of nerd sniping in a real-world attack. I can't say for sure that "Daniel" knew what he was doing and did it intentionally, but he presented me with a very interesting and confusing puzzle - how did someone manage to login to my online banking account without tripping any alarms or triggering even a single failed password error? - and I got so hyperfocused on trying to solve it that I blindly answered his questions without thinking, and didn't even realize he fabricated the whole thing. There was never an unauthorized login. It was just a ruse to give me something to panic about and a distraction to overfocus on, and it worked shockingly well, multiple times in the same call.
Skilled Adversary
Put simply, "Daniel" was extremely good at his job. He was more professional, knowledgeable, patient, and relatable than most legitimate Wells Fargo employees I've talked to. He had an intimate understanding of Wells Fargo's policies, procedures, and common customer service frustrations, which he expertly weaponized against me, invoking and subtly twisting real policies and procedures in a way that most casual or amateur attackers would not be able to pull off. On top of that, he had a lot of general technical knowledge, and seemed to have a pretty solid understanding of my technical knowledge and expertise, which he weaponized against me in a way that I would expect to encounter at DEF CON, not from some guy cold-calling me in the middle of a Wednesday.
For the most part, he wasn't asking me to do anything obviously suspicious, and the few suspicious requests he did make were either well-explained, or well-timed during a distraction, or so obscure that I doubt most less-technical users would have known the risks. He stayed on the phone for a long time, never in a hurry to finish until more than an hour later, which is unusual without the potential for a very high payout (I definitely do not have that kind of money). And while he did work to build urgency and create panic - a standard component of all scams, to disrupt the victim's critical thinking - he did it in novel and subtle ways that I didn't even pick up on, even though I used to literally teach other people how to do these attacks as part of my job. He even managed to pull off one of the most basic tricks in the book - mixing requests for new information into confirmations of existing information - so smoothly that I didn't even notice he was doing it, which is a first.
So, while it would be intellectually dishonest to pretend I'm not an "easy mark" sometimes - I may be perpetually paranoid, but I'm also easily distracted, and generally very optimistic and empathetic toward people by default - I've always been an eager student of human behavior, and I'm highly adept at studying and analyzing patterns, even if I don't always recognize them at first. From that perspective, I'm genuinely impressed by "Daniel", not because he successfully tricked me, but because the skills he used to do so are top-notch, and I suspect he could've tricked almost anyone who gave him even the slightest bit of attention.
Doing Better
Looking purely at the play-by-play of how this call went, I definitely made some mistakes that seem obvious, and I could easily go on for more pages analyzing everything I did "wrong". Or, at least, they seem obvious in hindsight, and that's exactly the problem: It's easy to look at a situation like this and say "Oh, well, she should've known better", which is usually our default response in the infosec world. We often operate under the belief that social engineering attacks can be prevented with better training, and, quite frankly, we can be very condescending in analyzing these situations, chalking them up to the victims not knowing enough to recognize danger.
Just a week before this incident occurred, new information came out about a breach at one of the largest authentication service providers in the industry, revealing that this was the result of a social engineering attack against their customer service subcontractor. Many of us throughout the infosec field have been analyzing how Okta could have better guarded their data against infiltration, or how their customer service workers could have been better trained, and generally hand-wringing over how we can further restrict the wide-reaching system access customer service departments need. But how many of us stopped to think about how the employee who got scammed is feeling, or what could have been done differently to help them feel safer and more comfortable reporting potentially-suspicious activity in advance, before it became a critical incident? I know I didn't, and that was insensitive of me. We always say we'd rather people report a thousand false alarms than fail to report a single real emergency, but if filing those reports results in condescending info-dumps or intimidating interrogations, is it really a surprise that so many people have been trained to just not say anything and hope their suspicions were wrong?
Perhaps this is just me trying to protect my bruised ego, but I feel like the lesson here isn't really a question of what I could've done differently. Rather, my own personal takeaway is a humbling reminder that everyone can get scammed, and no one is immune to deception or manipulation, not even the self-proclaimed experts. Training to identify and defend against social engineering is vital, but all the training in the world can't fully stop it from happening; we also need to ensure we're creating a safe, supportive, non-judgmental environment for people to report suspicious calls/emails/messages, and provide tools and procedures for someone to quickly and easily "check in" about a contact they're unsure about. And, while anti-scam training usually focuses heavily on how to identify and prevent such attacks, we should really put at least as much emphasis (if not more) on how to mitigate the damage after an attack. In security engineering, focusing on breach prevention instead of post-breach damage mitigation is now seen as a hopelessly outdated security posture, but we still tend to apply that attitude to the human side of security, even when we say we're not.
At the end of the day, all of us working in security, regardless of where we are in our respective careers, are just people, doing our best to help keep other people safe. Which is, ultimately, what this is all about; no one is perfect, everyone makes mistakes, and sometimes those mistakes carry expensive consequences. But in a security breach, every second matters, and we can't afford to waste time on our users and coworkers second-guessing themselves or fearing what will happen if they come forward with a possible incident, both of which happen a lot more often than we realize. Information security is like being a digital firefighter: Our job is to contain the fire before it spreads, then extinguish it, and the faster we can get started, the better the outcome will be for everyone. If someone waits to call for help because they're not sure they really smell smoke and they're afraid of getting berated for a false alarm, even a minor delay can carry dire consequences.
So this is my way of extending that olive branch, to say it's normal and human to make mistakes, even security-related mistakes, and that doesn't make you a bad person, or incompetent, or stupid. It makes you human. And we're human too. I'm human too. It's certainly better to avoid making the same mistake twice, and avoid making the same mistake as someone else if possible, but that's not what really matters in security. What really matters is to recognize what happened as fast as possible, take steps to correct it, and work cooperatively with our users and colleagues as a supportive team. Because if a firefighter gets called out to someone's house to put out a kitchen fire, it's a lot more productive to say "hey, it's ok, these things happen, at least we caught it before the whole house burned down" than to berate the caller for being reckless in the kitchen. Maybe I'm just idealistic, but that's the kind of workplace and security culture I'd certainly like to cultivate; as a security engineer, my job isn't merely to keep people safe. My job is to help them feel safe, so we can help each other stay safe.
And lastly, if you're reading this, Daniel Coffmane #1687979, whoever you really are: Well played.
This article has been updated as of January 10, 2025 16:57
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.