Philippine ownCloud Stays First. Chinese State Attribution Waits

Assess the Philippine ownCloud intrusions from an exploit-feasibility lens. Distinguish what the available evidence establishes from what remains unverified: affected versions before 10.13.1, authentication-bypass mechanics, likely post-compromise paths, and whether reported 9 GB exfiltration plus Metasploit/Mettle/Sliver artifacts close the kill chain. End with the three actions an exposed organization must take today; do not treat attribution as settled.

The evidence supports CVE-2023-49105 as a WebDAV authentication bypass fixed in ownCloud 10.13.1. A crafted pre-signed URL can permit file access when the signing key is not configured; the attacker still needs a valid username. That can jump directly from internet access to file theft—no shell required. But the reporting does not establish every historical version below 10.13.1 as vulnerable, nor prove the exact version and configuration running at each Philippine victim. Hunt.io (opens in new tab)

Post-compromise, the cleanest path is bulk WebDAV access, followed by legitimate-credential use—the operator’s records included a credential pair reportedly validated against ownCloud separately from the bypass. Metasploit, Mettle, and Sliver create a plausible second path toward command execution and C2; Sliver supports file discovery, transfer, and exfiltration. But tools sitting in an attacker-controlled directory are a toolbox in a van, not proof they entered the building. There is no cited host telemetry proving those payloads executed on the ownCloud server, gained persistence, or moved laterally. Hunt.io (opens in new tab) MITRE ATT&CK (opens in new tab)

The reported roughly 9 GB and 176 files materially support a data-theft objective, but appear to derive from attacker-maintained records and staged material. Without victim-side WebDAV logs, egress telemetry, file hashes, or matching recovered archives, the volume remains unverified. So the file-theft chain is plausible and partially evidenced; the malware-execution chain is not closed. “Chinese-speaking operator” is an observable clue, not settled attribution.

Today: 1) isolate exposed instances while preserving reverse-proxy, WebDAV, authentication, filesystem, process, and network evidence; 2) upgrade to 10.13.1 or a later supported release, then revoke sessions and rotate passwords, app tokens, signing keys, and exposed secrets; 3) hunt across the entire exposure window for pre-signed WebDAV requests, abnormal bulk downloads, the reported file set, and actual execution or C2 evidence associated with Sliver/Mettle—not merely filenames.

Make an evidence-based intelligence judgment on the Philippine nuclear and naval-support intrusions. How much confidence is justified in 'Chinese-speaking actor,' and how much—if any—in state direction? Separate victim, access, exfiltration, tooling, infrastructure, and attribution claims, identify the most important missing corroboration, and state what would materially change confidence.

The evidence supports moderate confidence that the operator used Chinese, but only low confidence in Chinese state direction. Simplified-Chinese comments, logs, docstrings, and data-sorting folders indicate operator language; they do not establish nationality, tasking, or a known PRC group.

• Victims — high: Nuclear-research and Philippine Navy-support organizations are directly represented in recovered files and scripts.
• Access — moderate: Nuclear access is consistent with ownCloud/WebDAV abuse associated with CVE-2023-49105; the separate WordPress compromise is less fully documented. ATT&CK: T1190.
• Exfiltration — high for 372 MB/176 recovered files; moderate for ~9 GB: The larger figure comes from a CSV inventory, not recovered payloads. ATT&CK: T1005, T1074.
• Tooling — high for presence, moderate for execution: Custom Python scripts, Sliver, Metasploit, and Mettle were found together; co-location alone cannot prove each tool ran against both victims.
• Infrastructure — high that 31.58.209[.]241 staged material; low that it was exclusive or state-controlled: No independent passive-DNS, certificate, hosting-payment, or prior-campaign linkage is reported.
• Attribution — moderate, Chinese-speaking operator; low, PRC direction; insufficient for an APT/G-number: Strategic victimology around nuclear and naval support is compatible with state collection, but that is narrative alignment—not attribution.

