I don't think that there is a standard way that this type of fraud is perpetrated, but I can tell you what I have seen and what I do when this happens to us, when about once every two months we get "change my bank account" emails sent to suppliers "from" our mail systems.
Our first thought is that the scenario didn't happen and that we have fraudulent staff working in collusion with the supplier. We have to rule that out, so we may review the staff emails looking for anything suspicious. This invariably turns out to be a dead end.
Then we ask if our own mail system or user accounts have been compromised: we have had this where a bad actor had access to an email account and could intercept, reply and delete mails as they arrived. It was very cheeky so don't underestimate these criminals. We spotted this as a users was logged in from two places at one, which is normal because of our business and use of VPNs etc. Because we have an immutable store of all messages we can see the deleted ones. We put in two-step verification to mitigate this risk and now we are very confident that an email account with 2SV is not compromised. Not 100% confident of course and it is still an option.
Then we look at the mails outbound from our domain and look for bounces and we ask the recipient email team to look in their logs for our mail. This has mixed results. In your case you say that your outbound mail never arrives, so I'd be looking at our outbound logs for mails to the domain and I would be checking the MX record of the recipient domain. If the message really did go out from our system, I'd get the message ID from the header and ask the recipient mail team to tell me if they have received it. The results are mixed because often the recipient organisation does not have an IT team and they don't know how emails get routed, delivered etc. It would be quite unusual for all emails to mydomain.com not be be delivered at all and quite unusual for a man-in-the-middle to be capturing all the mydomain.com mails and forwarding them, but I guess it's possible. If the recipient organisation never gets the mails then that spins off another query: why. Of course trying to do this over email when the recipient email system might be compromised is flawed to say the least. But the fact that your emails do not hit the recipient is a big indicator to me and I would want to get to the bottom of why. My hypothesis is that the recipient has shared their web-email password and a bad actor is logging into their account because that is a simple approach. Bad actors can get the password through various ways but one way that i have seen is they send a link to an online O365 doc or Google Doc that required a login and the user logs in using that link and the bad actor then has the password. There are other ways, I'm just saying this is what I have seen.
You say that your client sends mails cc to a manager but those don't arrive? That sounds like an interesting avenue to pursue. I would want the sender to check their logs for mails to the manager and our system for mails inbound for the manager. My hypothesis being that one or other of the mail systems is compromised. In the investigations I have run, the compromise has usually (well always now) been with the recipient email systems, the reason for this is that our systems have many defences in depth but we deal with small suppliers who don't have an IT engineering function. But we keep an open mind always as we really do not know until we have the data.
So now firstname.lastname@example.org sends an email to the recipient. If Alice Smith's corporate email account were under the control of the bad actor then my assumption would be that they would not bother with the @outlook.com address, but that's just an assumption. I'd ask myself why the recipient is dealing with @outlook.com rather than the real company, but perhaps the bad actor has changed the FROM address. We get that too of course. If the email sent out does match the email that was sent back with minor changes the obviously someone has intercepted that mail. I would want to confirm that though as the scams I have seen often have the email signature of one of our staff, it has a PO number etc but it's totally fake, but looks plausible. We know this because there is no exact match in the immutable email store that has been altered, but the human sender misreads the situation and says that it is the same email.
We now realise that it's a fool's errand to try to stop these scams most of which now originate with the recipient: their mails are compromised, they answer a fake email and change details etc. Some of the controls we have put in place to prevent a successful scam include:
- 2SV on all email accounts
- immutable storage for all emails so we can search actual content without the users being aware (we have governance for the process)
- Constant communication to staff "don't change bank account details based on an email" and "no, the CEO will never write to you telling you they want you to make a secret payment"
- Our internal payroll teams don't (or shouldn't) accept a "change my bank account" email, they should use a form on the intranet so that deals with message spoofing, but not account hijack. We have so many payroll teams though it does not always get through
- SPF, DMARC, DKIM. These are great ideas and I am sure they work well for small organisations. If you have these in place then the idea is that the recipient mail servers will use these to identify fraudulent mails. In practice for a big enterprise it's a big old effort and we realised that implementing DMARC and DKIM would kill our business because of the vast number of email sending domains, devices, third parties etc and we would need to employ a team just to deal with that. SPF works OK for us, most of the time. If you are not aware of these then Wikipedia will guide you but as I say we found them a great idea but simply too complicated for us to use in our enterprise. O365 may well come with these in place already?
- Mail inbound rules that flag spam from known bad domains. We know about legitimate service providers that host spam sending servers that our mail spam engine allows through, so we flag all mails from, for example, GoDaddy servers. It's whack-a-mole and we really let our cloud email service provider deal with spam
We have not implemented any third party tools that do "email security" because of the cost and because we have protection from Google, which isn't perfect but it's good enough.
When i look into these issues I find these tools useful
I have not answered your question directly for your specific case because I don't have enough data, though others may have come across this exact scenario, but I thought it might be helpful to share what I do although I accept it's not a perfect process and I make assumptions that are not 100% proven.