When a client's mailbox is sending fake invoices, the password reset is only the beginning

Sooner or later a practitioner gets the call. A client's vendors, or the client's own customers, are receiving invoices and payment-change requests from an address inside the client's company, and nobody there sent them. The messages read correctly. They reference real projects and real balances, because whoever is sending them has been reading the mailbox. Processing Content The instinct is to reset the password and turn on multifactor authentication. Both are right, but neither finishes the job. A password change closes one way in. Email account takeover, as it tends to play out in Microsoft 365 and other hosted mail, also leaves configuration behind: settings the intruders added while they had access, which keep working after the credential is gone. When those leftovers stay in place, a client can be declared secure on Tuesday and still be quietly leaking mail on Thursday. Start with sessions. Changing a password does not necessarily end sessions already established, because tokens issued earlier can remain usable until they expire or are explicitly revoked. Microsoft 365 treats this as a separate administrative action, usually surfaced as signing the user out everywhere or revoking sessions, and its exact behavior depends on the tenant's configuration and licensing. So whoever administers the tenant should confirm it there rather than assume it happened. Rules are next. An intruder who wants a fraudulent thread to keep running needs the real employee not to see the replies, and an inbox rule does that: Anything matching terms like invoice, wire or a vendor's domain gets filed into a folder nobody opens, or it's deleted. Some rules live on the server, where an administrator can see them; others are created in a desktop Outlook profile and are not, which is one reason a review should include the workstation and not only the cloud console. Forwarding and delegation also hide in more than one place. A mailbox can carry a forwarding address set by an administrator, a user can configure forwarding personally, and an organization-wide mail flow rule can copy messages outward. Mailbox permissions such as full access, Send As, and Send on Behalf Of let one account act as another, so cleaning the obvious mailbox while leaving a permission in place can let the fraud resume from a source nobody is watching. Labels differ, too: depending on the license and the admin center, the same setting can appear under another name, and other providers organize these controls differently again. One step is easy to overlook entirely: application consent. When a user, or an attacker acting as that user, grants a third-party application permission to read and send mail, that application holds access of its own. It is indifferent to the new password, and depending on how consent was granted, it may be unaffected by newly enabled multifactor authentication. Reviewing which applications hold mail permissions, and removing those nobody can account for, belongs on the same list as the reset. Someone must also answer a separate question: Who already received the fraudulent messages? In Microsoft 365, message trace can show what left the mailbox and where it went, within the retention window available to the tenant. That output is the outreach list. Anyone asked to change banking details should hear from a person by phone, at a number obtained independently of the suspect thread. If a payment has been initiated, the banks involved are the parties positioned to attempt a hold or recall, and they generally have more options the earlier they hear. Reporting to law enforcement, in the United States usually the FBI's Internet Crime Complaint Center, is the client's decision. The first hour, in rough order: Revoke sessions and tokens, not just the password; enroll or re-enroll multifactor authentication. Remove unexplained inbox rules, on the server and in desktop profiles. Check every forwarding path: mailbox, user-configured and mail flow rules. Review delegates, Send As and Send on Behalf Of, and recently created accounts. Revoke third-party application consents carrying mail permissions. Run message trace to list the messages and recipients. Call recipients at known-good numbers; call the bank first if money moved. Write down what changed, by whom and when. None of this makes the CPA the incident responder, and saying so plainly is part of the service. What the accountant owns is the payment workflow: which approvals were bypassed, which vendor master records may have been altered, whether new remittance details were accepted and acted on, and what this week's disbursement calendar looks like. That knowledge turns a technical cleanup into a business recovery, and it is often why the accountant ends up convening the client's administrator, the bank and whoever else belongs on the call. Just be careful with certainty. "We got them out" is a sentence nobody should say on day one, because persistence can sit where a fast triage pass does not reach. The defensible posture is that these steps close the doors you can see, that a qualified security professional should look for the ones you cannot, and that the client's counsel and insurer, rather than the accountant, should advise on notification and reporting obligations. What remains is ordinary controls discipline. Bank detail changes get verified out of band against a contact the client already had. Payment approvals require a second person. Recipients who were misled once get a heads-up before the next invoice cycle, because the damaged trust was the client's, and rebuilding it is a business task, not a technical one. Handled that way, an ugly week ends with a client whose controls are better than before, and an accountant who was useful in the part of the emergency that was genuinely theirs.