SearchSubscribe

P.K. SHARMA

Cyber security intelligence, AI governance, practitioner analysis

Threat Intel

Symantec says Warlock attacked a water utility and a telecom, and names no 2026 SharePoint flaw

Symantec and Carbon Black describe one Warlock intrusion that went from a web shell on a SharePoint server to ransomware on at least 33 hosts in nine days, yet name no 2026 flaw. Patch level, and whether machine keys were stolen, decide your exposure.

By Parminder Kumar Sharma · · 22 min read

Editorial illustration for the briefing: Symantec says Warlock attacked a water utility and a telecom, and names no 2026 SharePoint flaw

Nine days, and no CVE named

On Wednesday 22 July 2026 a web shell was written to a SharePoint server at a critical infrastructure operator. By Friday 31 July, the report says, Warlock had been deployed on at least 33 hosts in the same network, with ransomware binaries and a ransom note recorded on them. That is nine days, counted from the dates in the one intrusion that the Symantec and Carbon Black report of 1 October 2026 describes in full, and the report does not say which SharePoint flaw opened the door.

It names four SharePoint CVEs, all from 2025, as the chain that made the group notorious. It says those flaws "likely remain in the group's arsenal, alongside newer SharePoint flaws", and points to a CISA advisory without naming one of the newer ones. Dark Reading reports that Symantec could not say whether the group still uses the 2025 chain or newer flaws.

What this does not establish. It does not establish which of the four victims was the one described, or that the same flaw was used against the other three. It names no victim and no country, and it does not mention the UK. It does not say whether any files were encrypted: the report records ransomware binaries and a ransom note and never uses the word. It does not say whether data was stolen, what was demanded, or whether any water or telecom service was disrupted. It does not show that a state directs the group: "China-nexus" is Symantec's assessment of the actor behind the ransomware, and the sources differ on what that means. And it cannot tell you whether your servers are exposed. That depends on a build number you can read in a minute and a hunt that takes longer.

A timeline drawn to scale from 14 July to 11 August 2026. Microsoft publishes four SharePoint CVEs on 14 July. Eight days later, on 22 July, a web shell is written to a SharePoint server. Six numbered events follow, ending in the early hours of 31 July with a security-tool killer on at least 40 further hosts and ransomware binaries on at least 33, nine days after the web shell. Microsoft fixes CVE-2026-65660 on 11 August, 20 days after the web shell.
Drawn from the Symantec and Carbon Black report of 1 October 2026 and Microsoft security update dates. Day counts are derived.

What the report is, and what the headlines made of it

The primary source is a ten-minute read from the Threat Hunter Team at Symantec and Carbon Black, part of Broadcom, published on 1 October 2026. Its subject is a threat actor, not a piece of malware. Symantec calls the actor Longlegs, says it is also tracked as Storm-2603, the name Microsoft gave it in July 2025, and says it develops the Warlock ransomware.

BleepingComputer's story of 2 October, which is how many readers will have met it, is headlined "Warlock ransomware breach SharePoint in water, telecom operator attacks" and opens by calling Warlock a "China-linked ransomware group". Dark Reading's headline of 1 October says Warlock hits "large" organisations. The report gives no size for any victim. Both stories are pointers; neither adds a fact the report lacks, apart from the Dark Reading interview with a Symantec analyst, which is quoted below.

We read the Symantec report in full twice, once through a scripted fetch and once in a real browser, and the text matched. BleepingComputer and Dark Reading answer scripted fetches with a block, so we read them in a normal browser session and did not try to get round the block.

