Update: I've added an addendum to the end of this post, to provide clarifications and address feedback I've received since publishing this. Thank you, everyone!

---

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, totaling 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, but he had WAY more information about me than I would expect an average scammer to have, and I was tired and busy and just wanted to get this wrapped up. So I gave him the benefit of the doubt for the moment, but maintained heightened suspicions.

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. 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, kinda 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 account. Awesome.

This is the kind of thing I've spent my career training to rapidly respond to, so as soon as Daniel said this, 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. Problem solved, right? Well, no, he had already "opened a case" about my online access, so we needed to go through that process now. Which involved confirming my address (again), some information about the card (expiration date and CVV code, but never the full card number), my current account balance, my birth year, and the last four digits of my social security number. He asked all this while I was busy changing my password, checking my transaction history, and checking my IP address to make sure I wasn't accidentally logging in from across the country myself, so I gave it to him without thinking, still under the assumption that this was a legitimate call, and the parts that looked shady were just due to weirdness with Apple Pay.

Challenge Mode

After re-confirming details "Daniel" already had, and giving a couple new bits of information, I refreshed my online transaction history, which I was monitoring closely while this guy was ostensibly working through 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.

Obviously, I immediately asked him about it, and he said that was another fraudulent transaction that got flagged, and it would be removed just like all the others. It was at this point that I remembered the advice I give others about suspicious situations, and took a step back to think critically about what had happened:

• I received an unexpected call from my bank, normally a routine matter, which had now taken multiple different curveballs, ballooning an ordinary stolen/spoofed card number situation into a complex 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, 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, and while many large-volume scammers set up/hire illegal call centers where real people do this as a real job, he also had a distinctly North American accent, and it's a lot harder to run an illegal call center in the USA or Canada than in Asia, Africa, or eastern Europe. However, it's trivially easy for anyone to work a call center from anywhere in the world, regardless of where the company is actually based, and it doesn't really matter whether that call center serves legitimate clients. So I was inclined to trust him, but that's based entirely on my own biases, not anything concrete.
• He already knew my full debit card number (I never gave it at any point in the call), and I haven't had this card for very long, nor have I used it at many different locations.
• He already knew my full legal name, 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). 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, and I can't say for 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 scammer would usually be able to do, but I had not yet actually challenged any of it.
• Prior to this call, no fraudulent transactions appeared in my checking 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.
• The process of removing my card 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 one or two of those were legitimate artifacts 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 often sloppy when building back-end systems, but rarely THAT sloppy.
• Someone allegedly managed to login to my online account, successfully, without me knowing about it, meaning they already had my username and password. And while the username would be pretty easy to figure out, I actually use a unique password for online banking, and it's complex and different enough that it's unlikely someone would be able to harvest it directly or extrapolate it based on other passwords that have been compromised. Not impossible, 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.

Putting all of this together, the scales started to tip toward this potentially being 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. I needed more information. It was time to push back on this.

I started by asking if I could call the customer service number myself, and use the ID number Daniel gave me to continue this call. He said doing that before we completed this claim process would result in a fraud hold being placed on my entire checking account for 7-10 business days, unless I physically go to a branch. Which is actually consistent with similarly nonsensical policies I've encountered with Wells Fargo before (I hate this bank so much), so that tracks with something a legitimate Wells Fargo rep could say, but it's also straight out of the scammer handbook as a way to create urgency and panic and keep the victim engaged until they're done. 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 Social Security Number (a federal ID number issued in the USA that's considered extremely sensitive and private information), but that I could do it by entering it using touch tone keys, for security reasons.

To an untrained listener, this might sound like an extremely secure way to verify information, and a huge point in favor of the call being legit. It's how this information is entered when you call the bank directly; they ask you to type in your birthdate, and if you don't have your account number, you have to enter your social security number. Which is precisely what an attacker could 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), which can be decoded to identify which button you pushed. 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", and often used to make free calls from payphones using a tape recording of the tones made when inserting coins (until phone companies figured out a way to hide those tones from coming through the speaker before a call was connected). Just put the speaker of the tape recorder next to the phone's microphone, press play, and voila! The phone company thinks you paid for the call, and will allow your call to go through.

So, I was immediately suspicious, and 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 is another red flag - while I'm no expert, I've never heard of a call center system that can accept touch tones seamlessly while a call is active, and it would take extremely sophisticated audio processing capabilities to be able to do that, since the frequencies used by touch tone keys heavily overlap the frequencies of human speech.

Finally, after talking in circles about it for a few minutes, and getting lukewarm answers to all of my questions, it seemed like there wasn't an easy way around this, 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, I deliberately entered incorrect information. The real Wells Fargo would know what the real answers are, and should throw an immediate error if this step in the process was doing what "Daniel" claimed it was doing. And getting it wrong on the first attempt was something 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. So I used one of my other phone lines to call Wells Fargo myself.

Confirmation

