Social Engineering the Dispatch Center: Attack Scenarios and Verification Protocols
A threat actor does not need a zero-day to breach a PSAP. They just need a phone and a believable story. The call is the attack vector. The dispatcher's instinct to assist is the vulnerability being exploited. Dispatchers are trained to help. Someone calls with a problem, and the dispatcher finds the right outcome. It is a culture of efficient helpfulness, and it saves lives. It also makes dispatch centers one of the most socially engineered targets in public safety.
I have worked with enough agencies to know most of them have good technical controls. Firewalls, MFA, network segmentation. Those controls evaporate when someone calls in sounding like the chief and a dispatcher reads them a password because the caller sounds urgent and authoritative. The correct response to a suspicious call is a verified call-back, not compliance with a perceived superior.
This article covers three realistic attack scenarios and the verification protocols that stop them.
Public Safety Dispatch Social Engineering Examples
Scenario A: The Urgent Chief
The phone rings on a busy shift. Caller ID shows the chief's office number. The voice on the line sounds stressed and says they are locked out of the CAD system. They need the dispatcher's login credentials to get in before an incident escalates. They need it now.
The attacker spoofed the chief's number. They know the chief is at an offsite meeting. They picked a time when the dispatcher is juggling multiple radio feeds and screen queues. The urgency is the weapon.
What gets extracted: login credentials, operational details like unit locations and current staffing, or MFA bypass by asking for the one-time code the dispatcher just received.
Scenario B: The Vendor Technician
Someone calls claiming to be from the CAD vendor's support desk. They detected a sync error that will crash the database in 30 minutes unless the dispatcher reads back a few configuration values. They need the server IP, software version, or a specific admin panel setting.
The attacker researched the agency's vendor relationship from public procurement records. They use vendor terminology. They sound like they know what they are talking about.
What gets extracted: software versions with known vulnerabilities and authenticated access vectors.
Scenario C: The Hospital Coordinator
A call comes in from what sounds like a regional trauma center. The caller says a critical patient is en route but there is confusion about the receiving unit's radio channel. They need the dispatcher to confirm which channel the crew is using and who is on duty.
The attacker is mapping operational communications. They want to know which channels carry sensitive traffic and when shift changes happen. This data feeds a larger attack. Ransomware, credential harvesting, or a physical breach.
What gets extracted: radio channel assignments, personnel rosters, and shift schedules.
Vishing Attack Scenarios for 911 Centers
All three scenarios use voice phishing (vishing). The attack surface is the human at the console. The common thread is the abuse of trust under time pressure.
Caller ID spoofing is trivial, and VoIP systems make it even easier. The voice on the other end sounds like someone who belongs, and the dispatcher's training tells them to support the request. A 2023 report from CISA flagged vishing against public safety entities as a growing threat. The report noted that the social engineering tactics used against PSAPs are more effective than those used against private sector targets because the consequences of a delayed response are visible and immediate. The attacker weaponizes the dispatcher's own professionalism against them.
How to Verify Caller Identity in Emergency Dispatch
Verification is not complicated. It just requires a protocol and the discipline to follow it.
Out-of-band call-back. The dispatcher ends the call and calls back using a number from the agency's internal directory when the request is unusual or high-stakes. The number in the directory, not the one on Caller ID and not the one the caller provides. If the caller refuses a call-back because of an emergency, that is a red flag. Real emergencies follow established chain-of-command protocols.
Challenge-response codes. Some agencies use a daily shifting code word for internal verification. A caller claiming to be from IT should know the code of the day. This is a simple barrier that eliminates casual attackers.
Vendor pre-registration. Every vendor that might call your dispatch center should have a pre-registered contact and an escalation path. When someone calls claiming to be from the CAD vendor, the dispatcher uses the known number to call back. Unknown callers never receive configuration data.
Dispatch Center Operational Security Protocols
Protocols are the human side of the security architecture. You need a written procedure for verifying a caller's identity, the same way you need one for accepting a new radio channel.
The protocol should cover:
- What information is never given over an unsolicited phone call. Credentials, passwords, MFA codes, IP addresses, and software version numbers should be on the never-list.
- What information requires a verified call-back. Operational details like unit locations, staffing levels, and radio channel assignments should only be confirmed by calling a known number.
- What to do when the caller pushes back. The dispatcher needs a scripted response that frames verification as policy. "I need to follow our security protocol. I will call you right back on your agency line."
Training matters more than technology here. A dispatcher who has practiced a call-back protocol on a slow shift will use it on a busy one. A dispatcher who has never been briefed on vishing will help the attacker.
There is a related discussion in the article on building an incident response plan that survives contact with a real EMS cyber incident. The same principles apply: the plan has to be practiced, not just written.
Preventing Social Engineering in Public Safety Agencies
Technical controls still matter but they only cover part of the problem. The article on MFA for the ambulance and why just using a YubiKey is not the answer covers authentication complexity in field environments. But MFA does not help when someone gives their credentials to a voice on the phone.
The best prevention is layered. Restrict what can be done over the phone. Make call-back verification mandatory for any request that touches credentials, network data, or operational patterns. Run drills and role-play the scenarios above. If a dispatcher has heard the vendor scam in training, they will recognize it when it happens for real.
Frequently Asked Questions
Why is Caller ID not enough to verify a caller's identity?
Caller ID spoofing is simple and widely available. Attackers can make any number appear on the display, including a chief's office line or a vendor support center. Caller ID tells you where the call appears to come from, not who is actually on the line.
What is the most common psychological trigger in vishing calls to dispatch?
Urgency combined with authority. The caller creates a high-stakes scenario and claims to be someone with positional power. The dispatcher's instinct to comply with a superior overrides their security awareness.
How should a dispatcher respond to a caller who refuses call-back verification?
Politely but firmly. The standard response should be: "For security reasons, I need to verify this request. I will call you back immediately on your agency line." If the caller refuses or escalates, that is confirmation the call is not legitimate.
What information should never be given over an unsolicited phone call?
Passwords, MFA codes, IP addresses, software version numbers, and network configuration details. These should only be shared through pre-established secure channels.
---
A phone call is a low-tech attack vector that defeats high-tech defenses. The dispatcher who follows a call-back protocol is worth more than any firewall appliance. Build the protocol, train it on every shift, and audit compliance regularly. That is how you close this gap.
-- Steven
Need help with your agency’s cybersecurity? Get in touch