What Symantec and Carbon Black's report of 1 October 2026 states and leaves out, read in full on 3 October 2026.

  1. Question
    How many victims
    The report states
    At least four organisations in the past two months
    The report does not state
    The total; whether the four are the only ones; when the other three were attacked
  2. Question
    Who they are
    The report states
    A water utility, a telecom provider, a regional government body and a university
    The report does not state
    Names, sizes or countries; whether the detailed intrusion was the water utility or the telecom provider
  3. Question
    Where
    The report states
    Portuguese- and Spanish-speaking countries across Europe, Africa and Latin America
    The report does not state
    Any country by name; how many are in Europe; any mention of the UK
  4. Question
    How they got in
    The report states
    Likely exploitation of on-premises SharePoint flaws; a web shell on 22 July 2026
    The report does not state
    Any 2026 CVE; the victims' patch levels; whether any flaw was unfixed at the time
  5. Question
    What happened
    The report states
    In one intrusion: a security-tool killer on at least 40 further hosts in about two hours, then ransomware binaries and a ransom note on at least 33 hosts
    The report does not state
    Whether any files were encrypted or lost; whether the other three were hit the same way; any data theft, leak-site claim, ransom demand or payment; any service disruption
  6. Question
    Who
    The report states
    A China-nexus actor, Longlegs, also tracked as Storm-2603, that develops Warlock
    The report does not state
    A confidence level in this report; state direction; whether others deploy Warlock
  7. Question
    Indicators
    The report states
    19 file hashes and 2 network indicators
    The report does not state
    A hash labelled as the web shell; IP addresses; the SharePoint request pattern; the driver used in this intrusion

Method and accusation. The technical sections are detailed and the indicator list is usable. It is also a vendor publication. Its protection section describes Symantec's own XDR product, and its victim count is what Symantec saw, not what the group did. "At least four" is a floor from one company's visibility.

For scale only: Check Point reported that Warlock had reached 43 leak-site listings in the third quarter of 2025. That is a different measure over a different period and cannot be compared with Symantec's four, but it is a reminder that four is not the size of the group's activity.

Is this the SharePoint flaw from the earlier briefings?

No source says so, and the dates argue against it for the one intrusion that has dates. The earlier briefings here covered CVE-2026-65660: published on 11 August as a 6.5 spoofing flaw and relabelled as remote code execution at 8.8 on 27 August, then added to CISA's Known Exploited Vulnerabilities catalogue on 25 September. It is not named in the Symantec report. It is not among the six CVEs in the CISA alert that the report links. And Microsoft fixed it on 11 August, 20 days after the web shell of 22 July. Unless it was used before its fix, which no source says, it cannot be how that intrusion began. For the other three victims there are no dates at all.

What the report does give is two lists of candidates, shown below. It names the first four rows. It links to a CISA alert whose latest version lists the next six. The last row is the flaw from the earlier briefings, for comparison.

Candidate SharePoint flaws. Sources: Symantec report, CISA alert (last revised 26 August 2026), CISA KEV catalogue 2026.10.02, Microsoft security update data. Days before 22 July 2026 are derived.

  1. CVE and who names it
    CVE-2025-49704 (Symantec)
    Microsoft fix, and days before 22 Jul 2026
    8 Jul 2025, 379 days
    KEV added, ransomware flag
    22 Jul 2025, Known
  2. CVE and who names it
    CVE-2025-49706 (Symantec)
    Microsoft fix, and days before 22 Jul 2026
    8 Jul 2025, 379 days
    KEV added, ransomware flag
    22 Jul 2025, Known
  3. CVE and who names it
    CVE-2025-53770 (Symantec)
    Microsoft fix, and days before 22 Jul 2026
    20 Jul 2025, 367 days
    KEV added, ransomware flag
    20 Jul 2025, Known
  4. CVE and who names it
    CVE-2025-53771 (Symantec)
    Microsoft fix, and days before 22 Jul 2026
    20 to 21 Jul 2025, 366 to 367 days
    KEV added, ransomware flag
    Not in KEV
  5. CVE and who names it
    CVE-2026-32201 (CISA alert)
    Microsoft fix, and days before 22 Jul 2026
    14 Apr 2026, 99 days
    KEV added, ransomware flag
    14 Apr 2026, Unknown
  6. CVE and who names it
    CVE-2026-45659 (CISA alert)
    Microsoft fix, and days before 22 Jul 2026
    May 2026 update (12 May), 71 days; CVE published 21 May
    KEV added, ransomware flag
    1 Jul 2026, Known
  7. CVE and who names it
    CVE-2026-58644 (CISA alert)
    Microsoft fix, and days before 22 Jul 2026
    June 2026 update (9 Jun), 43 days; CVE published 14 Jul
    KEV added, ransomware flag
    16 Jul 2026, Unknown
  8. CVE and who names it
    CVE-2026-56164 (CISA alert)
    Microsoft fix, and days before 22 Jul 2026
    14 Jul 2026, 8 days
    KEV added, ransomware flag
    14 Jul 2026, Unknown
  9. CVE and who names it
    CVE-2026-50522 (CISA alert)
    Microsoft fix, and days before 22 Jul 2026
    14 Jul 2026, 8 days
    KEV added, ransomware flag
    22 Jul 2026, Unknown
  10. CVE and who names it
    CVE-2026-55040 (CISA alert)
    Microsoft fix, and days before 22 Jul 2026
    14 Jul 2026, 8 days
    KEV added, ransomware flag
    18 Aug 2026, Unknown
  11. CVE and who names it
    CVE-2026-65660 (earlier briefings)
    Microsoft fix, and days before 22 Jul 2026
    11 Aug 2026, 20 days after
    KEV added, ransomware flag
    25 Sep 2026, Unknown

