Blog

Most companies sign an incident response retainer once, file it, and never look at it again. That retainer names the people who would see your most sensitive data, talk to your attackers, and possibly move your money on the worst day your company has. This week’s news is a good prompt to treat ransomware negotiation firm vetting incident response planning as a trust decision you revisit, not a box you checked once.

What Was Reported, and What Is Confirmed

On October 9, FBI Director Kash Patel announced that agents had arrested “another suspected co-conspirator of the ShinyHunters group,” as BleepingComputer reported. Patel did not name the suspect. ShinyHunters is the extortion group the FBI holds responsible for the September breach of its jobs portal.

KrebsOnSecurity reported that the FBI arrested “an executive at a Canadian cybersecurity firm in connection with an investigation into the ShinyHunters hacking group,” citing multiple sources. Press reports identify the man reportedly arrested as Edward Dubrovsky, 54. The FBI has not publicly confirmed that he is the person Patel described. BleepingComputer says plainly: “While the FBI has not publicly confirmed that Dubrovsky is the suspected ShinyHunters co-conspirator, KrebsOnSecurity reports that multiple sources linked Dubrovsky’s arrest to the ShinyHunters investigation.”

The court record is more concrete, and it spells the name differently. A federal docket indexed on CourtListener, United States v. Dobrovsky in the Eastern District of Pennsylvania, shows an arrest on October 8. It lists the complaint charges as:

• “CONSPIRACY TO THREATEN TO IMPAIR THE CONFIDENTIALITY OF INFORMATION WITH THE INTENT TO EXTORT MONEY”
• “INTERFERENCE WITH COMMERCE BY THREATS (HOBBS ACT EXTORTION AND CONSPIRACY TO COMMIT HOBBS ACT EXTORTION)”

A commitment order dated October 9 sends the defendant to the Eastern District of Texas, where the charges were filed. The complaint itself is sealed. BleepingComputer notes that “it is still unclear what he is accused of doing or whether the case is connected to the FBI breach.”

These are allegations. Dubrovsky has not been convicted of anything, and he is presumed innocent. Prosecutors have not said the charges involve his negotiation work, and I am not suggesting they do.

What the Firms Say

Descriptions of his role vary, so here is what each source says. KrebsOnSecurity reported that LinkedIn listed him as one of CYPFER’s “ex-founders,” and that he is “now associated with another Canadian security firm and sponsor called CyberSteward.” CyberScoop describes CYPFER as “a firm that helps organizations negotiate with ransomware operators,” and CyberSteward as “a Toronto-based firm that helps breach victims negotiate ransom payments.”

CYPFER disputes the founder label. A firm representing CYPFER told CyberScoop that his role “was Managing Director from May 2022 through Dec. 2025,” and that he “had no affiliation, operational role or relationship with CYPFER since that time, and contrary to certain reporting, was never a founder or co-founder of the company.” I found no published statement from CyberSteward.

Did he do negotiation work himself? The sources point that way without proving it. Krebs quotes a LinkedIn post in which he wrote of “advisory, negotiations and settlement services,” and one of Krebs’s sources said “the suspect’s company specialized in handling ransomware negotiations with cybercrime groups.” He also recently published a book, Cyber Extortion Strategic Response, about handling cyber extortion.

One more line from Krebs is the reason this matters beyond one case. Sources told KrebsOnSecurity that “charges against principals at other companies that specialize in ransomware negotiation may be forthcoming.” That is unconfirmed, and I would treat it that way.

Why an IR Retainer Is a Trust Relationship

From here on, this is my opinion and my own recommendation, not something any source above prescribes.

Think about what you hand an incident response or negotiation firm during a crisis. You give them access to your environment, your stolen data samples, your executives’ phone numbers, your insurer, and sometimes your payment process. You give them direct contact with the people extorting you. Few vendors get that much trust that fast, and most companies picked theirs from an insurer’s panel list years ago.

Picture this hypothetical. Your company is hit, you call the firm on your retainer, and the negotiator assigned to you works through a channel nobody on your side can see. If that person, or anyone at the firm, were ever compromised or conflicted, you would have little way to know. Nothing in this week’s case shows that happened to any client. The point is that most retainers are not built to detect it if it ever did.

