- › Google tracks UNC6671 calling employees on personal mobile devices while impersonating the IT help desk, with pretexts built around mandatory security migrations.
- › Personal phones sit outside corporate controls, so nothing in your stack sees the call and nothing warns the person taking it.
- › Initial ransom demands run above $3 million and typically settle near $750,000 after negotiation.
- › Most organizations have spent years teaching staff that work reaches them on their personal phone, through multi-factor prompts, on-call rotations, and after-hours messaging.
- › The fix is a verification path people can use under pressure, not another reminder to be careful.
The call comes at 4:40 on a Friday. Someone from the help desk, friendly, a little rushed, apologizing for catching you at the end of the day. There is a mandatory security migration going through tonight and your account is one of the ones that did not take. They can push it through now if you have two minutes.
They called your personal cell. You have taken work calls on it for six years.
Google has been tracking the group behind this since January as UNC6671, operating under a rotating set of extortion brands including Redact, Pink, Helix, and Falcon, previously BlackFile. Their method is voice phishing against enterprise employees, called on personal mobile devices, with the caller impersonating IT support. The pretexts are account security issues, password resets, single sign-on and multi-factor setup, and access to an incident ticket. Victims get walked to a spoofed login portal that captures the credentials and the multi-factor token through adversary-in-the-middle infrastructure. From there the group exfiltrates from Microsoft 365 and Okta and opens with a demand above $3 million, settling around $750,000.
Google’s own assessment is worth quoting plainly: these compromises are not the result of a security vulnerability in vendor products.
Why the Personal Phone
Start with what the attacker gets by dialing that number instead of the desk line.
Nothing in your security stack is on that call. No mail gateway, no link rewriting, no banner warning that the sender is external, no logging. The recording, if there is one, lives on a carrier’s system you have no relationship with. Your detection engineering team, however good, has no telemetry from a phone call to a personal handset.
There is a second thing, and it is the one that matters more. A call to the personal phone reads as legitimate precisely because it is unusual. Nobody in an employee’s mental model of a scam pictures the scammer knowing their private number. The number itself functions as a credential. It says whoever is calling has access to an HR system or a directory, which means they are probably who they say they are.
That inference is reasonable. It is also wrong, and the person making it has about four seconds.
The Part Where We Usually Blame Somebody
What happens next in most organizations has a shape you can predict from the outside.
The employee gets described as having fallen for it. Someone notes that the training covered social engineering. Someone else suggests more frequent phishing simulations. The report closes with a recommendation about awareness, the person carries the story around for a couple of years, and the next employee in the same position makes the same call.
None of that touches why it worked.
Ask a different question. How did that employee learn that work arrives on their personal phone? They learned it from you. From the multi-factor prompt that pushes to their personal device because the company did not want to buy hardware tokens. From the on-call rotation that rings their cell. From the manager who messages them there because it is faster. From the six years of ordinary Tuesdays where a work call on the personal phone was completely normal, because it was.
An organization spends years teaching a behavior and then treats a single instance of that behavior as a character flaw in the person who learned it. The employee did exactly what the system trained them to do. The attacker knew that, which is why they dialed that number.
What Verification Actually Requires
Most companies believe they already have a verification policy. The policy usually says something like: if you receive an unexpected request, verify through official channels before acting.
Read that as an instruction someone has to follow at 4:40 on a Friday, on a call, with a person on the line waiting, when they have already been told there is a deadline. Which official channel? Called how? Do they hang up on someone who might genuinely be IT and might genuinely escalate that they were uncooperative? How long does the callback take, and what happens to the thing they were trying to leave for?
A control that requires someone to absorb social awkwardness and time pressure to comply is a control most people will skip most of the time. That is not a moral failing. It is what happens when you write a rule without designing the path to follow it.
Give people one number and make it fast
There should be exactly one way to verify that a call is really from your organization, it should be a number people can find without searching, and reaching a human on it should take under a minute. If your help desk callback queue runs eight minutes, you have built a verification step nobody will use, and you will find that out during an incident.
Say out loud that hanging up is correct
The single highest-value sentence you can put in front of staff is that hanging up on a caller claiming to be internal support is always acceptable and will never be held against them. Say it from leadership, in writing, more than once. Most people will not do the safe thing until someone with authority has told them the safe thing will not cost them anything.
Stop routing authentication through the personal phone
Every multi-factor push to a personal device reinforces the association you are trying to break. Phishing-resistant methods bound to hardware take the token out of reach of a voice call entirely, which is also what Google recommends coming out of this campaign. This is the control that removes the attack rather than warning about it.
Tell people what the help desk will never ask
Specific and short beats comprehensive. Your help desk will never ask for a code read aloud, never ask someone to approve a prompt they did not initiate, and never call a personal number about an account migration. Three concrete negatives are learnable. A twenty-slide module on social engineering is not.
Measure whether reporting is safe, not whether people click
Run the numbers you actually have. How many people reported a suspicious call last quarter? If the answer is close to zero, that is not an absence of attacks. In a program where reporting gets someone questioned about why they were fooled, people stop reporting and start quietly hoping they were wrong. You lose the early warning and keep the risk.
The Cost Side
The business case here is unusually easy to write, and worth writing down before the conversation happens.
An initial demand above $3 million, settling around $750,000, plus the incident response, the legal review, the notification obligations, and whatever the exfiltrated Microsoft 365 and Okta data turns out to include. Against that: hardware security keys for the population with access worth stealing, a callback path that answers in under a minute, and a leadership email that people are allowed to hang up.
The second column is a rounding error. It has been a rounding error for years, which is the part worth being annoyed about.
What I Would Actually Do Monday
Call your own help desk from an outside line and time how long it takes to reach a person who can confirm an identity. That number tells you whether your verification policy is real or decorative, and you can find it out before lunch.
Want to know whether your people would actually route around your controls under pressure? Take our free Human Attack Surface Score assessment, or contact us for a full risk assessment.
With a dual background in I/O Psychology (PhD Candidate) and Business Management (MBA), Marie bridges the gap between clinical rigor and operational strategy. She oversees B2B relations, compliance, and the 'business' of risk management.
View Author Page →
