JPCERT/CC Eyes

In JPCERT/CC Eyes, we previously reported on attacks conducted by Attack Exploiting Legitimate Service by APT-C-60. JPCERT/CC continues to observe similar attack activities in Japan. This report provides an update on the attacks confirmed between June and August 2025, focusing on developments since our last article. The following topics are covered:

• Attack flow
• Updates to the downloader and SpyGlace
• SpyGlace encoding functions and communication methods
• Decoy documents used in the attacks
• Analysis of the GitHub repository

Attack Flow

The attacks confirmed by JPCERT/CC were targeted spear-phishing emails sent to recruitment staff, in which the attackers impersonated job seekers. This pattern is closely similar to attacks that occurred around August 2024. Figure 1 shows the flow of the attack. In the previous attacks, victims were directed to download a VHDX file from Google Drive. However, in the latest attacks, the malicious VHDX file was directly attached to the email. When the recipient clicks the LNK file contained within the VHDX, a malicious script is executed via Git, which is a legitimate file.

The LNK file executes gcmd.exe (a legitimate Git file), and it runs the script glog.txt stored in the VHDX file.

P:\LICENSES.LOG\mingw64\bin\gcmd.exe "cd .\LICENSES.LOG\mingw64\bin && type glog.txt | gcmd.exe" && exit

The script executed by Git is responsible for displaying a decoy document, creating files, and executing those files. The created WebClassUser.dat (hereafter referred to as “Downloader1”) is registered in the registry as shown below, and then it gets persisted and executed through COM hijacking.

HKCU\Software\Classes\CLSID\{566296fe-e0e8-475f-ba9c-a31ad31620b1}\InProcServer32

Updates to Downloader1 and Downloader2

For attackers to identify compromised devices, Downloader1 periodically communicates with a legitimate statistics service called statcounter. The request headers are created in the following format. Compared to earlier versions, the current one is different in that it identifies compromised machines by their volume serial number and computer name.

Referer: ONLINE=>[Number1],[Number2] >> [%userprofile%] / [VolumeSerialNumber + ComputerName]

Downloader1 combines a filename derived from the volume serial number and the computer name with a URL embedded in the malware sample to generate a path in the following format, and it is used for communication.

https://raw.githubusercontent.com/carolab989/class2025/refs/heads/main/[VolumeSerialNumber + ComputerName].txt

The attackers check the referrer value sent to statcounter and then upload a file named "[VolumeSerialNumber + ComputerName].txt" corresponding to the infected device to GitHub. DownLoader1 then retrieves that file from GitHub. Based on the URL in the retrieved file, DownLoader2 is downloaded and executed. In addition to specifying the download URL, the "[VolumeSerialNumber + ComputerName].txt" can execute the following commands in Table 1. For example, the command "1*" can change the interval at which a GET request is sent to statcounter.com from the default of one hour to six hours. Such capability indicates the attackers’ intent to monitor the victim environment more cautiously.

Like earlier versions, the retrieved files are XOR-decoded and then executed using "sgznqhtgnghvmzxponum" as the key. Downloader2 can download and execute SpyGlace and its loader. The malware’s dynamic API resolution uses an encoding scheme based on ADD and XOR. The value has changed from earlier versions, and now XOR 0x05 is performed after add 0x04. The SpyGlace loader uses the same encoding scheme. As in earlier versions, files retrieved by Downloader2 are XOR-decoded with the key "AadDDRTaSPtyAG57er#$ad!lDKTOPLTEL78pE" and then executed by COM hijacking.

Updates to SpyGlace

JPCERT/CC has observed three versions of SpyGlace: 3.1.12, 3.1.13, and 3.1.14. Compared with Version 3.1.6, which was observed by JPCERT/CC in 2024, the previously implemented commands prockill and proclist have been modified to perform no action. JPCERT/CC also confirmed a new command, uld, has been added. The command calls a specific function of a loaded module and then unloads the module two seconds after that. This is possibly intended for modules that must execute a specific function before being unloaded. Additionally, in the screenupload command, the file path and the export function name for what appears to be a screenshot-related module have been changed to those shown below. Since the Clouds.db module itself has not been observed, its functionality is unknown, but it is believed to be related to the screenshot command. For a full list of implemented commands, see Appendix D.

File path: %LocalAppData%\Microsoft\Windows\Clouds\Clouds.db
Export Function: mssc1

There are slight differences among the observed versions, 3.1.12, 3.1.13, and 3.1.14. However, JPCERT/CC confirmed that the Mutex value is different between them. From version 3.1.14, the automatic execution path has also changed from %public%\AccountPictures\Default\ to %appdata%\Microsoft\SystemCertificates\My\CPLs. An article published in September 2025 [1] describes a campaign in which version 3.1.14 was used, but this is likely a separate campaign observed overseas because the GitHub repositories and other resources used in the campaign do not overlap with those observed by JPCERT/CC.

Details of SpyGlace’s Encoding Functions and Communication Methods

SpyGlace’s characteristic encoding scheme combines a single-byte XOR with a SUB instruction. This is heavily used for strings the malware employs and for resolving dynamic APIs. The "Download" command, one of SpyGlace’s commands, downloads an encrypted file. The file is decrypted using AES-128-CBC with the KEY and IV shown below and is created to the path %temp%\wcts66889.tmp. Figure 2 shows a part of the Download command code.

KEY: B0747C82C23359D1342B47A669796989
IV: 21A44712685A8BA42985783B67883999