My Ransomware Negotiation Firm Vetting Checklist for Incident Response

This is what I would do, and it is my recommendation only:

1. Re-vet the firm every year, not just at signing. Confirm who owns it, who runs it, and whether anything has changed. Check the names on the retainer against current news and court records.
2. Know the individuals, not just the logo. Ask which people would actually work your case and negotiate, and what background checks the firm runs on them.
3. Ask how they prevent conflicts of interest. Ask whether they have policies against staff having any relationship with threat actors beyond case communication, and how they enforce them.
4. Keep visibility into every attacker conversation. Require that all negotiation messages be logged and shared with your counsel and your internal lead, with no side channels.
5. Split the money from the talking. Any payment decision and movement of funds should need approval from your own executives and counsel, with documented checks, not just the negotiator’s word.
6. Have a second option ready. Keep an alternate firm pre-approved with your insurer, so you are not stuck with one vendor if you lose trust mid-incident.
7. Put audit rights in the contract. Ask for the right to review case records, data handling, and staff access after an incident closes.

The Bottom Line

One sealed complaint does not tell us what happened, and the person charged has not been convicted. What it does is remind us that the vendors we would call on our worst day deserve the same scrutiny we give any other privileged access. Review that retainer before you need it.

Backup servers are supposed to be the boring, trusted box in the corner that saves you on your worst day. This week is a reminder that attackers see them differently. Huntress reports that threat actors are chaining two AhsayCBS flaws to run code on exposed backup management servers, and the vendor’s first patch did not fully close the hole. If you treat AhsayCBS vulnerability backup server security as a quarterly checkbox, now is the time to treat it as an active incident.

What Huntress Saw in the AhsayCBS Attacks

AhsayCBS (Cloud Backup Server) is the management console for Ahsay’s backup software. In its October 8, 2026 writeup, Huntress says it is “primarily used by managed service providers (MSPs) and system integrators” and that it “centralizes control of backup operations.” That makes it a high-value spot: one console, many customers’ backups.

Huntress says NVD disclosed two CVEs on October 4, 2026:

• CVE-2026-105133, which Huntress describes as “a medium-severity flaw” in the checkSysPwd function that “can lead to improper authentication.”
• CVE-2026-105134, described as “a critical-severity vulnerability” in the Replication Receiver component that “can be exploited to achieve unauthenticated remote code execution as NT AUTHORITY/SYSTEM on the host.”

According to Huntress, attackers are chaining them: “First, CVE-2026-105133 is used to bypass authentication. Then CVE-2026-105134 is used to gain code execution.” Huntress says exploitation started on October 7 at 23:20:15 UTC, which is 7:20 PM ET. It adds that “As of October 8, Huntress has seen five organizations targeted via these flaws.”

Here is what Huntress documented after the attackers got in:

• Webshells. “In some incidents we saw threat actors deploy .jsp webshells in the web application directory immediately after exploitation.”
• A disguised cryptominer. “On several endpoints we observed the XMRig miner (edge.exe), renamed to masquerade as a Microsoft Edge process.”
• Persistence. A Windows service named MicrosoftEdgeUpdateSvc, built to look like the real Edge Update service, which ran a modified copy of the NSSM utility with SYSTEM privileges.
• Hiding tricks. A PowerShell script, Taskgmr.ps1, that Huntress says “appears to be an AI-assisted script.” It stopped the miner’s service while Task Manager was open.
• A vulnerable driver. In one incident, attackers downloaded WinRing0x64.sys. Huntress says it gave the miner kernel-level access to the hardware.

Huntress does not name an attacker, and its report does not describe any data theft or tampering with backups. I am keeping that scope. What it documents is SYSTEM-level code execution, webshells and mining. That is bad enough on a box that controls backups.

The Patch Story: Incomplete, Then Corrected

I would not call these flaws unpatched. A fix exists. But the timeline has a twist every operator should know. Ahsay’s own October 10, 2026 security alert says: “our previous patch v10.3.4.0 did not fully address the following security vulnerabilities,” naming both CVEs. It tells partners that “Partners running affected v10 versions should apply the AhsayCBS v10.3.4.45 hotfix” and adds: “After applying the hotfix, please reboot your server.” Ahsay says a partner portal login is required to download it.

