What was read from users' PCs: the samples.zip from the Onamae.com Desktop Cloud incident, and lab tests

Onamae.com Desktop Cloud is cloud-hosted Windows used for automated FX trading. Users connect from their own PCs over Remote Desktop (RDP). On October 20, GMO Internet Group announced that it had found unauthorized programs from a third party on some servers.

A party believed to be the attacker distributed samples.zip on their own site, calling it “data taken from VPSes and users’ PCs”. This post is a record of rereading its contents by counts and formats only. We cannot confirm that the logs are genuine, because the attacker chose these samples themselves.

##What samples.zip is

You may also see the value “232,557 bytes” online. That is the length field in the Wayback Machine index (CDX). It is not the size of the file itself. It is the length of the record stored after gzip compression. The file we actually retrieved was 235,002 bytes. In the same retrieval, source.zip was also larger than the index value (1,351,869), at 1,354,131, so the offset is consistent.

##How we read it: counting only

The logs contain users’ PC names, user names, and file names. So we handled them as follows.

1. Load the files only into REMnux, which is cut off from the outside. Do not write them to the host disk
2. Inside REMnux, count only the line prefixes ([FILE], [DIR], [COPIED]) and file extensions
3. Publish only the aggregate numbers. Do not show file names, paths, or PC names on screen
4. When done, delete the raw files and restore the virtual environment to its pre-work state

##Totals: 4,352 copies

Here are the 4,352 copies by extension.

4,352 is the number of copies written in the logs of these 10 machines. It is not the total damage. We also cannot tell whether the 10 machines the attacker chose represent other users.

There are 19 .rdp files. These are connection files that were saved on users’ PCs. A .rdp file records the destination and the user name, so the same user’s other destinations may have become known.

##When it ran

The execution times written in the logs run from 22:53:53 to 23:16:48 on October 14, 2026. Seven of the 10 machines fall within the 7 seconds from 22:53:53 to 22:54:00. The other two are at 23:14:33 and 23:16:48.

Seven machines in nearly the same second is most naturally explained by an automated run on many VPSes at once, not by a person operating them one at a time. This is our reading, not a confirmed fact.

The logs do not state a time zone. If the VPS clocks are on Japan time, this is five days before October 19, when GMO started investigating after inquiries from users. That would mean something was already running inside the VPSes by then. However, we have not confirmed that the logs themselves are genuine.

##What the shape of the logs shows

The machines differ a lot. The number of copy records ranged from 30 on the lowest machine to 1,155 on the highest. We did not look at file names or paths, so we cannot tell what criteria were used to choose the files to copy.

What follows is our reading. The two kinds of activity we counted are “make a listing” and “copy”, and both are operations that only need to read files. The same records can be produced from the VPS side by reading a drive shared over RDP, without installing anything on the user’s PC. The next section checks this mechanism in the lab.

We counted only the three kinds of lines above. We have not checked whether there are other records of writes. Even if there are none, that does not mean nothing was written. The samples are a subset chosen by the attacker, and as the next section shows, shared drives can also be written to.

##Lab test 1: RDP drive redirection

We check in our own lab whether our reading of the logs is correct. We did not use any real victim’s PC, only test marker files. For the setup, FlareVM was the RDP server, xfreerdp in WSL was the client, and REMnux relayed the TCP traffic.

Without redirection, you get “The network name cannot be found”. The name \\tsclient itself does not exist.

And writing is also possible. It does not stop at reading. That leaves the possibility of something being placed in the Startup folder of a shared drive, or an existing file being replaced.

You can also block it on the server side. If you set the policy fDisableCdm to 1, the share does not appear inside the server even when the client asks for it.

The share is visible only while you are connected over RDP. The users in the 10-machine log are thought to be people who were connected to the VPS at that time.

##Lab test 2: the DPAPI barrier

People often say, “They copied Chrome’s Login Data, so every saved password was read.” But copying the file alone does not let them read everything. The passwords inside are encrypted with DPAPI, a Windows mechanism tied to the user.

We copied data encrypted on DefenderVM to FlareVM and tried to decrypt it.

A file taken out on its own cannot be read on another PC. This is the part you do not need to fear excessively.

However, this applies only to the case where only the file was taken out. If an unauthorized program runs on the user’s PC as that user, DPAPI decrypts normally. Because shared drives can also be written to, we cannot say that entry point did not exist. “Cannot be read” and “safe” are different things. Change your saved passwords (steps are in post 3).

##The email timestamps can be read two ways

One more point about time. The attacker’s site had 25 images of emails to GMO (Gmail screens). The first two show 2:55 AM and 5:07 AM on October 21. Gmail shows times in the viewer’s own time zone setting, so the images alone do not tell us what time this was in Japan.

Both readings have support, and nothing settles it, because we do not have the headers of the original emails. The first image does not show the demanded amount, so we also cannot tell whether it is the same email as the 11:57 document GMO mentions. This post does not decide either way. Also, because the time zone setting can be changed freely, neither reading is evidence of where the attacker is.

##What we don’t know

• Whether the logs are genuine. The attacker made and chose them, so we cannot say they are unaltered
• Whether the 10 machines represent other users, and how many machines in total were read
• Whether the copied files were actually sent out. The logs only show records of copying
• Whether anything was actually written to users’ PCs
• How the attacker got into the VPSes. On their own site, the attacker claims that “the VPSes were connected in one Active Directory environment, and one VPS could be used to move to another”. It also claims that one admin-level account worked on every VPS, and that when a support engineer connected to a customer’s PC, the customer could pull that account’s credentials (post of Oct 24). Both are the attacker’s claims; GMO has not addressed them and we could not confirm them. GMO says it is investigating the intrusion route and has not published a cause (through the 6th notice)

##Summary

1. samples.zip is 235,002 bytes. It holds work logs for 10 machines and does not contain the actual files
2. The logs record 4,352 copies. The largest groups are PDF (1,805) and images (1,464)
3. Seven machines ran in nearly the same second. An automated run at once, not human hands, is the more natural reading
4. The method is RDP drive redirection. In the lab, both reading and writing were possible. The server-side fDisableCdm blocks it
5. A Login Data file on its own cannot be read on another PC. But “cannot be read” and “safe” are different things

How to check your own .rdp and what users should do are covered in post 3.