Read the table as candidates, not a finding. Symantec's analyst told Dark Reading that "the exploits for these more recent vulnerabilities behave quite similarly" to the 2025 chain. Whether that is why the report does not separate them is not stated, and it is not evidence about which was used.

Two details are easy to miss. First, ToolShell is a nickname for four CVEs, and the catalogue treats them differently: three are in KEV, each flagged Known for ransomware campaign use, and CVE-2025-53771, the spoofing flaw that bypasses the earlier fix, is not in the catalogue at all. A server is patched against CVEs, not against a nickname. Second, the ransomware flag reads Known on four of the eleven rows: the three ToolShell entries in KEV and CVE-2026-45659. CISA's flag says a flaw has been used in ransomware campaigns. It does not say Warlock.

The days column is the part a patch owner should keep. For the three flaws fixed on 14 July, the gap between fix and first web shell was eight days. For two of the 14 July entries, CVE-2026-56164 and CVE-2026-58644, Microsoft's record flags exploitation, and CISA catalogued them the same day and two days later. For anyone on a monthly cycle, patched in time meant patched within about a week. For the ToolShell flaws the same gap is 366 to 379 days. "We are patched" is a different claim in each row.

The report does not say the four victims were unpatched. Its significance section says the technique remains viable against SharePoint deployments "that have not been patched or otherwise mitigated", which is a statement about the technique, not a finding about these networks.

What each stage leaves for a hunter

The report is stronger on what happened after entry than on how entry happened. In the described intrusion the first observed activity was the web shell itself, so the exploit is inferred from it. Symantec's wording is that entry was "likely exploitation of vulnerabilities in Microsoft SharePoint Server", and that hedge is the report's own.

The table follows the one intrusion with dates, from the first web shell on 22 July to the ransomware on 31 July. Host counts are floors: "at least". File names, an account name and domains are published indicators, listed here so a hunter can search for them. No commands or payloads are reproduced.

The 22 to 31 July 2026 intrusion, stage by stage. Source: Symantec and Carbon Black, 1 October 2026. The right-hand column is this briefing's reading of what a defender can look for, not the report's advice.

  1. Stage
    Web shell, 22 Jul
    Observed in the report
    Written into the SharePoint LAYOUTS directory for several SharePoint versions at once, so it works whichever is installed. This one was named layout2sp.aspx.
    What it leaves for a hunter
    ASPX files in any LAYOUTS folder that are not part of the product; files written by the SharePoint worker process
  2. Stage
    Machine keys, by 28 Jul
    Observed in the report
    The web shell harvests the farm's ASP.NET machine keys. The attacker then forges a validly signed payload that runs code inside the SharePoint application pool. A repeated PowerShell command shows it on 28 Jul.
    What it leaves for a hunter
    Shells and PowerShell started by the worker process; the AMSI and Defender detections in CISA's alert; keys that stay valid until rotated
  3. Stage
    Recon and clean-up, 24 Jul
    Observed in the report
    Account and domain-trust discovery on a second SharePoint host. Numerically named files deleted from the Public and ProgramData folders. Executable and DLL pairs for side-loading dropped, one by the worker process.
    What it leaves for a hunter
    Discovery commands run by server accounts; the names doexe.exe, doexeloc.dll, ssvagent.exe and logger.exe; new executables in the numbered 0409 subfolder of the system folder
  4. Stage
    Test and fetch, 27 to 28 Jul
    Observed in the report
    A request to a subdomain of oastify.com that embeds the target's own domain name. Then msiexec installing three packages from catbox.moe and wasabisys.com subdomains within about 90 minutes.
    What it leaves for a hunter
    Server DNS and proxy logs for oastify.com; msiexec given a web address; the two network indicators
  5. Stage
    Spread, 28 to 29 Jul
    Observed in the report
    A domain account named SPSEPRDSetup added to local Administrators on three more hosts. VS Code Insiders installed as a tunnel service on one. NetExec run for directory enumeration, credential spraying and remote commands.
    What it leaves for a hunter
    Local Administrators changes; an account named like a SharePoint setup account; a service running code-insiders.exe; tunnel traffic from servers; many failed logons from one host
  6. Stage
    Defences down, 31 Jul
    Observed in the report
    A killer tool copied from an internal share and run on at least 40 further hosts in about two hours. The driver in this intrusion is unknown; K7RKScan was used in other recent attacks.
    What it leaves for a hunter
    Vulnerable driver loads; security services stopping on dozens of hosts within hours; a.exe in the public profile folder
  7. Stage
    Ransomware, 31 Jul
    Observed in the report
    run.exe and rune.exe and a note titled how to restore your files.txt recorded on at least 33 hosts. The payload was staged in the domain's SYSVOL share. The report does not say files were encrypted.
    What it leaves for a hunter
    See the diagram below