Huntress’s own updates track the same correction. On October 8 it said 10.3.4 “is also affected,” noting that “Previous reporting indicated that 10.3.4 was not susceptible.” Its October 12 update says it “independently verified that the AhsayCBS 10.3.4.45 hotfix mitigates the initial entry point of this attack chain.” Huntress also says companies on AhsayCBS v7, v8 and v9 “should apply the 9.15.2.70 hotfix.” Ahsay’s alert only mentions v10, so check your version against both pages.

The lesson there is simple. If you patched to 10.3.4.0 and moved on, you are not done.

AhsayCBS Vulnerability Backup Server Security: What Operators Should Do Now

Huntress recommends restricting management interface access “to trusted IP addresses only or require VPN.” If you find any of its indicators, it says to “carry out a full host re-image from a trusted backup; as attackers have been able to hide secondary backdoors for extended persistence.” My checklist, built on those two sources plus my own judgment:

1. Apply the hotfix and reboot. For v10, that is 10.3.4.45 per Ahsay. Confirm the reboot actually happened.
2. Get the console off the open internet. Allow-list trusted IPs or put it behind a VPN, as Huntress advises.
3. Hunt before you relax. Huntress publishes indicators and four Sigma rules. Look for unexpected child processes from cbssvcX64.exe, .jsp files in the web app directory, a MicrosoftEdgeUpdateSvc service, Edge-named binaries in Temp folders, WinRing0x64.sys, and outbound traffic to mining pools on port 8029.
4. Re-image if you find a hit. Do not just delete the webshell. Huntress’s guidance is a full rebuild from a trusted backup.
5. Review downstream access. If the console has credentials or agents tied to customer environments, check whether any of those were used during the exposure window.

Opinion: Your Recovery Plan Is Now an Attack Surface

This section is my opinion, not a finding from Huntress or Ahsay. In this campaign, the documented payoff was cryptomining. But think about what SYSTEM access to a backup console could mean in a different campaign. Imagine an attacker who quietly changed retention policies or disabled jobs weeks before a ransomware event. You would not find out until you tried to restore. That scenario is hypothetical, but the access needed to attempt it is exactly what these flaws grant.

So I treat backup management the way I treat domain controllers. Keep it off the internet. Give it separate admin credentials with MFA. Monitor it like a crown-jewel system. Test restores from copies the console cannot delete or change. If your recovery plan depends on a box anyone can reach from the internet, the plan is part of your attack surface.

Picture this: your building hands out a new master key, and only people who pass a background check can get one. That sounds sensible until you are the one deciding which of your employees carries it, which doors it opens, and who reviews the log afterward. That is roughly the governance question Anthropic’s Cyber Verification Program now puts in front of security teams. The program reduces some Claude security blocks for verified defenders, and it hands each organization the job of deciding who internally gets the sharper tool.

Here is what Anthropic actually documents, what it does not, and the questions I would want answered before turning it on.

What the Anthropic Cyber Verification Program Changes for Claude Security Work

Anthropic’s October 6, 2026 announcement describes an “expanded version” of the Cyber Verification Program, or CVP. It says the CVP “makes advanced cyber capabilities and reduced blocking classifiers available to qualifying security professionals.” The starting point matters. Anthropic says its generally available models, such as Claude Opus 5.5, Claude Fable 5.1 and Claude Sonnet 5.5, “have conservative cyber safeguards that block most cyber work.” Its reasoning is that cybersecurity is “inherently dual use”: the same capability that helps a team find and fix a flaw can help an attacker exploit it.

The general models are not useless for security. Anthropic’s Help Center page for the program says they can still be used for secure code review, threat modeling, patching known issues, finding vulnerabilities in your own source code and triaging alerts. But it warns that “other cyber security work like malware analysis or exploit validation may be interrupted by our safety classifiers.” The CVP is the route for professionals whose legitimate work is getting blocked.

This is also a merger. Anthropic says that for the past six months it ran two programs: Project Glasswing, which gave organizations securing critical software access to Claude Mythos, and the original CVP, which gave vetted teams “access to reduced safeguards on Claude Opus and Claude Sonnet models.” The new CVP integrates both. Each tier includes Claude Opus 5.5, Claude Sonnet 5.5, Claude Mythos 5.1 and future models.

Three Tiers, Documented

Anthropic documents three access tiers, each with “different verification requirements and security controls”:

• Defense Access covers defensive work such as SOC and incident response tasks, reverse-engineering malware, and analyzing and validating vulnerabilities. Anthropic’s examples of qualifying organizations include corporate, nonprofit, university and government security teams defending their own systems; critical infrastructure operators of any size; smaller security firms; open-source maintainers; and individual researchers with a track record of reported vulnerabilities. It is the only tier open to individuals, and only on a paid plan.
• Red Team Access adds authorized penetration testing and red-teaming, for organizations only. Testing is limited to systems they are authorized to test. Anthropic says users “will still experience real-time blocks” on actions that could cause physical harm or mass disruption, such as deploying ransomware or damaging physical systems.
• Specialized Access “has the fewest cyber blocks.” It is reserved for a limited set of verified organizations authorized to test safety systems such as flight operating systems, power grids, telecom networks and interbank transfer infrastructure. Anthropic says it reviews every one of them “in depth in collaboration with the US government,” and existing Glasswing members move into this tier.

Anthropic also published results from its own evaluation, CyScenarioBench, run against Claude Opus 5.5 under each tier’s safeguards. It reported that without CVP every task was blocked on the first prompt, and that in Defense Access 46 of 50 trials were blocked at some point. In Red Team Access there were no blocks, and the model completed 34 of 50 tasks. That is vendor-run testing on a vendor-built benchmark, so read it as Anthropic’s evidence that the tiers behave differently, not as independent validation.

Who Checks the Badge

Here the documentation is useful but not complete. Anthropic says it “will verify all applicants and request proof of the required security controls for the relevant access tier.” The Help Center lists what an application needs: organization and applicant details for identity verification, a description of your security work, and “an attestation to the security controls applicable to your desired tier.” Organizations apply once, and admins then designate seats or assign the program to workspaces or custom roles. Anthropic aims to answer within seven business days and places each applicant “at the highest tier” its information supports. The announcement adds that Red Team reviews take “a few weeks.”

The Help Center also lists factors that can rule an organization out. These include the nature of the work, whether Anthropic can verify who the organization is, the legal and regulatory environment and the risk access “could be compelled,” and a more cautious approach for organizations that primarily serve military, intelligence or law enforcement customers.

A few strings stay attached. The Usage Policy “still applies in full.” Anthropic says it “may review, narrow, or withdraw a grant.” Data retention is required “so that we can monitor for cyber misuse,” with limited zero-data-retention exceptions until Anthropic’s Enterprise Frontier Safeguards option arrives. Defense Access members have until December 15, 2026 to adopt phishing-resistant MFA and stop using API keys. CVP access also cannot be used to build a client-facing product without a separate approval.

What is not public: the exact scoring behind tier placement, how attestations are checked in practice, and precisely which classifier behaviors change in each tier beyond Anthropic’s examples. SecurityWeek’s coverage matches Anthropic’s description of the three-tier structure, but I have not seen independent detail beyond that.

Opinion: The Real Badge Check Happens Inside Your Org

This section is my opinion. Anthropic is checking the organization. Once a grant lands, your admins decide which workspaces, roles and seats get it. That makes CVP an internal privileged-access problem as much as a vendor program, and I would govern it like one:

• Map the tier to job duties. Only people whose work actually needs malware analysis or exploit validation should sit in a CVP-enabled workspace.
• Treat the workspace like a privileged group. Use named seats, periodic access reviews, and removal on role change.
• Log on your side too. Anthropic retains data for misuse monitoring, but that is its monitoring, not yours. Keep your own record of who used the elevated workspace and for which engagement.
• Get the controls done early. Phishing-resistant MFA and moving off API keys are good hygiene anyway, and the deadline is documented.
• Write down scope. Red Team Access is limited to systems you are authorized to test. Keep that authorization paperwork next to the access list.

A sharper tool for defenders is a reasonable idea. The part that will decide whether it stays reasonable is the boring part: who holds the badge, and who reads the log.

