20.8 Red vs Blue, Project and Real Incidents

Real incident: Equifax breach (2017)

In 2017, attackers exploited an unpatched Apache Struts vulnerability (publicly tracked as CVE-2017-5638) on an Equifax internet-facing dispute portal. Public US government reporting (including GAO) describes failures around identifying the vulnerable system, circulating the US-CERT patch alert on an outdated recipient list, and a scan that did not flag the portal – so the Critical web-app CVE stayed open while attackers later moved deeper and accessed large volumes of personal data (Equifax and GAO reported impact on the order of over 140 million individuals). Weakness: missing patch + incomplete asset inventory + weak detection on a public web application. What would have reduced it: timely Critical patching, accurate inventory of internet-facing apps, verified vulnerability scans that catch the real host, segmentation, and monitoring. Lab lesson: scanners and CVE lookups only help if Blue triages and patches – and never leaves a weak assessment target on a bridged LAN. Source: U.S. GAO report GAO-18-559; Equifax public statements; NVD entry for CVE-2017-5638 (verify current docs).

Real incident: WannaCry ransomware wave (2017)

In May 2017, WannaCry spread widely as ransomware that also wormed across networks by abusing unpatched Windows SMB (EternalBlue-class issues addressed in Microsoft’s MS17-010 bulletin). Reported disruption included many organisations worldwide and major impact on parts of the UK NHS where systems were unpatched or poorly segmented. Weakness: wormable OS/network vulnerability left unpatched + flat networks. What would have stopped / reduced it: apply available OS patches, disable unnecessary SMBv1, block SMB at the edge, segment critical networks, and keep offline backups. Lab lesson (different from Equifax’s web-app CVE): inventory must cover servers and OS services; re-scan after patching to prove High/Critical findings close. Source: Microsoft security blog on WannaCrypt; UK NAO investigation of WannaCry and the NHS; CISA alerts (verify current advisories).

Real incident: FBIJobs portal – ShinyHunters / Oracle PeopleSoft (Sept 2026)

1. What happened In late September 2026, multiple outlets reported that the FBI declared a cyber security incident after a breach of its FBIJobs.gov job-application portal. Reporting described theft of employees' and applicants' personal data (names, addresses, job titles, Social Security numbers; some outlets also described medical-related records in circulated samples). The group ShinyHunters claimed the intrusion. Treat published claim sizes as reported – do not invent record counts.

2. How the hack happened (public reporting only – high-level) 1. Attackers targeted the bureau's public job / HR applicant portal (an internet-facing enterprise application). 2. Per TechCrunch reporting of the group's claims, they abused a vulnerability in Oracle PeopleSoft hosting HR and applicant data (not a "jobs site is safe" assumption). 3. Once inside that application tier, they accessed stored personal and (per later media) sensitive HR/medical-related records tied to agents and applicants. 4. Samples and claims were circulated; the group told TechCrunch they sought a policy/advisory correction, not a classic financial ransom. 5. The FBI later notified staff internally that a cyber security incident had been declared and that PII such as SSN, address, and job title was exposed.

3. How to stop it / defend (this chapter: vulnerability scanning) - Inventory every internet-facing app (HR, applicant, PeopleSoft-class portals count). - Scan with OpenVAS/Nmap vuln scripts; triage Critical/High on public hosts first (CISA KEV style priority). - Patch or take offline; re-scan to prove the finding closed – raw scanner dumps are not remediation. - Segment HR/applicant data; least privilege on app service accounts; monitor unusual bulk exports from HR DBs.

4. How to take care so it won't happen again (checklist) - [ ] Asset list includes every public portal and its software version. - [ ] Patch SLA for Critical internet-facing CVEs (same week, not "next release"). - [ ] Vulnerability scan + owner named for every Critical finding. - [ ] Re-scan evidence attached to the ticket before closing. - [ ] Staff PII breach playbook: notify, monitor identity misuse, rotate related credentials.

Source: TechCrunch, Zack Whittaker, 28 Sept 2026; Nextgov/FCW and CyberScoop (late Sept 2026).

Real incident: Citrix NetScaler zero-days CVE-2026-88771 / CVE-2026-88772 (Sept 2026)

1. What happened In late September 2026, Citrix disclosed critical flaws in NetScaler ADC and Gateway, including CVE-2026-88771 and CVE-2026-88772. CISA added both to its Known Exploited Vulnerabilities (KEV) catalog and warned that threat actors were actively exploiting them globally. Mandiant / Google Threat Intelligence and GreyNoise reported real-world use against internet-facing NetScaler appliances in North America and Europe (government, finance, education, legal, professional services as reported). Post-compromise activity described in public reporting included web shells, tunneling tools, credential theft, and movement toward internal networks. Treat sector lists and malware names as reported – do not invent victim counts.

2. How the hack happened (public reporting only – high-level) 1. Attackers targeted internet-facing NetScaler ADC / Gateway appliances (edge VPN / ADC devices that often sit in front of internal apps). 2. They abused unauthenticated remote-code-execution class flaws (CVE-2026-88771 improper input validation; CVE-2026-88772 memory overflow when DTLS is enabled – DTLS is commonly on for VPN virtual servers). 3. Exploitation gave root-level control on the appliance OS (as described by Mandiant / GreyNoise public write-ups). 4. Operators installed persistence (custom PHP web shells; config tricks so ordinary-looking requests hit shells) and tunneling malware tracked publicly as WHIPSHOT / SLAPSHOT, then used that foothold for reconnaissance and credential theft toward the internal network. 5. GreyNoise observed exploit attempts before public CVE disclosure (zero-day window); Citrix then shipped patches and CISA / NCSC / NHS Digital amplified the urgency.

