Two Victims, One Supplier: Finding the Common Vendor Behind Two Intrusions
The challenge
A clinic group and a freight company, in different sectors and with no customers, staff or networks in common, were both robbed in the same week by a session that nobody ever logged into. Neither one can find a phishing mail, a stolen password or a piece of malware, and both were running multi-factor authentication that was never challenged. What two organisations like that share is suppliers. Six public records are on the board. Work out which supplier is in both stories and is the one that can create a session without a login.
What you'll learn
- Build vendor inventories for two organisations from public disclosures
- Intersect two sets and use secondary evidence to break the tie
- Recognise vendor impersonation features as an unlogged authentication path
- Explain why MFA is silent when a session is created server-side
- Use a third, unaffected organisation as a control group
Skills tested
Prerequisites
- What single sign-on and MFA do
- Reading a breach disclosure
How it works
When two organisations with nothing in common are hit the same week by the same unexplained mechanism, the shared thing is almost always a supplier. Vendor inventories are far more public than companies realise: breach notices name systems, regulatory filings list scope, job adverts describe the stack in detail, and engineers answer questions on forums.
The specific weakness here is an impersonation feature. Support tooling frequently ships a way for an agent to open a customer's application as one of that customer's users, because it is the fastest way to reproduce a bug. The session is minted on the vendor's side, so the customer's identity provider is never asked anything. No login event, no MFA challenge, no anomalous location, nothing in the customer's authentication log. Everything the victim would normally use to investigate is blind by design.
That is why the tie-break is not which vendor is bigger or more obviously security-critical. It is which vendor can create a session without performing a login, because that is the one capability that matches what both victims described.
Common mistakes
- Answering Latchkey SSO. It is in both stacks and it is the identity provider, which makes it the intuitive answer. Its status history covers the window, its external assessment is clean, and the victim states there is nothing in its logs. Intersecting is not enough; you have to eliminate.
- Answering Northfield or Vantage. Each appears in one victim only.
- Treating the forum thread as noise. The clinic that dropped Tidemark in July and was not hit is the closest thing to a control group on the board.
- Looking for the initial access vector at the victims. Neither victim was the way in. The attacker was already inside the vendor.
How to defend against it
Treat every vendor that can act as your users as part of your identity perimeter.
- Inventory which suppliers hold impersonation, assist or support-login rights, and turn the feature off where nobody actually uses it.
- Require per-session customer approval for impersonation, with an expiry, so a vendor-side compromise cannot silently mint sessions.
- Demand that vendor-side audit logs be exportable into your own SIEM in near real time. Harlow and Calder could not query the log that held the answer until a week after the intrusion.
- Alert on privileged activity from sessions with no corresponding authentication event in your identity provider. That correlation is cheap and it is exactly the gap this attack lives in.