Here is a hypothetical that will sound familiar to anyone who has sat through a cloud migration kickoff. The on-prem SharePoint farm is “being retired.” It has been being retired for two years. Patching it slips to “after the cutover,” monitoring quietly lapses, and the box keeps answering on port 443 the whole time. That server is exactly the kind of thing the Warlock ransomware crew is still breaking into, according to new research. It is getting in through SharePoint vulnerabilities, some of which have had a patch available for more than a year.

The source here is the Symantec and Carbon Black Threat Hunter Team’s October 1 report on Warlock. It describes a group Symantec calls Longlegs, which Microsoft tracks as Storm-2603, hitting critical infrastructure through on-premises SharePoint. Here is what the report actually says, where the sheet headline went a little too far, and what I would check this week.

Who Got Hit, and What Symantec Actually Says

Symantec says that in the past two months Longlegs attacked at least four organizations. Two were critical infrastructure operators, a water utility and a telecommunications provider. The other two were a regional government body and a university. All four were in Portuguese- and Spanish-speaking countries across Europe, Africa and Latin America. Symantec does not name the victims, and the report does not describe any disruption to water treatment or network operations. I am not going to imply either. The report calls the group China-nexus. It notes that Warlock has previously turned up in a wider range of countries, including the United States, but none of these four were US organizations.

This is not the group’s first SharePoint campaign. Warlock emerged in June 2025 and became notorious weeks later, when it was tied to the “ToolShell” zero-days in on-prem SharePoint Server. In its July 2025 write-up, Microsoft said it had observed Storm-2603 exploiting those flaws to deploy ransomware. Microsoft released security updates for all supported SharePoint Server versions that month.

Which SharePoint Vulnerabilities, and Which Patch

The sheet headline said “year-old flaws.” That is only partly right, and the distinction matters for what you patch:

• The 2025 ToolShell chain (CVE-2025-49704, CVE-2025-49706, CVE-2025-53770 and CVE-2025-53771). Symantec says these “likely remain in the group’s arsenal.” Note the word likely.
• Newer SharePoint flaws. Symantec points to the ones covered in a July 2026 CISA advisory. CISA’s SharePoint hardening alert lists six actively exploited 2026 CVEs affecting all supported on-prem versions: Subscription Edition, 2019 and 2016. CISA added them to its Known Exploited Vulnerabilities catalog between April and August 2026.

Symantec does not pin each intrusion to a single CVE. For the attack it walks through in detail, it says initial access was “likely” through SharePoint Server vulnerabilities. So the honest framing is “old and newer SharePoint flaws on servers that were not patched or otherwise mitigated,” not “a year-old bug did it.”

Inside One Intrusion: Nine Days From Webshell to Ransomware

Symantec’s detailed case is one intrusion at a critical infrastructure operator. The report does not say whether it was the water utility or the telecom. The timeline is worth reading slowly:

• July 22, 2026: A webshell landed in the SharePoint LAYOUTS directory. Symantec says the group drops it for several SharePoint versions at once, and uses it to harvest the farm’s ASP.NET machine keys. With those keys it can forge validly signed payloads and run code inside the SharePoint application pool.
• July 24 to 29: Reconnaissance, DLL sideloading and payloads pulled from public file-hosting services. The attackers added a domain account to local Administrators on three more hosts. Symantec says its name was likely chosen to pass for a SharePoint setup account. They installed a Visual Studio Code tunnel as a service for covert remote access and ran NetExec for Active Directory enumeration and credential spraying.
• July 31: An AV/EDR killer was pushed to at least 40 hosts within about two hours. Warlock showed up on at least 33 hosts almost as soon as protection dropped on each one. The payload was staged in the domain’s SYSVOL share, and on three hosts telemetry showed ordinary SYSVOL replication delivering it.

That is nine days from first observed activity to ransomware. It is not a smash-and-grab either. In my view, that is plenty of time for someone watching the right logs to notice.

One correction to a common shorthand. Symantec says Longlegs abuses a signed but vulnerable K7RKScan driver (CVE-2025-1055) to kill security tools, and BleepingComputer’s coverage repeats that. But in this specific intrusion, Symantec says the identity of the vulnerable driver “remains unknown.” K7RKScan is what the group used in other recent attacks.

Opinion: Patch Debt Is the Real Playbook

