What is the mechanism for this user impersonation?

Question

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: joe@olddomain.com. 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?

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.