Both Organisations Got Phished. Only One Noticed.

In August 2026, the US Cybersecurity and Infrastructure Security Agency published something it does not often publish: a side-by-side account of two red team assessments it ran at the same time, at two different critical infrastructure organisations, using similar tradecraft. Both assessments ended the same way, with the red team holding control of the domain and reaching sensitive business systems and cloud resources. What separated the two organisations was everything that happened in between. One security team spotted the first intrusion and pulled the affected machines off the network in minutes. The other never noticed, and the red team eventually read the security team's own email to check whether anyone had worked it out.

Both intrusions started the same way. Someone opened an email and clicked.

What CISA actually did

The advisory, published on 25 August 2026 as AA26-237A, "A Tale of Two SOCs", covers two concurrent engagements. Organisation A works in government services and facilities. Organisation B is a water and wastewater systems operator. Neither is named. CISA's red team simulates the behaviour of a real attacker, so the point is not only whether the team can get in, but whether the defenders see them doing it.

At Organisation A, the team found a web application still running with default credentials on several built-in accounts. That gave them the ability to send email from an internal address, which is about as convincing a sender as a phishing email can have. Four workstations later, they were inside.

At Organisation B, the approach was more ordinary. The team collected employee email addresses from public websites and sent spear phishing messages. Three people clicked a malicious link, and the team had three workstations.

In both organisations, a well-crafted email persuaded people to click. CISA does not present that as the failure. The advisory is about what happened next.

Two minutes, ten minutes, twenty minutes

At Organisation B, each of the three payloads triggered the same medium-severity alert when it ran: an executable file had loaded an unexpected DLL. Not a critical alert, just a middling one of the sort most security teams see many times a day.

Analysts triaged all three and manually isolated the affected workstations within ten minutes, two minutes and twenty minutes. That cut the red team's command and control connections and removed their foothold entirely. The engagement could only continue because Organisation B's own IT staff, who knew the assessment was happening, then ran a payload on a designated host so the exercise could proceed under an assume breach model.

The same class of activity, on the same day, produced no response at all at Organisation A. Their security operations centre did receive medium and low severity endpoint alerts tied to the red team's work. Nobody actioned them.

Why the alerts went nowhere

CISA is specific about the reasons, and none of them are about individual analysts being careless.

The first is noise. Organisation A had not tuned its detection tooling against a baseline of normal activity, so thousands of false positives generated by routine business operations were flowing through the queue, many of them rated more severe than the genuine intrusion. The real signal was there. It was indistinguishable from everything else.

The second is structure. Organisation A ran multiple security operations centres with multiple endpoint detection products. Staff in one centre did not talk to staff in another and could not see each other's tooling. Analysts did not talk to the people who owned the systems they were monitoring. In one exchange the red team observed, defenders investigating an alert on an endpoint management server tried to establish who owned the system and what it was for, could not find out, and closed it as a false positive.

The third is authority. CISA found that analysts had no standard operating procedures for escalating an alert and limited personal authority to act, so they defaulted to what the advisory calls a "wait and see" approach. Organisation B's staff, by contrast, were able to quarantine a machine on their own judgement and did so three times in under half an hour.

The consequence at Organisation A was severe. Having compromised a cloud application with permission to read and write mail across the tenant, the red team pulled security staff emails to check whether anyone had noticed. They also moved onto analysts' own workstations, captured screenshots, ran keyloggers and retrieved Teams messages.

The gap both organisations shared

Organisation B comes out of this well, and the advisory is careful not to make it a hero. Both organisations were caught by the same cloud problem: applications holding far more permission than they needed, and no process for revoking access or refresh tokens after a compromise.

Neither had implemented Conditional Access for workload identities, which extends access policy to the service principals that applications use. CISA notes that its red team has never observed an organisation using it. Both also left credentials sitting in plain text where a determined attacker would look for them, including in configuration files and, at Organisation B, in an XML file on a software distribution point. Our earlier piece on identity attacks in cloud environments covers why this matters once someone is already inside.

What this says about human risk

The comfortable reading of a phishing incident is that it happened because someone made a mistake. This advisory makes that reading hard to sustain. People clicked in both organisations. The difference in outcome came entirely from what the organisation was able to do in the following twenty minutes.

The UK's National Cyber Security Centre has argued this for years in its guidance on defending your organisation against phishing, which is blunt that no training package can teach every user to spot every phishing email, and that punishing people for clicking discourages the reporting you actually depend on. Its worked example is a financial services firm that received 1,800 emails carrying Dridex malware. Filtering stopped 1,750 of them. Of the 50 that reached inboxes, 36 were ignored or reported, 14 were clicked, and 13 of those failed to run because the devices were patched. One infection succeeded. Its call home was detected, reported and blocked, and the machine was cleaned within hours.

That is the shape of a working defence. Every layer leaks, and none of them has to be perfect.

Practical steps that follow from CISA's findings:

• Tune before you buy more. Establish a baseline of normal activity and filter routine business behaviour out of the alert queue. A detection nobody can find is not a detection.
• Give defenders the authority to act. Write down who may isolate a machine, block traffic or disable an account without seeking approval, and who they escalate to when they cannot.
• Keep system ownership records current. If an analyst cannot establish what a server does or who runs it, the ticket gets closed.
• Measure reports, not only clicks. Speed of reporting is the number that changed the outcome here. Building a culture where people report quickly does more than driving click rates towards zero ever will.
• Audit application permissions and token revocation. Review what your cloud applications can reach, remove what they do not need, and rehearse revoking tokens as part of incident response.
• Get credentials out of files. Plain text passwords in configuration files and shared drives turn a single clicked link into domain compromise.

The bottom line

Two organisations faced the same tradecraft on the same day. In both, phishing worked. In one, three medium-severity alerts were read, believed and acted on within twenty minutes, and the attackers lost their access. In the other, the same evidence sat unread in a queue while the attackers watched the security team through their own screens.

The lesson is not that the second organisation had worse people. It is that detection tools only work through the people, processes and permissions around them. Staff sit in that chain twice over, as the ones who click and as the ones who raise the alarm. Equipping them to do the second is where the return sits.

Phishing Tackle offers the tools businesses need to strengthen their human risk strategies, with multi-platform testing, real-time behavioural insights, and actionable data to keep your organisation ahead of modern cyber threats.

Contact us today to learn how Phishing Tackle can help safeguard your organisation from the growing array of cyber risks.