Trust as an Attack Surface: Consultancy Scams, Fake Recruiters, and CTEM

TL;DR

Cisco Talos recently documented a $300 "consultancy" offer that was really a screening interview: the attacker wanted to learn whether a security practitioner had the access, relationships, and non-public knowledge worth exploiting later. Fake recruiter schemes, trojanized "skills assessments," and North Korean IT-worker placements are variants of the same play — buy trust instead of breaking in. That makes human trust an attack surface, and it belongs in your Continuous Threat Exposure Management (CTEM) program alongside domains, IPs, and APIs. Trusteed CTEM gives teams one place to inventory what trusted people and partners can reach, correlate those assets with exploitability context, and gate what actually reaches the SOC queue.

What is trust as an attack surface?

Trust as an attack surface is the sum of relationships, delegated access, credentials, and non-public knowledge that let a person — employee, contractor, consultant, recruiter-supplied hire, MSSP analyst, or partner — do things an outsider cannot. It is not a metaphor. It is an enumerable set of access paths:

• People and identities: full-time staff, contractors, offshore delivery teams, fractional CISOs, consultants with standing VPN or SSO access.
• Delegated permissions: OAuth consent grants, cloud IAM roles, CI/CD tokens, shared secrets in password managers, break-glass accounts.
• Non-public knowledge: network topology, unreleased roadmap, unpatched internal findings, customer lists, incident timelines.
• Personal-side exposure: personal GitHub accounts, home lab gear, personal email used for 1099 invoices, identity documents shared with "recruiters."

An attacker who buys trust gets access without needing a CVE. But the result of that access usually shows up as technical exposure: a new OAuth grant nobody reviewed, a dev or admin panel reachable from the internet, an API key committed to a public repo, or unpatched software installed by a new hire's onboarding laptop. That is why CTEM programs should treat trust-layer risk as an input to exposure discovery, prioritization, validation, and remediation — not as a separate awareness-training project that ends with a slide deck.

Why it matters now

Three shifts have made trust attacks the cheapest path into well-defended organizations.

1. The price of a human is falling, not rising. A $300 consultation is deliberately calibrated: low enough to be plausible, high enough to be tempting, and trivial against the value of a single set of cloud credentials. Fake recruiters offering prestigious roles ask candidates to install "assessment software" that arrives trojanized — the same pattern seen in campaigns abusing fake password-manager installers hosted on public code platforms. The lure is brand spoofing, not a compromised vendor.

2. Nation-state programs industrialize it. Law enforcement and intelligence agencies from Japan, the United States, Australia, and Germany have publicly attributed long-running hiring schemes to a North Korean group tracked as WaterPlum (also known as Contagious Interview), including the first known laptop farm dismantled in Japan. Laptop farms put genuine-looking employees on corporate networks and payroll, with all the legitimate access that implies.

3. AI is compressing the cost of pretexting and expanding the payload side. Research tooling such as Talos's CAIRN already hunts AI-integrated malware by extracting prompt templates, API keys, and jailbreak terms from artifacts — evidence that adversaries are operationalizing LLM tradecraft faster than defenders are instrumenting for it. Meanwhile, AI agents have demonstrated their own breakout capability, including guessing passwords to reach a protected system.

For security leaders, the compliance angle adds urgency: SOC 2, ISO 27001, and sector regulators all ask how you manage vendor and third-party access and how you continuously monitor risk. "We do annual access reviews" is no longer a satisfying answer when the access was granted on a Tuesday and abused by Thursday.

How attacks / risks work

Most trust attacks follow a five-stage funnel. Mapping each stage to the technical artifact it leaves behind is what converts a human story into an engineering problem.

1. Pretext. A sparse social profile, an employer with no footprint and one employee, an offer that is slightly too generous for an initial call. The attacker is not yet attacking — they are qualifying.
2. Screening. A short call or chat to determine access level, tooling familiarity, and how much the target knows about internal systems. Flattery is the payload.
3. Escalation. A commissioned report, then a "special report" requiring data that is not public. To deliver, the target must ask colleagues, probe internal systems, or lean on professional relationships — the attacker outsources the reconnaissance.
4. Collection. Credentials, source code, internal documentation, network diagrams, customer data, or a foothold on a laptop inside the corporate network. This is the stage where CTEM telemetry can catch what awareness training cannot.
5. Persistence and reuse. New OAuth grants, added MFA devices, standing access for the "vendor," or malware that survives the engagement's end date.

Variants to expect: the trojanized job assessment, the fake recruiter on a legitimate-looking domain, the "integration partner" who requests read access to production for a proof of concept, the vendor account that never got deprovisioned after the contract ended, and the external consultant whose report for one client describes another client's architecture.