This section is my opinion, not Symantec’s finding. Nothing in this report needed a fresh zero-day to be scary. What made it work, as far as the public details go, is the stuff every ops team recognizes: an internet-facing on-prem server that probably was not first in line for patches, a farm whose machine keys a webshell could simply read, and a domain where a new executable in SYSVOL does not set off alarms. I call that patch debt. Like financial debt, the interest compounds quietly until someone else collects it.

Water utilities and telecoms are not uniquely careless. They tend to run long-lived systems with tight change windows, which is precisely the environment where “we’ll patch it after the migration” turns into a two-year habit.

What I Would Check This Week

• Find every on-prem SharePoint server, including the one “being retired,” and confirm the latest Microsoft updates are actually installed, not just approved.
• Get it off the open internet. CISA’s first recommendation is to avoid exposing SharePoint directly. If you must expose it, put it behind an application-layer proxy that enforces authentication.
• Hunt before you rotate. CISA says to look for machine-key harvesters and other intrusion artifacts before rotating IIS machine keys. Otherwise you are just handing the attacker fresh keys.
• Turn on AMSI integration for each SharePoint web application, as CISA recommends.
• Watch SYSVOL like it is production code. New executables under the scripts folder deserve an alert, and so does a VS Code tunnel service showing up on a server.

None of that is exotic. It is the backlog. Warlock is betting you will not get to it.

A hypothetical: suppose your help desk box gets popped on a Sunday. Nobody notices until Monday, and by then the attacker has gone from the ticketing app to root and is poking at other services on the network. Now suppose your entire job is telling other people about their vulnerabilities. That is roughly what the Dutch Institute for Vulnerability Disclosure says happened to it, and the Zammad zero-day DIVD breach is the best argument I have seen in a while for taking help desk security as seriously as the domain controller.

DIVD is a mostly volunteer group that finds flaws, reports them to vendors, and warns the owners of exposed systems. On its DIVD-2026-00014 case page it puts it bluntly: “DIVD got hacked through AI agents.” Here is what the group has said, what it has not, and what I would do about it.

The Zammad Zero-Day DIVD Breach: What DIVD Says Happened

According to DIVD’s timeline, the first malicious access to its systems came on September 21, 2026. DIVD spotted the activity on September 22, blocked access to everything in its datacenter, and started a forensic investigation with Merlon Security.

DIVD’s September 30 statement says the attackers got in through two zero-days in Zammad, the open-source ticketing system. Together the flaws “allowed session hijacking, remote code execution and privilege escalation from the Zammad user to root, in seconds due to the agentic part of this hack.” From there, DIVD says, the attackers could reach other services and exfiltrate data. DIVD credits network segmentation and fast work by its IT and incident response team for stopping them from going deeper. It also says it is assuming breach until it can prove otherwise.

The AI part rests on DIVD’s own reading of the logs. DIVD says the agent decided each next step itself, fast and on sloppy logic. Its scripts carried comments justifying its own actions, which DIVD notes a human attacker would not bother writing. The attack was, in DIVD’s words, “loud and very messy.”

The Two Flaws, Without the Hype

DIVD opened a second case, DIVD-2026-00015, to track the bugs and notify owners of vulnerable instances. The details matter, because several write-ups flattened them:

• CVE-2026-102489 is a session hijack that leads to remote code execution as the zammad user. DIVD lists Zammad 6.3.0 through 6.5.4 as exploitable. The code is also present in 7.0.0 through 7.1.3 but, per DIVD, is not exploitable there because of the runtime environment. DIVD scores it 8.7 on its own.
• CVE-2026-102490 is a local privilege escalation from the zammad user to root. DIVD lists versions 1.5.0 up to the 7.1.0 alpha and describes it as affecting all versions, including the latest alpha. DIVD scores it 8.5 on its own.

DIVD gives both a 9.4 critical score when they are chained, and that number is the honest headline. Neither bug alone hands a stranger root. Together they did. CISA added both CVEs to its Known Exploited Vulnerabilities catalog on October 2.

Patch Status as of October 6, 2026

This is still moving, so I am pinning it to a date. As of the afternoon of October 6, 2026, here is the status per Zammad’s October 5 security advisory.

