StealthTech
A controller at a machine shop outside Tampa gets an email from her CFO asking her to expedite a wire to a “new” supplier account before the end of the day. The signature block is right. The tone matches how the CFO actually writes. The only thing wrong with the email is that the CFO never sent it and by the time anyone picks up a phone to confirm, the money has already cleared through two intermediary accounts and is gone. That scenario, or some close variant of it, is how most business email compromise losses actually happen. Not through malware, not through a dramatic breach headline, but through a single convincing message that exploits trust between people who already work together.
Business email compromise, or BEC, has quietly become the most financially damaging category of cybercrime that defense contractors and other small-to-midsize businesses face more costly in aggregate than ransomware, because it doesn’t need to encrypt anything to succeed. It just needs one person to believe the email is real. For contractors handling Controlled Unclassified Information and answering to DFARS and CMMC obligations, a successful BEC incident carries a second layer of exposure beyond the wire fraud itself: it can expose the very email environment that stores program-related communications, subcontractor data, and financial records tied to government work.
How BEC Actually Works Inside a Company That Thinks It’s Careful
Most BEC attacks start with reconnaissance, not exploitation. An attacker will spend days or weeks quietly reading through a compromised mailbox often obtained through a prior phishing campaign or a credential reused from an unrelated breach learning who approves payments, how invoices are typically worded, and when the CFO tends to be traveling or otherwise hard to reach by phone. Only after that groundwork is done does the attacker either hijack an existing email thread or spin up a lookalike domain and send the payment request.
This is why BEC so often defeats spam filters and antivirus tools. There’s no malicious attachment, no suspicious link, no payload to detect. The email is text, sent from an account that may be technically legitimate, referencing real vendor names and real project numbers pulled straight from the mailbox the attacker already controls. Standard managed IT services that focus on patching and endpoint protection will not catch this pattern, because nothing about it looks like malware. It looks like business as usual, which is exactly the point.
There’s also a slower variant worth naming directly: vendor email compromise, where the attacker doesn’t touch your mailbox at all but instead compromises one of your actual suppliers and waits for a real invoice cycle to send a “corrected” banking detail from an account you’ve legitimately corresponded with for years. This version is harder to catch because every technical signal on your side sender domain, thread history, even SPF and DKIM checks out. The only thing that catches it is a verification habit that doesn’t trust email content regardless of how legitimate the sending account appears.
A third variant worth flagging separately targets payroll rather than accounts payable. An employee-impersonation email requesting a direct-deposit change, sent to HR from what looks like a personal account matching the employee’s real name, is a lower-dollar but higher-frequency version of the same trick and because the amounts are smaller, it often skips the scrutiny a six-figure wire request would trigger. Contractors who lock down wire approval but leave payroll changes to a single email confirmation are still exposed, just at a smaller and more frequent scale.
Why Defense Contractors Are a Disproportionate Target
Contractors working under DFARS 252.204-7012 and pursuing CMMC certification sit on two things attackers want: recurring six- and seven-figure invoice cycles with prime contractors, and email systems that route CUI-adjacent program correspondence. A finance team juggling multiple prime relationships, each with its own invoicing cadence and point of contact, has more surface area for a fraudulent “updated banking details” email to blend in unnoticed. The DFARS 252.204-7012 clause already obligates contractors to report cyber incidents affecting covered defense information within 72 hours, and a BEC compromise that touches a mailbox handling program data can trigger that reporting requirement even when the financial loss itself is the more visible damage.
Subcontractors and smaller primes are particularly exposed because they often lack a dedicated security team watching mail flow rules, forwarding rules, and login geography in real time. That gap is precisely where a co-managed IT arrangement earns its keep giving an internal IT person or small team the monitoring depth of a larger security operation without requiring the contractor to staff it alone.
The pattern doesn’t change much by geography, but the client base does. In our Boston client base, we tend to see BEC attempts targeting subcontractor payment cycles tied to larger prime relationships in the defense corridor. In Tampa and Sarasota, we more often see it aimed at manufacturing and machine shop clients where a single controller manages both payroll and vendor payments with limited segregation of duties. Contractors in our Boston, Tampa, and Sarasota markets working in manufacturing or engineering tend to share the same underlying gap: strong technical controls on the shop floor, and comparatively weak verification discipline in the front office where the money actually moves.
The Technical Signals That Catch BEC Before the Wire Goes Out
Detection has to happen at three layers, because BEC rarely announces itself at just one. The first layer is authentication DMARC, DKIM, and SPF enforcement that stops spoofed versions of your own domain from reaching recipients, paired with impossible-travel and new-device login alerts that flag when a mailbox is accessed from a country or IP range it has never touched before. The second layer is mail-flow behavior: inbox rules that silently forward or delete messages, a classic technique attackers use to hide their tracks after gaining access, should trigger an alert the moment they’re created rather than being discovered during a post-incident review. The third layer is content-based anomaly detection, which flags financial keywords “wire,” “ACH,” “updated banking,” “urgent payment” combined with external sender indicators or recently registered lookalike domains.
None of this is exotic technology. It’s the difference between a mail platform configured for default settings and one tuned specifically around fraud patterns, which is the core of what cybersecurity services should mean for a contractor rather than a generic antivirus bundle. Contractors evaluating their current posture against these three layers often find gaps not because the tools are absent but because nobody owns the alerts those tools generate. A SIEM or mail security platform generating hundreds of low-priority alerts a week, with nobody assigned to triage them, provides no more protection than having no alerting at all arguably less, because it creates a false sense that someone is watching.
Domain monitoring belongs in this same layer and is frequently skipped. Lookalike domains a swapped character, an added hyphen, a different top-level domain are cheap for an attacker to register and are usually the launch point for the more convincing thread-hijacking attempts described above. Monitoring for newly registered domains that closely resemble your own, and for domains resembling your most frequent vendors and primes, gives you a warning window before the first fraudulent email even goes out, rather than a reactive scramble after someone has already replied to it.
Multi-Factor Authentication Is Necessary but No Longer Sufficient
Every BEC prevention conversation eventually arrives at MFA, and for good reason credential theft remains the most common entry point into the mailbox an attacker eventually weaponizes. But MFA alone has developed its own blind spot. Push-based MFA fatigue attacks, where an attacker floods a user’s phone with approval requests until one gets accidentally tapped, have become common enough that we wrote a full breakdown of how they work and how to stop them in our piece on MFA fatigue attacks. The practical fix is number-matching MFA or, better yet, phishing-resistant hardware keys and passkeys, which we cover in more depth in Passkeys vs. Passwords for Business.
A contractor still relying on SMS codes or simple push approval for finance-team accounts is leaving the exact door open that most BEC intrusions walk through, and this is worth prioritizing specifically for the handful of mailboxes accounts payable, payroll, executive assistants that have the authority to move money or approve vendor changes. Blanket MFA rollouts often deprioritize exactly these accounts because they belong to less technical users who generate more support tickets, which inverts the actual risk profile of the organization.
Verifying Payment Changes Without Slowing Down the Business
The single highest-leverage control against BEC isn’t technical at all it’s a callback verification step for any change to banking details or any payment request above a defined threshold, made to a phone number pulled from an existing vendor file rather than one supplied in the suspicious email itself. Most finance teams already sense this intuitively but don’t have it written down as a required step, which means it gets skipped exactly when someone is busy or the request looks urgent which is, again, the point of the attack.
A workable verification framework generally includes:
- A callback to a known, previously verified phone number never a number listed in the email requesting the change
- A mandatory hold period, even brief, on any first-time payment to a new account regardless of who appears to have approved it
- Dual approval for wire transfers above a set dollar threshold, with the second approver working from a separate communication channel than the original request
- A standing rule that banking-detail changes are never actioned from email alone, full stop
This isn’t bureaucracy for its own sake. It’s the equivalent of a two-person integrity check applied to money movement, and it’s one of the few controls that works regardless of how convincing the email itself becomes including against the AI-generated voice and video impersonation attacks we detail in AI Deepfake Scams Targeting Businesses, where a “confirmation call” from what sounds exactly like your CFO is itself the fraud. A finance team that has moved to cloud-based VoIP gains centralized call logging and caller ID verification that traditional phone lines don’t offer, which matters directly here: if your voice infrastructure can’t confirm who actually placed a call, the callback control has a weak link built into it from the start.
Where Shadow IT, SaaS Sprawl, and Unmanaged AI Tools Widen the Attack Surface
BEC doesn’t only travel through Outlook or Gmail. Once a finance or program team starts using a scattered mix of unsanctioned collaboration tools, shared drives, and AI assistants to move faster, an attacker who compromises one login often finds a path into several others through password reuse or OAuth token abuse. We’ve written specifically about how this pattern develops in SaaS Sprawl Security and in Shadow AI Security, and the overlap with BEC is direct: every additional unmanaged app is another place an attacker can plant a forwarding rule or harvest a session token without your monitoring tools ever seeing it happen.
The same logic applies to internal AI adoption. AI integration done well accelerates fraud detection flagging the combination of a new login location, a newly created mail rule, and a financial keyword in the same 24-hour window faster than a human analyst reviewing logs manually ever could. Done poorly, or bolted on without proper access controls and without a governing usage policy, it just becomes another system an attacker can pivot through. Reducing this sprawl, or at minimum inventorying it, closes off lateral movement paths that turn a single compromised mailbox into a company-wide incident.
The Compliance Dimension: CMMC, CUI, and Incident Reporting Obligations
For contractors, a BEC event isn’t purely a finance problem it’s a compliance event the moment the compromised mailbox has touched anything resembling Controlled Unclassified Information. NIST SP 800-171 requires access control, audit logging, and incident response practices that directly map to the detection layers described above, and an assessor evaluating your environment under the CMMC framework will expect to see documented evidence that email-based fraud attempts are logged, investigated, and reportable not just blocked and forgotten. Even contractors not yet handling CUI still fall under FAR 52.204-21, which sets a baseline safeguarding standard that email account protection and access control clearly fall within.
This is where compliance work and cybersecurity operations stop being separate line items on an invoice and start functioning as the same program. A contractor who treats BEC detection purely as an IT nuisance, rather than as part of the audit trail an assessor will eventually ask about, tends to discover the gap during a CMMC assessment rather than before one. That gap tends to surface fastest in industries with thin back-office staffing finance and legal firms supporting contractor work included where the same one or two people who process payments are also expected to be the ones catching fraud attempts in real time, with no dedicated compliance function checking their work.
Documentation matters as much as the control itself here. An assessor doesn’t just want to know that MFA is enabled or that mail-flow alerting exists they want to see the policy that requires it, the log showing it fired correctly during a real or simulated event, and the record of who reviewed that alert and what they did about it. A contractor with strong technical controls but no paper trail behind them is in a weaker position during an assessment than one with slightly less sophisticated tooling but a documented, repeatable process wrapped around it.
Building an Incident Response Path Before You Need It
The financial and reputational damage from a BEC event is almost always worse when the response is improvised in the moment. A functional plan defines who has authority to freeze or reverse a wire with the bank, who contacts the FBI’s Internet Crime Complaint Center, and who determines whether the incident meets the DFARS 72-hour reporting threshold decisions that should never be made for the first time under pressure. At minimum, that plan should cover:
- Immediate password reset and session revocation for any account showing suspicious mail rules or login activity
- A same-day call to the receiving and sending banks, since wire recalls have a narrow window of viability measured in hours, not days
- Forensic preservation of the mailbox and its audit logs before remediation wipes the evidence an investigator or assessor will later need
- Internal notification to program managers if any CUI-adjacent communication passed through the compromised account
Contractors without the internal bandwidth to build and rehearse this kind of plan often lean on vCIO services to get an outside set of eyes on the plan’s gaps before an actual incident tests it for the first time. If a fraudulent transfer does clear, the same operational discipline that protects against ransomware verified, tested, and ideally immutable backup and data recovery ensures the incident doesn’t compound into a second crisis where financial records or program data are also unrecoverable. We cover why immutability specifically matters, beyond just having a backup that “runs,” in Immutable Backups Explained.
Continuous Monitoring: Why a SOC Changes the Detection Timeline
The difference between catching a BEC attempt in progress and discovering it after the money has moved usually comes down to how quickly someone is watching the right signal. A security operations center that ingests mail-flow logs, authentication events, and financial-keyword alerts around the clock rather than a monthly report someone skims is what actually closes the detection gap. We go into more detail on how AI-assisted SOC operations are changing that response timeline in What Is an AI SOC?, and the underlying principle connects directly to the Zero Trust vs. Traditional Network Security model: assume every login, every forwarding rule, and every payment request needs to prove itself, rather than assuming legitimacy because it originated inside the perimeter.
For a contractor evaluating whether to build this monitoring function internally or bring in outside help, the honest calculus usually comes down to headcount. A 24/7 watch requires either a rotating internal team most 40- and 60-person contractors can’t justify, or a partner already running that rotation across multiple clients. The CyberAB Marketplace is a useful starting point for identifying registered provider organizations that already understand the CMMC context this monitoring needs to satisfy, rather than a generic help desk vendor bolting on a security add-on.
Conclusion
Business email compromise doesn’t require a sophisticated exploit or a novel piece of malware it requires one convincing email and one person under time pressure. Stopping it means layering authentication controls, mail-flow monitoring, and a verification process for payment changes that doesn’t depend on anyone’s judgment in the moment, while making sure the compliance trail behind those controls holds up if a CMMC assessor or a DFARS incident report ever asks for it. Contractors who treat this as a standing operational discipline, rather than a one-time email security purchase, are the ones who catch the fraudulent wire request before it clears rather than after.
If your organization is planning its CMMC compliance journey, contact Stealth Technology Group today at (617) 903-5559 or visit the website to learn how modern cybersecurity infrastructure can accelerate your path toward certification readiness.