Patching does not evict. The machine-key step is the one a patch does not undo. Once a web shell has read the farm's keys, the attacker holds the material that makes forged requests look genuine, and installing an update does not change that material. Microsoft, the NCSC and CISA all treat stolen keys as something an update does not neutralise, which is why Microsoft's July 2025 guidance, the NCSC's alert of the same month and CISA's current alert all pair the update with a key rotation. CISA adds the part people skip: hunt for and remove machine-key harvesters before rotating, because a shell that is still there can steal the new keys. The Symantec report gives no such advice. Its protection section describes Symantec's product.

What the indicator list is. The report lists 19 file hashes, labelled as 5 Warlock, 6 malicious DLLs, 6 suspicious files, 1 AV and EDR killer and 1 vulnerable driver, plus 2 network indicators: litter[.]catbox[.]moe and xn8xyt-drop[.]s3[.]wasabisys[.]com. The body text also names a third cloud-storage path that is not on the list. There are no IP addresses, no hash labelled as the web shell, and nothing that would find the SharePoint request that came first. Hashes only find the exact files Symantec saw. In our judgement the behaviours in the table are the part most likely to repeat.

Four boxes with what each leaves for a hunter. The payload is staged in the SYSVOL scripts folder, then replicated to every domain controller and readable domain-wide. Protection is disabled on at least 40 further hosts in about two hours on 31 July, then ransomware binaries and a ransom note are recorded on at least 33 hosts. Not stated: when staging happened, how write access was gained, and which hosts were domain controllers.
Drawn from the Symantec and Carbon Black report of 1 October 2026. The hunting cues are this briefing's reading, not the report's advice.

A medium score on the step before the ransomware. The driver flaw named in the report, CVE-2025-1055 in K7 Security's K7RKScan.sys, shows how little a score says. NVD lists it at 5.6, medium, a score assigned by the CNA and not by NVD, on a vector of local access, high complexity and availability impact only. Its NVD analysis status is deferred, CISA's automated entry still carries the exploitation reading of none from 11 June 2025, and it is not in KEV. The report says the group has used it in other recent attacks to terminate protected security processes. A flaw can be medium on paper and still be the step that helps turn one compromised server into a domain-wide ransomware deployment.

Microsoft publishes a recommended driver block list and an attack surface reduction rule against vulnerable signed drivers. The page says the list is not guaranteed to block every vulnerable driver, and we could not confirm from it whether K7RKScan is on the list.

Three labels that do the thinking for you

"Critical infrastructure." The report says two of the four victims are critical infrastructure operators. Everything it describes is ordinary IT: SharePoint hosts, a Windows domain, endpoints. It says nothing about operational technology, plant control, supply, service disruption, or whether customers noticed. The label raises the stakes and tells a defender nothing to do. The advice for a SharePoint server at a water utility is the advice for one at a university.

"China-linked ransomware group." Each word carries a claim. BleepingComputer's phrase names the group Warlock, which merges a threat actor and a malware family: Symantec's actor is Longlegs, and Warlock is the ransomware it develops. Here is what each source says, in its own words where short.

