I'm trying to understand how this user impersonation might have taken place. Here's the scenario:

Our controller got a call from our bank this morning about a suspicious wire transfer request. After some back-and-forth with the controller and with the bank, we've established that this is what happened:

  1. Somebody sent an email to the bank requesting a wire transfer using an old domain of ours: [email protected]. This is an old domain that we used to use for email and which we still own. Email service is still set up for this domain, however all email address have been replaced with aliases that forward email to addresses at our new domain.

  2. The bank replied with instructions & a form to complete.

  3. The bad guy sent back the form, completed and signed, from a hotmail address. The bank may also have spoken to the bad guy - that's not clear to me (since I'm getting the information second hand).

  4. The bank called us (at our phone number on record) to confirm the transaction.

The question I have is this: how did the bad guy get the email which the bank sent? We have checked the logs for both our email systems (both old and new) and there are no recorded visits from any unusual IP addresses.

I think it was a simple "reply-to" header on the original email, and the person at the bank didn't notice that the reply was being sent to a different email. But shouldn't the bank have something in place to alert the user if the "reply-to" address is different from the "from" address?

My co-worker thinks the only other possibility is the bank's DNS record being hacked to redirect outgoing email. That seems highly improbable to me - is it possible that the bank's DNS record was hacked?

Finally, are there other ways for this to work?

1 Answer 1


Always go with the simplest choice.

Almost certainly it was a forged email with a legitimate (temporary) reply-to. No need for anything more complex. The staff at the bank use the same tools as everyone else for front-end customer contacts. Do you check reply-to addresses? No, neither do I & nor does the bank. Instead, they rely on their nested processes to mitigate the risk - which worked, so no problem. At least as far as the bank is concerned, they blocked the fraud and that is about all they need to do.

Whilst the bank could have been subject to a DNS-poisoning attack, this is quite unlikely and far too complex and costly for it to have been worth-while doing for such little return.

  • As it turns out, it was the reply-to header - I should have made a bet! While I agree that nobody checks reply-to addresses, it seems to me that a relatively simple security check would be to have your email client alert you to differences. At any rate, thanks for your answer!
    – Kryten
    Commented May 29, 2014 at 22:10
  • Ha, nice to know I got it right - thanks. I've worked with various financial institutions including banks and they work on risk/reward. Checks at the front-end cost too much in relation to the risks they reduce. And current email clients are pants! Commented May 29, 2014 at 22:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .