Analysis

The phishing vector your awareness training cannot fix

An internal link, on a trusted domain, through the normal channel. Why blaming the user guarantees recurrence — and why the only control that addresses this is third-party access governance.

Ketrica R. Green

A user clicked a document link shared from an internal collaboration site. Ransomware followed, and encryption began executing on affected hosts.

Every part of that sentence is ordinary except the one that matters. The link was internal. It was on a domain the user worked in daily, shared through the channel colleagues use to share documents with each other. And that single fact defeats two layers of defense simultaneously, which is why this vector deserves more attention than it gets.

It defeats the user, by design

Security awareness training is calibrated against a specific threat model: unexpected external email, unfamiliar sender domains, urgency and pressure, attachments you were not expecting, links whose hover text does not match their label. Every one of those signals was absent here.

There is no realistic version of awareness training in which that user does the right thing. Telling people to scrutinize links from their own collaboration platform is not a control — it is an instruction to distrust the tool you have asked them to work in all day, and it will be ignored within a week because work has to get done. Any program that treats this as a training failure will produce the same incident again, and will additionally guarantee that the next person hides it rather than reporting it.

It defeats the email security stack, also by design

URL reputation services, sandbox detonation, and attachment scanning are tuned against inbound external mail. That is where the volume is and that is where the budget went. A link to a trusted internal tenant does not trip them, because from the stack's perspective nothing arrived from outside.

The malicious content was already inside the trust boundary before any control looked at it. That is the whole trick, and it is not sophisticated. It just requires the attacker to be somewhere the controls are not pointed.

Which reframes the entire investigation

The click was not the incident. It was stage two.

The question that actually matters is how a malicious document reached an internal library, and whose access put it there. Treating the clicking user as patient zero produces a closed ticket and an open incident — you remediate the endpoint, and the file remains reachable by everyone who has not clicked it yet, through an entry point still in place.

The organization's controls were calibrated for outsiders, and the adversary came in through an identity the environment had already decided to trust.

Working backwards from the file — who uploaded it, from what identity, from what address and device, and when — surfaced an external guest account. A vendor collaborator, holding upload and sharing rights that exceeded anything the actual collaboration required.

The access had been provisioned for a legitimate business reason. It was then never reviewed, never scoped down, and never given an expiry date. It sat inside the trust boundary indefinitely until it became a delivery mechanism. That is not an unusual failure — it is the ordinary lifecycle of guest access in most tenants, which is precisely why it is worth writing about.

Responding without halting the business

In a cardholder data environment one question governs everything downstream: is the CDE affected? That determines whether you are running an operational recovery or a reportable card data breach with card brand notification, acquirer notification, and a potential forensic investigator engagement. So segmentation validation came first, before endpoint work, before anything.

Blast radius came from the platform audit log rather than from guesswork. Collaboration platforms record exactly who viewed, downloaded, or synced a file and when — which converts a vague exposure question into a bounded, prioritized list. That is the difference between targeted response and shutting down a department, and the gap between the number exposed and the number actually infected is the clearest measure of whether the response worked.

Containment was scoped precisely rather than broadly: quarantine the file and revoke every active sharing link to it; disable the guest account and revoke its sessions and tokens, because disabling an account alone can leave live tokens working; isolate infected endpoints at the network layer while preserving them for forensics; block identified command-and-control infrastructure; validate that segmentation held.

Taking the collaboration platform offline would have been simpler and worse. It is the substrate the business runs on, halting it halts the organization, and that creates pressure to rush every decision that follows. The timing judgment is the senior call in any ransomware response — contain too early and you tip off an actor who may still be staging, too late and you extend the damage. With encryption already executing, that calculus resolves toward speed. Active encryption is ongoing loss, and there is no investigative value worth additional hosts.

Fixing the class of problem

The lessons-learned review targeted the root cause rather than the symptom, which meant the controls that mattered were access governance controls, not email controls.

Why this is a third-party risk story

I have spent a large part of my career on third-party risk — building due diligence frameworks, automating vendor assessment across hundreds of suppliers, standing up third-party information security risk programs. This incident is the practical case for all of it, and it is worth saying plainly:

A vendor identity is inside your trust boundary, and every control you have built is calibrated for outsiders. The vendor questionnaire tells you what they do at their perimeter. It tells you nothing whatsoever about what their account can do inside yours.

That gap is where this incident lived, and it is where the next one will too.

← All writing