What each source says about the actor behind Warlock, and what it leaves unsaid. Sources read on 3 October 2026.

  1. Source and date
    Microsoft, blog of 22 July 2025, updated 23 July
    What it says
    Storm-2603 is "assessed with moderate confidence to be a China-based threat actor". Microsoft had not identified links to other known Chinese actors, and could not confidently assess its objectives.
    What it does not say
    Does not call it state-directed; does not call it financially motivated
  2. Source and date
    Unit 42, 5 August 2025
    What it says
    High confidence that Storm-2603 is its cluster CL-CRI-1040, and that the cluster is financially motivated. "Do not have enough direct evidence" to attribute it to any nation-state or cybercriminal entity.
    What it does not say
    Cannot rule out state motivation or cooperation; could not yet link its ransomware to Warlock
  3. Source and date
    Symantec, 22 October 2025
    What it says
    Warlock "appears to be used by a group based in China". A stolen code-signing certificate links it to a group TeamT5 called CamoFei, which appeared to be Chinese and active since at least 2019. The people involved "may be contractors".
    What it does not say
    No confidence level; says crime is one of the group's core activities, not a sideline
  4. Source and date
    Symantec, 1 October 2026
    What it says
    A "China-nexus threat actor", tied earlier to CL-CRI-1040, CamoFei and ChamelGang.
    What it does not say
    No confidence level, no basis restated, no claim of state tasking
  5. Source and date
    BleepingComputer, 2 October 2026
    What it says
    A "China-linked ransomware group".
    What it does not say
    No actor name; no confidence level

"China-nexus" says there is a link to China, not that a government directs the group. The sources agree on that and on little else. Microsoft was unsure of the objectives, Unit 42 leaned financial, and Symantec suggests contractors who sell services to espionage clients and also run ransomware for income. None of the five is a government attribution, and the CISA alert on SharePoint names no actor. The method behind these links is overlap in tools, infrastructure and a certificate, which another analyst can test. The accusation, that a state runs the group, is one no source makes. For a risk register, record it as a vendor assessment, with the confidence where one is stated. In the 2026 report there is none.

"Patched." A status of a CVE on a date. The questions that matter are patched by when, and clean as of when. The first is answered by the days column above; the second by the machine-key hunt. A farm patched on 14 August is patched against all six CISA-listed flaws, and was open to the three fixed on 14 July for 31 days, through the whole of the 22 to 31 July intrusion. Patched says what is fixed from now on. It says nothing about who is already inside.

The UK: what is sourced and what is not

The report names no country and does not mention the UK. The recent victims are described as being in Portuguese- and Spanish-speaking countries, a description that does not fit the UK. It also says earlier Warlock activity was seen in a wider range of countries, "including the United States, Brazil, India, Russia, Taiwan, and Japan". The word "including" means that list is not complete, so the absence of the UK from it is not a finding either.

What is sourced for the UK is older and about the earlier flaws. The NCSC's SharePoint alert, published on 22 July 2025 for CVE-2025-53770 and CVE-2025-53771, said Microsoft and the NCSC had observed active attacks "including a limited number in the UK". Those two CVEs sit inside the ToolShell chain that Symantec says remains in Warlock's arsenal. The NCSC advised installing the updates, turning on AMSI, deploying endpoint protection and rotating the ASP.NET machine keys, and asked UK organisations that believe they are compromised to report to the NCSC. We found no NCSC alert for the 2026 SharePoint flaws; that is a statement about what we could find on 3 October, not about what the NCSC has done.

The NCSC's guidance on responding to active exploitation makes the point that matters for the first step of the checklist: organisations "may not even know they are running the affected software".

Check the build, not the ticket

Fixed builds from Microsoft's update data, read on 3 October 2026. The July row covers the April to July flaws in the candidate table; the August row is CVE-2026-65660.

  1. Product
    SharePoint Server Subscription Edition
    July 2026 build (KB)
    16.0.19725.20434 (KB5002882)
    August 2026 build (KB)
    16.0.19725.20522 (KB5002893)
  2. Product
    SharePoint Server 2019
    July 2026 build (KB)
    16.0.10417.20175 (KB5002883)
    August 2026 build (KB)
    16.0.10417.20198 (KB5002894, KB5002896)
  3. Product
    SharePoint Server 2016
    July 2026 build (KB)
    16.0.5561.1001 (KB5002891)
    August 2026 build (KB)
    16.0.5565.1001 (KB5002905, KB5002906)