The decisive missing corroboration is victim-side telemetry linking exploitation, execution, and outbound transfer to this infrastructure. Recovered C2 configurations, code lineage to an established campaign, historical DNS/certificate pivots, or evidence of government tasking would materially raise confidence; evidence that the server was shared or compromised would lower it.

Translate the Philippine ownCloud breach into nuclear and naval-sector operational risk without assuming an OT compromise. Identify the plausible bridge from an IT file-sharing breach to engineering, safety, supplier, or control-system harm; name the evidence needed to prove that bridge; and give operator-safe containment steps for the next shift.

The immediate physical risk is not proven. Hunt.io places the nuclear ownCloud compromise at Purdue Level 4 and reports theft of nuclear-material records, a reactor core-component database, personnel data, and BitLocker/KeePass/AxCrypt material. The naval supplier suffered a separate WordPress intrusion, not the ownCloud exploit. There is currently no cited evidence of access to an engineering workstation, controller, or safety system. (Hunt.io (opens in new tab))

The plausible bridge is stolen credentials or engineering context enabling access through vendor portals, VPNs, project systems, or Level 3.5 jump hosts into Level 3 engineering services—and eventually Level 2/1. Stolen drawings or component records could also support convincing supplier impersonation or malicious engineering-file substitution. At Level 1, the safety trade-off becomes physical: a false trip may stop operations, while a missed trip may endanger personnel.

To prove that bridge, correlate ownCloud access and exfiltration times with identity, VPN, SSO, project-management, vendor-access, jump-host, and firewall logs. Examine exposed credential stores for accounts reaching engineering environments; hunt endpoints for the reported Sliver, Metasploit, and Mettle tooling; review engineering-file hashes and supplier exchanges; and compare PLC/HMI/SIS logic, setpoints, firmware, and controller checksums against approved baselines. Historian data and independent field readings should confirm whether any process behavior changed.

For the next shift: disconnect the affected internet-facing service after preserving logs and forensic images; revoke sessions and rotate exposed credentials from clean systems; suspend nonessential vendor access and permit emergencies only through a monitored jump host; block unnecessary Level 4-to-Level 3 paths; and perform read-only controller and physical process verification. Do not reboot controllers, push broad configuration changes, or alter SIS communications. Any segmentation change must pass plant change-control and testing, because disrupting a safety communication path could create the incident you are trying to prevent.

Assess the strategic meaning of simultaneous reporting on Philippine nuclear/naval targeting and the U.S. disruption of QTFY infrastructure. Argue against premature state attribution where warranted, but identify whether the victimology and regional context support a broader China-linked collection pattern. Give one decision implication for Philippine and allied security leaders.

The simultaneous reporting should not be mistaken for evidence of one coordinated operation. The U.S. case is stronger: DOJ identifies QTFY as a PRC state-sponsored group employed by a Nanjing company and says it operated the seized QScan and QTRouter platforms. By contrast, the Philippine case establishes Chinese-language operators, structured collection, and strategically significant victimology—not Chinese state command. Shared language, known vulnerabilities, and attractive targets cannot bridge that evidentiary gap.

Yet the pattern is difficult to dismiss. Collection from nuclear and naval organizations—including reported reactor, nuclear-material, personnel, and cryptographic records—would support military planning, counterintelligence, and long-term access. It also coincides with intensified South China Sea friction, including Chinese vessels shadowing Philippine-U.S.-Australian exercises. My assessment: broader China-linked collection is plausible, but linkage to QTFY or direction by Beijing remains unknown.

The decision implication is attribution-independent: Philippine and allied leaders should establish a joint counterintelligence-led hunt across nuclear, naval, and defense-contractor networks, prioritizing credential and key rotation, exposed-system review, evidence preservation, and cross-victim correlation—while reserving diplomatic escalation for independently corroborated state direction.

