The call that comes from your own IT desk
Somebody rings one of your colleagues on their personal mobile. They know the person's name, they know where they work, and they say they are calling from IT about a mandatory security upgrade that needs doing today. The number on the screen matches your real help desk.
Nothing about that call touches your firewall, your email filtering, or your antivirus. It arrives on a device you do not manage, through a channel you cannot monitor, and it asks a helpful person to do a helpful thing.
That is the attack. It is working well enough that a single group has been running it against financial, legal, and professional services firms all year.
What changed
Google's Threat Intelligence Group published an analysis on 7 August of a group it tracks as UNC6671. The group has run under several names, and the name-changing is part of why it is worth your attention.
It operated as BlackFile until May 2026, announced it was shutting down, then reappeared in June as Redact claiming the old brand had been hijacked by a former associate. Google found the same phishing templates, the same victim profile, and shared infrastructure across Redact, Pink, Helix, and Falcon. One group, five shopfronts. The researchers think the point is to hide how much they are actually breaching and to keep negotiations separate.
Between 7 January and 12 May, Google reviewed 18 Bitcoin wallet addresses linked to the group holding 141.65 BTC, roughly 10.7 million US dollars at the time those payments were made.
The targeting moved through the year. Manufacturing, property, healthcare, and insurance from April to May. Technology, transport, and hospitality in June. By July it had narrowed to private equity firms, law firms, and credit rating agencies. Google says the group has been active against organisations in the UK, North America, and Australia.
Why the usual controls do not catch it
The call goes to a personal phone. That is deliberate, and it is the detail that should change how you think about this.
Your work systems have controls on them. Personal mobiles do not. There is no filter, no logging, and no way for you to see the conversation happened. The first thing you know about it is what comes afterwards.
What comes afterwards is a login page. The caller gives a plausible reason to visit it: enable passkeys, re-enrol your authentication, complete an urgent migration. The page is a copy of the real one, sitting on a domain like passkeyhelpdesk or setupsso with your company's name added as a subdomain so it looks specific to you.
When the person types their password and approves the code from their phone, both go to the attacker in real time, who is typing them into the genuine login page at the same moment. This is what "adversary in the middle" means: the fake page is a relay, not a copy. Security researchers at CrowdStrike, tracking the same activity, describe attackers capturing live session tokens this way.
The code on your phone is a real code. The approval is a real approval. The login succeeds, and the attacker is inside the session.
Two further details are worth knowing. Once in, the group registers its own authentication device on the account, and removes the one that was there. And it goes for your single sign-on provider, the service everything else logs in through, rather than individual applications. Google's analysis notes the group reaching Microsoft 365 and Okta environments this way. Get the front door and every room is open.
Google was explicit in an earlier report that these compromises are "not the result of a security vulnerability in vendor products or infrastructure". Nothing was unpatched. Somebody was helpful on the phone.
The rule that stops it
One rule, and it is a process rule rather than a product one.
Nobody from IT will ever ring you and ask you to log in to anything. If you get that call, hang up and ring the IT number you already have.
That is the whole control. It works because it does not require anyone to spot a convincing fake, and the fakes are convincing. It moves the decision off the call the attacker controls and onto a channel they do not.
Say it plainly to your team, and say the second half too: you will never be in trouble for hanging up on IT. The attack runs on manufactured urgency and on people being reluctant to be difficult. If your culture makes hanging up feel rude, the rule will not hold when it matters.
Then three things worth doing behind it:
Move to passkeys where you can. A passkey is tied to the website it was created for, so it will not hand anything to a lookalike domain even if the person is completely fooled. The codes-on-your-phone approach is what this attack is built to defeat. The NCSC's position on passkeys is worth reading before your next renewal conversation.
Ask who can add an authentication device to an account. Registering a new device and deleting the old one is how the access survives a password reset. If nobody is alerted when that happens on your systems, that is a gap worth closing.
Agree now what your help desk will never ask for. Write the short list down, tell everyone, and make sure the people who answer the phones know they are allowed to say no.
If an outside IT company supports you, this conversation is one to have with them. They are the ones being impersonated.
How Steelwise can help
Working out how someone would actually get into your systems, and whether your team knows what to do when the phone rings, is a defined piece of work with a clear answer at the end. Get in touch if you would like a second opinion on yours.
Further reading
- NCSC guidance on phishing, which covers the reporting culture this depends on
- NCSC on multi-factor authentication for online services
- Cyber Essentials, which covers access control and authentication