Part 1 · assessment and mitigation recommendations · published v1.0 · 14 October 2026

A convincing support request opens the customer database

SC02 · Professional services · recruitment · hospitality · membership businesses

Real incident Client risk Possible routes Assessment Recommendations

What really happened

Caesars disclosed in September 2023 that social engineering against an outsourced IT support vendor preceded an unauthorised actor obtaining a copy of its loyalty-program database, including sensitive identity information for many members.

Caesars · SEC disclosure

Evidence limit: The company disclosure supports the vendor-social-engineering and database-loss connection. It does not prove every phone script, tool or intermediate step proposed below.

The question for the client

Can an impostor turn contact with our staff or support provider into access to customer records?

Business impact: Customer information could be disclosed or misused, with trust, contracts and potential legal consequences affected. A message click does not prove account takeover, database export or total system loss.

Systems involved: Public business information, email/SMS/telephone channels, helpdesk recovery, identity provider, CRM permissions, exports and audit logs.
Where people fit: Staff may receive the request; helpdesk staff may approve recovery; administrators define permissions. Their verification process and technical backstops matter as much as individual awareness.

How a similar risk could develop here

Proposed client threat model, not a reconstruction of undocumented incident details.

Gather business context → impersonate a trusted contact → seek an identity or recovery change → use the resulting access → reach CRM records or exports → evade or outlast response.

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.

SC02-S01LOW · proposed test impact

1. Approved public context

Use G02 on the client’s approved business sources, corroborating identities and excluding unrelated family data.

Why this is needed

It tests a barrier in the route above and helps answer: Can an impostor turn contact with our staff or support provider into access to customer records?

Vector / method

V01 · Social engineering and trusted-person impersonation

Tools and guides

Repository input

intel-register.csv · RES-010 · published assessment resource; pin its version/hash in the case record.

Output

Source and scope register; attach evidence, target ID, vector version and approval revision.

Measure

Corroborated observations / reviewed observations. 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

Reduce unnecessary public business detail and resolve unverified assumptions before designing any permitted simulation. Define an observable acceptance criterion for a later retest. No implementation work is allocated now.

SC02-S02HIGH · proposed test impact

2. Per-person contact simulation

Use V01/V02 only for named permitted people and channels, with token-only measurement; denied people are excluded and recorded.

Why this is needed

It tests a barrier in the route above and helps answer: Can an impostor turn contact with our staff or support provider into access to customer records?

Vector / method

Tools and guides

Agent001 · native service; handoff is not automatic execution
VoiceOps · native service; handoff is not automatic execution

Repository input

simulation-script.txt · RES-008 · published assessment resource; pin its version/hash in the case record.

Output

Channel receipts and behaviour measures; attach evidence, target ID, vector version and approval revision.

Measure

Verification/reporting events / confirmed delivered approved simulations. 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 the failed verification/reporting process and protective message controls; measure technical barriers separately. Define an observable acceptance criterion for a later retest. No implementation work is allocated now.

SC02-S03MED · proposed test impact

3. Identity-to-data barrier checks

Use test identities and synthetic CRM records to test MFA/recovery, roles and export controls. Mark assumed-compromise stages explicitly.

Why this is needed

It tests a barrier in the route above and helps answer: Can an impostor turn contact with our staff or support provider into access to customer records?

Vector / method

Tools and guides

burpsuite · Armory · Existing local tool notes · Maintained official user guide
OWASP ZAP (Web App Scanner) · Armory · Existing local tool notes · Maintained official user guide
Target Management / CRM · native service; handoff is not automatic execution

Repository input

synthetic-customers.csv · RES-007 · published assessment resource; pin its version/hash in the case record.

Output

Separate identity, record-access, export and detection findings; attach evidence, target ID, vector version and approval revision.

Measure

Prohibited actions denied / executed cases; alert delivery and response times. 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

Strengthen the particular recovery/MFA, role, export or alert barrier that failed; do not treat one employee interaction as proof of all failures. 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: Strengthen support verification, phishing-resistant MFA and recovery; reduce unnecessary public detail and risky message paths.

Reduce the impact if it happens: Restrict CRM permissions and exports, improve anomaly detection and practise rapid session revocation. Keep useful reporting easy for staff.

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
Customer database protection · social engineering	Planning available; channel delivery and evidence return incomplete	Agent001 has log-only/manual tasks recorded as complete. Correct those states before relying on automation. VoiceOps needs a configured calling provider, verified caller identity, budget and owned-number test. Prove approved email/SMS delivery and reporting separately.
Identity, passwords, MFA and recovery	Partial; client identity fixture required	Create representative test identities, agreed lockout limits and recovery fixtures. Prove checks in the actual client identity platform; installed tools and AI inference do not establish this.
External exposure, public intelligence and brand risk	Partial; sources and output review need validation	Verify the selected passive collectors on an owned fixture, confirm optional provider quotas, and establish source attribution and review.