Assess the compromised @7nohe/openapi-react-query-codegen workflow and the reported Trivy v0.69.4/tag compromise as release-trust failures. Determine what valid provenance does and does not prove, identify the likely downstream blast radius, and give a concrete inventory-and-containment sequence for engineering teams. Flag any facts that remain insufficiently corroborated rather than treating both incidents as identical.

Halil, these are both release-trust failures, but at different links. FACT: @7nohe/openapi-react-query-codegen was published with valid npm provenance after a comment-triggered GitHub Actions workflow checked out attacker-controlled fork code; its install step obtained an OIDC publishing token. ASSESSMENT: that provenance binds the package digest to the recognized workflow and publishing identity. It does not prove the checked-out code was trusted, the trigger was authorized, install hooks were safe, or the package was reviewed. For Trivy, compromised aqua-bot credentials reportedly triggered the genuine release automation for v0.69.4 and force-pushed mutable Action tags. An actual valid provenance attestation for that binary is not established by the available evidence; even if present, it would prove the compromised automation produced it—not that it was benign.

The blast radii differ. OpenAPI exposure centers on projects whose lockfiles resolved a malicious version, particularly floating ranges, and any CI or developer system that executed its install triggers. Those environments’ cloud and package-registry credentials, subsequent package publications, and derived artifacts become suspect. Reports disagree on whether eight or ten malicious versions were published, and claims of propagation into npm, RubyGems, and PyPI need package-by-package confirmation. Trivy’s radius is broader across distribution paths: v0.69.4 and latest reportedly reached GHCR, ECR Public, Docker Hub, deb/rpm packages, and get.trivy.dev; 76 of 77 trivy-action tags and all seven setup-trivy tags were reportedly redirected. Therefore, inventory both binary consumers and workflows using mutable tags—not merely repositories declaring v0.69.4.

Engineering teams should proceed in this order: (1) freeze affected CI jobs and package publishing; (2) enumerate OpenAPI lockfiles, install logs, caches, developer hosts, runner images, SBOMs, and artifacts built during the August 28 window; (3) enumerate every trivy-action/setup-trivy reference, its resolved commit SHA, downloaded Trivy digest, container digest, OS package, and latest pull from the March 19 window; (4) revoke and rotate every secret available to an affected runner—including registry, GitHub, cloud, SSH, and API credentials—and audit unexpected releases or tag changes; (5) purge caches and ephemeral runners, then rebuild artifacts from reviewed source on clean infrastructure; (6) restore only with immutable commit SHAs or image/package digests, verified against a post-remediation trusted release. Provenance verification remains necessary, but must be combined with trigger restrictions, reviewed workflow inputs, least-privilege OIDC, and independent digest approval.

Focus on CI/CD secret exposure and control-plane consequences from the malicious npm and Trivy release workflows. Which credentials, tokens, cloud identities, artifacts, runners, and deployments must be treated as potentially exposed; what evidence narrows the rotation scope; and which three pipeline controls provide the fastest risk reduction tonight?

Halil, treat every workflow that installed a malicious TanStack version or executed a poisoned Trivy tag as an identity-compromise event. Scope includes GITHUB_TOKEN, extracted GitHub OIDC tokens, resulting AWS STS/GCP/Azure federated credentials, Kubernetes tokens or kubeconfigs, SSH/deployment keys, registry and package tokens, database passwords, signing material, and secrets present in memory or the workspace. Quarantine affected self-hosted runners and caches; invalidate artifacts, images, attestations, and deployments produced by those runs until rebuilt from known-good inputs. Ephemeral runners can be discarded, while persistent runners require forensic review or replacement.

