- Hunt.io says an operator copied 68.837 GiB of SQL Server backups, with names matching Philippine overseas-employment systems, in 23 minutes 46 seconds on 6 September 2026.
- The first payload was fetched about 20 hours after the copy ended, and Hunt.io concludes it was not how the data was taken. How the operator got in is unknown.
- Leaders should ask whether large transfers from database hosts raise an alert, and whether the accounts that run services can also read backups.
The copy came first
The obvious focus is the exploit tool. In this case the log points elsewhere. Hunt.io's logs show the database backups were copied first. The first payload was fetched about twenty hours later.
That order matters for anyone who funds security. It suggests that alerting on known attack tools alone would not have caught this copy.
What Hunt.io found
Hunt.io, a threat intelligence firm, captured an open web folder on a rented server at UpCloud in Singapore. Anyone could read the operator's working folder. It included the operator's own transfer log and access log.
In the transfer log, 27 SQL Server backups, 68.837 GiB in total, show as fully copied. The job ran for 23 minutes and 46 seconds on 6 September 2026. Hunt.io says the file names match the case-management systems of a Philippine agency that handles overseas employment and migrant workers. Some carry the labels POEA and OFW.
Dark Reading, which covered the report, says the backups cover accreditation, contracts, and cashier and LandBank records. Hunt.io says its own report contains no personal records or credentials. It notified the relevant national CERT before publishing.
Hunt.io traced two addresses that downloaded files from the folder to certificates issued to the agency. One address took the loader and both payloads. The certificate shows what those addresses are. Hunt.io says it shows nothing about what they did with the files.
What nobody knows yet
The gaps are large. Hunt.io's recovered files do not show how the operator got in. They hold no command channel and no confirmation that any payload ran. The log also names neither the machine the data came from nor where it went.
Esteban Borges, Hunt.io's head of research, told Dark Reading the team cannot say how entry happened, whether the payload executed, or where the data ended up. Hunt.io has not found the data advertised for sale.
Borges still treats the case as a breach. In his words, the data was "copied out of the agency's control." The log also shows the job finishing. Hunt.io did not attribute the activity. Chinese-language fragments in the code belonged to a third-party library.
How the tool works
The payload is a lightly edited copy of GodPotato, a public tool. Hunt.io explains that it lifts a service account to SYSTEM, the top level of Windows access. It does this by abusing two built-in Windows communication layers, DCOM and RPC. It needs no Windows vulnerability.
The tool gets a SYSTEM-level Windows service to connect to a pipe the tool controls. It then copies that service's access token and uses it to run a command. Hunt.io says every step uses a permission the process already holds.
Delivery is quiet too. An eight-line PowerShell script rebuilds the payload in memory from text fragments, so no DLL file touches disk. Hunt.io adds that Microsoft's platform labels the payload Trojan:MSIL/GodPotato.FF!MTB, which backs up its reading of the code. That label helps find the tool. It does not show what the operator did before the tool arrived.
Why the order of events matters
The transfer finished at 01:26:50 on 6 September, Hunt.io's logs show. The access log records the first payload being downloaded at 21:41:33 that day, about twenty hours later. Hunt.io's reading is that the data was not taken through that payload. Whatever access the operator had during the copy was already enough.
In this log, the escalation tool appears after the copy. Defenders who wait for such a tool may arrive after the data has gone. A different signal is a rule that flags about 69 GiB of database backups moving in under half an hour.
That rule is a choice defenders could make, not a finding about this case. The log names neither the source host nor the destination. We cannot say such an alert would have fired here.
One caution on the numbers. The log's displayed speed of 20.238 MiB/s does not match volume divided by time, which is about 49.4 MiB/s. Hunt.io says the tool's summary speed is a rolling average, and reports both figures as logged.
Questions to put to your team
Ask who can read database backups, and whether those accounts also run services. Hunt.io says the operator's access was sufficient before any escalation tool appeared. Ask whether a transfer of tens of gigabytes from a database host triggers an alert, and who receives it.
Ask how fast you could tell regulators, staff and customers what was taken. Here, the operator's own mistake exposed the copy. Do not plan on an intruder's error to tell you.
A backup holds a full copy of a system's data. In this log, copying 27 of them took under 24 minutes.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Hunt.io.
