An employee's single sign-on page shows a neat grid of tiles: mail, file storage, the customer database, an analytics tool, e-signature, the team chat. One sign-in opens all of them. The phone rings. The caller gives a name, says IT is updating everyone's sign-in settings today, and offers to walk the employee through it on a page that looks exactly like the company's own. The page and the call are invented for this dispatch. Nothing about the call feels like an attack, and when it ends, every tile on that grid can be opened by someone else.
Last Thursday, January 29, Match Group confirmed what it called a recently identified security incident. A spokesperson said the company had "acted quickly to terminate the unauthorized access," that there was no indication login credentials, financial information or private communications were accessed, and that it believes the incident affects a limited amount of user data.1 BleepingComputer reported that it was told the attacker had compromised a single Okta sign-on account that reached a marketing analytics tool and cloud storage. Match disputed part of that account, saying its investigation found that the cloud storage files were not accessed.2 The attackers claim far more data than Match describes, and that claim is unverified.1
My argument is that the lesson for every organization is not about one company but about two things the login screen does not show. One sign-in is what organizations protect: the password, the second factor, the policy. Every app behind it is what an attacker gets once that sign-in is given away. The second is usually far larger than anyone has written down, and in this campaign the thing that gave it away was a convincing voice on the phone.
Sign in · illustrative
usera.employee
password••••••••
code••••••
typed into a page "IT" sent
Behind it
- File storage
- Customer database
- Analytics
- E-signature
- Team chat
- HR portal
- Finance reports
The campaign
The pieces came out over the past two weeks. On January 22, Okta warned that phishing kits built for callers were being sold as a service. According to Okta's report and BleepingComputer's coverage, attackers research a target's name, the applications the employee uses and the company's IT support numbers, then call with a spoofed corporate or help-desk number. While they talk, the kit lets them change what the victim's browser shows in real time, so each prompt matches the script.34 BleepingComputer described the sign-on dashboard such an attacker reaches as a gateway to a company's business-wide services.4
On January 30, Mandiant, part of Google's threat intelligence group, described an expanding campaign in which callers posing as IT told employees the company was updating its multi-factor settings, steered them to look-alike sign-in sites, captured their credentials and codes, and registered the attacker's own device. Mandiant did not name its victims. The researchers also reported that the targeting of organizations and people was deliberate, but what was taken afterward was likely opportunistic, "determined by the specific permissions and applications accessible via the individual compromised SSO session."5 And they stated that the compromises did not come from security vulnerabilities in vendors' products.5 Researchers cited in the press said the campaign targeted roughly 100 organizations; that figure is as reported, and CSO Online noted there was no official confirmation of how the companies were breached.16
The reach is the risk
That middle finding is the one to dwell on. The attacker chose whom to call. What the attacker could take was decided long before, by whoever granted that person access to each application, each shared folder and each role. Mandiant reported searches through cloud documents for terms such as confidential and VPN, and attempts to reach personal data in customer records.5 None of that required breaking an application. It required one person's ordinary session.
Reach grows quietly. A new tool is connected to single sign-on and every department gets a tile. Someone is given access for a project, and the project ends but the access does not. Each grant is reasonable on the day it is made. Nobody adds them up, because the review looks at the door. Sunday's essay, Who gave the machine permission?, asked what authority an automated system carries; the same question applies to a person's sign-in, which carries authority to everything it can open.
Reach sheet · one role · illustrative
Sales operations analyst
| One sign-in opens | Needed? |
|---|---|
| Customer database | yes |
| Analytics | yes |
| Team chat | yes |
| File storage, all company shares | review |
| E-signature | no |
| HR portal | no |
| Finance reports | left from a past project |
| Analytics admin console | no |
The voice on the phone
The other thing the login screen does not show is the trust between employees and their help desk. These callers knew names, applications and support numbers. They offered help with something that sounds routine, like setting up a passkey or updating sign-in settings.4 An employee who cooperates is doing what a good employee does when IT calls. That makes this a leadership and process problem as much as a technical one: people need to know, in advance and in writing, what IT will and will not ask them on a call.
Stronger sign-in factors help, and Okta and Mandiant both recommend phishing-resistant methods such as security keys or passkeys, because a caller cannot simply read them out.35 But a stronger door does not shrink what lies behind it.
This is not an argument against single sign-on. One place to grant, revoke and watch access is still far better than a scattered set of passwords. It is not a claim about what any one company did wrong; investigations were still under way as of February 2. And it is not a claim that the identity providers or the applications were hacked: by Mandiant's account, they were not.
Four checks for this month
- List the reach of five roles. For each, write down every app, share and role one sign-in opens, and remove what the role does not need.
- Tell staff what IT will never ask. Put it in writing, and give them a separate, official way to verify a caller before they act.
- Review every new sign-in device. In Mandiant's account, registering the attacker's device was the first move after the call. Treat that event as one someone looks at.
- Harden the widest doors first. Move the accounts with the most reach to phishing-resistant sign-in.
Back to the sign-on page. The sign-in box at the top will get attention this week, as it should. The grid of tiles below it deserves the same attention: who put each tile there, whether this person needs it, and what it would mean if someone else could open it after a friendly call from IT.