The evidence supports narrower rotation than an indiscriminate tenant-wide reset. TanStack says no npm token was stolen and its publish workflow was not modified; the attacker extracted a short-lived OIDC token after a legitimate release restored a poisoned cache. For Trivy, scope runs by immutable commit SHA and execution time—not the displayed tag—because 76 of 77 trivy-action tags and all setup-trivy tags were redirected, while v0.35.0 remained protected. Include Trivy 0.69.4, Docker images 0.69.5 and 0.69.6, and latest during the exposure window. Complete GitHub logs plus AWS CloudTrail AssumeRoleWithWebIdentity, equivalent GCP/Azure token-exchange logs, registry audit logs, and outbound-runner telemetry can identify which identities were actually reachable. Masked workflow logs alone do not clear a run.

Tonight’s three fastest controls are: (1) disable affected workflows, purge caches, and pin every action, package, and image to a reviewed commit SHA or digest; (2) revoke credentials reachable by confirmed runs and replace long-lived secrets with tightly scoped OIDC trust policies and protected deployment environments; (3) separate untrusted PR jobs from release jobs and caches, using disposable runners without production secrets. The CSP control planes are not shown as breached—the customer-side risk is that stolen workload identities can invoke legitimate APIs. “Trusted publishing” still requires deciding precisely what is trusted.

Compare the two active DeFi incidents strictly for immediate decision impact: Ajna v2's immutable liquidation-accounting flaw and the outdated Rain card contract affecting Avici and Tria. Separate confirmed losses and affected users from uncertain ongoing exposure, explain how immutability versus upgradeability changes containment, and give distinct same-day actions for each incident rather than one generic crypto response.

Halil, the immediate difference is containment authority. FACT: Ajna v2 lost approximately $775,400 across seven Ethereum pools through liquidation-accounting logic. The available reporting does not identify a confirmed user count. Because the contracts are immutable, operators cannot patch the flaw in place or rely on a conventional upgrade. Same-day action: stop routing deposits through every interface and integration, warn users that frontend closure does not disable contracts, withdraw recoverable positions, snapshot each pool’s state, and prepare migration to newly audited contracts. The amount still exposed in remaining positions is unknown.

FACT: The outdated Rain Solana card contract caused roughly $1.1 million in aggregate losses. Avici specifically reported about $500,800 affecting 1,685 users; Tria confirmed exposure, but no reliable Tria-specific loss or user count is available. Rain says the contract was upgraded and the issue resolved, while Avici pledged refunds. Same-day action: suspend card funding until each program verifies its deployed contract version and authorities, enumerate every integrator still referencing the obsolete contract, reconcile affected balances, and begin refunds. Unlike Ajna, upgradeability permits direct technical containment—but the residual exposure remains unknown until Rain proves no legacy deployment is still reachable.

Financially, Rain is already in recovery mode: reporting says the stolen stablecoins were converted to SOL, bridged to Ethereum, and sent through Tornado Cash, reducing the practical freeze window. Ajna remains the sharper ongoing-loss decision because vulnerable immutable pools may continue accepting direct transactions despite interface restrictions.

Evaluate AnonyMousKIT's multilingual Apple Support impersonation against the broader NSA/FBI/CISA deepfake guidance. Is the operational novelty synthetic voice quality, automation at scale, or live 2FA interception? Separate evidence of attempted calls from evidence of successful compromise, then specify controls that can be deployed now without relying on imperfect deepfake detection.

Halil, the operational novelty is automated multilingual orchestration, not demonstrated voice realism. Records show 200 calls between August 2025 and May 2026, with 55 scripts/transcripts and English, Spanish, and Portuguese personas. The workflow joined an automated “Apple Support” call to spoofed Apple/Find My pages that requested the device passcode, Apple ID credentials, and a current 2FA code. Live 2FA harvesting is the decisive takeover mechanism; automation packages and scales it. There is no audio-quality analysis showing that unusually convincing synthetic speech caused victims to comply.

The evidence proves attempted impersonation: call records, transcripts, scripts, and credential-harvesting infrastructure. It does not establish how many recipients submitted credentials, surrendered valid 2FA codes, lost their Apple accounts, or had Activation Lock removed. Those outcomes remain unknown. That distinction matters because infrastructure capability is not evidence of successful compromise.

