The Caller Had the Last Four of the SSN. Then Came the Broken Phone.

A help desk is supposed to confirm who a caller is before it resets a password or adds a device. In April 2024, HHS’s Health Sector Cybersecurity Coordination Center (HC3) described callers who passed that check with details they had gathered about the employees they were impersonating.

What information let the caller pass identity verification?

HC3’s alert describes threat actors calling a health-sector organization’s IT help desk from a phone number with an area code local to the target, claiming to be an employee in a financial role, specifically revenue cycle or administrator roles (HHS HC3 Sector Alert, April 3, 2024). Asked to verify their identity, the caller supplied the last four digits of the target employee’s Social Security number and a corporate ID number, along with other demographic details. HC3’s own assessment of where that came from: “These details were likely obtained from professional networking sites and other publicly available information sources, such as previous data breaches” (HHS HC3, 2024).

The caller had no need to guess, because these are the kinds of details that circulate after a breach. A help desk asking the same questions of a caller holding the same details would likely reach the same conclusion: verified.

Why did claiming a broken phone work?

The information got the caller in the door, and the next move got them a new device. HC3’s account: “The threat actor claimed that their phone was broken, and therefore could not log in or receive MFA tokens. The threat actor then successfully convinced the IT help desk to enroll a new device in multi-factor authentication (MFA) to gain access to corporate resources” (HHS HC3, 2024).

A broken phone is a plausible, sympathetic story, and it explains both things the caller said they could not do: log in, or receive an MFA token.

What did the attacker do with access?

HC3’s alert traces what happened next: “After gaining access, the threat actor specifically targeted login information related to payer websites, where they then submitted a form to make ACH changes for payer accounts.” HC3 continues: “Once access has been gained to employee email accounts, they sent instructions to payment processors to divert legitimate payments to attacker-controlled U.S. bank accounts. The funds were then transferred to overseas accounts” (HHS HC3, 2024). One new MFA device, enrolled on a help desk call, ended in diverted payer payments.

What does HHS recommend, and what limit does it name?

HC3 lists several mitigations for health-sector organizations: “requiring callbacks to the phone number on record for the employee requesting a password reset and enrollment of a new device,” monitoring for suspicious ACH changes, and revalidating users with access to payer websites (HHS HC3, 2024). Some hospitals require employees to appear in person at the IT help desk for these requests, and HC3 also suggests requiring the employee’s supervisor be contacted to verify the request.

HC3 flags one limit of the callback itself, in its own words: “It is important to note that when attempting callbacks for verification, the threat actor may claim to be too busy to take a phone call” (HHS HC3, 2024). In-person appearance and supervisor contact take the phone out of the check, but both assume the employee is on site or the supervisor is reachable in the moment, which is harder for an organization running shifts across several facilities.

How a healthcare help desk can verify a caller without trusting what they claim

ATO Protect for IT Help Desk is built to answer a different question than “does this caller know facts about the employee.” From the web portal or the API, the agent sends a secure verification link by SMS, email, or chat to the number on file. Whichever channel the link travels by, whoever opens it has to scan a government-issued ID, checked in real time against the authority that issued it. Knowing the last four digits of an SSN and a corporate ID number does not satisfy that check, because neither one is what gets checked.

A caller does not need to download an app or have registered in advance, so someone calling the help desk for the first time gets the same check as someone who has called before. SIM swap detection can flag when the caller’s number has recently moved to a new SIM, and man-in-the-middle detection is patented (US Pat. 10,601,859). It runs no selfie or liveness check, because generative AI can now defeat those methods. All user PII from the verification session is deleted, and verification reaches NIST IAL2, on SOC 2 infrastructure.

The same government-ID check already runs in higher education. At the University of Connecticut, “By integrating the ATO Protect API, students and staff can verify their identity with a government ID and reset passwords in under a minute without waiting for support” (Trusona, UConn case study). UConn runs it as self-service; a healthcare help desk would run the same check with an agent starting it.

The same discipline applies past this one alert. A caller reciting an SSN’s last four digits is one version of a knowledge-based check, and Trusona has written before about moving beyond knowledge-based authentication. Health portals also carry authorized users who never had a reason to supply an SSN, a separate verification gap covered in verifying people without a Social Security number.

What a healthcare help desk should ask about its own process

HC3’s alert describes what already happened, and it shows which identity questions a real caller answered correctly. Any healthcare help desk’s own procedure can be checked the same way: when a caller says their phone is broken and asks for a new MFA device, what does the process check that the caller cannot simply state?

Frequently asked questions

What did the HHS HC3 alert warn healthcare help desks about? HC3’s April 2024 sector alert describes threat actors calling health-sector IT help desks, posing as employees in financial roles, and using an employee’s SSN’s last four digits and corporate ID number to pass identity verification, then claiming a broken phone to get a new MFA device enrolled.

What information did the caller use to pass identity verification? The last four digits of the target employee’s Social Security number and their corporate ID number, along with other demographic details. HC3 says these were likely obtained from professional networking sites and other publicly available sources, including previous data breaches.

Why did claiming a broken phone work? It gave the caller a reason they could not log in or receive MFA tokens, and HC3 says the help desk was then convinced to enroll a new device.

What did the attacker do once they had access? HC3’s alert describes the attacker targeting payer-website logins, submitting ACH changes for payer accounts, and instructing payment processors to divert payments to attacker-controlled U.S. bank accounts before the funds moved overseas.

How can a healthcare help desk verify a caller without relying on knowledge questions? ATO Protect for IT Help Desk sends a secure verification link by SMS, email, or chat to the number on file, and the caller has to scan a government-issued ID that is checked against the authority that issued it. It requires no prior enrollment, runs no selfie or liveness check, and can flag a number that has recently moved to a new SIM.

HC3’s alert names the facts a caller used to get past identity verification. The question worth asking of any help desk’s own process is whether those same facts would get someone past it too.