The call usually shifts the attack into a higher-trust channel where the criminal can ask for credentials, payment details, or remote access steps. In some cases, the caller is pressured to install software that supposedly resolves the charge but actually introduces malware. Once the conversation starts, the attacker can adapt in real time and steer the victim toward a compromise that email filters never see.
How the attack changes once the victim calls back
A callback scam turns a one-way phishing attempt into an interactive social-engineering session. The attacker can answer objections, change the story, and keep the victim engaged long enough to extract information that would be harder to steal from a static message. That shift matters because the “proof” the victim seeks on the phone can be fabricated in real time.
The caller may present themselves as support, billing, or collections and use urgency to keep the conversation moving. Once trust is established, the ask often broadens from payment clarification to credentials, one-time codes, or remote access steps. In practice, the phone call becomes the control point where the attacker can steer the next action instead of waiting for the victim to interpret an email alone.
These scams also work because the victim often assumes a live human on the other end is more accountable than an email sender. That assumption is exactly what the attacker exploits. A call can sound legitimate, but the channel itself proves nothing about the caller’s authority, entitlement, or relationship to the invoice.
What the attacker can do during the call
Once the victim is talking, the attacker can gather account details, payment method data, verification codes, or remote-support instructions. They may direct the employee to “resolve” the issue by opening a site, approving a payment, or installing software that gives the attacker access to the endpoint. If the victim complies, the compromise can move from deception into credential theft, malware delivery, or remote control.
That live interaction gives the attacker flexibility. If one request fails, they can pivot to another: different pretext, different department, different urgency level, or a different payment route. The call is therefore not just a delivery method, it is a negotiation layer that helps the attacker adapt around normal technical controls.
Because the call is external to email security tooling, standard filtering and link-scanning controls do not see the full attack sequence. The real risk is not the invoice itself, but the human decision path that follows the callback. If the employee treats the number in the alert as a trusted escalation path, the attacker can use the conversation to defeat the victim’s normal caution.
Why callback fraud is effective in practice
Callback fraud works by combining urgency, authority, and a low-friction next step. The fake invoice or subscription alert creates a problem state, and the phone number offers a quick way to “fix” it. That shortens the time available for verification and increases the chance that the employee will act before checking the request through a known-good channel.
The main weakness is process confusion. If employees do not have a strict habit of independently locating vendor contact details, they may treat the number in the message as part of the official workflow. That creates an easy path for business email compromise, payment redirection, credential harvesting, and endpoint compromise, even when the original message looked only moderately suspicious.
For that reason, callback scams should be treated as a trust-boundary problem, not just a phishing problem. The message is only the trigger, the call is the exploitation environment. Once the attacker has real-time dialogue, the attack can escalate in ways that are harder to detect and easier to personalise.
Risk and Threat Considerations
Callback scams matter because they move the victim from a visible email channel into a higher-trust, less-monitored interaction where social pressure and improvisation can bypass normal verification habits. The risk is strongest when the employee believes the phone number is part of the legitimate invoice or subscription process.
Failure mechanism: The attacker uses the phone call to establish urgency, impersonate a vendor or internal support role, and steer the victim toward disclosure of credentials, payment information, or remote access actions that create immediate compromise risk.
Impact: The organisation can suffer payment fraud, account takeover, malware infection, or unauthorized access to internal systems, with consequences that may extend beyond the original invoice issue.
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 and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1566 — Phishing | Callback scams begin with a deceptive message that lures the victim into contact. |
| T1589 — Gather Victim Identity Information | Attackers use the call to elicit credentials, codes, and account details. | |
| T1204 — User Execution | The scam aims to get the victim to click, approve, or install something themselves. | |
| Recommendation — Train users to verify payment and subscription alerts through known-good contact paths. Monitor for requests that solicit account data during vendor or support calls. Block unverified installs and require separate approval for remote-support actions. | ||
| CIS Controls v8 | CIS-14 — Security Awareness and Skills Training | Employees need practice spotting callback-based social engineering and verification traps. |
| Recommendation — Include callback fraud scenarios in phishing and invoice-verification training. | ||
| NIST CSF 2.0 | PR.AT-01 — Identities and credentials are issued, managed, verified, revoked, and audited | Verification discipline is central when callers request credentials or access steps. |
| Recommendation — Require independent verification before any credential or payment disclosure. | ||
| NIST SP 800-53 Rev 5 | IR-4 — Incident Handling | A suspected callback scam is an incident response trigger, not just a user mistake. |
| IA-5 — Authenticator Management | The scam often seeks passwords, one-time codes, or other authenticators. | |
| Recommendation — Route reported callback scams to incident handling and containment workflows. Prevent sharing of authenticators and enforce rapid revocation if exposure is suspected. | ||
Practitioner Guidance
What to verify: Employees should treat any phone number inside an invoice, renewal notice, or subscription warning as untrusted until it is independently verified through a known vendor portal, contract record, or internal directory. The key judgement is whether the contact path was chosen by the employee, not by the message sender.
Decision rule: If the caller asks for a password, one-time code, payment card, bank detail, or remote-support action, stop the interaction and switch to a separate verification path. If the request is only to “confirm” an alert, that is still a security event if the number came from the message itself.
Practitioner takeaway: The safest response is to make the callback path non-authoritative by policy, because the attacker’s advantage comes from controlling the conversation before the employee has a chance to verify who they are really speaking to.
Related resources from NHI Mgmt Group
- Should organizations develop SLAs for NHI alert responses?
- What happens when users are pushed to call a fake security hotline from a phishing page?
- What happens when employees enter corporate credentials into a fake login page?
- What happens when an employee accepts a fake IT support call without verifying the caller?