SpyGlace communicates with its C2 servers using BASE64 and RC4. The format of the request headers used in the initial communication is shown below. The a001 value contains the userid value "GOLDBAR", and it is the same string reported by Positive Technologies [2] and was also used in attacks observed in Japan last year, suggesting that it may indicate the targeted region or a specific campaign. Regarding encoding scheme, SpyGlace has employed a modified RC4 since at least version 3.1.6.

a001=[md5("GOLDBAR")]&a002=[md5(systeminfo)]&a003=["uid" or "info"]&a004=[BASE64(CustomRC4([ComputerName;UserName;CpuInfo;OS Version;SpyGlace Version]))]

The modified RC4 increases the number of KSA cycles and performs additions to the value that is to be XORed. The variant can be decoded with the following Python script.

import base64

def CustomRC4(key: bytes, data: bytes) -> bytes:
    # --- KSA ---
    S = list(range(256))
    n = 3
    for round in range(n):
        j = 0
        keylen = len(key)
        if keylen == 0:
            raise ValueError("key must be non-empty")
        for i in range(256):
            j = (j + S[i] + key[i % keylen]) & 0xFF
            S[i], S[j] = S[j], S[i]

    # --- PRGA ---
    i = j = 0
    out = []
    for b in data:
        i = (i + 1) & 0xFF
        j = (j + S[i]) & 0xFF
        k = S[(S[i] + j) & 0xFF]
        S[i], S[j] = S[j], S[i]
        k2 = S[((S[((i >> 3) ^ (0x20 * j)) & 0xFF] + S[((0x20 * i) ^ (j >> 3)) & 0xFF]) ^ 0xAA) & 0xFF] + S[(S[j] + S[i]) & 0xFF]
        out.append( (b ^ k ^ k2) & 0xFF )
    return bytes(out)


def decode(base64in):
    key = b"90b149c69b149c4b99c04d1dc9b940b9"
    decoded = CustomRC4(key, base64.b64decode(base64in))
    print("Result: ", decoded)

Decoy Document Used

Figure 3 shows a part of the decoy document used in this campaign. Because the attackers targeted recruitment officers, the fabricated resume disguise the writer as a researcher and list multiple academic papers in the CV. However, the authors of those papers do not include the name of the email sender. The name on the resume partially matches the Gmail account name used by the sender, suggesting that the attackers may have created the account specifically for this attack.

Analysis of GitHub Repositories

Because the attackers use GitHub to distribute their payloads, all payloads distributed in the past can be retrieved unless the repository is deleted. Table 2 shows the uploaded SpyGlace versions and the periods during which they were available on GitHub.

JPCERT/CC has identified email addresses recorded in the commit logs of the GitHub repository managed by the attackers, as well as information on compromised devices composed of their volume serial numbers and computer names. The details are provided for reference in Appendices E and F.

In Closing

As with previous cases, attacks by APT-C-60 continue to primarily target Japan and other East Asian regions. While several changes have been identified, such as a shift in infrastructure from Bitbucket to GitHub and updates to the malware itself, many characteristics remain consistent, including the abuse of legitimate services and the behavior of the malware. JPCERT/CC recommends remaining alerted to this threat. C2 and hash values of the confirmed malware are listed in the Appendix. Please note that the C2 information includes legitimate services.

Yuma Masubuchi (Translated by Takumi Nakano)

References

[1] Sangfor 【高级威胁追踪(APT)】深入分析“伪猎者”组织Github仓库加密载荷
https://mp.weixin.qq.com/s/A1UhFfqnGRLsEZywvaQA4A

[2] Positive Technologies DarkHotel. A cluster of groups united by common techniques
https://global.ptsecurity.com/en/research/pt-esc-threat-intelligence/darkhotel-a-cluster-of-groups-united-by-common-techniques/

Appendix A: IoC Network

• https[:]//c.statcounter[.]com/13139439/0/1ba1a548/1/
• https[:]//raw.githubusercontent[.]com/carolab989/class2025//refs/heads/main/
• https[:]//raw.githubusercontent[.]com/football2025/class2025//refs/heads/main/
• https[:]//raw.githubusercontent[.]com/fenchiuwu/class2025/refs/heads/main/
• http[:]//raw.githubusercontent[.]com/Ridgley22387/r834829jf/refs/heads/main/datapages.txt
• http[:]//raw.githubusercontent[.]com/Ridgley22387/r834829jf/refs/heads/main/datautils.txt
• https[:]//bitbucket[.]org/clouds999/glo29839/downloads/
• https[:]//raw.githubusercontent[.]com/goldbars33/ozbdkak33/refs/heads/main/
• https[:]//185.181.230[.]71/wkdo9/4b3ru.asp
• https[:]//185.181.230[.]71/wkdo9/t1802.asp
• https[:]//185.181.230[.]71/wkdo9/n3tb4.asp
• https[:]//185.181.230[.]71/wkdo9/2qpmk.asp

Appendix B: IoC File

Appendix C: Other IoC

Appendix D: Commands

Appendix E: Email address used for the commit

kithatart@outlook.com
magnolia099@163.com
carolab989@proton.me
fenchiuwu@proton.me
Ridgley223870@proton.me

Appendix F: Victimized devices identified from the GitHub repository

1014988494f04da28046ba
1020301627MBE4OSU
2096821130DESKTOP-BN9A2SA
2958455713DESKTOP-NKVAKV1
4205732935******(Names have been masked as they may contain personal information)
3761538073DESKTOP-PVKDUAM
3537034124JKS
3472318429******(Names have been masked as they may contain personal information)
1620260207DESKTOP-6LO36DE
1347261043DESKTOP-0V7K7HA
2352730816DESKTOP-4QC5J5Q
3362573326DESKTOP-43R2GH0