Look for impersonated contacts, fake software update prompts, unusual messaging-based requests, and attempts to move users off established verification channels. Those signals indicate that attackers are using identity and trust manipulation rather than direct exchange compromise, so fraud controls and endpoint governance need to engage early.
How to tell when the targeting is personal, not platform-wide
The quickest way to distinguish individual targeting from a platform breach is to look for trust exploitation outside the exchange itself. Attackers usually impersonate support staff, vendors, or known contacts, then try to redirect the victim into a different channel where verification is weaker. That pattern points to social engineering against a person, not compromise of the trading platform.
Signals often show up in the wording and timing of the approach. Fake software update prompts, urgent wallet or account warnings, and requests to move to direct messaging or email are common because they bypass the normal controls people rely on inside the platform. The more the request tries to escape established verification paths, the more likely the attacker is targeting the individual.
Context also matters. If only a small number of users receive highly tailored contact while the platform remains stable, that is a different pattern from a broad service outage or many users seeing the same malicious behaviour. A targeted campaign often exploits the victim’s role, holdings, or public footprint, which is why user-facing fraud detection and reporting need to be as important as backend monitoring.
What the attack path usually looks like in practice
Individual targeting typically begins with reconnaissance. The attacker gathers public profile details, transaction habits, or community presence, then uses that information to make contact seem legitimate. Once trust is established, the next step is usually a prompt to reveal a code, approve a transfer, install software, or continue the conversation somewhere the platform cannot observe.
This is why NIST Privacy Framework thinking is useful even for a security question like this, because identity trust cues, disclosure control, and misuse of personal context all affect whether the attack succeeds. It is also why platform telemetry alone is insufficient: the abuse may occur in messaging apps, phone calls, or social channels before any exchange control is touched.
When the same pressure is applied at scale, you may see many users receiving similar lures, but the goal remains the same, to move the victim into a channel where the attacker can impersonate authority and bypass normal verification. That is a strong indicator that the account holder is the target, even if the platform never shows signs of compromise.
What controls matter most for early detection
Detection works best when organisations treat this as a fraud-and-trust problem, not only a cyber incident. Endpoint governance, user reporting, and contact verification need to trigger fast when users receive requests for remote access, wallet changes, seed phrases, or off-platform support. If the request cannot be verified inside the standard workflow, it should be treated as suspicious until proven otherwise.
Defenders should also watch for telltale combinations such as new communication channels plus urgency plus a request to authenticate, approve, or install something. Those combinations are harder to explain as benign support activity and are often the earliest reliable sign of a personal targeting campaign. If you already operate identity-aware detection, this is where it helps to correlate user reports with abnormal login or device prompts.
Internal guidance on The State of NHI & AI Agent Breach Report 2026 is useful here because it reinforces a recurring breach pattern: attackers often pursue the person, the secret, or the delegated access path rather than the platform perimeter. When you see that pattern, the right response is to confirm channel integrity, not assume the exchange has been breached.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Personal-targeting attacks often seek codes, tokens, or approvals that must be managed tightly. |
| AU-6 — Audit Review, Analysis, and Reporting | Spotting off-platform targeting depends on reviewing user reports and anomalous verification events. | |
| AC-7 — Unsuccessful Logon Attempts | Repeated prompts for codes or approvals can accompany account takeover attempts against individuals. | |
| Recommendation — Limit authenticator exposure and rotate compromised credentials immediately. Correlate fraud reports with login, reset, and approval activity to confirm attack patterns. Trigger alerts when suspicious verification attempts recur across a short time window. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question centers on preserving trusted access paths and preventing channel abuse. |
| A.5.16 — Identity management | Individual targeting relies on impersonating trusted identities and contacts. | |
| Recommendation — Enforce verified channels for sensitive account actions and support requests. Validate identity claims before accepting requests to change access or contact methods. | ||
| MITRE ATT&CK | T1585 — Establish Accounts | Impersonation and fake contacts are common setup steps in personalized targeting. |
| Recommendation — Map impersonation activity to the early stages of adversary setup and deception. | ||
Practitioner Guidance
What to prioritise: Build a triage rule that separates user-targeted fraud from platform compromise. Prioritise reports involving impersonation, channel switching, update prompts, and requests to reveal codes or move money, because those are the highest-signal indicators of a personal attack.
What to verify: Check whether the same message was delivered through official platform channels. If the request exists only in direct message, email, text, or voice contact, treat it as an off-platform trust test and verify before any user action is approved.
What good looks like: Security and fraud teams can quickly answer three questions, who contacted the user, what channel they asked to move to, and what action they wanted next. If those three points are clear, you can usually tell whether the attacker is targeting the individual or probing the platform.
Practitioner takeaway: The best early warning is not a technical indicator on the exchange, it is a trust boundary violation around the user. When the attacker tries to move the conversation, they are usually trying to move the control plane too.
Related resources from NHI Mgmt Group
- How do overprivileged NHIs increase breach impact in cloud environments?
- How can organisations spot obfuscated privilege changes before they become a breach?
- Should organisations treat agent discovery as part of IAM or platform operations?
- When should organisations treat a data governance platform as part of security architecture?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 13, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org