Latest / Breach Signals / The Invoice That Changed One Digit
Transcript
- The supplier is real. The invoice is expected. The six-week email thread is genuine. Only one digit in the bank account has changed. That single digit is the entire attack. How do you verify a payment change when the criminal may be reading every reply? This is Breach Signals from Scan.now. By the end of this episode, you will know why a familiar conversation can be more dangerous than an obvious fake, how payment diversion borrows real context, and which independent check can stop the transfer before trust becomes a loss. A typical attack begins before the invoice changes. Access to one mailbox can reveal signatures, customer names, previous invoices, travel plans and approval habits. The attacker may create forwarding rules, hide replies or monitor a thread until the right moment. In some cases they send from the compromised account. In others they register a lookalike domain and copy the display name, hoping the familiar thread and wording carry the deception. The payment instruction is the monetization step, not the entire attack. A changed account number, urgent settlement, confidential acquisition or request to bypass a colleague can all move money. Criminals may time the message near a real deadline and may answer questions convincingly because they can see earlier correspondence. That is why grammar, logos and conversational detail are weak defenses in this case. The strongest misleading signal is the thread itself. People assume that replying inside an existing conversation proves continuity of identity. Email threading is a presentation choice based on headers and subject lines. A compromised mailbox can participate legitimately from the mail system's perspective, while a spoofed or lookalike message may be grouped with related mail. Even a valid DKIM signature only identifies the signing domain, not the rightful human at the keyboard. Attackers may strengthen the illusion by deleting their own sent messages and moving warnings out of view. A mailbox rule can forward copies to an external address or hide replies from the real supplier. That makes account recovery more than a password change. Administrators need to inspect rules, delegated access, registered applications, recovery methods and active sessions, then determine how the initial access occurred. The real supplier may also be the compromised party, so your own inbox can be perfectly healthy while the fraud arrives from a genuine address. Controls must therefore focus on the payment change rather than on proving whose technical environment failed. If the destination changed, independent verification applies every time. That rule works even when both organizations have excellent email authentication. Another trap is verifying by replying. If the attacker controls the mailbox or Reply-To path, the question goes back to the person creating the fraud. Asking, are these new bank details correct, may produce a perfectly reassuring yes. A control is independent only when it uses information the attacker did not supply and a channel they do not control. Create a rule that any new or changed payment destination requires verification. Call a known contact using a number already held in your supplier record, not a number in the change request. For higher-value transfers, require a second person to compare the beneficiary name, account details and evidence. Record the confirmation in the accounting system so a later email cannot quietly reverse it. If money has already moved, contact the sending bank immediately and ask about recall or fraud procedures. Speed matters, but preserve the messages and headers before deleting anything. Notify the real supplier through a trusted route, secure affected email accounts, revoke sessions and inspect forwarding rules. Report the incident through the appropriate national fraud or law-enforcement channel. Do not continue negotiating inside the suspect thread. Prevention also requires clear records. Keep approved supplier details in a controlled system rather than treating the latest email as the master record. Limit who can edit those details, notify another person when they change and review dormant suppliers before reactivation. Separate the person who creates a payment from the person who releases it when staffing permits. Small teams can still create independence without expensive software. Clear responsibility matters more than elaborate tooling. One person can enter the invoice and a second can make the verification call. A written checklist can require the caller to record the known number used, the person reached and the time. The aim is not bureaucracy. It is to ensure that one compromised inbox cannot become both the request and the proof. Rehearse the process with suppliers so a real change does not arrive as a surprise under deadline pressure. The Scan.now Email Header Analyzer can help compare From, Reply-To, Return-Path, delivery hops and authentication results in a suspicious invoice message. The Phishing URL Checker can inspect any sign-in or document link used in the approach. Paste only the technical material you need and protect personal or commercial details. These tools cannot tell whether a real employee authorized a bank change, whether a mailbox owner is acting freely or whether a phone call reached the right person. They are evidence tools, not payment approval. The control that stops this loss is a business process: changed destination, separate verification, two-person review. Links to the analyzer and checker are included in this episode's description at scan dot now slash podcast. The rule to remember is: trust the process for changing payment details, not the familiarity of the message carrying them. A routine invoice deserves the same independent check as an urgent one when the destination changes. The extra minute should feel normal, not accusatory. Build the rule before the next invoice arrives, give staff permission to pause and make suppliers expect the confirmation call. Next time on Breach Signals, the caller will know your name, account type and recent support problem. We will examine why accurate personal details create confidence without proving identity, and how to restart a support conversation on your own terms.