The important nuance for defenders: most of these attempts fail, and they fail loudly. A rough perimeter of lookalike domains, unsolicited outreach, and applicant-submitted files will generate far more noise than confirmed incidents. Prioritization is the product — not more alerts.

Detection and visibility

What does good telemetry look like when the adversary is a trusted human?

• Identity events as exposure events. New OAuth consent grants, newly created service accounts, MFA method changes, role assignments, and contractor sessions outside the engagement window. These are exposure changes, not just audit-log entries.
• External attack surface deltas. Newly exposed services, jump hosts, admin panels, and VPN or remote-access endpoints — exactly the assets a trust attacker maps first. Ongoing, differential discovery beats annual scans, because the surface changes with every deployment and every contractor onboarded.
• Secrets and code exposure. Public repositories containing API keys, CI/CD tokens, or internal endpoints. This is the most common way a consulting engagement turns into a credential leak.
• Domain, DNS, and mail posture. Spoofable sending domains, missing DMARC enforcement, and lookalike domains registered against your brand. If a fake consultancy is emailing your staff from a near-miss domain, you want to know before someone replies.
• Vulnerability and exploitability context. When a new hire installs tooling during onboarding, or a partner exposes a service you did not know existed, the question is not "is there a CVE?" but "is this being exploited in the wild?" EPSS, KEV status, and exploit references turn a finding into a decision.
• A validation gate. Scanner output is a signal. Without validation — exploitability plus business context — every finding becomes an alarm, and analysts learn to ignore the queue. This is the single biggest difference between a scanner subscription and a CTEM program.

What good looks like in practice: an accountable owner per asset, a normalized finding record that carries exploitability context, a queue where a dashboard entry only appears when there is a real reason to page a human, and a report an auditor can read.

Reduce risk / best practices

1. Inventory trust, not just hardware. Maintain a live list of who and what can reach what: contractors, MSSPs, managed service accounts, OAuth apps, and the engagements that justify them.
2. Time-box and scope third-party access. Give consultants an expiry date, a named sponsor, and least privilege. Review standing access to production separately from read-only findings access.
3. Make external attack surface discovery continuous. Weekly or daily differential discovery of domains, IPs, services, and technologies — with alerting on new exposure, not a PDF at quarter end.
4. Validate before you alarm. Apply an exploitability and business-context gate so partner infrastructure and dev sandboxes do not drown the SOC in scanner noise.
5. Monitor the code and secret boundary continuously. Public repos, package manifests, and CI tokens are the fastest exit path for a trusted insider who means well but is being manipulated.
6. Harden the human funnel with policy, not vibes. Require legal and security review before accepting unsolicited consulting work, prohibit installing third-party tools on corporate assets during interviews or onboarding, interview on corporate-controlled machines, and verify recruiters through known channels.
7. Track applicant and vendor infrastructure. Lookalike domains, freshly registered domains, and IP reputation on unsolicited outreach domains are cheap, high-signal indicators.
8. Keep vulnerability context current. If anything a new hire or partner installs has known exploited vulnerabilities, you want that flagged on day one, not at the next annual assessment.
9. Give people an amnesty reporting path. Trust attacks work because targets are embarrassed. A no-blame report channel converts a quiet compromise into a 30-minute incident.
10. Measure outcomes, not activity. Report exposures opened and closed, mean time to remediate by severity and exploitability, percentage of findings validated versus raw, and coverage of known-external assets. Those are the numbers that survive an audit and a board meeting.

How Trusteed CTEM helps

• Attack surface and asset inventory. Trusteed CTEM discovers domains, IPs, services, and technologies through passive and active discovery, with ongoing scan plans — so the assets a fake consultant or new hire would target are known, owned, and tracked rather than discovered during an incident.
• Structured, multi-layer scanning. Network, web, API surface, SSL/TLS, and mail/DNS posture checks run continuously, which surfaces exposed remote access, misconfigured admin panels, and spoofable domains that trusted insiders can reach from anywhere.
• Exploitability-aware prioritization. Findings are enriched with catalog CVE data, EPSS and KEV context, and exploit references where available — so a KEV-listed flaw on an internet-facing service outranks a theoretical misconfiguration on an internal dev host.
• A validation and SOC gate. Trusteed validates exploitability and business context so not every scanner hit becomes an alarm. Dashboards and analyst queues focus on actionable risk (should_alarm), which is what keeps a trust-layer investigation from being buried in noise.
• API and deep DAST coverage. A dedicated API surface worker and a deeper DAST worker for critical applications cover the integration and proof-of-concept exposure that consulting engagements tend to introduce.
• Compliance and reporting views. Framework-oriented reporting gives you defensible answers to vendor access, continuous monitoring, and remediation-evidence questions from auditors and customers.
• Vulnerability intelligence. Trusteed's public and in-product intel on KEV and emergent threats keeps prioritization current between scans. Operators work in the tenant app at app.trusteed.io; product and research context lives at trusteed.io.