Microsoft's data marks each of the April, May, June and July updates as superseding the previous month's, for all three products, so a farm at or above the July row carries the fixes for the six CISA-listed flaws. The 2025 ToolShell fixes are lower builds still: 16.0.18526.20508 for Subscription Edition, 16.0.10417.20037 for 2019 and 16.0.5513.1001 for 2016.

The build matters more than the ticket because two of the six fixes were not announced when they shipped. Microsoft's note on CVE-2026-58644 says the update was released but the CVE was "inadvertently left out of the June 2026 release", so the CVE appeared on 14 July, five weeks after the fix. CVE-2026-45659 was likewise omitted from the May release notes and published on 21 May. A process that waits for a CVE to appear before it patches would have been late on both.

SharePoint Server 2016 and 2019 passed the end of extended support in mid-July 2026. Briefing 73 reports Microsoft's SharePoint engineer saying that no further updates are planned, so for those two products the August builds are very likely the last, and the next flaw found will have no fix coming.

What to do, in order

For UK organisations that run on-premises SharePoint. The order matters: the hunt comes before the key rotation, and the hunt reaches beyond SharePoint.

Take this with you

Eleven steps, most urgent first

  • List every on-premises SharePoint server, including test farms, forgotten farms and servers reachable only internally.
  • Mark which farms are reachable from the internet. CISA advises against exposing SharePoint directly. Where that cannot be avoided it asks for an application-layer reverse proxy that enforces authentication and inspects every request.
  • Read each farm's build from Central Administration and compare it with the build table. For anything below the July 2026 build, treat the server as exposed to exploited CVEs and go straight to the hunt. For 2016 and 2019, write down that no further fixes are planned and put a date on migration.
  • Confirm AMSI integration is on for every web application, with full mode for request body scanning where the product allows it, and that Defender or an equivalent is running on the SharePoint servers. CISA lists its request body scanning detection as Subscription Edition only.
  • Hunt before you rotate. On each SharePoint server look for ASPX files in the LAYOUTS folders that are not part of the product, shells and PowerShell started by the worker process, the names and domains in the stage table, the 19 hashes and 2 network indicators in the report, and the AMSI and Defender detection names in CISA's alert.
  • Then rotate the ASP.NET machine keys and restart IIS on every SharePoint server, following Microsoft's guidance. Rotating first lets a surviving shell steal the new keys.
  • Widen the hunt past SharePoint: local Administrators changes and accounts that imitate SharePoint setup accounts, services running code-insiders.exe, DNS lookups for oastify.com and msiexec fetches from public file hosts on servers, and unexpected writes to the SYSVOL scripts folder.
  • Take SharePoint out of the domain's blast radius where you can. Run its service accounts with the least privilege that works, keep them out of privileged domain groups, limit outbound internet from SharePoint hosts to what the farm needs, and restrict who and what can write to SYSVOL. The NCSC publishes guidance on preventing lateral movement. This step is general hardening, not a finding of the report.
  • Make security tools hard to switch off: tamper protection in your endpoint product, Microsoft's vulnerable driver block list or an App Control policy, the attack surface reduction rule against vulnerable signed drivers, and an alert when security services stop on many hosts at once. In the report, at least 40 further hosts lost protection in about two hours.
  • Review backups for this scenario: keep at least one copy offline or immutable, check that backup systems cannot be reached with domain administrator credentials, and test a restore of both SharePoint and Active Directory. The report says nothing about backups or recovery, so this too is general practice.
  • If the hunt finds anything, treat it as an incident, preserve the evidence, and report it to the NCSC. If you have not yet signed up to the NCSC Early Warning service, do so.

The question this leaves

The report is careful. It says "likely", it says "at least", it says the victims were in certain language areas and stops there. The gap is not in the report. It is in the sentence a board will hear on Monday: Warlock is attacking critical infrastructure through SharePoint, are we patched?

That question has a yes that means very little. Patched against what, by when, and with stolen machine keys still valid? If your answer is a ticket, the ticket is the label. The evidence is a build number and a hunt result, and both can be produced this week.

So the question is not whether your SharePoint is patched. It is this: if a web shell appeared on one of your SharePoint servers tomorrow, what would tell you before day nine?