The campaign fits NSA/FBI/CISA guidance: synthetic media enables trusted-party impersonation, but detection remains a “cat-and-mouse game.” Deployable controls are therefore procedural: treat unsolicited support calls as untrusted; never disclose a passcode, password, or 2FA code by voice or through a caller-supplied link; terminate the call and independently contact Apple through a known-good app, URL, or published number; require a second-channel confirmation before account recovery or device release; and rehearse/report impersonation attempts. Voice likeness should initiate suspicion, never authorize action.

James, close the room with a decision-ready response plan. Reconcile these findings: Alex says the ownCloud path aligns with CVE-2023-49105 and may require a valid username plus absent signing-key protection; Lena and Elena support operator-language evidence but not confident PRC state direction; Sara finds no proven OT bridge despite sensitive Level 4 data theft. Tomas and Priya treat the npm and Trivy events as CI/CD identity compromises, where valid provenance does not prove trustworthy source or workflow execution. Viktor distinguishes unpatchable Ajna v2 from upgradeable Rain integrations; Isabelle says AnonyMousKIT's novelty is automation and live 2FA capture, not proven deepfake realism. Rank what a CISO should do in the next 24 hours for ownCloud, the two supply-chain incidents, residual QTFY-compromised edge devices, Ajna v2, Rain/Avici/Tria, and AI-assisted account-recovery fraud. Then give one-sentence quick-hit treatment for SLEEPWALKER and the unexploited WordPress flaws, and state what should remain monitoring-only. Keep each subject operationally separate and flag where evidence is too weak for destructive remediation.

Decision: contain confirmed compromise and compromised identities before patching. 1—QTFY edge devices: isolate confirmed nodes, preserve evidence, replace or rebuild from known-good images, rotate device/VPN credentials from clean systems, and validate every OT-facing route; Sara’s finding does not justify an OT shutdown. 2—ownCloud: isolate suspect instances, preserve logs, revoke sessions and signing material, then apply a verified fix after staging; CVE-2023-49105 is a plausible path, not proof, so no estate-wide reimaging without host evidence. 3—npm incident: quarantine the ten suspect releases and affected runners, revoke publishing/OIDC credentials, compare source commits with built artifacts, and rebuild cleanly. 4—Trivy incident: suspend the implicated workflow, rotate registry/cloud credentials, and revalidate generated artifacts; valid provenance alone is insufficient, but absent execution evidence, do not wipe downstream systems.

5—Ajna v2: because the affected contract is described as unpatchable, stop new exposure through controlled interfaces, alert position owners, monitor contract activity, and prepare a tested migration—do not improvise destructive fund movement. 6—Rain/Avici/Tria: pause exposed functions where governance permits, simulate upgrades against a fork or staging environment, then upgrade; an untested emergency transaction risks creating a second incident. 7—AI-assisted recovery fraud: disable voice-only recovery, require callbacks through pre-registered channels, block support staff from requesting live 2FA codes, and review resets followed by MFA or payout changes. AnonyMousKIT’s actionable risk is automated impersonation and live 2FA capture, not demonstrated deepfake quality.

Quick hits: SLEEPWALKER: hunt exposed systems for the reported crafted-packet activation path and escalate only on matching network or host evidence. Unexploited WordPress flaws: inventory affected components and stage verified vendor updates this week; no emergency rebuild without exploitation. Keep PRC state direction, an OT bridge, deepfake realism, and campaigns affecting products absent from the estate monitoring-only; none should trigger destructive remediation. I found no current advisory or patch-version data sufficient to name specific fixes for Trivy, Ajna v2, Rain/Avici/Tria, or the WordPress flaws.