Among the many things I despise about Wells Fargo is their phone tree. It takes forever to actually get anywhere, and asks a bunch of irrelevant nonsense along the way. So much so, in fact, that I didn't even realize I dialed the wrong number at first: I mixed up two digits in the phone number, and didn't realize I was connected to the telephone equivalent of a scammy misspelled URL until the third "we have a special offer for you!" 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. Eventually, I connected to someone real at Wells Fargo. He started with the usual boilerplate stuff about Wells Fargo never asking someone for their full debit card number, but his tone quickly shifted to intrigue when I pointed out that this scammer never asked for my debit card number, and that I was still on the phone with him.

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 the card, and started the process of sending me a new one. In the process, he confirmed that no such request had already been filed, the transactions "Daniel" called me about didn't exist, and while he couldn't look up the supposed ID number I was given, he confirmed that no one by the name of "Daniel Coffman" or "Daniel Coffmane" works at Wells Fargo.

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" wasn't done with me yet, though.

The real Wells Fargo rep took notes on the incident, and opened a claim for the fraudulent transaction (frustratingly, there's no immediate reversal; have I mentioned yet that I loathe this bank?). 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, and 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, obviously not knowing it was fake. In total, on top of the $150 that went through (and that I'm disputing), there was another $800 or so that were blocked, thanks to the quick action of the real Wells Fargo rep.

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.

Admittedly, improvisation is not my strength, but I strung "Daniel" along as best as I could, asking for confirmation numbers of everything we had done, getting clarification on everything he told me, and generally trying to make him repeat himself and waste as much time as possible, without giving him any further information. Because if you're gonna scam me, I'm gonna scam right back; I may not be able to trick money out of a scammer trying to trick me, but I can at least waste a LOT of time. The funniest part was when I asked about that $150 that still hadn't been reversed, and he reassured me 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 for some reason I couldn't get him to explain FDIC to me.

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 nearly an hour and a half, 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 whether the "supervisor" ever really existed.

What Went Wrong?

This scam went against everything I thought I knew about social engineering attacks. The caller was professional, knowledgeable, patient, and easy to understand (connection issues notwithstanding). He had so much information about me already that, even knowing how easy it is to find sensitive information about people, I was inclined to take him at face value; all of my defensive information-control practices that usually make me hard to scam clearly failed in this case. For the most part, he wasn't asking me to do anything obviously suspicious, and the one thing that did seem suspicious before I caught on was something he had a cover story for that sounded plausible even under critical examination, with the other suspicious task being so sophisticated and technologically obscure that I doubt anyone else would've even picked up on it. He stayed on the phone for a long time, never in a hurry to finish and get off the line until the end, which is the opposite of how scams usually work. 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.

On the other hand, looking purely at the play-by-play of how this call went, I definitely made some big mistakes. I trusted the caller too much, gave up too much information before confirming whether it was real, and made a really obvious error with the Apple Pay authentication code. Or, at least, it seems obvious in hindsight, and that's exactly the lesson here: It's easy to look at a situation like this and say "Oh, well, she should've known better", and we do that a lot 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 sometimes be very condescending in analyzing these situations, chalking them up to the victims not knowing enough to recognize danger.

Just last week, as I write this, new information recently came out about a breach at one of the largest authentication service providers in the industry, revealing that this breach occurred as the result of a social engineering attack against their customer service subcontractor. Many of us throughout the infosec industry have been looking at this through an engineering lens, analyzing how Okta could have better guarded their data against infiltration, and generally hand-wringing over how much access customer service departments have to wide-reaching systems. But how many of us stopped to think about the employee who got tricked into providing their credentials is feeling, or what could have been done differently to help them feel safer and more comfortable reporting potentially-suspicious activity sooner, 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 the process of 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, 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 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 create 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. On the engineering side of things, 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 the equation, even when we say we're not.

So, while there's definitely some valuable technical information in this incident - this was a highly sophisticated attack, employing some techniques that are, as far as I'm aware, fairly novel - I think it's more useful to focus on the mitigation steps, and the human side of the equation. If you're starting to feel suspicious about an ongoing call/interaction, getting external verification as fast as possible is vital, whatever it takes. Not everyone will have access to multiple simultaneous phones, but you can put the person you're talking to on hold if you have to, or borrow a phone, or use text chat if it's an option. When in doubt, ask questions; even if they have an answer for everything, keep asking questions until you're satisfied, because even the most skilled and well-prepared scammers will eventually run out of good answers. And always remember that if you suspect someone isn't being honest with you, you are under no obligation to be honest with them; even if you're only slightly suspicious, you can try giving them false information as a test, especially if it's information that an authentic contact should instantly have available.

And lastly, if you're reading this, Daniel Coffmane #1687979, whoever you really are: Well played.

---

Update: Clarifications and Addenda

This post has gotten far more traction than I expected, thanks to the readers on Hacker News, thank you all so much! And thank you to matiskay for posting this there in the first place, I was not expecting that. I usually blog in obscurity, so this is new for me. I know common internet advice is "don't read the comments", but I read the comments, and I wanted to take a moment to respond to some of the criticism I've received since writing this.

