MANILA: A server exposed on the public internet held custom scripts, transfer logs and files taken from a Philippine nuclear research body. Hunt.io’s incident research says five Python scripts exploited a three-year-old ownCloud flaw to impersonate known users and retrieve files through WebDAV without their passwords.
The August 26 disclosure is newly actionable because CISA added CVE-2023-49105 to its Known Exploited Vulnerabilities Catalog on August 27, with forensic triage required and an August 30 federal remediation deadline. The exposed collection included nuclear-material account records, research-reactor data, employee information and credential stores. A recovered CSV referenced roughly 9 GB taken from the nuclear organization, although Hunt.io could inspect only about 372 MB of those files.
The server held the proof
Hunt.io, which sells infrastructure-monitoring services, says its Attack Capture system found an open directory at 31[.]58[.]209[.]241:8000 on August 13. The directory contained offensive tools, operator-written code, per-file transfer records and stolen material sorted into Simplified Chinese folders. Hunt.io reported the findings to CERT-PH under TLP:AMBER and says the national response team coordinated notification to the affected organizations.
The researcher found 1,310 files across 86 directories on the staging server. Five directories associated with the nuclear research body held 176 files totaling about 372 MB. The visible material included nuclear-material account records, draft strategic plans, a database of reactor core components, historic fuel inventories, radiation-safety documents, employee personal information, BitLocker recovery keys, a KeePass database and AxCrypt-encrypted files.
One operator CSV referenced about 9 GB as stolen from the organization. Hunt.io did not have most of that larger collection in the directory, so the 9 GB figure is an operator record rather than a complete researcher-held inventory. The public records do not establish operational disruption to a reactor or other nuclear system.
The folder names, script comments and log text support Hunt.io’s assessment that the operator likely speaks Chinese. Those clues do not identify a named group or establish direction by the Chinese government.
An empty key forged trust
The entry point was CVE-2023-49105 in ownCloud Server’s pre-signed URL handling. The ownCloud security advisory says an attacker who knows a username can “access, modify or delete any file without authentication” when that user’s signing key is absent. The vendor says that absence was the default state.
Pre-signed URLs are supposed to give a request time-limited authority over a file. A server creates a signature from the request details and a secret signing key, then checks the signature when the client returns. In the affected implementation, ownCloud continued the calculation when no key existed. Both sides used an empty secret. An attacker could reproduce it.
The recovered scripts assembled the query parameters OC-Credential, OC-Verb, OC-Expires, OC-Date and OC-Signature. They placed the account to impersonate in OC-Credential, calculated the signature with an empty byte string and sent requests to paths shaped like /remote.php/dav/files/<account>/<path>. The server accepted those requests as the named user even though the client had supplied no account password.
ownCloud rates the flaw 9.8 under CVSS 3. The affected range is core 10.6.0 through 10.13.0. The vendor fixed the issue in 10.13.1 by denying pre-signed URLs when a file owner’s signing key is missing.
Long description of the ownCloud access chain
The figure’s authentication row begins with an attacker who knows a valid ownCloud username for core 10.6.0 through 10.13.0. The server has no signing key configured for that user, so the attacker reproduces the pre-signed URL calculation with an empty secret. The server accepts the forged WebDAV request, allowing GET and PROPFIND operations to run. The observed-collection row shows requests crossing accounts with pauses of 1.5 to 6 seconds, followed by 176 copied files totaling about 372 MB and containing nuclear records, keys and credential stores. The bottom note distinguishes that recovered collection from an operator CSV that referenced about 9 GB.
Slow requests crossed accounts
Four of the recovered scripts targeted one account each. A fifth added PROPFIND requests with a Depth: 1 header so the operator could enumerate folders before requesting files. That sequence gives defenders a stronger recognition pattern than a large download alone: pre-signed WebDAV query parameters, account names in OC-Credential, folder enumeration and subsequent GET requests across several accounts.
The scripts also inserted random pauses. Four waited three to six seconds between requests; the enumeration-capable script used gaps of roughly 1.5 to 3.5 seconds. Hunt.io assessed the pacing as an attempt to avoid volume-based detection while sustaining collection. Low volume does not clear an exposed system. The authentication fields and account spread remain decisive.
Start the log review with reverse-proxy, load-balancer and ownCloud WebDAV records for /remote.php/dav/files/. Search query strings for OC-Credential, OC-Verb, OC-Expires, OC-Date and OC-Signature. Correlate PROPFIND with Depth: 1 and later GET requests from the same source, especially when one source cycles through unrelated accounts at short, irregular intervals.
The attacker-controlled staging address was 31[.]58[.]209[.]241:8000; treat it as a historical search value because infrastructure can change. Hunt.io also recovered a stage-one loader named multi_backupd with SHA-256 7447d0d0c34779d4c519823b39bf6ddc16d2b34a226b82ee69da6f5b4a77ad82. The researchers said the recovered logs did not tie that loader to the ownCloud intrusion, so a match may identify activity on the broader staging server without proving the nuclear-file theft path.
Stolen files extended the response
The stolen records create two different security problems. Nuclear, personnel and planning documents carry their own confidentiality consequences. BitLocker recovery keys and a KeePass database can also support access to other systems after the file server is patched.
That makes the incident-response boundary larger than the ownCloud host. Teams should identify every account whose files were reachable, every secret or recovery key stored there and every system that trusted those credentials. A clean application upgrade cannot revoke material that was already copied.
The CISA Known Exploited Vulnerabilities Catalog records CVE-2023-49105 as exploited in the wild. CISA lists ransomware use as unknown and requires forensic triage for federal systems. Its August 30 deadline has passed, which makes any remaining vulnerable federal deployment overdue under that instruction.
Scope the exposed servers
Inventory ownCloud Server deployments and record their running core version, internet exposure, WebDAV reachability and signing-key state. The vulnerable version range is 10.6.0 through 10.13.0. Give priority to systems reachable from the internet and repositories holding credentials, regulated documents or operational records.
Move affected servers to 10.13.1 or a later supported build that carries the fix. Confirm the installed artifact rather than relying on a planned change or a deployment ticket. If a distributor backported the fix, obtain its package advisory and map the package build to the upstream remediation.
Contain systems with matching request activity before rotating secrets. Preserve proxy, application and identity logs; identify the accounts named in the pre-signed requests; and reconstruct the files available to those accounts. Rotate exposed passwords, recovery keys, API tokens and vault material after the collection path is contained, then examine the systems that accepted those credentials for follow-on access.
Verify the fixed boundary
The verification test has two parts. First, compare every deployed ownCloud Server against the affected range and confirm that the running artifact is 10.13.1 or later, or a distributor build with a documented backport. The expected result is zero reachable deployments on core 10.6.0 through 10.13.0 and no deployment whose fix status rests only on an unverified change record.
Second, inspect the signing-key state and query historical WebDAV logs for OC-Credential, OC-Verb, OC-Expires, OC-Date and OC-Signature on /remote.php/dav/files/. Correlate PROPFIND enumeration with later GET requests and account changes from one source. The expected result is a non-empty signing key for every active owner and no unexplained accepted pre-signed request sequence. Any match should expand the response to the files, credentials and downstream systems reachable by the impersonated account.