Claim: You ranked QTFY edge-device response first in the same-day plan. Counter-evidence: The Philippine ownCloud incident has reported successful exploitation, named nuclear and naval-support victims, sensitive file theft, and roughly 9 GB exfiltration. By contrast, U.S. authorities say QScan and QTRouter domains were seized and rendered inoperable, leaving historical implants as a residual risk rather than proof of current command. Reconcile the ranking: under what evidence should QTFY outrank ownCloud, and what should the default order be for a CISO with exposure to both?

Putting QTFY first was too aggressive. The default order should be ownCloud first, QTFY second. The ownCloud case has reported compromise and exfiltration against named sensitive victims, while the DOJ says seizure of hard-coded domains made QScan and QTRouter inoperable. For exposed ownCloud instances, preserve evidence and isolate first, revoke sessions and signing material from a clean system, then upgrade to a vendor-supported fixed release—NVD identifies versions before 10.13.1 as affected. Rebuild only where compromise or integrity loss is established.

QTFY should outrank ownCloud only when local evidence shows an implanted edge device, recent malicious traffic, alternate command infrastructure, or placement on a privileged VPN/OT-management path—and the ownCloud deployment is demonstrably fixed, unexposed, or absent. Otherwise, hunt QTFY indicators immediately but isolate or replace only confirmed devices; historical indicators alone do not justify mass reimaging after the command infrastructure was disabled.

So the operational order is: 1) contain and investigate ownCloud; 2) hunt and remediate residual QTFY implants; 3) elevate QTFY to first only on evidence of present local control or greater network blast radius.

For SLEEPWALKER, establish the practical detection case rather than restating the headline. What packet conditions activate it, which Windows/ESET Management Agent environments are affected, and what concrete network and host telemetry can detect activation, DLL side-loading, or bytecode execution? State what defenders should do now given that administrator access is already required and no victims, deployment activity, C2 in... [arg clipped]

This is post-exploitation persistence, not an initial-access miracle. The DLL must first be placed beside ERAAgent.exe and loaded into that process. It then remains passive—no beacon—and activates only when traffic matches its custom magic-packet protocol, after which it decrypts and interprets tasking in a 23-opcode bytecode language. The analyzed sample contains a static AES key and recognizable protocol code, but recompilation could change both. No fixed source IP, port, domain, or C2 infrastructure has been established; flow logs alone are therefore weak. Packet capture or IDS inspection for the published protocol signature, correlated with immediate ERAAgent.exe activity, is the practical network detection case. Research (opens in new tab) GitHub (opens in new tab)

The affected-product headline is too broad. The sample is Windows x64 malware, checks only that its host process is named ERAAgent.exe, and carries forged ESET metadata showing version 11.2.2076.0; that does not prove that agent version is vulnerable. ESET reports that its current tested agent loaded the legitimate Windows dpapi.dll, not the local malicious copy. Installations paired with an ESET security product may also have Self-Defense preventing even administrators from modifying the directory. Other agent/Windows combinations remained under investigation, so there is no confirmed affected-version matrix. ESET (opens in new tab)

On hosts, hunt for an unsigned dpapi.dll beside ERAAgent.exe, SHA-256 d347170752a28e2b8c4b8b9f3cab2e3a6541ba11682c94498d26eb9002779d60, unexpected dpapisvc.dll, EveryoneIncludesAnonymous=1, unusual NullSessionPipes entries, and agent-service restarts following those changes. EDR should flag ERAAgent.exe loading DLLs outside expected signed paths, executable-memory or anomalous threads, and subsequent file, registry, child-process, or network activity. Bytecode runs inside the trusted process, so waiting for a suspicious child process will miss some execution.

Do now: 1) inventory Windows agents and inspect their loaded-module paths and installation directories; 2) deploy the file, registry, module-load, memory, and packet detections above—quarantine and acquire memory on any match; 3) update agents, enable Self-Defense/application control, lock the agent directory, and investigate how administrator access could have been obtained. No victims, operational deployment, or C2 have been demonstrated, so hunt hard—but do not call this an active campaign without evidence.