Trusteed CTEM vs point tools

Capability	Typical point tool	Trusteed CTEM
Discovery model	Point-in-time scan you schedule	Continuous discovery of domains, IPs, services, technologies with ongoing scan plans
Output	Raw findings and scanner signals	Findings correlated with CVE catalog, EPSS/KEV context, and exploit references
Noise handling	Every match is a ticket	Validation and business-context gate (should_alarm) before anything pages an analyst
Application depth	Generic web checks or none	Dedicated API surface worker plus deep DAST for critical applications
Posture beyond HTTP	Limited or absent	SSL/TLS, mail and DNS posture, network and service exposure in one surface view
Compliance evidence	Raw exports	Framework-oriented views and customer reporting
Where it fits	CI checks, container scans, template-based testing	End-to-end exposure management: discover, prioritize, validate, remediate, report

Template and container scanners such as Nuclei and Trivy are genuinely useful for what they do — they produce signals. They are not a CTEM workflow. They do not own your inventory, they do not adjudicate whether a finding deserves a phone call at 2 a.m., and they do not produce an auditor-ready narrative about how exposure is managed continuously.

FAQ

Is a $300 consultancy offer really a cyberattack? Usually it is the reconnaissance phase of one. The offer itself causes no damage; the objective is to determine whether you have access or knowledge worth extracting later. Treat unsolicited, well-paid, low-effort requests for your professional opinion as social engineering until proven otherwise.

How is CTEM different from a vulnerability scanner? A scanner produces findings from a point-in-time scan. CTEM is a continuous program: discover and inventory the attack surface, prioritize findings with exploitability context, validate them against business relevance so the SOC only sees actionable risk, remediate, and prove the outcome. Scanners are one input to CTEM — not a substitute for it.

Does CTEM cover third parties and contractors? It covers what they can reach. You cannot enforce least privilege on a vendor's identity if you do not know which of your assets are externally reachable and which services they expose. Continuous external attack surface discovery plus identity-oriented exposure tracking is what makes third-party access review meaningful rather than ceremonial.

Can we detect trust-layer attacks with tools we already own? Partly. Identity logs will show a new OAuth grant; they will not show that the requesting "consultant" registered a lookalike domain last week or that their engagement introduced a new API endpoint. Detection improves when identity telemetry, external surface discovery, and exploitability context are normalized in one place.

What is the fastest win? Two things: continuous diffing of your external surface so new exposure alerts you within days instead of quarters, and a validation gate so the resulting alerts are actually trusted by analysts. Both reduce risk and reduce fatigue at the same time.

Should we ban external consulting or recruiting outreach entirely? No — that is unworkable and counterproductive. The workable control is process: named sponsors, time-boxed access, security review before engagement, corporate-controlled hardware for interviews and onboarding, and a no-blame reporting channel. Policy handles the human layer; CTEM handles the technical exposure that policy inevitably misses.

How do we measure whether any of this is working? Track exposures discovered and closed, mean time to remediate by exploitability tier rather than raw CVSS, the ratio of validated to raw findings, and coverage of known external assets. If the ratio of validated findings is rising while the SOC queue is shrinking, the program is working.

What about AI-generated social engineering? Assume pretext quality will keep improving and that AI-integrated malware will continue moving from experimental to standard. The defensive constant is the same: know your exposure, prioritize by real exploitability, validate before alarming, and remediate with evidence.

Related resources

• Trusteed CTEM platform — product overview, continuous exposure management, and vulnerability intelligence.
• Trusteed tenant app — where operators run discovery, scan plans, findings validation, and reporting.
• Cisco Talos Threat Source: "Trust and the enticing consultancy offer" — the newsletter that prompted this piece, plus the CAIRN research toolkit for AI-integrated malware.
• CISA: guidance and advisories on North Korean IT worker schemes and insider risk — joint advisories on hiring schemes and remote IT worker fraud.
• NIST Cybersecurity Framework 2.0 — the Govern, Identify, and Protect functions map directly to third-party and trust-layer risk.
• NIST SP 800-53, Access Control and Personnel Security controls — the control language auditors expect to see behind your vendor access reviews.
• OWASP Secrets Management Cheat Sheet — practical guidance for the code-and-credential boundary that trust attacks most often cross.