3. How to stop it / defend (this chapter: vulnerability scanning) - Inventory every internet-facing edge appliance (NetScaler ADC/Gateway counts the same as a public web portal). - Treat CISA KEV Critical CVEs as same-week priority – not "next maintenance window". - Apply Citrix fixed builds (as of the advisory: 14.1-73.37+, 13.1-64.23+, and matching FIPS/NDcPP fixed trains; EOL 12.1/13.0 need migrate). - Before patching if compromise is suspected: hunt IoCs (Citrix Console / Mandiant / GreyNoise guidance), preserve evidence – updates can erase forensic visibility. - Temporary mitigations for one CVE (e.g. disable DTLS / block UDP/443 when not required) do not cover both flaws – patch is the real fix. - Re-scan / re-verify appliance version and exposure after change; document proof like any other Critical finding.

4. How to take care so it won't happen again (checklist) - [ ] Asset list includes every public VPN/ADC appliance + exact build version. - [ ] Subscribe to vendor + CISA KEV alerts for edge gear (not only "web apps"). - [ ] Patch SLA: Critical internet-facing / KEV = emergency change, with IoC hunt first when exploitation is reported. - [ ] Segment: compromised edge device must not equal full internal admin access. - [ ] Tabletop: "unpatched edge appliance" – isolate, preserve, patch, credential rotate, re-scan.

Source: CISA Alert, 27 Sept 2026 (KEV for CVE-2026-88771 / CVE-2026-88772); Citrix Security Bulletin CTX697096; BleepingComputer, Lawrence Abrams, 29 Sept 2026 (Mandiant / GreyNoise detail); UK NCSC alert 28 Sept 2026; NHS England Digital CC-4858.

Real incident: Warlock ransomware via SharePoint ToolShell (2025–2026 reporting, Oct 2026)

1. What happened In reporting dated 2 October 2026, BleepingComputer described the China-linked ransomware group Warlock targeting a water utility, a telecom provider, a regional government body, and a university. Initial access came through on-premises Microsoft SharePoint vulnerabilities. Public reporting said the gang has focused recently on Portuguese- and Spanish-speaking countries across Europe, Africa, and Latin America. The group emerged around June 2025 and gained notoriety abusing the SharePoint ToolShell vulnerability chain (CVE-2025-49704, CVE-2025-49706, CVE-2025-53770, CVE-2025-53771). Symantec identifies the same actor as Longlegs and attributes Warlock ransomware development to that group. Treat sector lists and host counts as reported – do not invent victim totals. Educational framing only.

2. How the hack happened (public reporting only – high-level) 1. Attackers targeted internet-facing on-prem SharePoint servers still exposed to known ToolShell-class flaws (more than a year after disclosure, researchers warn these remain viable). 2. After SharePoint access, operators dropped a web shell across SharePoint versions (as described in public write-ups – no exploit detail here). 3. In one intrusion starting 22 July, they performed reconnaissance, deleted staging artifacts about two days after initial access, and later staged the ransomware payload in domain SYSVOL (so it could replicate across domain controllers / GPO-style distribution). 4. They used common post-compromise tooling as reported: NetExec for Active Directory enumeration, credential spraying, and remote command execution; VS Code Insiders main executable installed as a service for remote tunneling. 5. Some attacks used AV/EDR-killing via a bring-your-own-vulnerable-driver (BYOVD) path with a signed K7RKScan driver tied to CVE-2025-1055. In the July case, a tool disabled protection on at least 40 hosts within about two hours; on 31 July, after that kill step, Warlock launched on at least 33 hosts almost as soon as protection was down.

3. How to stop it / defend (this chapter: vulnerability scanning) - Inventory every internet-facing Microsoft SharePoint (and related IIS) host – same urgency as a public VPN or HR portal. - Prioritise ToolShell / SharePoint CVEs on CISA KEV-style lists; patch or take offline the same week, not "next release". - Re-scan after patching to prove Critical findings closed; raw scanner output is not remediation. - Segment SharePoint from domain controllers; least privilege on service accounts; alert on unexpected SYSVOL writes and new services that look like remote-tunnel helpers. - Keep EDR/AV tamper protection on; watch for BYOVD / unexpected signed-driver loads that disable security tools. - Hunt web shells and unusual SharePoint process behaviour before assuming a version bump cleaned the box.

4. How to take care so it won't happen again (checklist) - [ ] Asset list includes every public SharePoint URL + exact build / CU level. - [ ] Patch SLA: Critical internet-facing SharePoint / ToolShell-class = emergency change. - [ ] Vulnerability scan + named owner for every Critical finding; re-scan proof before closing the ticket. - [ ] Monitor SYSVOL, new scheduled tasks/services, and EDR disable events on domain-joined hosts. - [ ] Tabletop: "unpatched SharePoint → ransomware" – isolate, preserve evidence, credential rotate, re-scan.

Source: BleepingComputer, Ionut Ilascu, 2 October 2026 (Warlock ransomware / SharePoint ToolShell reporting; Symantec Longlegs attribution as cited there).