First of all, I wanted to make some clarifications about how the call went, and who had what information at what times. I was actually planning to simply revise the article, but given how many people have already read it, I'll add it here instead. Starting with the very beginning; I mentioned that the caller "verified" my information at the start of the call, which I didn't phrase very well. So, to be clear, all I did was acknowledge information he already had. Before this call even started, "Daniel" already had the following information, and didn't ask me to provide anything:

1. My full legal name, including middle initial.
2. The correct primary phone number that's associated with my Wells Fargo account.
3. My full mailing address that's associated with my Wells Fargo account.
4. The last four digits of my debit card number, which he recited to me over the phone.
5. Presumably the rest of my debit card number, to add it to Apple Pay.

So, the first segment of the call, before the Apple Pay thing, was such a textbook-perfect example of the "correct"/standard way for banks to make transaction verification calls that, until he got to the payload of the scam, it was honestly a smoother and more positive and helpful call than any legitimate interaction I've ever had with Wells Fargo (which, in and of itself, probably should have registered as suspiciously too good to be true). Even after that point, the call consisted mostly of him giving me information he already had, and the few things he asked for did not seem even slightly suspicious in the moment, it was all in aggregate; he didn't ask for big, obvious datapoints until long after the point where I picked up on the scam.

Also, at the point where he wanted to record the touch tones from me entering my SSN and birthdate, I should probably clarify that I don't actually know what he planned to use that for. My hypothesis, based on the format and what I know about the Wells Fargo phone tree, is that the plan was to use the playback of my entry to have an accomplice impersonate me to Wells Fargo employees, but that's only a guess. And even if it's an accurate guess, I don't know what the end goal would be. All I know is that he kept me on the phone for well over 20 minutes trying to do whatever he was doing, before realizing he had been caught and trying to dump out of the call, and I don't know whether he realized I intentionally slipped him bad information, or just chalked it up to a glitch on his end or a mistake on my part that he didn't have a non-suspicious way to ask me to correct.

As for the feedback this post has received: A lot of people have pointed out that banks and credit cards making outgoing fraud alert calls to customers is no longer a standard practice. That's completely fair, and an area where I was operating on outdated information; these sorts of fraud alert calls were standard practice for every bank and credit card I had as recently as 2018, and I was unaware that this is no longer the case. While it may seem like 2018 was an extremely long time ago, it really wasn't, and the only people who seem to be consciously aware that this was a trend shift for security reasons are some fellow security professionals, and people who work in banks.

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, 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 all the user accounts on other services that are attached to my Gmail accounts, which constantly spam me to the point of making those email accounts unusable, but trying to cancel any of them 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, all because someone signed up and mistyped their email address, and a ton of tech companies seemingly decided that it was no longer necessary to verify email addresses on account registrations anymore. So when some random stranger with a legit-looking cover story said "Apple Pay is so janky that the legit process of fixing someone else's fraud looks extremely shady", my instinctive first reaction was "yeah, that checks out", which is the exact same gut reaction I would have to the someone saying the same thing about Google Pay. And I'm not exaggerating when I say that literally every interaction I've ever had with Wells Fargo customer service has been such a nightmare that they always leave me feeling nothing but broken frustration and simmering disdain, so when someone posing as a Wells Fargo employee says "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", my instinctive first reaction is "yeah, that tracks with every other conversation I've ever had with this bank". In fact, that kinda reinforced the realism of the call to me, at first. 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.

Of course, it also didn't help that this scammer was very good at his work. I alluded to this at a few points, but I didn't put it all together in the original article: I've taught training sessions on how to perform social engineering attacks, to people who do them as part of their job, all of whom were highly-skilled experts in their respective fields, and "Daniel" would've been at the top of the class. He caught me while I was distracted, tired, and busy, slipped most of his requests for information into confirmations of details he already knew so seamlessly that I didn't even realize I had given something away until after I already did it. Plus, I naturally struggle to read/write while also listening/speaking, so if someone's talking incessantly in my ear while I'm trying to read an email, it's really easy to overlook the entire paragraph of security-related instructions and disclaimers at the bottom of that email. I won't pretend to be the best of the best or at the top of my field or anything, but I'm pretty confident that I'm at least decent at what I do, and I stand by my work (much of which is classified). But 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, the point I wanted to make with this article; 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, which is something that happens a LOT more often than many of us realize. So, I guess my message with this article is to say that making a security mistake doesn't make you a bad person, or incompetent, or stupid. It makes you human. And we're human too. In many ways, infosec is like being a digital firefighter: Our job is to contain the fire before it gets any worse, then put it out, and the faster we can get started, the better things will be for everyone. Ideally, we should be working with the people we're protecting, and that's much easier to do with an empathetic approach.

So this is my way of extending that olive branch, to say it's normal and human to make mistakes, and avoiding making these sorts of mistakes is not what really matters in security. It's certainly better to avoid making the same mistake twice, but what really matters is to recognize what happened, and 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.

Thanks for reading.

---

This article has been updated as of March 31, 2022 17:23