For CVE-2026-102489, Zammad says 7.0 and later are not affected in practice. It says exploitation only works on 6.5 and earlier, which are out of support and no longer get security updates. It also says it first received a report on the issue in August 2026, and that a hardening change to the affected code shipped in 7.2.0.

For CVE-2026-102490, Zammad calls it a local privilege escalation that cannot be exploited remotely on its own, and ties it to a confirmed vulnerability in packager.io. Its wording is that the team “is working on a solution.” I found no fix announced. The Zammad 7.2.1 release notes, published October 6, do not mention this CVE. Zammad also says 102490 went public before it had the details to reproduce it, a disclosure dispute I will leave to the two parties.

What Got Out, and What Nobody Knows Yet

Early coverage, including Help Net Security’s October 1 report, said DIVD had not yet shared which data was accessed. DIVD’s own statement from the same day goes a bit further. Volunteer data got out, “such as DIVD email addresses and possibly contact details.” DIVD says whose data and exactly which data are still under investigation, and warns that it is now easier for someone to pose as a DIVD volunteer. That is all DIVD has confirmed about the data.

The same goes for who did it. DIVD says it sees no link to any known public threat actor. It also says no facts so far point to a deliberate, targeted attack on its most sensitive assets, though it cannot rule that out.

Why Help Desk Security Belongs on the Critical List

Opinion: I would call the help desk crown-jewel infrastructure. That is my label, not DIVD’s. The case is simple. Think about what a typical ticket queue holds in most shops, not DIVD’s specifically: password reset threads, screenshots of admin consoles, VPN error messages with hostnames in them, and the email address of every user who ever asked for help. It usually holds a mail integration, often an LDAP or SSO hookup, and API tokens for other systems. It is internet-facing by design, because customers and staff need to reach it. And in a lot of shops it is the app nobody owns after the install weekend.

DIVD’s story has the shape of every bad night I remember: an old version, a half-known bug, and a service account one step from root. The difference is speed. If an agent can chain those steps in seconds, the gap between “first access” and “it reached the next box” is shorter than your alert routing.

What I Would Do This Week

• Check your version today. If you are on Zammad 6.5 or older, you are on unsupported code that is exploitable for 102489. Upgrade, or follow DIVD’s advice and take the instance offline until you can.
• Copy your logs before you upgrade. Help Net reports that the Dutch NCSC recommends keeping application and network logs, which will help if more details on the second flaw emerge. DIVD also publishes an indicator-of-compromise log check script on its case page.
• Lock down the server, not just the app. Zammad’s own guidance is to restrict access to the underlying server to trusted administrators. Since 102490 has no announced fix, assume anything running as the zammad user could become root.
• Segment it like it matters. DIVD credits segmentation with limiting the damage. The help desk host should not be able to reach everything else just because it is internal.
• Watch the vendor channel. Keep an eye on Zammad’s security advisories for the 102490 fix.

DIVD deserves credit for publishing this in near real time, embarrassing parts included. The least we can do is look at our own ticket queues.

Picture this message landing in a researcher’s inbox. It would look like it came from someone whose name everyone in the AI policy world already knows, inviting them onto a shiny new advisory committee. The subject would feel urgent, not spammy. If the mail gate treated that famous name as VIP traffic instead of a lookalike, the reply would open the door to the real payload. That’s the AI researcher phishing impersonation pattern Proofpoint just documented, and it’s exactly the kind of email security problem operators keep underestimating.

The attack didn’t need a zero-day. It needed a recognizable name, a believable pretext, and a mailbox that still trusts famous people.

What Proofpoint Actually Reported

On October 1, 2026, Proofpoint published research on a group it tracks as TA419. Proofpoint calls TA419 a China-aligned, espionage-motivated threat actor. That is the vendor’s attribution language. The report does not publish a numeric confidence score, does not name a Chinese government agency or contractor, and does not claim a courtroom-grade linkage. I’m sticking to that wording rather than the broader “Chinese hackers” label some headlines used.

Proofpoint says it has watched TA419 run targeted credential phishing against people at US- and Japan-based think tanks, defense contractors, universities, and law firms since at least April 2025, and that the group’s activity had not been reported publicly before.

The campaigns that match this post’s topic are narrower than “AI experts” in general:

