Executive summary
September's reporting linked exposed enterprise applications with continuing abuse of legitimate identity and remote-support workflows, documented by the UK National Cyber Security Centre, Google's PeopleSoft investigation and Microsoft's helpdesk-impersonation analysis. The US Cybersecurity and Infrastructure Security Agency recorded 43 September additions to its Known Exploited Vulnerabilities catalogue. These sources describe distinct campaigns and should not be read as a single actor's activity. Likely (B2), remediation that combines patching with investigation of credentials, sessions and downstream access will address more of the documented risk than closing the original entry point alone; this is our assessment of the reported post-compromise behaviour.
The month in numbers
| Measure | September result | Definition and source |
|---|---|---|
| Known Exploited Vulnerabilities (KEV) additions | 43 | Records with September dateAdded values in CISA's 30 September catalogue snapshot |
| National Vulnerability Database (NVD) publications | 15,074 | The public NVD publication-date query for September returns this totalResults value |
| The Gentlemen postings counted | At least 105 | September Discovered entries on ransomware.live's group page |
| Qilin postings counted | At least 74 | The same date filter on Qilin's page |
| Cl0p postings counted | At least 2 | The same date filter on Cl0p's page |
The three leak-site rows represent at least 181 postings counted here. They are criminal claims, not confirmed breaches, unique organisations or a complete market total. Only these three group pages were enumerated for this selection. The small Cl0p count is a result for the visible dated rows, not evidence that the group conducted only two intrusions. Discovery dates also differ from estimated attack dates; the latter were excluded from this calculation.
The KEV calculation filters the historical catalogue by addition date, preserving what its fields said at month end. The NVD calculation uses an inclusive UTC publication range from 1–30 September. Both NVD and leak-site figures are retrospective counts of records dated in the period, not a claim about the complete information available to defenders on every day of the month. None of these counts measures local exposure. Keep vulnerability disclosure volume, exploitation evidence and asset applicability in separate columns when deciding work priorities.
Theme one: an edge-device patch was only part of containment
The NCSC's 28 September NetScaler alert identifies CVE-2026-88771 and CVE-2026-88772 as actively exploited. It distinguishes the first vulnerability's input-validation flaw from the second's memory-boundary weakness. Its guidance couples vendor updates with investigation and continued hunting, and warns that isolation or replacement can cause service disruption.
Mandiant and Google Threat Intelligence Group's 29 September investigation reports observed exploitation of CVE-2026-88772 and attributes exploitation of CVE-2026-88771 to vendor disclosures. Mandiant describes modified web-server handling, PHP web shells and a Python tunneller used for internal access. It recommends assessing both members of redundant appliance pairs, coordinating credential and session recovery, and looking beyond the appliance for lateral movement. Its temporary Datagram Transport Layer Security restrictions are specific to CVE-2026-88772 and do not mitigate both flaws.
Our recommended incident record should separate four questions. Was the appliance vulnerable during exposure? Is there evidence that it was compromised? Which identities and internal services were accessible from it? What evidence supports restoration of trust? A successfully installed update answers only the first question going forward. Do not let a maintenance ticket close the investigation by default.
Assign ownership of service continuity before deciding whether to isolate an appliance. Record the chosen containment measure, its scope and its limitations. Preserve relevant evidence while coordinating the recovery sequence with the vendor and incident-response team. Where paired systems synchronise configuration, validate each member separately before allowing the restored pair to resume normal operation. These are response-planning recommendations grounded in the reported persistence and lateral-access risks, not a claim that every exposed appliance was compromised.
Theme two: support workflows became an intrusion path
Microsoft's 2 September helpdesk-impersonation report describes external Microsoft Teams contacts persuading users to allow remote support. The reported chain installs a malicious package, runs a JavaScript implant through a legitimate Node.js runtime and progresses towards internal identity infrastructure. Microsoft explicitly describes abuse of collaboration features and users overriding warnings, rather than a technical vulnerability in Teams. Its analysis also distinguishes dormant blockchain-based discovery code from the command infrastructure actually used by the recovered implants.
For defenders, our recommendation is to correlate the support interaction with subsequent endpoint behaviour. Investigate an unexpected support session followed by installer execution, a new runtime in a user-writable location and remote administration towards sensitive servers. The sequence and authorisation context matter more than the presence of Node.js or a support tool in isolation. Document the legitimate helpdesk case and initiating identity before deciding that the session was expected.
The same principle applies to authentication approvals. Microsoft's 22 September EvilTokens report describes abuse of device-code authentication to obtain account access, with stolen tokens used for mailbox access and persistence. Microsoft reports more than 12,000 compromised inboxes across over 10,000 organisations in the platform's activity; these are its broader observations, not a September-only total. It recommends restricting device-code flow to necessary uses and warns that session revocation can leave an access-token window, requiring additional containment decisions.
We recommend testing recovery with a controlled account and an agreed success criterion: the unwanted access should fail, the relevant grants and sessions should be reviewed, and mailbox changes should be investigated. A password reset confirmation is insufficient as the sole test. Exceptions for legitimate device flows should have a named business owner and a defined scope, with the resulting sign-ins distinguishable in monitoring.
Theme three: temporary mitigations needed revalidation
In its 25 September PeopleSoft update, Mandiant and Google report renewed mass exploitation by UNC6240, which they identify as ShinyHunters. The researchers describe modified requests bypassing some path-based web application firewall rules on systems that remained unpatched. They report expanded targeting across multiple sectors and web shells on dozens of systems. Their guidance stresses patching, appropriate handling of the Environment Management Hub component, review of all relevant nodes and rotation of credentials accessible from the application tier.
The report covers both file-based persistence and command execution without creating a web-shell file. Accordingly, the absence of a known filename is not a complete exclusion test; that is our assessment of the two reported execution paths. The review should include process and access evidence as well as files. Keep observations and uncertainty separate, especially when logs do not cover the full exposure interval.
For every emergency mitigation, we recommend maintaining an expiry or review date and a record of the exact assumption it relies on. Assign someone to verify whether the application, proxy and security control interpret requests consistently, using safe vendor-supported validation. A rule's installation time is not evidence that it blocked all relevant requests. Once the vendor fix is deployed, confirm the deployment across the actual service population before retiring compensating controls.
An application team should also define what the service identity could read. That inventory determines the credential and data investigation after compromise. It should include connected databases and integration accounts, while avoiding an unsupported assumption that every accessible secret was stolen. Record exposure separately from confirmed access and confirmed exfiltration. These distinctions improve both incident decisions and later notification assessments.
Theme four: criminal objectives extended beyond encryption
Google's 1 September BREEZE COMET report describes financially motivated intrusions into Brazilian organisations and payment infrastructure. It reports theft of credentials needed to interact with financial systems, activity across development and cloud environments, and fraudulent transfers. The underlying investigations began before September. Google's suggestion that infrastructure could support wider geographical targeting is an assessment of intent, not proof of a completed expansion.
Our recommendation for payment operators is to review the path from an administrative account to a transaction-capable identity. The exercise should identify who can retrieve or replace application credentials, approve changes to payment integrations and access the systems that issue or verify transactions. Security and fraud teams should agree which observations trigger a joint investigation. Avoid waiting for encryption when the suspected objective is manipulation of financial activity.
Microsoft's 24 September Storm-2570 analysis describes consistent remote-management, discovery, credential-access and exfiltration behaviour across deployments of different ransomware families. Microsoft explicitly says the initial-access method remains unconfirmed. That uncertainty should remain visible; the article does not support attributing every intrusion to a particular exploit or phishing lure.
For detection engineering, we recommend modelling the recurring pre-impact sequence independently of the final ransomware name. Start with unauthorised remote-management installation, changes to security controls and abnormal movement towards privileged systems. Validate each analytic against legitimate administrative work before deployment. When those events combine, investigate them as a possible active intrusion without requiring a known encryptor hash.
Actors of the month
The sources use different scopes. BREEZE COMET is Google's actor designation for the financial intrusions it describes. Storm-2570 is Microsoft's tracked ransomware activity. Google's PeopleSoft report links UNC6240 with ShinyHunters. None of those relationships establishes links between the separate groups, and this review does not infer shared sponsorship or personnel.
The NCSC's 15 September CHOSEN BRICK announcement addresses another threat model: Iranian state actors targeting dissidents, activists and journalists through tailored social engineering and spyware. The NCSC describes collection of communications and device information and recommends dedicated support for people at risk. This is an official attribution, not an inference from a victim list. It also shows why a corporate ransomware exercise alone is insufficient preparation for organisations supporting high-risk individuals.
The vulnerability landscape
The historical KEV catalogue contains these selected additions among September's 43 records.
| Date added | Product | Identifier or identifiers |
|---|---|---|
| 2 September | JFrog Artifactory | CVE-2026-82329 |
| 11 September | GitLab Community Edition and Enterprise Edition | CVE-2026-85706 |
| 27 September | Citrix NetScaler | CVE-2026-88771 and CVE-2026-88772 |
| 30 September | Cisco Catalyst SD-WAN Manager | CVE-2026-76504 |
All 43 September entries have Unknown in the historical known-ransomware-use field. Unknown is not a negative finding. Keep the catalogue snapshot with the triage record so later enrichment cannot be mistaken for knowledge available at the earlier date.
For NetScaler, the NCSC alert lists affected supported tracks as follows. These thresholds must be read with the vendor's full advisory and the deployment's precise track.
| Track | Affected versions listed by NCSC |
|---|---|
| NetScaler ADC and Gateway 14.1 | Before 14.1-73.37 |
| NetScaler ADC and Gateway 13.1 | Before 13.1-64.23 |
| NetScaler ADC 14.1 FIPS | Before 14.1-73.37 FIPS |
| NetScaler ADC 13.1 FIPS and NDcPP | Before 13.1-37.279 |
The special tracks should not be dropped from an inventory check simply because standard builds share a similar version prefix. Our recommendation is to obtain the appropriate vendor build for each track and retain evidence of the running version after the change.
The ransomware landscape
The counted leak-site postings describe a limited public view of extortion. They cannot establish which ransomware family executed, whether data was taken, whether a payment occurred or when access began. Microsoft's Storm-2570 report offers a separate, incident-based view of activity before impact. Keep these evidence types apart: a public claim is useful collection material, while observed intrusion telemetry supports a different class of finding.
We recommend testing recovery of identity and remote administration alongside restoration of business data. Give the exercise team an explicit question about access left behind: which sessions, accounts, support agents or application integrations could still be used after the primary host is rebuilt? Require documented checks, with gaps carried forward rather than converted into a clean finding.
Policy and law enforcement
Microsoft says its Digital Crimes Unit and partners coordinated disruption of EvilTokens infrastructure in the 22 September publication. This is a specific disruption report, not proof that the wider device-code phishing threat has ended. The NCSC's CHOSEN BRICK announcement connects technical compromise with the personal-safety concerns of targeted communities.
Our recommendation is to assign a response owner for high-risk individuals as well as corporate services. Make support routes usable from a trusted device and avoid exposing sensitive details through the account being investigated. This is practical preparedness advice; this review does not attempt a comprehensive statement of September's regulatory changes or jurisdiction-specific reporting obligations.
What to watch: assessment
Likely (B2), the most consequential follow-up work will remain outside the patched component when an intrusion has already obtained credentials or internal access. This judgement draws on Mandiant's NetScaler and PeopleSoft investigations and Microsoft's identity reporting. It is conditional on compromise and does not mean every organisation running an affected product has suffered an intrusion.
The next collection priorities should therefore be evidence of reused access after remediation, newly discovered unauthorised application grants, and compromise extending to internal administration systems. For unconfirmed cases, document the coverage period and available telemetry before declaring the search complete. Revisit temporary mitigations when either the vendor guidance or the observed attack method changes.
September briefings
The companion weekly reporting periods are listed below. The monthly analysis groups the evidence by defensive problem; the weekly series follows the chronology.
- Weekly threat briefing: 31 August–6 September 2026.
- Weekly threat briefing: 7–13 September 2026.
- Weekly threat briefing: 14–20 September 2026.
- Weekly threat briefing: 21–27 September 2026.