Key facts

Sources

  1. PrimaryPrimary source: Warlock Ransomware Attackers Hit Water and Telecom Operators, 1 October 2026. Read in full for victims, the 22 to 31 July intrusion chain, indicators and attribution wording.Symantec and Carbon Black Threat Hunter Team (Broadcom)accessed 2026-10-03
  2. PrimaryAlert: CISA Urges SharePoint Hardening After New Exploitations (first published 14 July 2026, last revised 26 August 2026). Six exploited SharePoint CVEs and hardening advice, including hunting before rotating machine keys.CISAaccessed 2026-10-03
  3. PrimaryKnown Exploited Vulnerabilities catalogue, version 2026.10.02. Used for KEV dates and the ransomware campaign use flag on each candidate CVE.CISAaccessed 2026-10-03
  4. PrimaryJuly 2026 security update document: CVE-2026-50522, 55040, 56164 and 58644 release dates, exploitation flags, fixed builds and revision notes.Microsoft Security Response Centeraccessed 2026-10-03
  5. PrimaryMay 2026 security update document: CVE-2026-45659 release and the revision note saying it was omitted from the May notes.Microsoft Security Response Centeraccessed 2026-10-03
  6. PrimaryApril 2026 security update document: CVE-2026-32201 release date and fixed builds.Microsoft Security Response Centeraccessed 2026-10-03
  7. PrimaryAugust 2026 security update document: CVE-2026-65660 release, revision history and fixed builds.Microsoft Security Response Centeraccessed 2026-10-03
  8. PrimaryJuly 2025 security update document: release and revision dates and fixed builds for the four ToolShell CVEs.Microsoft Security Response Centeraccessed 2026-10-03
  9. PrimaryRecord for the K7RKScan driver flaw named in the report: publication date, CNA-assigned score, deferred status. Retrieved through the NVD API.NIST National Vulnerability Databaseaccessed 2026-10-03
  10. PrimaryDisrupting active exploitation of on-premises SharePoint vulnerabilities (22 July 2025, updated 23 July). Storm-2603 attribution wording and machine key rotation guidance.Microsoft Threat Intelligenceaccessed 2026-10-03
  11. PrimaryWarlock Ransomware: Old Actor, New Tricks? (22 October 2025). The earlier Symantec reasoning for a China-based actor and links to CamoFei and ChamelGang.Symantec and Carbon Black Threat Hunter Team (Broadcom)accessed 2026-10-03
  12. PrimaryProject AK47 (5 August 2025). Independent vendor assessment: high confidence Storm-2603 is CL-CRI-1040, financially motivated, no direct evidence for a nation-state.Palo Alto Networks Unit 42accessed 2026-10-03
  13. PrimaryState of Ransomware Q3 2025. Source for the count of 43 Warlock leak-site listings, used for scale only.Check Point Researchaccessed 2026-10-03
  14. PrimaryAlert of 22 July 2025 on CVE-2025-53770 and CVE-2025-53771: limited UK targeting, the four recommended actions and the reporting route.UK National Cyber Security Centreaccessed 2026-10-03
  15. PrimaryVulnerability management guidance: responding to active exploitation. Used for the point that organisations may not know what they run.UK National Cyber Security Centreaccessed 2026-10-03
  16. PrimaryMicrosoft recommended driver block rules. Used for the vulnerable driver block list and the attack surface reduction rule, and its stated limits.Microsoftaccessed 2026-10-03
  17. PrimaryLifecycle page for SharePoint Server 2019: extended support end date in July 2026.Microsoftaccessed 2026-10-03
  18. Reported byNews coverage of 2 October 2026 that points to the Symantec report. Read in a browser session because it blocks scripted fetches.BleepingComputeraccessed 2026-10-03
  19. Reported byNews coverage of 1 October 2026 with an interview with a Symantec analyst on whether ToolShell or newer flaws were used.Dark Readingaccessed 2026-10-03

Share this briefing

Know someone who owns this problem? Send it to them.

LinkedInXWhatsAppEmail

Related briefings

The briefing, in your inbox

Practitioner analysis of cyber and AI security news. No vendor noise.

How often

Every new briefing in one email, at 7am, or at 7am, 12:30pm and 6pm. Nothing is sent when nothing is new. Unsubscribe any time.