• July 2026, starting July 8: TA419 impersonated Lynne Edwards Parker, the former Principal Deputy Director of the White House Office of Science and Technology Policy, and then Heidi Crebo-Rediker, an economist and foreign policy expert. The targets were AI policy experts at US think tanks, universities, and law firms.
• February 2026: the same group impersonated a senior Anthropic employee, whom Proofpoint does not name, to reach an AI policy analyst at a US think tank. The subject line referenced military use of Claude.

Proofpoint names Parker and Crebo-Rediker in the primary report, so those names appear here. It does not name the Anthropic employee, and it declines to name the targets. Reuters later identified one target independently; I’m not repeating that name. Stick to what the vendor published.

How the AI Researcher Phishing Impersonation and Email Security Chain Worked

The sequence is worth walking for anyone who runs mail or identity:

1. A benign opener. Invitations to join a fictitious “AI Policy Advisory Committee,” or to contribute to a supposed Senate Foreign Relations Committee report on AI export controls and supply chains. No malware. Just rapport.
2. If the target replies, a shortened URL that claims to share more information.
3. A multi-stage redirect through actor-controlled domains, including a Cloudflare Turnstile check behind a fake OneDrive loading screen.
4. An adversary-in-the-middle (AitM) page built on a customized Frameless BitB kit. The victim sees what looks like a real Microsoft sign-in. The proxy relays the login to genuine Microsoft infrastructure, so password, MFA, and conditional access can all succeed while the attacker captures the session cookies.

Proofpoint says both July campaigns used the same first-stage domain and the same second-stage AitM domain. Sender addresses were lookalike webmail accounts, not the real people’s corporate mailboxes. Nextgov/FCW’s write-up of the same report is consistent on the names, dates, and Microsoft-focused AitM chain.

Reuters, summarizing Proofpoint, said the recent campaign involved fewer than ten individuals at a handful of organizations, and that Proofpoint’s view of the targeting suggested an intelligence interest in US policymaking rather than technology theft alone. That “fewer than ten” figure is Reuters citing Proofpoint; it is not in the public Proofpoint blog post itself, so treat it carefully. Reuters’ own page returned a bot block to my link check, so I am citing it by name only and linking the sources that did return HTTP 200.

One more attribution note, because the headline asked for it. Proofpoint told Reuters it based the China alignment on malware types, infrastructure, and targeting priorities that line up with Chinese intelligence collection. The published Proofpoint blog leans harder on targeting history, Cloudflare-fronted file-share domains, NameSilo registrations, and a recurring self-signed TLS certificate cluster than on a named malware family. Either way, the confidence language available to the public is “China-aligned” plus “likely supports wider Chinese intelligence objectives,” not a scored attribution to a specific PLA or MSS unit.

What This Means for Email Security Operators

Everything below is my ops opinion, not Proofpoint’s checklist.

Spam filters are not the control that failed here. The lure was a conversation that looked like work. The payload was a session-stealing login that can survive ordinary MFA. If your mail gate still boosts messages that look like they come from famous people, or if your SOC treats “VIP sender” as a reason to lower scrutiny, you are playing into the same habit this campaign abused.

• Treat VIP lookalikes as hostile until proven. Display-name matches on free webmail, or near-miss addresses that echo a public figure, should raise priority, not lower it.
• Verify unexpected outreach out-of-band. Proofpoint’s own recommendation is the right one: confirm unsolicited subject-matter invitations through another independent channel before you reply, click, or join anything.
• Assume AitM against Microsoft 365. Passkeys and other phishing-resistant, origin-bound authentication matter here more than another banner warning. If cookie theft is the goal, push MFA alone is not enough.
• Watch the reply, not just the first message. The dangerous link arrived after the target engaged. Thread-aware detections and reply-path URL checks beat first-message-only rules.
• Inventory who your researchers talk to. Policy shops, universities, and outside counsel in the AI regulation lane are soft targets for this pretext. Know which mailboxes sit at that intersection.

Proofpoint assesses that TA419 will likely keep targeting think tanks and policy experts, and will keep spoofing real subject-matter experts. I take that as a vendor forecast, not a guarantee. The durable lesson for operators is smaller and meaner: famous names are not authentication, and a mailbox that still treats them as urgent is doing the attacker’s first hop for free.