Part 1 · assessment and mitigation recommendations · published v1.0 · 14 October 2026
The invoice is plausible. The bank account is wrong.
SC03 · Construction · suppliers · finance teams · SMEs
What really happened
Ubiquiti reported that employee impersonation and fraudulent requests to its finance department led to $46.7 million in transfers in June 2015. Its later filing also records recoveries; the transfer amount is not the final net loss.
Ubiquiti · March 2022 financial filing, describing the 2015 fraud
Evidence limit: This is a documented finance-process fraud example. It does not establish that the victim’s mailbox was technically compromised or that the proposed tools below were used.
The question for the client
Would our payment process stop a convincing but unverified supplier or executive instruction?
Business impact: Direct cash loss, delayed legitimate supplier payments, disputes and business interruption.
- Systems involved
- Mailboxes, supplier registers, invoice approval, payment authorisation and the independent callback channel.
- Where people fit
- Accounts-payable staff, executives, supplier relationship owners and approvers face time pressure and apparent authority.
How a similar risk could develop here
Proposed client threat model, not a reconstruction of undocumented incident details.
Learn a believable transaction context → impersonate a supplier or executive → request a change or urgent transfer → exploit weak independent verification → payment reaches an unauthorised destination.
Each route depends on several controls. If one stage is blocked, later checks can only continue as a separately authorised, clearly labelled assumed-compromise test. Do not claim an end-to-end attack succeeded merely because a downstream test identity was supplied.
Referenced attack-vector guides
Approval is specific, never inherited from the guide. Check the client, campaign, individual person/asset, method, channel, time window and risk ceiling. Deny overrides allow; absent, expired or withdrawn permission blocks the action. LOW/MED/HIGH describe proposed test impact, not permission or finding severity.
Read the approval rules.
Assessment playbook · Part 1
Start with G01 scope and Target Management, G02 intelligence gathering where needed, and G03 tool/resource preflight. Each selected vector receives its own scoped invocation record.
SC03-S01LOW · proposed test impact1. Walk the approval process
Trace a fictional invoice and bank-change request through normal decisions.
- Why this is needed
- It tests a barrier in the route above and helps answer: Would our payment process stop a convincing but unverified supplier or executive instruction?
- Vector / method
- Tools and guides
- Target Management / CRM · native service; handoff is not automatic execution
- Finance approval records · client/operator supplied
- Repository input
- invoice-scenario.txt · RES-017 · published assessment resource; pin its version/hash in the case record.
- Output
- Process map and control gaps; attach evidence, target ID, vector version and approval revision.
- Measure
- Decision points with independent verification / required points. Agree the acceptance threshold before testing; state raw counts, denominator, conditions and limitations. Compare prohibited cases with a permitted/clean control.
- Current result
- NOT ASSESSED. This is a prepared playbook; no client test or finding is being invented.
- Recommendation on failure
- Define independent verification and separation of duties for the actual payment/change decision. Define an observable acceptance criterion for a later retest. No implementation work is allocated now.
SC03-S02HIGH · proposed test impact2. Approved finance role-play
Use a reviewed fictional request for permitted participants only; never provide a real payment destination or execute a transfer.
- Why this is needed
- It tests a barrier in the route above and helps answer: Would our payment process stop a convincing but unverified supplier or executive instruction?
- Vector / method
- Tools and guides
- Agent001 · native service; handoff is not automatic execution
- VoiceOps · native service; handoff is not automatic execution
- Repository input
- invoice-scenario.txt · RES-017 · published assessment resource; pin its version/hash in the case record.
- Output
- Decision and verification evidence; attach evidence, target ID, vector version and approval revision.
- Measure
- Unverified changes stopped / executed approved scenarios. Agree the acceptance threshold before testing; state raw counts, denominator, conditions and limitations. Compare prohibited cases with a permitted/clean control.
- Current result
- NOT ASSESSED. This is a prepared playbook; no client test or finding is being invented.
- Recommendation on failure
- Improve trusted-channel callback and escalation when the request is urgent or unusual. Define an observable acceptance criterion for a later retest. No implementation work is allocated now.
SC03-S03LOW · proposed test impact3. Response tabletop
Review the route for reporting, escalation and attempted payment recall using synthetic facts.
- Why this is needed
- It tests a barrier in the route above and helps answer: Would our payment process stop a convincing but unverified supplier or executive instruction?
- Vector / method
- Tools and guides
- Finance incident controller · client/operator supplied
- Repository input
- incident-injects.csv · RES-018 · published assessment resource; pin its version/hash in the case record.
- Output
- Response gap report; attach evidence, target ID, vector version and approval revision.
- Measure
- Required decisions with reachable responsible role / required decisions. Agree the acceptance threshold before testing; state raw counts, denominator, conditions and limitations. Compare prohibited cases with a permitted/clean control.
- Current result
- NOT ASSESSED. This is a prepared playbook; no client test or finding is being invented.
- Recommendation on failure
- Clarify the reporting and recall route, decision authority and required evidence; do not imply funds will always be recovered. Define an observable acceptance criterion for a later retest. No implementation work is allocated now.
Use one step-result record per case and G06 reporting for the client deliverable. The report must explain successes, failures, uncertainty, prohibitions and coverage limits.
Recommendations to reduce the risk
Reduce the likelihood: Verify changes through trusted contact information independent of the request, separate approval duties and protect finance identities.
Reduce the impact if it happens: Use sensible payment controls and a rehearsed escalation/recall process. No recovery guarantee is implied.
How to verify improvement later: repeat the failed control case and a permitted/clean comparison using the same agreed measure; compare conditions and evidence. A better test pass rate alone is not a quantified reduction in business risk.
End of Part 1: evidence-backed findings and mitigation recommendations. The implementation action plan, allocated work, commercial service packaging and costs are deliberately deferred.
Supporting TenguProtect capabilities
Baseline from the 13 October operational audit. This does not claim the complete service is ready or that permissions are already enforced across every agent.
| Capability | Observed readiness | Remaining gap |
|---|
| Business email compromise and payment fraud | Partial; approved manual exercise available after scope | Verify email delivery and outcome collection; map finance approval evidence. Native draft success is not proof the finance workflow was exercised. |
| Security governance, suppliers and staff lifecycle | Content and advisory components; repeatable delivery unproven | Define the exact advisory scope, evidence requests, reviewer competence and report. Do not imply accreditation or legal compliance from a checklist. |